yes, it was for backward compatibility with 2543. Yes it would be nice
to be able to change, and that has started to be put in place more
recently, with RFC 4916. It uses a new option tag 'from-change' to
condition this behavior, so backward compatibility is preserved.
Paul
Raj Jain wrote:
> Correct. I didn't realize that there were these MUST clauses in
> section 8.2.6.2. It's interesting because the From/To URIs and display
> names don't contribute to dialog matching, so in theory why can't they
> be altered in a response? Was this done for backward compatbility with
> RFC 2543?
>
> It's actually kind of a nice feature if one could update the To URI
> and display name in a response. For instance, you send a call into a
> PBX where one of many users can answer it. The 200 OK then carries
> back the connected party's identity to the caller. In reality, no one
> seems to have implemented RFC 4916 (from what I can tell from the last
> SIPit). And thus people are sticking in either Remote-Party-Id or
> P-A-I in the 200 OK today to acheive the same goal. This also saves
> you an UPDATE/RE-INVITE round-trip right after answer that you would
> need in RFC 4916.
>
> --
> Raj Jain
>
>
> On Mon, Jun 2, 2008 at 8:59 AM, Brett Tate <[EMAIL PROTECTED]> wrote:
>> See rfc3261 8.2.6.2 concerning From, To, Call-ID, Via, and CSeq. A UAS
>> device not following rfc3261 8.2.6.2 is not compliant and likely not
>> very interoperable. Some aspects of section 8.2.6.2 might be deprecated
>> in the future; however it still has not been. Since the device is non
>> compliant, you can basically act however you wish.
>>
>> RFC 4916 provides a mechanism (using option tag "from-change") to
>> partially deprecate the uri matching rules within a dialog. However it
>> still doesn't allow them to change within responses.
>>
>>
>>> -----Original Message-----
>>> From: [EMAIL PROTECTED]
>>> [mailto:[EMAIL PROTECTED] On
>>> Behalf Of Raj Jain
>>> Sent: Monday, June 02, 2008 6:56 AM
>>> To: Sree
>>> Cc: Sip-Implementors
>>> Subject: Re: [Sip-implementors] Question on matching response
>>> to atransaction
>>>
>>> On Mon, Jun 2, 2008 at 4:50 AM, Sree <[EMAIL PROTECTED]> wrote:
>>>> In such a scenario, what is the action to be taken on Response that
>>>> contain the Via branch and Cseq method identical to the
>>> Request that
>>>> created the transaction, but differs in either/all of the
>>> following headers:
>>>
>>>> From: [differs in from-URI only]
>>> A proper RFC 3261 compliant implementation (that matches
>>> dialogs based on from-tag, to-tag, and Call-ID fields only)
>>> should treat this as a valid response.
>>>
>>>> From: [differs in from-tag]
>>> This response will fail dialog matching and will thus be ignored.
>>>
>>>> To: [differs in to-URI only]
>>> This is a valid response.
>>>
>>>> To: [differs in to-tag]
>>> This means that the request was forked and the response has
>>> been sent by a different UAS.
>>>
>>>> Call-ID:
>>> This response will fail dialog matching and will thus be ignored.
>> _______________________________________________
>> 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
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
