--On 02 June 2004 22:32 +0200 Nils Ohlmeier <[EMAIL PROTECTED]> wrote:
So even if the proxy does record-route the Contact headers of the UAs
will ensure that further in-dialog requests will be delivered to the
right UA. Explaining the relation between the Route and the Contact
header is a little bit long. Please refer to the Record-Route and Route
sections of RFC3261 for the details.
So in essence I think what you are saying is:
a) The UAS MUST add a Contact: header to the reply to the INVITE as it
is establishing a dialog
b) The remote target in the Route: must be the Contact: field specified
in the header (per 12.1.1):
The remote target MUST be set to the URI from the Contact
header field of the request.
c) The Request-URI from Route: MUST be used by the proxy for the subsequent
in-dialog transaction because (per 12.2.1.1):
If the route set is not empty, and the first URI in the route set
contains the lr parameter (see Section 19.1.1), the UAC MUST place
the remote target URI into the Request-URI and MUST include a Route
header field containing the route set values in order, including
all parameters.
If the route set is not empty, and its first URI does not contain
the lr parameter, the UAC MUST place the first URI from the route
set into the Request-URI, stripping any parameters that are not
allowed in a Request-URI. The UAC MUST add a Route header field
containing the remainder of the route set values in order,
including all parameters. The UAC MUST then place the remote
target URI into the Route header field as the last value.
The bit that got me confused was 12.1.1:
The Contact header field contains an address where the
UAS would like to be contacted for subsequent requests in the dialog
which seems to imply a degree of optionality ("would like to be")
as to whether the UAC contacts the UAS at the address in the
Contact: header provided or using the original Request-URI.
But I can rely on this working no matter how obnoxious the UAC and
UAS (i.e. A and C are) provided they are compliant?
Alex
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
