From danb.lists@googlemail.com Mon Mar 26 15:47:17 2012
From: Dan-Cristian Bogos <danb.lists@googlemail.com>
To: sr-users@lists.kamailio.org
Subject: [SR-Users] Kamailio modifying ruri during loose-route
Date: Mon, 26 Mar 2012 15:47:11 +0200
Message-ID:
 <CADMA_LDOSiYzNy+pHSAeHdYnubmr_gPov6wYrq82isfkzwkBzA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1718534376=="

--===============1718534376==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hey Guys,

I have noticed some unexpected behavior (at least by me) during my tests.

When routing specific ACK message back to 200 OK originator, Kamailio
will rewrite the ruri with the value of route header. Is that known or
some memory access problem?

Call setup: B2BUA(127.0.0.1) -> Kamailio (1.2.3.4) -> End device (2.3.4.5).

Bellow is a trace of 200 OK -ACK flow before and after kamailio,
together with the xlog capture of ruri before and after calling
loose_route on ACK.

Thanks in advance for any kind of tip.

DanB

PS: Since testing with a newer version would be a bit harder due to
some particular features I use in 3.1 which are taking a bit of effort
to migrate, have tried my luck here before, so hope to get your
understanding.

Kamailio version:
"""

root(a)kam:/home/dan# kamailio -V
version: kamailio 3.1.5 (x86_64/linux)
flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS,
USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM,
SHM_MMAP, PKG_MALLOC, DBG_QM_MALLOC, USE_FUTEX,
FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR,
USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=3D1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535, PKG_SIZE 4MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: unknown
compiled on 07:41:01 Sep 15 2011 with gcc 4.4.5
"""

Syslog:
"""

Mar 26 14:27:01 kam /usr/sbin/kamailio[7929]: ERROR: <script>: Before
loose_route, ru is sip:01234567(a)127.0.0.1:5069;transport=3Dudp
Mar 26 14:27:01 kam /usr/sbin/kamailio[7929]: ERROR: <script>: Loose
route, ru is sip:1.2.3.4:25060;lr=3Don;ftag=3Da9c837bc;nat=3Dyes
"""

