[Serusers] [Serdev] loose_route behaviour, detecting single?Route with myself

Jiri Kuthan jiri at iptel.org
Mon Jul 16 12:06:40 CEST 2007


At 09:26 12/07/2007, 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.

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

Thanks a lot!

-jiri




--
Jiri Kuthan            http://iptel.org/~jiri/




More information about the sr-users mailing list