- sr-users - kamailio.org

(no subject)
by Alberto Llamas 17 Mar '17

17 Mar '17

Hi Guys, Who knows and can recommend a company a company where I could order Toll free numbers for EU?. I really appreciate any hint and sorry for the noise. Regards, -- Alberto Llamas Telecommunications Engineer dCAP | KPAC | SSCA *"Internet is all about share"*

2 1

cisco spa502g issues
by Ben Kramer 17 Mar '17

17 Mar '17

Hi guys, we have a bunch of SIP phones behind a fire wall, with our kamalio server out on the internet. Most of them are the older SPA92x series, but we have some new SPA502g's. We have no problems calling between 92x and 502's. How ever the 502's calling each other do not get voice path. I have noticed that the phones REGISTER differently: AOR:: 5546@<our domain> Contact:: sip:5546@<OUR OFFICE IP>:1032 Q= Expires:: 180 Callid:: 4754c4f9-c67e1018(a)10.0.41.29 Cseq:: 43112 User-agent:: Cisco/SPA502G-7.6.2a State:: CS_DIRTY Flags:: 0 Cflag:: 0 Socket:: udp:<OUR SR IP>:5060 Methods:: 6815 AOR:: 5590(a)sip.skunkworks.net.au Contact:: sip:5590@10.0.41.14:5060 Q= Expires:: 1154 Callid:: 24435738-224b06db(a)10.0.41.14 Cseq:: 8012 User-agent:: Linksys/SPA921-5.1.8 Received:: sip:<OUR OFFICE IP>:1026 State:: CS_SYNC Flags:: 0 Cflag:: 64 Socket:: udp:<OUR SR IP>:5060 Methods:: 4767 The older 921 has its private IP in the contact, where as the newer 502 has the external IP of our office in the contact. Our file wall is a Watchguard T-10 (latest updates etc) with the SIP-ALG running. Any thoughts on where to start looking ? Cheers, Ben.

1 0

send_all blocks indefinitely
by Robert 16 Mar '17

16 Mar '17

H all, Recently, when I'm trying to load test Kamailio with a single proxy, it hung at around 15000 TPS. I attached gdb to one of the kamailio processes and I saw this: (gdb) where #0 0x00007fa8872366ad in __libc_send (fd=13, buf=0x7ffe6e0e5350, n=16, flags=-2027723091) at ../sysdeps/unix/sysv/linux/x86_64/send.c:27 #1 0x00000000004eb635 in send_all (socket=13, data=0x7ffe6e0e5350, data_len=16) at pass_fd.c:133 #2 0x00007fa4155a1b69 in tcp_close_connection (conn_id=28022) at tcp_funcs.c:199 #3 0x00007fa4155a363f in cleanup (start=0x7fa4540c3ab8, end=0x7fa42f92dca0) at tcp_funcs.c:337 #4 0x00007fa4155a1496 in timer_clean_tcp_connections (ticks=18583555, param=0x0) at tcp_funcs.c:165 #5 0x0000000000617f79 in fork_basic_timer (child_id=-1, desc=0x7fa4155a88e0 "Connections cleanup timer", make_sock=1, f=0x7fa4155a0ac6 <timer_clean_tcp_connections>, param=0x0, interval=30) at timer_proc.c:79 #6 0x00007fa4155a5816 in child_init (rank=0) at tcp_mod.c:176 tcp_func.c is something I wrote myself, which is basically a timer that runs periodically to try to clean up tcp connections that I no longer need. The code for tcp_close_connection is taken directly from usrloc > urecord.c > close_connection() >From the gdb output above, it seems like send_all is blocked and never returned, which led to my proxy to hang. In kamailio/src/core/pass_fd.c, I saw this: ... /** sends all data (takes care of signals) (assumes blocking fd) * returns number of bytes sent or < 0 for an error */ int send_all(int socket, void* data, int data_len) But in kamailio/doc/misc/TODO, I saw this: ... x [tcp] make send_all, send non-blocking ready ? x [tcp] tcp_send w/ timeout (to avoid waiting forever to send DOS) So, my question is, is send_all() suppose to block or not? I'm fairly new to how tcp and socket connection works. Any help will be appreciated! Thanks, Robert -- View this message in context: http://sip-router.1086192.n5.nabble.com/send-all-blocks-indefinitely-tp1569… Sent from the Users mailing list archive at Nabble.com.

1 0

Cdr on shutdown
by Diego Nadares 16 Mar '17

16 Mar '17

Hi Guys, Is it possible to generate cdrs or to save dialogs to db when kamailio receives a kill signal from terminal? Thanks in advance. Diego

3 5

siptrace duplicate both incoming and outgoing messages
by Grant Bagdasarian 16 Mar '17

16 Mar '17

Hi, Is it possible to instruct Kamailio to duplicate both incoming and outgoing messages automatically? If not, if I set the flag and explicitly call sip_trace, will both messages be duplicated to the capture server? Regards, Grant Bagdasarian CM

2 1

mi_fifo: No module matching <jsonrpcs> found
by Mostafa Zare 15 Mar '17

15 Mar '17

hi guys i'm newbie to kamailio. i've installed kamailio version 5 (and all the modules) from pkgs on a jessie debian. i have the below config on my kamailio.cfg when i try to start kamailio service it throws the following error. what's the problem? - systemctl status kamailio: kamailio.service - Kamailio (OpenSER) - the Open Source SIP Server Loaded: loaded (/lib/systemd/system/kamailio.service; enabled) Active: failed (Result: exit-code) since Wed 2017-03-15 19:01:17 IRST; 10s ago Process: 9377 ExecStart=/usr/sbin/kamailio -P /var/run/kamailio/kamailio.pid -f $CFGFILE -m $SHM_MEMORY -M $PKG_MEMORY -u $USER -g $GROUP (code=exited, status=255) Main PID: 1576 (code=exited, status=0/SUCCESS) Mar 15 19:01:17 kamailio-debian kamailio[9377]: ERROR: <core> [core/modparam.c:152]: set_mod_param_regex(): No module matching <jsonrpcs> found Mar 15 19:01:17 kamailio-debian kamailio[9377]: CRITICAL: <core> [core/cfg.y:3404]: yyerror_at(): parse error in config file /etc/kamailio/kamailio.cfg, line 103, column 72: Can't set module parameter Mar 15 19:01:17 kamailio-debian kamailio[9377]: ERROR: <core> [core/modparam.c:141]: set_mod_param_regex(): parameter <ds_probing_threshhold> of type <2> not found in module <dispatcher> Mar 15 19:01:17 kamailio-debian kamailio[9377]: CRITICAL: <core> [core/cfg.y:3404]: yyerror_at(): parse error in config file /etc/kamailio/kamailio.cfg, line 135, column 50: Can't set module parameter Mar 15 19:01:17 kamailio-debian kamailio[9377]: ERROR: bad config file (4 errors) Mar 15 19:01:17 kamailio-debian kamailio[9377]: INFO: <core> [core/sctp_core.c:53]: sctp_core_destroy(): SCTP API not initialized Mar 15 19:01:17 kamailio-debian kamailio[9377]: loading modules under config path: /usr/lib/x86_64-linux-gnu/kamailio/modules/ Mar 15 19:01:17 kamailio-debian systemd[1]: kamailio.service: control process exited, code=exited status=255 Mar 15 19:01:17 kamailio-debian systemd[1]: Failed to start Kamailio (OpenSER) - the Open Source SIP Server. Mar 15 19:01:17 kamailio-debian systemd[1]: Unit kamailio.service entered failed state. - kamailio.cfg: # *** To run in debug mode: # - define WITH_DEBUG # #!ifndef DBURL #!define DBURL "mysql://kamailio:kamailiorw@localhost/kamailio" #!endif ####### Global Parameters ######### #!ifdef WITH_DEBUG debug=4 log_stderror=yes #!else debug=2 log_stderror=no #!endif memdbg=5 memlog=5 # log_facility=LOG_LOCAL0 # Ds increasing debug... debug=2 fork=yes children=4 /* comment the next line to enable TCP */ disable_tcp=yes /* uncomment the next line to disable the auto discovery of local aliases based on revers DNS on IPs (default on) */ auto_aliases=no /* add local domain aliases */ # alias="mysipserver.com" port=5060 /* uncomment and configure the following line if you want Kamailio to bind on a specific interface/port/proto (default bind on all available) */ # listen=udp:0.0.0.0:5060 # listen=127.0.0.1:5060 sip_warning=no ####### Modules Section ######## # set paths to location of modules (to sources or installation folders) mpath="/usr/lib/x86_64-linux-gnu/kamailio/modules/" #!ifdef WITH_MYSQL loadmodule "db_mysql.so" #!endif loadmodule "mi_fifo.so" loadmodule "kex.so" loadmodule "tm.so" loadmodule "tmx.so" loadmodule "sl.so" loadmodule "rr.so" loadmodule "pv.so" loadmodule "maxfwd.so" loadmodule "textops.so" loadmodule "siputils.so" loadmodule "xlog.so" loadmodule "sanity.so" loadmodule "ctl.so" loadmodule "mi_rpc.so" loadmodule "acc.so" loadmodule "dispatcher.so" # ----------------- setting module-specific parameters --------------- # ----- mi_fifo params ----- modparam("jsonrpcs", "fifo_name", "/var/run/kamailio/kamailio_rpc.fifo") # ----- rr params ----- # add value to ;lr param to cope with most of the UAs modparam("rr", "enable_full_lr", 1) # do not append from tag to the RR (no need for this script) modparam("rr", "append_fromtag", 0) # ----- acc params ----- modparam("acc", "log_flag", 1) modparam("acc", "failed_transaction_flag", 3) modparam("acc", "log_extra", "src_user=$fU;src_domain=$fd;dst_ouser=$tU;dst_user=$rU;dst_domain=$rd;src_ip=$si") # ----- tm params ----- modparam("tm", "fr_timer", 2000) modparam("tm", "fr_inv_timer", 40000) # ----- dispatcher params ----- # modparam("dispatcher", "db_url", DBURL) # modparam("dispatcher", "table_name", "dispatcher") modparam("dispatcher", "list_file", "/etc/kamailio/dispatcher.list") modparam("dispatcher", "flags", 2) modparam("dispatcher", "dst_avp", "$avp(AVP_DST)") modparam("dispatcher", "grp_avp", "$avp(AVP_GRP)") modparam("dispatcher", "cnt_avp", "$avp(AVP_CNT)") modparam("dispatcher", "ds_probing_mode", 1) modparam("dispatcher", "ds_ping_interval", 15) modparam("dispatcher", "ds_probing_threshhold", 1) modparam("dispatcher", "ds_ping_reply_codes", "class=2;class=3;class=4") ####### Routing Logic ######## # main request routing logic route { # per request initial checks route(REQINIT); # handle requests within SIP dialogs route(WITHINDLG); ### only initial requests (no To tag) # CANCEL processing if (is_method("CANCEL")) { if (t_check_trans()) t_relay(); exit; } t_check_trans(); # record routing for dialog forming requests (in case they are routed) # - remove preloaded route headers remove_hf("Route"); if (is_method("INVITE|SUBSCRIBE")) record_route(); # account only INVITEs if (is_method("INVITE")) { setflag(1); # do accounting } # dispatch destinations route(DISPATCH); # handle presence related requests route(PRESENCE); # handle registrations route(REGISTRAR); if ($rU==$null) { # request with no Username in RURI sl_send_reply("484","Address Incomplete"); exit; } } route[RELAY] { if (!t_relay()) { sl_reply_error(); } exit; } # Per SIP request initial checks route[REQINIT] { if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); exit; } if(!sanity_check("1511", "7")) { xlog("Malformed SIP message from $si:$sp\n"); exit; } } # Handle requests within SIP dialogs 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(1); # do accounting ... setflag(3); # ... even if the transaction fails } route(RELAY); } else { if (is_method("SUBSCRIBE") && uri == myself) { # in-dialog subscribe requests route(PRESENCE); exit; } if ( is_method("ACK") ) { if ( t_check_trans() ) { # non loose-route, but stateful ACK; # must be 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; } } # Handle SIP registrations route[REGISTRAR] { if(!is_method("REGISTER")) return; sl_send_reply("404", "No registrar"); exit; } # Presence server route route[PRESENCE] { if(!is_method("PUBLISH|SUBSCRIBE")) return; sl_send_reply("404", "Not here"); exit; } # Dispatch requests route[DISPATCH] { # Destination types: # http://kamailio.org/docs/modules/4.2.x/modules/dispatcher.html#dispatcher.f… # 4 = round robin # 9 = weight-based # round robin dispatching on gateways group '1' if(!ds_select_dst("1", "9")) { send_reply("404", "No destination"); exit; } t_set_fr(0,2000); t_on_failure("ROUTE_ADVANCE"); route(RELAY); exit; } event_route[dispatcher:dst-down] { xlog("L_ERR", "Destination down: $rm $ru ($du)\n"); } event_route[dispatcher:dst-up] { xlog("L_ERR", "Destination up: $rm $ru\n"); } failure_route[ROUTE_ADVANCE] { if (t_is_canceled()) { exit; } xlog("L_NOTICE", "Media server $du failed to answer, selecting other one!\n"); if (t_check_status("503") || (t_branch_timeout() and !t_branch_replied())) { ds_mark_dst("ip"); # select the new destination if(ds_next_dst()) { # again set local timeout for reply # xlog("L_NOTICE", "Selecting next route upon failure\n"); t_set_fr(0,2000); t_on_failure("ROUTE_ADVANCE"); route(RELAY); exit; } else { #last available node failed to reply, no other destinations available send_reply("404", "No destination"); xlog("L_NOTICE","No destination, sent 404\n"); exit; } } else { xlog("L_NOTICE","Unhandled failured route!\n"); } }

