January 2017 - sr-users

Kamailio & Asterisk SIP Registration Forwarding - Asterisk replies 401 Unauthorized
by Ben Fitzgerald 17 Apr '26

17 Apr '26

Hi, I've been following this integration tutorial http://kb.asipto.com/asterisk:realtime:kamailio-4.0.x-asterisk-11.3.0-astdb and have a successful registration and I can even make calls through my asterisk box. However what is unusual to me is that every time a phone registers with Kamailio, that is forwarded to Asterisk (as expected), yet Asterisk replies with 401 Unauthorized. Oddly enough the phone registers and can still make calls. What worries me is that as we scale to 100's of cps, this seemingly erroneous message may slow down Asterisk because it's trying to handle authentication for users which have already been authenticated by Kamailio. If this behavior is expected, then that would be good to know as well. This is the sip debug from ASTERISK (I have replaced IP's with the names of the servers): <--- SIP read from TCP:kamailio:41205 ---> REGISTER sip:asteriskIP:5060;transport=tcp SIP/2.0 Via: SIP/2.0/TCP kamailio;branch=z9hG4bK998f.2846e405000000000000000000000000.0 To: <sip:40081@asteriskIP> From: <sip:40081@asteriskIP>;tag=32fda68bf54efeeb04e3edc67b53c63d-cfb0 CSeq: 10 REGISTER Call-ID: 0005ce130bcee5c4-26538@kamailio Max-Forwards: 70 Content-Length: 0 User-Agent: kamailio (4.3.0 (x86_64/linux)) Contact: <sip:40081@kamailio:5060> Expires: 3600 <-------------> --- (11 headers 0 lines) --- Sending to kamailio:5060 (no NAT) Sending to kamailio:5060 (no NAT) <--- Transmitting (no NAT) to kamailio:5060 ---> SIP/2.0 401 Unauthorized Via: SIP/2.0/TCP kamailio;branch=z9hG4bK998f.2846e405000000000000000000000000.0;received= kamailio From: <sip:40081@asteriskIP>;tag=32fda68bf54efeeb04e3edc67b53c63d-cfb0 To: <sip:40081@asteriskIP>;tag=as404bac9a Call-ID: 0005ce130bcee5c4-26538@ kamailio CSeq: 10 REGISTER Server: Asterisk PBX 11.6-cert2 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH Supported: replaces, timer WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="262b338e" Content-Length: 0 <------------> Scheduling destruction of SIP dialog '0005ce130bcee5c4-26538@ kamailio' in 32000 ms (Method: REGISTER) Scheduling destruction of SIP dialog '0005ce130bcee5c4-26538@ kamailio' in 32000 ms (Method: REGISTER) Really destroying SIP dialog '0005ce130bcee5c1-26536@ kamailio' Method: REGISTER ========================= sip.conf for kamailio trunk: [kamailio-inbound] type=friend dtmfmode=auto host=kamailioIP allow=all context=sipout insecure=port,invite canreinvite=no ======================== Asterisk version: 11.6-cert2 Kamailio version: 4.3 Benjamin Fitzgerald LETS Corporation (925) 235-1154 ben(a)letscorp.us *******Confidential Notice: This message is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this message in error, please delete this message from all computers and contact Orion Systems/LETS Corp immediately by return e-mail and/or telephone at (925) 566-5600

4 8

Support for TLS server_name extension (aka SNI=server name indication)
by Barry Flanagan 04 Sep '25

04 Sep '25

Hi, Back in Kamailio 1.5, the release notes state: "support for TLS server_name extension (aka SNI=server name indication)" However, I cannot find any indication of this in the current TLS docs, and trying to set tls_server_name or server_name in tls.cfg fails with "unsupported option". Is this actually supported? Thanks. -Barry Flanagan

5 7

[Serusers] Digest Authentication with Tenor DX
by Ashutosh Kumar 29 Apr '25

29 Apr '25

Hi, Does someone have any idea/experience with Quintum DX radius server's support for digest mode authentication. The Access-Request packets sent by SER are getting an error back. Guide. Regards, Ashutosh Kumar Chetu, Inc. Ph : 1(305) 402 6724 - Witin US Ph : 91 120 5323340 - Outside US Fax:1 (305) 832 5987 For more information, please visit http://www.chetu.com

2 1

