sr-users

sr-users@lists.kamailio.org

42 participants
37519 discussions

Maintaining order of messages in a sip dialog on forwarding
by Daniel Tryba 05 Aug '15

05 Aug '15

Since switching to 4.2.5 (from 3.x) a customer has problems with a buggy user agent (IMHO). What I am seeing now is: provider kamailio customer INVITE1-> INVITE1-> <-Trying <-Trying <-200 OK <-200 OK ACK1-> INVITE2-> INVITE2-> ACK1-> ACK1 arrives 0.007s before INVITE2, but INVITE2 is send 0.004s before ACK1. It looks like this wasn't happening with Kamailio 3.x, it worked fine then (apparently). Can this reordering be (gracefully) prevented somehow (ignoring the fact that during transport reordering can happen)? A Q&D hack looks to be just usleep the reinvite a little. The endpoint is essentially ignoring the reinvite before (and after) the ACK. After a timeout INVITE2 is canceled and after that INVITE1 will be ended with a BYE from provider. kamailio-customer communication is UDP provider-kamailio is tcp when message >= 1300b. INVITE1 is TCP, INVITE2 and ACK1 are UDP.

2 5

VIA header question.
by Chad 04 Aug '15

04 Aug '15

Hi list, I need a little help, I am a business owner trying to get Kamailio up and running as a SIP load balancer. I hired a Kamailio consultant to help me do so, but Kamailio is not working and I am getting conflicting information. My Kamailio consultant and my VOIP provider are telling me 2 different things and I don't know which one is right. Kamailio sends SIP traffic to the VOIP provider with 2 VIA headers like this (in this order): Via: SIP/2.0/UDP 10.10.10.254;branch=z9hG4bK7291.6a0bbd2e8fd639a47d7d2de606779e47.0. Via: SIP/2.0/UDP 209.170.201.25:5060;received=10.10.10.102;branch=z9hG4bK742dc03d;rport=5060. The VOIP provider says that is incorrect because they are supposed to reply back to the topmost VIA header so they reply to the 10.10.10.254 IP (which is not public) and the call ends. The VOIP provider says Kamailio should send the VIA headers like this instead: Via: SIP/2.0/UDP 209.170.201.25:5060;received=10.10.10.102;branch=z9hG4bK742dc03d;rport=5060. Via: SIP/2.0/UDP 10.10.10.254;branch=z9hG4bK7291.6a0bbd2e8fd639a47d7d2de606779e47.0. My Kamailio consultant says the way we are sending it is right and that the VOIP provider is processing the call incorrectly. I read that the SIP proxy is supposed to remove the internal header from the 1st example above based on this RFC: https://tools.ietf.org/html/rfc3261#section-16.7 Item: 3. Via "The proxy removes the topmost Via header field value from the response." If that applies to this situation (which I don't know if it does) then Kamailio should be removing the 10.10.10.254 VIA line and only sending 1 VIA header like this: Via: SIP/2.0/UDP 209.170.201.25:5060;received=10.10.10.102;branch=z9hG4bK742dc03d;rport=5060. Which would sort of make the VOIP provider right in that the topmost VIA line would then be the external IP, but how they said to fix it (reversing the VIA lines) is wrong. Does anyone know what the right answer is here? Please let me know. THANKS for your help. -- ^C

3 3

MSILO: Archiving every message
by SamyGo 03 Aug '15

03 Aug '15

Hi, Tried finding anything as weird as I am trying to do on mailing list but couldn't. The idea is to save a copy of the messages on database. MSILO module can keep the message as long as the destination user is offline, or doesn't support method:MESSAGE or expiry timeout. Any ideas will be appreciated. Best Regards, Sammy

2 2

Re: [SR-Users] Mutiple branch forking and voicemail
by Daniel-Constantin Mierla 03 Aug '15

03 Aug '15