2 1

SIP contact header question
by Jack Davis 15 Mar '17

15 Mar '17

Greetings, I have a general question about the usage of SIP contact headers in the context of using Kamailio as a SIP proxy. ________________________________ [ A ] --> [ Kamailio B ] ---> [ C ] Node A originates a SIP invite, containing a valid via header and URI while setting the contact address to a user@itself and delivers it to Kamailio B which is acting as a SIP proxy. Kamailio B then uses dispatcher routing to direct the Invite to node C, adding a via line with its own information as well as a record-route header with its own proxy information but retaining the same contact address from A. Node C establishes the call and then sends a re-invite to the Kamailio B proxy which is in turn sent to Node A. Node A responds with a 200 OK The problem arises when Node C tries to send an Ack in response to this 200 OK. The ack is being sent to the Contact address, rather than the routing already established in the initial dialog. ________________________________ My question is: should kamailio be rewriting this contact address with its own? Is that the best practice? My understanding is that the contact header is more so related to future requests within the same dialog ONLY when a record-route is not used. I would appreciate any clarification on the RFC or best practices in this scenario. Thank you, Jack Davis

5 12

Kamailio does'nt respond to packets from specific addresses
by עדי ויזגן 15 Mar '17

15 Mar '17

Hi everyone, I have the following problem: I have a Kamailio server that is connected to several Asterisk servers for load balacing in a LAN network with the IP's of 192.168.16.X. I recently connected with another company that is supposed to send me calls through the Kamailio server. The problem is this: I am connected to then with a cable from their network to mine. My port has the address 10.9.18.198 and they come from the address 172.18.177.18. When I get packets from their address (172...) I can see them getting to my Kamailio server, but the Kamailio does not respond. It only happens when I get packets from 172 source address. If I get from 192 or 10 adresses from my LAN network it works, and if I get packets from real world IP's through my WAN it works. Does anyone have any idea why the Kamailio does'nt respond to packets from 172 adresses? And how to fix this? Thanks in advance!

2 3

Kamailio World 2017 - A selection of presentations
by Daniel-Constantin Mierla 15 Mar '17

15 Mar '17

Hello, I would like to announce that many of the presentations at Kamailio World 2017 (May 8-10, in Berlin, Germany) are now listed at: - https://www.kamailioworld.com/k05/schedule/ Just several are not published yet, working to get all their details in place and expect to have the first draft of the schedule very soon. This edition takes place again at the same location in the famous city center of Berlin, the number of seats is limited, last year the event was fully booked. Do not delay too much your registration if you want to attend this year: - https://www.kamailioworld.com/k05/registration/ Thanks to the sponsors (https://www.kamailioworld.com/k05/sponsors/), it looks like we will be able to offer again some grants for students or underrepresented groups. More details will be sent out in the near future. Looking forward to meeting many of you in Berlin! 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

1 0

Re: [SR-Users] rtpproxy doesn't record after start_recording
by Marko Tirs 14 Mar '17

14 Mar '17

Hi Daniel, yes, I hear the audio going both ways ok. In the meantime I succeeded to record something by rtpproxy but in best case only one direction, I can hear just the callee, but not the caller. In the meantime I have used start_recording in route[NATMANAGE] but before rtpproxy_manage("co"): -------------------------------------------------- if (is_method("INVITE") and (status=="200")) { start_recording(); } rtpproxy_manage("co"); -------------------------------------------------- After reading of your message I tested also with start_recording after rtpproxy_manage("co"): -------------------------------------------------- rtpproxy_manage("co"); if (is_method("INVITE") and (status=="200")) { start_recording(); } -------------------------------------------------- But the result was the same: I have 2 SIP users: 31 (X-Lite on Windows, static address 192.168.0.11) 35 (Android Zoiper, IP address 192.168.0.29 (by DHCP)) Kamailio has static address 192.168.0.13. When 35 calls 31 then I hear 1 direction in the recorded rtp file, the voice of callee. When 31 calls 35 then I don't hear anything in the recorded file. I don't understand why this difference when user 31 or 35 initiates a call!? But I hear audio conversation in both directions, just from the recorded file in one direction, or even nothing. I get 2 files per one call: <call-id>.rtp and <call-id>.rtcp How many files should rtpproxy produce for one call? Should also a file or two for 2nd channel be generated? How can I record both audio ways? Thank you Marko The whole function route[NATMANAGE]: # RTPProxy control route[NATMANAGE] { #!ifdef WITH_NAT if (is_request()) { if(has_totag()) { if(check_route_param("nat=yes")) { setbflag(FLB_NATB); } } } if (!(isflagset(FLT_NATS) || isbflagset(FLB_NATB))) return; if (is_method("INVITE") and (status=="200")) { start_recording(); } rtpproxy_manage("co"); if (is_request()) { if (!has_totag()) { if(t_is_branch_route()) { add_rr_param(";nat=yes"); } } } if (is_reply()) { if(isbflagset(FLB_NATB)) { set_contact_alias(); } } #!endif return; } ----- Original Message ----- From: Daniel-Constantin Mierla <miconda(a)gmail.com> To: Marko Tirs <marko.tirs(a)yahoo.com>; Kamailio (SER) - Users Mailing List <sr-users(a)lists.sip-router.org> Sent: Tuesday, March 14, 2017 5:23 PM Subject: Re: [SR-Users] rtpproxy doesn't record after start_recording Hello, I think you can call the start recording function just after rtpproxy_manage(). If you don't use the start recording function, is the audio going both ways without problems? Cheers, Daniel

1 0

Re: [SR-Users] rtpproxy doesn't record after start_recording
by Marko Tirs 14 Mar '17

14 Mar '17

Hi Daniel, yes, I hear the audio going both ways ok. In the meantime I succeeded to record something by rtpproxy but in best case only one direction, I can hear just the callee, but not the caller. In the meantime I have used start_recording in route[NATMANAGE] but before rtpproxy_manage("co"): -------------------------------------------------- if (is_method("INVITE") and (status=="200")) { start_recording(); } rtpproxy_manage("co"); -------------------------------------------------- After reading of your message I tested also with start_recording after rtpproxy_manage("co"): -------------------------------------------------- rtpproxy_manage("co"); if (is_method("INVITE") and (status=="200")) { start_recording(); } -------------------------------------------------- But the result was the same: I have 2 SIP users: 31 (X-Lite on Windows, static address 192.168.0.11) 35 (Android Zoiper, IP address 192.168.0.29 (by DHCP)) Kamailio has static address 192.168.0.13. When 35 calls 31 then I hear 1 direction in the recorded rtp file, the voice of callee. When 31 calls 35 then I don't hear anything in the recorded file. I don't understand why this difference when user 31 or 35 initiates a call!? But I hear audio conversation in both directions, just from the recorded file in one direction, or even nothing. I get 2 files per one call: <call-id>.rtp and <call-id>.rtcp How many files should rtpproxy produce for one call? Should also a file or two for 2nd channel be generated? How can I record both audio ways? Thank you Marko The whole function route[NATMANAGE]: # RTPProxy control route[NATMANAGE] { #!ifdef WITH_NAT if (is_request()) { if(has_totag()) { if(check_route_param("nat=yes")) { setbflag(FLB_NATB); } } } if (!(isflagset(FLT_NATS) || isbflagset(FLB_NATB))) return; if (is_method("INVITE") and (status=="200")) { start_recording(); } rtpproxy_manage("co"); if (is_request()) { if (!has_totag()) { if(t_is_branch_route()) { add_rr_param(";nat=yes"); } } } if (is_reply()) { if(isbflagset(FLB_NATB)) { set_contact_alias(); } } #!endif return; } ----- Original Message ----- From: Daniel-Constantin Mierla <miconda(a)gmail.com> To: Marko Tirs <marko.tirs(a)yahoo.com>; Kamailio (SER) - Users Mailing List <sr-users(a)lists.sip-router.org> Sent: Tuesday, March 14, 2017 5:23 PM Subject: Re: [SR-Users] rtpproxy doesn't record after start_recording Hello, I think you can call the start recording function just after rtpproxy_manage(). If you don't use the start recording function, is the audio going both ways without problems? Cheers, Daniel

