sr-users January 2017

sr-users@lists.kamailio.org

87 participants
114 discussions

Cannot hear voice with symmetric NAT and STUN
by Khoa Pham 08 Feb '17

08 Feb '17

Hi, I have Kamailio as SIP server and RTP server. Client is PJSIP. I read that STUN is for non-symmetric NAT, and RTP server is for symmetric NAT. Supposed A calls B. If A, B both use symmetric NAT and STUN, they cannot hear each other If A or B use non-symmetric NAT and NOT using STUN, they cannot hear each other. Why is that? I read http://tools.ietf.org/id/draft-takeda-symmetric-nat-traversal-00.txt for Prediction Failure, is that related to this problem ? -- Khoa Pham HCMC University of Science Faculty of Information Technology

8 18

Diversion Header - relay messed up
by Roman Dissauer 08 Feb '17

08 Feb '17

When I get an INVITE with Diversion Header the Request is forwarded without Diversion Header and the Request User is taken from Diversion User. Problem is that on the Destination Host I cannot get original Request User what is the intended destination! Is this intended behaviour? How can I change this behaviour? I already tried to delete the Diversion Header on request_route but this didn’t change the behaviour. Thanks in andvance for your help! Roman Here The INVITEs with x.x.x.x as Kamailio external IP and y.y.y.y as Carrier IP Incoming INVITE: INVITE sip:+43123456789@x.x.x.x:5060 SIP/2.0. Via: SIP/2.0/UDP y.y.y.y:5060;branch=z9hG4bK02B7871714d9345f843. From: <sip:+43987654321@y.y.y.y>;tag=gK022ac5cb. To: <sip:436761234567@x.x.x.x>. Call-ID: 906143813_44460603(a)y.y.y.y. CSeq: 28100 INVITE. Max-Forwards: 19. Allow: INVITE,ACK,CANCEL,BYE,REGISTER,REFER,INFO,SUBSCRIBE,NOTIFY,PRACK,UPDATE,OPTIONS. Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay, multipart/mixed. Contact: <sip:+43987654321@y.y.y.y:5060>. P-Asserted-Identity: <sip:+43987654321@y.y.y.y:5060>. Diversion: <sip:+436761234567@y.y.y.y:5060>;privacy=full;screen=no; reason=unconditional; counter=1. Supported: timer,100rel. Session-Expires: 1800. Min-SE: 90. Content-Length: 260. Content-Disposition: session; handling=required. Content-Type: application/sdp. ... Relayed INVITE: INVITE sip:436761234567@x.x.x.x:5060 SIP/2.0. Record-Route: <sip:10.23.101.1;r2=on;lr=on;ftag=gK022ac5cb>. Record-Route: <sip:x.x.x.x;r2=on;lr=on;ftag=gK022ac5cb>. Via: SIP/2.0/UDP 10.23.101.1;branch=z9hG4bK8582.4fc0216dbecafde29127db502993222c.0. Via: SIP/2.0/UDP y.y.y.y:5060;rport=5060;branch=z9hG4bK02B7871714d9345f843. From: <sip:+43987654321@y.y.y.y>;tag=gK022ac5cb. To: <sip:436761234567@x.x.x.x>. Call-ID: 906143813_44460603(a)y.y.y.y. CSeq: 28100 INVITE. Max-Forwards: 18. Allow: INVITE,ACK,CANCEL,BYE,REGISTER,REFER,INFO,SUBSCRIBE,NOTIFY,PRACK,UPDATE,OPTIONS. Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay, multipart/mixed. Contact: <sip:+43987654321@y.y.y.y:5060>. P-Asserted-Identity: <sip:+43987654321@y.y.y.y:5060>. Supported: timer,100rel. Session-Expires: 1800. Min-SE: 90. Content-Length: 274. Content-Disposition: session; handling=required. ...

3 3

Second coredump in a month
by Jon Bonilla (Manwe) 08 Feb '17

08 Feb '17

Hi all A server running version 4.4.4+0~20161223011227 has segfaulted for the second time this month. I'm attaching a bt in case someone can explain it to me. cheers, Jon

2 12

Kamailio parse failed message
by Hai Bui Duc Ha 07 Feb '17

07 Feb '17

