Re: [OpenSIPS-Users] Unsuccessfull upgrade from 1.4.5 to 1.6.1 (RR module)

2010-01-25 Thread Bogdan-Andrei Iancu
Yes, with 1.4 works because that version does not load the content of 
domain table to use it for "is the address pointing to me?" test.

Regards,
Bogdan

Oleg Burlacu wrote:
> Thank you Bogdan!
> The GW IP was in the "domain" table. Once deleted - all is ok.
> Interesting fact - the OpenSips 1.4 works ok even the gw ip is in the 
> domain table.
>  
> Best regards,
> Oleg Burlacu 
>
> On Fri, Jan 22, 2010 at 7:06 PM, Bogdan-Andrei Iancu 
> mailto:bog...@voice-system.ro>> wrote:
>
> Hi Oleg,
>
> The problem seams to be around the loose_route() part -> after the
> loose_route, the ACK is not sent to the GW, but it loop on the proxy.
> That is a typically behaviour when you misconfigure opensips and
> opensips believes that the GW IP is one of its own IPs.
>
> Is the GW IP added as "alias" in the script? or in the "domain" table?
>
> Regards,
> Bogdan
>
> Oleg Burlacu wrote:
> >
> >
> > Hi,
> > I'm running a statefull proxy that in most cases need to relay the
> > calls to a PSTN gateway.
> > After the migration to the Opensips 1.6.1, there is a problem with
> > compatibility / RR module and the gateway (Cisco AS5300).
> > Opensips does not relay 'correctly' (in my case) the ACK
> messages. The
> > Cisco gateway do not receive ACKs and hangup the call after a
> timeout.
> > The configuration script is developed on the sipwise template,
> but it
> > works perfectly in 1.4 version of Opensips.
> >
> > When debugging I see each time more and more headers in ACK packets
> > Record-Route: 
> > Record-Route: 
> > Record-Route: 
> > Record-Route: 
> > Via: SIP/2.0/UDP xx.yy.56.226;branch=z9hG4bKa636.94cf333.2
> > Via: SIP/2.0/UDP xx.yy.56.226;branch=z9hG4bKa636.94cf333.2
> > Via: SIP/2.0/UDP xx.yy.56.226;branch=z9hG4bKa636.94cf333.2
> > Via: SIP/2.0/UDP xx.yy.56.226;branch=z9hG4bKa636.94cf333.2
> > Via: SIP/2.0/UDP
> > xx.yy.17.20;branch=z9hG4bK591c111423e34b43aea64e671405
> >
> > When disabling the record_route(), and messages go from sip client
> > directly to the gateway - all in ok.
> > When communicating between 2 sip clients on the same proxy - the
> > messages are relayed correctly.
> > What can be the solution?
> >
> >
> > The entire message log:
> >
> > U xx.yy.17.20:5060 -> xx.yy.56.226:5060
> > INVITE sip:987...@xx.yy.56.226 SIP/2.0.
> > Via: SIP/2.0/UDP
> > xx.yy.17.20;branch=z9hG4bK591c111426464b44616423ea16ed.
> > From: "unknown" ;tag=152937654c2b.
> > To: .
> > Contact: .
> > Call-ID: D17BF0696DC546A7B436401CD27774720x591c1114.
> > CSeq: 1 INVITE.
> > Max-Forwards: 70.
> > User-Agent: SJphone/1.65.377a (SJ Labs).
> >
> >
> > U xx.yy.56.226:5060 -> xx.yy.17.20:5060
> > SIP/2.0 100 Trying.
> > Via: SIP/2.0/UDP
> > xx.yy.17.20;branch=z9hG4bK591c111426464b44616423ea16ed.
> > From: "unknown" ;tag=152937654c2b.
> > To: .
> > Call-ID: D17BF0696DC546A7B436401CD27774720x591c1114.
> > CSeq: 1 INVITE.
> >
> >
> >
> > U xx.yy.56.226:5060 -> xx.yy.17.20:5060
> > SIP/2.0 407 Proxy Authentication Required.
> > Via: SIP/2.0/UDP
> > xx.yy.17.20;branch=z9hG4bK591c111426464b44616423ea16ed.
> > From: "unknown" ;tag=152937654c2b.
> > To:
> ;tag=c97b4d1cb1f3d0da549e06a8d482ef63.8548.
> > Call-ID: D17BF0696DC546A7B436401CD27774720x591c1114.
> > CSeq: 1 INVITE.
> >
> >
> >
> > U xx.yy.17.20:5060 -> xx.yy.56.226:5060
> > ACK sip:987...@xx.yy.56.226 SIP/2.0.
> > Via: SIP/2.0/UDP
> > xx.yy.17.20;branch=z9hG4bK591c111426464b44616423ea16ed.
> > From: "unknown" ;tag=152937654c2b.
> > To:
> ;tag=c97b4d1cb1f3d0da549e06a8d482ef63.8548.
> > Call-ID: D17BF0696DC546A7B436401CD27774720x591c1114.
> > CSeq: 1 ACK.
> > Max-Forwards: 70.
> > User-Agent: SJphone/1.65.377a (SJ Labs).
> > Content-Length: 0.
> >
> >
> >
> > U xx.yy.17.20:5060 -> xx.yy.56.226:5060
> > INVITE sip:987...@xx.yy.56.226 SIP/2.0.
> > Via: SIP/2.0/UDP
> > xx.yy.17.20;branch=z9hG4bK591c111426474b446164164716f0.
> > From: "unknown" ;tag=152937654c2b.
> > To: .
> > Contact: .
> > Call-ID: D17BF0696DC546A7B436401CD27774720x591c1114.
> > CSeq: 2 INVITE.
> > Max-Forwards: 70.
> > User-Agent: SJphone/1.65.377a (SJ Labs).
> > Content-Length: 362.
> > Content-Type: application/sdp.
> > Supported: replaces,norefersub,timer.
> > Proxy-Authorization: Digest
> >
> 
> username="123456",realm="xx.yy.56.226",nonce="4b43ec22000883661dbea2617b91d28401983dd85b7d",uri="sip:987...@xx.yy.56.226",response="91a62cf62af7870c1e24d6c35857e78d".
> >
> >
> >
> > U xx.yy.56.226:5060 -> xx.yy.17.20:5060
> > SIP/2.0 100 Trying.
> > Via: SIP/2.0/UDP
> > xx

