Right now an AD has to do that entry. We'll make sure it gets in. RjS On Jan 20, 2011, at 2:58 AM, Gonzalo Camarillo wrote: > 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
