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@gmail.com Cc: serusers@iptel.org, openimscore-cscf@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@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

---

Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

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

Klaus Darilion wrote:

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.

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@iptel.org and serdev@lists.iptel.org?

On Thursday 12 July 2007 09:26:37 Martin Hoffmann wrote:

Nils Ohlmeier wrote:

...

On Wednesday 11 July 2007 21:57:15 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 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.

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?

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 Thursday 12 July 2007 12:54:58 Martin Hoffmann wrote:

Nils Ohlmeier wrote:

...

On Thursday 12 July 2007 09:26:37 Martin Hoffmann wrote:

...

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?

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

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.

Book keeping: Limited to seruser and changed subject.

I'm not sure if that was the right limitation, but anyway ;-)

Regards Nils

On Thursday 12 July 2007 13:49:45 Martin Hoffmann wrote:

Nils Ohlmeier wrote:

...

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.

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

On Monday 16 July 2007 12:06:40 Jiri Kuthan wrote:

At 09:26 12/07/2007, Martin Hoffmann wrote:

...

Nils Ohlmeier wrote:

...

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.

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

...

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")?

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

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

Nils Ohlmeier wrote:

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.

Using RURI domain wont work, e.g. A@mydomain calls B@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.

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

On Friday 13 July 2007 14:12:52 Martin Hoffmann wrote:

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?

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 ;-)

...

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

No. That is not true. Because you could receive a non-2xx ACK with a TEL RURI and preloaded route. What now?

...

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.

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

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:

...

On Friday 13 July 2007 14:12:52 Martin Hoffmann wrote:

...

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

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.

...

...

...

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.

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

Nils Ohlmeier wrote:

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.

Right, but I was referring to the case where the ruri does not point to you, but (most probably) a PSTN GW.

...

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.

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.

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?

Indeed.

...

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!

Yes, "corner case" was maybe misphrased. My point was that it does not occur in every setup.

...

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.

Isn't uri params implemented differently in 2.0? Where the actual params are added before relaying (based on avp)?

g-)

On Thursday 12 July 2007 09:03:39 Klaus Darilion wrote:

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.

This was the assumption of the old, and it is unfortunately totaly wrong! See below for more details.

...

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()

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.

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

Nils Ohlmeier wrote:

On Thursday 12 July 2007 09:03:39 Klaus Darilion wrote:

...

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.

This was the assumption of the old, and it is unfortunately totaly wrong! See below for more details.

...

...

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()

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

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

Nils Ohlmeier wrote:

On Thursday 12 July 2007 15:24:59 Klaus Darilion wrote:

...

Nils Ohlmeier wrote:

...

On Thursday 12 July 2007 09:03:39 Klaus Darilion wrote:

...

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!)

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.

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:

On Friday 13 July 2007 11:16:24 Klaus Darilion wrote:

...

Nils Ohlmeier wrote:

...

On Thursday 12 July 2007 15:24:59 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 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.

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?

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

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

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

Jan Janak wrote:

Martin Hoffmann wrote:

...

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?

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.

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

At 16:18 16/07/2007, Klaus Darilion wrote:

Martin Hoffmann wrote:

...

Jan Janak wrote:

...

Martin Hoffmann wrote:

...

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?

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.

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/

At 11:24 17/07/2007, Nils Ohlmeier wrote:

On Tuesday 17 July 2007 10:24:56 Jiri Kuthan wrote:

...

At 16:18 16/07/2007, Klaus Darilion 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.

That would mean that doing lookup() in a stateless proxy is practically not allowed.

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

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

a true case indeed, still like the other not a BIG issue I think.

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/

At 18:48 17/07/2007, Atle Samuelsen wrote:

Hi,

...

...

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?

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

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.

Jiri Kuthan wrote:

At 16:18 16/07/2007, Klaus Darilion wrote:

...

...

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

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.

(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

Jiri Kuthan wrote:

At 11:52 17/07/2007, Martin Hoffmann wrote:

...

...

...

...

| | 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 :-)))

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.

...

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

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.

...

...

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

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.

...

...

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

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