[Serusers] loose_route behaviour, detecting single Route with myself

JF jfkavaka at gmail.com
Thu Jun 28 17:13:43 CEST 2007


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



More information about the sr-users mailing list