Hi all, I have problem when make call with my Android mobile use PJSIP library. Scenario: my client -> Kamailio -> Freeswitch (media server) -> another client (soft phone on Windows) my client: + use Bluestack + Capture via Wireshark + use Wifi Issue: The call will be drop after ~ 30 second. I see the error on Kamailio: *Jan 5 16:08:59 ab-kz-02 kamailio[6343]: ERROR: <core> [parser/parse_fline.c:257]: parse_first_line(): parse_first_line: bad message (offset: 13)* *Jan 5 16:08:59 ab-kz-02 kamailio[6343]: ERROR: <core> [parser/parse_fline.c:257]: parse_first_line(): parse_first_line: bad message (offset: 13)* *Jan 5 16:08:59 ab-kz-02 kamailio[6343]: ERROR: <core> [parser/msg_parser.c:690]: parse_msg(): ERROR: parse_msg: message=<p:8 PCMA/8000#015#012a=rtpmap:101 telephone-event/8000#015#012a=fmtp:101 0-16#015#012ACK sip:buiduchahai@125.212.212.36:11000;transport=tcp SIP/2.0#015#012Via: SIP/2.0/TCP 10.0.2.15:57735;rport;branch=z9hG4bKPjlgc13AjrUrFJHq60vWhGqsUaGXi2F98Z;alias#015#012Max-Forwards: 70#015#012From: "Phap Huynh" <sip:huynhngocphap@happy.anttel-pro.ab-kz-02.antbuddy.com <sip%3Ahuynhngocphap(a)happy.anttel-pro.ab-kz-02.antbuddy.com>>;tag=zJBNvD67y3E.1I5Y5ZrRI4JmP5JKeNWO#015#012To: <sip:buiduchahai@happy.anttel-pro.ab-kz-02.antbuddy.com <sip%3Abuiduchahai(a)happy.anttel-pro.ab-kz-02.antbuddy.com>>;tag=2SF4D790Zy6Kj#015#012Call-ID: ftMudIpIQeKWwP8kQDi2z1S0D1sV3KaB#015#012CSeq: 29055 ACK#015#012Route: <sip:125.212.212.40;transport=tcp;lr;ftag=zJBNvD67y3E.1I5Y5ZrRI4JmP5JKeNWO>#015#012Content-Length: 0#015#012#015#012>* *Jan 5 16:08:59 ab-kz-02 kamailio[6343]: ERROR: <core> [receive.c:129]: receive_msg(): core parsing of SIP message failed (49.156.54.54:50785/2 <http://49.156.54.54:50785/2>)* Seem to the server error when parse (on INVITE SDP) *a=rtpmap:8 PCMA/8000a=rtpmap:101 telephone-event/8000a=fmtp:101 0-16* (on new ACK message) *ACK sip:buiduchahai@125.212.212.36:11000;transport=tcp SIP/2.0* *Via: SIP/2.0/TCP 10.0.2.15:57735;rport;branch=z9hG4bKPjlgc13AjrUrFJHq60vWhGqsUaGXi2F98Z;alias* *Max-Forwards: 70* *From: "Phap Huynh" <sip:huynhngocphap@happy.anttel-pro.ab-kz-02.antbuddy.com <sip%3Ahuynhngocphap(a)happy.anttel-pro.ab-kz-02.antbuddy.com>>;tag=zJBNvD67y3E.1I5Y5ZrRI4JmP5JKeNWO* *To: <sip:buiduchahai@happy.anttel-pro.ab-kz-02.antbuddy.com <sip%3Abuiduchahai(a)happy.anttel-pro.ab-kz-02.antbuddy.com>>;tag=2SF4D790Zy6Kj* *Call-ID: ftMudIpIQeKWwP8kQDi2z1S0D1sV3KaB* *CSeq: 29055 ACK* *Route: <sip:125.212.212.40;transport=tcp;lr;ftag=zJBNvD67y3E.1I5Y5ZrRI4JmP5JKeNWO>* *Content-Length: 0* I think the SIP message is fragmented but when resume package is not correct. Do you have any advice ? Thank you for watching ! Regards, Hai Bui -- Hai Bui VoIP engineer, Cvoice team, HTK-HCM Office Mobile: +84-165-618-9876

2 11

FOSDEM 2017
by Daniel-Constantin Mierla 07 Feb '17

07 Feb '17

Hello, another edition of FOSDEM is approaching, about 2 weeks left: - https://fosdem.org/2017/ Couple of devs and many Kamailio friends will be around. Like past year, there is a Realtime Communications devroom, this edition on Sunday. Very interesting presentation for our ecosystem: Olle giving a presentation about IPv4/IPv6, Inaki introducing its SFU media server project, Jose talking about JsSIP, Daniel debating about fundraising FreeRTC, Lorenzo with Janus SIP-WebRTC gateway, the other Lorenzo with Homer Sipcature, Saul with Jitsi, Dan with cgrates, Matt with Asterisk, Giovanni with FreeSwitch... Schedule at: - https://fosdem.org/2017/schedule/track/real_time_communications/ On Sunday morning, part of Lua devroom, I will present about using Lua for building RTC services with Kamailio: - https://fosdem.org/2017/schedule/track/lua/ - https://fosdem.org/2017/schedule/event/luartcserviceskamailio/ During the past editions we organized a dinner on Saturday evening. Shall we attempt to do it again in advance this year? Or should we do it on spot based on the weather and mood at the end of Saturday? Cheers, Daniel -- Daniel-Constantin Mierla www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Mar 6-8 (Europe) and Mar 20-22 (USA) - www.asipto.com Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com

