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:[EMAIL PROTECTED] Skickat: den 31 juli 2006 09:36
 Till: Simon Morvan
 Kopia: Kerker Staffan; [email protected]
 Ä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 <[EMAIL PROTECTED]>:
 >> 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 <[EMAIL PROTECTED]>:
 >> > Is this issue solved in Openser 1.1.0 ?
 >> >
 >> > 2006/7/7, Simon Morvan <[EMAIL PROTECTED]>:
 >> > > 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 <[EMAIL PROTECTED]>:
>> > > > 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:[EMAIL PROTECTED]:5060;maddr=172.
 >> 28.248.66;transport=udp;lr>
 >>
 >> > > > > ---
 >> > > > >
 >> > > > > the ACK i sent look like this:
 >> > > > >
 >> > > > > ---
>> > > > > Request-Line: ACK sip:[EMAIL PROTECTED];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:[EMAIL PROTECTED]:5060;ma ddr= >> 172.28.248.66;transport=udp;lr>
 >> > > > >       From: "Snom 2652" <sip:[EMAIL PROTECTED]>;tag=li9buf1i4p
 >> > > > >       To: <sip:[EMAIL PROTECTED]>;tag=hvseiz7kgb
 >> > > > >       Call-ID: [EMAIL PROTECTED]
 >> > > > >       CSeq: 1 ACK
 >> > > > >       Max-Forwards: 70
 >> > > > >       Contact: <sip:[EMAIL PROTECTED]: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. [EMAIL PROTECTED]
 >> > > > >
 >> > > > >
 >> > > > > _______________________________________________
 >> > > > > Users mailing list
 >> > > > > [email protected]
 >> > > > > http://openser.org/cgi-bin/mailman/listinfo/users
 >> > > >
 >> > > >
 >> > > > _______________________________________________
 >> > > > Users mailing list
 >> > > > [email protected]
 >> > > > http://openser.org/cgi-bin/mailman/listinfo/users
 >> > > >
 >> > >
 >> >
 >>

_______________________________________________
Users mailing list
[email protected]
http://openser.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[email protected]
http://openser.org/cgi-bin/mailman/listinfo/users

Reply via email to