need help with RTPProxy in bridged mode
by Grant Bagdasarian 04 Apr '20

04 Apr '20

Hello, I'm using RTPproxy for the first time in bridged mode and I can't get kamailio/rtpproxy to rewrite the c parameter to the correct public ip address of kamailio. The setup is as following: Carrier ------[fiber]------ Kamailio ---------[lan]--------- Freeswitch Kamailio is listening on two interfaces: 1) Private: 172.0.0.1 2) Public: 192.168.0.1 (since we have a dedicated fiber with our carrier, this is its public address) Freeswitch is listening on: 1) 172.0.0.2 Carrier is on: 1) 10.0.0.1 I've started an rtpproxy instance on the Kamailio box using: rtpproxy -s udp:127.0.0.1:7721 -u rtpproxy rtpproxy -p /var/run/rtpproxy/rtpproxy.pid -l 192.168.0.1 172.0.0.1 I've played around with rtpproxy_manage() and the various flags (ie, ei), but I can't get kamailio to set the correct public IP when the 200 OK has to be sent back to the carrier. It always sets it to its private address, instead of its public address. I'm using Kamailio 4.2 with sippy/rtpproxy 2.0. Could someone please point me into the right direction? Thanks! Grant

4 8

rtpproxy does not response, disable it
by Zodiac 03 Jan '20

03 Jan '20

Dear friends, I am working on a program on Kamailio and rtpengine proxy. I am wondering whether can I set Kamailio and rtpengine daemon on different physical machines. For example, I set Kamailio on a machine with IP address:10.109.247.80, and launch rtpengine daemon on another machine with interface parameter as 10.109.247.90 and ng port 7723. I set parameter in Kamailio.cfg with modparam(“rtpengine”, “rtpengine_sock”, “udp:10.109.247.90:7723”). Unfortunately I got debug message like this: ERROR: rtpengine [rtpengine.c:1710]: send_rtpp_command(): can't send command to a RTP proxy ERROR: rtpengine [rtpengine.c:1746]: send_rtpp_command(): proxy <udp:10.109.247.90:7723> does not respond, disable it ERROR: rtpengine [rtpengine.c:1616]: rtpp_test(): proxy did not respond to ping And, I also tried to set Kamailio and rtpengine daemon in a same machine,and use modparam(“rtpengine”, “rtpengine_sock”, “udp:localhost:7723”). And Kamailio can work functionally under this situation. rtpengine daemon can receive ping message from Kamailio and rtpengine daemon can work as suspected. So for the later case, is it supposed that Kamailio be in the same machine with same localhost address? Otherwise, what’s the reason for my ERROR? ------------------------------------ 北京邮电大学网络技术研究院网络与交换技术国家重点实验室田军 +86 18810315790 mozillafire(a)bupt.edu.cn ------------------------------------

5 10

Kamailio Behind TCP Load Balancer
by Colin Morelli 04 Jun '18

04 Jun '18

Hey all, I'm looking to put Kamailio behind a TCP load balancer that is SIP-unaware. My application is deployed in AWS and I'm tying to place Kamailio behind an ELB. For the most part, everything is fine. For my specific implementation I'm disabling UDP as a signaling transport and using only TLS. This enables me to not have to worry about a SIP-aware LB at the edge because replies to an incoming request will be sent over the existing established TCP socket (avoiding any crazy routing requirements). However - this poses an issue with source addresses. Does Kamailio support anything like the proxy protocol ( http://www.haproxy.org/download/1.5/doc/proxy-protocol.txt) for getting TCP stream information from a load balancer? Do I need to go back to exposing it directly to the world so that I can get source addresses? Thanks, Colin

3 4

Kamailio Websocket Questions
by Nagorny, Dimitry 17 Apr '18

17 Apr '18

