That would be fine with me also. Cheers, Lyndon -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@xxxxxxxxxxxx] Sent: Tuesday, January 18, 2011 7:30 AM To: Robert Sparks Cc: Adam Roach; Jon Peterson; Ong, Lyndon; Mary Barnes; sjames_1958@xxxxxxxxx; sipping LIST Subject: Re: [Technical Errata Reported] RFC3398 (2580) Hi, for the record, I am also OK with "hold for document update". Cheers, Gonzalo On 18/01/2011 5:16 PM, Robert Sparks wrote: > Also, > > 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. > > I agree with "hold for document update". At the worst case, if something sends the CANCEL, > it's introducing traffic into a network that is too congested to handle the CANCEL. In the best case, > it introduces a message (and its retransmissions) that get ignored, or a single message that gets > an error response. (And for completeness, there is one situation that we traded-off to get > congestion protection that sending the cancel will actually improve - when you have lost the path > for responses to get back, but the requests (like the INVITE) was actually processed.) > > So, the question that tips the balance on choosing between verify (for an amended report) and > "hold for document update" is, I believe, "Does this cause a deployment problem". > > RjS > > On Jan 18, 2011, at 8:14 AM, Adam Roach wrote: > >> Yes, it seems correct. I would tag it as accurate, and set the action to "hold for document update". >> >> /a >> >> On 1/18/11 02:51, Jan 18, Gonzalo Camarillo wrote: >>> Hi, >>> >>> Stephen seems to be correct here. The gateway should not send the CANCEL >>> because it has not received any provisional response. I suggest we >>> accept the erratum. Comments? >>> >>> Cheers, >>> >>> Gonzalo >>> >>> On 19/10/2010 8:31 PM, RFC Errata System wrote: >>>> The following errata report has been submitted for RFC3398, >>>> "Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping". >>>> >>>> -------------------------------------- >>>> You may review the report below and at: >>>> http://www.rfc-editor.org/errata_search.php?rfc=3398&eid=2580 >>>> >>>> -------------------------------------- >>>> Type: Technical >>>> Reported by: Stephen James<sjames_1958@xxxxxxxxx> >>>> >>>> Section: 8.1.3 >>>> >>>> Original Text >>>> ------------- >>>> Item 6. >>>> >>>> The gateway also sends a CANCEL message to the SIP node to >>>> >>>> terminate any initiation attempts. >>>> >>>> >>>> >>>> Corrected Text >>>> -------------- >>>> 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." >>>> >>>> Instructions: >>>> ------------- >>>> This errata is currently posted as "Reported". If necessary, please >>>> use "Reply All" to discuss whether it should be verified or >>>> rejected. When a decision is reached, the verifying party (IESG) >>>> can log in to change the status and edit the report, if necessary. >>>> >>>> -------------------------------------- >>>> RFC3398 (draft-ietf-sipping-isup-06) >>>> -------------------------------------- >>>> Title : Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping >>>> Publication Date : December 2002 >>>> Author(s) : G. Camarillo, A. B. Roach, J. Peterson, L. Ong >>>> Category : PROPOSED STANDARD >>>> Source : Session Initiation Proposal Investigation >>>> Area : Real-time Applications and Infrastructure >>>> Stream : IETF >>>> Verifying Party : IESG >>>> >> > _______________________________________________ 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
