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@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@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@gmail.com:
Is this issue solved in Openser 1.1.0 ?
2006/7/7, Simon Morvan garphy@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@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@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@saabgroup.com > > > > > > _______________________________________________ > > Users mailing list > > Users@openser.org > > http://openser.org/cgi-bin/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > Users@openser.org > http://openser.org/cgi-bin/mailman/listinfo/users >
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users