Hi List, two questions regarding Kamailio Websockets: 1. How do I send INVITE request TO the listening Websocket? I usually used for UDP/TCP/TLS these format, but somehow this is not working for Websocket because it gets in an endless loop: if ($rU=~"^(\+|00|0)?[1-9][0-9]{4,20}$") { $ru = "sip:" + $rU + "@" + $sel(cfg_get.pstn.gw_ip) + ";user=phone;transport=udp"; force_send_socket(udp:MY_EXTERN_IP:MY_EXTERN_PORT); rtpengine_offer("internal trust-address RTP AVP"); route(RELAY); exit; } 2. Why do I get these errors every time my Websocket Client is registering, but it still works and DB is inserted with registered location: ERROR: <core> [parser/parse_fline.c:257]: parse_first_line(): parse_first_line: bad message (offset: 22) ERROR: <core> [parser/msg_parser.c:690]: parse_msg(): ERROR: parse_msg: message=<HTTP/1.1 101 Switching Protocols#015#012Sia: SIP/2.0/TCP 10.250.5.17:51283#015#012Sec-WebSocket-Protocol: sip#015#012Upgrade: websocket#015#012Connection: upgrade#015#012Sec-WebSocket-Accept: 6uLXlD/aBrzu/j3PYP3DWO7rvLE=#015#012Server: kamailio (4.3.5 (x86_64/linux))#015#012Content-Length: 0#015#012#015#012> I am using Kamailio 4.3.5 + CentOS 7.2. I appreciate every help I can get. Best Regards Dimitry Nagorny Trainee

3 4

Re: [SR-Users] How to determine correct port to set in record-route header
by Pranathi Venkatayogi 30 Mar '18

30 Mar '18

Any help? From: Pranathi Venkatayogi Sent: Monday, January 23, 2017 2:35 PM To: 'Kamailio (SER) - Users Mailing List' <sr-users(a)lists.sip-router.org> Subject: How to determine correct port to set in record-route header Hi, I am using Kamailio behind NAT, unable to figure how to make it put “public ip” in Record-route header, I am manually inserting the hard-coded header myself as below. However now I am having trouble choosing the right port number in all scenarios. $var(dstPort) = 5061; if (dst_port==5060) { $var(dstPort) = 5060; } insert_hf("Record-Route: <sip:MY_PUBLICIP_ADDR:$var(dstPort);transport=tls;lr;nat=yes>\r\n", "Record-Route"); In one scenario I see the conflicting port numbers in “via” header vs “Record route”. The ACK is being set to port 5060 based on Record route header and is not being received by the callee. 2017-01-23 14:52:49.970233 [blink.exe 2780]: SENDING: Packet 11, +0:00:36.411867 10.0.27.108:58217 -(SIP over TLS)-> 172.31.211.31:5061 SIP/2.0 180 Ringing Via: SIP/2.0/TLS 63.149.103.72:5061;received=172.31.211.31;branch=z9hG4bK4799.7067bd2a48063748a4c353fa408eaefa.0 Via: SIP/2.0/UDP 10.0.16.52;rport=5060;branch=z9hG4bK4799.935a27c6ef5ad112225964cbe7c1be44.0;i=2 Via: SIP/2.0/TLS 10.11.200.12:51793;rport=51793;received=10.11.200.12;branch=z9hG4bKPj49f6aeca3f9b4155ab4c5304b544aa4d;alias Record-Route: <sip:63.149.103.72:5060;transport=tls;lr;nat=yes> Record-Route: <sip:10.0.16.52:5061;transport=tls;lr;nat=yes> Call-ID: 09ce10efa6a946bf9445ccc21857393e From: "cust1" <sip:cust1@devtranslation.sms-test.cyracom.com>;tag=95082caabecc42548c2fec5ccd29e5de To: <sip:spanish@translation.sms-test.cyracom.com>;tag=ec365cc8489b48a7bc5725d21b7d97a1 CSeq: 17422 INVITE Server: Blink 3.0.0 (Windows) Contact: <sip:20745891@10.0.27.108:58216;transport=tls> Allow: SUBSCRIBE, NOTIFY, PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, MESSAGE, REFER Content-Length: 0 Questions: 1. How can I let in-built record-route function automatically choose “public ip” so I can get rid of my manual insertion altogether. 2. If no option, what is the right way to choose the port on which packet is being received, so it is same as what is on “VIA”. 3. Any other pointers to improve the logic here?

3 3

rtjson + uac + event - OK, ACK and BYE display name not updated
by Diego Nadares 30 Jan '18

30 Jan '18