1 0

rtpproxy doesn't record after start_recording
by Marko Tirs 14 Mar '17

14 Mar '17

Hello experts, I'm newbie in Kamailio and have a problem with my 1st installation. I just want to control the calls between SIP clients registered by Kamailio and record the conversations. I installed rtpproxy and started with rtpproxy -F -s udp:127.0.0.1:7722 -l 192.168.0.13 -r /home/user1/rtpproxy -d DBUG:LOG_LOCAL0 After start_recording() in the function onreply_route[MANAGE_REPLY] rtpproxy creates the files <call-id>.rtp and <call-id>.rtcp but they remain at zero length. 2nd problem is that the media stream is broken in one direction after start_recording() has been executed, the callee doesn't hear the caller. How is the right Kamailio configuration for recording conversations? Thank you Regards Marko Modified kamailio-basic.cfg partly: #!KAMAILIO #!define WITH_NAT #!ifdef WITH_NAT loadmodule "nathelper.so" loadmodule "rtpproxy.so" #!endif #!ifdef WITH_NAT # ----- rtpproxy params ----- modparam("rtpproxy", "rtpproxy_sock", "udp:127.0.0.1:7722") # ----- nathelper params ----- modparam("nathelper", "natping_interval", 30) modparam("nathelper", "ping_nated_only", 1) modparam("nathelper", "sipping_bflag", FLB_NATSIPPING) modparam("nathelper", "sipping_from", "sip:pinger@kamailio.org") # params needed for NAT traversal in other modules modparam("nathelper|registrar", "received_avp", "$avp(RECEIVED)") modparam("usrloc", "nat_bflag", FLB_NATB) #!endif ####### Routing Logic ######## route[RELAY] { # enable additional event routes for forwarded requests # - serial forking, RTP relaying handling, a.s.o. if (is_method("INVITE|BYE|SUBSCRIBE|UPDATE")) { if(!t_is_set("branch_route")) t_on_branch("MANAGE_BRANCH"); } if (is_method("INVITE|SUBSCRIBE|UPDATE")) { if(!t_is_set("onreply_route")) t_on_reply("MANAGE_REPLY"); } if (is_method("INVITE")) { if(!t_is_set("failure_route")) t_on_failure("MANAGE_FAILURE"); } if (!t_relay()) { sl_reply_error(); } exit; } # RTPProxy control route[NATMANAGE] { #!ifdef WITH_NAT if (is_request()) { if(has_totag()) { if(check_route_param("nat=yes")) { setbflag(FLB_NATB); } } } if (!(isflagset(FLT_NATS) || isbflagset(FLB_NATB))) return; rtpproxy_manage("co"); if (is_request()) { if (!has_totag()) { if(t_is_branch_route()) { add_rr_param(";nat=yes"); } } } if (is_reply()) { if(isbflagset(FLB_NATB)) { set_contact_alias(); } } #!endif return; } # Manage incoming replies onreply_route[MANAGE_REPLY] { xdbg("incoming reply\n"); if (is_method("INVITE") and (status=="200")) { xlog("START_RECORDING #1\n"); start_recording(); xlog("START_RECORDING #2\n"); } else if(status=~"[12][0-9][0-9]") route(NATMANAGE); }

2 1

Is kamailio support load balancing for websockets
by SureshTummala 14 Mar '17

14 Mar '17

Hi, I want to use kamailio as a load balancer for web sockets. Is kamailio supports LB functionality for web-sockets? I can able to use kamailio as a proxy and can make calls with websockets. Now i want to add LB functionality. Setup: UA1 -->LB -->Proxy UA2 <--LB <--Proxy LB is not forwarding the packets from Proxy to UA Please help me Regards,Suresh Tummala

1 0

Several Asterisk on this same IP
by przeqpiciel 14 Mar '17

14 Mar '17

I would like to ask you how you deal with several asterisks and kamailio on that same IP address, I have installation where i route 5060 to internal server with kamailio and I would like to route RTP to asterisks, but is any way to get around a problem with RTP ports collisions?

6 19

how to unregister an remote registration at uac module
by José Lopes 13 Mar '17

13 Mar '17

Hello, I am using the module uac to do remote registration. But sometimes i need to do unregister, to control or debug the registration process. I tried using kamcmd with uac.reg_disable, but this doesn't unregister. There is any way to do it? Best regards, Jose Lopes

2 2

Segmentation fault - dialog RPC
by pars3c 13 Mar '17

13 Mar '17

