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