Hi Guys, We are modifying "from" and "to" headers with rtjson module via a json struct. It works fine in INVITE, TRYING, RINGING and OK but not in the following messages. Kamailio It's changing ONLY "from" and "to" URI BUT NOT the DISPLAY NAME. I think it's the tm module but I can't figure out how to confirm this. Maybe I need to configure something else in my cfg or could it be a bug? My json struct that is handled by rtjson module response.routing = "serial"; //response.routing = "parallel"; response.routes = []; response.routes[0] = {}; response.routes[0].uri = "sip:1111111111@172.16.213.31:5060"; response.routes[0].headers = { // Headers to be modified "from": { "display": "1111111111", "uri": "sip:111111111@172.16.213.38" }, "to": { "display": "2222222222", "uri": "sip:2222222222@172.16.213.38" }, }; response.routes[0].headers.extra = {};//"X-Hdr-A: abc\r\nX-Hdr-B: bcd\r\n"; This is part of my cfg .... modparam("dialog","dlg_flag", FLD_START) modparam("uac","restore_mode","auto") modparam("uac", "restore_dlg", 1) .... # account only INVITEs if (is_method("INVITE") && !has_totag()) { setflag(FLT_ACC); # do accounting * setflag(FLD_START); # do accounting* setflag(FLT_ACCMISSED); setflag(FLT_ACCFAILED); } ..... >From source/Aleg: *From: sipp <sip:sipp@172.16.213.21:5060 <http://sip:sipp@172.16.213.21:5060>>;tag=1.* *To: sut <sip:5555555555@172.16.213.38:5060 <http://sip:5555555555@172.16.213.38:5060>>.* To dest/Bleg: *From: 1111111111 <sip:111111111@172.16.213.38 <sip%3A111111111(a)172.16.213.38>>;tag=1.* *To: 2222222222 <sip:2222222222@172.16.213.38 <sip%3A2222222222(a)172.16.213.38>>.* Incorrect display name in BYE and ACK: *From: sipp <sip:111111111@172.16.213.38 <sip%3A111111111(a)172.16.213.38>>;tag=1.* *To: sut <sip:2222222222@172.16.213.38 <sip%3A2222222222(a)172.16.213.38>>;tag=2.* interface: any filter: ( port 5060 ) and (ip or ip6) # U 2016/12/06 15:52:13.638731 172.16.213.21:5060 -> 172.16.213.38:5060 INVITE sip:5555555555@172.16.213.38:5060 SIP/2.0. Via: SIP/2.0/UDP 172.16.213.21:5060;branch=z9hG4bK-12775-1-0. *From: sipp <sip:sipp@172.16.213.21:5060 <http://sip:sipp@172.16.213.21:5060>>;tag=1.* *To: sut <sip:5555555555@172.16.213.38:5060 <http://sip:5555555555@172.16.213.38:5060>>.* Call-ID: 1-12775(a)172.16.213.21. CSeq: 1 INVITE. Contact: "SIPP" <sip:sipp@172.16.213.21:5060>. Max-Forwards: 70. Subject: Performance Test. Content-Type: multipart/mixed;boundary=uniqueBoundary. Remote-Party-ID: <sip:sipp@172.16.213.21 >:5060;party=calling;id-type=subscriber;privacy=off;screen=no>. Content-Length: 549. . --uniqueBoundary. Content-Type: application/sdp. . v=0. o=user1 53655765 2353687637 IN IP4 172.16.213.21. s=-. c=IN IP4 172.16.213.21. t=0 0. m=audio 6000 RTP/AVP 8. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-11,16. . --uniqueBoundary. Content-Type: application/gtd. Content-Disposition: signal;handling=optional. . IAM,. CGN,04,y,1,y,4,1143617400. CIC,0000000573. CPC,09. CPN,02,y,1,52381660. FCI,n,n,n,n,y,n,n,u. GCI,f7140cc78a611601838a002128d7e512. NOC,0,n,1,n. PRN,q761*,AR*,oper2,1993. TMR,02. . --uniqueBoundary--. ................ # U 2016/12/06 15:52:13.734159 172.16.213.38:5060 -> 172.16.213.21:5060 SIP/2.0 100 trying -- your call is important to us. Via: SIP/2.0/UDP 172.16.213.21:5060;branch=z9hG4bK-12775-1-0. *From: sipp <sip:sipp@172.16.213.21:5060 <http://sip:sipp@172.16.213.21:5060>>;tag=1.* *To: sut <sip:5555555555@172.16.213.38:5060 <http://sip:5555555555@172.16.213.38:5060>>.* Call-ID: 1-12775(a)172.16.213.21. CSeq: 1 INVITE. Server: kamailio (4.4.4 (x86_64/linux)). Content-Length: 0. . ................ # U 2016/12/06 15:52:13.878600 172.16.213.38:5060 -> 172.16.213.31:5060 INVITE sip:1111111111@172.16.213.31:5060 SIP/2.0. Via: SIP/2.0/UDP 172.16.213.38;branch=z9hG4bKabaa.840cc83114975a34a37b7af020d37b65.1. *From: 1111111111 <sip:111111111@172.16.213.38 <sip%3A111111111(a)172.16.213.38>>;tag=1.* *To: 2222222222 <sip:2222222222@172.16.213.38 <sip%3A2222222222(a)172.16.213.38>>.* Call-ID: 1-12775(a)172.16.213.21. CSeq: 1 INVITE. Max-Forwards: 69. Subject: Performance Test. Content-Type: multipart/mixed;boundary=uniqueBoundary. Content-Length: 788. Contact: <sip:btpsh-58470879-6c61-1@172.16.213.38>. . --uniqueBoundary. Content-Type: application/sdp. . v=0. o=user1 53655765 2353687637 IN IP4 172.16.213.38. s=-. c=IN IP4 172.16.213.38. t=0 0. m=audio 40236 RTP/AVP 8. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-11,16. a=sendrecv. a=rtcp:40237. a=ice-ufrag:QNCzXhUr. a=ice-pwd:Ci90BRpdZH51Hx5BaPgGMrGCeh. a=candidate:P1djl8LFNb5kexbG 1 UDP 2130706431 172.16.213.38 40236 typ host. a=candidate:P1djl8LFNb5kexbG 2 UDP 2130706430 172.16.213.38 40237 typ host. . --uniqueBoundary. Content-Type: application/gtd. Content-Disposition: signal;handling=optional. . IAM,. CGN,04,y,1,y,4,1143617400. CIC,0000000573. CPC,09. CPN,02,y,1,52381660. FCI,n,n,n,n,y,n,n,u. GCI,f7140cc78a611601838a002128d7e512. NOC,0,n,1,n. PRN,q761*,AR*,oper2,1993. TMR,02. . --uniqueBoundary--. ................ # U 2016/12/06 15:52:13.879441 172.16.213.31:5060 -> 172.16.213.38:5060 SIP/2.0 180 Ringing. Via: SIP/2.0/UDP 172.16.213.38;branch=z9hG4bKabaa.840cc83114975a34a37b7af020d37b65.1. *From: 1111111111 <sip:111111111@172.16.213.38 <sip%3A111111111(a)172.16.213.38>>;tag=1.* *To: 2222222222 <sip:2222222222@172.16.213.38 <sip%3A2222222222(a)172.16.213.38>>;tag=2.* Call-ID: 1-12775(a)172.16.213.21. CSeq: 1 INVITE. Contact: <sip:172.16.213.31:5060;transport=UDP>. Content-Type: application/sdp. Content-Length: 137. . v=0. o=user1 53655765 2353687637 IN IP4 172.16.213.31. s=-. c=IN IP4 172.16.213.31. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000. ................ # U 2016/12/06 15:52:13.936565 172.16.213.38:5060 -> 172.16.213.21:5060 SIP/2.0 180 Ringing. *From: sipp <sip:sipp@172.16.213.21:5060 <http://sip:sipp@172.16.213.21:5060>>;tag=1.* *To: sut <sip:5555555555@172.16.213.38:5060 <http://sip:5555555555@172.16.213.38:5060>>;tag=2.* Call-ID: 1-12775(a)172.16.213.21. CSeq: 1 INVITE. Content-Type: application/sdp. Content-Length: 316. Via: SIP/2.0/UDP 172.16.213.21:5060;branch=z9hG4bK-12775-1-0. Contact: <sip:atpsh-58470879-6c61-2@172.16.213.38>. . v=0. o=user1 53655765 2353687637 IN IP4 172.16.213.38. s=-. c=IN IP4 172.16.213.38. t=0 0. m=audio 40248 RTP/AVP 0. a=rtpmap:0 PCMU/8000. a=sendrecv. a=rtcp:40249. a=candidate:P1djl8LFNb5kexbG 1 UDP 2130706431 172.16.213.38 40248 typ host. a=candidate:P1djl8LFNb5kexbG 2 UDP 2130706430 172.16.213.38 40249 typ host. ................ # U 2016/12/06 15:52:20.882165 172.16.213.31:5060 -> 172.16.213.38:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 172.16.213.38;branch=z9hG4bKabaa.840cc83114975a34a37b7af020d37b65.1. *From: 1111111111 <sip:111111111@172.16.213.38 <sip%3A111111111(a)172.16.213.38>>;tag=1.* *To: 2222222222 <sip:2222222222@172.16.213.38 <sip%3A2222222222(a)172.16.213.38>>;tag=2.* Call-ID: 1-12775(a)172.16.213.21. CSeq: 1 INVITE. Contact: <sip:172.16.213.31:5060;transport=UDP>. Content-Type: application/sdp. Content-Length: 213. . v=0. o=user1 53655765 2353687637 IN IP4 172.16.213.31. s=-. c=IN IP4 172.16.213.31. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:20. a=sendrecv. ................ # U 2016/12/06 15:52:21.173798 172.16.213.38:5060 -> 172.16.213.21:5060 SIP/2.0 200 OK. *From: sipp <sip:sipp@172.16.213.21:5060 <http://sip:sipp@172.16.213.21:5060>>;tag=1.* *To: sut <sip:5555555555@172.16.213.38:5060 <http://sip:5555555555@172.16.213.38:5060>>;tag=2.* Call-ID: 1-12775(a)172.16.213.21. CSeq: 1 INVITE. Content-Type: application/sdp. Content-Length: 380. Via: SIP/2.0/UDP 172.16.213.21:5060;branch=z9hG4bK-12775-1-0. Contact: <sip:atpsh-58470879-6c61-2@172.16.213.38>. . v=0. o=user1 53655765 2353687637 IN IP4 172.16.213.38. s=-. c=IN IP4 172.16.213.38. t=0 0. m=audio 40248 RTP/AVP 0. a=rtpmap:0 PCMU/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:20. a=sendrecv. a=rtcp:40249. a=candidate:P1djl8LFNb5kexbG 1 UDP 2130706431 172.16.213.38 40248 typ host. a=candidate:P1djl8LFNb5kexbG 2 UDP 2130706430 172.16.213.38 40249 typ host. ................ # U 2016/12/06 15:52:21.174390 172.16.213.21:5060 -> 172.16.213.38:5060 ACK sip:atpsh-58470879-6c61-2@172.16.213.38 SIP/2.0. Via: SIP/2.0/UDP 172.16.213.21:5060;branch=z9hG4bK-12775-1-4. *From: sipp <sip:sipp@172.16.213.21:5060 <http://sip:sipp@172.16.213.21:5060>>;tag=1.* *To: sut <sip:5555555555@172.16.213.38:5060 <http://sip:5555555555@172.16.213.38:5060>>;tag=2.* Call-ID: 1-12775(a)172.16.213.21. CSeq: 1 ACK. Contact: sip:sipp@172.16.213.21:5060. Max-Forwards: 70. Subject: Performance Test. Content-Length: 0. . ................ # U 2016/12/06 15:52:21.248172 172.16.213.38:5060 -> 172.16.213.31:5060 ACK sip:172.16.213.31:5060;transport=UDP SIP/2.0. Via: SIP/2.0/UDP 172.16.213.38;branch=z9hG4bKabaa.98116b5795d4c30f52156187a72059c8.0. *From: sipp <sip:111111111@172.16.213.38 <sip%3A111111111(a)172.16.213.38>>;tag=1.* *To: sut <sip:2222222222@172.16.213.38 <sip%3A2222222222(a)172.16.213.38>>;tag=2.* Call-ID: 1-12775(a)172.16.213.21. CSeq: 1 ACK. Max-Forwards: 69. Subject: Performance Test. Content-Length: 0. Contact: <sip:btpsh-58470879-6c61-1@172.16.213.38>. . ................ # U 2016/12/06 15:52:51.178826 172.16.213.21:5060 -> 172.16.213.38:5060 BYE sip:atpsh-58470879-6c61-2@172.16.213.38 SIP/2.0. Via: SIP/2.0/UDP 172.16.213.21:5060;branch=z9hG4bK-12775-1-7. *From: sipp <sip:sipp@172.16.213.21:5060 <http://sip:sipp@172.16.213.21:5060>>;tag=1.* *To: sut <sip:5555555555@172.16.213.38:5060 <http://sip:5555555555@172.16.213.38:5060>>;tag=2.* Call-ID: 1-12775(a)172.16.213.21. CSeq: 2 BYE. Contact: sip:sipp@172.16.213.21:5060. Max-Forwards: 70. Subject: Performance Test. Content-Length: 0. . ................ # U 2016/12/06 15:52:51.468639 172.16.213.38:5060 -> 172.16.213.31:5060 BYE sip:172.16.213.31:5060;transport=UDP SIP/2.0. Via: SIP/2.0/UDP 172.16.213.38;branch=z9hG4bK7baa.3cb44935b506e759e3418501b0688b08.0. *From: sipp <sip:111111111@172.16.213.38 <sip%3A111111111(a)172.16.213.38>>;tag=1.* *To: sut <sip:2222222222@172.16.213.38 <sip%3A2222222222(a)172.16.213.38>>;tag=2.* Call-ID: 1-12775(a)172.16.213.21. CSeq: 2 BYE. Max-Forwards: 69. Subject: Performance Test. Content-Length: 0. Contact: <sip:btpsh-58470879-6c61-1@172.16.213.38>. . ................ # U 2016/12/06 15:52:51.469153 172.16.213.31:5060 -> 172.16.213.38:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 172.16.213.38;branch=z9hG4bK7baa.3cb44935b506e759e3418501b0688b08.0. *From: sipp <sip:111111111@172.16.213.38 <sip%3A111111111(a)172.16.213.38>>;tag=1.* *To: sut <sip:2222222222@172.16.213.38 <sip%3A2222222222(a)172.16.213.38>>;tag=2.* Call-ID: 1-12775(a)172.16.213.21. CSeq: 2 BYE. Contact: <sip:172.16.213.31:5060;transport=UDP>. Content-Length: 0. . ................ # U 2016/12/06 15:52:51.519423 172.16.213.38:5060 -> 172.16.213.21:5060 SIP/2.0 200 OK. *From: sipp <sip:sipp@172.16.213.21:5060 <http://sip:sipp@172.16.213.21:5060>>;tag=1.* *To: sut <sip:5555555555@172.16.213.38:5060 <http://sip:5555555555@172.16.213.38:5060>>;tag=2.* Call-ID: 1-12775(a)172.16.213.21. CSeq: 2 BYE. Content-Length: 0. Via: SIP/2.0/UDP 172.16.213.21:5060;branch=z9hG4bK-12775-1-7. Contact: <sip:atpsh-58470879-6c61-2@172.16.213.38>. . ................ exit 13 received, 0 dropped Sorry for my english. Thanks in advance! Diego.