Ngrep of call:
"""
#
U 2012/03/26 14:27:00.089455 127.0.0.1:5069 -> 1.2.3.4:25060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 1.2.3.4:25060;branch=3Dz9hG4bK361e.ba530345.0.
Via: SIP/2.0/UDP
192.168.1.29:5060;rport=3D3081;received=3D2.3.4.5;branch=3Dz9hG4bK-373632-e2d=
6ebcc5a1d2a481e4957541b393f9a.
Record-Route: <sip:1.2.3.4:25060;lr=3Don;ftag=3Da9c837bc;nat=3Dyes>.
From: "ines.demo" <sip:ines.demo(a)mydomain.net>;tag=3Da9c837bc.
To: <sip:01234567(a)mydomain.net>;tag=3DBcBSHa56Bp7ge.
Call-ID: 65464bffda1b33cfcc9d97c9e8f81cb3(a)0:0:0:0:0:0:0:0.
CSeq: 2 INVITE.
Contact: <sip:01234567(a)127.0.0.1:5069;transport=3Dudp>.
User-Agent: WebiB2BUA 1.0.6.
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO,
REGISTER, REFER, NOTIFY.
Supported: timer, precondition, path, replaces.
Allow-Events: talk, hold, refer.
Content-Type: application/sdp.
Content-Disposition: session.
Content-Length: 417.
Remote-Party-ID: "01234567"
<sip:01234567(a)mydomain.net>;party=3Dcalling;privacy=3Doff;screen=3Dno.
.
v=3D0.
o=3Droot 13076 13076 IN IP4 1.2.3.4.
s=3Dsession.
c=3DIN IP4 1.2.3.4.
t=3D0 0.
m=3Daudio 48548 RTP/AVP 8 0 102 3 101.
a=3Drtpmap:8 PCMA/8000.
a=3Drtpmap:0 PCMU/8000.
a=3Drtpmap:102 iLBC/8000.
a=3Dfmtp:102 mode=3D30.
a=3Drtpmap:3 GSM/8000.
a=3Drtpmap:101 telephone-event/8000.
a=3Dfmtp:101 0-16.
a=3DsilenceSupp:off - - - -.
a=3Dptime:20.
a=3Dnortpproxy:yes.
m=3Dvideo 0 RTP/AVP 96 97 98.
a=3Drtpmap:96 /0.
a=3Drtpmap:97 /0.
a=3Drtpmap:98 /0.

#
U 2012/03/26 14:27:00.089589 1.2.3.4:25060 -> 2.3.4.5:3081
SIP/2.0 200 OK.
Via: SIP/2.0/UDP
192.168.1.29:5060;rport=3D3081;received=3D2.3.4.5;branch=3Dz9hG4bK-373632-e2d=
6ebcc5a1d2a481e4957541b393f9a.
Record-Route: <sip:1.2.3.4:25060;lr=3Don;ftag=3Da9c837bc;nat=3Dyes>.
From: "ines.demo" <sip:ines.demo(a)mydomain.net>;tag=3Da9c837bc.
To: <sip:01234567(a)mydomain.net>;tag=3DBcBSHa56Bp7ge.
Call-ID: 65464bffda1b33cfcc9d97c9e8f81cb3(a)0:0:0:0:0:0:0:0.
CSeq: 2 INVITE.
Contact: <sip:01234567(a)127.0.0.1:5069;transport=3Dudp>.
User-Agent: WebiB2BUA 1.0.6.
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO,
REGISTER, REFER, NOTIFY.
Supported: timer, precondition, path, replaces.
Allow-Events: talk, hold, refer.
Content-Type: application/sdp.
Content-Disposition: session.
Content-Length: 417.
Remote-Party-ID: "01234567"
<sip:01234567(a)mydomain.net>;party=3Dcalling;privacy=3Doff;screen=3Dno.
.
v=3D0.
o=3Droot 13076 13076 IN IP4 1.2.3.4.
s=3Dsession.
c=3DIN IP4 1.2.3.4.
t=3D0 0.
m=3Daudio 48548 RTP/AVP 8 0 102 3 101.
a=3Drtpmap:8 PCMA/8000.
a=3Drtpmap:0 PCMU/8000.
a=3Drtpmap:102 iLBC/8000.
a=3Dfmtp:102 mode=3D30.
a=3Drtpmap:3 GSM/8000.
a=3Drtpmap:101 telephone-event/8000.
a=3Dfmtp:101 0-16.
a=3DsilenceSupp:off - - - -.
a=3Dptime:20.
a=3Dnortpproxy:yes.
m=3Dvideo 0 RTP/AVP 96 97 98.
a=3Drtpmap:96 /0.
a=3Drtpmap:97 /0.
a=3Drtpmap:98 /0.

#
U 2012/03/26 14:27:00.160046 2.3.4.5:3081 -> 1.2.3.4:25060
ACK sip:01234567(a)127.0.0.1:5069;transport=3Dudp SIP/2.0.
Call-ID: 65464bffda1b33cfcc9d97c9e8f81cb3(a)0:0:0:0:0:0:0:0.
CSeq: 2 ACK.
Via: SIP/2.0/UDP
192.168.1.29:5060;branch=3Dz9hG4bK-373632-6eac5ecf0ba5ab4ce7094ad17870dca3.
From: "ines.demo" <sip:ines.demo(a)mydomain.net>;tag=3Da9c837bc.
To: <sip:01234567(a)mydomain.net>;tag=3DBcBSHa56Bp7ge.
Max-Forwards: 70.
Route: <sip:1.2.3.4:25060;lr=3Don;ftag=3Da9c837bc;nat=3Dyes>.
Contact: "ines.demo"
<sip:ines.demo(a)192.168.1.29:5060;transport=3Dudp;registering_acc=3Dmydomain=
_net>.
User-Agent: Jitsi1.0-beta1-nightly.build.3820Windows 7.
Content-Length: 0.
.


#
U 2012/03/26 14:27:00.160278 1.2.3.4:25060 -> 1.2.3.4:25060
ACK sip:1.2.3.4:25060;lr=3Don;ftag=3Da9c837bc;nat=3Dyes SIP/2.0.
Call-ID: 65464bffda1b33cfcc9d97c9e8f81cb3(a)0:0:0:0:0:0:0:0.
CSeq: 2 ACK.
Via: SIP/2.0/UDP 1.2.3.4:25060;branch=3Dz9hG4bKcydzigwkX.
Via: SIP/2.0/UDP
192.168.1.29:5060;rport=3D3081;received=3D2.3.4.5;branch=3Dz9hG4bK-373632-6ea=
c5ecf0ba5ab4ce7094ad17870dca3.
From: "ines.demo" <sip:ines.demo(a)mydomain.net>;tag=3Da9c837bc.
To: <sip:01234567(a)mydomain.net>;tag=3DBcBSHa56Bp7ge.
Max-Forwards: 69.
Contact: "ines.demo"
<sip:ines.demo(a)2.3.4.5:3081;transport=3Dudp;registering_acc=3Dmydomain_net>.
User-Agent: Jitsi1.0-beta1-nightly.build.3820Windows 7.
Content-Length: 0.
"""


--===============1718534376==--


From apogrebennyk@sipwise.com Mon Mar 26 16:07:14 2012
From: Andrew Pogrebennyk <apogrebennyk@sipwise.com>
To: sr-users@lists.kamailio.org
Subject: Re: [SR-Users] Kamailio modifying ruri during loose-route
Date: Mon, 26 Mar 2012 16:07:07 +0200
Message-ID: <4F70780B.7060102@sipwise.com>
In-Reply-To:
 <CADMA_LDOSiYzNy+pHSAeHdYnubmr_gPov6wYrq82isfkzwkBzA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1045490073=="

--===============1045490073==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Dan,
Well, it looks like kamailio recognizes 127.0.0.1 as its own URI that's
why it does rewrite. Do you have by chance such alias in your config (or
auto_aliases=yes)?

On 03/26/2012 03:47 PM, Dan-Cristian Bogos wrote:
> Hey Guys,
> 
> I have noticed some unexpected behavior (at least by me) during my tests.
> 
> When routing specific ACK message back to 200 OK originator, Kamailio
> will rewrite the ruri with the value of route header. Is that known or
> some memory access problem?
> 
> Call setup: B2BUA(127.0.0.1) -> Kamailio (1.2.3.4) -> End device (2.3.4.5).
> 
> Bellow is a trace of 200 OK -ACK flow before and after kamailio,
> together with the xlog capture of ruri before and after calling
> loose_route on ACK.
> 
> Thanks in advance for any kind of tip.
> 
> DanB
> 


--===============1045490073==--