Re: [OpenSIPS-Users] Unsuccessfull upgrade from 1.4.5 to 1.6.1 (RR module)
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)
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)
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)
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)
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