Dear all, many times, when i call dialog_list on dialog module with jsonrpc, kamailio crash. The version i use is: 4.4.2 Thanks for any suggestion. #0 0x00007f2a706eb00a in internal_rpc_profile_print_dlgs (rpc=0x7f2a4fdf99a0, c=0x7f2a4fdf9940, profile_name=0x7fffb9fa8b10, value=0x0) at dialog.c:1666 1666 if ((!value || (STR_EQ(*value, ph->value))) && ph->dlg) { The dump , with bt full is this : #0 0x00007f2a706eb00a in internal_rpc_profile_print_dlgs (rpc=0x7f2a4fdf99a0, c=0x7f2a4fdf9940, profile_name=0x7fffb9fa8b10, value=0x0) at dialog.c:1666 profile = 0x7f2a5098fb40 ph = 0x0 i = 10 #1 0x00007f2a706eb6e4 in rpc_profile_print_dlgs (rpc=0x7f2a4fdf99a0, c=0x7f2a4fdf9940) at dialog.c:1772 profile_name = {s = 0x1c78b00 "outbound", len = 8} value = {s = 0x0, len = 0} #2 0x00007f2a4fbe45c6 in jsonrpc_dispatch (msg=0x7fffb9fa9f10, s1=0x0, s2=0x0) at jsonrpc-s_mod.c:1091 rpce = 0x7f2a75609360 ctx = 0x7f2a4fdf9940 ret = 0 nj = 0x1c76af0 val = {s = 0x1c77b20 "dlg.profile_list", len = 16} __FUNCTION__ = "jsonrpc_dispatch" #3 0x000000000041f4ad in do_action (h=0x7fffb9fa9e30, a=0x7f2a75584700, msg=0x7fffb9fa9f10) at action.c:1054 ret = -5 v = 4288256 dst = {send_sock = 0x1b9fa9b23, to = {s = {sa_family = 14080, sa_data = "Xu*\177\000\000\b7Xu*\177\000"}, sin = { sin_family = 14080, sin_port = 30040, sin_addr = {s_addr = 32554}, sin_zero = "\b7Xu*\177\000"}, sin6 = { sin6_family = 14080, sin6_port = 30040, sin6_flowinfo = 32554, sin6_addr = {__in6_u = { __u6_addr8 = "\b7Xu*\177\000\000S \205\000\060\000\000", __u6_addr16 = {14088, 30040, 32554, 0, 8275, 133, 48, 0}, __u6_addr32 = {1968715528, 32554, 8724563, 48}}}, sin6_scope_id = 26}}, id = 0, proto = 16 '\020', send_flags = { f = 155 '\233', blst_imask = 250 '\372'}} tmp = 0x7fffb9fab700 "\t" new_uri = 0x0 end = 0x0 crt = 0x7fffb9fa92d0 "" cmd = 0x7f2a754adcc0 len = 0 user = 0 uri = {user = {s = 0x12c <Address 0x12c out of bounds>, len = 0}, passwd = {s = 0x7fffb9fa92d0 "", len = 1969341184}, host = { s = 0x7f2a75475010 "\001", len = 4742114}, port = {s = 0x0, len = 0}, params = { s = 0x98206f7473 <Address 0x98206f7473 out of bounds>, len = 1969341256}, sip_params = { s = 0x7fffb9fa91e0 "`\222\372\271\377\177", len = 6538286}, headers = {s = 0x1c2b6f0 "\300\300\302\001", len = 0}, port_no = 50838, proto = 30049, type = 32554, flags = 0, transport = {s = 0x0, len = -940795965}, ttl = {s = 0x0, len = 0}, user_param = {s = 0x6222286e00000000 <Address 0x6222286e00000000 out of bounds>, len = 577270895}, maddr = { s = 0x3a746e65696c6309 <Address 0x3a746e65696c6309 out of bounds>, len = 0}, method = {s = 0x75c5f0 "core", len = -1174760864}, lr = {s = 0x764661 "rval_destroy", len = 7718524}, r2 = {s = 0x7f2a7561c348 "\002", len = 1967607824}, gr = {s = 0x7fffb9fa91b8 "H\303au*\177", len = 1967607824}, transport_val = {s = 0x7f2a7561c300 "\300\004", len = 1969341256}, ttl_val = {s = 0x7f2a7557e200 "\020", len = -1174760316}, user_param_val = {s = 0x7f2a75583700 "\002", len = 1969341256}, maddr_val = {s = 0x416f00 "1\355I\211\321^H\211\342H\203\344\360PTI\307\300\060\336q", len = -1174751488}, method_val = { ---Type <return> to continue, or q <return> to quit--- s = 0x0, len = 0}, lr_val = {s = 0x7fffb9fa9260 "Ð\372\271\377\177", len = 5581478}, r2_val = {s = 0x0, len = 0}, gr_val = { s = 0x3a28d <Address 0x3a28d out of bounds>, len = 1969177728}} next_hop = {user = {s = 0x1c2b6f0 "\300\300\302\001", len = 1969330344}, passwd = { s = 0x69692c22 <Address 0x69692c22 out of bounds>, len = 29537760}, host = { s = 0x400000000 <Address 0x400000000 out of bounds>, len = -1174761304}, port = { s = 0x71657228 <Address 0x71657228 out of bounds>, len = 1969342102}, params = {s = 0x0, len = 1}, sip_params = {s = 0x0, len = -1174761328}, headers = {s = 0x1 <Address 0x1 out of bounds>, len = 2}, port_no = 40672, proto = 47610, type = 32767, flags = 3120206016, transport = {s = 0x7a6563697220616c <Address 0x7a6563697220616c out of bounds>, len = 1701736297}, ttl = { s = 0x7f2a75580848 "\001", len = -1174760828}, user_param = {s = 0x7fffb9fa9f10 "\b\005", len = -1174757840}, maddr = { s = 0x65722e2e223a7069 <Address 0x65722e2e223a7069 out of bounds>, len = 1702129517}, method = {s = 0x7f2a7561c696 "/sip", len = 29855024}, lr = {s = 0x0, len = 0}, r2 = {s = 0x0, len = 0}, gr = {s = 0x500000004 <Address 0x500000004 out of bounds>, len = 4}, transport_val = {s = 0x400000004 <Address 0x400000004 out of bounds>, len = 6552774}, ttl_val = { s = 0x7fffb9fa9060 "", len = 1967607824}, user_param_val = {s = 0x1000001 <Address 0x1000001 out of bounds>, len = 1967607824}, maddr_val = {s = 0x7fffb9fa90b0 "\020PGu*\177", len = 1956545302}, method_val = {s = 0x0, len = 0}, lr_val = {s = 0x1000000 <Address 0x1000000 out of bounds>, len = 14985000}, r2_val = { s = 0x165e80 <Address 0x165e80 out of bounds>, len = 1792216}, gr_val = {s = 0x1ed710 <Address 0x1ed710 out of bounds>, len = 8}} u = 0x7f2a75583f30 port = 0 dst_host = 0x7f2a75583700 i = 32767 flags = 0 avp = 0x7fffb9fa9e30 st = {flags = 151652617, id = 29193, name = {n = 0, s = {s = 0x6e65090a00000000 <Address 0x6e65090a00000000 out of bounds>, len = -1174761256}, re = 0x6e65090a00000000}, avp = 0x7fffb9fa9000} sct = 0x7fffb9fa94d0 sjt = 0x7fffb9fa9f10 rve = 0x416f00 mct = 0x7fffb9fab700 rv = 0x92922726f727265 rv1 = 0x0 c1 = {cache_type = 3120205776, val_type = 32767, c = {avp_val = {n = -940803561, s = { s = 0x31c7ec7a17 "\213D$8H\201\304\070\002", len = -1174757616}, re = 0x31c7ec7a17}, pval = {rs = { s = 0x31c7ec7a17 "\213D$8H\201\304\070\002", len = -1174757616}, ri = -1174757840, flags = 32767}}, i2s = "vp(s:inserver_erPor)\","} s = {s = 0x1c2b6f0 "\300\300\302\001", len = 0} srevp = {0x0, 0x0} mod_f_params = {{type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, ---Type <return> to continue, or q <return> to quit--- select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}} __FUNCTION__ = "do_action" #4 0x000000000042c218 in run_actions (h=0x7fffb9fa9e30, a=0x7f2a75584700, msg=0x7fffb9fa9f10) at action.c:1549 t = 0x7f2a75584700 ret = -1 mod = 0x0 ms = 0 __FUNCTION__ = "run_actions" #5 0x000000000041f416 in do_action (h=0x7fffb9fa9e30, a=0x7f2a75585b10, msg=0x7fffb9fa9f10) at action.c:1045 ret = 1 v = 1 dst = {send_sock = 0x7fffb9fa9b50, to = {s = {sa_family = 64710, sa_data = "c\000\000\000\000\000\060\233\372\271\377\177\000"}, sin = {sin_family = 64710, sin_port = 99, sin_addr = {s_addr = 0}, sin_zero = "0\233\372\271\377\177\000"}, sin6 = { sin6_family = 64710, sin6_port = 99, sin6_flowinfo = 0, sin6_addr = {__in6_u = { __u6_addr8 = "0\233\372\271\377\177\000\000Ù¨bu*\177\000", __u6_addr16 = {39728, 47610, 32767, 0, 43225, 30050, 32554, 0}, __u6_addr32 = {3120208688, 32767, 1969400025, 32554}}}, sin6_scope_id = 366}}, id = 10, proto = -24 '\350', send_flags = {f = 234 '\352', blst_imask = 98 'b'}} tmp = 0x1467562aa20 <Address 0x1467562aa20 out of bounds> new_uri = 0x7a0a02 "parse_headers" end = 0x79db5c "core: parser/msg_parser.c" crt = 0x40 <Address 0x40 out of bounds> cmd = 0x7f2a75475010 len = 1967607824 user = 32554 uri = {user = {s = 0x0, len = 0}, passwd = {s = 0x7fffb9fa9b70 "@\234\372\271\004", len = 6529985}, host = { s = 0x416f00 "1\355I\211\321^H\211\342H\203\344\360PTI\307\300\060\336q", len = -1174751488}, port = {s = 0x0, len = 0}, params = {s = 0x7fffb9fa9ba0 "p\234\372\271\377\177", len = 6661320}, sip_params = {s = 0x7fffb9fa99f0 "", len = 1967607824}, headers = {s = 0x0, len = 1967607824}, port_no = 39488, proto = 47610, type = 32767, flags = 6552774, transport = { s = 0x7fffb9fa9a20 "", len = 1967607824}, ttl = {s = 0x1000000 <Address 0x1000000 out of bounds>, len = 1967607824}, user_param = {s = 0x7fffb9fa9a70 "\240\232\372\271\377\177", len = 1956545302}, maddr = { s = 0x1ed710 <Address 0x1ed710 out of bounds>, len = 0}, method = {s = 0x1000000 <Address 0x1000000 out of bounds>, len = 14986448}, lr = {s = 0x1658d8 <Address 0x1658d8 out of bounds>, len = 1790768}, r2 = { s = 0x1ed710 <Address 0x1ed710 out of bounds>, len = 8}, gr = {s = 0x12e <Address 0x12e out of bounds>, len = 1967607824}, transport_val = {s = 0x14600000000 <Address 0x14600000000 out of bounds>, len = 1969417808}, ttl_val = { s = 0x7fffb9fa9aa0 "\240\233\372\271\377\177", len = 4742114}, user_param_val = {s = 0x0, len = 1967607824}, maddr_val = { s = 0x0, len = 0}, method_val = {s = 0x7fffb9fa9ba0 "p\234\372\271\377\177", len = 6534031}, lr_val = {s = 0x79d630 "core", len = 6552774}, r2_val = {s = 0x7fffb9fa9b00 "n\001", len = 1969417880}, gr_val = {s = 0x7f2a7562aa20 "", len = 1969399988}} next_hop = {user = {s = 0x7fffb9fa9820 "", len = 1967607824}, passwd = {s = 0x1000000 <Address 0x1000000 out of bounds>, len = 1967607824}, host = {s = 0x7fffb9fa9870 "\240\230", <incomplete sequence \372\271>, len = 1956545302}, port = { ---Type <return> to continue, or q <return> to quit--- s = 0x1c588e1 "\311\305\001", len = 0}, params = {s = 0x1000000 <Address 0x1000000 out of bounds>, len = 14986216}, sip_params = {s = 0x1659c0 <Address 0x1659c0 out of bounds>, len = 1969416936}, headers = {s = 0x7f2a7562aa20 "", len = 1969399993}, port_no = 301, proto = 0, type = ERROR_URI_T, flags = 0, transport = { s = 0x7f2a7562a8d9 "Content-Type: application/json-rpc\r\nCache-Control: no-cache\r\nPragma: no-cache\r\nUser-Agent: Java/1.8.0_121\r\nHost: \r\nAccept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2\r\nConn"..., len = 0}, ttl = { s = 0xb9fa98a0 <Address 0xb9fa98a0 out of bounds>, len = 1969416936}, user_param = {s = 0x0, len = 1967607824}, maddr = { s = 0x0, len = 0}, method = {s = 0x7fffb9fa99a0 "\240\233\372\271\377\177", len = 6534031}, lr = {s = 0x79d630 "core", len = 0}, r2 = {s = 0x0, len = 0}, gr = {s = 0x7fffb9fa9e7c "\260\f\222\017", len = -1174757736}, transport_val = { s = 0x79d630 "core", len = -1174757704}, ttl_val = {s = 0x7a0a10 "get_hdr_field", len = 7986012}, user_param_val = { s = 0xe8 <Address 0xe8 out of bounds>, len = 1967607824}, maddr_val = {s = 0x79d630 "core", len = 1969416864}, method_val = { s = 0x7a0a10 "get_hdr_field", len = 7986012}, lr_val = {s = 0xe8 <Address 0xe8 out of bounds>, len = 1967607824}, r2_val = { s = 0x7f2a75475010 "\001", len = 1969416864}, gr_val = {s = 0x7f2a7562eaa0 <incomplete sequence \350>, len = 1969399988}} u = 0x7f2a7562ee50 port = 0 dst_host = 0x80067e961 i = 0 flags = 0 avp = 0x7f2a75475010 st = {flags = 3120207856, id = 32767, name = {n = 1967607824, s = {s = 0x7f2a75475010 "\001", len = 1969239958}, re = 0x7f2a75475010}, avp = 0x7f2a75475010} sct = 0x4b9fa9c40 sjt = 0x79d630 rve = 0x7f2a75582f20 mct = 0x7fffb9fab700 rv = 0x63fcc6 rv1 = 0x0 c1 = {cache_type = 43, val_type = RV_NONE, c = {avp_val = {n = 0, s = {s = 0x0, len = 7718384}, re = 0x0}, pval = {rs = {s = 0x0, len = 7718384}, ri = 26, flags = 0}}, i2s = "\t\000\000\000\000\000\000\000huTu*\177\000\000\000\000\000\000\000"} s = {s = 0x7fffb9fa99f0 "", len = 1969239512} srevp = {0x3000000018, 0x7fffb9fa9ab0} mod_f_params = {{type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}, {type = NOSUBTYPE, u = {number = 0, string = 0x0, str = {s = 0x0, len = 0}, data = 0x0, attr = 0x0, select = 0x0}}} __FUNCTION__ = "do_action"

2 2

unable to receive response from freeswitch
by ysuryas . 13 Mar '17

13 Mar '17

I have configured kamailio (192.168.56.102) and freeswitch(192.168.56.103) in separate virtualboxes when making a call, the invite goes to proxy and it is forwarded to freeswitch but response from freeswitch is "unreachable port" attached the wireshark trace: I don't why 10.0.2.15 is making the Invite to freeswitch, i was expecting 192.168.56.102 to do that. UA -> 192.168.56.102 -> 192.168.56.103 Any suggestions on this? [image: Inline image 1] Thanks, Surya

2 1

rtpproxy doesn't record after start_recording
by Marko Tirs 11 Mar '17

11 Mar '17