Hello, On 31/07/15 11:31, Marino Mileti wrote: > Hello, > > I would like to implement a voicemail services but i'm trying everything > without good results :( > > My scenario is: > > - A make a parallel forking to B(1001) and C(1002) > - If timeout, call is routed to voicemail > > I've done something like this...very simple > > seturi("sip:1001@172.20.40.103"); > > append_branch("1002(a)172.20.40.103"); > route(RELAY) > > on failure_route.. > if (t_check_status("486|408")) { > $ru = "sip:8000@172.20.40.103:5090"; > > route(RELAY); > > exit; > > } > > The scenario is working but on log there are some error... > t_should_relay_response > > I would like that when a branch reach the failure route, all other branches > will be cancelled..and call is routed to VM. > Can anyone help me? > > When the failure_route is executed, no branch is active anymore. To be able to assist further, you have to send here the errors you get in the log, to understand what is wrong. Cheers, Daniel -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Book: SIP Routing With Kamailio - http://www.asipto.com

2 1

www.kamailio.org unreachable via ipv6
by Daniel Tryba 03 Aug '15

03 Aug '15

(www.)kamailio.org is unreachable at this time (the whole morning) on 2a00:d60:0:400::2. ipv4 is responsing. Never noticed whether connectivity via ipv6 was working in the past or this is new and misconfigured.

2 1

Announcement: Kamailio is now systemd-rtc-server
by Alex Balashov 03 Aug '15

03 Aug '15

For immediate release: ATLANTA, GA (1 April 2015)--Evariste Systems LLC, an Atlanta-based software vendor specialising in Kamailio-based service delivery solutions for the VoIP ITSP market, is pleased to announce that it, in collaboration with Red Hat Software and Ringfree Communications, has finalised the absorption of the Kamailio SIP Server into the 'systemd' system management platform for Linux. The new component shall be called 'systemd-rtc-server', or 'Systemd Real-Time Communication Server'. Alex Balashov, principal of Evariste and leader of the tri-vendor collaboration effort, will officially announce the handover of the reigns of the Kamailio project to the personal leadership of Lennart Poettering at the upcoming Systemd Real Time Communications World conference, to be held in Berlin on 27-29 May of this year. John Knight, Director of GNOME 3 Integration and part-time usability consultant at Ringfree Communications, based in Hendersonville, North Carolina,was quick to summarise the triumphs of the long-standing integration effort. Remarked Knight: "The industry has recognised for years that a SIP proxy is a basic building block in the 'init' subsystem of any Linux host. In this age of multimedia communication with voice and video, it was a travesty that systemd handled time synchronisation, network configuration, login management, logging, and console, but not SIP message routing." Sean McCord, a veteran partner at Atlanta-based integrator CyCORE & Docker, was quick to concur: "SIP calls are much easier to troubleshoot with binary logs. Combined with packet captures of TLS-encrypted WebRTC calls, systemd-journald is the ultimate call setup troubleshooting methodology of the responsive, kinetic enterprise." To support the integration of Kamailio into the ecosystem of every major Linux distribution, Evariste has released new 'dbus_api' and 'pulseaudio' modules for the project. Balashov stated, "We fully expect to use the D-Bus API to achieve gnome-session integration with systemd-rtc-server-usrloc, but we aren't going to leave Windows users behind; KamailioSvcHost.exe will support Domain Controller policies for G.722 in Active Directory forests." Despite an aggressive delivery timeline by the tri-vendor consortium behind systemd-rtc-server, industry commentators have widely lambasted the fact that it took so long for Kamailio to become integrated into systemd. Fred Posner, solutions architect at The Palner Group in Fort Lauderdale, Florida, recently wrote in a widely-publicised blog post: "sr-dev have been keeping their heads in the sand for too long. For years now, it has been completely obvious and self-evident to anyone with half a brain that all kinds of VoIP software should be included in systemd. It's a basic building block of the whole OS, having absorbed functionality previously provided by all kinds of packages like util-linux and wireless-tools." John Knight of Ringfree accepted the criticism readily, but advocated a forward-thinking orientation focused on breaking with the uncertainty of the past: "In the absence of a SIP component for routing calls to the PSTN, some people thought, 'systemd has no clear direction apart from the whims of its developers, and is a perpetually moving goal post.' Well, a SIP server should put an end to that whole discussion; that's exactly what was missing, and now that we have systemd-rtc-server, we've eliminated all doubts about the coherence, conceptual integrity and finality of systemd." -- Alex Balashov | Principal | Evariste Systems LLC 303 Perimeter Center North, Suite 300 Atlanta, GA 30346 United States Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

