[Serusers] Re: sequential forking / t_on_failure

[Klaus Darilion]

Alex Bligh wrote:

> Nils / Klaus,
> 
> --On 02 June 2004 20:08 +0200 Nils Ohlmeier <nils at iptel.org> wrote:
> 
>> On Wednesday 02 June 2004 20:03, Alex Bligh wrote:
>>
>>> --On 02 June 2004 18:38 +0100 Alex Bligh <alex at 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