[Technical Errata Reported] RFC3261 (2910)

[RFC Errata System]

The following errata report has been submitted for RFC3261,
"SIP: Session Initiation Protocol".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3261&eid=2910

--------------------------------------
Type: Technical
Reported by: Iñaki Baz Castillo <***@aliax.net>

Section: Table 2

Original Text
-------------
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
Contact 1xx - - - o - -

Corrected Text
--------------
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
Contact 1xx - - - m - -

Notes
-----
RFC 3261 says:

Section 12.1: "Dialogs are created through the generation of non-failure responses to requests with specific methods. Within this specification, only 2xx and 101-199 responses with a To tag, where the request was INVITE, will establish a dialog."

Section 12.1.1: "When a UAS responds to a request with a response that establishes a dialog (such as a 2xx to INVITE), the UAS MUST copy all Record-Route header field values from the request into the response [...]. The UAS MUST add a Contact header field to the response."

So it's clear that a 1xx response to an INVITE creates a dialog and then it MUST contain a Contact header and mirrored Record-Route headers.

However Table 2 (page 162) says:

Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
Contact 1xx - - - o - -
Record-Route 2xx,18x mr - o o o o -

Obviously Record-Route is optional since in the absence of a proxy doing record-routing, such header will not be present. However Contact header should appear as mandatory (m) for 1xx responses for INVITE rather than optional (o).

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.

--------------------------------------
RFC3261 (draft-ietf-sip-rfc2543bis-09)
--------------------------------------
Title : SIP: Session Initiation Protocol
Publication Date : June 2002
Author(s) : J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler
Category : PROPOSED STANDARD
Source : Session Initiation Protocol
Area : Real-time Applications and Infrastructure
Stream : IETF
Verifying Party : IESG

[Bob Penfield]

The entry in the table should be "c" (not "m"). A Contact is not required in a 100 Trying response. The Contact is only required for a 1xx that creates a dialog.


-----Original Message-----
From: sip-***@ietf.org [mailto:sip-***@ietf.org] On Behalf Of RFC Errata System
Sent: Tuesday, August 02, 2011 10:54 AM
To: ***@dynamicsoft.com; ***@cs.columbia.edu; ***@ericsson.com; ***@wcom.com; ***@neustar.com; ***@dynamicsoft.com; ***@icir.org; ***@research.att.com; ***@ericsson.com; ***@nostrum.com; ***@softarmor.com; ***@alcatel-lucent.com
Cc: ***@ietf.org; rfc-***@rfc-editor.org
Subject: [Sip] [Technical Errata Reported] RFC3261 (2910)


The following errata report has been submitted for RFC3261,
"SIP: Session Initiation Protocol".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3261&eid=2910

--------------------------------------
Type: Technical
Reported by: Iñaki Baz Castillo <***@aliax.net>

Section: Table 2

Original Text
-------------
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
Contact 1xx - - - o - -

Corrected Text
--------------
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
Contact 1xx - - - m - -

Notes
-----
RFC 3261 says:

Section 12.1: "Dialogs are created through the generation of non-failure responses to requests with specific methods. Within this specification, only 2xx and 101-199 responses with a To tag, where the request was INVITE, will establish a dialog."

Section 12.1.1: "When a UAS responds to a request with a response that establishes a dialog (such as a 2xx to INVITE), the UAS MUST copy all Record-Route header field values from the request into the response [...]. The UAS MUST add a Contact header field to the response."

So it's clear that a 1xx response to an INVITE creates a dialog and then it MUST contain a Contact header and mirrored Record-Route headers.

However Table 2 (page 162) says:

Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
Contact 1xx - - - o - -
Record-Route 2xx,18x mr - o o o o -

Obviously Record-Route is optional since in the absence of a proxy doing record-routing, such header will not be present. However Contact header should appear as mandatory (m) for 1xx responses for INVITE rather than optional (o).

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.

--------------------------------------
RFC3261 (draft-ietf-sip-rfc2543bis-09)
--------------------------------------
Title : SIP: Session Initiation Protocol
Publication Date : June 2002
Author(s) : J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler
Category : PROPOSED STANDARD
Source : Session Initiation Protocol
Area : Real-time Applications and Infrastructure
Stream : IETF
Verifying Party : IESG
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core SIP specifications.

[Iñaki Baz Castillo]

2011/8/2 Bob Penfield <***@acmepacket.com>:
> The entry in the table should be "c" (not "m"). A Contact is not required in a 100 Trying response. The Contact is only required for a 1xx that creates a dialog.

Right.

--
Iñaki Baz Castillo
<***@aliax.net>
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core SIP specifi

[Robert Sparks]

(removing the RFC Editor, and setting reply-to to the sipcore list)

Some thing to think about when considering errata on the existing Tables 2 and 3 in RFC3261:

We have had many conversations about the utility of maintaining tables 2 and 3.
I think the most recent was around the Anaheim meeting - see the notes at:
<http://www.ietf.org/proceedings/77/minutes/sipcore.html>

We had strong support for not continuing to add information to Tables 2 and 3, but not
to remove the existing tables from the document. Maintaining the existing table is
probably a separate question, but keep the arguments noted in the minutes above in
mind when choosing to do so.

RjS

On Aug 2, 2011, at 1:28 PM, Iñaki Baz Castillo wrote:

> 2011/8/2 Bob Penfield <***@acmepacket.com>:
>> The entry in the table should be "c" (not "m"). A Contact is not required in a 100 Trying response. The Contact is only required for a 1xx that creates a dialog.
>
> Right.
>
> --
> Iñaki Baz Castillo
> <***@aliax.net>

_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core SIP specifications.

[Iñaki Baz Castillo]

