Hi, The basic answer is yes. However if the URI's changed without using the RFC 4916 mechanism, the request (or response) would be malformed. RFC 3261 prepared things for RFC 4916 (and maybe another alternative within the future). It also ensured that the URI's would not be needed within headers such as Replaces (RFC 3891).
Excluding the usage of RFC 4916, a lenient device would need to decide how to behave if accepting the malformed request/response. More specifically, it would need to decide if better to ignore the To/From URI modification or accept the modification. For instance if the sender changed the remote user's identity to something incorrect, should the remote user start using the incorrect identity within the From of subsequent requests that it sends? Similarly if the sender changed its identity, should the remote user start using the changed identity within the To of subsequent requests that it sends; and if so, should it only allow certain requests to cause the change (similar to RFC 4916)? > -----Original Message----- > From: isshed [mailto:[email protected]] > Sent: Thursday, April 24, 2014 1:30 AM > To: Brett Tate > Cc: sip-implementors > Subject: Re: [Sip-implementors] Dialog matching > > Hi Brett, > > RFC 3261 section 12.2.1.1 also 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, 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. > > Does that mean while matching dialog, URIs of FROM and TO tag should > not be considered? > > Thanks. > > On Wed, Apr 23, 2014 at 5:10 PM, isshed <[email protected]> wrote: > > Thanks Brett!! > > > > On Wed, Apr 23, 2014 at 4:26 PM, Brett Tate <[email protected]> > wrote: > >>> Tags are all same i made a typo only the URI in > >>> the ACK is changed. > >> > >> Hi, > >> > >> My response concerning malformed messages still applies. The ACK is > >> malformed (from a RFC 3261 and RFC 4916 perspective); thus the > device can > >> basically handle it however it wants. However since it is an ACK, a > 400 > >> response obviously cannot be returned. > >> > >> RFC 3261 section 12.2: > >> > >> "The URI in the To field of the request MUST be set to the remote > URI > >> from the dialog state. The tag in the To header field of the > request > >> MUST be set to the remote tag of the dialog ID. The From URI of > the > >> request MUST be set to the local URI from the dialog state. The > tag > >> in the From header field of the request MUST be set to the local > tag > >> of the dialog ID." > >> > >> -- > >> > >> This email is intended solely for the person or entity to which it > is > >> addressed and may contain confidential and/or privileged > information. If > >> you are not the intended recipient and have received this email in > error, > >> please notify BroadSoft, Inc. immediately by replying to this > message, and > >> destroy all copies of this message, along with any attachment, prior > to > >> reading, distributing or copying it. -- This email is intended solely for the person or entity to which it is addressed and may contain confidential and/or privileged information. If you are not the intended recipient and have received this email in error, please notify BroadSoft, Inc. immediately by replying to this message, and destroy all copies of this message, along with any attachment, prior to reading, distributing or copying it. _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