Re: [OpenSIPS-Users] Unsuccessfull upgrade from 1.4.5 to 1.6.1 (RR module)

2010-01-23 Thread Oleg Burlacu
Thank you Bogdan!
The GW IP was in the "domain" table. Once deleted - all is ok.
Interesting fact - the OpenSips 1.4 works ok even the gw ip is in the domain
table.

Best regards,
Oleg Burlacu

On Fri, Jan 22, 2010 at 7:06 PM, Bogdan-Andrei Iancu  wrote:

> Hi Oleg,
>
> The problem seams to be around the loose_route() part -> after the
> loose_route, the ACK is not sent to the GW, but it loop on the proxy.
> That is a typically behaviour when you misconfigure opensips and
> opensips believes that the GW IP is one of its own IPs.
>
> Is the GW IP added as "alias" in the script? or in the "domain" table?
>
> Regards,
> Bogdan
>
> Oleg Burlacu wrote:
> >
> >
> > Hi,
> > I'm running a statefull proxy that in most cases need to relay the
> > calls to a PSTN gateway.
> > After the migration to the Opensips 1.6.1, there is a problem with
> > compatibility / RR module and the gateway (Cisco AS5300).
> > Opensips does not relay 'correctly' (in my case) the ACK messages. The
> > Cisco gateway do not receive ACKs and hangup the call after a timeout.
> > The configuration script is developed on the sipwise template, but it
> > works perfectly in 1.4 version of Opensips.
> >
> > When debugging I see each time more and more headers in ACK packets
> > Record-Route: 
> > Record-Route: 
> > Record-Route: 
> > Record-Route: 
> > Via: SIP/2.0/UDP xx.yy.56.226;branch=z9hG4bKa636.94cf333.2
> > Via: SIP/2.0/UDP xx.yy.56.226;branch=z9hG4bKa636.94cf333.2
> > Via: SIP/2.0/UDP xx.yy.56.226;branch=z9hG4bKa636.94cf333.2
> > Via: SIP/2.0/UDP xx.yy.56.226;branch=z9hG4bKa636.94cf333.2
> > Via: SIP/2.0/UDP
> > xx.yy.17.20;branch=z9hG4bK591c111423e34b43aea64e671405
> >
> > When disabling the record_route(), and messages go from sip client
> > directly to the gateway - all in ok.
> > When communicating between 2 sip clients on the same proxy - the
> > messages are relayed correctly.
> > What can be the solution?
> >
> >
> > The entire message log:
> >
> > U xx.yy.17.20:5060 -> xx.yy.56.226:5060
> > INVITE sip:987...@xx.yy.56.226 SIP/2.0.
> > Via: SIP/2.0/UDP
> > xx.yy.17.20;branch=z9hG4bK591c111426464b44616423ea16ed.
> > From: "unknown" ;tag=152937654c2b.
> > To: .
> > Contact: .
> > Call-ID: D17BF0696DC546A7B436401CD27774720x591c1114.
> > CSeq: 1 INVITE.
> > Max-Forwards: 70.
> > User-Agent: SJphone/1.65.377a (SJ Labs).
> >
> >
> > U xx.yy.56.226:5060 -> xx.yy.17.20:5060
> > SIP/2.0 100 Trying.
> > Via: SIP/2.0/UDP
> > xx.yy.17.20;branch=z9hG4bK591c111426464b44616423ea16ed.
> > From: "unknown" ;tag=152937654c2b.
> > To: .
> > Call-ID: D17BF0696DC546A7B436401CD27774720x591c1114.
> > CSeq: 1 INVITE.
> >
> >
> >
> > U xx.yy.56.226:5060 -> xx.yy.17.20:5060
> > SIP/2.0 407 Proxy Authentication Required.
> > Via: SIP/2.0/UDP
> > xx.yy.17.20;branch=z9hG4bK591c111426464b44616423ea16ed.
> > From: "unknown" ;tag=152937654c2b.
> > To: ;tag=c97b4d1cb1f3d0da549e06a8d482ef63.8548.
> > Call-ID: D17BF0696DC546A7B436401CD27774720x591c1114.
> > CSeq: 1 INVITE.
> >
> >
> >
> > U xx.yy.17.20:5060 -> xx.yy.56.226:5060
> > ACK sip:987...@xx.yy.56.226 SIP/2.0.
> > Via: SIP/2.0/UDP
> > xx.yy.17.20;branch=z9hG4bK591c111426464b44616423ea16ed.
> > From: "unknown" ;tag=152937654c2b.
> > To: ;tag=c97b4d1cb1f3d0da549e06a8d482ef63.8548.
> > Call-ID: D17BF0696DC546A7B436401CD27774720x591c1114.
> > CSeq: 1 ACK.
> > Max-Forwards: 70.
> > User-Agent: SJphone/1.65.377a (SJ Labs).
> > Content-Length: 0.
> >
> >
> >
> > U xx.yy.17.20:5060 -> xx.yy.56.226:5060
> > INVITE sip:987...@xx.yy.56.226 SIP/2.0.
> > Via: SIP/2.0/UDP
> > xx.yy.17.20;branch=z9hG4bK591c111426474b446164164716f0.
> > From: "unknown" ;tag=152937654c2b.
> > To: .
> > Contact: .
> > Call-ID: D17BF0696DC546A7B436401CD27774720x591c1114.
> > CSeq: 2 INVITE.
> > Max-Forwards: 70.
> > User-Agent: SJphone/1.65.377a (SJ Labs).
> > Content-Length: 362.
> > Content-Type: application/sdp.
> > Supported: replaces,norefersub,timer.
> > Proxy-Authorization: Digest
> >
> username="123456",realm="xx.yy.56.226",nonce="4b43ec22000883661dbea2617b91d28401983dd85b7d",uri="sip:987...@xx.yy.56.226
> ",response="91a62cf62af7870c1e24d6c35857e78d".
> >
> >
> >
> > U xx.yy.56.226:5060 -> xx.yy.17.20:5060
> > SIP/2.0 100 Trying.
> > Via: SIP/2.0/UDP
> > xx.yy.17.20;branch=z9hG4bK591c111426474b446164164716f0.
> > From: "unknown" ;tag=152937654c2b.
> > To: .
> > Call-ID: D17BF0696DC546A7B436401CD27774720x591c1114.
> > CSeq: 2 INVITE.
> > Server: OpenSIPS (1.6.1-notls (x86_64/linux)).
> > Content-Length: 0.
> >
> >
> > U xx.yy.56.226:5060 -> xx.yy.17.20:5060
> > SIP/2.0 100 Giving a try.
> > Via: SIP/2.0/UDP
> > xx.yy.17.20;branch=z9hG4bK591c111426474b446164164716f0.
> > From: "unknown" ;tag=152937654c2b.
> > To: .
> > Call-ID: D17BF0696DC546A7B436401CD27774720x591c1114.
> > CSeq: 2 INVITE.
> >
> >
> > U xx.yy.56.226:5060 -> xx.yy.25.114:5060
> > INVITE sip:987...@xx.yy.25.114:5060;transport=udp SIP/2.0.
> > Record-Route:
> .
> > Via: SIP/2.