Hello experts, I'm newbie in Kamailio and have a problem with my 1st installation. I just want to control the calls between SIP clients registered by Kamailio and record the conversations. I installed rtpproxy and started with rtpproxy -F -s udp:127.0.0.1:7722 -l 192.168.0.13 -r /home/user1/rtpproxy -d DBUG:LOG_LOCAL0 After start_recording() in the function onreply_route[MANAGE_REPLY] rtpproxy creates the files <call-id>.rtp and <call-id>.rtcp but they remain at zero length. 2nd problem is that the media stream is broken in one direction after start_recording() has been executed, the callee doesn't hear the caller. How is the right Kamailio configuration for recording conversations? Thank you Regards Marko Modified kamailio-basic.cfg partly: #!KAMAILIO #!define WITH_NAT #!ifdef WITH_NAT loadmodule "nathelper.so" loadmodule "rtpproxy.so" #!endif #!ifdef WITH_NAT # ----- rtpproxy params ----- modparam("rtpproxy", "rtpproxy_sock", "udp:127.0.0.1:7722") # ----- nathelper params ----- modparam("nathelper", "natping_interval", 30) modparam("nathelper", "ping_nated_only", 1) modparam("nathelper", "sipping_bflag", FLB_NATSIPPING) modparam("nathelper", "sipping_from", "sip:pinger@kamailio.org") # params needed for NAT traversal in other modules modparam("nathelper|registrar", "received_avp", "$avp(RECEIVED)") modparam("usrloc", "nat_bflag", FLB_NATB) #!endif ####### Routing Logic ######## route[RELAY] { # enable additional event routes for forwarded requests # - serial forking, RTP relaying handling, a.s.o. if (is_method("INVITE|BYE|SUBSCRIBE|UPDATE")) { if(!t_is_set("branch_route")) t_on_branch("MANAGE_BRANCH"); } if (is_method("INVITE|SUBSCRIBE|UPDATE")) { if(!t_is_set("onreply_route")) t_on_reply("MANAGE_REPLY"); } if (is_method("INVITE")) { if(!t_is_set("failure_route")) t_on_failure("MANAGE_FAILURE"); } if (!t_relay()) { sl_reply_error(); } exit; } # RTPProxy control route[NATMANAGE] { #!ifdef WITH_NAT if (is_request()) { if(has_totag()) { if(check_route_param("nat=yes")) { setbflag(FLB_NATB); } } } if (!(isflagset(FLT_NATS) || isbflagset(FLB_NATB))) return; rtpproxy_manage("co"); if (is_request()) { if (!has_totag()) { if(t_is_branch_route()) { add_rr_param(";nat=yes"); } } } if (is_reply()) { if(isbflagset(FLB_NATB)) { set_contact_alias(); } } #!endif return; } # Manage incoming replies onreply_route[MANAGE_REPLY] { xdbg("incoming reply\n"); if (is_method("INVITE") and (status=="200")) { xlog("START_RECORDING #1\n"); start_recording(); xlog("START_RECORDING #2\n"); } else if(status=~"[12][0-9][0-9]") route(NATMANAGE); }

1 0

Dispatcher Module - Hava limit?
by Rodrigo Moreira 11 Mar '17

11 Mar '17

Hello, I am experiencing the following problem: my dispatcher module is losing many calls when the scenario for balancing is about 175 CPS or more. Is there a limit that the module can do? Where do I find this information? Att., -- Rodrigo M. (37) 9132-4539 (34) 9889-3069

3 6

Multiple parallel branches, one invalid
by Nathan Ward 10 Mar '17

10 Mar '17

Hi, I have a scenario I’m not sure of the best way to solve. I use alias_db and have multiple destinations for a single number, and have append_branches set to 1. I then use lookup_branches to get details from the location table for each branch. I then do t_load_contacts and t_next_contacts, then t_relay to parallel fork the calls to the destination, and all the phones ring at once. This all works great if all the destinations from the dbaliases table are online. However, if one of them is offline, lookup_branches says "Not found in usrloc”. This branch is still there, and the call is attempted. In my environment, this then does a DNS lookup, can’t resolve the domain, and the branch fails. This is the first branch that is tried, and when this branch has an error like this, it causes t_relay() to fail - I check for the output of t_relay() and reply with an error - per the default config that Kamailio ships with. I guess what I need to figure out, is if there’s a way to have t_relay fail only if all branches fail? Or, is there a more elegant way to handle this? I should add, I only allow a single registration per subscriber - so, lookup_branches only returns one branch per alias from alias_db_lookup. -- Nathan Ward

2 1

404 not here for BYE
by Mikhail Khomenkov 10 Mar '17

10 Mar '17