2011/8/2 Robert Sparks <***@nostrum.com>:
> (removing the RFC Editor, and setting reply-to to the sipcore list)
>
> Some thing to think about when considering errata on the existing Tables 2 and 3 in RFC3261:
>
> We have had many conversations about the utility of maintaining tables 2 and 3.
> I think the most recent was around the Anaheim meeting - see the notes at:
> <http://www.ietf.org/proceedings/77/minutes/sipcore.html>
>
> We had strong support for not continuing to add information to Tables 2 and 3, but not
> to remove the existing tables from the document.  Maintaining the existing table is
> probably a separate question, but keep the arguments noted in the minutes above in
> mind when choosing to do so.

I also think that table 2 (at least table 2) is not useful, and just
adds complexity. It's much better to explain/describe/mandate the
presence of headers in the text (IMHO).

Regards.



--
Iñaki Baz Castillo
<***@aliax.net>
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core

[Robert Sparks]

(Attempting to move this to the sipcore mailing list)

Further, they're only going to make sense for 1xx that is sent using 100rel.

So the errata as submitted is incorrect. We could just reject it and move on (my preference given the way we're handling Table 2),
or try to edit it to be more correct and put it in hold-for-document update (see <http://www.ietf.org/iesg/statement/errata-processing.html>).

RjS

On Aug 2, 2011, at 10:58 AM, Bob Penfield wrote:

> The entry in the table should be "c" (not "m"). A Contact is not required in a 100 Trying response. The Contact is only required for a 1xx that creates a dialog.
>
>
> -----Original Message-----
> From: sip-***@ietf.org [mailto:sip-***@ietf.org] On Behalf Of RFC Errata System
> Sent: Tuesday, August 02, 2011 10:54 AM
> To: ***@dynamicsoft.com; ***@cs.columbia.edu; ***@ericsson.com; ***@wcom.com; ***@neustar.com; ***@dynamicsoft.com; ***@icir.org; ***@research.att.com; ***@ericsson.com; ***@nostrum.com; ***@softarmor.com; ***@alcatel-lucent.com
> Cc: ***@ietf.org; rfc-***@rfc-editor.org
> Subject: [Sip] [Technical Errata Reported] RFC3261 (2910)
>
>
> The following errata report has been submitted for RFC3261,
> "SIP: Session Initiation Protocol".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=3261&eid=2910
>
> --------------------------------------
> Type: Technical
> Reported by: Iñaki Baz Castillo <***@aliax.net>
>
> Section: Table 2
>
> Original Text
> -------------
> Header field where proxy ACK BYE CAN INV OPT REG
> ___________________________________________________________
> Contact 1xx - - - o - -
>
> Corrected Text
> --------------
> Header field where proxy ACK BYE CAN INV OPT REG
> ___________________________________________________________
> Contact 1xx - - - m - -
>
> Notes
> -----
> RFC 3261 says:
>
> Section 12.1: "Dialogs are created through the generation of non-failure responses to requests with specific methods. Within this specification, only 2xx and 101-199 responses with a To tag, where the request was INVITE, will establish a dialog."
>
> Section 12.1.1: "When a UAS responds to a request with a response that establishes a dialog (such as a 2xx to INVITE), the UAS MUST copy all Record-Route header field values from the request into the response [...]. The UAS MUST add a Contact header field to the response."
>
> So it's clear that a 1xx response to an INVITE creates a dialog and then it MUST contain a Contact header and mirrored Record-Route headers.
>
> However Table 2 (page 162) says:
>
> Header field where proxy ACK BYE CAN INV OPT REG
> ___________________________________________________________
> Contact 1xx - - - o - -
> Record-Route 2xx,18x mr - o o o o -
>
> Obviously Record-Route is optional since in the absence of a proxy doing record-routing, such header will not be present. However Contact header should appear as mandatory (m) for 1xx responses for INVITE rather than optional (o).
>
> 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.
>
> --------------------------------------
> RFC3261 (draft-ietf-sip-rfc2543bis-09)
> --------------------------------------
> Title : SIP: Session Initiation Protocol
> Publication Date : June 2002
> Author(s) : J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler
> Category : PROPOSED STANDARD
> Source : Session Initiation Protocol
> Area : Real-time Applications and Infrastructure
> Stream : IETF
> Verifying Party : IESG

_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core SIP specifications.

[Iñaki Baz Castillo]

2011/8/2 Robert Sparks <***@nostrum.com>:
> Further, they're only going to make sense for 1xx that is sent using 100rel.

This has been discussed in sip-implementors, and that assertion seems
incorrect. As I've reported in the errata:


Section 12.1: "Dialogs are created through the generation of
non-failure responses to requests with specific methods. Within this
specification, only 2xx and 101-199 responses with a To tag, where the
request was INVITE, will establish a dialog."

Section 12.1.1: "When a UAS responds to a request with a response that
establishes a dialog (such as a 2xx to INVITE), the UAS MUST copy all
Record-Route header field values from the request into the response
[...]. The UAS MUST add a Contact header field to the response."

So it's clear that a 1xx response to an INVITE creates a dialog and
then it MUST contain a Contact header and mirrored Record-Route
headers, *regardless* the usage of 100rel.

Am I wrong? if so, why?

Regards.


--
Iñaki Baz Castillo
<***@aliax.net>
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the cor

[Robert Sparks]

(removing the rfc-editor and trimming the distribution to the lists)

On Aug 2, 2011, at 5:24 PM, Iñaki Baz Castillo wrote:

> 2011/8/2 Robert Sparks <***@nostrum.com>:
>> Further, they're only going to make sense for 1xx that is sent using 100rel.
>
> This has been discussed in sip-implementors, and that assertion seems
> incorrect. As I've reported in the errata:
>
>
> Section 12.1: "Dialogs are created through the generation of
> non-failure responses to requests with specific methods. Within this
> specification, only 2xx and 101-199 responses with a To tag, where the
> request was INVITE, will establish a dialog."
>
> Section 12.1.1: "When a UAS responds to a request with a response that
> establishes a dialog (such as a 2xx to INVITE), the UAS MUST copy all
> Record-Route header field values from the request into the response
> [...]. The UAS MUST add a Contact header field to the response."
>
> So it's clear that a 1xx response to an INVITE creates a dialog and
> then it MUST contain a Contact header and mirrored Record-Route
> headers, *regardless* the usage of 100rel.
>
> Am I wrong? if so, why?

Not wrong, just incomplete. This will create an (early) dialog at the UAS.
It may or may not create a dialog at the UAC without 100rel since the
message may never get to the UAC. Where I said "make sense" above,
it might have been better if I had said "be useful".

>
> Regards.
>
>
> --
> Iñaki Baz Castillo
> <***@aliax.net>
> _______________________________________________
> sipcore mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore

_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core SIP specifications.

[Samir Srivastava]

Hi, IMHO presentation of information in tabulated form helps a lot to
starters. Like ABNF it helps parser developers (expert of syntax &
semantic analysis) to develop it without referring each line of SIP
rfc's. 3262 or 100rel should have updated table Ideally each
subsequent RFC should conisder table updation. Tabulation of
information will be done by vendors internally anyway. So do it in
community. SIP needed hitchakers guide. Simplicity for starters
please. Regards Samir

On 8/4/11, Romel Khan <***@idt.net> wrote:
> So it is useful if one of UAS or UAC requires it, but it does not have to be
> mandatory. Some comments:
> -- RFC3261 mentions early dialog without mentioning RFC3262. Then it seems
> logical to me that it needs to be made clear in this RFC3261 that early
> dialog must mean Contact and Record-Route (if Record-Route was received in
> INVITE) headers is mandatory in 1xx without reference to 100rel.
>
> -- A UAS could always send 1xx with headers that are required for early
> dialog but it doesn't have to enforce 100rel (eg because the origination or
> UAS side itself may not support reliable provisional response handling, or
> reliable provisioning not really required for its operation). UAS could send
> "support:100rel" if it supports it, or it would not send it if it doesn't
> support this. In my opinion, if UAC hasn't sent 100rel required, it should
> be up to the UAS to decide whether to enforce 100rel
> (with "required:100rel") if its application really requires SIP requests
> before call answer. If the origination side (UAC) side has a need to send
> early requests, like UPDATE, then the UAC should require 100rel from the
> termination side (UAS) by sending this in INVITE. In a VoIP service provider
> world, these kind of capabilities are configured during interconnect turn
> up.
>
> -- I notice that some vendors gateway implementations, even if gateway is
> the termination side, require 100rel for the gateway to receive pre-answer
> requests such as UPDATE. This really didn't have to be this way. I have
> always seen these gateways, when it is the termination side, respond back
> SIP 183 with the headers that create early dialog. So if the origination
> side received the SIP 183 response, then there is no reason for the
> origination side to now not be able to send UPDATE request. Also, no
> reason for the termination gateways to not accept the SIP UPDATE without
> requiring PRACK.
>
> Thanks.
>
> On Wed, Aug 3, 2011 at 11:46 AM, Robert Sparks <***@nostrum.com> wrote:
>
>> (removing the rfc-editor and trimming the distribution to the lists)
>>
>> On Aug 2, 2011, at 5:24 PM, Iñaki Baz Castillo wrote:
>>
>> > 2011/8/2 Robert Sparks <***@nostrum.com>:
>> >> Further, they're only going to make sense for 1xx that is sent using
>> 100rel.
>> >
>> > This has been discussed in sip-implementors, and that assertion seems
>> > incorrect. As I've reported in the errata:
>> >
>> >
>> > Section 12.1: "Dialogs are created through the generation of
>> > non-failure responses to requests with specific methods. Within this
>> > specification, only 2xx and 101-199 responses with a To tag, where the
>> > request was INVITE, will establish a dialog."
>> >
>> > Section 12.1.1: "When a UAS responds to a request with a response that
>> > establishes a dialog (such as a 2xx to INVITE), the UAS MUST copy all
>> > Record-Route header field values from the request into the response
>> > [...]. The UAS MUST add a Contact header field to the response."
>> >
>> > So it's clear that a 1xx response to an INVITE creates a dialog and
>> > then it MUST contain a Contact header and mirrored Record-Route
>> > headers, *regardless* the usage of 100rel.
>> >
>> > Am I wrong? if so, why?
>>
>> Not wrong, just incomplete. This will create an (early) dialog at the UAS.
>> It may or may not create a dialog at the UAC without 100rel since the
>> message may never get to the UAC. Where I said "make sense" above,
>> it might have been better if I had said "be useful".
>>
>> >
>> > Regards.
>> >
>> >
>> > --
>> > Iñaki Baz Castillo
>> > <***@aliax.net>
>> > _______________________________________________
>> > sipcore mailing list
>> > ***@ietf.org
>> > https://www.ietf.org/mailman/listinfo/sipcore
>>
>> _______________________________________________
>> Sip mailing list https://www.ietf.org/mailman/listinfo/sip
>> This list is essentially closed and only used for finishing old business.
>> Use sip-***@cs.columbia.edu for questions on how to develop a SIP
>> implementation.
>> Use ***@ietf.org for new developments on the application of sip.
>> Use ***@ietf.org for issues related to maintenance of the core SIP
>> specifications.
>>
>
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core SIP specifications.

[Paul Kyzivat]

On 8/5/11 12:15 AM, Samir Srivastava wrote:
> Hi, IMHO presentation of information in tabulated form helps a lot to
> starters. Like ABNF it helps parser developers (expert of syntax&
> semantic analysis) to develop it without referring each line of SIP
> rfc's. 3262 or 100rel should have updated table Ideally each
> subsequent RFC should conisder table updation. Tabulation of
> information will be done by vendors internally anyway. So do it in
> community. SIP needed hitchakers guide. Simplicity for starters
> please. Regards Samir

That was the concept that led to the table in the first place.
But history has shown this not to work very well in practice, for a
number of reasons. Here are some:

- it proved impossible to define a table format that expressed
all the nuances. There still had to be text to explain the
complex cases. People tended to believe the table even though
its flagged as having exceptions

- extensions to sip require updates to the table. But the extensions
are done in separate RFCs, not revisions to 3261. So they tended
to specify new rows to the table. These never get rolled up in
one place. Also, extensions that add methods add columns to the
table. When that happens, then you need to specify the values
for the new columns, for rows in 3261 and also in all extensions
that added rows. This is difficult, and was rarely if ever done
right.

- given both a table and text descriptions of what is required,
it was unclear which is the authoritative normative specification.

(I'm certain there are more reasons.)

To be workable we would probably need to move the entire table to an
IANA registry. That also seemed unworkable.

And with text descriptions it is easier to specify the requirements in
ways that will apply to most headers and methods that might be defined
in the future.

The bottom line is that we ultimately decided that the table was a bad
idea and we didn't want to continue maintaining it.

Thanks,
Paul

> On 8/4/11, Romel Khan<***@idt.net> wrote:
>> So it is useful if one of UAS or UAC requires it, but it does not have to be
>> mandatory. Some comments:
>> -- RFC3261 mentions early dialog without mentioning RFC3262. Then it seems
>> logical to me that it needs to be made clear in this RFC3261 that early
>> dialog must mean Contact and Record-Route (if Record-Route was received in
>> INVITE) headers is mandatory in 1xx without reference to 100rel.
>>
>> -- A UAS could always send 1xx with headers that are required for early
>> dialog but it doesn't have to enforce 100rel (eg because the origination or
>> UAS side itself may not support reliable provisional response handling, or
>> reliable provisioning not really required for its operation). UAS could send
>> "support:100rel" if it supports it, or it would not send it if it doesn't
>> support this. In my opinion, if UAC hasn't sent 100rel required, it should
>> be up to the UAS to decide whether to enforce 100rel
>> (with "required:100rel") if its application really requires SIP requests
>> before call answer. If the origination side (UAC) side has a need to send
>> early requests, like UPDATE, then the UAC should require 100rel from the
>> termination side (UAS) by sending this in INVITE. In a VoIP service provider
>> world, these kind of capabilities are configured during interconnect turn
>> up.
>>
>> -- I notice that some vendors gateway implementations, even if gateway is
>> the termination side, require 100rel for the gateway to receive pre-answer
>> requests such as UPDATE. This really didn't have to be this way. I have
>> always seen these gateways, when it is the termination side, respond back
>> SIP 183 with the headers that create early dialog. So if the origination
>> side received the SIP 183 response, then there is no reason for the
>> origination side to now not be able to send UPDATE request. Also, no
>> reason for the termination gateways to not accept the SIP UPDATE without
>> requiring PRACK.
>>
>> Thanks.
>>
>> On Wed, Aug 3, 2011 at 11:46 AM, Robert Sparks<***@nostrum.com> wrote:
>>
>>> (removing the rfc-editor and trimming the distribution to the lists)
>>>
>>> On Aug 2, 2011, at 5:24 PM, Iñaki Baz Castillo wrote:
>>>
>>>> 2011/8/2 Robert Sparks<***@nostrum.com>:
>>>>> Further, they're only going to make sense for 1xx that is sent using
>>> 100rel.
>>>>
>>>> This has been discussed in sip-implementors, and that assertion seems
>>>> incorrect. As I've reported in the errata:
>>>>
>>>>
>>>> Section 12.1: "Dialogs are created through the generation of
>>>> non-failure responses to requests with specific methods. Within this
>>>> specification, only 2xx and 101-199 responses with a To tag, where the
>>>> request was INVITE, will establish a dialog."
>>>>
>>>> Section 12.1.1: "When a UAS responds to a request with a response that
>>>> establishes a dialog (such as a 2xx to INVITE), the UAS MUST copy all
>>>> Record-Route header field values from the request into the response
>>>> [...]. The UAS MUST add a Contact header field to the response."
>>>>
>>>> So it's clear that a 1xx response to an INVITE creates a dialog and
>>>> then it MUST contain a Contact header and mirrored Record-Route
>>>> headers, *regardless* the usage of 100rel.
>>>>
>>>> Am I wrong? if so, why?
>>>
>>> Not wrong, just incomplete. This will create an (early) dialog at the UAS.
>>> It may or may not create a dialog at the UAC without 100rel since the
>>> message may never get to the UAC. Where I said "make sense" above,
>>> it might have been better if I had said "be useful".
>>>
>>>>
>>>> Regards.
>>>>
>>>>
>>>> --
>>>> Iñaki Baz Castillo
>>>> <***@aliax.net>
>>>> _______________________________________________
>>>> sipcore mailing list
>>>> ***@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/sipcore
>>>
>>> _______________________________________________
>>> Sip mailing list https://www.ietf.org/mailman/listinfo/sip
>>> This list is essentially closed and only used for finishing old business.
>>> Use sip-***@cs.columbia.edu for questions on how to develop a SIP
>>> implementation.
>>> Use ***@ietf.org for new developments on the application of sip.
>>> Use ***@ietf.org for issues related to maintenance of the core SIP
>>> specifications.
>>>
>>
> _______________________________________________
> Sip mailing list https://www.ietf.org/mailman/listinfo/sip
> This list is essentially closed and only used for finishing old business.
> Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
> Use ***@ietf.org for new developments on the application of sip.
> Use ***@ietf.org for issues related to maintenance of the core SIP specifications.
>

_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core SIP specifications.

[Samir Srivastava]

Hi, IMHO the updation (to 3261) requirement MUST be needed for
non-table RFC also. We should be sufficient with tables in different
RFCs. Consider development of PUBLISH if UA doesnot support publish it
can still claim 3261 compliance via tables only. Single table req is
not good. By the same token we might need SINGLE place for headers in
textual description. With c,m, m*, o, t labels it is much easier for
parsers. Let TU developers worry about the context/usage. This needs
updation when it widens/narrows. Text only version will cause lengthy
discussions referring lines etc for message rejection. We can say
table with associated section is normative for parsing. TU usage refer
other sections. Regards Samir


On 8/5/11, Paul Kyzivat <***@alum.mit.edu> wrote:
> On 8/5/11 12:15 AM, Samir Srivastava wrote:
>> Hi, IMHO presentation of information in tabulated form helps a lot to
>> starters. Like ABNF it helps parser developers (expert of syntax&
>> semantic analysis) to develop it without referring each line of SIP
>> rfc's. 3262 or 100rel should have updated table Ideally each
>> subsequent RFC should conisder table updation. Tabulation of
>> information will be done by vendors internally anyway. So do it in
>> community. SIP needed hitchakers guide. Simplicity for starters
>> please. Regards Samir
>
> That was the concept that led to the table in the first place.
> But history has shown this not to work very well in practice, for a
> number of reasons. Here are some:
>
> - it proved impossible to define a table format that expressed
> all the nuances. There still had to be text to explain the
> complex cases. People tended to believe the table even though
> its flagged as having exceptions
>
> - extensions to sip require updates to the table. But the extensions
> are done in separate RFCs, not revisions to 3261. So they tended
> to specify new rows to the table. These never get rolled up in
> one place. Also, extensions that add methods add columns to the
> table. When that happens, then you need to specify the values
> for the new columns, for rows in 3261 and also in all extensions
> that added rows. This is difficult, and was rarely if ever done
> right.
>
> - given both a table and text descriptions of what is required,
> it was unclear which is the authoritative normative specification.
>
> (I'm certain there are more reasons.)
>
> To be workable we would probably need to move the entire table to an
> IANA registry. That also seemed unworkable.
>
> And with text descriptions it is easier to specify the requirements in
> ways that will apply to most headers and methods that might be defined
> in the future.
>
> The bottom line is that we ultimately decided that the table was a bad
> idea and we didn't want to continue maintaining it.
>
> Thanks,
> Paul
>
>> On 8/4/11, Romel Khan<***@idt.net> wrote:
>>> So it is useful if one of UAS or UAC requires it, but it does not have to
>>> be
>>> mandatory. Some comments:
>>> -- RFC3261 mentions early dialog without mentioning RFC3262. Then it
>>> seems
>>> logical to me that it needs to be made clear in this RFC3261 that early
>>> dialog must mean Contact and Record-Route (if Record-Route was received
>>> in
>>> INVITE) headers is mandatory in 1xx without reference to 100rel.
>>>
>>> -- A UAS could always send 1xx with headers that are required for early
>>> dialog but it doesn't have to enforce 100rel (eg because the origination
>>> or
>>> UAS side itself may not support reliable provisional response handling,
>>> or
>>> reliable provisioning not really required for its operation). UAS could
>>> send
>>> "support:100rel" if it supports it, or it would not send it if it doesn't
>>> support this. In my opinion, if UAC hasn't sent 100rel required, it
>>> should
>>> be up to the UAS to decide whether to enforce 100rel
>>> (with "required:100rel") if its application really requires SIP requests
>>> before call answer. If the origination side (UAC) side has a need to send
>>> early requests, like UPDATE, then the UAC should require 100rel from the
>>> termination side (UAS) by sending this in INVITE. In a VoIP service
>>> provider
>>> world, these kind of capabilities are configured during interconnect turn
>>> up.
>>>
>>> -- I notice that some vendors gateway implementations, even if gateway is
>>> the termination side, require 100rel for the gateway to receive
>>> pre-answer
>>> requests such as UPDATE. This really didn't have to be this way. I have
>>> always seen these gateways, when it is the termination side, respond back
>>> SIP 183 with the headers that create early dialog. So if the origination
>>> side received the SIP 183 response, then there is no reason for the
>>> origination side to now not be able to send UPDATE request. Also, no
>>> reason for the termination gateways to not accept the SIP UPDATE without
>>> requiring PRACK.
>>>
>>> Thanks.
>>>
>>> On Wed, Aug 3, 2011 at 11:46 AM, Robert Sparks<***@nostrum.com>
>>> wrote:
>>>
>>>> (removing the rfc-editor and trimming the distribution to the lists)
>>>>
>>>> On Aug 2, 2011, at 5:24 PM, Iñaki Baz Castillo wrote:
>>>>
>>>>> 2011/8/2 Robert Sparks<***@nostrum.com>:
>>>>>> Further, they're only going to make sense for 1xx that is sent using
>>>> 100rel.
>>>>>
>>>>> This has been discussed in sip-implementors, and that assertion seems
>>>>> incorrect. As I've reported in the errata:
>>>>>
>>>>>
>>>>> Section 12.1: "Dialogs are created through the generation of
>>>>> non-failure responses to requests with specific methods. Within this
>>>>> specification, only 2xx and 101-199 responses with a To tag, where the
>>>>> request was INVITE, will establish a dialog."
>>>>>
>>>>> Section 12.1.1: "When a UAS responds to a request with a response that
>>>>> establishes a dialog (such as a 2xx to INVITE), the UAS MUST copy all
>>>>> Record-Route header field values from the request into the response
>>>>> [...]. The UAS MUST add a Contact header field to the response."
>>>>>
>>>>> So it's clear that a 1xx response to an INVITE creates a dialog and
>>>>> then it MUST contain a Contact header and mirrored Record-Route
>>>>> headers, *regardless* the usage of 100rel.
>>>>>
>>>>> Am I wrong? if so, why?
>>>>
>>>> Not wrong, just incomplete. This will create an (early) dialog at the
>>>> UAS.
>>>> It may or may not create a dialog at the UAC without 100rel since the
>>>> message may never get to the UAC. Where I said "make sense" above,
>>>> it might have been better if I had said "be useful".
>>>>
>>>>>
>>>>> Regards.
>>>>>
>>>>>
>>>>> --
>>>>> Iñaki Baz Castillo
>>>>> <***@aliax.net>
>>>>> _______________________________________________
>>>>> sipcore mailing list
>>>>> ***@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/sipcore
>>>>
>>>> _______________________________________________
>>>> Sip mailing list https://www.ietf.org/mailman/listinfo/sip
>>>> This list is essentially closed and only used for finishing old
>>>> business.
>>>> Use sip-***@cs.columbia.edu for questions on how to develop a
>>>> SIP
>>>> implementation.
>>>> Use ***@ietf.org for new developments on the application of sip.
>>>> Use ***@ietf.org for issues related to maintenance of the core SIP
>>>> specifications.
>>>>
>>>
>> _______________________________________________
>> Sip mailing list https://www.ietf.org/mailman/listinfo/sip
>> This list is essentially closed and only used for finishing old business.
>> Use sip-***@cs.columbia.edu for questions on how to develop a SIP
>> implementation.
>> Use ***@ietf.org for new developments on the application of sip.
>> Use ***@ietf.org for issues related to maintenance of the core SIP
>> specifications.
>>
>
> _______________________________________________
> Sip mailing list https://www.ietf.org/mailman/listinfo/sip
> This list is essentially closed and only used for finishing old business.
> Use sip-***@cs.columbia.edu for questions on how to develop a SIP
> implementation.
> Use ***@ietf.org for new developments on the application of sip.
> Use ***@ietf.org for issues related to maintenance of the core SIP
> specifications.
>
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core SIP specifications.

[Paul Kyzivat]

On 8/10/11 9:37 AM, Samir Srivastava wrote:
> Hi, IMHO the updation (to 3261) requirement MUST be needed for
> non-table RFC also. We should be sufficient with tables in different
> RFCs. Consider development of PUBLISH if UA doesnot support publish it
> can still claim 3261 compliance via tables only. Single table req is
> not good. By the same token we might need SINGLE place for headers in
> textual description. With c,m, m*, o, t labels it is much easier for
> parsers. Let TU developers worry about the context/usage. This needs
> updation when it widens/narrows. Text only version will cause lengthy
> discussions referring lines etc for message rejection. We can say
> table with associated section is normative for parsing. TU usage refer
> other sections. Regards Samir

I've tried to parse the above, and I just can't figure out what you are
proposing.

Can you please try again to state how you think these rules should be
documented?

Thanks,
Paul

> On 8/5/11, Paul Kyzivat<***@alum.mit.edu> wrote:
>> On 8/5/11 12:15 AM, Samir Srivastava wrote:
>>> Hi, IMHO presentation of information in tabulated form helps a lot to
>>> starters. Like ABNF it helps parser developers (expert of syntax&
>>> semantic analysis) to develop it without referring each line of SIP
>>> rfc's. 3262 or 100rel should have updated table Ideally each
>>> subsequent RFC should conisder table updation. Tabulation of
>>> information will be done by vendors internally anyway. So do it in
>>> community. SIP needed hitchakers guide. Simplicity for starters
>>> please. Regards Samir
>>
>> That was the concept that led to the table in the first place.
>> But history has shown this not to work very well in practice, for a
>> number of reasons. Here are some:
>>
>> - it proved impossible to define a table format that expressed
>> all the nuances. There still had to be text to explain the
>> complex cases. People tended to believe the table even though
>> its flagged as having exceptions
>>
>> - extensions to sip require updates to the table. But the extensions
>> are done in separate RFCs, not revisions to 3261. So they tended
>> to specify new rows to the table. These never get rolled up in
>> one place. Also, extensions that add methods add columns to the
>> table. When that happens, then you need to specify the values
>> for the new columns, for rows in 3261 and also in all extensions
>> that added rows. This is difficult, and was rarely if ever done
>> right.
>>
>> - given both a table and text descriptions of what is required,
>> it was unclear which is the authoritative normative specification.
>>
>> (I'm certain there are more reasons.)
>>
>> To be workable we would probably need to move the entire table to an
>> IANA registry. That also seemed unworkable.
>>
>> And with text descriptions it is easier to specify the requirements in
>> ways that will apply to most headers and methods that might be defined
>> in the future.
>>
>> The bottom line is that we ultimately decided that the table was a bad
>> idea and we didn't want to continue maintaining it.
>>
>> Thanks,
>> Paul
>>
>>> On 8/4/11, Romel Khan<***@idt.net> wrote:
>>>> So it is useful if one of UAS or UAC requires it, but it does not have to
>>>> be
>>>> mandatory. Some comments:
>>>> -- RFC3261 mentions early dialog without mentioning RFC3262. Then it
>>>> seems
>>>> logical to me that it needs to be made clear in this RFC3261 that early
>>>> dialog must mean Contact and Record-Route (if Record-Route was received
>>>> in
>>>> INVITE) headers is mandatory in 1xx without reference to 100rel.
>>>>
>>>> -- A UAS could always send 1xx with headers that are required for early
>>>> dialog but it doesn't have to enforce 100rel (eg because the origination
>>>> or
>>>> UAS side itself may not support reliable provisional response handling,
>>>> or
>>>> reliable provisioning not really required for its operation). UAS could
>>>> send
>>>> "support:100rel" if it supports it, or it would not send it if it doesn't
>>>> support this. In my opinion, if UAC hasn't sent 100rel required, it
>>>> should
>>>> be up to the UAS to decide whether to enforce 100rel
>>>> (with "required:100rel") if its application really requires SIP requests
>>>> before call answer. If the origination side (UAC) side has a need to send
>>>> early requests, like UPDATE, then the UAC should require 100rel from the
>>>> termination side (UAS) by sending this in INVITE. In a VoIP service
>>>> provider
>>>> world, these kind of capabilities are configured during interconnect turn
>>>> up.
>>>>
>>>> -- I notice that some vendors gateway implementations, even if gateway is
>>>> the termination side, require 100rel for the gateway to receive
>>>> pre-answer
>>>> requests such as UPDATE. This really didn't have to be this way. I have
>>>> always seen these gateways, when it is the termination side, respond back
>>>> SIP 183 with the headers that create early dialog. So if the origination
>>>> side received the SIP 183 response, then there is no reason for the
>>>> origination side to now not be able to send UPDATE request. Also, no
>>>> reason for the termination gateways to not accept the SIP UPDATE without
>>>> requiring PRACK.
>>>>
>>>> Thanks.
>>>>
>>>> On Wed, Aug 3, 2011 at 11:46 AM, Robert Sparks<***@nostrum.com>
>>>> wrote:
>>>>
>>>>> (removing the rfc-editor and trimming the distribution to the lists)
>>>>>
>>>>> On Aug 2, 2011, at 5:24 PM, Iñaki Baz Castillo wrote:
>>>>>
>>>>>> 2011/8/2 Robert Sparks<***@nostrum.com>:
>>>>>>> Further, they're only going to make sense for 1xx that is sent using
>>>>> 100rel.
>>>>>>
>>>>>> This has been discussed in sip-implementors, and that assertion seems
>>>>>> incorrect. As I've reported in the errata:
>>>>>>
>>>>>>
>>>>>> Section 12.1: "Dialogs are created through the generation of
>>>>>> non-failure responses to requests with specific methods. Within this
>>>>>> specification, only 2xx and 101-199 responses with a To tag, where the
>>>>>> request was INVITE, will establish a dialog."
>>>>>>
>>>>>> Section 12.1.1: "When a UAS responds to a request with a response that
>>>>>> establishes a dialog (such as a 2xx to INVITE), the UAS MUST copy all
>>>>>> Record-Route header field values from the request into the response
>>>>>> [...]. The UAS MUST add a Contact header field to the response."
>>>>>>
>>>>>> So it's clear that a 1xx response to an INVITE creates a dialog and
>>>>>> then it MUST contain a Contact header and mirrored Record-Route
>>>>>> headers, *regardless* the usage of 100rel.
>>>>>>
>>>>>> Am I wrong? if so, why?
>>>>>
>>>>> Not wrong, just incomplete. This will create an (early) dialog at the
>>>>> UAS.
>>>>> It may or may not create a dialog at the UAC without 100rel since the
>>>>> message may never get to the UAC. Where I said "make sense" above,
>>>>> it might have been better if I had said "be useful".
>>>>>
>>>>>>
>>>>>> Regards.
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Iñaki Baz Castillo
>>>>>> <***@aliax.net>
>>>>>> _______________________________________________
>>>>>> sipcore mailing list
>>>>>> ***@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/sipcore
>>>>>
>>>>> _______________________________________________
>>>>> Sip mailing list https://www.ietf.org/mailman/listinfo/sip
>>>>> This list is essentially closed and only used for finishing old
>>>>> business.
>>>>> Use sip-***@cs.columbia.edu for questions on how to develop a
>>>>> SIP
>>>>> implementation.
>>>>> Use ***@ietf.org for new developments on the application of sip.
>>>>> Use ***@ietf.org for issues related to maintenance of the core SIP
>>>>> specifications.
>>>>>
>>>>
>>> _______________________________________________
>>> Sip mailing list https://www.ietf.org/mailman/listinfo/sip
>>> This list is essentially closed and only used for finishing old business.
>>> Use sip-***@cs.columbia.edu for questions on how to develop a SIP
>>> implementation.
>>> Use ***@ietf.org for new developments on the application of sip.
>>> Use ***@ietf.org for issues related to maintenance of the core SIP
>>> specifications.
>>>
>>
>> _______________________________________________
>> Sip mailing list https://www.ietf.org/mailman/listinfo/sip
>> This list is essentially closed and only used for finishing old business.
>> Use sip-***@cs.columbia.edu for questions on how to develop a SIP
>> implementation.
>> Use ***@ietf.org for new developments on the application of sip.
>> Use ***@ietf.org for issues related to maintenance of the core SIP
>> specifications.
>>
>

_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core SIP specifications.

[Worley, Dale R (Dale)]

> From: Samir Srivastava [***@gmail.com]
>
> Hi, IMHO presentation of information in tabulated form helps a lot to
> starters. Like ABNF it helps parser developers (expert of syntax &
> semantic analysis) to develop it without referring each line of SIP
> rfc's.

The tables are a useful guide to starters. But as others have noted,
it is very difficult to keep the tables up to date, and there is no
format for the tables that correctly presents the conditions for
all "optional" headers.

Parser developers may be tempted to use the tables to determine
whether a message has all the required headers, but it is nearly
impossible to make that determination other than while carrying out
the processing for the message.

The real rule for the presence of headers is: "Perform the processing
that is mandated by the SIP message. Headers whose values are
required to perform this processing must be present; headers whose
values are not used in the processing are ignored. If a needed header
is not present, the processing of the message is aborted and it has no
effect. If the message is a request, an appropriate error response is
sent (if enough information is present in the request to allow doing
so)."

Dale
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core SIP specifications.

[Iñaki Baz Castillo]

El 04/08/2011 21:09, "Romel Khan" <***@idt.net> escribió:
>
> So it is useful if one of UAS or UAC requires it, but it does not have to
be mandatory. Some comments:
> -- RFC3261 mentions early dialog without mentioning RFC3262. Then it seems
logical to me that it needs to be made clear in this RFC3261 that early
dialog must mean Contact and Record-Route (if Record-Route was received in
INVITE) headers is mandatory in 1xx without reference to 100rel.
>
> -- A UAS could always send 1xx with headers that are required for early
dialog but it doesn't have to enforce 100rel (eg because the origination or
UAS side itself may not support reliable provisional response handling, or
reliable provisioning not really required for its operation). UAS could send
"support:100rel" if it supports it, or it would not send it if it doesn't
support this. In my opinion, if UAC hasn't sent 100rel required, it should
be up to the UAS to decide whether to enforce 100rel
(with "required:100rel") if its application really requires SIP requests
before call answer. If the origination side (UAC) side has a need to send
early requests, like UPDATE, then the UAC should require 100rel from the
termination side (UAS) by sending this yin INVITE. In a VoIP service
provider world, these kind of capabilities are configured during
interconnect turn up.
>
> -- I notice that some vendors gateway implementations, even if gateway is
the termination side, require 100rel for the gateway to receive pre-answer
requests such as UPDATE. This really didn't have to be this way. I have
always seen these gateways, when it is the termination side, respond back
SIP 183 with the headers that create early dialog. So if the origination
side received the SIP 183 response, then there is no reason for the
origination side to now not be able to send UPDATE request. Also, no
reason for the termination gateways to not accept the SIP UPDATE without
requiring PRACK.

