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

[JF]

Right. No tel URI Contacts. Contacts use only SIP or SIPS URIs.

JF

On 7/11/07, Nils Ohlmeier <nils at 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 at 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 at 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 at 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 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-)
>
>
>