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

JF jfkavaka at gmail.com
Tue Jul 17 13:22:04 CEST 2007


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 at iptel.org> wrote:
> 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
> _______________________________________________
> Serdev mailing list
> Serdev at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serdev
>



More information about the sr-users mailing list