Hi i have some kind of issue with BYE Asterisk send invite to Kamailio1, Kamailio1 proxy to Kamailio2, Kamailio2 found UAC and send invite to it. UAC response 200OK -> Kamailio2 -> Kamailio1 -> Asterisk. Session established. But then UAC sending BYE to Kamailio2 , Kamailio2 sending it to Kamailio1 and Kamailio1 response 404 not here (not sending BYE to Asterisk) Any suggestions? 54.236.97.30 107.21.18.6 10.0.0.68 108.41.170.187 Asterisk Kamailio1 Kamailio2 UAC | invite | | | |--------------------------------> | invite | | | |------------------------------->| invite | | | |----------------------------------->| | | | 200OK | | | 200OK |<-----------------------------------| | 200OK |<-------------------------------| | |<--------------------------------| | | BYE | | BYE |<-----------------------------------| | |<-------------------------------| | | | 404 Not here | | | |------------------------------->| 404 Not here | | | |----------------------------------->| # U 107.21.18.6:5060 -> 10.0.0.68:5060 INVITE sip:88919640010@sip7.keku.com SIP/2.0. Record-Route: <sip:107.21.18.6;lr=on>. Via: SIP/2.0/UDP 107.21.18.6:5060;branch=z9hG4bK67a4. 83b3107c510ddfe551896134a5e82554.0. Via: SIP/2.0/UDP 54.236.97.30:5060;received=54.236.97.30;branch= z9hG4bK3d97649d;rport=5060. Max-Forwards: 68. From: "6093756295 <(609)%20375-6295>" <sip:6093756295@54.236.97.30>; tag=as372f68e0. To: <sip:88919640010@sip6.keku.com>. Contact: <sip:6093756295@54.236.97.30:5060>. Call-ID: 01e9e3e03dd2995d720bff297a226e83@54.236.97.30:5060. CSeq: 102 INVITE. User-Agent: Asterisk PBX. Date: Fri, 10 Mar 2017 02:30:12 GMT. Min-SE: 120. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE. Supported: replaces, timer. Cisco-Guid: 1241711126_45859092(a)23.29.27.22. Content-Type: application/sdp. Content-Length: 237. . v=0. o=root 39119558 39119558 IN IP4 54.236.97.30. s=Asterisk PBX 1.8.28-cert5. c=IN IP4 54.236.97.30. t=0 0. m=audio 53626 RTP/AVP 0 101. a=rtpmap:0 PCMU/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=ptime:20. a=sendrecv. U 10.0.0.68:5060 -> 107.21.18.6:5060 SIP/2.0 100 trying -- your call is important to us. Via: SIP/2.0/UDP 107.21.18.6:5060;branch=z9hG4bK67a4. 83b3107c510ddfe551896134a5e82554.0;rport=5060. Via: SIP/2.0/UDP 54.236.97.30:5060;received=54.236.97.30;branch= z9hG4bK3d97649d;rport=5060. From: "6093756295 <(609)%20375-6295>" <sip:6093756295@54.236.97.30>; tag=as372f68e0. To: <sip:88919640010@sip6.keku.com>. Call-ID: 01e9e3e03dd2995d720bff297a226e83@54.236.97.30:5060. CSeq: 102 INVITE. Server: kamailio (4.4.3 (x86_64/linux)). Content-Length: 0. . # U 10.0.0.68:5060 -> 108.41.170.187:53487 INVITE sip:88919640010@108.41.170.187:53487;rinstance=37d7b85846910961 SIP/2.0. Record-Route: <sip:107.23.47.88;lr>. Record-Route: <sip:107.21.18.6;lr=on>. Via: SIP/2.0/UDP 107.23.47.88:5060;branch=z9hG4bK67a4. d6f7e6b1f007e0958a99c6a6342e4e48.1. Via: SIP/2.0/UDP 107.21.18.6:5060;rport=5060;branch=z9hG4bK67a4. 83b3107c510ddfe551896134a5e82554.0. Via: SIP/2.0/UDP 54.236.97.30:5060;received=54.236.97.30;branch= z9hG4bK3d97649d;rport=5060. Max-Forwards: 66. From: "6093756295 <(609)%20375-6295>" <sip:6093756295@54.236.97.30>; tag=as372f68e0. To: <sip:88919640010@sip6.keku.com>. Contact: <sip:6093756295 <(609)%20375-6295>@54.236.97.30: 5060;alias=107.21.18.6~5060~1>. Call-ID: 01e9e3e03dd2995d720bff297a226e83@54.236.97.30:5060. CSeq: 102 INVITE. User-Agent: Asterisk PBX. Date: Fri, 10 Mar 2017 02:30:12 GMT. Min-SE: 120. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE. Supported: replaces, timer. Cisco-Guid: 1241711126_45859092(a)23.29.27.22. Content-Type: application/sdp. Content-Length: 645. . v=0. o=root 39119558 39119558 IN IP4 107.23.47.88. s=Asterisk PBX 1.8.28-cert5. c=IN IP4 107.23.47.88. t=0 0. m=audio 10054 RTP/SAVPF 0 101. a=rtpmap:0 PCMU/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=ptime:20. a=sendrecv. a=rtcp:10055. a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:v7hy4Ix2Re87vG/ Fiymv20UGZ89xoWPp/dFzmiHq. a=setup:actpass. a=fingerprint:sha-1 18:F3:50:26:22:26:81:88:FB:95: F8:4B:3A:A7:9F:A6:F5:B7:B8:E3. a=ice-ufrag:ZgtwCEvD. a=ice-pwd:a0Tt54oToZFj9b42QXOM2Fq1VR. a=candidate:RzNgC40JM1mFcCUB 1 UDP 2130706431 107.23.47.88 10054 typ host. a=candidate:RzNgC40JM1mFcCUB 2 UDP 2130706430 107.23.47.88 10055 typ host. # U 108.41.170.187:53487 -> 10.0.0.68:5060 SIP/2.0 100 Trying. Via: SIP/2.0/UDP 107.23.47.88:5060;branch=z9hG4bK67a4. d6f7e6b1f007e0958a99c6a6342e4e48.1. Via: SIP/2.0/UDP 107.21.18.6:5060;rport=5060;branch=z9hG4bK67a4. 83b3107c510ddfe551896134a5e82554.0. Via: SIP/2.0/UDP 54.236.97.30:5060;received=54.236.97.30;branch= z9hG4bK3d97649d;rport=5060. To: <sip:88919640010@sip6.keku.com>. From: "6093756295 <(609)%20375-6295>" <sip:6093756295@54.236.97.30>; tag=as372f68e0. Call-ID: 01e9e3e03dd2995d720bff297a226e83@54.236.97.30:5060. CSeq: 102 INVITE. Content-Length: 0. . # U 108.41.170.187:53487 -> 10.0.0.68:5060 SIP/2.0 180 Ringing. Via: SIP/2.0/UDP 107.23.47.88:5060;branch=z9hG4bK67a4. d6f7e6b1f007e0958a99c6a6342e4e48.1. Via: SIP/2.0/UDP 107.21.18.6:5060;rport=5060;branch=z9hG4bK67a4. 83b3107c510ddfe551896134a5e82554.0. Via: SIP/2.0/UDP 54.236.97.30:5060;received=54.236.97.30;branch= z9hG4bK3d97649d;rport=5060. Record-Route: <sip:107.23.47.88;lr>. Record-Route: <sip:107.21.18.6;lr=on>. Contact: <sip:88919640010@108.41.170.187:53487;rinstance=37d7b85846910961>. To: "88919640010"<sip:88919640010@sip6.keku.com>;tag=d6323b02. From: "6093756295 <(609)%20375-6295>" <sip:6093756295@54.236.97.30>; tag=as372f68e0. Call-ID: 01e9e3e03dd2995d720bff297a226e83@54.236.97.30:5060. CSeq: 102 INVITE. User-Agent: X-Lite release 4.9.6 stamp 82167. Allow-Events: talk, hold. Content-Length: 0. . # U 10.0.0.68:5060 -> 107.21.18.6:5060 SIP/2.0 180 Ringing. Via: SIP/2.0/UDP 107.21.18.6:5060;rport=5060;branch=z9hG4bK67a4. 83b3107c510ddfe551896134a5e82554.0. Via: SIP/2.0/UDP 54.236.97.30:5060;received=54.236.97.30;branch= z9hG4bK3d97649d;rport=5060. Record-Route: <sip:107.23.47.88;lr>. Record-Route: <sip:107.21.18.6;lr=on>. Contact: <sip:88919640010@108.41.170.187:53487;rinstance=37d7b85846910961>. To: "88919640010"<sip:88919640010@sip6.keku.com>;tag=d6323b02. From: "6093756295 <(609)%20375-6295>" <sip:6093756295@54.236.97.30>; tag=as372f68e0. Call-ID: 01e9e3e03dd2995d720bff297a226e83@54.236.97.30:5060. CSeq: 102 INVITE. User-Agent: X-Lite release 4.9.6 stamp 82167. Allow-Events: talk, hold. Content-Length: 0. . # U 108.41.170.187:53487 -> 10.0.0.68:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 107.23.47.88:5060;branch=z9hG4bK67a4. d6f7e6b1f007e0958a99c6a6342e4e48.1. Via: SIP/2.0/UDP 107.21.18.6:5060;rport=5060;branch=z9hG4bK67a4. 83b3107c510ddfe551896134a5e82554.0. Via: SIP/2.0/UDP 54.236.97.30:5060;received=54.236.97.30;branch= z9hG4bK3d97649d;rport=5060. Record-Route: <sip:107.23.47.88;lr>. Record-Route: <sip:107.21.18.6;lr=on>. Contact: <sip:88919640010@108.41.170.187:53487;rinstance=37d7b85846910961>. To: <sip:88919640010@sip6.keku.com>;tag=d6323b02. From: "6093756295 <(609)%20375-6295>" <sip:6093756295@54.236.97.30>; tag=as372f68e0. Call-ID: 01e9e3e03dd2995d720bff297a226e83@54.236.97.30:5060. CSeq: 102 INVITE. Allow: SUBSCRIBE, NOTIFY, INVITE, ACK, CANCEL, BYE, REFER, INFO, OPTIONS, MESSAGE. Content-Type: application/sdp. Supported: replaces. User-Agent: X-Lite release 4.9.6 stamp 82167. Content-Length: 283. . v=0. o=- 620006012 3 IN IP4 172.22.1.2. s=X-Lite release 4.9.6 stamp 82167. c=IN IP4 172.22.1.2. t=0 0. m=audio 56064 RTP/SAVPF 0 101. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:aoNS33aJgrSvBRBRtHHhjlA+ rLvd9ldUiUxXzoem. a=sendrecv. # U 10.0.0.68:5060 -> 107.21.18.6:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 107.21.18.6:5060;rport=5060;branch=z9hG4bK67a4. 83b3107c510ddfe551896134a5e82554.0. Via: SIP/2.0/UDP 54.236.97.30:5060;received=54.236.97.30;branch= z9hG4bK3d97649d;rport=5060. Record-Route: <sip:107.23.47.88;lr>. Record-Route: <sip:107.21.18.6;lr=on>. Contact: <sip:88919640010@108.41.170.187:53487;rinstance=37d7b85846910961>. To: <sip:88919640010@sip6.keku.com>;tag=d6323b02. From: "6093756295 <(609)%20375-6295>" <sip:6093756295@54.236.97.30>; tag=as372f68e0. Call-ID: 01e9e3e03dd2995d720bff297a226e83@54.236.97.30:5060. CSeq: 102 INVITE. Allow: SUBSCRIBE, NOTIFY, INVITE, ACK, CANCEL, BYE, REFER, INFO, OPTIONS, MESSAGE. Content-Type: application/sdp. Supported: replaces. User-Agent: X-Lite release 4.9.6 stamp 82167. Content-Length: 215. . v=0. o=- 620006012 3 IN IP4 107.23.47.88. s=X-Lite release 4.9.6 stamp 82167. c=IN IP4 107.23.47.88. t=0 0. m=audio 10072 RTP/AVP 0 101. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=sendrecv. a=rtcp:10073. # U 107.21.18.6:5060 -> 10.0.0.68:5060 ACK sip:88919640010@108.41.170.187:53487;rinstance=37d7b85846910961 SIP/2.0. Via: SIP/2.0/UDP 107.21.18.6:5060;branch=z9hG4bK67a4. ff7b9cc9b887d892d7fd83e6f046b4d4.0. Via: SIP/2.0/UDP 54.236.97.30:5060;received=54.236.97.30;branch= z9hG4bK4e4d5063;rport=5060. Route: <sip:107.23.47.88;lr>. Max-Forwards: 68. From: "6093756295 <(609)%20375-6295>" <sip:6093756295@54.236.97.30>; tag=as372f68e0. To: <sip:88919640010@sip7.keku.com>;tag=d6323b02. Contact: <sip:6093756295@54.236.97.30:5060>. Call-ID: 01e9e3e03dd2995d720bff297a226e83@54.236.97.30:5060. CSeq: 102 ACK. User-Agent: Asterisk PBX. Content-Length: 0. . # U 10.0.0.68:5060 -> 108.41.170.187:53487 ACK sip:88919640010@108.41.170.187:53487;rinstance=37d7b85846910961 SIP/2.0. Via: SIP/2.0/UDP 107.23.47.88:5060;branch=z9hG4bK67a4. 3a3af8e184f57334c9d42b8ce7d77849.0. Via: SIP/2.0/UDP 107.21.18.6:5060;rport=5060;branch=z9hG4bK67a4. ff7b9cc9b887d892d7fd83e6f046b4d4.0. Via: SIP/2.0/UDP 54.236.97.30:5060;received=54.236.97.30;branch= z9hG4bK4e4d5063;rport=5060. Max-Forwards: 66. From: "6093756295 <(609)%20375-6295>" <sip:6093756295@54.236.97.30>; tag=as372f68e0. To: <sip:88919640010@sip7.keku.com>;tag=d6323b02. Contact: <sip:6093756295 <(609)%20375-6295>@54.236.97.30: 5060;alias=107.21.18.6~5060~1>. Call-ID: 01e9e3e03dd2995d720bff297a226e83@54.236.97.30:5060. CSeq: 102 ACK. User-Agent: Asterisk PBX. Content-Length: 0. . # U 108.41.170.187:53487 -> 10.0.0.68:5060 . . # U 108.41.170.187:53487 -> 10.0.0.68:5060 BYE sip:6093756295 <(609)%20375-6295>@54.236.97.30:5060;alias=107.21.18.6~5060~1 SIP/2.0. Via: SIP/2.0/UDP 172.22.1.2:53487;branch=z9hG4bK-524287-1--- 1034af445c791a63;rport. Max-Forwards: 70. Route: <sip:107.23.47.88;lr>. Route: <sip:107.21.18.6;lr=on>. Contact: <sip:88919640010@108.41.170.187:53487;rinstance=37d7b85846910961>. To: "6093756295 <(609)%20375-6295>" <sip:6093756295@54.236.97.30>; tag=as372f68e0. From: <sip:88919640010@sip6.keku.com>;tag=d6323b02. Call-ID: 01e9e3e03dd2995d720bff297a226e83@54.236.97.30:5060. CSeq: 2 BYE. User-Agent: X-Lite release 4.9.6 stamp 82167. Content-Length: 0. . # U 10.0.0.68:5060 -> 107.21.18.6:5060 BYE sip:6093756295 <(609)%20375-6295>@54.236.97.30:5060;alias=107.21.18.6~5060~1 SIP/2.0. Via: SIP/2.0/UDP 107.23.47.88:5060;branch=z9hG4bKbdb2. c896050feb9a2151548b9fe6c3f776fb.0. Via: SIP/2.0/UDP 172.22.1.2:53487;received=108.41.170.187;branch=z9hG4bK- 524287-1---1034af445c791a63;rport=53487. Max-Forwards: 68. Route: <sip:107.21.18.6;lr=on>. Contact: <sip:88919640010@108.41.170.187:53487;rinstance=37d7b85846910961>. To: "6093756295 <(609)%20375-6295>" <sip:6093756295@54.236.97.30>; tag=as372f68e0. From: <sip:88919640010@sip6.keku.com>;tag=d6323b02. Call-ID: 01e9e3e03dd2995d720bff297a226e83@54.236.97.30:5060. CSeq: 2 BYE. User-Agent: X-Lite release 4.9.6 stamp 82167. Content-Length: 0. . # U 107.21.18.6:5060 -> 10.0.0.68:5060 SIP/2.0 404 Not here. Via: SIP/2.0/UDP 107.23.47.88:5060;rport=5060;branch=z9hG4bKbdb2. c896050feb9a2151548b9fe6c3f776fb.0. Via: SIP/2.0/UDP 172.22.1.2:53487;received=108.41.170.187;branch=z9hG4bK- 524287-1---1034af445c791a63;rport=53487. To: "6093756295 <(609)%20375-6295>" <sip:6093756295@54.236.97.30>; tag=as372f68e0. From: <sip:88919640010@sip6.keku.com>;tag=d6323b02. Call-ID: 01e9e3e03dd2995d720bff297a226e83@54.236.97.30:5060. CSeq: 2 BYE. Server: kamailio (4.2.5 (x86_64/linux)). Content-Length: 0. . # U 10.0.0.68:5060 -> 108.41.170.187:53487 SIP/2.0 404 Not here. Via: SIP/2.0/UDP 172.22.1.2:53487;received=108.41.170.187;branch=z9hG4bK- 524287-1---1034af445c791a63;rport=53487. To: "6093756295 <(609)%20375-6295>" <sip:6093756295@54.236.97.30>; tag=as372f68e0. From: <sip:88919640010@sip6.keku.com>;tag=d6323b02. Call-ID: 01e9e3e03dd2995d720bff297a226e83@54.236.97.30:5060. CSeq: 2 BYE. Server: kamailio (4.2.5 (x86_64/linux)). Content-Length: 0.