Re: [OpenSIPS-Users] Unsuccessfull upgrade from 1.4.5 to 1.6.1 (RR module)

2010-01-22 Thread Bogdan-Andrei Iancu
Hi Oleg,

The problem seams to be around the loose_route() part -> after the 
loose_route, the ACK is not sent to the GW, but it loop on the proxy. 
That is a typically behaviour when you misconfigure opensips and 
opensips believes that the GW IP is one of its own IPs.

Is the GW IP added as "alias" in the script? or in the "domain" table?

Regards,
Bogdan

Oleg Burlacu wrote:
>
>
> Hi, 
> I'm running a statefull proxy that in most cases need to relay the 
> calls to a PSTN gateway.
> After the migration to the Opensips 1.6.1, there is a problem with 
> compatibility / RR module and the gateway (Cisco AS5300).
> Opensips does not relay 'correctly' (in my case) the ACK messages. The 
> Cisco gateway do not receive ACKs and hangup the call after a timeout.
> The configuration script is developed on the sipwise template, but it 
> works perfectly in 1.4 version of Opensips.
>
> When debugging I see each time more and more headers in ACK packets
> Record-Route: 
> Record-Route: 
> Record-Route: 
> Record-Route: 
> Via: SIP/2.0/UDP xx.yy.56.226;branch=z9hG4bKa636.94cf333.2
> Via: SIP/2.0/UDP xx.yy.56.226;branch=z9hG4bKa636.94cf333.2
> Via: SIP/2.0/UDP xx.yy.56.226;branch=z9hG4bKa636.94cf333.2
> Via: SIP/2.0/UDP xx.yy.56.226;branch=z9hG4bKa636.94cf333.2
> Via: SIP/2.0/UDP 
> xx.yy.17.20;branch=z9hG4bK591c111423e34b43aea64e671405
>
> When disabling the record_route(), and messages go from sip client 
> directly to the gateway - all in ok.
> When communicating between 2 sip clients on the same proxy - the 
> messages are relayed correctly.
> What can be the solution?
>
>
> The entire message log:
>
> U xx.yy.17.20:5060 -> xx.yy.56.226:5060
> INVITE sip:987...@xx.yy.56.226 SIP/2.0.
> Via: SIP/2.0/UDP 
> xx.yy.17.20;branch=z9hG4bK591c111426464b44616423ea16ed.
> From: "unknown" ;tag=152937654c2b.
> To: .
> Contact: .
> Call-ID: D17BF0696DC546A7B436401CD27774720x591c1114.
> CSeq: 1 INVITE.
> Max-Forwards: 70.
> User-Agent: SJphone/1.65.377a (SJ Labs).
>
>
> U xx.yy.56.226:5060 -> xx.yy.17.20:5060
> SIP/2.0 100 Trying.
> Via: SIP/2.0/UDP 
> xx.yy.17.20;branch=z9hG4bK591c111426464b44616423ea16ed.
> From: "unknown" ;tag=152937654c2b.
> To: .
> Call-ID: D17BF0696DC546A7B436401CD27774720x591c1114.
> CSeq: 1 INVITE.
>  
>
>
> U xx.yy.56.226:5060 -> xx.yy.17.20:5060
> SIP/2.0 407 Proxy Authentication Required.
> Via: SIP/2.0/UDP 
> xx.yy.17.20;branch=z9hG4bK591c111426464b44616423ea16ed.
> From: "unknown" ;tag=152937654c2b.
> To: ;tag=c97b4d1cb1f3d0da549e06a8d482ef63.8548.
> Call-ID: D17BF0696DC546A7B436401CD27774720x591c1114.
> CSeq: 1 INVITE.
>  
>
>
> U xx.yy.17.20:5060 -> xx.yy.56.226:5060
> ACK sip:987...@xx.yy.56.226 SIP/2.0.
> Via: SIP/2.0/UDP 
> xx.yy.17.20;branch=z9hG4bK591c111426464b44616423ea16ed.
> From: "unknown" ;tag=152937654c2b.
> To: ;tag=c97b4d1cb1f3d0da549e06a8d482ef63.8548.
> Call-ID: D17BF0696DC546A7B436401CD27774720x591c1114.
> CSeq: 1 ACK.
> Max-Forwards: 70.
> User-Agent: SJphone/1.65.377a (SJ Labs).
> Content-Length: 0.
>
>
>
> U xx.yy.17.20:5060 -> xx.yy.56.226:5060
> INVITE sip:987...@xx.yy.56.226 SIP/2.0.
> Via: SIP/2.0/UDP 
> xx.yy.17.20;branch=z9hG4bK591c111426474b446164164716f0.
> From: "unknown" ;tag=152937654c2b.
> To: .
> Contact: .
> Call-ID: D17BF0696DC546A7B436401CD27774720x591c1114.
> CSeq: 2 INVITE.
> Max-Forwards: 70.
> User-Agent: SJphone/1.65.377a (SJ Labs).
> Content-Length: 362.
> Content-Type: application/sdp.
> Supported: replaces,norefersub,timer.
> Proxy-Authorization: Digest 
> username="123456",realm="xx.yy.56.226",nonce="4b43ec22000883661dbea2617b91d28401983dd85b7d",uri="sip:987...@xx.yy.56.226",response="91a62cf62af7870c1e24d6c35857e78d".
>
>
>
> U xx.yy.56.226:5060 -> xx.yy.17.20:5060
> SIP/2.0 100 Trying.
> Via: SIP/2.0/UDP 
> xx.yy.17.20;branch=z9hG4bK591c111426474b446164164716f0.
> From: "unknown" ;tag=152937654c2b.
> To: .
> Call-ID: D17BF0696DC546A7B436401CD27774720x591c1114.
> CSeq: 2 INVITE.
> Server: OpenSIPS (1.6.1-notls (x86_64/linux)).
> Content-Length: 0.
>
>
> U xx.yy.56.226:5060 -> xx.yy.17.20:5060
> SIP/2.0 100 Giving a try.
> Via: SIP/2.0/UDP 
> xx.yy.17.20;branch=z9hG4bK591c111426474b446164164716f0.
> From: "unknown" ;tag=152937654c2b.
> To: .
> Call-ID: D17BF0696DC546A7B436401CD27774720x591c1114.
> CSeq: 2 INVITE.
>  
>
> U xx.yy.56.226:5060 -> xx.yy.25.114:5060
> INVITE sip:987...@xx.yy.25.114:5060;transport=udp SIP/2.0.
> Record-Route: .
> Via: SIP/2.0/UDP xx.yy.56.226;branch=z9hG4bKf69b.0ced9bb7.0.
> Via: SIP/2.0/UDP 
> xx.yy.17.20;branch=z9hG4bK591c111426474b446164164716f0.
> From: "unknown" ;tag=152937654c2b.
> To: .
> Contact: .
> Call-ID: D17BF0696DC546A7B436401CD27774720x591c1114.
> CSeq: 2 INVITE.
> Max-Forwards: 69.
>
>
>
> U xx.yy.25.114:5060 -> xx.yy.56.226:5060
> SIP/2.0 100 Trying.
> Via: SIP/2.0/UDP 
> xx.yy.56.226;branch=z9hG4bKf69b.0ced9bb7.0,SIP/2.0/UDP 
> xx.yy.17.20;branch=z9hG4bK591c111426474b446164164716f0.
> Fr