5 8

Check if user is registered before reply is routed
by Dmytro Bogovych 01 Aug '15

01 Aug '15

Greetings. Sorry for previous false letter. I want to check if user is registered before reply is routed to its target user agent. Imho it should be like this: onreply_route[MANAGE_REPLY] { if ($rm=="INVITE") { if (registered("location", $ru)) { # Do job - pause for 15 seconds and give chance to reregister } } } But kamailio complains on registered function 0(6274) ERROR: <core> [cfg.y:3295]: yyparse(): misused command registered 0(6274) : <core> [cfg.y:3439]: yyerror_at(): parse error in config file /usr/local/etc/kamailio/kamailio.cfg, line 1121, column 35: Command cannot be used in the block Documentation confirms - registered() function can be used in REQUEST_ROUTE and FAILURE_ROUTE only. Is it possible to check if user is registered when reply is processed in scripts? Thank you!

4 3

Interpretation of Contact header
by Joachim Büchse 30 Jul '15

30 Jul '15

Good day, I’m experiencing some problems with our VoiP providers handling of REGISTER requests. We are using a Gigaset PRO N720 as UAC behind a Juniper SSG 140 with SIP-Alg enabled. This setup kind of works with UDP but our provider wants us to use TCP. With TCP enforced incoming calls don’t work. I’ve done some wire tracing and to me it seems that the providers configuration is to blame, but then - there are many RFCs out there and many NAT and UAC bug workarounds. Anyway, I wanted to get the opinion of “the" experts about how the requests send to the UAS SHOULD be correctly interpreted. The REGISTER requests/responses look like this (outside of the firewall): Protocol TCP! client port 19091 <-> server port 5060 REGISTER sip:pbx.peoplefone.ch SIP/2.0 Via: SIP/2.0/TCP 212.126.160.92:6717;rport;branch=z9hG4bKc1375589832468de63a719eac31156ec From: "Michel" <sip:90780408050@pbx.peoplefone.ch>;tag=2153084485 To: "Michel" <sip:90780408050@pbx.peoplefone.ch> Call-ID: 2825358480@10_10_128_10 CSeq: 1 REGISTER Contact: <sip:90780408050@212.126.160.92:6717;transport=tcp> Max-Forwards: 70 User-Agent: N720-DM-PRO/70.089.00.000.000 Expires: 180 Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, INFO, REFER, SUBSCRIBE, NOTIFY Content-Length: 0 SIP/2.0 401 Unauthorized Via: SIP/2.0/TCP 212.126.160.92:6717;rport=19091;branch=z9hG4bKc1375589832468de63a719eac31156ec From: "Michel" <sip:90780408050@pbx.peoplefone.ch>;tag=2153084485 To: "Michel" <sip:90780408050@pbx.peoplefone.ch>;tag=a0440f545f39b2694d387b475a5f6bc9.b8fc Call-ID: 2825358480@10_10_128_10 CSeq: 1 REGISTER WWW-Authenticate: Digest realm="pbx.peoplefone.ch", nonce="VNqJBVTah9m57ZGGs8b5XCTM3GyaExDy" Server: kamailio (3.2.1 (x86_64/linux)) Content-Length: 0 REGISTER sip:pbx.peoplefone.ch SIP/2.0 Via: SIP/2.0/TCP 212.126.160.92:6717;rport;branch=z9hG4bK9c27afea96e2af4baab2f8d144a588e0 From: "Michel" <sip:90780408050@pbx.peoplefone.ch>;tag=2153084485 To: "Michel" <sip:90780408050@pbx.peoplefone.ch> Call-ID: 2825358480@10_10_128_10 CSeq: 2 REGISTER Contact: <sip:90780408050@212.126.160.92:6717;transport=tcp> Authorization: Digest username="90780408050", realm="pbx.peoplefone.ch", uri="sip:pbx.peoplefone.ch", nonce="VNqJBVTah9m57ZGGs8b5XCTM3GyaExDy", response="764f371a08d258157a249f8d1b852514" Max-Forwards: 70 User-Agent: N720-DM-PRO/70.089.00.000.000 Expires: 180 Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, INFO, REFER, SUBSCRIBE, NOTIFY Content-Length: 0 SIP/2.0 200 OK Via: SIP/2.0/TCP 212.126.160.92:6717;rport=19091;branch=z9hG4bK9c27afea96e2af4baab2f8d144a588e0 From: "Michel" <sip:90780408050@pbx.peoplefone.ch>;tag=2153084485 To: "Michel" <sip:90780408050@pbx.peoplefone.ch>;tag=a0440f545f39b2694d387b475a5f6bc9.6bda Call-ID: 2825358480@10_10_128_10 CSeq: 2 REGISTER Contact: <sip:90780408050@212.126.160.92:6717;transport=tcp>;q=0;expires=180;received="sip:212.126.160.92:19091;transport=TCP" Server: kamailio (3.2.1 (x86_64/linux)) Content-Length: 0 The ip:port the firewall is sending those requests from is ip 212.126.160.92 port 19091. So this does NOT match the port from the Contact header. For TCP this seems rather logical to me, as one cant be listening on a TCP port and use it for sending at the same time. The UAC closes this “register connection” with TCP FIN after the register, and so does the firewall. However unfortunately subsequent requests from the provider (ie UAS) come in on port 19091 (not port 6717 from the Contact header) and the firewall simply drops them. Observations: - the server does NOT include received=212.126.160.92 in the Via of the reponse. According to RFC3581 this is mandatory when rport is present in the request, so this is probably an error in the server. - the server does include received="sip:212.126.160.92:19091;transport=TCP” in the Contact of the response. I didnt see this in any RFC (which means nothing;-) but it could be an error. - after the client received the 200 OK it closes the TCP connection. - the server tries several times to re-contact the client (incoming TCP SYN). However not on port 6717 (defined in the Contact header) but on port 19091 (where the REGISTER came from). RFC3581 defines special behaviour when “rport” is defined in the request (i.e. response should go to the same port the request came from) - however it’s not so clear if this should apply to subsequent (INVITE/OPTIONS) requests from the server to the client. Those are strictly spoken not replies (or are they?). RFC5626 defines that a “proxy” should keep track of the flows over which it received a registration and send requests over the same flow. It is not clear if RFC5626 should be applied. The RFC5626 defines that a UAC includes an “ob” parameter in the Contact field if it whishes further requests over the same flow. Also the RFC mandates a client to add a "reg-id=x" in the Contact field. Both are not the case here, so in short I think RFC5626 should NOT be applied. In which case conecting to the originating port (instead of the Contact port) would be a server error. So in short and if I interpret the RFCs correctly, the client is reachable and should be contacted on Transport: TCP IP: 212.126.160.92 Port: 6717 If anyone who lives and breathes SIP could enlighten me if the UAS is right to call back on 19091 instead of 6717 I would really appreciate it;-)) Best regards, Joachim

3 4

Issue with ACK behind NAT
by Alberto Sagredo 30 Jul '15

30 Jul '15

I have Kamailio in a local network with RTPPROXY and NAT MANAGE I have seen an issue with ACK as show when Asterisk sends ACK to Kamailio, it sends to advertised Address instead to Kamailio IP address. What could i add to solve this? route[WITHINDLG] { if (has_totag()) { # sequential request withing a dialog should # take the path determined by record-routing if (loose_route()) { if (is_method("BYE")) { setflag(FLT_ACC); # do accounting ... setflag(FLT_ACCFAILED); # ... even if the transaction fails dlg_manage(); } if ( is_method("ACK") ) { # ACK is forwarded statelessy route(NATMANAGE); } route(RELAY); } else { if (is_method("SUBSCRIBE") && uri == myself) { # in-dialog subscribe requests route(PRESENCE); exit; } if ( is_method("ACK") ) { if ( t_check_trans() ) { # no 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 exit; } } sl_send_reply("404","Not here"); } exit; } } BR

2 14

Re: [SR-Users] Memory Issue while accessing $rb (prakash)
by Surendra.P 30 Jul '15

30 Jul '15

Hi Prakash, Specify the more private memory with -M option, while running kamailio Like -M 64 :-) Regards @surendra

1 0

Jump to page:

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