7 13

kamailio proxy behind firewall
by JBF 07 Feb '17

07 Feb '17

Hello, we have the following Configuration for our kamailio installation (we are using TLS and not udp) (1) F5 Firewall (configured as message fowarding), opening a TLS server on the outside (2) SIP proxy, with a TLS server accessed by the F5 . The SIP proxy doesnt see the F5 TLS server (3) SIP registrar REGISTER works find We have the following issue on INVITE: A sends an INVITE to B. The Registrar patches the R-URI with the content of location, which contains the publi ip of the Device (because the device used stun) we force the routing from registrar to proxy by using t_relay (SIP_PROXY_IP) /The proxy tries to route to this R-URI, which is not visible/ I am not sure how to fix that: Record Route is for a true sip proxy, but the Firewall does not have an server facing the SIP proxy: the sip proxy needs to find the proper client socket opened at register to route the INVITE We have arranged for the Firewall to add its own Via, but if i understand correctly, this is used for replies, and here we are dealing with a request forwarding, and t_relay uses the r-ruri to route requests. IT might be why REGISTER works correctly (ie the 200 OK is routed correctly from proxy to firewall) I could arrange for the location table to contain the private ip and port of the firewall connection (through the use of the received/rport info inserted in the Via by the proxy ) That would mean, however that the contact of the user will contain the private interface of the F5 which i found weird. How do you think i should proceed ? any advices are welcome Thank you -- View this message in context: http://sip-router.1086192.n5.nabble.com/kamailio-proxy-behind-firewall-tp15… Sent from the Users mailing list archive at Nabble.com.

2 3

SIP message order
by Andy Chen 06 Feb '17

06 Feb '17

Hello sr-users, First of all, I'm new to this forum so any help would be greatly appreciated as my Kamailio knowledge is somewhat limited. Thanks for your patience. So to the question at hand. If the originator of the SIP method sends SIP messages out of order, does the Kamailio put them back in order before relaying it to the destination device? I'm seeing where the 200 OK was sent first before the SIP UPDATE within the same CSeq number. The reason I'm asking is because I'm seeing this behavior now with UDP transport protocol and I'm trying to justify why we don't need to switch to TCP to fix this issue. Thanks. --Andy

2 1

sdp_with_transport
by M. Salman 01 Feb '17

01 Feb '17

Hi Guys, Just wanted to clarify the following case: what should be result of sdp_with_transport("RTP/SAVPF") on line: m=audio 10231 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 126 I am having a weird behavior for two different versions of Kamailio. I hope I am doing something wrong. kamailio 4.3.2 => sdp_with_transport("RTP/SAVPF") = true kamailio 4.4.5 => sdp_with_transport("RTP/SAVPF") = false -- Regards M. Salman VoIP Professional

3 2

any public databases or schemas for dial plans?
by Daniel Pocock 31 Jan '17

31 Jan '17

Hi, Are there any public databases of dial plan information? Are there any schemas (e.g. XML / XSD) useful for describing arbitrary dial plans from different carriers around the world? The type of things that I'm interested in: - being able to translate any local number to E.164 (if possible) - knowing the expected length (or range of lengths) for different numbers - being able to recognize numbers that can't be translated to E.164 (e.g. the emergency numbers) - being able to classify specific types of number that usually have a carrier-specific or country-specific meaning (e.g. classifying numbers as directory assistance, customer service, emergency) I'm familiar with Google's libphonenumber, although it is not a database, rather, it is a library that has dial plan logic in Java. It supports many of the things I want for numbers that can be translated to E.164 and country-level dial plans, but not local dial plans (e.g. dialing a London number without the 020 area code). Regards, Daniel

2 2

Using DNS for Service Discovery with Kamailio
by Casco, Alessio 31 Jan '17

31 Jan '17

Hello Guys! I'd like to be able to use SRV records inside dispatcher groups, so I can automatise the discovery of new backends on my network using DNS I've tried with the following formats into the dispatcher.list file: $group _sip._udp.sip-voice_backends $group sip-voice_backends and none looks to be working, running the kamailio_ctl dispatcher.list won't show me the group set with SRV records. ( I also try NAPTR records, with no luck as well.) * Does the dispatcher module support SRV or NAPTR records? (maybe my format is not correct) * If not, do you have any other idea on what I could do to achieve what I'd like to do? Thanks Alessio

3 7

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users January 2017