Re: [OpenSIPS-Users] Unsuccessfull upgrade from 1.4.5 to 1.6.1 (RR module)

2010-01-22 Thread Gabriel Bermudez
Hi,

I'm no expert but I think that the default opensips scripts handles the
downscript ACK with this code:
route(1) simple relays the message.

if (has_totag()) {
# sequential request withing a dialog should
# take the path determined by record-routing
if (loose_route()) {
if (is_method("BYE")) {
setflag(1); # do accounting ...
setflag(3); # ... even if the transaction
fails
}
route(1);
} else {
/* uncomment the following lines if you want to
enable presence */
##if (is_method("SUBSCRIBE") && $rd ==
"your.server.ip.address") {
##  # in-dialog subscribe requests
##  route(2);
##  exit;
##}
if ( is_method("ACK") ) {
if ( t_check_trans() ) {
# non loose-route, but stateful ACK;
must be an ACK after a 487 or e.g. 404 from upstream server
t_relay();
exit;
} else {
# ACK without matching transaction
... ignore and discard.\n");
exit;
}
}
sl_send_reply("404","Not here");
}
exit;
}

Hope it helps,

Regards,


2010/1/21 Oleg Burlacu 

>
>
> Hi,
> I'm running a statefull proxy that in most cases need to relay the calls to
> a PSTN gateway.
> After the migration to the Opensips 1.6.1, there is a problem with
> compatibility / RR module and the gateway (Cisco AS5300).
> Opensips does not relay 'correctly' (in my case) the ACK messages. The
> Cisco gateway do not receive ACKs and hangup the call after a timeout.
> The configuration script is developed on the sipwise template, but it works
> perfectly in 1.4 version of Opensips.
>
> When debugging I see each time more and more headers in ACK packets
>  Record-Route: 
> Record-Route: 
> Record-Route: 
> Record-Route: 
> Via: SIP/2.0/UDP xx.yy.56.226;branch=z9hG4bKa636.94cf333.2
> Via: SIP/2.0/UDP xx.yy.56.226;branch=z9hG4bKa636.94cf333.2
> Via: SIP/2.0/UDP xx.yy.56.226;branch=z9hG4bKa636.94cf333.2
> Via: SIP/2.0/UDP xx.yy.56.226;branch=z9hG4bKa636.94cf333.2
> Via: SIP/2.0/UDP
> xx.yy.17.20;branch=z9hG4bK591c111423e34b43aea64e671405
>
> When disabling the record_route(), and messages go from sip client directly
> to the gateway - all in ok.
> When communicating between 2 sip clients on the same proxy - the messages
> are relayed correctly.
> What can be the solution?
>
>
> The entire message log:
>
>  U xx.yy.17.20:5060 -> xx.yy.56.226:5060
> INVITE sip:987...@xx.yy.56.226 SIP/2.0.
> Via: SIP/2.0/UDP
> xx.yy.17.20;branch=z9hG4bK591c111426464b44616423ea16ed.
> From: "unknown" ;tag=152937654c2b.
> To: .
> Contact: .
> Call-ID: D17BF0696DC546A7B436401CD27774720x591c1114.
> CSeq: 1 INVITE.
> Max-Forwards: 70.
> User-Agent: SJphone/1.65.377a (SJ Labs).
>
>
> U xx.yy.56.226:5060 -> xx.yy.17.20:5060
> SIP/2.0 100 Trying.
> Via: SIP/2.0/UDP
> xx.yy.17.20;branch=z9hG4bK591c111426464b44616423ea16ed.
> From: "unknown" ;tag=152937654c2b.
> To: .
> Call-ID: D17BF0696DC546A7B436401CD27774720x591c1114.
> CSeq: 1 INVITE.
>
>
>
> U xx.yy.56.226:5060 -> xx.yy.17.20:5060
> SIP/2.0 407 Proxy Authentication Required.
> Via: SIP/2.0/UDP
> xx.yy.17.20;branch=z9hG4bK591c111426464b44616423ea16ed.
> From: "unknown" ;tag=152937654c2b.
> To: ;tag=c97b4d1cb1f3d0da549e06a8d482ef63.8548.
> Call-ID: D17BF0696DC546A7B436401CD27774720x591c1114.
> CSeq: 1 INVITE.
>
>
>
> U xx.yy.17.20:5060 -> xx.yy.56.226:5060
> ACK sip:987...@xx.yy.56.226 SIP/2.0.
> Via: SIP/2.0/UDP
> xx.yy.17.20;branch=z9hG4bK591c111426464b44616423ea16ed.
> From: "unknown" ;tag=152937654c2b.
> To: ;tag=c97b4d1cb1f3d0da549e06a8d482ef63.8548.
> Call-ID: D17BF0696DC546A7B436401CD27774720x591c1114.
> CSeq: 1 ACK.
> Max-Forwards: 70.
> User-Agent: SJphone/1.65.377a (SJ Labs).
> Content-Length: 0.
>
>
>
> U xx.yy.17.20:5060 -> xx.yy.56.226:5060
> INVITE sip:987...@xx.yy.56.226 SIP/2.0.
> Via: SIP/2.0/UDP
> xx.yy.17.20;branch=z9hG4bK591c111426474b446164164716f0.
> From: "unknown" ;tag=152937654c2b.
> To: .
> Contact: .
> Call-ID: D17BF0696DC546A7B436401CD27774720x591c1114.
> CSeq: 2 INVITE.
> Max-Forwards: 70.
> User-Agent: SJphone/1.65.377a (SJ Labs).
> Content-Length: 362.
> Content-Type: application/sdp.
> Supported: replaces,norefersub,timer.
> Proxy-Authorization: Digest
> username="123456",realm="xx.yy.56.226",nonce="4b43ec22000883661dbea2617b91d28401983dd85b7d",uri="sip:987...@xx.yy.56.226
> ",response="9

