Hi Dale, everybody seems to agree with your recommendation. Do you want to update the status of this erratum in the RFC Errata Verification page or you want one of us to take care of it? Thanks, Gonzalo On 19/01/2011 7:04 PM, Worley, Dale R (Dale) wrote: > ________________________________________ > From: sipping-bounces@xxxxxxxx [sipping-bounces@xxxxxxxx] On Behalf Of Robert Sparks [rjsparks@xxxxxxxxxxx] > > The report is not complete - there are other examples in the document with the same bug. > If you're going to fix one of them by errata, you probably need to fix all of them. > _______________________________________________ > > Yeah -- that's covered in my errata report of 21 Dec (resent 3 Jan): > > http://www.ietf.org/mail-archive/web/sipping/current/msg17732.html > > ====================================================================== > RFC3398, "ISDN User Part (ISUP) to SIP Mapping" > Source of RFC: sipping (rai) > > Errata ID: 2580 > > Status: Reported > Type: Technical > > Reported By: Stephen James > Date Reported: 2010-10-19 > > Section 8.1.3 says: > > Item 6. > The gateway also sends a CANCEL message to the SIP node to > terminate any initiation attempts. > > It should say: > > Drop this statement. > > Notes: > > No CANCEL is sent on INVITE transaction timeout. This is per 3261 "If > no provisional response has been received, the CANCEL request MUST NOT > be sent; rather, the client MUST wait for the arrival of a provisional > response before sending the request." > ---------------------------------------------------------------------- > Recommended status: (correct) Hold for document update > > Section 8.1.3 item 6 should be updated to "The gateway also sends a > CANCEL message to the SIP node to terminate the initiation attempt if > a provisional response has been received." The situation illustrated > in section 8.1.3 does not distinguish the "provisional response > received" case from the "provisional response not received" case, so > the commentary should cover both cases. (The specific example > diagrammed shows the "no provisional response received" case.) > > A similar change should be made to section 8.1.4 item 7, "The REL will > trigger a CANCEL request to the SIP node if a provisional response has > been received." > > A similar change should be made to section 8.1.7 item 7, "Upon receipt > of a REL message before an INVITE final response, the gateway will > send a CANCEL towards the SIP node if a provisional response has been > received. > > Since a reader familiar with SIP will know the rules for sending > CANCEL, this correction is not crucial for proper implementation of > the RFC, so I am recommending that it be held for document update. > ====================================================================== > > Dale > _______________________________________________ > Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip > Use sip@xxxxxxxx for new developments of core SIP _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