2 1

sip6 BYE
by Mikhail Khomenkov 10 Mar '17

10 Mar '17

Hi i have some kind of issue with BYE Asterisk send invite to Kamailio1, Kamailio1 proxy to Kamailio2, Kamailio2 found UAC and send invite to it. UAC response 200OK -> Kamailio2 -> Kamailio1 -> Asterisk. Session established. But then UAC sending BYE to Kamailio2 , Kamailio2 sending it to Kamailio1 and Kamailio1 response 404 not here (not sending BYE to Asterisk) Any suggestions? 54.236.97.30 107.21.18.6 10.0.0.68 108.41.170.187 Asterisk Kamailio1 Kamailio2 UAC | invite | | | |--------------------------------> | invite | | | |------------------------------->| invite | | | |----------------------------------->| | | | 200OK | | | 200OK |<-----------------------------------| | 200OK |<-------------------------------| | |<--------------------------------| | | BYE | | BYE |<-----------------------------------| | |<-------------------------------| | | | 404 Not here | | | |------------------------------->| 404 Not here | | | |----------------------------------->| # U 107.21.18.6:5060 -> 10.0.0.68:5060 INVITE sip:88919640010@sip7.keku.com SIP/2.0. Record-Route: <sip:107.21.18.6;lr=on>. Via: SIP/2.0/UDP 107.21.18.6:5060 ;branch=z9hG4bK67a4.83b3107c510ddfe551896134a5e82554.0. Via: SIP/2.0/UDP 54.236.97.30:5060 ;received=54.236.97.30;branch=z9hG4bK3d97649d;rport=5060. Max-Forwards: 68. From: "6093756295" <sip:6093756295@54.236.97.30>;tag=as372f68e0. To: <sip:88919640010@sip6.keku.com>. Contact: <sip:6093756295@54.236.97.30:5060>. Call-ID: 01e9e3e03dd2995d720bff297a226e83@54.236.97.30:5060. CSeq: 102 INVITE. User-Agent: Asterisk PBX. Date: Fri, 10 Mar 2017 02:30:12 GMT. Min-SE: 120. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE. Supported: replaces, timer. Cisco-Guid: 1241711126_45859092(a)23.29.27.22. Content-Type: application/sdp. Content-Length: 237. . v=0. o=root 39119558 39119558 IN IP4 54.236.97.30. s=Asterisk PBX 1.8.28-cert5. c=IN IP4 54.236.97.30. t=0 0. m=audio 53626 RTP/AVP 0 101. a=rtpmap:0 PCMU/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=ptime:20. a=sendrecv. U 10.0.0.68:5060 -> 107.21.18.6:5060 SIP/2.0 100 trying -- your call is important to us. Via: SIP/2.0/UDP 107.21.18.6:5060 ;branch=z9hG4bK67a4.83b3107c510ddfe551896134a5e82554.0;rport=5060. Via: SIP/2.0/UDP 54.236.97.30:5060 ;received=54.236.97.30;branch=z9hG4bK3d97649d;rport=5060. From: "6093756295" <sip:6093756295@54.236.97.30>;tag=as372f68e0. To: <sip:88919640010@sip6.keku.com>. Call-ID: 01e9e3e03dd2995d720bff297a226e83@54.236.97.30:5060. CSeq: 102 INVITE. Server: kamailio (4.4.3 (x86_64/linux)). Content-Length: 0. . # U 10.0.0.68:5060 -> 108.41.170.187:53487 INVITE sip:88919640010@108.41.170.187:53487;rinstance=37d7b85846910961 SIP/2.0. Record-Route: <sip:107.23.47.88;lr>. Record-Route: <sip:107.21.18.6;lr=on>. Via: SIP/2.0/UDP 107.23.47.88:5060 ;branch=z9hG4bK67a4.d6f7e6b1f007e0958a99c6a6342e4e48.1. Via: SIP/2.0/UDP 107.21.18.6:5060 ;rport=5060;branch=z9hG4bK67a4.83b3107c510ddfe551896134a5e82554.0. Via: SIP/2.0/UDP 54.236.97.30:5060 ;received=54.236.97.30;branch=z9hG4bK3d97649d;rport=5060. Max-Forwards: 66. From: "6093756295" <sip:6093756295@54.236.97.30>;tag=as372f68e0. To: <sip:88919640010@sip6.keku.com>. Contact: <sip:6093756295@54.236.97.30:5060;alias=107.21.18.6~5060~1>. Call-ID: 01e9e3e03dd2995d720bff297a226e83@54.236.97.30:5060. CSeq: 102 INVITE. User-Agent: Asterisk PBX. Date: Fri, 10 Mar 2017 02:30:12 GMT. Min-SE: 120. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE. Supported: replaces, timer. Cisco-Guid: 1241711126_45859092(a)23.29.27.22. Content-Type: application/sdp. Content-Length: 645. . v=0. o=root 39119558 39119558 IN IP4 107.23.47.88. s=Asterisk PBX 1.8.28-cert5. c=IN IP4 107.23.47.88. t=0 0. m=audio 10054 RTP/SAVPF 0 101. a=rtpmap:0 PCMU/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=ptime:20. a=sendrecv. a=rtcp:10055. a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:v7hy4Ix2Re87vG/Fiymv20UGZ89xoWPp/dFzmiHq. a=setup:actpass. a=fingerprint:sha-1 18:F3:50:26:22:26:81:88:FB:95:F8:4B:3A:A7:9F:A6:F5:B7:B8:E3. a=ice-ufrag:ZgtwCEvD. a=ice-pwd:a0Tt54oToZFj9b42QXOM2Fq1VR. a=candidate:RzNgC40JM1mFcCUB 1 UDP 2130706431 107.23.47.88 10054 typ host. a=candidate:RzNgC40JM1mFcCUB 2 UDP 2130706430 107.23.47.88 10055 typ host. # U 108.41.170.187:53487 -> 10.0.0.68:5060 SIP/2.0 100 Trying. Via: SIP/2.0/UDP 107.23.47.88:5060 ;branch=z9hG4bK67a4.d6f7e6b1f007e0958a99c6a6342e4e48.1. Via: SIP/2.0/UDP 107.21.18.6:5060 ;rport=5060;branch=z9hG4bK67a4.83b3107c510ddfe551896134a5e82554.0. Via: SIP/2.0/UDP 54.236.97.30:5060 ;received=54.236.97.30;branch=z9hG4bK3d97649d;rport=5060. To: <sip:88919640010@sip6.keku.com>. From: "6093756295" <sip:6093756295@54.236.97.30>;tag=as372f68e0. Call-ID: 01e9e3e03dd2995d720bff297a226e83@54.236.97.30:5060. CSeq: 102 INVITE. Content-Length: 0. . # U 108.41.170.187:53487 -> 10.0.0.68:5060 SIP/2.0 180 Ringing. Via: SIP/2.0/UDP 107.23.47.88:5060 ;branch=z9hG4bK67a4.d6f7e6b1f007e0958a99c6a6342e4e48.1. Via: SIP/2.0/UDP 107.21.18.6:5060 ;rport=5060;branch=z9hG4bK67a4.83b3107c510ddfe551896134a5e82554.0. Via: SIP/2.0/UDP 54.236.97.30:5060 ;received=54.236.97.30;branch=z9hG4bK3d97649d;rport=5060. Record-Route: <sip:107.23.47.88;lr>. Record-Route: <sip:107.21.18.6;lr=on>. Contact: <sip:88919640010@108.41.170.187:53487;rinstance=37d7b85846910961>. To: "88919640010"<sip:88919640010@sip6.keku.com>;tag=d6323b02. From: "6093756295" <sip:6093756295@54.236.97.30>;tag=as372f68e0. Call-ID: 01e9e3e03dd2995d720bff297a226e83@54.236.97.30:5060. CSeq: 102 INVITE. User-Agent: X-Lite release 4.9.6 stamp 82167. Allow-Events: talk, hold. Content-Length: 0. . # U 10.0.0.68:5060 -> 107.21.18.6:5060 SIP/2.0 180 Ringing. Via: SIP/2.0/UDP 107.21.18.6:5060 ;rport=5060;branch=z9hG4bK67a4.83b3107c510ddfe551896134a5e82554.0. Via: SIP/2.0/UDP 54.236.97.30:5060 ;received=54.236.97.30;branch=z9hG4bK3d97649d;rport=5060. Record-Route: <sip:107.23.47.88;lr>. Record-Route: <sip:107.21.18.6;lr=on>. Contact: <sip:88919640010@108.41.170.187:53487;rinstance=37d7b85846910961>. To: "88919640010"<sip:88919640010@sip6.keku.com>;tag=d6323b02. From: "6093756295" <sip:6093756295@54.236.97.30>;tag=as372f68e0. Call-ID: 01e9e3e03dd2995d720bff297a226e83@54.236.97.30:5060. CSeq: 102 INVITE. User-Agent: X-Lite release 4.9.6 stamp 82167. Allow-Events: talk, hold. Content-Length: 0. . # U 108.41.170.187:53487 -> 10.0.0.68:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 107.23.47.88:5060 ;branch=z9hG4bK67a4.d6f7e6b1f007e0958a99c6a6342e4e48.1. Via: SIP/2.0/UDP 107.21.18.6:5060 ;rport=5060;branch=z9hG4bK67a4.83b3107c510ddfe551896134a5e82554.0. Via: SIP/2.0/UDP 54.236.97.30:5060 ;received=54.236.97.30;branch=z9hG4bK3d97649d;rport=5060. Record-Route: <sip:107.23.47.88;lr>. Record-Route: <sip:107.21.18.6;lr=on>. Contact: <sip:88919640010@108.41.170.187:53487;rinstance=37d7b85846910961>. To: <sip:88919640010@sip6.keku.com>;tag=d6323b02. From: "6093756295" <sip:6093756295@54.236.97.30>;tag=as372f68e0. Call-ID: 01e9e3e03dd2995d720bff297a226e83@54.236.97.30:5060. CSeq: 102 INVITE. Allow: SUBSCRIBE, NOTIFY, INVITE, ACK, CANCEL, BYE, REFER, INFO, OPTIONS, MESSAGE. Content-Type: application/sdp. Supported: replaces. User-Agent: X-Lite release 4.9.6 stamp 82167. Content-Length: 283. . v=0. o=- 620006012 3 IN IP4 172.22.1.2. s=X-Lite release 4.9.6 stamp 82167. c=IN IP4 172.22.1.2. t=0 0. m=audio 56064 RTP/SAVPF 0 101. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:aoNS33aJgrSvBRBRtHHhjlA+rLvd9ldUiUxXzoem. a=sendrecv. # U 10.0.0.68:5060 -> 107.21.18.6:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 107.21.18.6:5060 ;rport=5060;branch=z9hG4bK67a4.83b3107c510ddfe551896134a5e82554.0. Via: SIP/2.0/UDP 54.236.97.30:5060 ;received=54.236.97.30;branch=z9hG4bK3d97649d;rport=5060. Record-Route: <sip:107.23.47.88;lr>. Record-Route: <sip:107.21.18.6;lr=on>. Contact: <sip:88919640010@108.41.170.187:53487;rinstance=37d7b85846910961>. To: <sip:88919640010@sip6.keku.com>;tag=d6323b02. From: "6093756295" <sip:6093756295@54.236.97.30>;tag=as372f68e0. Call-ID: 01e9e3e03dd2995d720bff297a226e83@54.236.97.30:5060. CSeq: 102 INVITE. Allow: SUBSCRIBE, NOTIFY, INVITE, ACK, CANCEL, BYE, REFER, INFO, OPTIONS, MESSAGE. Content-Type: application/sdp. Supported: replaces. User-Agent: X-Lite release 4.9.6 stamp 82167. Content-Length: 215. . v=0. o=- 620006012 3 IN IP4 107.23.47.88. s=X-Lite release 4.9.6 stamp 82167. c=IN IP4 107.23.47.88. t=0 0. m=audio 10072 RTP/AVP 0 101. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=sendrecv. a=rtcp:10073. # U 107.21.18.6:5060 -> 10.0.0.68:5060 ACK sip:88919640010@108.41.170.187:53487;rinstance=37d7b85846910961 SIP/2.0. Via: SIP/2.0/UDP 107.21.18.6:5060 ;branch=z9hG4bK67a4.ff7b9cc9b887d892d7fd83e6f046b4d4.0. Via: SIP/2.0/UDP 54.236.97.30:5060 ;received=54.236.97.30;branch=z9hG4bK4e4d5063;rport=5060. Route: <sip:107.23.47.88;lr>. Max-Forwards: 68. From: "6093756295" <sip:6093756295@54.236.97.30>;tag=as372f68e0. To: <sip:88919640010@sip7.keku.com>;tag=d6323b02. Contact: <sip:6093756295@54.236.97.30:5060>. Call-ID: 01e9e3e03dd2995d720bff297a226e83@54.236.97.30:5060. CSeq: 102 ACK. User-Agent: Asterisk PBX. Content-Length: 0. . # U 10.0.0.68:5060 -> 108.41.170.187:53487 ACK sip:88919640010@108.41.170.187:53487;rinstance=37d7b85846910961 SIP/2.0. Via: SIP/2.0/UDP 107.23.47.88:5060 ;branch=z9hG4bK67a4.3a3af8e184f57334c9d42b8ce7d77849.0. Via: SIP/2.0/UDP 107.21.18.6:5060 ;rport=5060;branch=z9hG4bK67a4.ff7b9cc9b887d892d7fd83e6f046b4d4.0. Via: SIP/2.0/UDP 54.236.97.30:5060 ;received=54.236.97.30;branch=z9hG4bK4e4d5063;rport=5060. Max-Forwards: 66. From: "6093756295" <sip:6093756295@54.236.97.30>;tag=as372f68e0. To: <sip:88919640010@sip7.keku.com>;tag=d6323b02. Contact: <sip:6093756295@54.236.97.30:5060;alias=107.21.18.6~5060~1>. Call-ID: 01e9e3e03dd2995d720bff297a226e83@54.236.97.30:5060. CSeq: 102 ACK. User-Agent: Asterisk PBX. Content-Length: 0. . # U 108.41.170.187:53487 -> 10.0.0.68:5060 . . # U 108.41.170.187:53487 -> 10.0.0.68:5060 BYE sip:6093756295@54.236.97.30:5060;alias=107.21.18.6~5060~1 SIP/2.0. Via: SIP/2.0/UDP 172.22.1.2:53487 ;branch=z9hG4bK-524287-1---1034af445c791a63;rport. Max-Forwards: 70. Route: <sip:107.23.47.88;lr>. Route: <sip:107.21.18.6;lr=on>. Contact: <sip:88919640010@108.41.170.187:53487;rinstance=37d7b85846910961>. To: "6093756295" <sip:6093756295@54.236.97.30>;tag=as372f68e0. From: <sip:88919640010@sip6.keku.com>;tag=d6323b02. Call-ID: 01e9e3e03dd2995d720bff297a226e83@54.236.97.30:5060. CSeq: 2 BYE. User-Agent: X-Lite release 4.9.6 stamp 82167. Content-Length: 0. . # U 10.0.0.68:5060 -> 107.21.18.6:5060 BYE sip:6093756295@54.236.97.30:5060;alias=107.21.18.6~5060~1 SIP/2.0. Via: SIP/2.0/UDP 107.23.47.88:5060 ;branch=z9hG4bKbdb2.c896050feb9a2151548b9fe6c3f776fb.0. Via: SIP/2.0/UDP 172.22.1.2:53487 ;received=108.41.170.187;branch=z9hG4bK-524287-1---1034af445c791a63;rport=53487. Max-Forwards: 68. Route: <sip:107.21.18.6;lr=on>. Contact: <sip:88919640010@108.41.170.187:53487;rinstance=37d7b85846910961>. To: "6093756295" <sip:6093756295@54.236.97.30>;tag=as372f68e0. From: <sip:88919640010@sip6.keku.com>;tag=d6323b02. Call-ID: 01e9e3e03dd2995d720bff297a226e83@54.236.97.30:5060. CSeq: 2 BYE. User-Agent: X-Lite release 4.9.6 stamp 82167. Content-Length: 0. . # U 107.21.18.6:5060 -> 10.0.0.68:5060 SIP/2.0 404 Not here. Via: SIP/2.0/UDP 107.23.47.88:5060 ;rport=5060;branch=z9hG4bKbdb2.c896050feb9a2151548b9fe6c3f776fb.0. Via: SIP/2.0/UDP 172.22.1.2:53487 ;received=108.41.170.187;branch=z9hG4bK-524287-1---1034af445c791a63;rport=53487. To: "6093756295" <sip:6093756295@54.236.97.30>;tag=as372f68e0. From: <sip:88919640010@sip6.keku.com>;tag=d6323b02. Call-ID: 01e9e3e03dd2995d720bff297a226e83@54.236.97.30:5060. CSeq: 2 BYE. Server: kamailio (4.2.5 (x86_64/linux)). Content-Length: 0. . # U 10.0.0.68:5060 -> 108.41.170.187:53487 SIP/2.0 404 Not here. Via: SIP/2.0/UDP 172.22.1.2:53487 ;received=108.41.170.187;branch=z9hG4bK-524287-1---1034af445c791a63;rport=53487. To: "6093756295" <sip:6093756295@54.236.97.30>;tag=as372f68e0. From: <sip:88919640010@sip6.keku.com>;tag=d6323b02. Call-ID: 01e9e3e03dd2995d720bff297a226e83@54.236.97.30:5060. CSeq: 2 BYE. Server: kamailio (4.2.5 (x86_64/linux)). Content-Length: 0.