[OpenSIPS-Users] Unsuccessfull upgrade from 1.4.5 to 1.6.1 (RR module)

2010-01-21 Thread Oleg Burlacu
Hi,
I'm running a statefull proxy that in most cases need to relay the calls to
a PSTN gateway.
After the migration to the Opensips 1.6.1, there is a problem with
compatibility / RR module and the gateway (Cisco AS5300).
Opensips does not relay 'correctly' (in my case) the ACK messages. The Cisco
gateway do not receive ACKs and hangup the call after a timeout.
The configuration script is developed on the sipwise template, but it works
perfectly in 1.4 version of Opensips.

When debugging I see each time more and more headers in ACK packets
 Record-Route: 
Record-Route: 
Record-Route: 
Record-Route: 
Via: SIP/2.0/UDP xx.yy.56.226;branch=z9hG4bKa636.94cf333.2
Via: SIP/2.0/UDP xx.yy.56.226;branch=z9hG4bKa636.94cf333.2
Via: SIP/2.0/UDP xx.yy.56.226;branch=z9hG4bKa636.94cf333.2
Via: SIP/2.0/UDP xx.yy.56.226;branch=z9hG4bKa636.94cf333.2
Via: SIP/2.0/UDP
xx.yy.17.20;branch=z9hG4bK591c111423e34b43aea64e671405

When disabling the record_route(), and messages go from sip client directly
to the gateway - all in ok.
When communicating between 2 sip clients on the same proxy - the messages
are relayed correctly.
What can be the solution?


The entire message log:

 U xx.yy.17.20:5060 -> xx.yy.56.226:5060
INVITE sip:987...@xx.yy.56.226 SIP/2.0.
Via: SIP/2.0/UDP
xx.yy.17.20;branch=z9hG4bK591c111426464b44616423ea16ed.
From: "unknown" ;tag=152937654c2b.
To: .
Contact: .
Call-ID: D17BF0696DC546A7B436401CD27774720x591c1114.
CSeq: 1 INVITE.
Max-Forwards: 70.
User-Agent: SJphone/1.65.377a (SJ Labs).


U xx.yy.56.226:5060 -> xx.yy.17.20:5060
SIP/2.0 100 Trying.
Via: SIP/2.0/UDP
xx.yy.17.20;branch=z9hG4bK591c111426464b44616423ea16ed.
From: "unknown" ;tag=152937654c2b.
To: .
Call-ID: D17BF0696DC546A7B436401CD27774720x591c1114.
CSeq: 1 INVITE.



U xx.yy.56.226:5060 -> xx.yy.17.20:5060
SIP/2.0 407 Proxy Authentication Required.
Via: SIP/2.0/UDP
xx.yy.17.20;branch=z9hG4bK591c111426464b44616423ea16ed.
From: "unknown" ;tag=152937654c2b.
To: ;tag=c97b4d1cb1f3d0da549e06a8d482ef63.8548.
Call-ID: D17BF0696DC546A7B436401CD27774720x591c1114.
CSeq: 1 INVITE.



