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@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=1024, 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@127.0.0.1:5069;transport=udp Mar 26 14:27:01 kam /usr/sbin/kamailio[7929]: ERROR: <script>: Loose route, ru is sip:1.2.3.4:25060;lr=on;ftag=a9c837bc;nat=yes """
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=z9hG4bK361e.ba530345.0. Via: SIP/2.0/UDP 192.168.1.29:5060;rport=3081;received=2.3.4.5;branch=z9hG4bK-373632-e2d6ebcc5a1d2a481e4957541b393f9a. Record-Route: sip:1.2.3.4:25060;lr=on;ftag=a9c837bc;nat=yes. From: "ines.demo" sip:ines.demo@mydomain.net;tag=a9c837bc. To: sip:01234567@mydomain.net;tag=BcBSHa56Bp7ge. Call-ID: 65464bffda1b33cfcc9d97c9e8f81cb3@0:0:0:0:0:0:0:0. CSeq: 2 INVITE. Contact: sip:01234567@127.0.0.1:5069;transport=udp. 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@mydomain.net;party=calling;privacy=off;screen=no. . v=0. o=root 13076 13076 IN IP4 1.2.3.4. s=session. c=IN IP4 1.2.3.4. t=0 0. m=audio 48548 RTP/AVP 8 0 102 3 101. a=rtpmap:8 PCMA/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:102 iLBC/8000. a=fmtp:102 mode=30. a=rtpmap:3 GSM/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=silenceSupp:off - - - -. a=ptime:20. a=nortpproxy:yes. m=video 0 RTP/AVP 96 97 98. a=rtpmap:96 /0. a=rtpmap:97 /0. a=rtpmap: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=3081;received=2.3.4.5;branch=z9hG4bK-373632-e2d6ebcc5a1d2a481e4957541b393f9a. Record-Route: sip:1.2.3.4:25060;lr=on;ftag=a9c837bc;nat=yes. From: "ines.demo" sip:ines.demo@mydomain.net;tag=a9c837bc. To: sip:01234567@mydomain.net;tag=BcBSHa56Bp7ge. Call-ID: 65464bffda1b33cfcc9d97c9e8f81cb3@0:0:0:0:0:0:0:0. CSeq: 2 INVITE. Contact: sip:01234567@127.0.0.1:5069;transport=udp. 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@mydomain.net;party=calling;privacy=off;screen=no. . v=0. o=root 13076 13076 IN IP4 1.2.3.4. s=session. c=IN IP4 1.2.3.4. t=0 0. m=audio 48548 RTP/AVP 8 0 102 3 101. a=rtpmap:8 PCMA/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:102 iLBC/8000. a=fmtp:102 mode=30. a=rtpmap:3 GSM/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=silenceSupp:off - - - -. a=ptime:20. a=nortpproxy:yes. m=video 0 RTP/AVP 96 97 98. a=rtpmap:96 /0. a=rtpmap:97 /0. a=rtpmap:98 /0.
# U 2012/03/26 14:27:00.160046 2.3.4.5:3081 -> 1.2.3.4:25060 ACK sip:01234567@127.0.0.1:5069;transport=udp SIP/2.0. Call-ID: 65464bffda1b33cfcc9d97c9e8f81cb3@0:0:0:0:0:0:0:0. CSeq: 2 ACK. Via: SIP/2.0/UDP 192.168.1.29:5060;branch=z9hG4bK-373632-6eac5ecf0ba5ab4ce7094ad17870dca3. From: "ines.demo" sip:ines.demo@mydomain.net;tag=a9c837bc. To: sip:01234567@mydomain.net;tag=BcBSHa56Bp7ge. Max-Forwards: 70. Route: sip:1.2.3.4:25060;lr=on;ftag=a9c837bc;nat=yes. Contact: "ines.demo" sip:ines.demo@192.168.1.29:5060;transport=udp;registering_acc=mydomain_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=on;ftag=a9c837bc;nat=yes SIP/2.0. Call-ID: 65464bffda1b33cfcc9d97c9e8f81cb3@0:0:0:0:0:0:0:0. CSeq: 2 ACK. Via: SIP/2.0/UDP 1.2.3.4:25060;branch=z9hG4bKcydzigwkX. Via: SIP/2.0/UDP 192.168.1.29:5060;rport=3081;received=2.3.4.5;branch=z9hG4bK-373632-6eac5ecf0ba5ab4ce7094ad17870dca3. From: "ines.demo" sip:ines.demo@mydomain.net;tag=a9c837bc. To: sip:01234567@mydomain.net;tag=BcBSHa56Bp7ge. Max-Forwards: 69. Contact: "ines.demo" sip:ines.demo@2.3.4.5:3081;transport=udp;registering_acc=mydomain_net. User-Agent: Jitsi1.0-beta1-nightly.build.3820Windows 7. Content-Length: 0. """
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