Subject: Re: [Sipping] [Technical Errata Reported] RFC3398 (2580)

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 18 Jan 2011 10:51:23 +0200

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 <[email-masked]>
> 
> 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
>

---

From: Adam Roach <[email-masked]>
Date: Tue, 18 Jan 2011 08:14:18 -0600

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:
>> Reported by: Stephen James<[email-masked]>
>>
>> Section: 8.1.3
>>
>> Original Text
>> -------------
>> Item 6.
>>

---

From: Robert Sparks <[email-masked]>
Date: Tue, 18 Jan 2011 09:16:47 -0600

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
>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 18 Jan 2011 17:29:53 +0200

Hi,

for the record, I am also OK with "hold for document update".

Cheers,

Gonzalo

---

From: "Ong, Lyndon" <[email-masked]>
Date: Tue, 18 Jan 2011 10:35:44 -0500

That would be fine with me also.

Cheers,

Lyndon

-----Original Message-----
From: Gonzalo Camarillo [mailto:[email-masked]] 
Sent: Tuesday, January 18, 2011 7:30 AM
To: Robert Sparks
Cc: Adam Roach; Jon Peterson; Ong, Lyndon; Mary Barnes; [email-masked]; sipping LIST
Subject: Re: [Technical Errata Reported] RFC3398 (2580)

Hi,

Cheers,

Gonzalo

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Wed, 19 Jan 2011 12:04:02 -0500

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Robert Sparks [[email-masked]]

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.

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

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 20 Jan 2011 10:58:29 +0200

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:
> Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP

---

From: Robert Sparks <[email-masked]>
Date: Thu, 20 Jan 2011 08:25:37 -0600

Right now an AD has to do that entry. We'll make sure it gets in.

RjS