U xx.yy.17.20:5060 -> xx.yy.56.226:5060
ACK sip:987...@xx.yy.56.226 SIP/2.0.
Via: SIP/2.0/UDP
xx.yy.17.20;branch=z9hG4bK591c111426464b44616423ea16ed.
From: "unknown" ;tag=152937654c2b.
To: ;tag=c97b4d1cb1f3d0da549e06a8d482ef63.8548.
Call-ID: D17BF0696DC546A7B436401CD27774720x591c1114.
CSeq: 1 ACK.
Max-Forwards: 70.
User-Agent: SJphone/1.65.377a (SJ Labs).
Content-Length: 0.



U xx.yy.17.20:5060 -> xx.yy.56.226:5060
INVITE sip:987...@xx.yy.56.226 SIP/2.0.
Via: SIP/2.0/UDP
xx.yy.17.20;branch=z9hG4bK591c111426474b446164164716f0.
From: "unknown" ;tag=152937654c2b.
To: .
Contact: .
Call-ID: D17BF0696DC546A7B436401CD27774720x591c1114.
CSeq: 2 INVITE.
Max-Forwards: 70.
User-Agent: SJphone/1.65.377a (SJ Labs).
Content-Length: 362.
Content-Type: application/sdp.
Supported: replaces,norefersub,timer.
Proxy-Authorization: Digest
username="123456",realm="xx.yy.56.226",nonce="4b43ec22000883661dbea2617b91d28401983dd85b7d",uri="sip:987...@xx.yy.56.226
",response="91a62cf62af7870c1e24d6c35857e78d".



