2 Jun
2004
2 Jun
'04
8:38 p.m.
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?
Alex
2 Jun
2 Jun
8:43 p.m.
Hi Alex!
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))
regards,
klaus
Alex Bligh 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?
Alex
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
9:03 p.m.
New subject: [Serusers] Re: sequential forking / t_on_failure
--On 02 June 2004 18:38 +0100 Alex Bligh <alex(a)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.)
Alex
9:08 p.m.
New subject: [Serusers] Re: sequential forking / t_on_failure
On Wednesday 02 June 2004 20:03, Alex Bligh wrote:
--On 02 June 2004 18:38 +0100 Alex Bligh
<alex(a)alex.org.uk> wrote:
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.
Greetings
Nils
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.)
11:26 p.m.
New subject: [Serusers] Re: sequential forking / t_on_failure
Nils / Klaus,
--On 02 June 2004 20:08 +0200 Nils Ohlmeier <nils(a)iptel.org> wrote:
On Wednesday 02 June 2004 20:03, Alex Bligh wrote:
> --On 02 June 2004 18:38 +0100 Alex Bligh <alex(a)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
11:44 p.m.
New subject: [Serusers] Re: sequential forking / t_on_failure
Hi Alex,
On Wednesday 02 June 2004 22:26, Alex Bligh wrote:
Nils / Klaus,
--On 02 June 2004 20:08 +0200 Nils Ohlmeier <nils(a)iptel.org> wrote:
As I allready explained on SIP-Implemetors: the Contact header is mandatory
for requests and replies which can establish a dialog. If your book does not
mention this or even do not explain the simple scenario how further in-dialog
requests (re-INVITE, BYE's etc.) are delivered to the target, i would suggest
to throw it away and read the RFC instead ;-)
The Contact from the remote side will be used in future requests as final
target. In case of loose-routing as request URI, in case of strict routing as
last hop in the Route header. That is the reason why the Contact header is
mandatory in INVITE and 200 OK (for the INVITE). (That is the reason why i
said in the Route header is everything included.)
So the proxy will never rely on parameters in the Record-Route/Route header.
If you are looking at some real world traces, search for the remote side
Contact URI in the BYE message. You will for sure find it somewhere.
Greetings
Nils
On Wednesday 02 June 2004 20:03, Alex Bligh
wrote:
> --On 02 June 2004 18:38 +0100 Alex Bligh <alex(a)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.
3 Jun
3 Jun
1:31 a.m.
New subject: [Serusers] Re: sequential forking / t_on_failure
Alex Bligh wrote:
Nils / Klaus,
--On 02 June 2004 20:08 +0200 Nils Ohlmeier <nils(a)iptel.org> wrote:
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
On Wednesday 02 June 2004 20:03, Alex Bligh
wrote:
> --On 02 June 2004 18:38 +0100 Alex Bligh <alex(a)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. 
2:15 a.m.
New subject: [Serusers] Re: sequential forking / t_on_failure
At 10:26 PM 6/2/2004, Alex Bligh wrote:
Nils / Klaus,
--On 02 June 2004 20:08 +0200 Nils Ohlmeier <nils(a)iptel.org> wrote:
In terms of RFC3261, it routes by r-uri, unless the next hop is driven
by Route header field.
On Wednesday 02 June 2004 20:03, Alex Bligh
wrote:
>--On 02 June 2004 18:38 +0100 Alex Bligh <alex(a)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.
In RFC3261, use of Contacts is mandatory. That's not the case in RFC2543
which was a bug.
-jiri
10:30 a.m.
New subject: [Serusers] Re: sequential forking / t_on_failure
--On 03 June 2004 01:15 +0200 Jiri Kuthan <jiri(a)iptel.org> wrote:
In RFC3261, use of Contacts is mandatory. That's
not the case in RFC2543
which was a bug.
Ah! the final part of the jigsaw. The SIP book (written by an RFC author)
seems to predate RFC3261 (at least in parts). Thanks. Now all sorted
I think.
Alex
7507
days inactive
7508
days old
8 comments
4 participants
participants (4)
-
Alex Bligh -
Jiri Kuthan -
Klaus Darilion -
Nils Ohlmeier