[Users] Route-header DNS lookup?

[Simon Morvan]

Is this issue solved in Openser 1.1.0 ?

2006/7/7, Simon Morvan <garphy at gmail.com>:
> As Daniel said on the ml thread :
> > it makes sense, we will analyze the implications and include it on the
> > to-do list.
> >
> > Cheers,
> > Daniel
> Has it been included in the developpement branch yet ?
>
> --
> Simon.
>
> 2006/7/7, Klaus Darilion <klaus.mailinglists at pernau.at>:
> > I'm not sure about the maddr parameter. doesn't it mean that the request
> > should be forwarded to this IP regardsless of the domain? If yes, the
> > DNS lookup can be skipped.
> >
> > regards
> > klaus
> >
> > Kerker Staffan wrote:
> > > hi
> > > i recently bounced into this problem, and i'm not sure here.
> > > i'm running the openser-devel, with the cacheless db_mode=3. (works fine btw)
> > >
> > > the record-route header received by the proxy on the other side (SNOM4S), inserts
> > > the domain name (iptel1.ipatl.se) and not the hostname (sip.iptel1.ipatl.se) in the
> > > record-route header, and uses the maddr=<ip_of_server> with the actual server IP address.
> > >
> > > now, when my client (behind the OpenSER) replies with an ACK to the incomming OK,
> > > it uses the Route-header recieved in the RR-header, and sends the ACK to OpenSER. i
> > > then get the following errors in OpenSER.
> > >
> > > ---
> > > /usr/local/sbin/openser[3583]: ERROR: mk_proxy: could not resolve hostname: "iptel1.ipatl.se"
> > > /usr/local/sbin/openser[3583]: ERROR: uri2proxy: bad host name in URI <sip:4ffec4ce755c218a72228c6643cb3b6b at iptel1.ipatl.se:5060;maddr=172.28.248.66;transport=udp;lr>
> > > ---
> > >
> > > the ACK i sent look like this:
> > >
> > > ---
> > > Request-Line: ACK sip:2307 at iptel1.ipatl.se;gruu=6fg9n6dl SIP/2.0
> > >       Via: SIP/2.0/UDP 172.28.248.52:2051;branch=z9hG4bK-d96b1fvapkyn;rport
> > >       Route: <sip:172.28.248.10;lr=on;ftag=li9buf1i4p>
> > >       Route: <sip:4ffec4ce755c218a72228c6643cb3b6b at iptel1.ipatl.se:5060;maddr=                172.28.248.66;transport=udp;lr>
> > >       From: "Snom 2652" <sip:2652 at ipatl.se>;tag=li9buf1i4p
> > >       To: <sip:2307 at ipatl.se>;tag=hvseiz7kgb
> > >       Call-ID: 3c269d83900b-xj3ild14y880 at snom360
> > >       CSeq: 1 ACK
> > >       Max-Forwards: 70
> > >       Contact: <sip:2652 at 172.28.248.52:2051;line=cp4a7ljd>
> > >       Content-Length: 0
> > > ---
> > >
> > > as far as i understand, according the rfc 3263, the route-header may contain domain name that
> > > has to be resolved using SRV.
> > >
> > > ---
> > > "6 Constructing SIP URIs
> > >
> > >    In many cases, an element needs to construct a SIP URI for inclusion
> > >    in a Contact header in a REGISTER, or in a Record-Route header in an
> > >    INVITE.  According to RFC 3261 [1], these URIs have to have the
> > >    property that they resolve to the specific element that inserted
> > >    them.  However, if they are constructed with just an IP address, for
> > >    example:
> > >
> > >    sip:1.2.3.4
> > >
> > >    then should the element fail, there is no way to route the request or
> > >    response through a backup.
> > >
> > >    SRV provides a way to fix this.  Instead of using an IP address, a
> > >    domain name that resolves to an SRV record can be used:
> > >
> > >    sip:server23.provider.com"
> > > ---
> > >
> > > now, OpenSER only asks DNS for an A record of the name recieved in the route header,
> > > and since that's a domain name, it's unresolvable, and so the ACK is never sent.
> > >
> > > any hints or clues?
> > >
> > > best regards,
> > > /Staffan Kerker
> > >
> > >
> > > --
> > > Staffan Kerker
> > > Saab Communications, Växjö
> > > p. +46 470 42185
> > > c. +46 705 391365
> > > m. staffan.kerker at saabgroup.com
> > >
> > >
> > > _______________________________________________
> > > Users mailing list
> > > Users at openser.org
> > > http://openser.org/cgi-bin/mailman/listinfo/users
> >
> >
> > _______________________________________________
> > Users mailing list
> > Users at openser.org
> > http://openser.org/cgi-bin/mailman/listinfo/users
> >
>