3 2

Bounty for topos fix
by Trevor Peirce 09 Mar '17

09 Mar '17

Hello, I would like to offer a $100 USD bounty if a developer is able to provide a fix for the two topos problems I have experienced. I will add another $50 if this can be solved within 48 hours of the time stamp of this message. The bug report is at: https://github.com/kamailio/kamailio/issues/1005 You may find the most relevant information in my last few updates. Please refer to mar1-nat.txt and mar1-reinvite.txt for the most recent SIP captures, and the post below that for example database records. Steps to reproduce the NAT problem can be found at https://github.com/kamailio/kamailio/issues/1005#issuecomment-283255720 Some fine print to clarify the offer: Payment is contingent on resolving both described use-cases. Payment will be sent via your choice of PayPal, cheque drawn on a US bank, or cheque drawn on a Canadian bank. Payment will be issued once the patch is accepted by the Kamailio project, although the bonus for a quick resolution simply requires a suitable patch to be submitted to the bug tracker within 48 hours from now. Thanks! -- Trevor Peirce AcroVoice Solutions Inc

1 1

Changes in LCR Target List doesn't takes place immediately
by Nitesh Lohchab 09 Mar '17

09 Mar '17

Hello, I believe LCR Target list is stored in the database and any changes made here should affect the behaviour of the calls imedialtely. I have changed one of my Target List Rule , where I changed my gateway Id to another gateway. But the calls are still being routed via previous gateway. Is there something I can do to make the changes in production hours. Sometimes one of carriers delivers bad call quality I would like to switch the carriers. -- Regards, Nitesh Lohchab

2 1

rtpengine sending rtp to wrong endpoint after reinvite
by Grant Bagdasarian 09 Mar '17

09 Mar '17

Hi, One of our customers is using a SEMS box to place two outbound calls using our sip trunk. Once the first call is connected a second call is placed and when the second call answers their server sends a re-invite to switch audio ports so the rtp traffic doesn't flow through their server anymore but is routed inside our platform. Basically, they just switch SDP's of both calls. It seems like a random issue, and is not really reproducible, except for placing multiple calls and sometimes both parties can hear each other, other times they can't, because rtpengine fails (I think) to update the endpoint and keeps sending rtp back to their server for one of the call legs. We tried to reproduce the case using a freeswitch box and it worked every time. After the reinvite, the rtp remained within our platform. The signaling in both cases still goes through the freeswitch or sems for call control. Does anyone have experience with this case? Or seen the issue before where rtpengine keeps sending rtp to the original endpoint? Regards, Grant Bagdasarian CM

2 3

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