Good Subject,
Looking into RFC-2543 the appropriate section to refer our issue would
be the below ones 11.2 and 11.4
11.2 Callee Issues Response
.....
The UAS stores the values of the To and From field, including any
tags. These become the local and remote addresses of the call leg,
respectively.
11.4 Caller or Callee Generate Subsequent Requests
Once the call has been established, either the caller or callee MAY
generate INVITE or BYE requests to change or terminate the call.
Regardless of whether the caller or callee is generating the new
request, the header fields in the request are set as follows. For the
desired call leg, the To header field is set to the remote address,
and the From header field is set to the local address (both including
any tags).
The reason I was curious about this is because of a newer RFC-4916 which
allows changing the URI (not the tags) in the To and
>From header fields of mid-dialog requests and it introduces a new
supported header tag named "from-change" and these newer RFCs are
deprecating those mandatory requirements of RFC-3261 as shown below
This solution involves changing the URI (not the tags) in the To and
From header fields of mid-dialog requests and their responses,
compared with the corresponding values in the dialog forming request
and response. Changing the To and From header field URIs was
contemplated in Section 12.2.1.1 of RFC 3261 [1], which says:
"Usage of the URI from the To and From fields in the original
request within subsequent requests is done for backwards
compatibility with RFC 2543 [6], which used the URI for dialog
identification. In this specification, only the tags are used for
dialog identification. It is expected that mandatory reflection
of the original To and From URI in mid-dialog requests will be
deprecated in a subsequent revision of this specification."
This document therefore deprecates mandatory reflection of the
original To and From URIs in mid-dialog requests and their responses,
which constitutes a change to RFC 3261 [1]. This document makes no
provision for proxies that are unable to tolerate a change of URI,
since changing the URI has been expected for a considerable time. To
cater for any UAs that are not able to tolerate a change of URI, a
new option tag "from-change" is introduced for providing a positive
indication of support in the Supported header field. By sending a
request with a changed From header field URI only to targets that
have indicated support for this option, there is no need to send this
option tag in a Require header field.
So I guess the newer RFCs are suggesting that we should relex the
backward compatibility rules going forward to be able to provide newer
capabilities like the one provided by implementing this RFC :)
Best Regards,
Indresh K Singh
>>-----Original Message-----
>>From: [email protected]
>>[mailto:[email protected]] On
>>Behalf Of ext Roman Shpount
>>Sent: Friday, February 19, 2010 3:39 PM
>>To: Paul Kyzivat
>>Cc: [email protected]
>>Subject: Re: [Sip-implementors] Query - are *header*
>>parameters (other thantag) of From and To part of dialog state?
>>
>>The same section says that complete To and From fields
>>including any tags
>>are stored as remote and local address. Subsequent requests
>>in dialog should
>>set their To and From headers to remote and local addresses, which are
>>complete To and From headers. This is done to be compatible
>>with RFC 2543,
>>where request would only match the dialog if complete To,
>>From and Call-ID
>>match.
>>
>>____________________________
>>Roman Shpount www.telurix.com
>>
>>On Fri, Feb 19, 2010 at 3:22 PM, Paul Kyzivat
>><[email protected]> wrote:
>>
>>>
>>>
>>> Roman Shpount wrote:
>>>
>>>> From/To header should be preserved completely with all of
>>its parameters
>>>> to be compatible with RFC 2543. RFC 3261 Section 11.2
>>Callee Issues Response
>>>> says that "The response MUST copy the To, From, Call-ID,
>>CSeq and Via fields
>>>> from the request." This implies that complete header,
>>including all the
>>>> header parameters are copied. The RFC 3261 should still
>>match the request
>>>> based on To and From tags. Older, RFC 2543 based user
>>agents, will only
>>>> match request to dialog if complete To and From headers
>>are preserved.
>>>>
>>>
>>> That is pertinent to the *response* to the request.
>>>
>>> The question is about subsequent requests within the dialog.
>>>
>>> Thanks,
>>> Paul
>>>
>>_______________________________________________
>>Sip-implementors mailing list
>>[email protected]
>>https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
