it makes sense, we will analyze the implications and include it on the to-do list. Cheers, Daniel

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: _______________________________________________ Users mailing list Users(a)openser.org http://openser.org/cgi-bin/mailman/listinfo/users

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

return RR_ERROR; } }else{ if (set_dst_uri(_m, uri) < 0) { LOG(L_ERR, "after_loose: Error while

return RR_ERROR; }

Is this issue solved in Openser 1.1.0 ? 2006/7/7, Simon Morvan &lt;garphy(a)gmail.com&gt;om>:

modified file : modules/rr/loose.c 2006/7/28, Simon Morvan &lt;garphy(a)gmail.com&gt;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 &lt;garphy(a)gmail.com&gt;om>: > > Is this issue solved in Openser 1.1.0 ? > > > > 2006/7/7, Simon Morvan &lt;garphy(a)gmail.com&gt;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 &lt;klaus.mailinglists(a)pernau.at&gt;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;maddr= > 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 > > > > > > > > > >