[Serusers] Re: sequential forking / t_on_failure

[Jiri Kuthan]

At 10:26 PM 6/2/2004, 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.

In terms of RFC3261, it routes by r-uri, unless the next hop is driven
by Route header field.


>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.


In RFC3261, use of Contacts is mandatory. That's not the case in RFC2543 
which was a bug.

-jiri