[Serusers] Re: sequential forking / t_on_failure

[Alex Bligh]

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.

Alex