SV: [Users] Route-header DNS lookup?
Daniel-Constantin Mierla
daniel at voice-system.ro
Wed Aug 16 16:09:41 CEST 2006
Hello,
On 08/16/06 16:26, Kerker Staffan wrote:
> hi
> is this issue (maddr=) fixed in the 1.1.0 release?
>
no, it is only in the CVS head. However, this is not a big difference
between current CVS head and 1.1.0, so you should be able to backport it
very easy.
> do you know if the db_mode=3 is in the 1.1.0 release?
>
yes, this is in 1.1.0.
Cheers,
Daniel
> best regards,
> /staffan
>
>
>> -----Ursprungligt meddelande-----
>> Från: Klaus Darilion [mailto:klaus.mailinglists at pernau.at]
>> Skickat: den 31 juli 2006 09:36
>> Till: Simon Morvan
>> Kopia: Kerker Staffan; users at openser.org
>> Ämne: Re: [Users] Route-header DNS lookup?
>>
>> Hi Simon!
>>
>> Please make a unified diff (cvs diff -u) and post it at the
>> bugtracker on sourceforge:
>> http://sourceforge.net/tracker/?group_id=139143&atid=743022
>>
>> This way it can't get lost under thousands of emails.
>>
>> regards
>> klaus
>>
>> Simon Morvan wrote:
>> > modified file : modules/rr/loose.c
>> >
>> > 2006/7/28, Simon Morvan <garphy at gmail.com>:
>> >> after a quick check, the answer is : no
>> >>
>> >> this is a quick hack i've made as a workaround. feedback
>> welcome :)
>> >>
>> >> 781,783c781,803
>> >> < if (set_dst_uri(_m, uri) < 0) {
>> >> < LOG(L_ERR, "after_loose: Error
>> while setting
>> >> dst_uri\n");
>> >> < return RR_ERROR;
>> >> ---
>> >> > if( puri.maddr.s != NULL ){
>> >> > str builturistr;
>> >> > char builturi[150];
>> >> >
>> >> > memcpy( builturi, "sip:", 4 );
>> >> > memcpy( builturi+4, puri.maddr.s+6,
>> >> puri.maddr.len-6 );
>> >> > builturi[4+puri.maddr.len-6] ='\0';
>> >> >
>> >> > LOG( L_ERR, "MaddrURI is %p\n",
>> builturi );
>> >> >
>> >> > builturistr.s = builturi;
>> >> > builturistr.len = 4+puri.maddr.len-6;
>> >> >
>> >> > if (set_dst_uri(_m, &builturistr) < 0) {
>> >> > LOG(L_ERR, "after_loose:
>> Error while
>> >> setting dst_uri\n");
>> >> > return RR_ERROR;
>> >> > }
>> >> >
>> >> > }else{
>> >> > if (set_dst_uri(_m, uri) < 0) {
>> >> > LOG(L_ERR, "after_loose:
>> Error while
>> >> setting dst_uri\n");
>> >> > return RR_ERROR;
>> >> > }
>> >>
>> >>
>> >> 2006/7/28, Simon Morvan <garphy at gmail.com>:
>> >> > 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;ma
>> ddr=
>> >> 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
>> >> > > >
>> >> > >
>> >> >
>> >>
>>
>>
>>
>
> _______________________________________________
> Users mailing list
> Users at openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users
>
>
More information about the sr-users
mailing list