I entirely agree with it. And I also think that the fact that a 1xx response
without 100rel is not reliable does not mean that it does not create a
dialog so Contact and RR are required.

[Romel Khan]

So it is useful if one of UAS or UAC requires it, but it does not have to be
mandatory. Some comments:
-- RFC3261 mentions early dialog without mentioning RFC3262. Then it seems
logical to me that it needs to be made clear in this RFC3261 that early
dialog must mean Contact and Record-Route (if Record-Route was received in
INVITE) headers is mandatory in 1xx without reference to 100rel.

-- A UAS could always send 1xx with headers that are required for early
dialog but it doesn't have to enforce 100rel (eg because the origination or
UAS side itself may not support reliable provisional response handling, or
reliable provisioning not really required for its operation). UAS could send
"support:100rel" if it supports it, or it would not send it if it doesn't
support this. In my opinion, if UAC hasn't sent 100rel required, it should
be up to the UAS to decide whether to enforce 100rel
(with "required:100rel") if its application really requires SIP requests
before call answer. If the origination side (UAC) side has a need to send
early requests, like UPDATE, then the UAC should require 100rel from the
termination side (UAS) by sending this in INVITE. In a VoIP service provider
world, these kind of capabilities are configured during interconnect turn
up.

-- I notice that some vendors gateway implementations, even if gateway is
the termination side, require 100rel for the gateway to receive pre-answer
requests such as UPDATE. This really didn't have to be this way. I have
always seen these gateways, when it is the termination side, respond back
SIP 183 with the headers that create early dialog. So if the origination
side received the SIP 183 response, then there is no reason for the
origination side to now not be able to send UPDATE request. Also, no
reason for the termination gateways to not accept the SIP UPDATE without
requiring PRACK.

