Alex Bligh wrote:
Nils / Klaus,
--On 02 June 2004 20:08 +0200 Nils Ohlmeier nils@iptel.org wrote:
On Wednesday 02 June 2004 20:03, Alex Bligh wrote:
--On 02 June 2004 18:38 +0100 Alex Bligh alex@alex.org.uk wrote:
Consider the situation whereby after an INVITE occurs which ser initially routes to A (which is, say, busy) and subsequently routes to B. Perhaps it has gone through t_on_failure or some other mechanism of sequential forking. Assume the INVITE has been OK'd and ACK'd.
What mechanism does ser use to ensure subsequent transactions on the call-leg (such as BYE, re-INVITE etc.) are sent to B and not A? IE where is the state being stored and how?
I am obviously assuming (transaction) stateful forwarding and that record_route is on (else the proxy wouldn't even get to see BYE etc.)
Nils said:
In this case the Route header resulting out of the Record-Route header includes all informations required to route any subsequent in-dialog request to it's destination. So any re-INVITE or BYE can be routed stateless to its destination.
Klaus said:
This is done in outside the proxy - for in-dialog requests, the request URI contains the "contact" of the other party (or the Route header for strict routers (old SIP RFC))
This implies ser is looking either at the parameters in the Record-Route: header added by ser on the INVITE (which is what Nils seems to suggest) OR relies on the initiating UA using as a Request-URI for subsequent in-dialog messages the Contact: header added by the UA providing the OK response to INVITE.
I think it's probably the latter that's happening. But can I rely on this? IE Is it mandatory for the subsequent in-dialog transactions to use the Contact: address supplied by the UAS, and is it mandatory for the UAS to add a Contact: header at all? I'm reading the call flow example on p167 of "SIP: Understanding the Session Initiation Protocol" and it doesn't seem to be there. What's concerning me is that I can see it works, but I can't tell why or if it will always work. I am probably being very dumb.
you have to distinguish between loose router (new RFC) and strict routers. For both, a dialog creating response typically (not always mandatory) includes the Contact: header.
- loose routers: the Contact:-URI is in the request URI and the Route: header indicates the intermediate SIP proxies.
- strict_routers: the next hop is in the request URI and the Contact:-Uri is in the last Route: header
Anyway, the information to route the message to the proper UA is available.
Klaus