responses inline...

>>>A client sends a REGISTER message to a SIP Proxy, which changes the
>>>Contact: header to itself, but leaves the From: intact. The message
is
>>>then forwarded to the REGISTAR. Some questions:
>>>
>>>*Is this enough to guarantee that inbound messages will be directed
to
>>>such Proxy? Assuming of course the Registar is queried by other
Proxies?
The proxy MUST NOT change the Contact header. If you want to achieve
this
functionallity, the Proxy should insert a Path: header field when
relaying the 
REGISTER request to the registrar. Read carefully RFC 3327 to see the
exact mechanism.


>>>* Is it guaranteed that the 200OK for the REGISTER will go through
the
>>>Proxy? Given that Record-Route is not processed in REGISTER messages
I
>>>got the impression that the REGISTAR could (at least theoretically)
send
>>>the 200OK message directly to the endpoint
Responses are routed back following the reverse path included in the
Via: headers
present in the incoming request. Therefore, the 200 OK response will
travel back the 
Via: headers and one of them will be the proxy.


>>>Does this Proxy registration mechanism have any implication in
REGISTER
>>>call flows where authentication is used? 
If you do not change the Contact: header field value (totally against
RFC 3261) there will be no
alteration in the registration process.

>>>>I looked at RFC3327 but it seems in that case the Contact: header
isn't
>>>>changed. Besides it seems to assume that DNS is not used.
As I have previously explained, proxies does not modify Contact: but
only add Path: header.
Why you think that there is such an assumption for not using DNS????

>>>>Finally, how widespread is RFC3327?
As far as I know it has been introduced as a requirement from the 3GPP
and therefore
it will be mainly be implemented in proxies and registrars building
3GPP systems. For the
rest of SIP roles it is not much spread and who knows wether it will be
implemented or not...



Hope it helps,

Samuel.



Unclassified.
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Reply via email to