Thanks.

On Wed, Aug 3, 2011 at 11:46 AM, Robert Sparks <***@nostrum.com> wrote:

> (removing the rfc-editor and trimming the distribution to the lists)
>
> On Aug 2, 2011, at 5:24 PM, Iñaki Baz Castillo wrote:
>
> > 2011/8/2 Robert Sparks <***@nostrum.com>:
> >> Further, they're only going to make sense for 1xx that is sent using
> 100rel.
> >
> > This has been discussed in sip-implementors, and that assertion seems
> > incorrect. As I've reported in the errata:
> >
> >
> > Section 12.1: "Dialogs are created through the generation of
> > non-failure responses to requests with specific methods. Within this
> > specification, only 2xx and 101-199 responses with a To tag, where the
> > request was INVITE, will establish a dialog."
> >
> > Section 12.1.1: "When a UAS responds to a request with a response that
> > establishes a dialog (such as a 2xx to INVITE), the UAS MUST copy all
> > Record-Route header field values from the request into the response
> > [...]. The UAS MUST add a Contact header field to the response."
> >
> > So it's clear that a 1xx response to an INVITE creates a dialog and
> > then it MUST contain a Contact header and mirrored Record-Route
> > headers, *regardless* the usage of 100rel.
> >
> > Am I wrong? if so, why?
>
> Not wrong, just incomplete. This will create an (early) dialog at the UAS.
> It may or may not create a dialog at the UAC without 100rel since the
> message may never get to the UAC. Where I said "make sense" above,
> it might have been better if I had said "be useful".
>
> >
> > Regards.
> >
> >
> > --
> > Iñaki Baz Castillo
> > <***@aliax.net>
> > _______________________________________________
> > sipcore mailing list
> > ***@ietf.org
> > https://www.ietf.org/mailman/listinfo/sipcore
>
> _______________________________________________
> Sip mailing list https://www.ietf.org/mailman/listinfo/sip
> This list is essentially closed and only used for finishing old business.
> Use sip-***@cs.columbia.edu for questions on how to develop a SIP
> implementation.
> Use ***@ietf.org for new developments on the application of sip.
> Use ***@ietf.org for issues related to maintenance of the core SIP
> specifications.
>