19 Jun
2007
19 Jun
'07
7:55 p.m.
Hi all,
When SER receives an INVITE with a single Route header pointing to
itself, it's supposed to delete it and process the message as if no
Route header was there in the first place. This is what RFC3261
mandates, right?
But currently the loose_route function returns true to the script in
this case, just like when more Route headers are present.
So I have some routing logic for when no Route headers are present,
and if I want to apply the same routing logic to the case when there
is a single Route header pointing to myself (naturally, as it's the
same as if no Route header was present), I currently have to replicate
the same routing logic inside the if (loose_route())...
Or is there an other way? Do I have to develop my own module function
or use some regexp search from the script to detect if there are more
Routes besides myself before I call loose_route?
The best would be to change loose_route to return false and just
remove the Route header pointing to myself when there are no more
Route headers in the message... what do you think?
JF
20 Jun
20 Jun
12:08 p.m.
New subject: [Serusers] loose_route behaviour, detecting single Route with myself
Hi,
in SER 2.x you can use rr module's parameter:
modparam("rr", "next_route_avp", "next_route");
and then check if that AVP is set. If it is, then there is another
destination you should forward the request. If it does not, then it was
targeted to your host, regardless of the loose_route call return value.
Michal
On Út, 2007-06-19 at 18:55 +0100, JF wrote:
Hi all,
When SER receives an INVITE with a single Route header pointing to
itself, it's supposed to delete it and process the message as if no
Route header was there in the first place. This is what RFC3261
mandates, right?
But currently the loose_route function returns true to the script in
this case, just like when more Route headers are present.
So I have some routing logic for when no Route headers are present,
and if I want to apply the same routing logic to the case when there
is a single Route header pointing to myself (naturally, as it's the
same as if no Route header was present), I currently have to replicate
the same routing logic inside the if (loose_route())...
Or is there an other way? Do I have to develop my own module function
or use some regexp search from the script to detect if there are more
Routes besides myself before I call loose_route?
The best would be to change loose_route to return false and just
remove the Route header pointing to myself when there are no more
Route headers in the message... what do you think?
JF
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
12:57 p.m.
New subject: [Serusers] [OpenIMSCore-CSCF] loose_route behaviour, detecting single Route with myself
Hi Joao,
You might also be interested in this thread:
http://lists.iptel.org/pipermail/serdev/2007-March/009517.html
-Dragos
JF wrote:
Hi all,
When SER receives an INVITE with a single Route header pointing to
itself, it's supposed to delete it and process the message as if no
Route header was there in the first place. This is what RFC3261
mandates, right?
But currently the loose_route function returns true to the script in
this case, just like when more Route headers are present.
So I have some routing logic for when no Route headers are present,
and if I want to apply the same routing logic to the case when there
is a single Route header pointing to myself (naturally, as it's the
same as if no Route header was present), I currently have to replicate
the same routing logic inside the if (loose_route())...
Or is there an other way? Do I have to develop my own module function
or use some regexp search from the script to detect if there are more
Routes besides myself before I call loose_route?
The best would be to change loose_route to return false and just
remove the Route header pointing to myself when there are no more
Route headers in the message... what do you think?
JF
_______________________________________________
OpenIMSCore-CSCF mailing list
OpenIMSCore-CSCF(a)lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openimscore-cscf
--
-----------------------------------------
Dipl. Eng. Dragos Vingarzan
Fraunhofer FOKUS/NGNI
Kaiserin-Augusta-Allee 31
10589 Berlin,Germany
Phone +49 (0)30 - 3463 - 7385
Mobile +49 (0)163 - 159 - 5221
Web www.fokus.fraunhofer.de www.openimscore.org
We could change the world if God would give us the source code...
-----------------------------------------------------------------
21 Jun
21 Jun
11:55 a.m.
If there's a single Route header pointing to itself, then this is a good
indication that a UA added a Route to your proxy as an outbound proxy.
If SER correctly identities the uri as itself, it should AFAIK return false.
Could you please turn on debugging and then look for loose_route and
after_loose debug messages in the logs and post them?
g-)
JF wrote:
Hi all,
When SER receives an INVITE with a single Route header pointing to
itself, it's supposed to delete it and process the message as if no
Route header was there in the first place. This is what RFC3261
mandates, right?
But currently the loose_route function returns true to the script in
this case, just like when more Route headers are present.
So I have some routing logic for when no Route headers are present,
and if I want to apply the same routing logic to the case when there
is a single Route header pointing to myself (naturally, as it's the
same as if no Route header was present), I currently have to replicate
the same routing logic inside the if (loose_route())...
Or is there an other way? Do I have to develop my own module function
or use some regexp search from the script to detect if there are more
Routes besides myself before I call loose_route?
The best would be to change loose_route to return false and just
remove the Route header pointing to myself when there are no more
Route headers in the message... what do you think?
JF
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
22 Jun
22 Jun
11:11 a.m.
New subject: [Serusers] loose_route behaviour, detecting single Route with myself
Thanks Greger,
The problem is related to the fact that the Req-URI is a tel-URI.
I had to work around it in the script by not letting loose_route get
called when the URI is a tel URI.
In loose.c, loose_route() says (by looking at the log):
DBG("loose_route: RURI is NOT myself\n");
because Req-URI doesn't have a host part.
Then after_loose(_m, &puri, 1, 0) is called because the single
existing Route header has our SIP URI.
And then:
DBG("after_loose: Topmost route URI: '%.*s' is me\n", uri->len,
ZSW(uri->s));
and
DBG("after_loose: No next URI found\n");
An since _ruri_myself == 0, return RR_DRIVEN;
IMO the fact that the Req-URI is a tel URI shouldn't make loose_route
return true in this case...
JF
On 6/21/07, Greger V. Teigre <greger(a)teigre.com> wrote:
If there's a single Route header pointing to
itself, then this is a good
indication that a UA added a Route to your proxy as an outbound proxy.
If SER correctly identities the uri as itself, it should AFAIK return false.
Could you please turn on debugging and then look for loose_route and
after_loose debug messages in the logs and post them?
g-)
JF wrote:
Hi all,
When SER receives an INVITE with a single Route header pointing to
itself, it's supposed to delete it and process the message as if no
Route header was there in the first place. This is what RFC3261
mandates, right?
But currently the loose_route function returns true to the script in
this case, just like when more Route headers are present.
So I have some routing logic for when no Route headers are present,
and if I want to apply the same routing logic to the case when there
is a single Route header pointing to myself (naturally, as it's the
same as if no Route header was present), I currently have to replicate
the same routing logic inside the if (loose_route())...
Or is there an other way? Do I have to develop my own module function
or use some regexp search from the script to detect if there are more
Routes besides myself before I call loose_route?
The best would be to change loose_route to return false and just
remove the Route header pointing to myself when there are no more
Route headers in the message... what do you think?
JF
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
12:37 p.m.
New subject: [Serusers] loose_route behaviour, detecting single Route with myself
This seems like a corner case where the tel uri with no domain results in maybe a bit
unfortunate return code from loose_route.
Comments anyone?
g-)
------- Original message -------
From: JF <jfkavaka(a)gmail.com>
Cc: serusers(a)iptel.org, openimscore-cscf(a)lists.berlios.de
Sent: 22.6.'07, 11:11
Thanks Greger,
The problem is related to the fact that the Req-URI is a tel-URI.
I had to work around it in the script by not letting loose_route get
called when the URI is a tel URI.
In loose.c, loose_route() says (by looking at the log):
DBG("loose_route: RURI is NOT myself\n");
because Req-URI doesn't have a host part.
Then after_loose(_m, &puri, 1, 0) is called because the single
existing Route header has our SIP URI.
And then:
DBG("after_loose: Topmost route URI: '%.*s' is me\n", uri->len,
ZSW(uri->s));
and
DBG("after_loose: No next URI found\n");
An since _ruri_myself == 0, return RR_DRIVEN;
IMO the fact that the Req-URI is a tel URI shouldn't make loose_route
return true in this case...
JF
On 6/21/07, Greger V. Teigre <greger(a)teigre.com> wrote:
If there's a single Route header pointing to
itself, then this is a good
indication that a UA added a Route to your proxy as an outbound proxy.
If SER correctly identities the uri as itself, it should AFAIK return false.
Could you please turn on debugging and then look for loose_route and
after_loose debug messages in the logs and post them?
g-)
JF wrote:
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers Hi all,
When SER receives an INVITE with a single Route header pointing to
itself, it's supposed to delete it and process the message as if no
Route header was there in the first place. This is what RFC3261
mandates, right?
But currently the loose_route function returns true to the script in
this case, just like when more Route headers are present.
So I have some routing logic for when no Route headers are present,
and if I want to apply the same routing logic to the case when there
is a single Route header pointing to myself (naturally, as it's the
same as if no Route header was present), I currently have to replicate
the same routing logic inside the if (loose_route())...
Or is there an other way? Do I have to develop my own module function
or use some regexp search from the script to detect if there are more
Routes besides myself before I call loose_route?
The best would be to change loose_route to return false and just
remove the Route header pointing to myself when there are no more
Route headers in the message... what do you think?
JF
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
28 Jun
28 Jun
5:13 p.m.
New subject: [Serusers] loose_route behaviour, detecting single Route with myself
I would propose to simply apply this patch to modules/rr/loose.c:
@@ -1069,8 +1069,8 @@
return -1;
}
- if (is_myself(&_m->parsed_uri.host, _m->parsed_uri.port_no)
- || _m->parsed_uri.type==TEL_URI_T ||
_m->parsed_uri.type==TELS_URI_T) {
+ if (_m->parsed_uri.type==TEL_URI_T || _m->parsed_uri.type==TELS_URI_T ||
+ is_myself(&_m->parsed_uri.host,
_m->parsed_uri.port_no)) {
DBG("loose_route: RURI is myself (or tel URI)\n");
if ((ret = is_myself(&puri.host, puri.port_no)) == 1 &&
!(enable_double_rr && is_2rr(&puri.params))) {
JF
On 6/22/07, Greger Viken Teigre <greger(a)teigre.com> wrote:
This seems like a corner case where the tel uri with
no domain results in maybe a bit unfortunate return code from loose_route.
Comments anyone?
g-)
------- Original message -------
From: JF <jfkavaka(a)gmail.com>
Cc: serusers(a)iptel.org, openimscore-cscf(a)lists.berlios.de
Sent: 22.6.'07, 11:11
Thanks Greger,
The problem is related to the fact that the Req-URI is a tel-URI.
I had to work around it in the script by not letting loose_route get
called when the URI is a tel URI.
In loose.c, loose_route() says (by looking at the log):
DBG("loose_route: RURI is NOT myself\n");
because Req-URI doesn't have a host part.
Then after_loose(_m, &puri, 1, 0) is called because the single
existing Route header has our SIP URI.
And then:
DBG("after_loose: Topmost route URI: '%.*s' is me\n", uri->len,
ZSW(uri->s));
and
DBG("after_loose: No next URI found\n");
An since _ruri_myself == 0, return RR_DRIVEN;
IMO the fact that the Req-URI is a tel URI shouldn't make loose_route
return true in this case...
JF
On 6/21/07, Greger V. Teigre <greger(a)teigre.com> wrote:
If there's a single Route header pointing to
itself, then this is a good
indication that a UA added a Route to your proxy as an outbound proxy.
If SER correctly identities the uri as itself, it should AFAIK return false.
Could you please turn on debugging and then look for loose_route and
after_loose debug messages in the logs and post them?
g-)
JF wrote:
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers Hi all,
When SER receives an INVITE with a single Route header pointing to
itself, it's supposed to delete it and process the message as if no
Route header was there in the first place. This is what RFC3261
mandates, right?
But currently the loose_route function returns true to the script in
this case, just like when more Route headers are present.
So I have some routing logic for when no Route headers are present,
and if I want to apply the same routing logic to the case when there
is a single Route header pointing to myself (naturally, as it's the
same as if no Route header was present), I currently have to replicate
the same routing logic inside the if (loose_route())...
Or is there an other way? Do I have to develop my own module function
or use some regexp search from the script to detect if there are more
Routes besides myself before I call loose_route?
The best would be to change loose_route to return false and just
remove the Route header pointing to myself when there are no more
Route headers in the message... what do you think?
JF
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
10 Jul
10 Jul
7:46 p.m.
New subject: [Serusers] loose_route behaviour, detecting single Route with myself
no comments?
On 6/28/07, JF <jfkavaka(a)gmail.com> wrote:
I would propose to simply apply this patch to
modules/rr/loose.c:
@@ -1069,8 +1069,8 @@
return -1;
}
- if (is_myself(&_m->parsed_uri.host, _m->parsed_uri.port_no)
- || _m->parsed_uri.type==TEL_URI_T ||
_m->parsed_uri.type==TELS_URI_T) {
+ if (_m->parsed_uri.type==TEL_URI_T || _m->parsed_uri.type==TELS_URI_T ||
+ is_myself(&_m->parsed_uri.host,
_m->parsed_uri.port_no)) {
DBG("loose_route: RURI is myself (or tel URI)\n");
if ((ret = is_myself(&puri.host, puri.port_no)) == 1 &&
!(enable_double_rr && is_2rr(&puri.params))) {
JF
On 6/22/07, Greger Viken Teigre <greger(a)teigre.com> wrote:
This seems like a corner case where the tel uri
with no domain results in maybe a bit unfortunate return code from loose_route.
Comments anyone?
g-)
------- Original message -------
From: JF <jfkavaka(a)gmail.com>
Cc: serusers(a)iptel.org, openimscore-cscf(a)lists.berlios.de
Sent: 22.6.'07, 11:11
Thanks Greger,
The problem is related to the fact that the Req-URI is a tel-URI.
I had to work around it in the script by not letting loose_route get
called when the URI is a tel URI.
In loose.c, loose_route() says (by looking at the log):
DBG("loose_route: RURI is NOT myself\n");
because Req-URI doesn't have a host part.
Then after_loose(_m, &puri, 1, 0) is called because the single
existing Route header has our SIP URI.
And then:
DBG("after_loose: Topmost route URI: '%.*s' is me\n", uri->len,
ZSW(uri->s));
and
DBG("after_loose: No next URI found\n");
An since _ruri_myself == 0, return RR_DRIVEN;
IMO the fact that the Req-URI is a tel URI shouldn't make loose_route
return true in this case...
JF
On 6/21/07, Greger V. Teigre <greger(a)teigre.com> wrote:
If there's a single Route header pointing to
itself, then this is a good
indication that a UA added a Route to your proxy as an outbound proxy.
If SER correctly identities the uri as itself, it should AFAIK return false.
Could you please turn on debugging and then look for loose_route and
after_loose debug messages in the logs and post them?
g-)
JF wrote:
> Hi all,
>
> When SER receives an INVITE with a single Route header pointing to
> itself, it's supposed to delete it and process the message as if no
> Route header was there in the first place. This is what RFC3261
> mandates, right?
>
> But currently the loose_route function returns true to the script in
> this case, just like when more Route headers are present.
>
> So I have some routing logic for when no Route headers are present,
> and if I want to apply the same routing logic to the case when there
> is a single Route header pointing to myself (naturally, as it's the
> same as if no Route header was present), I currently have to replicate
> the same routing logic inside the if (loose_route())...
>
> Or is there an other way? Do I have to develop my own module function
> or use some regexp search from the script to detect if there are more
> Routes besides myself before I call loose_route?
>
> The best would be to change loose_route to return false and just
> remove the Route header pointing to myself when there are no more
> Route headers in the message... what do you think?
>
> JF
> _______________________________________________
> Serusers mailing list
> Serusers(a)lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
>
>
>
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers 
11 Jul
11 Jul
4:31 p.m.
New subject: [Serusers] [Serdev] loose_route behaviour, detecting single Route with myself
Hello,
I think the TEL URI was invented to make the live easier for PSTN gateways. So
they should only be used between proxy's and gateways (or vice versa). This
also means that a TEL URI should not be used routing between SIP proxies.
IMHO basically the first fully SIP aware hop should turn the TEL URI into a
SIP URI. That makes life of everybody easier.
So I think that treating a TEL URI as a local URI (as if it would have one of
the local domains) is not the correct solution.
To understand the scenario a little bit better: in this an in-dialog request
with a To-tag (then I'm wondering how this can happen), or is this an initial
request without a To-tag (the devices uses your proxy as outbound proxy)?
Regards
Nils
On Thursday 28 June 2007 17:13:43 JF wrote:
I would propose to simply apply this patch to
modules/rr/loose.c:
@@ -1069,8 +1069,8 @@
return -1;
}
- if (is_myself(&_m->parsed_uri.host, _m->parsed_uri.port_no)
- || _m->parsed_uri.type==TEL_URI_T ||
_m->parsed_uri.type==TELS_URI_T) {
+ if (_m->parsed_uri.type==TEL_URI_T ||
_m->parsed_uri.type==TELS_URI_T || +
is_myself(&_m->parsed_uri.host,
_m->parsed_uri.port_no)) {
DBG("loose_route: RURI is myself (or tel URI)\n");
if ((ret = is_myself(&puri.host, puri.port_no)) == 1 &&
!(enable_double_rr && is_2rr(&puri.params))) {
JF
On 6/22/07, Greger Viken Teigre <greger(a)teigre.com> wrote:
This seems like a corner case where the tel uri
with no domain results in
maybe a bit unfortunate return code from loose_route. Comments anyone?
g-)
------- Original message -------
From: JF <jfkavaka(a)gmail.com>
Cc: serusers(a)iptel.org, openimscore-cscf(a)lists.berlios.de
Sent: 22.6.'07, 11:11
> Thanks Greger,
>
> The problem is related to the fact that the Req-URI is a tel-URI.
> I had to work around it in the script by not letting loose_route get
> called when the URI is a tel URI.
>
> In loose.c, loose_route() says (by looking at the log):
> DBG("loose_route: RURI is NOT myself\n");
> because Req-URI doesn't have a host part.
>
> Then after_loose(_m, &puri, 1, 0) is called because the single
> existing Route header has our SIP URI.
> And then:
> DBG("after_loose: Topmost route URI: '%.*s' is me\n",
uri->len,
> ZSW(uri->s)); and
> DBG("after_loose: No next URI found\n");
> An since _ruri_myself == 0, return RR_DRIVEN;
>
> IMO the fact that the Req-URI is a tel URI shouldn't make loose_route
> return true in this case...
>
> JF
>
> On 6/21/07, Greger V. Teigre <greger(a)teigre.com> wrote:
> > If there's a single Route header pointing to itself, then this is a
> > good indication that a UA added a Route to your proxy as an outbound
> > proxy. If SER correctly identities the uri as itself, it should AFAIK
> > return false. Could you please turn on debugging and then look for
> > loose_route and after_loose debug messages in the logs and post them?
> > g-)
> >
> > JF wrote:
> > > Hi all,
> > >
> > > When SER receives an INVITE with a single Route header pointing to
> > > itself, it's supposed to delete it and process the message as if no
> > > Route header was there in the first place. This is what RFC3261
> > > mandates, right?
> > >
> > > But currently the loose_route function returns true to the script
> > > in this case, just like when more Route headers are present.
> > >
> > > So I have some routing logic for when no Route headers are present,
> > > and if I want to apply the same routing logic to the case when
> > > there is a single Route header pointing to myself (naturally, as
> > > it's the same as if no Route header was present), I currently have
> > > to replicate the same routing logic inside the if
> > > (loose_route())...
> > >
> > > Or is there an other way? Do I have to develop my own module
> > > function or use some regexp search from the script to detect if
> > > there are more Routes besides myself before I call loose_route?
> > >
> > > The best would be to change loose_route to return false and just
> > > remove the Route header pointing to myself when there are no more
> > > Route headers in the message... what do you think?
> > >
> > > JF
> > > _______________________________________________
> > > Serusers mailing list
> > > Serusers(a)lists.iptel.org
> > > http://lists.iptel.org/mailman/listinfo/serusers
>
> _______________________________________________
> Serusers mailing list
> Serusers(a)lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________
Serdev mailing list
Serdev(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serdev
5:07 p.m.
New subject: [Serusers] [Serdev] loose_route behaviour, detecting single Route with myself
The scenario was actually using an Application Server.
The AS starts a call and sends an INVITE with tel URI to a SER which
is the entrypoint to my SIP infrastructure. The AS uses this SER as
outbound proxy, so it includes its SIP URI in a Route header.
The use-case for tel URI in the Req-URI here is that it will be the
task of my SIP infrastructure to determine if this tel URI is
associated to a SIP phone, or if it should be forwarded to a PSTN gw.
JF
On 7/11/07, Nils Ohlmeier <nils(a)iptel.org> wrote:
Hello,
I think the TEL URI was invented to make the live easier for PSTN gateways. So
they should only be used between proxy's and gateways (or vice versa). This
also means that a TEL URI should not be used routing between SIP proxies.
IMHO basically the first fully SIP aware hop should turn the TEL URI into a
SIP URI. That makes life of everybody easier.
So I think that treating a TEL URI as a local URI (as if it would have one of
the local domains) is not the correct solution.
To understand the scenario a little bit better: in this an in-dialog request
with a To-tag (then I'm wondering how this can happen), or is this an initial
request without a To-tag (the devices uses your proxy as outbound proxy)?
Regards
Nils
On Thursday 28 June 2007 17:13:43 JF wrote:
I would propose to simply apply this patch to
modules/rr/loose.c:
@@ -1069,8 +1069,8 @@
return -1;
}
- if (is_myself(&_m->parsed_uri.host, _m->parsed_uri.port_no)
- || _m->parsed_uri.type==TEL_URI_T ||
_m->parsed_uri.type==TELS_URI_T) {
+ if (_m->parsed_uri.type==TEL_URI_T ||
_m->parsed_uri.type==TELS_URI_T || +
is_myself(&_m->parsed_uri.host,
_m->parsed_uri.port_no)) {
DBG("loose_route: RURI is myself (or tel URI)\n");
if ((ret = is_myself(&puri.host, puri.port_no)) == 1 &&
!(enable_double_rr && is_2rr(&puri.params))) {
JF
On 6/22/07, Greger Viken Teigre <greger(a)teigre.com> wrote:
This seems like a corner case where the tel uri
with no domain results in
maybe a bit unfortunate return code from loose_route. Comments anyone?
g-)
------- Original message -------
From: JF <jfkavaka(a)gmail.com>
Cc: serusers(a)iptel.org, openimscore-cscf(a)lists.berlios.de
Sent: 22.6.'07, 11:11
> Thanks Greger,
>
> The problem is related to the fact that the Req-URI is a tel-URI.
> I had to work around it in the script by not letting loose_route get
> called when the URI is a tel URI.
>
> In loose.c, loose_route() says (by looking at the log):
> DBG("loose_route: RURI is NOT myself\n");
> because Req-URI doesn't have a host part.
>
> Then after_loose(_m, &puri, 1, 0) is called because the single
> existing Route header has our SIP URI.
> And then:
> DBG("after_loose: Topmost route URI: '%.*s' is me\n",
uri->len,
> ZSW(uri->s)); and
> DBG("after_loose: No next URI found\n");
> An since _ruri_myself == 0, return RR_DRIVEN;
>
> IMO the fact that the Req-URI is a tel URI shouldn't make loose_route
> return true in this case...
>
> JF
>
> On 6/21/07, Greger V. Teigre <greger(a)teigre.com> wrote:
> > If there's a single Route header pointing to itself, then this is a
> > good indication that a UA added a Route to your proxy as an outbound
> > proxy. If SER correctly identities the uri as itself, it should AFAIK
> > return false. Could you please turn on debugging and then look for
> > loose_route and after_loose debug messages in the logs and post them?
> > g-)
> >
> > JF wrote:
> > > Hi all,
> > >
> > > When SER receives an INVITE with a single Route header pointing to
> > > itself, it's supposed to delete it and process the message as if no
> > > Route header was there in the first place. This is what RFC3261
> > > mandates, right?
> > >
> > > But currently the loose_route function returns true to the script
> > > in this case, just like when more Route headers are present.
> > >
> > > So I have some routing logic for when no Route headers are present,
> > > and if I want to apply the same routing logic to the case when
> > > there is a single Route header pointing to myself (naturally, as
> > > it's the same as if no Route header was present), I currently have
> > > to replicate the same routing logic inside the if
> > > (loose_route())...
> > >
> > > Or is there an other way? Do I have to develop my own module
> > > function or use some regexp search from the script to detect if
> > > there are more Routes besides myself before I call loose_route?
> > >
> > > The best would be to change loose_route to return false and just
> > > remove the Route header pointing to myself when there are no more
> > > Route headers in the message... what do you think?
> > >
> > > JF
> > > _______________________________________________
> > > Serusers mailing list
> > > Serusers(a)lists.iptel.org
> > > http://lists.iptel.org/mailman/listinfo/serusers
>
> _______________________________________________
> Serusers mailing list
> Serusers(a)lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________
Serdev mailing list
Serdev(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serdev
5:23 p.m.
New subject: [Serusers] [Serdev] loose_route behaviour, detecting single Route with myself
Hi,
On Wednesday 11 July 2007 17:07:22 JF wrote:
The scenario was actually using an Application
Server.
The AS starts a call and sends an INVITE with tel URI to a SER which
is the entrypoint to my SIP infrastructure. The AS uses this SER as
outbound proxy, so it includes its SIP URI in a Route header.
The use-case for tel URI in the Req-URI here is that it will be the
task of my SIP infrastructure to determine if this tel URI is
associated to a SIP phone, or if it should be forwarded to a PSTN gw.
But your AS uses a SIP URI as Contact in the INVITE?
And when the call is established either to a phone or the GW there will be no
TEL URI any more in the dialog, right?
If you can answer both questions from above with yes, I would propose to add
another check for the To-tag before we deviced if this is loose route driven
or not. That should then hopefully solve your problem in a generic way
without caring about the URI scheme.
Nils
JF
On 7/11/07, Nils Ohlmeier <nils(a)iptel.org> wrote:
> Hello,
>
> I think the TEL URI was invented to make the live easier for PSTN
> gateways. So they should only be used between proxy's and gateways (or
> vice versa). This also means that a TEL URI should not be used routing
> between SIP proxies. IMHO basically the first fully SIP aware hop should
> turn the TEL URI into a SIP URI. That makes life of everybody easier.
>
> So I think that treating a TEL URI as a local URI (as if it would have
> one of the local domains) is not the correct solution.
>
> To understand the scenario a little bit better: in this an in-dialog
> request with a To-tag (then I'm wondering how this can happen), or is
> this an initial request without a To-tag (the devices uses your proxy as
> outbound proxy)?
>
> Regards
> Nils
>
> On Thursday 28 June 2007 17:13:43 JF wrote:
> > I would propose to simply apply this patch to modules/rr/loose.c:
> >
> > @@ -1069,8 +1069,8 @@
> > return -1;
> > }
> >
> > - if (is_myself(&_m->parsed_uri.host, _m->parsed_uri.port_no)
> > - || _m->parsed_uri.type==TEL_URI_T ||
> > _m->parsed_uri.type==TELS_URI_T) {
> > + if (_m->parsed_uri.type==TEL_URI_T ||
> > _m->parsed_uri.type==TELS_URI_T || +
> > is_myself(&_m->parsed_uri.host,
> > _m->parsed_uri.port_no)) {
> > DBG("loose_route: RURI is myself (or tel URI)\n");
> > if ((ret = is_myself(&puri.host, puri.port_no)) == 1
&&
> > !(enable_double_rr &&
is_2rr(&puri.params))) {
> >
> >
> > JF
> >
> > On 6/22/07, Greger Viken Teigre <greger(a)teigre.com> wrote:
> > > This seems like a corner case where the tel uri with no domain
> > > results in maybe a bit unfortunate return code from loose_route.
> > > Comments anyone? g-)
5:35 p.m.
New subject: [Serusers] [Serdev] loose_route behaviour, detecting single Route with myself
Answer to 1st question: Yes.
Answer to 2nd question: if the call is routed to a SIP phone, the
Req-URI is rewritten with an appropriate SIP URI (not necessarily
sip:number_in_tel_uri@mydomain). If it goes to a PSTN gw, it is kept
unchanged as a tel URI.
JF
On 7/11/07, Nils Ohlmeier <nils(a)iptel.org> wrote:
Hi,
On Wednesday 11 July 2007 17:07:22 JF wrote:
The scenario was actually using an Application
Server.
The AS starts a call and sends an INVITE with tel URI to a SER which
is the entrypoint to my SIP infrastructure. The AS uses this SER as
outbound proxy, so it includes its SIP URI in a Route header.
The use-case for tel URI in the Req-URI here is that it will be the
task of my SIP infrastructure to determine if this tel URI is
associated to a SIP phone, or if it should be forwarded to a PSTN gw.
But your AS uses a SIP URI as Contact in the INVITE?
And when the call is established either to a phone or the GW there will be no
TEL URI any more in the dialog, right?
If you can answer both questions from above with yes, I would propose to add
another check for the To-tag before we deviced if this is loose route driven
or not. That should then hopefully solve your problem in a generic way
without caring about the URI scheme.
Nils
JF
On 7/11/07, Nils Ohlmeier <nils(a)iptel.org> wrote:
> Hello,
>
> I think the TEL URI was invented to make the live easier for PSTN
> gateways. So they should only be used between proxy's and gateways (or
> vice versa). This also means that a TEL URI should not be used routing
> between SIP proxies. IMHO basically the first fully SIP aware hop should
> turn the TEL URI into a SIP URI. That makes life of everybody easier.
>
> So I think that treating a TEL URI as a local URI (as if it would have
> one of the local domains) is not the correct solution.
>
> To understand the scenario a little bit better: in this an in-dialog
> request with a To-tag (then I'm wondering how this can happen), or is
> this an initial request without a To-tag (the devices uses your proxy as
> outbound proxy)?
>
> Regards
> Nils
>
> On Thursday 28 June 2007 17:13:43 JF wrote:
> > I would propose to simply apply this patch to modules/rr/loose.c:
> >
> > @@ -1069,8 +1069,8 @@
> > return -1;
> > }
> >
> > - if (is_myself(&_m->parsed_uri.host, _m->parsed_uri.port_no)
> > - || _m->parsed_uri.type==TEL_URI_T ||
> > _m->parsed_uri.type==TELS_URI_T) {
> > + if (_m->parsed_uri.type==TEL_URI_T ||
> > _m->parsed_uri.type==TELS_URI_T || +
> > is_myself(&_m->parsed_uri.host,
> > _m->parsed_uri.port_no)) {
> > DBG("loose_route: RURI is myself (or tel URI)\n");
> > if ((ret = is_myself(&puri.host, puri.port_no)) == 1
&&
> > !(enable_double_rr &&
is_2rr(&puri.params))) {
> >
> >
> > JF
> >
> > On 6/22/07, Greger Viken Teigre <greger(a)teigre.com> wrote:
> > > This seems like a corner case where the tel uri with no domain
> > > results in maybe a bit unfortunate return code from loose_route.
> > > Comments anyone? g-)
5:43 p.m.
New subject: [Serusers] [Serdev] loose_route behaviour, detecting single Route with myself
On Wednesday 11 July 2007 17:35:39 JF wrote:
Answer to 1st question: Yes.
Ok
Answer to 2nd question: if the call is routed to a SIP
phone, the
Req-URI is rewritten with an appropriate SIP URI (not necessarily
sip:number_in_tel_uri@mydomain). If it goes to a PSTN gw, it is kept
unchanged as a tel URI.
Ok, but for further in-dialog routing of the message between your AS and the
GW the Contact's of the AS and the GW are important. As long none of these
two uses a TEL URI Contact (which would be IMHO totally stupid), it does not
matter if the TEL URI is not re-written on the way to the GW.
Nils
JF
On 7/11/07, Nils Ohlmeier <nils(a)iptel.org> wrote:
> Hi,
>
> On Wednesday 11 July 2007 17:07:22 JF wrote:
> > The scenario was actually using an Application Server.
> > The AS starts a call and sends an INVITE with tel URI to a SER which
> > is the entrypoint to my SIP infrastructure. The AS uses this SER as
> > outbound proxy, so it includes its SIP URI in a Route header.
> >
> > The use-case for tel URI in the Req-URI here is that it will be the
> > task of my SIP infrastructure to determine if this tel URI is
> > associated to a SIP phone, or if it should be forwarded to a PSTN gw.
>
> But your AS uses a SIP URI as Contact in the INVITE?
> And when the call is established either to a phone or the GW there will
> be no TEL URI any more in the dialog, right?
>
> If you can answer both questions from above with yes, I would propose to
> add another check for the To-tag before we deviced if this is loose route
> driven or not. That should then hopefully solve your problem in a generic
> way without caring about the URI scheme.
>
> Nils
>
> > JF
> >
> > On 7/11/07, Nils Ohlmeier <nils(a)iptel.org> wrote:
> > > Hello,
> > >
> > > I think the TEL URI was invented to make the live easier for PSTN
> > > gateways. So they should only be used between proxy's and gateways
> > > (or vice versa). This also means that a TEL URI should not be used
> > > routing between SIP proxies. IMHO basically the first fully SIP aware
> > > hop should turn the TEL URI into a SIP URI. That makes life of
> > > everybody easier.
> > >
> > > So I think that treating a TEL URI as a local URI (as if it would
> > > have one of the local domains) is not the correct solution.
> > >
> > > To understand the scenario a little bit better: in this an in-dialog
> > > request with a To-tag (then I'm wondering how this can happen), or is
> > > this an initial request without a To-tag (the devices uses your proxy
> > > as outbound proxy)?
> > >
> > > Regards
> > > Nils
> > >
> > > On Thursday 28 June 2007 17:13:43 JF wrote:
> > > > I would propose to simply apply this patch to modules/rr/loose.c:
> > > >
> > > > @@ -1069,8 +1069,8 @@
> > > > return -1;
> > > > }
> > > >
> > > > - if (is_myself(&_m->parsed_uri.host,
_m->parsed_uri.port_no)
> > > > - || _m->parsed_uri.type==TEL_URI_T ||
> > > > _m->parsed_uri.type==TELS_URI_T) {
> > > > + if (_m->parsed_uri.type==TEL_URI_T ||
> > > > _m->parsed_uri.type==TELS_URI_T || +
> > > > is_myself(&_m->parsed_uri.host,
> > > > _m->parsed_uri.port_no)) {
> > > > DBG("loose_route: RURI is myself (or tel
URI)\n");
> > > > if ((ret = is_myself(&puri.host, puri.port_no))
==
> > > > 1 && !(enable_double_rr && is_2rr(&puri.params)))
{
> > > >
> > > >
> > > > JF
> > > >
> > > > On 6/22/07, Greger Viken Teigre <greger(a)teigre.com> wrote:
> > > > > This seems like a corner case where the tel uri with no domain
> > > > > results in maybe a bit unfortunate return code from
loose_route.
> > > > > Comments anyone? g-)
5:55 p.m.
New subject: [Serusers] [Serdev] loose_route behaviour, detecting single Route with myself
Right. No tel URI Contacts. Contacts use only SIP or SIPS URIs.
JF
On 7/11/07, Nils Ohlmeier <nils(a)iptel.org> wrote:
On Wednesday 11 July 2007 17:35:39 JF wrote:
Answer to 1st question: Yes.
Ok
Answer to 2nd question: if the call is routed to
a SIP phone, the
Req-URI is rewritten with an appropriate SIP URI (not necessarily
sip:number_in_tel_uri@mydomain). If it goes to a PSTN gw, it is kept
unchanged as a tel URI.
Ok, but for further in-dialog routing of the message between your AS and the
GW the Contact's of the AS and the GW are important. As long none of these
two uses a TEL URI Contact (which would be IMHO totally stupid), it does not
matter if the TEL URI is not re-written on the way to the GW.
Nils
JF
On 7/11/07, Nils Ohlmeier <nils(a)iptel.org> wrote:
> Hi,
>
> On Wednesday 11 July 2007 17:07:22 JF wrote:
> > The scenario was actually using an Application Server.
> > The AS starts a call and sends an INVITE with tel URI to a SER which
> > is the entrypoint to my SIP infrastructure. The AS uses this SER as
> > outbound proxy, so it includes its SIP URI in a Route header.
> >
> > The use-case for tel URI in the Req-URI here is that it will be the
> > task of my SIP infrastructure to determine if this tel URI is
> > associated to a SIP phone, or if it should be forwarded to a PSTN gw.
>
> But your AS uses a SIP URI as Contact in the INVITE?
> And when the call is established either to a phone or the GW there will
> be no TEL URI any more in the dialog, right?
>
> If you can answer both questions from above with yes, I would propose to
> add another check for the To-tag before we deviced if this is loose route
> driven or not. That should then hopefully solve your problem in a generic
> way without caring about the URI scheme.
>
> Nils
>
> > JF
> >
> > On 7/11/07, Nils Ohlmeier <nils(a)iptel.org> wrote:
> > > Hello,
> > >
> > > I think the TEL URI was invented to make the live easier for PSTN
> > > gateways. So they should only be used between proxy's and gateways
> > > (or vice versa). This also means that a TEL URI should not be used
> > > routing between SIP proxies. IMHO basically the first fully SIP aware
> > > hop should turn the TEL URI into a SIP URI. That makes life of
> > > everybody easier.
> > >
> > > So I think that treating a TEL URI as a local URI (as if it would
> > > have one of the local domains) is not the correct solution.
> > >
> > > To understand the scenario a little bit better: in this an in-dialog
> > > request with a To-tag (then I'm wondering how this can happen), or is
> > > this an initial request without a To-tag (the devices uses your proxy
> > > as outbound proxy)?
> > >
> > > Regards
> > > Nils
> > >
> > > On Thursday 28 June 2007 17:13:43 JF wrote:
> > > > I would propose to simply apply this patch to modules/rr/loose.c:
> > > >
> > > > @@ -1069,8 +1069,8 @@
> > > > return -1;
> > > > }
> > > >
> > > > - if (is_myself(&_m->parsed_uri.host,
_m->parsed_uri.port_no)
> > > > - || _m->parsed_uri.type==TEL_URI_T ||
> > > > _m->parsed_uri.type==TELS_URI_T) {
> > > > + if (_m->parsed_uri.type==TEL_URI_T ||
> > > > _m->parsed_uri.type==TELS_URI_T || +
> > > > is_myself(&_m->parsed_uri.host,
> > > > _m->parsed_uri.port_no)) {
> > > > DBG("loose_route: RURI is myself (or tel
URI)\n");
> > > > if ((ret = is_myself(&puri.host, puri.port_no))
==
> > > > 1 && !(enable_double_rr && is_2rr(&puri.params)))
{
> > > >
> > > >
> > > > JF
> > > >
> > > > On 6/22/07, Greger Viken Teigre <greger(a)teigre.com> wrote:
> > > > > This seems like a corner case where the tel uri with no domain
> > > > > results in maybe a bit unfortunate return code from
loose_route.
> > > > > Comments anyone? g-)
9:57 p.m.
New subject: [Serusers] [Serdev] loose_route behaviour, detecting single Route with myself
Nils Ohlmeier wrote:
On Wednesday 11 July 2007 17:35:39 JF wrote:
It would not only be stupid, it would be illegal.
.--[RFC 3261, section 8.1.1.8]--
|
| The Contact header field MUST be present and contain exactly one SIP
| or SIPS URI in any request that can result in the establishment of a
| dialog.
|
`--
Answer to 1st question: Yes.
Ok
Answer to 2nd question: if the call is routed to
a SIP phone, the
Req-URI is rewritten with an appropriate SIP URI (not necessarily
sip:number_in_tel_uri@mydomain). If it goes to a PSTN gw, it is kept
unchanged as a tel URI.
Ok, but for further in-dialog routing of the message between your AS and the
GW the Contact's of the AS and the GW are important. As long none of these
two uses a TEL URI Contact (which would be IMHO totally stupid), it does not
matter if the TEL URI is not re-written on the way to the GW.
Indeed. The only way loose_route() can end up using tel URIs is when someone
preloaded a message with a Route header and used a tel URI as
Request-URI, which is perfectly legal.
As for the return value of loose_route(), behaviour has changed over
time a bit. In 0.8 it used to return true only if there was yet another
Route header, ie., it returned false if this proxy was the last one in
the chain of record routing. This changed sometime in 0.9 to the current
behaviour to return true whenever there the topmost Route is this proxy.
In most cases this is what you want, because the presence of Routes
indicates an in-dialog message which you want to treat differently (In
practice, most UAs just forward the message to the outgoing proxy
without adding a Route header, which is perfectly legal as well). The
proper test for this, of course, is to check for the presence of a To
tag. But it seems to be common to all SER configs I have seen to misuse
loose_route() in this way.
Changing the behaviour of loose_route() yet again would mess up a lot of
configs as the earlier change messed up a lot of configs (it certainly
cost me a couple of hours debugging). Having another function would
probably be a better approach. Especially, since loose_route() is
actually the wrong name. The function does both loose and static record
routing.
Regards,
Martin
12 Jul
12 Jul
12:44 a.m.
New subject: [Serusers] [Serdev] loose_route behaviour, detecting single Route with myself
On Wednesday 11 July 2007 21:57:15 Martin Hoffmann wrote:
Indeed. The only way loose_route() can end up using
tel URIs is when
someone preloaded a message with a Route header and used a tel URI as
Request-URI, which is perfectly legal.
Exactly.
As for the return value of loose_route(), behaviour
has changed over
time a bit. In 0.8 it used to return true only if there was yet another
Route header, ie., it returned false if this proxy was the last one in
the chain of record routing. This changed sometime in 0.9 to the current
behaviour to return true whenever there the topmost Route is this proxy.
Yes. My assumption was that loose_route() returns true if the message came to
the proxy by the usage of Route headers. Or in other words: the routing of
this message was completely handle by the loose_route function because of the
presence of correct Route headers.
In most cases this is what you want, because the
presence of Routes
indicates an in-dialog message which you want to treat differently (In
practice, most UAs just forward the message to the outgoing proxy
without adding a Route header, which is perfectly legal as well). The
proper test for this, of course, is to check for the presence of a To
tag. But it seems to be common to all SER configs I have seen to misuse
loose_route() in this way.
The realization of the fact that the presence or absence of To-tag is not
enough to decide if a request belongs to a dialog or not. The big exception
here is the ACK for negative replies. It has a To-tag but a dialog was not
established.
Changing the behaviour of loose_route() yet again
would mess up a lot of
configs as the earlier change messed up a lot of configs (it certainly
cost me a couple of hours debugging). Having another function would
probably be a better approach. Especially, since loose_route() is
actually the wrong name. The function does both loose and static record
routing.
I agree, changing the return value again would not help. The big question is
if a preloaded request should be "handled" by the loose_route function?
I guess the best solution would be to have one function preloaded() which
returns true on preloaded requests and just consumes the Route header. And if
this function returned true you could treat the request like any other
incoming request from one of your UAs without a Route header.
Then you would call loose_route() only to take care of the remaining in-dialog
request (no matter if it is loose or strict routing).
But such a seperation would mean a change in the behavior again, because
currently preloaded requests are also handled by loose_route() (it returns
true for these requests). So it would be only an option to change this in
head.
Cheers
Nils
9:06 a.m.
New subject: [Serusers] [Serdev] loose_route behaviour, detecting single Route with myself
Nils Ohlmeier wrote:
But such a seperation would mean a change in the
behavior again, because
currently preloaded requests are also handled by loose_route() (it returns
true for these requests). So it would be only an option to change this in
head.
I would vote to make totally new functions which also have a better
naming. Then people can use the old function with old behavior or the
new functions with new behavior.
regards
klaus
9:21 a.m.
New subject: [Serusers] [Serdev] loose_route behaviour, detecting single Route with myself
Klaus Darilion wrote:
Nils Ohlmeier wrote:
Me 2. Possibly even put all that into a new rr module (rr2? recroute?).
Regards,
Martin
PS: Why is this thread send to serdev twice? Or is there a difference
between serdev(a)iptel.org and serdev(a)lists.iptel.org?
But such a seperation would mean a change in the
behavior again, because
currently preloaded requests are also handled by loose_route() (it returns
true for these requests). So it would be only an option to change this in
head.
I would vote to make totally new functions which also have a better
naming. Then people can use the old function with old behavior or the
new functions with new behavior.
9:26 a.m.
New subject: [Serusers] [Serdev] loose_route behaviour, detecting single?Route with myself
Nils Ohlmeier wrote:
On Wednesday 11 July 2007 21:57:15 Martin Hoffmann
wrote:
That is a non-issue. This ACK needs special treatment anyways -- it is
to be consumed by tm.
Is there any argument against putting a
if (method == "ACK") {
t_relay();
drop();
}
somewhere way up in your config?
Regards,
Martin
In most cases this is what you want, because the
presence of Routes
indicates an in-dialog message which you want to treat differently (In
practice, most UAs just forward the message to the outgoing proxy
without adding a Route header, which is perfectly legal as well). The
proper test for this, of course, is to check for the presence of a To
tag. But it seems to be common to all SER configs I have seen to misuse
loose_route() in this way.
The realization of the fact that the presence or absence of To-tag is not
enough to decide if a request belongs to a dialog or not. The big exception
here is the ACK for negative replies. It has a To-tag but a dialog was not
established.
12:28 p.m.
New subject: [Serusers] [Serdev] loose_route behaviour, detecting single?Route with myself
On Thursday 12 July 2007 09:26:37 Martin Hoffmann wrote:
Nils Ohlmeier wrote:
And how do you distinguish between in-dialog ACKs and out-of-dialog ACKs?
Note: they both have a To-tag and even worse if the original INVITE contained
a pre-loaded Route header (for outbound proxy) the ACK has to contain this
Route as well!
Nils
On Wednesday 11 July 2007 21:57:15 Martin
Hoffmann wrote:
That is a non-issue. This ACK needs special treatment anyways -- it is
to be consumed by tm.
Is there any argument against putting a
if (method == "ACK") {
t_relay();
drop();
}
somewhere way up in your config? In most cases this is what you want, because the
presence of Routes
indicates an in-dialog message which you want to treat differently (In
practice, most UAs just forward the message to the outgoing proxy
without adding a Route header, which is perfectly legal as well). The
proper test for this, of course, is to check for the presence of a To
tag. But it seems to be common to all SER configs I have seen to misuse
loose_route() in this way.
The realization of the fact that the presence or absence of To-tag is not
enough to decide if a request belongs to a dialog or not. The big
exception here is the ACK for negative replies. It has a To-tag but a
dialog was not established.
12:54 p.m.
New subject: [Serusers] ACK processing (was: [Serdev] loose_route behaviour, detecting single?Route with myself)
Nils Ohlmeier wrote:
On Thursday 12 July 2007 09:26:37 Martin Hoffmann
wrote:
Techically, there is no such thing. There is only ACKs to 2xx and
non-2xx responses. The former are always in-dialog requests, since the
2xx creates the dialog should it not yet exists. The latter is a matter
of the transaction layer which doesn't know of dialogs.
In practice, an ACK to a non-2xx response always needs to be eaten by
tm. This t_relay() does. Any ACK to a 2xx response needs to be routed
like any other in-dialog request to the endpoint (save for some
elaborate processing such as authentication). Which means, my code
snipped does indeed lack a loose_route() before t_relay().
Is there any argument against putting a
if (method == "ACK") {
t_relay();
drop();
}
somewhere way up in your config?
And how do you distinguish between in-dialog ACKs and out-of-dialog ACKs? Note: they both have a To-tag and even worse if the
original INVITE contained
a pre-loaded Route header (for outbound proxy) the ACK has to contain this
Route as well!
Depends. A non-2xx ACK indeed has to. But a 2xx ACK musn't. It is to be
created like any other in-dialog request. The Route set thus MUST be the
reversed set of the Record-Route headers of the 2xx response, possibly
be empty.
Regards,
Martin
Book keeping: Limited to seruser and changed subject.
1:25 p.m.
New subject: [Serusers] ACK processing (was: [Serdev] loose_route behaviour, detecting single?Route with myself)
On Thursday 12 July 2007 12:54:58 Martin Hoffmann wrote:
You are not telling me anything new here. But as I explained in my other reply
to Klaus it is quite tricky to distinguish a non-2xx ACK with pre-loaded
Route, from a 2xx ACK with just one Route header. Then the only difference is
the RURI.
Because of this I prefer the approach of "routing" pre-loaded requests via
loose_route() to the RURI. That is IMHO the cleanest solution.
Nils Ohlmeier wrote:
You call them non-2xx ACKs, I called them out-of-dialog ACKs (because the
typical scenario for them is the acknowledgment of the 40[17] for the INVITE,
and there is no dialog yet). But we are speaking about the same here.
On Thursday 12 July 2007 09:26:37 Martin Hoffmann
wrote:
Techically, there is no such thing. There is only ACKs to 2xx and
non-2xx responses. The former are always in-dialog requests, since the
2xx creates the dialog should it not yet exists. The latter is a matter
of the transaction layer which doesn't know of dialogs. Is there any argument against putting a
if (method == "ACK") {
t_relay();
drop();
}
somewhere way up in your config?
And how do you distinguish between in-dialog ACKs and out-of-dialog ACKs? In practice, an ACK to a non-2xx response always needs
to be eaten by
tm. This t_relay() does. Any ACK to a 2xx response needs to be routed
like any other in-dialog request to the endpoint (save for some
elaborate processing such as authentication). Which means, my code
snipped does indeed lack a loose_route() before t_relay().
Ok, what is the loose_route suppose to do in this case?
A 2xx ACK would be "routed" according to the Route headers by loose_route(),
and relayed by t_relay() then. And what about the pre-loaded non-2xx ACKs?
I would treat them exactly the same way like the 2xx ACK. loose_route() will
consum the Route header and t_relay() then forwards it to the RURI (which
should be your proxy). When you receive it again, their is no Route in it any
more, so it should hit your normal non-dialog code where it hopefully sooner
or later will hit a t_relay.
Note: they
both have a To-tag and even worse if the original INVITE
contained a pre-loaded Route header (for outbound proxy) the ACK has to
contain this Route as well!
Depends. A non-2xx ACK indeed has to. But a 2xx ACK musn't. It is to be
created like any other in-dialog request. The Route set thus MUST be the
reversed set of the Record-Route headers of the 2xx response, possibly
be empty. Book keeping: Limited to seruser and changed subject.
I'm not sure if that was the right limitation, but anyway ;-)
Regards
Nils
1:49 p.m.
New subject: [Serusers] ACK processing (was: [Serdev] loose_route behaviour, detecting single?Route with myself)
Nils Ohlmeier wrote:
Meaning, it gets the treatment it deserves.
On Thursday 12 July 2007 12:54:58 Martin Hoffmann
wrote:
Finally figured that from your reply to Klaus.
Techically, there is no such thing. There is only ACKs to 2xx and
non-2xx responses. The former are always in-dialog requests, since the
2xx creates the dialog should it not yet exists. The latter is a matter
of the transaction layer which doesn't know of dialogs.
You call them non-2xx ACKs, I called them out-of-dialog ACKs (because the
typical scenario for them is the acknowledgment of the 40[17] for the INVITE,
and there is no dialog yet). But we are speaking about the same here. In practice,
an ACK to a non-2xx response always needs to be eaten by
tm. This t_relay() does. Any ACK to a 2xx response needs to be routed
like any other in-dialog request to the endpoint (save for some
elaborate processing such as authentication). Which means, my code
snipped does indeed lack a loose_route() before t_relay().
Ok, what is the loose_route suppose to do in this case?
A 2xx ACK would be "routed" according to the Route headers by loose_route(),
and relayed by t_relay() then. And what about the pre-loaded non-2xx ACKs?
I would treat them exactly the same way like the 2xx ACK. loose_route() will
consum the Route header and t_relay() then forwards it to the RURI (which
should be your proxy).
Now you made me read tm sources again. What actually happens inside tm
when you call t_relay() is that t_lookup_request() matches the
transaction the ACK belongs to, t_newtran() releases that transaction,
and t_relay_to() stops the script.
Thus, the call the loose_route() doesn't hurt, in the non-2xx case it
effectively is a no-op.
But as I explained in my other reply
to Klaus it is quite tricky to distinguish a non-2xx ACK with pre-loaded
Route, from a 2xx ACK with just one Route header. Then the only difference is
the RURI.
There is another one: For the former you have a transaction, for the
latter you don't. tm happily exploits this difference. No need to worry
in your config.
Regards,
Martin
2:38 p.m.
New subject: [Serusers] ACK processing (was: [Serdev] loose_route behaviour, detecting single?Route with myself)
On Thursday 12 July 2007 13:49:45 Martin Hoffmann wrote:
Nils Ohlmeier wrote:
I glad that it is fine if you use tm.
But I think it should also work if you are not transaction statefull (if you
dont use tm). That is actually the problem which I wanted to solve with the
new loose_route implementation.
Nils
And what about the pre-loaded non-2xx ACKs?
I would treat them exactly the same way like the 2xx ACK. loose_route()
will consum the Route header and t_relay() then forwards it to the RURI
(which should be your proxy).
Now you made me read tm sources again. What actually happens inside tm
when you call t_relay() is that t_lookup_request() matches the
transaction the ACK belongs to, t_newtran() releases that transaction,
and t_relay_to() stops the script.
Thus, the call the loose_route() doesn't hurt, in the non-2xx case it
effectively is a no-op.
But as I explained in my other reply
to Klaus it is quite tricky to distinguish a non-2xx ACK with pre-loaded
Route, from a 2xx ACK with just one Route header. Then the only
difference is the RURI.
There is another one: For the former you have a transaction, for the
latter you don't. tm happily exploits this difference. No need to worry
in your config. 
16 Jul
16 Jul
12:06 p.m.
New subject: [Serusers] [Serdev] loose_route behaviour, detecting single?Route with myself
At 09:26 12/07/2007, Martin Hoffmann wrote:
Nils Ohlmeier wrote:
I would say too that this is not a big exception but an insignificant one.
(Historians may wish to comment, that from the protocol design point of view
the positive ACK is just terribly insane in SIP, but for benefit of the
mailing list readers I will save you this ellaboration.)
On Wednesday 11 July 2007 21:57:15 Martin
Hoffmann wrote:
That is a non-issue. This ACK needs special treatment anyways -- it is
to be consumed by tm. In most cases this is what you want, because the
presence of Routes
indicates an in-dialog message which you want to treat differently (In
practice, most UAs just forward the message to the outgoing proxy
without adding a Route header, which is perfectly legal as well). The
proper test for this, of course, is to check for the presence of a To
tag. But it seems to be common to all SER configs I have seen to misuse
loose_route() in this way.
The realization of the fact that the presence or absence of To-tag is not
enough to decide if a request belongs to a dialog or not. The big exception
here is the ACK for negative replies. It has a To-tag but a dialog was not
established. Is there any argument against putting a
if (method == "ACK") {
t_relay();
drop();
}
somewhere way up in your config?
Haven't tried but it seems workable. It would have to be behind loose_route
(otherweise e2e ACK routed using record-routed logic would be routed wrong.)
hbh ACKs are absorbed by t_relay, e2e ACKs forwarded statelessly.
Anyhow, I got lost in the volume of this exciting debate. Can some of the
honorable gentlemen make me a massive favor and "destilate" for me, what
the problem is thought to be? (i.e., what does not work "as is")?
Thanks a lot!
-jiri
--
Jiri Kuthan http://iptel.org/~jiri/
17 Jul
17 Jul
noon
New subject: [Serusers] [Serdev] loose_route behaviour, detecting single?Route with myself
On Monday 16 July 2007 12:06:40 Jiri Kuthan wrote:
At 09:26 12/07/2007, Martin Hoffmann wrote:
I'll try my best....
It was started by JF who pointed out that an INVITE with a TEL URI in the RURI
and a SIP URI as preloaded Route is not handled the same way by loose_route()
as other preloaded requests. The reason for this is that a TEL URI is not
detected/accepted as local URI.
If the RURI contains a local URI the handling is very easy, because you simply
can remove the Route header and forward the request to yourself. In the
second round the request should be treated as any other incoming request
without a preloaded route. Unfortunately this does not work in case of
non-local RURI's.
Then I tried to explain what was the motivation behind the change of the
loose_route() function for 2.0 (stateless handling of non-2xx preloaded ACKs
and 2xx ACKs - please see the thread for details).
Then the reasonable question was raised if preloaded requests should be
handled by the loose_route() function at all.
Currently I like Martin's proposal of having an extra function for preloaded
requests best. But
- a clean implemenatation of this is not easy
- still the only solution for distinguishing non-2xx preloaded ACKs from 2xx
ACKs seems to be a Route cookie (which can be omitted if your proxy is
statefull)
- all this discussion is IMO for SER version > 2.0
Besides this interesting discussion for future SER versions, the big open
question is: if and how we want to change/fix the original problem of JF?
Personally I do not like JFs proposal, because it "fixes" only his problem
with TEL URIs. But the general problem of having pre-loaded requests with
non-local or non-routeable RURIs is not solved by this.
Changing loose_route() in a way of not handling preloaded requests is a too
dramitcal change for the 2.0 release IMHO.
Introducing a To-tag check would be a faulty solution as well (as I explained
already that you can not distinguish a non-2xx preloaded ACK from a 2xx ACK
by this).
So I fear there is no optimal solution for this. Thus I would propose that we
just explain that this "special case" has to be considered by the script
writers.
Regards
Nils
Nils Ohlmeier wrote:
I would say too that this is not a big exception but an insignificant one.
(Historians may wish to comment, that from the protocol design point of
view the positive ACK is just terribly insane in SIP, but for benefit of
the mailing list readers I will save you this ellaboration.)
The realization of the fact that the presence or
absence of To-tag is
not enough to decide if a request belongs to a dialog or not. The big
exception here is the ACK for negative replies. It has a To-tag but a
dialog was not established.
That is a non-issue. This ACK needs special treatment anyways -- it is
to be consumed by tm. Is there any argument against putting a
if (method == "ACK") {
t_relay();
drop();
}
somewhere way up in your config?
Haven't tried but it seems workable. It would have to be behind loose_route
(otherweise e2e ACK routed using record-routed logic would be routed
wrong.) hbh ACKs are absorbed by t_relay, e2e ACKs forwarded statelessly.
Anyhow, I got lost in the volume of this exciting debate. Can some of the
honorable gentlemen make me a massive favor and "destilate" for me, what
the problem is thought to be? (i.e., what does not work "as is")?
1:22 p.m.
New subject: [Serusers] [Serdev] loose_route behaviour, detecting single?Route with myself
In order to be treated as a special case in the script (with
uri~="tel:.*"), we will need the extra function to detect preloaded
routes.
JF
On 7/17/07, Nils Ohlmeier <nils(a)iptel.org> wrote:
On Monday 16 July 2007 12:06:40 Jiri Kuthan wrote:
At 09:26 12/07/2007, Martin Hoffmann wrote:
I'll try my best....
It was started by JF who pointed out that an INVITE with a TEL URI in the RURI
and a SIP URI as preloaded Route is not handled the same way by loose_route()
as other preloaded requests. The reason for this is that a TEL URI is not
detected/accepted as local URI.
If the RURI contains a local URI the handling is very easy, because you simply
can remove the Route header and forward the request to yourself. In the
second round the request should be treated as any other incoming request
without a preloaded route. Unfortunately this does not work in case of
non-local RURI's.
Then I tried to explain what was the motivation behind the change of the
loose_route() function for 2.0 (stateless handling of non-2xx preloaded ACKs
and 2xx ACKs - please see the thread for details).
Then the reasonable question was raised if preloaded requests should be
handled by the loose_route() function at all.
Currently I like Martin's proposal of having an extra function for preloaded
requests best. But
- a clean implemenatation of this is not easy
- still the only solution for distinguishing non-2xx preloaded ACKs from 2xx
ACKs seems to be a Route cookie (which can be omitted if your proxy is
statefull)
- all this discussion is IMO for SER version > 2.0
Besides this interesting discussion for future SER versions, the big open
question is: if and how we want to change/fix the original problem of JF?
Personally I do not like JFs proposal, because it "fixes" only his problem
with TEL URIs. But the general problem of having pre-loaded requests with
non-local or non-routeable RURIs is not solved by this.
Changing loose_route() in a way of not handling preloaded requests is a too
dramitcal change for the 2.0 release IMHO.
Introducing a To-tag check would be a faulty solution as well (as I explained
already that you can not distinguish a non-2xx preloaded ACK from a 2xx ACK
by this).
So I fear there is no optimal solution for this. Thus I would propose that we
just explain that this "special case" has to be considered by the script
writers.
Regards
Nils
_______________________________________________
Serdev mailing list
Serdev(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serdev
Nils Ohlmeier wrote:
I would say too that this is not a big exception but an insignificant one.
(Historians may wish to comment, that from the protocol design point of
view the positive ACK is just terribly insane in SIP, but for benefit of
the mailing list readers I will save you this ellaboration.)
The realization of the fact that the presence or
absence of To-tag is
not enough to decide if a request belongs to a dialog or not. The big
exception here is the ACK for negative replies. It has a To-tag but a
dialog was not established.
That is a non-issue. This ACK needs special treatment anyways -- it is
to be consumed by tm. Is there any argument against putting a
if (method == "ACK") {
t_relay();
drop();
}
somewhere way up in your config?
Haven't tried but it seems workable. It would have to be behind loose_route
(otherweise e2e ACK routed using record-routed logic would be routed
wrong.) hbh ACKs are absorbed by t_relay, e2e ACKs forwarded statelessly.
Anyhow, I got lost in the volume of this exciting debate. Can some of the
honorable gentlemen make me a massive favor and "destilate" for me, what
the problem is thought to be? (i.e., what does not work "as is")?
12 Jul
12 Jul
8:31 p.m.
New subject: [Serusers] [Serdev] loose_route behaviour, detecting single Route with myself
I vote for a new preloaded_route() in trunk. I also suggest a new alias
for loose_route (or rename and create loose_route as backwards
compatible name): in_dialog() returning true if and only if the message
being processed is and in-dialog message.
g-)
Nils Ohlmeier wrote:
On Wednesday 11 July 2007 21:57:15 Martin Hoffmann
wrote:
Indeed. The only way loose_route() can end up
using tel URIs is when
someone preloaded a message with a Route header and used a tel URI as
Request-URI, which is perfectly legal.
Exactly.
As for the return value of loose_route(),
behaviour has changed over
time a bit. In 0.8 it used to return true only if there was yet another
Route header, ie., it returned false if this proxy was the last one in
the chain of record routing. This changed sometime in 0.9 to the current
behaviour to return true whenever there the topmost Route is this proxy.
Yes. My assumption was that loose_route() returns true if the message came to
the proxy by the usage of Route headers. Or in other words: the routing of
this message was completely handle by the loose_route function because of the
presence of correct Route headers.
In most cases this is what you want, because the
presence of Routes
indicates an in-dialog message which you want to treat differently (In
practice, most UAs just forward the message to the outgoing proxy
without adding a Route header, which is perfectly legal as well). The
proper test for this, of course, is to check for the presence of a To
tag. But it seems to be common to all SER configs I have seen to misuse
loose_route() in this way.
The realization of the fact that the presence or absence of To-tag is not
enough to decide if a request belongs to a dialog or not. The big exception
here is the ACK for negative replies. It has a To-tag but a dialog was not
established.
Changing the behaviour of loose_route() yet again
would mess up a lot of
configs as the earlier change messed up a lot of configs (it certainly
cost me a couple of hours debugging). Having another function would
probably be a better approach. Especially, since loose_route() is
actually the wrong name. The function does both loose and static record
routing.
I agree, changing the return value again would not help. The big question is
if a preloaded request should be "handled" by the loose_route function?
I guess the best solution would be to have one function preloaded() which
returns true on preloaded requests and just consumes the Route header. And if
this function returned true you could treat the request like any other
incoming request from one of your UAs without a Route header.
Then you would call loose_route() only to take care of the remaining in-dialog
request (no matter if it is loose or strict routing).
But such a seperation would mean a change in the behavior again, because
currently preloaded requests are also handled by loose_route() (it returns
true for these requests). So it would be only an option to change this in
head.
Cheers
Nils
13 Jul
13 Jul
11:38 a.m.
New subject: [Serusers] [Serdev] loose_route behaviour, detecting single Route with myself
On Thursday 12 July 2007 20:31:10 Greger V. Teigre wrote:
I vote for a new preloaded_route() in trunk. I also
suggest a new alias
for loose_route (or rename and create loose_route as backwards
compatible name): in_dialog() returning true if and only if the message
being processed is and in-dialog message.
The problem is that you simply can not provide the functions you want in a
stateless way.
An non-2xx ACK with a preloaded route looks exactly the same then a 2xx ACK. A
preloaded_route() function thus has no chance to distinguish them. And I will
not make the rr module depending on the tm module, just to query tm all the
time if it knows something about this transaction or not.
IMHO the only way to distinguish these two is the RURI. Because in a normal
loose route case the 2xx ACK should have non-local URI (the remote Contact)
as RURI. But the non-2xx ACK should have a local RURI.
But with this theory we are back to the original topic: is a TEL URI a local
URI or not.
And an in_dialog() function would not work as well. Because the To-tag is not
enough to decide wether the request belongs to an established dialog or not.
And the presence of one Route header also means nothing.
Is just came to my mind that a possible solution could be to add some kind of
secret information to our Record-Route headers. Then the criteria for
distinguishing a preloaded from an in-dialog routed request would be the
presence of this "secret" information in the Route header. And if a UA omits
this "secret" add-on from the Route header it would be guilty on its own that
its requests might be mis-routed.
Nils
12:22 p.m.
New subject: [Serusers] [Serdev] loose_route behaviour, detecting single Route with myself
Nils Ohlmeier wrote:
On Thursday 12 July 2007 20:31:10 Greger V. Teigre
wrote:
Using RURI domain wont work, e.g. A@mydomain calls B(a)iptel.org. If I
want the call from A to go to my dispatcher first, then to my proxy
cluster (e.g. for authentication and SIP Identity signing) and then to
iptel the dispatcher also needs to distinguish the
non-2xx-ACK+preloadedroute.
I vote for a new preloaded_route() in trunk. I
also suggest a new alias
for loose_route (or rename and create loose_route as backwards
compatible name): in_dialog() returning true if and only if the message
being processed is and in-dialog message.
The problem is that you simply can not provide the functions you want in a
stateless way.
An non-2xx ACK with a preloaded route looks exactly the same then a 2xx ACK. A
preloaded_route() function thus has no chance to distinguish them. And I will
not make the rr module depending on the tm module, just to query tm all the
time if it knows something about this transaction or not.
IMHO the only way to distinguish these two is the RURI. Because in a normal
loose route case the 2xx ACK should have non-local URI (the remote Contact)
as RURI. But the non-2xx ACK should have a local RURI.
But with this theory we are back to the original topic: is a TEL URI a local
URI or not. And an in_dialog() function would not work as well.
Because the To-tag is not
enough to decide wether the request belongs to an established dialog or not.
And the presence of one Route header also means nothing.
Is just came to my mind that a possible solution could be to add some kind of
secret information to our Record-Route headers. Then the criteria for
distinguishing a preloaded from an in-dialog routed request would be the
presence of this "secret" information in the Route header. And if a UA omits
this "secret" add-on from the Route header it would be guilty on its own that
its requests might be mis-routed.
I had the same idea - probably there is no other workaround.
btw: I guess there are many ser users out there which use dispatcher in
stateless mode - how do they handle this yet?
regards
klaus
2:12 p.m.
New subject: [Serusers] [Serdev] loose_route behaviour, detecting single Route with myself
Nils Ohlmeier wrote:
An non-2xx ACK with a preloaded route looks exactly the same then a 2xx ACK. A
preloaded_route() function thus has no chance to distinguish them. And I will
not make the rr module depending on the tm module, just to query tm all the
time if it knows something about this transaction or not.
IMHO the only way to distinguish these two is the RURI. Because in a normal
loose route case the 2xx ACK should have non-local URI (the remote Contact)
as RURI. But the non-2xx ACK should have a local RURI.
Indeed. But doesn't that point towards the old behaviour? Only return
true if forwarding can be done based on a Route, otherwise the script
needs to decide what to do based on the Request-URI? Apparently, having
a Route header pointing to the proxy doesn't mean a thing.
BTW: What does loose_route() do if the topmost route doesn't point to
this proxy?
But with this theory we are back to the original
topic: is a TEL URI a local
URI or not.
I though that was solved. Only SIP and SIPS URI are allowed in Contact.
Your 2xx ACK will never have a TEL URI (unless the UA is broken in which
case someone should have sent a 400 back).
Is just came to my mind that a possible solution could
be to add some kind of
secret information to our Record-Route headers.
/me not like. Sounds like magic plus vendor specific extensions are
frowned upon in SIP.
Regards,
Martin
3:19 p.m.
New subject: [Serusers] [Serdev] loose_route behaviour, detecting single Route with myself
On Friday 13 July 2007 14:12:52 Martin Hoffmann wrote:
No. That is not true. Because you could receive a non-2xx ACK with a TEL RURI
and preloaded route. What now?
Sure, they are. But I currently do not really see any option for this problem.
Except we would consider removing strict route support. Then would not have
to look at the RURI at all any more. But I'm not in favor of that.
Nils
Nils Ohlmeier wrote:
loose_route should return false for this, because the message can not be
handled/routed by simply forwarding the request. This was the thing which
Dragos complained about earlier on the mailing lists already.
I chose this return code, because otherwise people would rely on the
loose_route return value true, and forward the message without further
inspection assuming it is in-dialog. And uuuppss you have an open proxy
without knowing ;-)
An non-2xx ACK with a preloaded route looks
exactly the same then a 2xx
ACK. A preloaded_route() function thus has no chance to distinguish them.
And I will not make the rr module depending on the tm module, just to
query tm all the time if it knows something about this transaction or
not.
IMHO the only way to distinguish these two is the RURI. Because in a
normal loose route case the 2xx ACK should have non-local URI (the remote
Contact) as RURI. But the non-2xx ACK should have a local RURI.
Indeed. But doesn't that point towards the old behaviour? Only return
true if forwarding can be done based on a Route, otherwise the script
needs to decide what to do based on the Request-URI? Apparently, having
a Route header pointing to the proxy doesn't mean a thing.
BTW: What does loose_route() do if the topmost route doesn't point to
this proxy? But with this
theory we are back to the original topic: is a TEL URI a
local URI or not.
I though that was solved. Only SIP and SIPS URI are allowed in Contact.
Your 2xx ACK will never have a TEL URI (unless the UA is broken in which
case someone should have sent a 400 back). Is just came
to my mind that a possible solution could be to add some
kind of secret information to our Record-Route headers.
/me not like. Sounds like magic plus vendor specific extensions are
frowned upon in SIP.
4:08 p.m.
New subject: [Serusers] [Serdev] loose_route behaviour, detecting single Route with myself
Nils Ohlmeier wrote:
Sure, they are. But I currently do not really see any option for this problem.
Possibly, the problem is that loose_route() is trying to be smart. Maybe
it should be split in two. One function removes the topmost Route if
present and pointing to this proxy (it can return false if the Route is
all wrong and we can reply 4xx then), another one that allows to check
if there is a Route left. The rest is done in config.
Without reading 3261 again, I think this can be done in a way compatible
with strict routing.
Regards,
Martin
On Friday 13 July 2007 14:12:52 Martin Hoffmann
wrote:
No. That is not true. Because you could receive a non-2xx ACK with a TEL RURI
and preloaded route. What now?
Depends on what you do with an INVITE. Same thing shall be done to that
ACK. Which means you cannot have loose_route() decide for you.
Nils Ohlmeier wrote:
But with
this theory we are back to the original topic: is a TEL URI a
local URI or not.
I though that was solved. Only SIP and SIPS URI are allowed in Contact.
Your 2xx ACK will never have a TEL URI (unless the UA is broken in which
case someone should have sent a 400 back). Is just came to my mind that a possible solution could
be to add some
kind of secret information to our Record-Route headers.
/me not like. Sounds like magic plus vendor specific extensions are
frowned upon in SIP.
16 Jul
16 Jul
2:04 p.m.
New subject: [Serusers] [Serdev] loose_route behaviour, detecting single Route with myself
Ok, let me try to take a step back. This discussion is an example of why
ser.cfg sometimes seems like black magic for most users. It's very
complicated to get a generic config that works in most scenarios. What
we really need to make sure is that people can use the recommended black
magic in most cases, that it is intuitive how to add their own stuff,
and that we make it difficult to "break".. phew...
What would a "normal" user like to know in ser.cfg?
1. Do I need to process like an INVITE or do I t_relay?
2. How do I open or prevent relaying?
Ex. I am sure quite a lot of configs will let an INVITE with a
pre-loaded Route go through without authentication...
I still feel that preloaded_route() and in_dialog() would be simpler to
understand for most people. I agree with Martin that maybe having a
separate function checking/removing/failing a pre-loaded route is
cleaner than letting loose_route() do it.
The problem of "non-2xx ACK with a preloaded route looks exactly the
same then a 2xx ACK" is a corner-case, and I don't see any solution
either, than the suggest uri param in the rr. So, could we
automaticlly add the rr param if and only if the original INVITE is
forwarded statelessly?
The above functions could thus look for the rr param to detect the
corner-case and thus behave consistently.
g-)
Martin Hoffmann wrote:
Nils Ohlmeier wrote:
Sure, they are. But I currently do not really see any option for this
problem.
Possibly, the problem is that loose_route() is trying to be smart. Maybe
it should be split in two. One function removes the topmost Route if
present and pointing to this proxy (it can return false if the Route is
all wrong and we can reply 4xx then), another one that allows to check
if there is a Route left. The rest is done in config.
Without reading 3261 again, I think this can be done in a way compatible
with strict routing.
Regards,
Martin
On Friday 13 July 2007 14:12:52 Martin Hoffmann
wrote:
Depends on what you do with an INVITE. Same thing shall be done to that
ACK. Which means you cannot have loose_route() decide for you.
Nils Ohlmeier wrote:
No. That is not true. Because you could receive a non-2xx ACK with a TEL
RURI
and preloaded route. What now?
But with this theory we are back to the original
topic: is a TEL URI a
local URI or not.
I though that was solved. Only SIP and SIPS URI are allowed in Contact.
Your 2xx ACK will never have a TEL URI (unless the UA is broken in which
case someone should have sent a 400 back).
Is just came to my mind that a possible solution could
be to add some
kind of secret information to our Record-Route headers.
/me not like. Sounds like magic plus vendor specific extensions are
frowned upon in SIP.
4:53 p.m.
New subject: [Serusers] [Serdev] loose_route behaviour, detecting single Route with myself
On Monday 16 July 2007 14:04:31 Greger V. Teigre wrote:
Ok, let me try to take a step back. This discussion is
an example of why
ser.cfg sometimes seems like black magic for most users. It's very
complicated to get a generic config that works in most scenarios. What
we really need to make sure is that people can use the recommended black
magic in most cases, that it is intuitive how to add their own stuff,
and that we make it difficult to "break".. phew...
What would a "normal" user like to know in ser.cfg?
1. Do I need to process like an INVITE or do I t_relay?
2. How do I open or prevent relaying?
Ex. I am sure quite a lot of configs will let an INVITE with a
pre-loaded Route go through without authentication...
Which is not an issue as long as the RURI points to you. Because then you
simply route the request to yourself with no Route header any more, and then
it should be processed like a request without pre-loaded Route.
I still feel that preloaded_route() and in_dialog()
would be simpler to
understand for most people.
Just to state it clearly: the names of these two function can not be
implemented technically correct! Thus I would vote at least against the
names.
If you use has_to_tag(), fine you should know what you are doing. But
in_dialog() without being dialog statefull promisses to much.
I agree with Martin that maybe having a
separate function checking/removing/failing a pre-loaded route is
cleaner than letting loose_route() do it.
Ok. I'm still trying to evaluate if this is possible or not. See below for
more details. But we are talking here about > 2.0 any way, right?
The problem of "non-2xx ACK with a preloaded
route looks exactly the
same then a 2xx ACK" is a corner-case, and I don't see any solution
either, than the suggest uri param in the rr.
Just to make it clear to everybody: this "corner case" occurs in all setups
with a stateless load balancer and where the INVITE gets challenged!
So, could we
automaticlly add the rr param if and only if the original INVITE is
forwarded statelessly?
I don't think so, because the rr module has no idea when you call
record_route() how the request is going to be tramsitted.
I would prefer to have a general option for adding (or not adding) such a
Route cookie. The only question would be then, what should be the default
setting for this option.
The above functions could thus look for the rr param
to detect the
corner-case and thus behave consistently.
g-)
Martin Hoffmann wrote:
> Nils Ohlmeier wrote:
>> On Friday 13 July 2007 14:12:52 Martin Hoffmann wrote:
[...]
>> Sure, they are. But I currently do not really
see any option for this
>> problem.
>
> Possibly, the problem is that loose_route() is trying to be smart. Maybe
> it should be split in two. One function removes the topmost Route if
> present and pointing to this proxy (it can return false if the Route is
> all wrong and we can reply 4xx then), another one that allows to check
> if there is a Route left. The rest is done in config.
>
> Without reading 3261 again, I think this can be done in a way compatible
> with strict routing.
Yes probably it could. The only problem with this approach is that you need to
store some state between the calls of these two functions.
And I guess it should be allowed to call e.g. functions from the select
framework in between. I'm assuming for example that would simply check with
the select framework if their are still route headers present after you
called the "remove topmost route" function, to see if it is necessary to call
the second route function. This would mean that the changes of the
first "remove topmost route" function would have to be applied to the
message. And you hopefully know that this is not easily possible in SER.
Don't get me wrong. The approach sounds interesting. But currently the
implementation looks tricky to me.
Nils
17 Jul
17 Jul
1:39 p.m.
New subject: [Serusers] [Serdev] loose_route behaviour, detecting single Route with myself
Nils Ohlmeier wrote:
I assume you here implicitly mean that they cannot be implemented
technically correct for both stateful and stateless? I assumed in my
suggestion that we can make an rr param work.
Indeed.
Yes, "corner case" was maybe misphrased. My point was that it does not
occur in every setup.
Isn't uri params implemented differently in 2.0? Where the actual params
are added before relaying (based on avp)?
g-)
On Monday 16 July 2007 14:04:31 Greger V. Teigre
wrote:
Right, but I was referring to the case where the ruri does not point to
you, but (most probably) a PSTN GW.
Ok, let me try to take a step back. This
discussion is an example of why
ser.cfg sometimes seems like black magic for most users. It's very
complicated to get a generic config that works in most scenarios. What
we really need to make sure is that people can use the recommended black
magic in most cases, that it is intuitive how to add their own stuff,
and that we make it difficult to "break".. phew...
What would a "normal" user like to know in ser.cfg?
1. Do I need to process like an INVITE or do I t_relay?
2. How do I open or prevent relaying?
Ex. I am sure quite a lot of configs will let an INVITE with a
pre-loaded Route go through without authentication...
Which is not an issue as long as the RURI points to you. Because then you
simply route the request to yourself with no Route header any more, and then
it should be processed like a request without pre-loaded Route.
I still feel that preloaded_route() and
in_dialog() would be simpler to
understand for most people.
Just to state it clearly: the names of these two function can not be
implemented technically correct! Thus I would vote at least against the
names.
If you use has_to_tag(), fine you should know what you
are doing. But
in_dialog() without being dialog statefull promisses to much.
Right, so maybe in_dialog should be found in tm?
I agree with
Martin that maybe having a
separate function checking/removing/failing a pre-loaded route is
cleaner than letting loose_route() do it.
Ok. I'm still trying to evaluate if this is possible or not. See below for
more details. But we are talking here about > 2.0 any way, right?
The problem of
"non-2xx ACK with a preloaded route looks exactly the
same then a 2xx ACK" is a corner-case, and I don't see any solution
either, than the suggest uri param in the rr.
Just to make it clear to everybody: this "corner case" occurs in all setups
with a stateless load balancer and where the INVITE gets challenged!
So, could we
automaticlly add the rr param if and only if the original INVITE is
forwarded statelessly?
I don't think so, because the rr module has no idea when you call
record_route() how the request is going to be tramsitted.
12 Jul
12 Jul
9:03 a.m.
New subject: [Serusers] [Serdev] loose_route behaviour, detecting single Route with myself
Martin Hoffmann wrote:
In most cases this is what you want, because the
presence of Routes
indicates an in-dialog message which you want to treat differently (In
Here we see the root problem of the loose_route function: it's naming
and it's usage.
To identify in-dialog messages the only thing to worry about is the
to-tag. Nothing more, nothing less.
practice, most UAs just forward the message to the
outgoing proxy
without adding a Route header, which is perfectly legal as well). The
proper test for this, of course, is to check for the presence of a To
tag. But it seems to be common to all SER configs I have seen to misuse
loose_route() in this way.
Yes.
Changing the behaviour of loose_route() yet again
would mess up a lot of
configs as the earlier change messed up a lot of configs (it certainly
cost me a couple of hours debugging). Having another function would
probably be a better approach. Especially, since loose_route() is
actually the wrong name. The function does both loose and static record
routing.
I totally agree with you, e.g:
if (in_dialog()) { # probably an alias to has_totag()
process_routes(); # may have different return values
# -1: no routes found
# -2: only a single route pointing to "myself"
# 1: loose routing done
# 2: strict routing done
... NAT traversal, security checks, ....
t_relay();
exit;
}
process_routes();
# here proceed according to policy, e.g.
# -1, -2: handle now incoming request
# 1, 2: reject out-of-dialog loose/strict-route request
...
regards
klaus
Regards,
Martin
_______________________________________________
Serdev mailing list
Serdev(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serdev
12:39 p.m.
New subject: [Serusers] [Serdev] loose_route behaviour, detecting single Route with myself
On Thursday 12 July 2007 09:03:39 Klaus Darilion wrote:
No. The To-tag is not enough as criteria for in-dialog. And unfortunately the
presence of Route isn't as well.
You can basically have these type of ACKs (ACKs illustrate the worst case):
- the UAC uses an outbound proxy without a Route header
- the in-dialog ACK will have a To-tag and a Route header
- the out-of-dialog ACK will have a To-tag and no Route header
- the UAC uses a Route header for its outbound proxy
- then in-dialog ACK will have a To-tag and a Route header (same as above)
- the out-of-dialog ACK will have a To-tag and a Route header (and this is
the problematic case!)
The only thing which distinguishes the in-dialog ACKs from the last
out-of-dialog ACK might be the length of the Route header. If the Route
header has the length one it might be an out-of-dialog ACK. But in the worst
case this is equal to an in-dialog ACK with only one Route header. In this
case the only difference will be the RURI.
Martin Hoffmann wrote:
This was the assumption of the old, and it is unfortunately totaly wrong! See
below for more details.
In most cases this is what you want, because the
presence of Routes
indicates an in-dialog message which you want to treat differently (In
Here we see the root problem of the loose_route function: it's naming
and it's usage.
To identify in-dialog messages the only thing to worry about is the
to-tag. Nothing more, nothing less. practice, most
UAs just forward the message to the outgoing proxy
without adding a Route header, which is perfectly legal as well). The
proper test for this, of course, is to check for the presence of a To
tag. But it seems to be common to all SER configs I have seen to misuse
loose_route() in this way.
Yes.
Changing the behaviour of loose_route() yet again
would mess up a lot of
configs as the earlier change messed up a lot of configs (it certainly
cost me a couple of hours debugging). Having another function would
probably be a better approach. Especially, since loose_route() is
actually the wrong name. The function does both loose and static record
routing.
I totally agree with you, e.g:
if (in_dialog()) { # probably an alias to has_totag() process_routes(); # may have different return
values
# -1: no routes found
# -2: only a single route pointing to "myself"
# 1: loose routing done
# 2: strict routing done
... NAT traversal, security checks, ....
t_relay();
exit;
}
process_routes();
# here proceed according to policy, e.g.
# -1, -2: handle now incoming request
# 1, 2: reject out-of-dialog loose/strict-route request
...
Ok, what would be the difference then between this new process_routes()
function and adding more different return values to the existing
loose_route() function?
Nils
3:21 p.m.
New subject: [Serusers] [Serdev] loose_route behaviour, detecting single Route with myself
Nils Ohlmeier wrote:
Ok, what would be the difference then between this new
process_routes()
function and adding more different return values to the existing
loose_route() function?
We could change the behavior without causing problems to old config
files and we could give it a better name.
regards
klaus
3:24 p.m.
New subject: [Serusers] [Serdev] loose_route behaviour, detecting single Route with myself
Nils Ohlmeier wrote:
On Thursday 12 July 2007 09:03:39 Klaus Darilion
wrote:
No. The To-tag is not enough as criteria for in-dialog. And unfortunately the
presence of Route isn't as well.
You can basically have these type of ACKs (ACKs illustrate the worst case):
- the UAC uses an outbound proxy without a Route header
- the in-dialog ACK will have a To-tag and a Route header
- the out-of-dialog ACK will have a To-tag and no Route header
- the UAC uses a Route header for its outbound proxy
- then in-dialog ACK will have a To-tag and a Route header (same as above)
- the out-of-dialog ACK will have a To-tag and a Route header (and this is
the problematic case!)
Is it really necessary to differ this cases in ser.cfg? I usually just
t_relay() the ACKs as tm module should know if this is a 2xx ACK or a
non-2xx ACK.
If you need this information in ser.cfg, then having a function
t_is_ack_local() would be useful.
regards
klaus
Martin Hoffmann wrote:
This was the assumption of the old, and it is unfortunately totaly wrong! See
below for more details.
In most cases this is what you want, because the
presence of Routes
indicates an in-dialog message which you want to treat differently (In
Here we see
the root problem of the loose_route function: it's naming
and it's usage.
To identify in-dialog messages the only thing to worry about is the
to-tag. Nothing more, nothing less. practice,
most UAs just forward the message to the outgoing proxy
without adding a Route header, which is perfectly legal as well). The
proper test for this, of course, is to check for the presence of a To
tag. But it seems to be common to all SER configs I have seen to misuse
loose_route() in this way.
Yes.
Changing the behaviour of loose_route() yet again
would mess up a lot of
configs as the earlier change messed up a lot of configs (it certainly
cost me a couple of hours debugging). Having another function would
probably be a better approach. Especially, since loose_route() is
actually the wrong name. The function does both loose and static record
routing.
I totally agree with you, e.g:
if (in_dialog()) { # probably an alias to has_totag()
The only thing which distinguishes the in-dialog ACKs from the last
out-of-dialog ACK might be the length of the Route header. If the Route
header has the length one it might be an out-of-dialog ACK. But in the worst
case this is equal to an in-dialog ACK with only one Route header. In this
case the only difference will be the RURI.
process_routes(); # may have different return
values
# -1: no routes found
# -2: only a single route pointing to "myself"
# 1: loose routing done
# 2: strict routing done
... NAT traversal, security checks, ....
t_relay();
exit;
}
process_routes();
# here proceed according to policy, e.g.
# -1, -2: handle now incoming request
# 1, 2: reject out-of-dialog loose/strict-route request
...
Ok, what would be the difference then between this new process_routes()
function and adding more different return values to the existing
loose_route() function?
Nils
4:13 p.m.
New subject: [Serusers] [Serdev] loose_route behaviour, detecting single Route with myself
On Thursday 12 July 2007 15:24:59 Klaus Darilion wrote:
Nils Ohlmeier wrote:
I did not claimed that I want this information to be available in the config.
You suggested to export it via the return code.
But as I pointed out to Martin in the other mail, the point is that non-2xx
and 2xx ACKs should also be routed correctly in case of stateless forwarding.
So telling everybody just call t_relay() for all ACKs, it will take care of
it, is IMHO no acceptable option.
Best Regards
Nils Ohlmeier
On Thursday 12 July 2007 09:03:39 Klaus Darilion
wrote:
Is it really necessary to differ this cases in ser.cfg? I usually just
t_relay() the ACKs as tm module should know if this is a 2xx ACK or a
non-2xx ACK.
If you need this information in ser.cfg, then having a function
t_is_ack_local() would be useful. I totally agree with you, e.g:
if (in_dialog()) { # probably an alias to has_totag()
No. The To-tag is not enough as criteria for in-dialog. And unfortunately
the presence of Route isn't as well.
You can basically have these type of ACKs (ACKs illustrate the worst
case): - the UAC uses an outbound proxy without a Route header
- the in-dialog ACK will have a To-tag and a Route header
- the out-of-dialog ACK will have a To-tag and no Route header
- the UAC uses a Route header for its outbound proxy
- then in-dialog ACK will have a To-tag and a Route header (same as
above) - the out-of-dialog ACK will have a To-tag and a Route header (and
this is the problematic case!)
13 Jul
13 Jul
11:16 a.m.
New subject: [Serusers] [Serdev] loose_route behaviour, detecting single Route with myself
Nils Ohlmeier wrote:
On Thursday 12 July 2007 15:24:59 Klaus Darilion
wrote:
Is telling "If you do statefull forwarding just t_relay() the ACKs -
both, in loose_route block and after loose_route block" an acceptable
option?
klaus
Nils Ohlmeier wrote:
I did not claimed that I want this information to be available in the config.
You suggested to export it via the return code.
But as I pointed out to Martin in the other mail, the point is that non-2xx
and 2xx ACKs should also be routed correctly in case of stateless forwarding.
So telling everybody just call t_relay() for all ACKs, it will take care of
it, is IMHO no acceptable option. On Thursday 12 July 2007 09:03:39 Klaus Darilion
wrote:
Is it really necessary to differ this cases in
ser.cfg? I usually just
t_relay() the ACKs as tm module should know if this is a 2xx ACK or a
non-2xx ACK.
If you need this information in ser.cfg, then having a function
t_is_ack_local() would be useful. I totally agree with you, e.g:
if (in_dialog()) { # probably an alias to has_totag()
No. The To-tag is not enough
as criteria for in-dialog. And unfortunately
the presence of Route isn't as well.
You can basically have these type of ACKs (ACKs illustrate the worst
case): - the UAC uses an outbound proxy without a Route header
- the in-dialog ACK will have a To-tag and a Route header
- the out-of-dialog ACK will have a To-tag and no Route header
- the UAC uses a Route header for its outbound proxy
- then in-dialog ACK will have a To-tag and a Route header (same as
above) - the out-of-dialog ACK will have a To-tag and a Route header (and
this is the problematic case!)
11:43 a.m.
New subject: [Serusers] [Serdev] loose_route behaviour, detecting single Route with myself
On Friday 13 July 2007 11:16:24 Klaus Darilion wrote:
Nils Ohlmeier wrote:
Sure, for transaction statefull relaying there is no problem with this.
The problem is, that I'm also looking for a solution which works stateless (if
you run a SER without tm - e.g. a stateless load balancer).
Nils
On Thursday 12 July 2007 15:24:59 Klaus Darilion
wrote:
Is telling "If you do statefull forwarding just t_relay() the ACKs -
both, in loose_route block and after loose_route block" an acceptable
option? Is it really necessary to differ this cases in
ser.cfg? I usually just
t_relay() the ACKs as tm module should know if this is a 2xx ACK or a
non-2xx ACK.
If you need this information in ser.cfg, then having a function
t_is_ack_local() would be useful.
I did not claimed that I want this information to be available in the
config. You suggested to export it via the return code.
But as I pointed out to Martin in the other mail, the point is that
non-2xx and 2xx ACKs should also be routed correctly in case of stateless
forwarding. So telling everybody just call t_relay() for all ACKs, it
will take care of it, is IMHO no acceptable option.
12:16 p.m.
New subject: [Serusers] [Serdev] loose_route behaviour, detecting single Route with myself
Nils Ohlmeier wrote:
On Friday 13 July 2007 11:16:24 Klaus Darilion wrote:
I think now I also realized the problem that you describe. In stateless
mode the dispatcher can't distinguish between in-dialog ACK (which is
just forwarded after loose_route) and out-of-dialog+preloadedroute
(which requires dispatcher activity before forward).
What about adding a cookie to RR header to distinguish between
pre-loaded routes and learned routes?
regards
klaus
Nils Ohlmeier wrote:
Sure, for transaction statefull relaying there is no problem with this.
The problem is, that I'm also looking for a solution which works stateless (if
you run a SER without tm - e.g. a stateless load balancer). On Thursday 12 July 2007 15:24:59 Klaus Darilion
wrote:
Is telling "If you do
statefull forwarding just t_relay() the ACKs -
both, in loose_route block and after loose_route block" an acceptable
option? Is it really necessary to differ this cases in
ser.cfg? I usually just
t_relay() the ACKs as tm module should know if this is a 2xx ACK or a
non-2xx ACK.
If you need this information in ser.cfg, then having a function
t_is_ack_local() would be useful.
I did not claimed that I want this information
to be available in the
config. You suggested to export it via the return code.
But as I pointed out to Martin in the other mail, the point is that
non-2xx and 2xx ACKs should also be routed correctly in case of stateless
forwarding. So telling everybody just call t_relay() for all ACKs, it
will take care of it, is IMHO no acceptable option.
12:01 p.m.
New subject: [Serusers] [Serdev] loose_route behaviour, detecting single Route with myself
This discussion is quite interesting ...
Nils Ohlmeier wrote:
No. The To-tag is not enough as criteria for
in-dialog. And unfortunately the
presence of Route isn't as well.
You can basically have these type of ACKs (ACKs illustrate the worst case):
- the UAC uses an outbound proxy without a Route
header
(A) > - the in-dialog ACK will have a To-tag and a Route header
(B) > - the out-of-dialog ACK will have a To-tag and no Route header
- the UAC uses a Route header for its outbound proxy
(C) > - then in-dialog ACK will have a To-tag and a Route header (same
as above)
(D) > - the out-of-dialog ACK will have a To-tag and a Route header
(and this is
the problematic case!)
ACK. Lets consider the different forwarding scenarios: tm + sl
tm:
(A) loose_route=true, --> just t_relay
(B) loose_route=false, --> just t_relay (will be absorbed by tm)
(C) loose_route=true, --> just t_relay
(D) loose_route=true, --> just t_relay (will be absorbed by tm)
sl:
(A) loose_route=true, --> just forward
(B) loose_route=false, --> lookup()*, forward
(C) loose_route=true, --> just forward
(D) loose_route=true, --> lookup()**, forward
* if lookup() was done for corresponding INVITE then lookup() then it
also has do be done here. Usually lookup() is done if RURI=myself.
** if lookup() was done for corresponding INVITE then lookup() then it
also has do be done here. This scenario is more complicated - if the
proxy is just used as relay (Route=myself, RURI!=myself) then lookup()
is not necessary. If this is the authoritative proxy (Route=myself,
RURI=myself), then lookup will be performed.
I think all scenarios can be handled with current functionality,
although I would prefer the behavior suggested by JF to have
loose_route=false if there is only one route header which points to the
proxy itself because regardless if the outbound proxy is addressed
directly or with a preloaded route set it has to be routed identically.
regards
klaus
sl dispatcher
The only thing which distinguishes the in-dialog ACKs
from the last
out-of-dialog ACK might be the length of the Route header. If the Route
header has the length one it might be an out-of-dialog ACK. But in the worst
case this is equal to an in-dialog ACK with only one Route header. In this
case the only difference will be the RURI.
process_routes(); # may have different return
values
# -1: no routes found
# -2: only a single route pointing to "myself"
# 1: loose routing done
# 2: strict routing done
... NAT traversal, security checks, ....
t_relay();
exit;
}
process_routes();
# here proceed according to policy, e.g.
# -1, -2: handle now incoming request
# 1, 2: reject out-of-dialog loose/strict-route request
...
Ok, what would be the difference then between this new process_routes()
function and adding more different return values to the existing
loose_route() function?
Nils
2:28 p.m.
New subject: [Serusers] [Serdev] loose_route behaviour, detecting single Route with myself
Klaus Darilion wrote:
sl:
(A) loose_route=true, --> just forward
(B) loose_route=false, --> lookup()*, forward
(C) loose_route=true, --> just forward
(D) loose_route=true, --> lookup()**, forward
Just a quick reminder that lookup() and forward don't go together. A
stateless proxy has to make the same decision for the same message (aka
re-sent request). Since entries in usrloc expire, there is a good chance
that a resent will be send somewhere else.
Regards,
Martin
16 Jul
16 Jul
2:11 p.m.
New subject: [Serusers] [Serdev] loose_route behaviour, detecting single Route with myself
Martin Hoffmann wrote:
Klaus Darilion wrote:
What makes you think that stateless proxies have to make the same
decision for the same message? Being stateless means that there is no
information about the routing decision made in the past.
You paragraph would make sense for stateful proxies for the duration
of the transaction.
Jan.
sl:
(A) loose_route=true, --> just forward
(B) loose_route=false, --> lookup()*, forward
(C) loose_route=true, --> just forward
(D) loose_route=true, --> lookup()**, forward
Just a quick reminder that lookup() and forward don't go together. A
stateless proxy has to make the same decision for the same message (aka
re-sent request). Since entries in usrloc expire, there is a good chance
that a resent will be send somewhere else.
2:33 p.m.
New subject: [Serusers] [Serdev] loose_route behaviour, detecting single Route with myself
Jan Janak wrote:
Martin Hoffmann wrote:
RFC 3261, section 16.11:
| A stateless proxy MUST follow the request processing steps described
| in Sections 16.4 through 16.5 with the following exception:
|
| o A stateless proxy MUST choose one and only one target from the
| target set. This choice MUST only rely on fields in the
| message and time-invariant properties of the server. In
| particular, a retransmitted request MUST be forwarded to the
| same destination each time it is processed. Furthermore,
| CANCEL and non-Routed ACK requests MUST generate the same
| choice as their associated INVITE.
Klaus Darilion wrote:
What makes you think that stateless proxies have to make the same
decision for the same message? sl:
(A) loose_route=true, --> just forward
(B) loose_route=false, --> lookup()*, forward
(C) loose_route=true, --> just forward
(D) loose_route=true, --> lookup()**, forward
Just a quick reminder that lookup() and forward don't go together. A
stateless proxy has to make the same decision for the same message (aka
re-sent request). Since entries in usrloc expire, there is a good chance
that a resent will be send somewhere else. You paragraph would make sense for stateful proxies
for the duration
of the transaction.
Well, no, since a stateful proxy makes the decision only once per
transaction (it swallows re-sent messages).
Regards,
Martin
4:18 p.m.
New subject: [Serusers] [Serdev] loose_route behaviour, detecting single Route with myself
Martin Hoffmann wrote:
Jan Janak wrote:
That would mean that doing lookup() in a stateless proxy is practically
not allowed.
regards
klaus
Martin Hoffmann wrote:
RFC 3261, section 16.11:
| A stateless proxy MUST follow the request processing steps described
| in Sections 16.4 through 16.5 with the following exception:
|
| o A stateless proxy MUST choose one and only one target from the
| target set. This choice MUST only rely on fields in the
| message and time-invariant properties of the server. In
| particular, a retransmitted request MUST be forwarded to the
| same destination each time it is processed. Furthermore,
| CANCEL and non-Routed ACK requests MUST generate the same
| choice as their associated INVITE. Klaus Darilion wrote:
What makes you think that stateless
proxies have to make the same
decision for the same message? sl:
(A) loose_route=true, --> just forward
(B) loose_route=false, --> lookup()*, forward
(C) loose_route=true, --> just forward
(D) loose_route=true, --> lookup()**, forward
Just a quick reminder that
lookup() and forward don't go together. A
stateless proxy has to make the same decision for the same message (aka
re-sent request). Since entries in usrloc expire, there is a good chance
that a resent will be send somewhere else.
17 Jul
17 Jul
10:24 a.m.
New subject: [Serusers] [Serdev] loose_route behaviour, detecting single Route with myself
At 16:18 16/07/2007, Klaus Darilion wrote:
Martin Hoffmann wrote:
That's indeed what Martin suggested. The spec is vague in this, the idea in it
is that retransmissions don't get 'forked' if usrloc entry changes. That
basically means there cannot be a statelss proxy unless it never changes
its routing data :-) Sound a bit like an overstandardization to me. (I hope
I don't offend those on mailing list, who consider RFC3261 too axiomatically.)
If one had a well articulated case for stateless proxy with userloc (does anyone
have such?), I would not hesitate to do it. We have done such things in the
past, note for example that in default configuration SER's registrat is
stateless. This is tremendously important because of performance implications.
Nevertheless, if you look at the RFC3261, it actually says that the UAS
should be stateful in such case. Here we traded a minor consistency issue
against a significant performance gain. (still we preserve the 100%
bible-compliant option by the way of configuring stateful registrar script)
-jiri
--
Jiri Kuthan http://iptel.org/~jiri/
Jan Janak wrote:
That would mean that doing lookup() in a stateless proxy is practically
not allowed. Martin Hoffmann wrote:
RFC 3261, section 16.11:
| A stateless proxy MUST follow the request processing steps described
| in Sections 16.4 through 16.5 with the following exception:
|
| o A stateless proxy MUST choose one and only one target from the
| target set. This choice MUST only rely on fields in the
| message and time-invariant properties of the server. In
| particular, a retransmitted request MUST be forwarded to the
| same destination each time it is processed. Furthermore,
| CANCEL and non-Routed ACK requests MUST generate the same
| choice as their associated INVITE. Klaus Darilion wrote:
> sl:
> (A) loose_route=true, --> just forward
> (B) loose_route=false, --> lookup()*, forward
> (C) loose_route=true, --> just forward
> (D) loose_route=true, --> lookup()**, forward
Just a quick reminder that lookup() and forward don't go together. A
stateless proxy has to make the same decision for the same message (aka
re-sent request). Since entries in usrloc expire, there is a good chance
that a resent will be send somewhere else.
What makes you think that stateless
proxies have to make the same
decision for the same message?
11:24 a.m.
New subject: [Serusers] [Serdev] loose_route behaviour, detecting single Route with myself
On Tuesday 17 July 2007 10:24:56 Jiri Kuthan wrote:
At 16:18 16/07/2007, Klaus Darilion wrote:
I assume the authors were not so much concerned about adding new bindings
during a transaction, because I can not see any harm in sending an ACK or
CANCEL to a new binding which hasn't received the INVITE.
But if the binding for the original INVITE disappeared (expire, or was
removed), then a non-2xx ACK could pontentially do not reach its target
(which is not a big harm either, it just causes lots of retransmissions). But
if a CANCEL is not forwarded to its target that is not nice (allthough the
UAC would have to send a BYE anyway if it would receive a late 200 for this
INVITE, and a non-200 reply would result in retrnasmissions - see above).
But I agree that this seems to be an overspecified scenario were I would tend
to ignore the spec.
Just my 2 cents
Nils
Martin Hoffmann wrote:
That's indeed what Martin suggested. The spec is vague in this, the idea in
it is that retransmissions don't get 'forked' if usrloc entry changes. That
basically means there cannot be a statelss proxy unless it never changes
its routing data :-) Sound a bit like an overstandardization to me. (I hope
I don't offend those on mailing list, who consider RFC3261 too
axiomatically.) RFC 3261, section 16.11:
| A stateless proxy MUST follow the request processing steps
| described in Sections 16.4 through 16.5 with the following exception:
|
| o A stateless proxy MUST choose one and only one target from the
| target set. This choice MUST only rely on fields in the
| message and time-invariant properties of the server. In
| particular, a retransmitted request MUST be forwarded to the
| same destination each time it is processed. Furthermore,
| CANCEL and non-Routed ACK requests MUST generate the same
| choice as their associated INVITE.
That would mean that doing lookup() in a stateless proxy is practically
not allowed.
5:59 p.m.
New subject: [Serusers] [Serdev] loose_route behaviour, detecting single Route with myself
At 11:24 17/07/2007, Nils Ohlmeier wrote:
On Tuesday 17 July 2007 10:24:56 Jiri Kuthan wrote:
a true case indeed, still like the other not a BIG issue I think.
At 16:18 16/07/2007, Klaus Darilion wrote:
I assume the authors were not so much concerned about adding new bindings
during a transaction, because I can not see any harm in sending an ACK or
CANCEL to a new binding which hasn't received the INVITE.
But if the binding for the original INVITE disappeared (expire, or was
removed), then a non-2xx ACK could pontentially do not reach its target
(which is not a big harm either, it just causes lots of retransmissions). Martin Hoffmann wrote:
That's indeed what Martin suggested. The spec is vague in this, the idea in
it is that retransmissions don't get 'forked' if usrloc entry changes. That
basically means there cannot be a statelss proxy unless it never changes
its routing data :-) Sound a bit like an overstandardization to me. (I hope
I don't offend those on mailing list, who consider RFC3261 too
axiomatically.) RFC 3261, section 16.11:
| A stateless proxy MUST follow the request processing steps
| described in Sections 16.4 through 16.5 with the following exception:
|
| o A stateless proxy MUST choose one and only one target from the
| target set. This choice MUST only rely on fields in the
| message and time-invariant properties of the server. In
| particular, a retransmitted request MUST be forwarded to the
| same destination each time it is processed. Furthermore,
| CANCEL and non-Routed ACK requests MUST generate the same
| choice as their associated INVITE.
That would mean that doing lookup() in a stateless proxy is practically
not allowed. But
if a CANCEL is not forwarded to its target that is not nice (allthough the
UAC would have to send a BYE anyway if it would receive a late 200 for this
INVITE, and a non-200 reply would result in retrnasmissions - see above).
how likely it is that a phone being rung up is suddenly re-registered at
a different location?
perhaps we would be able to find even more cases, but without explicitely
doing that I think they would be marginal and your conclusion is notwistanding
the completeness of a marginal-error-catalogue holding right.
-jiri
But I agree that this seems to be an overspecified
scenario were I would tend
to ignore the spec.
Just my 2 cents
Nils
--
Jiri Kuthan http://iptel.org/~jiri/
6:48 p.m.
New subject: [Serusers] [Serdev] loose_route behaviour, detecting single Route with myself
Hi,
Ive seen this a few times infact. I've seen this happen when a useragent
got a new IP due to the router infront of it was rebooting every 60
second.. The call was haveing some "hickups" as the customer called
it.. every 1 min the call droped for 5 seconds.. then came up again..
-A
But
if a CANCEL is not forwarded to its target that is not nice (allthough the
UAC would have to send a BYE anyway if it would receive a late 200 for this
INVITE, and a non-200 reply would result in retrnasmissions - see above).
how likely it is that a phone being rung up is suddenly re-registered at
a different location?
7:32 p.m.
New subject: [Serusers] [Serdev] loose_route behaviour, detecting single Route with myself
At 18:48 17/07/2007, Atle Samuelsen wrote:
Hi,
Ive seen this a few times infact. I've seen this happen when a useragent
got a new IP due to the router infront of it was rebooting every 60
second.. The call was haveing some "hickups" as the customer called
it.. every 1 min the call droped for 5 seconds.. then came up again..
That sounds very realistic, still in this case I think I would be fixing
the rapidly changing IP address because that's the root problem. Established
calls would not work very well with it either and certainly many other things
break.
-jiri
But
if a CANCEL is not forwarded to its target that is not nice (allthough the
UAC would have to send a BYE anyway if it would receive a late 200 for this
INVITE, and a non-200 reply would result in retrnasmissions - see above).
how likely it is that a phone being rung up is suddenly re-registered at
a different location?
18 Jul
18 Jul
6:18 a.m.
New subject: [Serusers] [Serdev] loose_route behaviour, detecting single Route with myself
* Jiri Kuthan <jiri(a)iptel.org> [070717 19:34]:
At 18:48 17/07/2007, Atle Samuelsen wrote:
Offcource that would be the preferd way of doing it.. but it happens..
you asked how likeley it was to happen :) I've seen this more then once
infact.. so it does happen :)
tough, over to fixing or not fixing it.. In most cases, the BYE will
come true in anyways, due to that the user behind the changing ip will
most likley also hanup at sometime, and since he has\nt recived a bye..
he will send one out :)
- AtlE
Hi,
Ive seen this a few times infact. I've seen this happen when a useragent
got a new IP due to the router infront of it was rebooting every 60
second.. The call was haveing some "hickups" as the customer called
it.. every 1 min the call droped for 5 seconds.. then came up again..
That sounds very realistic, still in this case I think I would be fixing
the rapidly changing IP address because that's the root problem. Established
calls would not work very well with it either and certainly many other things
break. But
if a CANCEL is not forwarded to its target that is not nice (allthough the
UAC would have to send a BYE anyway if it would receive a late 200 for this
INVITE, and a non-200 reply would result in retrnasmissions - see above).
how likely it is that a phone being rung up is suddenly re-registered at
a different location?
17 Jul
17 Jul
7:11 p.m.
New subject: [Serusers] [Serdev] loose_route behaviour, detecting single Route with myself
Jiri Kuthan wrote:
how likely it is that a phone being rung up is
suddenly re-registered at
a different location?
perhaps we would be able to find even more cases, but without explicitely
doing that I think they would be marginal and your conclusion is notwistanding
the completeness of a marginal-error-catalogue holding right.
-jiri
Actually, in the more modern world of wi-fi phones roaming on access
points, this is becoming more and more common. It's best to probably
plan for the future when this will be more commonplace rather than just
dismiss it, as it will almost certainly come back to bite us later.
N.
7:34 p.m.
New subject: [Serusers] [Serdev] loose_route behaviour, detecting single Route with myself
At 19:11 17/07/2007, SIP wrote:
Jiri Kuthan wrote:
Well the debate is about the implication on amount of state in proxy servers.
If, using transaction state, a server keeps sending stuff to a location which
is unregistered in the meantime, that's not ideal either, is it.
My point is not denying existence of location changes, my point is that I don't
see how being trasaction-stateful makes life with it better (from which I conlude
that stateless proxy servers are perfectly legitimate, if not "just useful").
how likely it is that a phone being rung up is
suddenly re-registered at
a different location?
perhaps we would be able to find even more cases, but without explicitely
doing that I think they would be marginal and your conclusion is notwistanding
the completeness of a marginal-error-catalogue holding right.
-jiri
Actually, in the more modern world of wi-fi phones roaming on access points, this is
becoming more and more common. It's best to probably plan for the future when this
will be more commonplace rather than just dismiss it, as it will almost certainly come
back to bite us later. N.
--
Jiri Kuthan http://iptel.org/~jiri/
11:52 a.m.
New subject: [Serusers] [Serdev] loose_route behaviour, detecting single Route with myself
Jiri Kuthan wrote:
At 16:18 16/07/2007, Klaus Darilion wrote:
That's indeed what Martin suggested. The spec is vague in this, the idea in it
is that retransmissions don't get 'forked' if usrloc entry changes. That
basically means there cannot be a statelss proxy unless it never changes
its routing data :-) Sound a bit like an overstandardization to me.
I tend to disagree. This bullet effectively limits stateless proxies to
load balancers and other rather static cases. IMHO it's the authors' way
of saying "Don't do stateless proxying." Many have tryied nonetheless
and, oh wonder, many have failed. Statless proxying is broken. There is
too many tripfalls.
|
| o A stateless proxy MUST choose one and only one target from the
| target set. This choice MUST only rely on fields in the
| message and time-invariant properties of the server. In
| particular, a retransmitted request MUST be forwarded to the
| same destination each time it is processed. Furthermore,
| CANCEL and non-Routed ACK requests MUST generate the same
| choice as their associated INVITE.
That would mean that doing lookup() in a stateless proxy is practically
not allowed. (I hope
I don't offend those on mailing list, who consider RFC3261 too axiomatically.)
Well, it is not obviously broken at this point, so it shall be followed.
If one had a well articulated case for stateless proxy
with userloc (does anyone
have such?), I would not hesitate to do it. We have done such things in the
past, note for example that in default configuration SER's registrat is
stateless. This is tremendously important because of performance implications.
Nevertheless, if you look at the RFC3261, it actually says that the UAS
should be stateful in such case.
Haven't searched too thoroughly, but does it actually say somewhere
"registrar MUST be statefull".
Here we traded a minor consistency issue
against a significant performance gain.
Did you now? We've been through this, but the statelessness actually
killed my registrars quite regularly when coming under heavy load. That
got fixed (for a while, anyways) by making the registrar stateful.
The heavy part of processing a REGISTER is _not_ the transaction
handling.
Regards,
Martin
6:07 p.m.
New subject: [Serusers] [Serdev] loose_route behaviour, detecting single Route with myself
At 11:52 17/07/2007, Martin Hoffmann wrote:
My point is it actually is, because it effectively mandates state usage, wherease
there are valid scenarios which rely on the stateless mode. (not sure actually
what is the sense of defining and banning a stateless proxy in the same document :-))
Exactly my point -- overstandardized.
I would prefer not to generalize a specific error. Whereas for example
a DB architecture may overshadow transaction processing overhead,
a properly cached architecture moves the next shock space to TM.
Under abnormal situations this is the next bottleneck.
-jiri
Jiri Kuthan wrote:
Yes. (Or if you read it rigirously, it limites the use case to load-balancers
that never change the list of load-balanced servers :-)))
At 16:18 16/07/2007, Klaus Darilion wrote:
That's indeed what Martin suggested. The spec is vague in this, the idea in it
is that retransmissions don't get 'forked' if usrloc entry changes. That
basically means there cannot be a statelss proxy unless it never changes
its routing data :-) Sound a bit like an overstandardization to me.
I tend to disagree.
This bullet effectively limits stateless proxies to
load balancers and other rather static cases. |
| o A stateless proxy MUST choose one and only one target from the
| target set. This choice MUST only rely on fields in the
| message and time-invariant properties of the server. In
| particular, a retransmitted request MUST be forwarded to the
| same destination each time it is processed. Furthermore,
| CANCEL and non-Routed ACK requests MUST generate the same
| choice as their associated INVITE.
That would mean that doing lookup() in a stateless proxy is practically
not allowed. IMHO it's the authors' way
of saying "Don't do stateless proxying." Many have tryied nonetheless
and, oh wonder, many have failed. Statless proxying is broken. There is
too many tripfalls.
I agree authors said that, but I'm not sure they realized completely what
they have said and I think they went too far with it. Despite all possible
corner-cases, stateless-forwarding has been deployed and worked, paritcularly
for sake of load-balancing. I'm personally opposed against generally banning
stateless forwarding (even though it is not the mainstream case).
(I hope
I don't offend those on mailing list, who consider RFC3261 too axiomatically.)
Well, it is not obviously broken at this point, so it shall be followed. If one had a well articulated case for stateless
proxy with userloc (does anyone
have such?), I would not hesitate to do it. We have done such things in the
past, note for example that in default configuration SER's registrat is
stateless. This is tremendously important because of performance implications.
Nevertheless, if you look at the RFC3261, it actually says that the UAS
should be stateful in such case.
Haven't searched too thoroughly, but does it actually say somewhere
"registrar MUST be statefull". Here we traded
a minor consistency issue
against a significant performance gain.
Did you now? We've been through this, but the statelessness actually
killed my registrars quite regularly when coming under heavy load. That
got fixed (for a while, anyways) by making the registrar stateful.
The heavy part of processing a REGISTER is _not_ the transaction
handling.
8:27 p.m.
New subject: [Serusers] [Serdev] loose_route behaviour, detecting single Route with myself
Jiri Kuthan wrote:
Well, they didn't do that. But they very effectively limited it. On a
side note (as in SCNR): You can do load balancing without actually
having a proxy.
My point is it actually is, because it effectively mandates state usage, wherease
there are valid scenarios which rely on the stateless mode. (not sure actually
what is the sense of defining and banning a stateless proxy in the same document :-))
Again, they didn't actually bann anything. It's more that statefull
proxies a SHOULD. If you know what you are doing, you may violate it.
Exactly my point -- overstandardized.
Er, that was a question. But even so, I wouldn't call SIP
overstandardized considering the number of interoperability problems.
Maybe overengineered here and there. And in the case of INVITE
transactions, misguided.
Regards,
Martin
At 11:52 17/07/2007, Martin Hoffmann wrote:
Indeed. Although forevers are tricky beasts in the best of cases. But
even if you stick to the rest of it, the use is still limited to rather
simple proxies. Using lookup() in a stateless manner will not guarantee
that the retransmit ends up somewhere else or even gets 404ed. And that
part of the rule (don't you dare forking requests on a stateless proxy)
does make sense. I think Postel's Law is lurking in there somewhere.
> >> |
> >> | o A stateless proxy MUST choose one and only one target from the
> >> | target set. This choice MUST only rely on fields in the
> >> | message and time-invariant properties of the server. In
> >> | particular, a retransmitted request MUST be forwarded to the
> >> | same destination each time it is processed. Furthermore,
> >> | CANCEL and non-Routed ACK requests MUST generate the same
> >> | choice as their associated INVITE.
> >
This bullet effectively limits stateless proxies
to
load balancers and other rather static cases.
Yes. (Or if you read it rigirously, it limites the use case to load-balancers
that never change the list of load-balanced servers :-))) IMHO it's
the authors' way
of saying "Don't do stateless proxying." Many have tryied nonetheless
and, oh wonder, many have failed. Statless proxying is broken. There is
too many tripfalls.
I agree authors said that, but I'm not sure they realized completely what
they have said and I think they went too far with it. Despite all possible
corner-cases, stateless-forwarding has been deployed and worked, paritcularly
for sake of load-balancing. I'm personally opposed against generally banning
stateless forwarding (even though it is not the mainstream case). (I hope
I don't offend those on mailing list, who consider RFC3261 too axiomatically.)
Well, it is not obviously broken at this point, so it shall be followed. Nevertheless, if you look at the RFC3261, it actually
says that the UAS
should be stateful in such case.
Haven't searched too thoroughly, but does it actually say somewhere
"registrar MUST be statefull".
6151
days inactive
6179
days old
59 comments
12 participants
participants (12)
-
Atle Samuelsen -
Dragos Vingarzan -
Greger V. Teigre -
Greger Viken Teigre
-
Jan Janak -
JF -
Jiri Kuthan -
Klaus Darilion -
Martin Hoffmann -
Michal Matyska -
Nils Ohlmeier -
SIP