16 Aug
2006
16 Aug
'06
4:09 p.m.
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@pernau.at]
Skickat: den 31 juli 2006 09:36
Till: Simon Morvan
Kopia: Kerker Staffan; users(a)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:
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
modified file : modules/rr/loose.c
2006/7/28, Simon Morvan <garphy(a)gmail.com>om>:
> 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(a)gmail.com>om>:
> > Is this issue solved in Openser 1.1.0 ?
> >
> > 2006/7/7, Simon Morvan <garphy(a)gmail.com>om>:
> > > 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(a)pernau.at>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@iptel1.ipatl.se:5060;maddr=172.
> 28.248.66;transport=udp;lr>
>
> > > > > ---
> > > > >
> > > > > the ACK i sent look like this:
> > > > >
> > > > > ---
> > > > > Request-Line: ACK
sip:2307@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@iptel1.ipatl.se:5060;ma
ddr=
> 172.28.248.66;transport=udp;lr>
> > > > > From: "Snom 2652"
<sip:2652@ipatl.se>;tag=li9buf1i4p
> > > > > To: <sip:2307@ipatl.se>;tag=hvseiz7kgb
> > > > > Call-ID: 3c269d83900b-xj3ild14y880@snom360
> > > > > CSeq: 1 ACK
> > > > > Max-Forwards: 70
> > > > > Contact: <sip:2652@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(a)saabgroup.com
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Users mailing list
> > > > > Users(a)openser.org
> > > > > http://openser.org/cgi-bin/mailman/listinfo/users
> > > >
> > > >
> > > > _______________________________________________
> > > > Users mailing list
> > > > Users(a)openser.org
> > > > http://openser.org/cgi-bin/mailman/listinfo/users
> > > >
> > >
> >
>