2 7

fix_nated_contact and IPv6
by Sebastian Damm 27 Oct '17

27 Oct '17

Hi, I'm trying to set up a Kamailio (4.1.3) server which converts between IPv6 and IPv4. Everything looks pretty good. Now I have a test client which sends packets via IPv6, but in contact header, SDP etc. there are still IPv4 addresses. (This comes from some converting from v4 to v6 earlier.) Thus, Kamailio tries to do a fix_nated_contact(). But after fixing, the Contact URI is wrong. Example: inbound Contact: <sip:bob@192.168.8.132> outbound Contact: <sip:bob@1234:1234:0:1234:0:0:0:2> The correct way of transforming the Contact URI would be: Contact: <sip:bob@[1234:1234:0:1234:0:0:0:2]> This incorrect Contact URI doesn't hurt first, but when the called party wants to hang up the call, it addresses the URI from Contact header, and Kamailio can't parse the Request URI: Jan 22 12:03:48 router /usr/sbin/kamailio[21309]: ERROR: pv [pv_core.c:304]: pv_get_ruri_attr(): failed to parse the R-URI Jan 22 12:03:48 router /usr/sbin/kamailio[21309]: ERROR: rr [loose.c:934]: loose_route(): failed to parse Request URI Jan 22 12:03:48 router /usr/sbin/kamailio[21309]: ERROR: domain [domain.c:140]: is_uri_host_local(): error while parsing R-URI Is this a bug in the nathelper module? Was it never meant to handle IPv6 addresses? Or do I understand something wrong? Best Regards, Sebastian

4 4