U xx.yy.56.226:5060 -> xx.yy.17.20:5060
SIP/2.0 100 Trying.
Via: SIP/2.0/UDP
xx.yy.17.20;branch=z9hG4bK591c111426474b446164164716f0.
From: "unknown" ;tag=152937654c2b.
To: .
Call-ID: D17BF0696DC546A7B436401CD27774720x591c1114.
CSeq: 2 INVITE.
Server: OpenSIPS (1.6.1-notls (x86_64/linux)).
Content-Length: 0.


U xx.yy.56.226:5060 -> xx.yy.17.20:5060
SIP/2.0 100 Giving a try.
Via: SIP/2.0/UDP
xx.yy.17.20;branch=z9hG4bK591c111426474b446164164716f0.
From: "unknown" ;tag=152937654c2b.
To: .
Call-ID: D17BF0696DC546A7B436401CD27774720x591c1114.
CSeq: 2 INVITE.


U xx.yy.56.226:5060 -> xx.yy.25.114:5060
INVITE sip:987...@xx.yy.25.114:5060;transport=udp SIP/2.0.
Record-Route: .
Via: SIP/2.0/UDP xx.yy.56.226;branch=z9hG4bKf69b.0ced9bb7.0.
Via: SIP/2.0/UDP
xx.yy.17.20;branch=z9hG4bK591c111426474b446164164716f0.
From: "unknown" ;tag=152937654c2b.
To: .
Contact: .
Call-ID: D17BF0696DC546A7B436401CD27774720x591c1114.
CSeq: 2 INVITE.
Max-Forwards: 69.



U xx.yy.25.114:5060 -> xx.yy.56.226:5060
SIP/2.0 100 Trying.
Via: SIP/2.0/UDP xx.yy.56.226;branch=z9hG4bKf69b.0ced9bb7.0,SIP/2.0/UDP
xx.yy.17.20;branch=z9hG4bK591c111426474b446164164716f0.
From: "unknown" ;tag=152937654c2b.
To: ;tag=708A5698-428.
Date: Wed, 06 Jan 2010 09:59:05 GMT.
Call-ID: D17BF0696DC546A7B436401CD27774720x591c1114.
Server: Cisco-SIPGateway/IOS-12.x.
CSeq: 2 INVITE.
Allow-Events: telephone-event.
Content-Length: 0.



U xx.yy.25.114:5060 -> xx.yy.56.226:5060
SIP/2.0 183 Session Progress.
Via: SIP/2.0/UDP xx.yy.56.226;branch=z9hG4bKf69b.0ced9bb7.0,SIP/2.0/UDP
xx.yy.17.20;branch=z9hG4bK591c111426474b446164164716f0.
From: "unknown" ;tag=152937654c2b.
To: ;tag=708A5698-428.
Date: Wed, 06 Jan 2010 09:59:05 GMT.
Call-ID: D17BF0696DC546A7B436401CD27774720x591c1114.
Server: Cisco-SIPGateway/IOS-12.x.
CSeq: 2 INVITE.
Allow