Brett,
Yes, 3261 has all those MUSTs in it. But it was there for 2543
compatibility. AFAIK there is nothing that calls for checking that the
URIs remain unchanged as a requirement for recognizing that the request
is an in-dialog request.
So I think it might be within the letter of the law to reject the
request with a 400 because it isn't valid. But absent that I would
expect it to accept the request. Returning 481 is IMO wrong.
Of course it could pretend to be only 2543 compliant. But then, IIRC, it
should not have returned a to-tag during dialog establishment.
So I think both the proxy and the gw are behaving improperly.
Thanks,
Paul
Brett Tate wrote:
> RFC 3261 does not allow the To/From uri matching values to change within a
> dialog. RFC 4916 provides the ability to alter To/From uri matching values;
> however it requires the support/use of option-tag “from-change”. Except per
> RFC 4916, I’m not aware of an RFC which has officially deprecated the To/From
> rules mandated by RFC 3261 section 12.2.1.1.
>
> RFC 3261 section 12.2.1.1:
>
> "A request within a dialog is constructed by using many of the
> components of the state stored as part of the dialog.
>
> 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."
>
>
>
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
