[Technical Errata Reported] RFC3398 (2580)

[RFC Errata System]

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 <***@yahoo.com>

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-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP

[Gonzalo Camarillo]

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 <***@yahoo.com>
>
> 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-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP

[Adam Roach]

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<***@yahoo.com>
>>
>> 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-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP

[Robert Sparks]

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<***@yahoo.com>
>>>
>>> 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-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP

[Gonzalo Camarillo]

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<***@yahoo.com>
>>>>
>>>> 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-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP

[Ong, Lyndon]

That would be fine with me also.

Cheers,

Lyndon

-----Original Message-----
From: Gonzalo Camarillo [mailto:***@ericsson.com]
Sent: Tuesday, January 18, 2011 7:30 AM
To: Robert Sparks
Cc: Adam Roach; Jon Peterson; Ong, Lyndon; Mary Barnes; ***@yahoo.com; 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<***@yahoo.com>
>>>>
>>>> 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-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP

[Worley, Dale R (Dale)]

________________________________________
From: sipping-***@ietf.org [sipping-***@ietf.org] On Behalf Of Robert Sparks [***@nostrum.com]

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-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP

[Gonzalo Camarillo]

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-***@ietf.org [sipping-***@ietf.org] On Behalf Of Robert Sparks [***@nostrum.com]
>
> 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-***@cs.columbia.edu for questions on current sip
> Use ***@ietf.org 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-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP

[Robert Sparks]

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-***@ietf.org [sipping-***@ietf.org] On Behalf Of Robert Sparks [***@nostrum.com]
>>
>> 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-***@cs.columbia.edu for questions on current sip
>> Use ***@ietf.org 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-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP