- sr-users - kamailio.org

kamcmd permissions problem
by Uri Shacked 10 Jun '15

10 Jun '15

Hi, I am using exec_avp() command from kamailio. The command execute a shell script that runs kamctl and kamcmd commands. kamailio runs with user 'kamailio' and group 'kamailio' (defaults). There is not problem with the kamctl commands. But, the kamcmd commands fails due to permissions issues. Any ideas? Cheers, Uri

2 1

403 not relaying
by jaflong jaflong 09 Jun '15

09 Jun '15

Hi, I am getting a 403 not relaying response. This is the part of the config How would I print the value of var myself, from_uri and uri # if caller is not local subscriber, then check if it calls # a local destination, otherwise deny, not an open relay here if (from_uri!=myself && uri!=myself) { sl_send_reply("403","Not relaying"); exit; }

2 1

IP fragment
by Tuan Viet Nguyen 09 Jun '15

09 Jun '15

Hello, I would like to know if Kamailio handles the case where we receive a big SIP message fragmented in IP layer? Thanks,

2 2

Testing RPMs for v4.3.0
by Daniel-Constantin Mierla 09 Jun '15

09 Jun '15

Hello, in preparation for releasing v4.3.0 next week, I updated the specs for building RPMs from branch 4.3. However, I am not able to test the results, just made sure the build is ok. Packages are available at: - https://build.opensuse.org/package/show/home:kamailio:v4.3.x-rpms/kamailio43 I hope people here using RPMs will do some tests and provide feedback, interested mainly in: - it installs ok - after install, it starts ok with default configuration file - fifo and unix sockets are created now in /var/run/kamailio, so it has to be checked they are there - kamctl works ok for commands: ps, uptime and 'mi version' Some modules are not packaged in various versions, as I could not spot what are the packages needed for building them and if they are available with different names. For example, apparently jansson lib is on redhat, but not on centos, libev doesn't seem to be there. Also, I haven't had time to look at packaging erlang module. Help with the above is appreciated as well as helping building RPMs genrally. Maybe the init.d script needs to be reviewed and updated as well. 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 4

Need information regarding kamilio setup to support IPSec
by Priyaranjan Nayak 09 Jun '15

09 Jun '15

Hi All, I have a ims client endpoint supporting rfc 3329(IPSec).Now I am sending register message to kamailio server with Security-Client header and not getting any Security-Server header in response. Could you please tell me below queries - Whether kamailio server supporting rfc 3329 (IPSec) or not ? - If yes,how can we setup kamailio server to support Security-Client,Security-Server and Security-varify(as per rfc 3329) header ? Thanks Priyaranjan

3 3

Private IP in SDP packet headers
by Alex 08 Jun '15

08 Jun '15

Hello! Please help to fix problem with sdp headers UAC Inet -> (X.X.X.X) Kamailio (192.168.30.250) -> Asterisk (192.168.30.2) When i call from UAC to 9002 i received INVITE/SDP from kamailio SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.1.52:27080 ;received=10.10.101.50;branch=z9hG4bK-d8754z-027c786dac17bf68-1---d8754z-;rport=27080 Record-Route: <sip :192.168.30.2;line=sr-mYtaP6eErk-dx6VfrLzfr6BaPGj0OHFfPYd0OHFfPYIQpHmFr9mQPKDEx9VlvZ8QO4ttma**> Record-Route: <sip:X.X.X.X;r2=on;lr=on;ftag=0748d948;nat=yes> From: <sip:user4@X.X.X.X>;tag=0748d948 To: <sip:9002@X.X.X.X>;tag=as3914e1d1 Call-ID: ZWU5YmFiNTNhNmNmYWQzYzhkZWUzZDNjOTU3MDFiNGU. CSeq: 2 INVITE Server: Virtel.net Node2 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Supported: replaces, timer Contact: <sip:192.168.30.2;line=sr-mYtaP62ar9nzrg20y6eYPA-LrA-0P6Bax6z*> Content-Type: application/sdp Content-Length: 278 v=0 o=root 732368067 732368067 IN IP4 X.X.X.X s=Asterisk PBX 11.17.1 c=IN IP4 X.X.X.X t=0 0 m=audio 15768 RTP/AVP 0 8 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=sendrecv a=nortpproxy:yes Why Record-Route and Contact fields contain private IP of asterisk ?

2 1

Need to add extra header in 200 OK message by using kamailio.cfg file
by Priyaranjan Nayak 08 Jun '15

08 Jun '15

Hi All, I wanted to send a extra header(i.e. Security-Server ) in the 200 OK from kamailio server. Could you please suggest me how can I add extra header in 200 OK message by using kamailio.cfg file ? Thanks Priyaranjan

3 4

msilo storage of message id
by Shouvanik Chakrabarti 07 Jun '15

07 Jun '15

Hello. We have been using the msilo module to handle offline SIP messaging. I have noticed that the m_store function ends up storing all the records with the default message id which is zero. However m_dump uses this id to figure which messages have already been sent. Thus on calling m_dump on registration, no messages are dumped. We simply get a 'message already sent' debug log. Is there a way around this? Any help would be deeply appreciated. Thanks, Shouvanik.

2 2

Kamailio second contact header
by Ali Taher 05 Jun '15

05 Jun '15

Hello, I'm trying to build new contact header that will be sent from Kamailio as below : load_gws(1, $rU, $fu); append_to_reply("Contact:"); while (next_gw()) { append_to_reply("$ru"); } append_to_reply("\r\n"); sl_send_reply("300","Multiple Choices"); exit; yet I'm getting two Contact headers as shown in below SIP message. How can I remove second contact header (highlighted below in gray) Via: SIP/2.0/UDP 192.168.26.3:42528;branch=z9hG4bK-d8754z-4c2cc56c3145b446-1---d8754z-;rport= 42528;received=192.168.26.3 To: "9612"<sip:9612@192.168.110.181>;tag=b27e1a1d33761e85846fc98f5f3a7e58.1a8d From: "test"<sip:test@192.168.110.181>;tag=8571af74 Call-ID: Y2MzOTNiOGRhMTc2NDkwZjIxNzZhYTAzZmM0OGE3NDY CSeq: 2 INVITE Contact: sip:9612@C001,sip:9612@192.168.26.1,sip:9612@192.168.26.6,sip:9612@192.168.2 6.8 Contact: sip:9612@192.168.26.8 Server: kamailio (4.1.8 (x86_64/linux)) Content-Length: 0 Thanks, Ali

2 12

Misc Radius can't parse sip-avps?
by Yasin CANER 05 Jun '15

05 Jun '15

Hello all; i am working on misc_radius modulü. i configured system like below. and when i try to write debug , it gives <null> Could you take a look what i am doing wrong Thanks -----FREERADIUS----- 101(a)192.168.0.188 Auth-Type := Accept, Service-Type == "SIP-Caller-AVPs" Sip-Avp = "#3#1" --------------------------- -----------Kamailio.cfg modparam("misc_radius", "radius_config", "/etc/radiusclient-ng/radiusclient.conf") modparam("misc_radius", "group_service_type", 12) modparam("misc_radius", "uri_service_type", 10) modparam("misc_radius", "caller_service_type", 30) modparam("misc_radius", "callee_service_type", 31) modparam("misc_radius", "caller_extra", "Calling-Station-Id=$fu") modparam("misc_radius", "callee_extra", "SIP-URI-User=$rU;SIP-URI-Host=$rd") #modparam("misc_radius", "group_extra", "My-Special=$avp(i:100)") modparam("misc_radius", "uri_extra", "Called-Station-Id=$tu") modparam("misc_radius", "common_response", 1) #"dont forget to change caller_service_type to 30 and callee_service_type to 31 as written in dictionary.kamailio" if(is_method("INVITE")){ if(!radius_load_caller_avps("$fU(a)192.168.0.188")){ xlog("L_ALERT","Bulamadim Bulamadim"); sl_send_reply("403", "Forbidden - Bulamadim"); exit; } xlog("L_ALERT"," i3 $avp(i:3) $avp(s:3) s6 $avp(6) $avp(session-protocol) $avp(Sip-Avp)"); } -------------------------- ---------RESULT-------- 1(21867) DEBUG: misc_radius [functions.c:453]: radius_is_user_in(): success 1(21867) DEBUG: misc_radius [functions.c:268]: radius_load_caller_avps(): success 1(21867) DEBUG: misc_radius [functions.c:137]: generate_avps_rad(): AVP 'SIP-AVP'/0='#3#1'/0 has been added May 25 15:05:28 group1-imslab11 /usr/local/sbin/kamailio[21587]: ALERT: <script>: i3 <null> <null> s6 <null> <null> 3#1 --------------------------

3 6

Kamailio fails to start if cannot connect to MySQL
by Al S 05 Jun '15

05 Jun '15

Hi, We have verified if MySQL server is offline when Kamailio is starting, Kamailio fails to start correctly.Is this a bug? Jun 4 10:53:22 ape /usr/sbin/kamailio[10630]: ERROR: db_mysql [km_my_con.c:109]: driver error: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)Jun 4 10:53:22 ape /usr/sbin/kamailio[10630]: ERROR: <core> [db.c:320]: could not add connection to the poolJun 4 10:53:22 ape /usr/sbin/kamailio[10630]: ERROR: usrloc [dlist.c:518]: failed to open database connectionJun 4 10:53:22 ape /usr/sbin/kamailio[10630]: ERROR: registrar [reg_mod.c:472]: failed to register domainJun 4 10:53:22 ape /usr/sbin/kamailio[10630]: ERROR: <core> [route.c:1216]: fixing failed (code=-1) at cfg:/etc/kamailio/kamailio.cfg:858Jun 4 10:53:22 ape /usr/sbin/kamailio[10630]: ERROR: <core> [route.c:1216]: fixing failed (code=-1) at cfg:/etc/kamailio/kamailio.cfg:861Jun 4 10:53:22 ape /usr/sbin/kamailio[10630]: ERROR: <core> [route.c:1216]: fixing failed (code=-1) at cfg:/etc/kamailio/kamailio.cfg:863 We are running kamailio 3.3.7. Thanks,Al

3 2

Private IP in SDP packet headers
by Alex 05 Jun '15

05 Jun '15

Hello! Please help to fix problem with sdp headers UAC Inet -> (X.X.X.X) Kamailio (192.168.30.250) -> Asterisk (192.168.30.2) When i call from UAC to 9002 i received INVITE/SDP from kamailio SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.1.52:27080 ;received=10.10.101.50;branch=z9hG4bK-d8754z-027c786dac17bf68-1---d8754z-;rport=27080 Record-Route: <sip:192.168.30.2;line=sr-mYtaP6eErk-dx6VfrLzfr6BaPGj0OHFfPYd0OHFfPYIQpHmFr9mQPKDEx9VlvZ8QO4ttma**> Record-Route: <sip:X.X.X.X;r2=on;lr=on;ftag=0748d948;nat=yes> From: <sip:user4@X.X.X.X>;tag=0748d948 To: <sip:9002@X.X.X.X>;tag=as3914e1d1 Call-ID: ZWU5YmFiNTNhNmNmYWQzYzhkZWUzZDNjOTU3MDFiNGU. CSeq: 2 INVITE Server: Virtel.net Node2 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Supported: replaces, timer Contact: <sip:192.168.30.2;line=sr-mYtaP62ar9nzrg20y6eYPA-LrA-0P6Bax6z*> Content-Type: application/sdp Content-Length: 278 v=0 o=root 732368067 732368067 IN IP4 X.X.X.X s=Asterisk PBX 11.17.1 c=IN IP4 X.X.X.X t=0 0 m=audio 15768 RTP/AVP 0 8 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=sendrecv a=nortpproxy:yes Why Record-Route and Contact fields contain private IP of asterisk ?

2 1

How should a PBX behave when a user dials a DID configured for the same or another tenant on that PBX?
by Antonio Gómez Soto 04 Jun '15

04 Jun '15

Hello, This is question on PBX behavior, what is the right thing to do, and how do PBX's generally behave. If a user on a phone, dials a number, which happens to be configured on the same phone system (for example another tenant), there are two options: 1. The PBX notices this, and directly connects the phone to the DID on that system 2. The PBX sends the call out on the SIP trunk, and the provider-routing sends the call back as an incoming call. What are the pros and cons of each option? How do PBX's generally behave? Thanks, Antonio

2 1

Getting 404 From Kamailio for PRACK
by Austin Einter 04 Jun '15

04 Jun '15

Hi All I am trying ti implement a IMS client. For testing I am using Kamailio proxy. During call setup, I get 404 for Prack message. Whats going wrong not able to figure out. Here is the Kamailio log below, can somebody help me too find whats wrong her. *11(25376) DEBUG: sl [sl.c:296]: send_reply(): reply in stateless mode (sl)11(25376) DEBUG: <core> [msg_translator.c:206]: check_via_address(): check_via_address(192.168.1.195, 192.168.1.195, 0)11(25376) DEBUG: <core> [tcp_main.c:2281]: tcpconn_send_put(): tcp_send: send from reader (25376 (11)), reusing fd11(25376) DEBUG: <core> [tcp_main.c:2516]: tcpconn_do_send(): tcp_send: sending...11(25376) DEBUG: <core> [tcp_main.c:2550]: tcpconn_do_send(): tcp_send: after real write: c= 0x7fe2ebd05390 n=386 fd=511(25376) DEBUG: <core> [tcp_main.c:2551]: tcpconn_do_send(): tcp_send: buf=SIP/2.0 200 OKVia: SIP/2.0/TCP 192.168.1.195:40611;branch=z9hG4bK1186661565From: <sip:linux_ua_1@192.168.1.195 <sip%3Alinux_ua_1(a)192.168.1.195>>;tag=1307796831To: <sip:linux_ua_1@192.168.1.195 <sip%3Alinux_ua_1(a)192.168.1.195>>;tag=25fbdd2b0c9b93b0791296269f5ae411.38a0Call-ID: 835380265(a)192.168.1.195 <835380265(a)192.168.1.195>CSeq: 2 REGISTERContact: <sip:linux_ua_1@192.168.1.195:40611;transport=tcp>;expires=3600Server: kamailio (4.2.3 (x86_64/linux))Content-Length: 011(25376) DEBUG: <core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil)11(25376) DEBUG: <core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil)11(25376) DEBUG: <core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil)11(25376) DEBUG: <core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil)11(25376) DEBUG: <core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil)11(25376) DEBUG: <core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil)11(25376) DEBUG: <core> [xavp.c:448]: xavp_destroy_list(): destroying xavp list (nil)11(25376) DEBUG: <core> [receive.c:298]: receive_msg(): receive_msg: cleaning up11(25376) DEBUG: <core> [io_wait.h:388]: io_watch_add(): DBG: io_watch_add(0xa33180, 5, 2, 0x7fe2ebd05390), fd_no=111(25376) DEBUG: <core> [tcp_read.c:1362]: tcp_read_req(): tcp_read_req: content-length= 011(25376) DEBUG: <core> [parser/msg_parser.c:623]: parse_msg(): SIP Request:11(25376) DEBUG: <core> [parser/msg_parser.c:625]: parse_msg(): method: <SUBSCRIBE>11(25376) DEBUG: <core> [parser/msg_parser.c:627]: parse_msg(): uri: <sip:linux_ua_1@192.168.1.195 <sip%3Alinux_ua_1(a)192.168.1.195>>11(25376) DEBUG: <core> [parser/msg_parser.c:629]: parse_msg(): version: <SIP/2.0>11(25376) DEBUG: <core> [parser/parse_via.c:1284]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK1577674881>; state=1611(25376) DEBUG: <core> [parser/parse_via.c:2672]: parse_via(): end of header reached, state=511(25376) DEBUG: <core> [parser/msg_parser.c:513]: parse_headers(): parse_headers: Via found, flags=211(25376) DEBUG: <core> [parser/msg_parser.c:515]: parse_headers(): parse_headers: this is the first via11(25376) DEBUG: <core> [receive.c:154]: receive_msg(): After parse_msg...11(25376) DEBUG: <core> [receive.c:197]: receive_msg(): preparing to run routing scripts...11(25376) DEBUG: <core> [parser/parse_addr_spec.c:898]: parse_addr_spec(): end of header reached, state=1011(25376) DEBUG: <core> [parser/msg_parser.c:190]: get_hdr_field(): DEBUG: get_hdr_field: <To> [28]; uri=[sip:linux_ua_1@192.168.1.195 <sip%3Alinux_ua_1(a)192.168.1.195>] 11(25376) DEBUG: <core> [parser/msg_parser.c:192]: get_hdr_field(): DEBUG: to body [<sip:linux_ua_1@192.168.1.195 <sip%3Alinux_ua_1(a)192.168.1.195>>]11(25376) DEBUG: <core> [parser/msg_parser.c:170]: get_hdr_field(): get_hdr_field: cseq <CSeq>: <2> <SUBSCRIBE>11(25376) DEBUG: maxfwd [mf_funcs.c:85]: is_maxfwd_present(): value = 70 11(25376) DEBUG: <core> [parser/msg_parser.c:204]: get_hdr_field(): DEBUG: get_hdr_body : content_length=011(25376) DEBUG: <core> [parser/msg_parser.c:106]: get_hdr_field(): found end of header11(25376) DEBUG: <core> [parser/parse_addr_spec.c:176]: parse_to_param(): DEBUG: add_param: tag=133567903511(25376) DEBUG: <core> [parser/parse_addr_spec.c:898]: parse_addr_spec(): end of header reached, state=2911(25376) DEBUG: sanity [mod_sanity.c:255]: w_sanity_check(): sanity checks result: 111(25376) DEBUG: siputils [checks.c:103]: has_totag(): no totag11(25376) DEBUG: tm [t_lookup.c:1072]: t_check_msg(): DEBUG: t_check_msg: msg id=2 global id=1 T start=(nil)11(25376) DEBUG: tm [t_lookup.c:527]: t_lookup_request(): t_lookup_request: start searching: hash=34123, isACK=011(25376) DEBUG: tm [t_lookup.c:485]: matching_3261(): DEBUG: RFC3261 transaction matching failed11(25376) DEBUG: tm [t_lookup.c:709]: t_lookup_request(): DEBUG: t_lookup_request: no transaction found11(25376) DEBUG: tm [t_lookup.c:1141]: t_check_msg(): DEBUG: t_check_msg: msg id=2 global id=2 T end=(nil)11(25376) DEBUG: <core> [socket_info.c:583]: grep_sock_info(): grep_sock_info - checking if host==us: 13==13 && [192.168.1.195] == [192.168.1.195]11(25376) DEBUG: <core> [socket_info.c:587]: grep_sock_info(): grep_sock_info - checking if port 4060 (advertise 0) matches port 506011(25376) DEBUG: <core> [socket_info.c:583]: grep_sock_info(): grep_sock_info - checking if host==us: 13==13 && [192.168.1.195] == [192.168.1.195]11(25376) DEBUG: <core> [socket_info.c:587]: grep_sock_info(): grep_sock_info - checking if port 4060 (advertise 0) matches port 506011(25376) DEBUG: <core> [socket_info.c:583]: grep_sock_info(): grep_sock_info - checking if host==us: 13==13 && [192.168.1.195] == [192.168.1.195]11(25376) DEBUG: <core> [socket_info.c:587]: grep_sock_info(): grep_sock_info - checking if port 4090 (advertise 0) matches port 506011(25376) DEBUG: registrar [lookup.c:203]: lookup_helper(): contact for [linux_ua_1] cannot handle the SIP method11(25376) DEBUG: registrar [lookup.c:211]: lookup_helper(): 'linux_ua_1' has no valid contact in usrloc11(25376) DEBUG: tm [t_lookup.c:1373]: t_newtran(): DEBUG: t_newtran: msg id=2 , global msg id=2 , T on entrance=(nil)11(25376) DEBUG: tm [t_lookup.c:527]: t_lookup_request(): t_lookup_request: start searching: hash=34123, isACK=011(25376) DEBUG: tm [t_lookup.c:485]: matching_3261(): DEBUG: RFC3261 transaction matching failed11(25376) DEBUG: tm [t_lookup.c:709]: t_lookup_request(): DEBUG: t_lookup_request: no transaction found11(25376) DEBUG: tm [t_hooks.c:380]: run_reqin_callbacks_internal(): DBG: trans=0x7fe2ebd10e68, callback type 1, id 0 entered11(25376) DEBUG: <core> [md5utils.c:67]: MD5StringArray(): DEBUG: MD5 calculated: c17c6f2bd5d60787072aef8ffcf5bfe611(25376) DEBUG: tm [t_lookup.c:1072]: t_check_msg(): DEBUG: t_check_msg: msg id=2 global id=2 T start=0x7fe2ebd10e6811(25376) DEBUG: tm [t_lookup.c:1144]: t_check_msg(): DEBUG: t_check_msg: T already found!11(25376) DEBUG: <core> [msg_translator.c:206]: check_via_address(): check_via_address(192.168.1.195, 192.168.1.195, 0)11(25376) DEBUG: <core> [mem/shm_mem.c:111]: _shm_resize(): WARNING:vqm_resize: resize(0) called11(25376) DEBUG: tm [t_reply.c:1653]: cleanup_uac_timers(): DEBUG: cleanup_uac_timers: RETR/FR timers reset11(25376) DEBUG: <core> [tcp_main.c:2281]: tcpconn_send_put(): tcp_send: send from reader (25376 (11)), reusing fd11(25376) DEBUG: <core> [tcp_main.c:2516]: tcpconn_do_send(): tcp_send: sending...11(25376) DEBUG: <core> [tcp_main.c:2550]: tcpconn_do_send(): tcp_send: after real write: c= 0x7fe2ebd05390 n=334 fd=511(25376) DEBUG: <core> [tcp_main.c:2551]: tcpconn_do_send(): tcp_send: buf=SIP/2.0 405 Method Not AllowedVia: SIP/2.0/TCP 192.168.1.195:40611;branch=z9hG4bK1577674881From: <sip:linux_ua_1@192.168.1.195 <sip%3Alinux_ua_1(a)192.168.1.195>>;tag=1335679035To: <sip:linux_ua_1@192.168.1.195 <sip%3Alinux_ua_1(a)192.168.1.195>>;tag=ff272440259f71af2c767e7942717037-95d5Call-ID: 1397060040(a)192.168.1.195 <1397060040(a)192.168.1.195>CSeq: 2 SUBSCRIBEServer: kamailio (4.2.3 (x86_64/linux))Content-Length: 011(25376) DEBUG: tm [t_reply.c:728]: _reply_light(): DEBUG: reply sent out. buf=0x7fe30fea65c0: SIP/2.0 405 Method N..., shmem=0x7fe2ebd135a8: SIP/2.0 405 Method N11(25376) DEBUG: tm [t_reply.c:738]: _reply_light(): DEBUG: _reply_light: finished11(25376) DEBUG: sl [sl.c:288]: send_reply(): reply in stateful mode (tm)11(25376) DEBUG: <core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil)11(25376) DEBUG: <core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil)11(25376) DEBUG: <core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil)11(25376) DEBUG: <core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil)11(25376) DEBUG: <core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil)11(25376) DEBUG: <core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil)11(25376) DEBUG: <core> [xavp.c:448]: xavp_destroy_list(): destroying xavp list (nil)11(25376) DEBUG: <core> [receive.c:298]: receive_msg(): receive_msg: cleaning up 9(25374) DEBUG: websocket [ws_conn.c:459]: wsconn_get_list(): wsconn_get_list 9(25374) DEBUG: websocket [ws_conn.c:503]: wsconn_get_list(): wsconn_get_list returns list [(nil)] with [0] members10(25375) DEBUG: <core> [tcp_read.c:1362]: tcp_read_req(): tcp_read_req: content-length= 35910(25375) DEBUG: <core> [parser/msg_parser.c:623]: parse_msg(): SIP Request:10(25375) DEBUG: <core> [parser/msg_parser.c:625]: parse_msg(): method: <INVITE>10(25375) DEBUG: <core> [parser/msg_parser.c:627]: parse_msg(): uri: <sip:linux_ua_1@192.168.1.195 <sip%3Alinux_ua_1(a)192.168.1.195>>10(25375) DEBUG: <core> [parser/msg_parser.c:629]: parse_msg(): version: <SIP/2.0>10(25375) DEBUG: <core> [parser/parse_via.c:1284]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK1970975121>; state=1610(25375) DEBUG: <core> [parser/parse_via.c:2672]: parse_via(): end of header reached, state=510(25375) DEBUG: <core> [parser/msg_parser.c:513]: parse_headers(): parse_headers: Via found, flags=210(25375) DEBUG: <core> [parser/msg_parser.c:515]: parse_headers(): parse_headers: this is the first via10(25375) DEBUG: <core> [receive.c:154]: receive_msg(): After parse_msg...10(25375) DEBUG: <core> [receive.c:197]: receive_msg(): preparing to run routing scripts...10(25375) DEBUG: <core> [parser/parse_addr_spec.c:898]: parse_addr_spec(): end of header reached, state=1010(25375) DEBUG: <core> [parser/msg_parser.c:190]: get_hdr_field(): DEBUG: get_hdr_field: <To> [28]; uri=[sip:linux_ua_1@192.168.1.195 <sip%3Alinux_ua_1(a)192.168.1.195>] 10(25375) DEBUG: <core> [parser/msg_parser.c:192]: get_hdr_field(): DEBUG: to body [<sip:linux_ua_1@192.168.1.195 <sip%3Alinux_ua_1(a)192.168.1.195>>]10(25375) DEBUG: <core> [parser/msg_parser.c:170]: get_hdr_field(): get_hdr_field: cseq <CSeq>: <2> <INVITE>10(25375) DEBUG: maxfwd [mf_funcs.c:85]: is_maxfwd_present(): value = 70 10(25375) DEBUG: <core> [parser/msg_parser.c:204]: get_hdr_field(): DEBUG: get_hdr_body : content_length=35910(25375) DEBUG: <core> [parser/msg_parser.c:106]: get_hdr_field(): found end of header10(25375) DEBUG: <core> [parser/parse_addr_spec.c:176]: parse_to_param(): DEBUG: add_param: tag=60426366410(25375) DEBUG: <core> [parser/parse_addr_spec.c:898]: parse_addr_spec(): end of header reached, state=2910(25375) DEBUG: sanity [mod_sanity.c:255]: w_sanity_check(): sanity checks result: 110(25375) DEBUG: siputils [checks.c:103]: has_totag(): no totag10(25375) DEBUG: tm [t_lookup.c:1072]: t_check_msg(): DEBUG: t_check_msg: msg id=3 global id=2 T start=0xffffffffffffffff10(25375) DEBUG: tm [t_lookup.c:527]: t_lookup_request(): t_lookup_request: start searching: hash=12870, isACK=010(25375) DEBUG: tm [t_lookup.c:485]: matching_3261(): DEBUG: RFC3261 transaction matching failed10(25375) DEBUG: tm [t_lookup.c:709]: t_lookup_request(): DEBUG: t_lookup_request: no transaction found10(25375) DEBUG: tm [t_lookup.c:1141]: t_check_msg(): DEBUG: t_check_msg: msg id=3 global id=3 T end=(nil)10(25375) DEBUG: <core> [socket_info.c:583]: grep_sock_info(): grep_sock_info - checking if host==us: 13==13 && [192.168.1.195] == [192.168.1.195]10(25375) DEBUG: <core> [socket_info.c:587]: grep_sock_info(): grep_sock_info - checking if port 4060 (advertise 0) matches port 506010(25375) DEBUG: <core> [socket_info.c:583]: grep_sock_info(): grep_sock_info - checking if host==us: 13==13 && [192.168.1.195] == [192.168.1.195]10(25375) DEBUG: <core> [socket_info.c:587]: grep_sock_info(): grep_sock_info - checking if port 4060 (advertise 0) matches port 506010(25375) DEBUG: <core> [socket_info.c:583]: grep_sock_info(): grep_sock_info - checking if host==us: 13==13 && [192.168.1.195] == [192.168.1.195]10(25375) DEBUG: <core> [socket_info.c:587]: grep_sock_info(): grep_sock_info - checking if port 4090 (advertise 0) matches port 506010(25375) DEBUG: registrar [lookup.c:198]: lookup_helper(): contact for [linux_ua_1] found by address10(25375) DEBUG: tm [t_lookup.c:1373]: t_newtran(): DEBUG: t_newtran: msg id=3 , global msg id=3 , T on entrance=(nil)10(25375) DEBUG: tm [t_lookup.c:527]: t_lookup_request(): t_lookup_request: start searching: hash=12870, isACK=010(25375) DEBUG: tm [t_lookup.c:485]: matching_3261(): DEBUG: RFC3261 transaction matching failed10(25375) DEBUG: tm [t_lookup.c:709]: t_lookup_request(): DEBUG: t_lookup_request: no transaction found10(25375) DEBUG: tm [t_hooks.c:380]: run_reqin_callbacks_internal(): DBG: trans=0x7fe2ebd13848, callback type 1, id 0 entered10(25375) DEBUG: <core> [md5utils.c:67]: MD5StringArray(): DEBUG: MD5 calculated: c4c3d26baa62dea619271f186d6344fc10(25375) DEBUG: tm [t_funcs.c:347]: t_relay_to(): SER: new INVITE10(25375) DEBUG: <core> [msg_translator.c:206]: check_via_address(): check_via_address(192.168.1.195, 192.168.1.195, 0)10(25375) DEBUG: <core> [mem/shm_mem.c:111]: _shm_resize(): WARNING:vqm_resize: resize(0) called10(25375) DEBUG: <core> [tcp_main.c:2281]: tcpconn_send_put(): tcp_send: send from reader (25375 (10)), reusing fd10(25375) DEBUG: <core> [tcp_main.c:2516]: tcpconn_do_send(): tcp_send: sending...10(25375) DEBUG: <core> [tcp_main.c:2550]: tcpconn_do_send(): tcp_send: after real write: c= 0x7fe2ebd096b0 n=307 fd=510(25375) DEBUG: <core> [tcp_main.c:2551]: tcpconn_do_send(): tcp_send: buf=SIP/2.0 100 trying -- your call is important to usVia: SIP/2.0/TCP 192.168.1.195:19009;branch=z9hG4bK1970975121From: <sip:linux_ua_0@192.168.1.195 <sip%3Alinux_ua_0(a)192.168.1.195>>;tag=604263664To: <sip:linux_ua_1@192.168.1.195 <sip%3Alinux_ua_1(a)192.168.1.195>>Call-ID: 734015646(a)192.168.1.195 <734015646(a)192.168.1.195>CSeq: 2 INVITEServer: kamailio (4.2.3 (x86_64/linux))Content-Length: 010(25375) DEBUG: tm [t_reply.c:728]: _reply_light(): DEBUG: reply sent out. buf=0x7fe30fea6968: SIP/2.0 100 trying -..., shmem=0x7fe2ebd163f0: SIP/2.0 100 trying -10(25375) DEBUG: tm [t_reply.c:738]: _reply_light(): DEBUG: _reply_light: finished10(25375) DEBUG: <script>: new branch [0] to sip:linux_ua_1@192.168.1.195:40611;transport=tcp10(25375) DEBUG: <core> [msg_translator.c:2893]: create_via_hf(): create_via_hf: id added: <;i=2>, rcv proto=210(25375) DEBUG: <core> [msg_translator.c:206]: check_via_address(): check_via_address(192.168.1.195, 192.168.1.195, 0)10(25375) DEBUG: <core> [tcp_main.c:1818]: tcp_send(): tcp_send: no open tcp connection found, opening new one10(25375) DEBUG: <core> [ip_addr.c:243]: print_ip(): tcpconn_new: new tcp connection: 192.168.1.19510(25375) DEBUG: <core> [tcp_main.c:1073]: tcpconn_new(): tcpconn_new: on port 40611, type 210(25375) DEBUG: <core> [tcp_main.c:1382]: tcpconn_add(): tcpconn_add: hashes: 3453:3998:0, 310(25375) INFO: <core> [tcp_main.c:2753]: tcpconn_1st_send(): quick connect for 0x7fe2ebd1703010(25375) DEBUG: tm [t_funcs.c:394]: t_relay_to(): SER: new transaction fwd'ed10(25375) DEBUG: <core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil)10(25375) DEBUG: <core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil)14(25379) DEBUG: <core> [tcp_main.c:3565]: handle_ser_child(): handle_ser_child: read response= 7fe2ebd17030, 6, fd 28 from 10 (25375)10(25375) DEBUG: <core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil)10(25375) DEBUG: <core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil)10(25375) DEBUG: <core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil)10(25375) DEBUG: <core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil)10(25375) DEBUG: <core> [xavp.c:448]: xavp_destroy_list(): destroying xavp list (nil)14(25379) DEBUG: <core> [io_wait.h:388]: io_watch_add(): DBG: io_watch_add(0x9eeee0, 28, 2, 0x7fe2ebd17030), fd_no=1910(25375) DEBUG: <core> [receive.c:298]: receive_msg(): receive_msg: cleaning up14(25379) DEBUG: <core> [io_wait.h:610]: io_watch_del(): DBG: io_watch_del (0x9eeee0, 28, -1, 0x0) fd_no=20 called14(25379) DEBUG: <core> [tcp_main.c:4219]: handle_tcpconn_ev(): tcp: DBG: sending to child, events 114(25379) DEBUG: <core> [tcp_main.c:3902]: send2child(): selected tcp worker 2 12(25377) for activity on [tcp:192.168.1.195:4060 <http://192.168.1.195:4060>], 0x7fe2ebd1703012(25377) DEBUG: <core> [tcp_read.c:1554]: handle_io(): received n=8 con=0x7fe2ebd17030, fd=512(25377) DEBUG: <core> [tcp_read.c:1362]: tcp_read_req(): tcp_read_req: content-length= 38812(25377) DEBUG: <core> [parser/msg_parser.c:633]: parse_msg(): SIP Reply (status):12(25377) DEBUG: <core> [parser/msg_parser.c:635]: parse_msg(): version: <SIP/2.0>12(25377) DEBUG: <core> [parser/msg_parser.c:637]: parse_msg(): status: <183>12(25377) DEBUG: <core> [parser/msg_parser.c:639]: parse_msg(): reason: <Session Progress>12(25377) DEBUG: <core> [parser/parse_via.c:1284]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK6423.c4c3d26baa62dea619271f186d6344fc.0>; state=612(25377) DEBUG: <core> [parser/parse_via.c:1284]: parse_via_param(): Found param type 236, <i> = <2>; state=1612(25377) DEBUG: <core> [parser/parse_via.c:2672]: parse_via(): end of header reached, state=512(25377) DEBUG: <core> [parser/msg_parser.c:513]: parse_headers(): parse_headers: Via found, flags=212(25377) DEBUG: <core> [parser/msg_parser.c:515]: parse_headers(): parse_headers: this is the first via12(25377) DEBUG: <core> [receive.c:154]: receive_msg(): After parse_msg...12(25377) DEBUG: tm [t_lookup.c:1072]: t_check_msg(): DEBUG: t_check_msg: msg id=1 global id=0 T start=0xffffffffffffffff12(25377) DEBUG: <core> [parser/parse_via.c:1284]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK1970975121>; state=1612(25377) DEBUG: <core> [parser/parse_via.c:2672]: parse_via(): end of header reached, state=512(25377) DEBUG: <core> [parser/msg_parser.c:513]: parse_headers(): parse_headers: Via found, flags=6212(25377) DEBUG: <core> [parser/msg_parser.c:526]: parse_headers(): parse_headers: this is the second via12(25377) DEBUG: <core> [parser/parse_addr_spec.c:176]: parse_to_param(): DEBUG: add_param: tag=165643220412(25377) DEBUG: <core> [parser/parse_addr_spec.c:898]: parse_addr_spec(): end of header reached, state=2912(25377) DEBUG: <core> [parser/msg_parser.c:190]: get_hdr_field(): DEBUG: get_hdr_field: <To> [43]; uri=[sip:linux_ua_1@192.168.1.195 <sip%3Alinux_ua_1(a)192.168.1.195>] 12(25377) DEBUG: <core> [parser/msg_parser.c:192]: get_hdr_field(): DEBUG: to body [<sip:linux_ua_1@192.168.1.195 <sip%3Alinux_ua_1(a)192.168.1.195>>]12(25377) DEBUG: <core> [parser/msg_parser.c:170]: get_hdr_field(): get_hdr_field: cseq <CSeq>: <2> <INVITE>12(25377) DEBUG: tm [t_lookup.c:949]: t_reply_matching(): DEBUG: t_reply_matching: hash 12870 label 0 branch 012(25377) DEBUG: tm [t_lookup.c:1004]: t_reply_matching(): DEBUG: t_reply_matching: reply matched (T=0x7fe2ebd13848)!12(25377) DEBUG: tm [t_hooks.c:288]: run_trans_callbacks_internal(): DBG: trans=0x7fe2ebd13848, callback type 2, id 0 entered12(25377) DEBUG: acc [acc_logic.c:644]: tmcb_func(): acc callback called for t(0x7fe2ebd13848) event type 2, reply code 18312(25377) DEBUG: tm [t_lookup.c:1141]: t_check_msg(): DEBUG: t_check_msg: msg id=1 global id=1 T end=0x7fe2ebd1384812(25377) DEBUG: tm [t_reply.c:2200]: reply_received(): DEBUG: reply_received: org. status uas=100, uac[0]=0 local=0 is_invite=1)12(25377) DEBUG: <script>: incoming reply12(25377) DEBUG: tm [t_reply.c:1294]: t_should_relay_response(): ->>>>>>>>> T_code=100, new_code=18312(25377) DEBUG: tm [t_reply.c:1812]: relay_reply(): DEBUG: relay_reply: branch=0, save=0, relay=0 icode=012(25377) DEBUG: <core> [parser/msg_parser.c:204]: get_hdr_field(): DEBUG: get_hdr_body : content_length=38812(25377) DEBUG: <core> [parser/msg_parser.c:106]: get_hdr_field(): found end of header12(25377) DEBUG: <core> [msg_translator.c:2278]: generate_res_buf_from_sip_res(): old size: 948, new size: 85312(25377) DEBUG: <core> [msg_translator.c:2296]: generate_res_buf_from_sip_res(): copied size: orig:125, new: 30, rest: 823 msg=SIP/2.0 183 Session ProgressVia: SIP/2.0/TCP 192.168.1.195:19009;branch=z9hG4bK1970975121Record-Route: <sip:192.168.1.195:4060;transport=tcp;lr>From: <sip:linux_ua_0@192.168.1.195 <sip%3Alinux_ua_0(a)192.168.1.195>>;tag=604263664To: <sip:linux_ua_1@192.168.1.195 <sip%3Alinux_ua_1(a)192.168.1.195>>;tag=1656432204Call-ID: 734015646(a)192.168.1.195 <734015646(a)192.168.1.195>CSeq: 2 INVITEContact: <sip:linux_ua_1@192.168.1.195:40611;transport=TCP>Content-Type: application/sdpUser-Agent: Linux 64 US-UA 1.0.1Require: 100relRSeq: 1Content-Length: 388v=0o=- 0 0 IN IP4 192.168.1.195s=IMS_Callc=IN IP4 192.168.1.195t=0 0m=audio 21720 RTP/AVP 99 0 8 101 b=AS:64a=curr:qos remote nonea=curr:qos local nonea=des:qos mandatory remote sendrecva=conf:qos remote sendrecva=des:qos mandatory local sendrecva=rtpmap:101 telephone-event/8000a=fmtp:101 0-15a=rtpmap:99 AMR/8000a=rtpmap:0 PCMU/8000a=rtpmap:8 PCMA/800012(25377) DEBUG: <core> [tcp_main.c:2297]: tcpconn_send_put(): tcp_send: tcp connection found (0x7fe2ebd096b0), acquiring fd12(25377) DEBUG: <core> [tcp_main.c:2307]: tcpconn_send_put(): tcp_send, c= 0x7fe2ebd096b0, n=1614(25379) DEBUG: <core> [tcp_main.c:3565]: handle_ser_child(): handle_ser_child: read response= 7fe2ebd096b0, 2, fd -1 from 12 (25377)12(25377) DEBUG: <core> [tcp_main.c:2337]: tcpconn_send_put(): tcp_send: after receive_fd: c= 0x7fe2ebd096b0 n=8 fd=812(25377) DEBUG: <core> [tcp_main.c:2516]: tcpconn_do_send(): tcp_send: sending...12(25377) DEBUG: <core> [tcp_main.c:2550]: tcpconn_do_send(): tcp_send: after real write: c= 0x7fe2ebd096b0 n=853 fd=812(25377) DEBUG: <core> [tcp_main.c:2551]: tcpconn_do_send(): tcp_send: buf=SIP/2.0 183 Session ProgressVia: SIP/2.0/TCP 192.168.1.195:19009;branch=z9hG4bK1970975121Record-Route: <sip:192.168.1.195:4060;transport=tcp;lr>From: <sip:linux_ua_0@192.168.1.195 <sip%3Alinux_ua_0(a)192.168.1.195>>;tag=604263664To: <sip:linux_ua_1@192.168.1.195 <sip%3Alinux_ua_1(a)192.168.1.195>>;tag=1656432204Call-ID: 734015646(a)192.168.1.195 <734015646(a)192.168.1.195>CSeq: 2 INVITEContact: <sip:linux_ua_1@192.168.1.195:40611;transport=TCP>Content-Type: application/sdpUser-Agent: Linux 64 US-UA 1.0.1Require: 100relRSeq: 1Content-Length: 388v=0o=- 0 0 IN IP4 192.168.1.195s=IMS_Callc=IN IP4 192.168.1.195t=0 0m=audio 21720 RTP/AVP 99 0 8 101 b=AS:64a=curr:qos remote nonea=curr:qos local nonea=des:qos mandatory remote sendrecva=conf:qos remote sendrecva=des:qos mandatory local sendrecva=rtpmap:101 telephone-event/8000a=fmtp:101 0-15a=rtpmap:99 AMR/8000a=rtpmap:0 PCMU/8000a=rtpmap:8 PCMA/800012(25377) DEBUG: tm [t_hooks.c:288]: run_trans_callbacks_internal(): DBG: trans=0x7fe2ebd13848, callback type 512, id 0 entered12(25377) DEBUG: acc [acc_logic.c:644]: tmcb_func(): acc callback called for t(0x7fe2ebd13848) event type 512, reply code 18312(25377) DEBUG: <core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil)12(25377) DEBUG: <core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil)12(25377) DEBUG: <core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil)12(25377) DEBUG: <core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil)12(25377) DEBUG: <core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil)12(25377) DEBUG: <core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil)12(25377) DEBUG: <core> [xavp.c:448]: xavp_destroy_list(): destroying xavp list (nil)12(25377) DEBUG: <core> [receive.c:298]: receive_msg(): receive_msg: cleaning up12(25377) DEBUG: <core> [io_wait.h:388]: io_watch_add(): DBG: io_watch_add(0xa33180, 5, 2, 0x7fe2ebd17030), fd_no=110(25375) DEBUG: <core> [tcp_read.c:1362]: tcp_read_req(): tcp_read_req: content-length= 39210(25375) DEBUG: <core> [parser/msg_parser.c:623]: parse_msg(): SIP Request:10(25375) DEBUG: <core> [parser/msg_parser.c:625]: parse_msg(): method: <PRACK>10(25375) DEBUG: <core> [parser/msg_parser.c:627]: parse_msg(): uri: <sip:linux_ua_1@192.168.1.195:40611;transport=TCP>10(25375) DEBUG: <core> [parser/msg_parser.c:629]: parse_msg(): version: <SIP/2.0>10(25375) DEBUG: <core> [parser/parse_via.c:1284]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK1576634775>; state=1610(25375) DEBUG: <core> [parser/parse_via.c:2672]: parse_via(): end of header reached, state=510(25375) DEBUG: <core> [parser/msg_parser.c:513]: parse_headers(): parse_headers: Via found, flags=210(25375) DEBUG: <core> [parser/msg_parser.c:515]: parse_headers(): parse_headers: this is the first via10(25375) DEBUG: <core> [receive.c:154]: receive_msg(): After parse_msg...10(25375) DEBUG: <core> [receive.c:197]: receive_msg(): preparing to run routing scripts...10(25375) DEBUG: <core> [parser/parse_addr_spec.c:176]: parse_to_param(): DEBUG: add_param: tag=165643220410(25375) DEBUG: <core> [parser/parse_addr_spec.c:898]: parse_addr_spec(): end of header reached, state=2910(25375) DEBUG: <core> [parser/msg_parser.c:190]: get_hdr_field(): DEBUG: get_hdr_field: <To> [43]; uri=[sip:linux_ua_1@192.168.1.195 <sip%3Alinux_ua_1(a)192.168.1.195>] 10(25375) DEBUG: <core> [parser/msg_parser.c:192]: get_hdr_field(): DEBUG: to body [<sip:linux_ua_1@192.168.1.195 <sip%3Alinux_ua_1(a)192.168.1.195>>]10(25375) DEBUG: <core> [parser/msg_parser.c:170]: get_hdr_field(): get_hdr_field: cseq <CSeq>: <3> <PRACK>10(25375) DEBUG: maxfwd [mf_funcs.c:85]: is_maxfwd_present(): value = 70 10(25375) DEBUG: <core> [parser/msg_parser.c:204]: get_hdr_field(): DEBUG: get_hdr_body : content_length=39210(25375) DEBUG: <core> [parser/msg_parser.c:106]: get_hdr_field(): found end of header10(25375) DEBUG: <core> [parser/parse_addr_spec.c:176]: parse_to_param(): DEBUG: add_param: tag=60426366410(25375) DEBUG: <core> [parser/parse_addr_spec.c:898]: parse_addr_spec(): end of header reached, state=2910(25375) DEBUG: sanity [mod_sanity.c:255]: w_sanity_check(): sanity checks result: 110(25375) DEBUG: siputils [checks.c:106]: has_totag(): totag found10(25375) DEBUG: rr [loose.c:90]: is_preloaded(): is_preloaded: No10(25375) DEBUG: <core> [socket_info.c:583]: grep_sock_info(): grep_sock_info - checking if host==us: 13==13 && [192.168.1.195] == [192.168.1.195]10(25375) DEBUG: <core> [socket_info.c:587]: grep_sock_info(): grep_sock_info - checking if port 4060 (advertise 0) matches port 4061110(25375) DEBUG: <core> [socket_info.c:583]: grep_sock_info(): grep_sock_info - checking if host==us: 13==13 && [192.168.1.195] == [192.168.1.195]10(25375) DEBUG: <core> [socket_info.c:587]: grep_sock_info(): grep_sock_info - checking if port 4060 (advertise 0) matches port 4061110(25375) DEBUG: <core> [socket_info.c:583]: grep_sock_info(): grep_sock_info - checking if host==us: 13==13 && [192.168.1.195] == [192.168.1.195]10(25375) DEBUG: <core> [socket_info.c:587]: grep_sock_info(): grep_sock_info - checking if port 4090 (advertise 0) matches port 4061110(25375) DEBUG: rr [loose.c:674]: after_strict(): Next hop: 'sip:192.168.1.195:4060;transport=tcp;lr' is loose router10(25375) DEBUG: rr [loose.c:724]: after_strict(): The last route URI: 'sip:192.168.1.195:4060;transport=tcp;lr'10(25375) DEBUG: tm [t_lookup.c:1373]: t_newtran(): DEBUG: t_newtran: msg id=4 , global msg id=3 , T on entrance=0xffffffffffffffff10(25375) DEBUG: tm [t_lookup.c:527]: t_lookup_request(): t_lookup_request: start searching: hash=12871, isACK=010(25375) DEBUG: tm [t_lookup.c:485]: matching_3261(): DEBUG: RFC3261 transaction matching failed10(25375) DEBUG: tm [t_lookup.c:709]: t_lookup_request(): DEBUG: t_lookup_request: no transaction found10(25375) DEBUG: tm [t_hooks.c:380]: run_reqin_callbacks_internal(): DBG: trans=0x7fe2ebd1b780, callback type 1, id 0 entered10(25375) DEBUG: <core> [md5utils.c:67]: MD5StringArray(): DEBUG: MD5 calculated: 0dd1edaf37f3874c5176befe76ed5b3e10(25375) DEBUG: <core> [msg_translator.c:2893]: create_via_hf(): create_via_hf: id added: <;i=2>, rcv proto=210(25375) DEBUG: <core> [msg_translator.c:206]: check_via_address(): check_via_address(192.168.1.195, 192.168.1.195, 0)10(25375) DEBUG: <core> [tcp_main.c:1818]: tcp_send(): tcp_send: no open tcp connection found, opening new one10(25375) DEBUG: <core> [ip_addr.c:243]: print_ip(): tcpconn_new: new tcp connection: 192.168.1.19510(25375) DEBUG: <core> [tcp_main.c:1073]: tcpconn_new(): tcpconn_new: on port 4060, type 210(25375) DEBUG: <core> [tcp_main.c:1382]: tcpconn_add(): tcpconn_add: hashes: 3360:0:0, 410(25375) INFO: <core> [tcp_main.c:2753]: tcpconn_1st_send(): quick connect for 0x7fe2ebd1e5c010(25375) DEBUG: tm [t_funcs.c:394]: t_relay_to(): SER: new transaction fwd'ed14(25379) DEBUG: <core> [ip_addr.c:243]: print_ip(): tcpconn_new: new tcp connection: 192.168.1.19510(25375) DEBUG: <core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil)14(25379) DEBUG: <core> [tcp_main.c:1073]: tcpconn_new(): tcpconn_new: on port 19785, type 210(25375) DEBUG: <core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil)10(25375) DEBUG: <core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil)10(25375) DEBUG: <core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil)14(25379) DEBUG: <core> [tcp_main.c:1382]: tcpconn_add(): tcpconn_add: hashes: 3888:3539:528, 510(25375) DEBUG: <core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil)10(25375) DEBUG: <core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil)10(25375) DEBUG: <core> [xavp.c:448]: xavp_destroy_list(): destroying xavp list (nil)10(25375) DEBUG: <core> [receive.c:298]: receive_msg(): receive_msg: cleaning up14(25379) DEBUG: <core> [io_wait.h:388]: io_watch_add(): DBG: io_watch_add(0x9eeee0, 29, 2, 0x7fe2ebd228e0), fd_no=1914(25379) DEBUG: <core> [tcp_main.c:3565]: handle_ser_child(): handle_ser_child: read response= 7fe2ebd1e5c0, 6, fd 30 from 10 (25375)14(25379) DEBUG: <core> [io_wait.h:388]: io_watch_add(): DBG: io_watch_add(0x9eeee0, 30, 2, 0x7fe2ebd1e5c0), fd_no=2014(25379) DEBUG: <core> [io_wait.h:610]: io_watch_del(): DBG: io_watch_del (0x9eeee0, 29, -1, 0x0) fd_no=21 called14(25379) DEBUG: <core> [tcp_main.c:4219]: handle_tcpconn_ev(): tcp: DBG: sending to child, events 114(25379) DEBUG: <core> [tcp_main.c:3902]: send2child(): selected tcp worker 3 13(25378) for activity on [tcp:192.168.1.195:4060 <http://192.168.1.195:4060>], 0x7fe2ebd228e013(25378) DEBUG: <core> [tcp_read.c:1554]: handle_io(): received n=8 con=0x7fe2ebd228e0, fd=513(25378) DEBUG: <core> [tcp_read.c:1362]: tcp_read_req(): tcp_read_req: content-length= 39213(25378) DEBUG: <core> [parser/msg_parser.c:623]: parse_msg(): SIP Request:13(25378) DEBUG: <core> [parser/msg_parser.c:625]: parse_msg(): method: <PRACK>13(25378) DEBUG: <core> [parser/msg_parser.c:627]: parse_msg(): uri: <sip:192.168.1.195:4060;transport=tcp;lr>13(25378) DEBUG: <core> [parser/msg_parser.c:629]: parse_msg(): version: <SIP/2.0>13(25378) DEBUG: <core> [parser/parse_via.c:1284]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK7423.0dd1edaf37f3874c5176befe76ed5b3e.0>; state=613(25378) DEBUG: <core> [parser/parse_via.c:1284]: parse_via_param(): Found param type 236, <i> = <2>; state=1613(25378) DEBUG: <core> [parser/parse_via.c:2672]: parse_via(): end of header reached, state=513(25378) DEBUG: <core> [parser/msg_parser.c:513]: parse_headers(): parse_headers: Via found, flags=213(25378) DEBUG: <core> [parser/msg_parser.c:515]: parse_headers(): parse_headers: this is the first via13(25378) DEBUG: <core> [receive.c:154]: receive_msg(): After parse_msg...13(25378) DEBUG: <core> [receive.c:197]: receive_msg(): preparing to run routing scripts...13(25378) DEBUG: <core> [parser/parse_via.c:1284]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK1576634775>; state=1613(25378) DEBUG: <core> [parser/parse_via.c:2672]: parse_via(): end of header reached, state=513(25378) DEBUG: <core> [parser/msg_parser.c:513]: parse_headers(): parse_headers: Via found, flags=10013(25378) DEBUG: <core> [parser/msg_parser.c:526]: parse_headers(): parse_headers: this is the second via13(25378) DEBUG: <core> [parser/parse_addr_spec.c:176]: parse_to_param(): DEBUG: add_param: tag=165643220413(25378) DEBUG: <core> [parser/parse_addr_spec.c:898]: parse_addr_spec(): end of header reached, state=2913(25378) DEBUG: <core> [parser/msg_parser.c:190]: get_hdr_field(): DEBUG: get_hdr_field: <To> [43]; uri=[sip:linux_ua_1@192.168.1.195 <sip%3Alinux_ua_1(a)192.168.1.195>] 13(25378) DEBUG: <core> [parser/msg_parser.c:192]: get_hdr_field(): DEBUG: to body [<sip:linux_ua_1@192.168.1.195 <sip%3Alinux_ua_1(a)192.168.1.195>>]13(25378) DEBUG: <core> [parser/msg_parser.c:170]: get_hdr_field(): get_hdr_field: cseq <CSeq>: <3> <PRACK>13(25378) DEBUG: maxfwd [mf_funcs.c:85]: is_maxfwd_present(): value = 69 13(25378) DEBUG: <core> [parser/msg_parser.c:204]: get_hdr_field(): DEBUG: get_hdr_body : content_length=39213(25378) DEBUG: <core> [parser/msg_parser.c:106]: get_hdr_field(): found end of header13(25378) DEBUG: <core> [parser/parse_addr_spec.c:176]: parse_to_param(): DEBUG: add_param: tag=60426366413(25378) DEBUG: <core> [parser/parse_addr_spec.c:898]: parse_addr_spec(): end of header reached, state=2913(25378) DEBUG: sanity [mod_sanity.c:255]: w_sanity_check(): sanity checks result: 113(25378) DEBUG: siputils [checks.c:106]: has_totag(): totag found13(25378) DEBUG: rr [loose.c:113]: find_first_route(): No Route headers found13(25378) DEBUG: rr [loose.c:929]: loose_route(): There is no Route HF13(25378) DEBUG: <core> [msg_translator.c:206]: check_via_address(): check_via_address(192.168.1.195, 192.168.1.195, 0)13(25378) DEBUG: <core> [tcp_main.c:2281]: tcpconn_send_put(): tcp_send: send from reader (25378 (13)), reusing fd13(25378) DEBUG: <core> [tcp_main.c:2516]: tcpconn_do_send(): tcp_send: sending...13(25378) DEBUG: <core> [tcp_main.c:2550]: tcpconn_do_send(): tcp_send: after real write: c= 0x7fe2ebd228e0 n=386 fd=514(25379) DEBUG: <core> [io_wait.h:610]: io_watch_del(): DBG: io_watch_del (0x9eeee0, 30, -1, 0x0) fd_no=20 called13(25378) DEBUG: <core> [tcp_main.c:2551]: tcpconn_do_send(): tcp_send: buf=SIP/2.0 404 Not hereVia: SIP/2.0/TCP 192.168.1.195:4060;branch=z9hG4bK7423.0dd1edaf37f3874c5176befe76ed5b3e.0;i=2Via: SIP/2.0/TCP 192.168.1.195:19009;branch=z9hG4bK1576634775From: <sip:linux_ua_0@192.168.1.195 <sip%3Alinux_ua_0(a)192.168.1.195>>;tag=604263664To: <sip:linux_ua_1@192.168.1.195 <sip%3Alinux_ua_1(a)192.168.1.195>>;tag=1656432204Call-ID: 734015646(a)192.168.1.195 <734015646(a)192.168.1.195>CSeq: 3 PRACKServer: kamailio (4.2.3 (x86_64/linux))Content-Length: 014(25379) DEBUG: <core> [tcp_main.c:4219]: handle_tcpconn_ev(): tcp: DBG: sending to child, events 114(25379) DEBUG: <core> [tcp_main.c:3898]: send2child(): WARNING: send2child: no free tcp receiver, connection passed to the least busy one (1)14(25379) DEBUG: <core> [tcp_main.c:3902]: send2child(): selected tcp worker 0 10(25375) for activity on [tcp:192.168.1.195:4060 <http://192.168.1.195:4060>], 0x7fe2ebd1e5c013(25378) DEBUG: <core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil)13(25378) DEBUG: <core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil)10(25375) DEBUG: <core> [tcp_read.c:1554]: handle_io(): received n=8 con=0x7fe2ebd1e5c0, fd=1013(25378) DEBUG: <core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil)13(25378) DEBUG: <core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil)13(25378) DEBUG: <core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil)13(25378) DEBUG: <core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil)10(25375) DEBUG: <core> [tcp_read.c:1362]: tcp_read_req(): tcp_read_req: content-length= 013(25378) DEBUG: <core> [xavp.c:448]: xavp_destroy_list(): destroying xavp list (nil)10(25375) DEBUG: <core> [parser/msg_parser.c:633]: parse_msg(): SIP Reply (status):13(25378) DEBUG: <core> [receive.c:298]: receive_msg(): receive_msg: cleaning up10(25375) DEBUG: <core> [parser/msg_parser.c:635]: parse_msg(): version: <SIP/2.0>10(25375) DEBUG: <core> [parser/msg_parser.c:637]: parse_msg(): status: <404>10(25375) DEBUG: <core> [parser/msg_parser.c:639]: parse_msg(): reason: <Not here>10(25375) DEBUG: <core> [parser/parse_via.c:1284]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK7423.0dd1edaf37f3874c5176befe76ed5b3e.0>; state=613(25378) DEBUG: <core> [io_wait.h:388]: io_watch_add(): DBG: io_watch_add(0xa33180, 5, 2, 0x7fe2ebd228e0), fd_no=110(25375) DEBUG: <core> [parser/parse_via.c:1284]: parse_via_param(): Found param type 236, <i> = <2>; state=1610(25375) DEBUG: <core> [parser/parse_via.c:2672]: parse_via(): end of header reached, state=510(25375) DEBUG: <core> [parser/msg_parser.c:513]: parse_headers(): parse_headers: Via found, flags=210(25375) DEBUG: <core> [parser/msg_parser.c:515]: parse_headers(): parse_headers: this is the first via10(25375) DEBUG: <core> [receive.c:154]: receive_msg(): After parse_msg...10(25375) DEBUG: tm [t_lookup.c:1072]: t_check_msg(): DEBUG: t_check_msg: msg id=5 global id=4 T start=0xffffffffffffffff10(25375) DEBUG: <core> [parser/parse_via.c:1284]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK1576634775>; state=1610(25375) DEBUG: <core> [parser/parse_via.c:2672]: parse_via(): end of header reached, state=510(25375) DEBUG: <core> [parser/msg_parser.c:513]: parse_headers(): parse_headers: Via found, flags=6210(25375) DEBUG: <core> [parser/msg_parser.c:526]: parse_headers(): parse_headers: this is the second via10(25375) DEBUG: <core> [parser/parse_addr_spec.c:176]: parse_to_param(): DEBUG: add_param: tag=165643220410(25375) DEBUG: <core> [parser/parse_addr_spec.c:898]: parse_addr_spec(): end of header reached, state=2910(25375) DEBUG: <core> [parser/msg_parser.c:190]: get_hdr_field(): DEBUG: get_hdr_field: <To> [43]; uri=[sip:linux_ua_1@192.168.1.195 <sip%3Alinux_ua_1(a)192.168.1.195>] 10(25375) DEBUG: <core> [parser/msg_parser.c:192]: get_hdr_field(): DEBUG: to body [<sip:linux_ua_1@192.168.1.195 <sip%3Alinux_ua_1(a)192.168.1.195>>]10(25375) DEBUG: <core> [parser/msg_parser.c:170]: get_hdr_field(): get_hdr_field: cseq <CSeq>: <3> <PRACK>10(25375) DEBUG: tm [t_lookup.c:949]: t_reply_matching(): DEBUG: t_reply_matching: hash 12871 label 0 branch 010(25375) DEBUG: tm [t_lookup.c:1004]: t_reply_matching(): DEBUG: t_reply_matching: reply matched (T=0x7fe2ebd1b780)!10(25375) DEBUG: tm [t_lookup.c:1141]: t_check_msg(): DEBUG: t_check_msg: msg id=5 global id=5 T end=0x7fe2ebd1b78010(25375) DEBUG: tm [t_reply.c:2200]: reply_received(): DEBUG: reply_received: org. status uas=0, uac[0]=0 local=0 is_invite=0)10(25375) DEBUG: tm [t_reply.c:1294]: t_should_relay_response(): ->>>>>>>>> T_code=0, new_code=40410(25375) DEBUG: tm [t_reply.c:1812]: relay_reply(): DEBUG: relay_reply: branch=0, save=0, relay=0 icode=010(25375) DEBUG: <core> [parser/msg_parser.c:204]: get_hdr_field(): DEBUG: get_hdr_body : content_length=010(25375) DEBUG: <core> [parser/msg_parser.c:106]: get_hdr_field(): found end of header10(25375) DEBUG: <core> [msg_translator.c:2278]: generate_res_buf_from_sip_res(): old size: 386, new size: 29110(25375) DEBUG: <core> [msg_translator.c:2296]: generate_res_buf_from_sip_res(): copied size: orig:117, new: 22, rest: 269 msg=SIP/2.0 404 Not hereVia: SIP/2.0/TCP 192.168.1.195:19009;branch=z9hG4bK1576634775From: <sip:linux_ua_0@192.168.1.195 <sip%3Alinux_ua_0(a)192.168.1.195>>;tag=604263664To: <sip:linux_ua_1@192.168.1.195 <sip%3Alinux_ua_1(a)192.168.1.195>>;tag=1656432204Call-ID: 734015646(a)192.168.1.195 <734015646(a)192.168.1.195>CSeq: 3 PRACKServer: kamailio (4.2.3 (x86_64/linux))Content-Length: 010(25375) DEBUG: <core> [mem/shm_mem.c:111]: _shm_resize(): WARNING:vqm_resize: resize(0) called10(25375) DEBUG: <core> [tcp_main.c:2281]: tcpconn_send_put(): tcp_send: send from reader (25375 (10)), reusing fd10(25375) DEBUG: <core> [tcp_main.c:2516]: tcpconn_do_send(): tcp_send: sending...10(25375) DEBUG: <core> [tcp_main.c:2550]: tcpconn_do_send(): tcp_send: after real write: c= 0x7fe2ebd096b0 n=291 fd=510(25375) DEBUG: <core> [tcp_main.c:2551]: tcpconn_do_send(): tcp_send: buf=SIP/2.0 404 Not hereVia: SIP/2.0/TCP 192.168.1.195:19009;branch=z9hG4bK1576634775From: <sip:linux_ua_0@192.168.1.195 <sip%3Alinux_ua_0(a)192.168.1.195>>;tag=604263664To: <sip:linux_ua_1@192.168.1.195 <sip%3Alinux_ua_1(a)192.168.1.195>>;tag=1656432204Call-ID: 734015646(a)192.168.1.195 <734015646(a)192.168.1.195>CSeq: 3 PRACKServer: kamailio (4.2.3 (x86_64/linux))Content-Length: 010(25375) DEBUG: tm [t_reply.c:1653]: cleanup_uac_timers(): DEBUG: cleanup_uac_timers: RETR/FR timers reset10(25375) DEBUG: <core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil)10(25375) DEBUG: <core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil)10(25375) DEBUG: <core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil)10(25375) DEBUG: <core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil)10(25375) DEBUG: <core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil)10(25375) DEBUG: <core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil)10(25375) DEBUG: <core> [xavp.c:448]: xavp_destroy_list(): destroying xavp list (nil)10(25375) DEBUG: <core> [receive.c:298]: receive_msg(): receive_msg: cleaning up10(25375) DEBUG: <core> [io_wait.h:388]: io_watch_add(): DBG: io_watch_add(0xa33180, 10, 2, 0x7fe2ebd1e5c0), fd_no=214(25379) CRITICAL: <core> [pass_fd.c:293]: receive_fd(): EOF on 1314(25379) DEBUG: <core> [tcp_main.c:3537]: handle_ser_child(): DBG: handle_ser_child: dead child 4, pid 25369 (shutting down?)14(25379) DEBUG: <core> [io_wait.h:610]: io_watch_del(): DBG: io_watch_del (0x9eeee0, 13, -1, 0x0) fd_no=19 calledroot@Kamal:/usr/local/etc/kamailio# *

2 1

Increase Simultaneous Registration
by Austin Einter 04 Jun '15

04 Jun '15

Hi All I am using Kamailio 4.0.4 (x86_64/linux). I wanted to do simultaneous registrations of large number of endpoints. Many times I see only 2048 endpoints registered and for other endpoints Kamailio did not respond for REGISTER message. I am tcp as transport. Now my questions are 1. What are the different configurations available to increase Kamailio performance 2. If I put Kamailio in a Linux 64 Bit, 2GHz, 8GB RAM machine, how much simultaneous and total registrations can be achieved. I have tuned system file FDs, tcp related configurations like ephemeral port range, and other required configurations. I hope there should be some configurations in Kamailio to achieve higher throughput , can somebody help me out. Thanks Austin

2 1

Problem with command kamcmd pkg.stats on Kamailio 4.2.5
by Dao Hai Dang 04 Jun '15

04 Jun '15

Hi, I need help with kamcmd pkg.stats on Kamailio 4.2.5. When I used this command to check kamailio process, I get an entry with no pid and total_size param. I used kamcmd ps and the process error was MI FIFO. Same thing happened when I added snmpstats module, I get process SNMP AgentX with no pid and total_size param. This didn't happen when I use kamailio 4.1.x . Below are logs : [root@localhost ~]# kamcmd pkg.stats { entry: 0 pid: 1532 rank: 0 used: 376224 free: 3718760 real_used: 475544 total_size: 4194304 total_frags: 4 } { entry: 1 pid: 1534 rank: 1 used: 384496 free: 3709368 real_used: 484936 total_size: 4194304 total_frags: 22 } { entry: 2 pid: 1535 rank: -1 used: 384552 free: 3710096 real_used: 484208 total_size: 4194304 total_frags: 8 } { entry: 3 pid: 1536 rank: -1 used: 384552 free: 3710096 real_used: 484208 total_size: 4194304 total_frags: 8 } { entry: 4 pid: 0 rank: 0 used: 393744 free: 3701072 real_used: 493232 total_size: 0 total_frags: 4 } { entry: 5 pid: 1543 rank: -2 used: 383592 free: 3710552 real_used: 483752 total_size: 4194304 total_frags: 8 } { entry: 6 pid: 1544 rank: -4 used: 454392 free: 3640424 real_used: 553880 total_size: 4194304 total_frags: 4 } [root@localhost ~]# kamcmd ps 1532 attendant 1534 udp receiver child=0 sock=10.84.11.116:5060 1535 slow timer 1536 timer 1537 MI FIFO 1543 ctl handler 1544 tcp main process Thanks & Regards, Dao Hai Dang -------------------------------------------------------------------------------- Solutions & Software Development Center | VNPT Technology A member of VietNam Posts & Telecomunications Group Addr : 124 Hoang Quoc Viet, Ha Noi Mobile : (+84 )912 363 579 - Skype : cnoob89 Office : (+84) 438 36 20 94 - ext 1222

2 6

Strange core.tcp_list / tls.list output
by Mikko Lehto 04 Jun '15

04 Jun '15

Hi, I noticed thath command core.tcp_list in kamcmd gives output that does not make sense to me: --- kamcmd> core.tcp_list { id: 1 type: TLS state: CONN_OK timeout: 3599 ref_count: 1 src_ip: 192.168.47.132 src_port: 5061 dst_ip: 10.10.235.9 dst_port: 54769 } { id: 2 type: TLS state: CONN_OK timeout: 3599 ref_count: 1 src_ip: 192.168.47.132 src_port: 32854 dst_ip: 10.10.235.9 dst_port: 5041 } --- In my scenario I am connecting via TLS to host 192.168.47.132:5061. And host 192.168.47.132 is connecting to my proxy host 10.10.235.9:5041. pcap verifies this. Also tls.list gives similar output. Values regarding incoming connection (id=2) makes total sense. It seems that values regarding outgoing connection (id=1) have dst_* values swapped with src_* values. To debug, I placed this logging to tcp_main.c: --- $ git diff tcp_main.c diff --git a/tcp_main.c b/tcp_main.c index 5830c8e..3717cf6 100644 --- a/tcp_main.c +++ b/tcp_main.c @@ -1207,6 +1207,7 @@ again: } from=&my_name; /* update from with the real "from" address */ su2ip_addr(&ip, &my_name); + LM_WARN("after getsockname() my_name=%s server=%s ip=%s\n", su2a(&my_name, sizeof(my_name)), su2a(server, sizeof(*server)), ip_addr2a(&ip)); find_socket: #ifdef USE_TLS if (unlikely(type==PROTO_TLS)) @@ -1223,6 +1224,7 @@ find_socket: else *res_si=sendipv6_tcp; } *res_local_addr=*from; + LM_WARN("before return my_name=%s server=%s ip=%s\n", su2a(&my_name, sizeof(my_name)), su2a(server, sizeof(*server)), ip_addr2a(&ip)); return s; error: if (s!=-1) tcp_safe_close(s); --- This gives following output: WARNING: <core> [tcp_main.c:1210]: tcp_do_connect(): after getsockname() my_name=192.168.47.132:5061 server=192.168.47.132:5061 ip=10.10.235.9 WARNING: <core> [tcp_main.c:1227]: tcp_do_connect(): before return my_name=192.168.47.132:5061 server=192.168.47.132:5061 ip=10.10.235.9 Are tcp endpoint values really wrong way around or did I undertand something wrong about their meaning? I am running Kamailio 4.2.5 (x86_64/linux) 61d84c-dirty from git. -- Mikko Lehto

2 3

Kamailio Contact header read-only
by Ali Taher 04 Jun '15

04 Jun '15

Hello, I'm trying to change contact header in SIP response message by stripping first characters (for testing only) as below : $ct = $(ct{s.strip,25}); But I got below error saying that $ct is read-only: 0(15410) : <core> [cfg.y:3419]: yyerror_at(): parse error in config file /usr/local/etc/kamailio/kamailio.cfg, line 575, column 5-7: read only pvar in assignment left side ERROR: bad config file (1 errors) The question is how can I change contact header before it's sending of Kamailio? Thanks Ali

2 7

SIP Auth Realm - From domain or Request domain ?
by jay binks 04 Jun '15

04 Jun '15

I have a questions in regards to SIP Auth, and specifically how Asterisk 13 with PJSIP appears to send Invites. It seems that the typical Kamailio config sends the SIP auth challenge with the from domain as the auth realm. however in the case of the Asterisk 13 ( PJSIP ) invite, the from domain is an RFC1918 IP address and I would have to use the domain from the request. What im wanting to know is what the consensus is on where the auth realm comes from. does everyone 100% agree that you send auth using the SIP From header, or is this something that some do Request domain ? What im considering doing is to use the from domain, but if from domain = RFC1918 then use request domain. Im just after everyone's opinion on how to best handle this invite, from a auth_challenge perspective. ( not so much if the Asterisk 13 PJSIP module is doing the right or wrong thing ) INVITE sip:555111222333@sip.mytestdomain.com:5060 SIP/2.0 Via: SIP/2.0/UDP 180.111.222.333:5060;rport;branch=z9hG4bKPjafb111a9-aaaf-4c9e-b456-748514855a06 From: <sip:555111222333@172.18.90.1 >;tag=88317259-052b-4997-bd2e-9c8836e27b47 To: <sip:555111222333@sip.netsip.net.au> Contact: <sip:9d43c8df-6378-4266-89c1-0a0bb0e1d0d1@180.111.222.333:5060> Call-ID: b7da52e2-dfd1-434e-a2c2-b28e1683ce0e -- Sincerely Jay

2 1

Fwd: Kamailio start failed
by Gopalakrishnan N 03 Jun '15

03 Jun '15

Hi, I have added the ASTERISK integration in kamailio.cfg, after adding those, am not able to start kamailio service, its getting failed, attached is the script. Any help would be appreciated. Thank you with regards, Gopalkrishnan N. Mob: +91 99404 91346 VoIP call - sip:saigop@gtalk2voip.com

2 4

Need help to configure rtpporyx
by Mir Jee 03 Jun '15

03 Jun '15

Hi! Please help me to configure rtpproxy on centos + kamailio.

2 1

lookup() to fork execution of routing script?
by Andrey Utkin 03 Jun '15

03 Jun '15

Hi! Currently we have the following logic in our Kamailio routing script. On incoming INVITE, we lookup() the location of called party, then we analyse the updated Request-URI ($ru) regarding callee contact protocol: is it websocket-based or not, to distinguish web-based useragents from classic SIP agents and provide RTP profiles interconnection with rtpengine (RTP/SAVPF for web-based, RTP/AVPF for the rest). After that, we relay the mangled INVITE to callee location(s) with t_relay(). The issue arises when callee has both websocket-based and classic useragents registered simultaneously. According to lookup() manual, it replaces Req-URI with just one contact, and somehow also attach metainformation about additional locations, so that t_relay() forks the call. lookup() does not provide the possibility to fork the execution of routing script, so that we could execute our routing logic described above. But I would love this to be possible, because the only alternative way for calling to multiple locations seems to be the serial forking described in TM module manual. But we don't need serial calling contact-by-contact, waiting for call failures, we need parallel calling to all available user locations. So we need an advice how to go. Is there a way to implement what we need at scripting level, or should this feature be implemented in Kamailio code (or is it already there?). Thanks in advance for any help. -- Andrey Utkin

2 2

Kamailio LCR Multiple choices
by Ali Taher 03 Jun '15

03 Jun '15

Hello, I'm using LCR module to send multiple choices. Everything works fine so far , yet I have a problem that last gateway comes first, then gateways are ordered correctly. Below is correct sorting of gateways: First gateway : 192.168.26.4 Second gateway: 192.168.26.1 Third gateway : 192.168.26.6 Below is Invite response I'm getting, as you can see 192.168.26.6 (last gateway) is included as the first gateway , then 192.168.26.4 (first gateway) comes next. Via: SIP/2.0/UDP 192.168.26.3:37066;branch=z9hG4bK-d8754z-885c37410729cc3b-1---d8754z-;rport= 37066;received=192.168.26.3 To: "9612"<sip:9612@192.168.110.181>;tag=b27e1a1d33761e85846fc98f5f3a7e58.8d8f From: "5000"<sip:5000@192.168.110.181>;tag=aa37be29 CSeq: 1 INVITE Call-ID: NTY0YjVmYzZiNzc3ZDA3ZDA3MmM0OGM1ZDBhZGZhNTM. Contact: <sip:9612@192.168.26.6>, <sip:9612@192.168.26.4>, <sip:9612@192.168.26.1>, <sip:9612@192.168.26.6> Below is routing block I'm using : if (is_method("INVITE")) { if (!load_gws(1, $rU, $fu)) { sl_send_reply("502", "Unable to load Gateways"); exit; } else while(next_gw()) { append_branch(); } sl_send_reply("300","Multiple Choices"); exit; } Appreciate your help. Regards, Ali

2 7

delay on "location" table update
by Al S 03 Jun '15

03 Jun '15

Hi, I was wondering if it's normal for "location" table to be updated almost 10 sec after receiving REGISTER. Thanks,Al

2 1

Potential CNXCC bug
by Jay Patel 02 Jun '15

02 Jun '15

I am trying to use cnxcc for credit control . It seems like dialog and cnxcc modules are getting out of sync. For some reason , I see cnxcc.active_clients gets stuck and they never clear up. Interestingly only calls that gets failure 5xx and 4xx from PSTN gateway gets stuck, all successful calls are cleared . I have made sure , I have setflag(DLG_FLAG) 1st line in my routing logic. If you need my routing script, I can share with you . Am I missing anything obvious? As you can see , "dlg.list" is empty, ( no calls in progress in system.) kamcmd> dlg.list kamcmd> But , two user are stuck ( 1 with 6 calls in progress and another with 2 calls in progress) kamcmd> cnxcc.active_clients client_id:917044056840,number_of_calls:6,concurrent_calls:0,type:1,max_amount:0.000000,consumed_amount:0.000000; client_id:971554578191,number_of_calls:2,concurrent_calls:0,type:1,max_amount:0.000000,consumed_amount:0.000000; Here are the call dumps for both users. kamcmd> cnxcc.check_client s:971554578191 id:0,confirmed:no,local_consumed_amount:0.588000,global_consumed_amount:0.000000,local_max_amount:7.690000,global_max_amount:0.00000 id:1,confirmed:no,local_consumed_amount:0.588000,global_consumed_amount:0.000000,local_max_amount:7.690000,global_max_amount:0.00000 kamcmd> kamcmd> kamcmd> cnxcc.check_client s:917044056840 id:0,confirmed:no,local_consumed_amount:0.588000,global_consumed_amount:0.000000,local_max_amount:9.990000,global_max_amount:0.00000 id:1,confirmed:no,local_consumed_amount:14.100000,global_consumed_amount:0.000000,local_max_amount:9.990000,global_max_amount:0.0000 id:2,confirmed:no,local_consumed_amount:14.100000,global_consumed_amount:0.000000,local_max_amount:9.990000,global_max_amount:0.0000 id:3,confirmed:no,local_consumed_amount:14.100000,global_consumed_amount:0.000000,local_max_amount:9.990000,global_max_amount:0.0000 id:4,confirmed:no,local_consumed_amount:14.100000,global_consumed_amount:0.000000,local_max_amount:9.990000,global_max_amount:0.0000 id:5,confirmed:no,local_consumed_amount:0.588000,global_consumed_amount:0.000000,local_max_amount:9.990000,global_max_amount:0.00000 kamcmd>

1 0

Kamailio LCR rule matching
by Ali Taher 02 Jun '15

02 Jun '15

Hi, I'm using LCR module in Kamailio , where matching of the rule (From-URI in LCR-rule table) is currently based on user part of sip address in From field (highlighted below in blue). While we need to change the identification to be on the otg value sent in the sip address in From field (highlighted below in yellow). INVITE sip:86532917453592@172.16.5.108:5060 <http://sip:86532917453592@172.16.5.108:5060> SIP/2.0 Via: SIP/2.0/UDP 172.16.5.112:5060;branch=z9hG4bK1sansay9906915rdb2243 Via: SIP/2.0/UDP 216.53.4.5:5060;branch=z9hG4bK_1852370774_4741_1 Record-Route: <sip:sansay9906915rdb2243@172.16.5.112:5060;lr;transport=udp> To: <sip:86532917453592@69.41.186.186:5060 <http://sip:86532917453592@69.41.186.186:5060> > From: <sip: <http://sip:+249964642906@216.53.4.5:5060> +249964642906@216.53.4.5:5060;otg=024050>;tag=1852370774_C Call-ID: sbcsipuac.2_169.132.137.51_b55sb12_1_1_2015052909455960_1852370774_487698 CSeq: 1 INVITE Contact: <sip:+249964642906@216.53.4.5:5060 <http://sip:+249964642906@216.53.4.5:5060> > P-Asserted-Identity: <sip:+249964642906@216.53.4.5:5060 <http://sip:+249964642906@216.53.4.5:5060> > Privacy: none User-Agent: VCS 5.9.2.42-01 Allow: INVITE, ACK, CANCEL, BYE Max-Forwards: 69 Content-Length: 0 How can we achieve this ? Any help will be appreciated. Regards, Ali

3 2

RTPengine+Kamailio, 200 OK without DTLS fingerprint
by Vasiliy Ganchev 02 Jun '15

02 Jun '15

Hello list! Have some difficulties with RTPengine: My test scheme is: UA(WS) -> Kamailio (WS proxy) -> Kamailio (SIP REGISTRAR, proxy) -> ASTERISK (media server) -> UA (SIP) Kamailio (WS) use RTPengine. Kamailio (WS proxy) - 4.2.3 Kamailio (SIP REGISTRAR, proxy) - 4.1.4 RTPengine - 3.3.0.0+0~mr3.8.0.0 I make a test call and have troubles in negotiation between UA(WS) -> Kamailio (WS proxy): UA(WS) -> INVITE -> Kamailio WS ...... rtpengine_manage("trust-address replace-origin replace-session-connection ICE=force"); ...... this INVITE consists in SDP section a=fingerprint:sha-256...... When Kamailio (WS) receives 200 OK, it is also handled by RTPengine ....... rtpengine_manage("trust-address replace-origin replace-session-connection ICE=force"); ....... but UA (WS) receives 200OK without fingerprint, and log an error: Failed to set remote answer sdp: Called with SDP without DTLS fingerprint. Currently spend a lot of time reading Kamailio/RTPengine documentation/mail-list - but without success If someone have some hints, I would appreciate any help. -- View this message in context: http://sip-router.1086192.n5.nabble.com/RTPengine-Kamailio-200-OK-without-D… Sent from the Users mailing list archive at Nabble.com.

3 8

RFC 6140
by Al S 02 Jun '15

02 Jun '15

Hi, I was wondering if Kamailio support RFC 6140 to register Addresses of Record (AORs) in bulk map to a unique set of contacts. REGISTER sip:kamailio.example.com SIP/2.0 Via: SIP/2.0/UDP 198.51.100.3:5060;branch=z9hG4bKnashds7 Max-Forwards: 70 To: <sip:pbx@kamailio.example.com> From: <sip:pbx@kamailio.example.com>;tag=a23589 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Proxy-Require: gin Require: gin Supported: path Contact: <sip:198.51.100.3:5060;bnc> Expires: 7200 Content-Length: 0 Thanks,Al

2 3

next via branch value
by Juha Heinanen 01 Jun '15

01 Jun '15

when kamailio forwards invite request, it adds to it a new via header. for example, incoming invite: SIP/2.0/TCP 192.168.43.192:48089;branch=z9hG4bK4e1ab219cbde6190;rport outgoing invite: SIP/2.0/TCP 192.98.102.10;branch=z9hG4bK27b9.597e97c43da7ddd6be8520b662d616b9.0;i=5 SIP/2.0/TCP 192.168.43.192:48089;received=192.98.102.10;branch=z9hG4bK4e1ab219cbde6190;rport=49582 is it somehow possible to find out in the config script, what will the branch value of the new via header be? if that value would be known, it could be assigned to rtpengine extra_id_pv pseudo variable before making the offer and could then be used in rtpengine_delete to delete the right branch. if the new via branch value cannot be known, any suggestions on how to uniquely identify the outgoing branched of the invite? -- juha

4 14

Request of advice about TAS for IMS
by dfretes＠ing.una.py 01 Jun '15

01 Jun '15

I am trying to setup a really simple (I hope so) IMS platform, with some basic services (like voicemail, IVR, videoconference), but I'm kind of stuck. I have installed Kamailio IMS on debian and a OpenIMS VM also. But my little problem begins when I try to configure a application server (in this case, a TAS). I have tried with Elastix 3.0 (kamailio+asterisk), asterisk alone, and read some about Restcomm. For Elastix and asterisk, I get stuck trying to setup the trigger point. For Restcomm, I only find documentation for integration with Clearwater IMS. So, I need your help. Somebody has something like that working? What TAS (or components for a TAS) do you recommend? Tutorials, examples, manuals that you know can help me? Thanks for reading, and many many thanks for any advice. David

2 1

Select a network
by Nelson Migliaro 01 Jun '15

01 Jun '15

Hello everybody, I need to apply a specific configuration to softphones registering from a specific network range. Is there something like:

2 2

Invalid SDP line (no '=' delimiter) error !
by Badri Ranganathan 01 Jun '15

01 Jun '15

Hi all, I am answering a SIP call made to my softphone. The softphone rings and also sends a 200 OK correctly. But the other end that made the call is seeing a failure in the SDP of the 200 OK packet. This error is seen in SDP header => Invalid SDP line (no '=' delimiter) error w.r.t w_frame4_public_ip.pcap It looks like the failure as seen in wireshark is because line "audio 5000 RTP/AVP 8 101" should really be "m= audio 5000 RTP/AVP 8 101" so it doesn't see the '=' delimiter. But if you look at w_frame52_local_ip.pcap, the packets sent from the local IP has the contents correct. It is only after passing the public IP and at the network premises, that this failure is reported by the Session Border controller. I am not able to understand why a correctly formed packet sent out is seen "corrupted" at the network end. Any ideas really appreciated. Thanks, Badri.

2 1

Re: [SR-Users] Regarding presence conference
by Daniel-Constantin Mierla 01 Jun '15

01 Jun '15

Hello, the conference mixer is supposed to send PUBLISH requests with information about who is in the conference room, who is speaking at that moment and so. That is not the job of the presence_conference module. Eventually, that could be a pua_conference module that has to be implemented. The presence_conference module was implemented as part of GSoC and the PUA was supposed to be inside SEMS, but the other project failed. If you want to get it all working, you have to implement the PUA either in your version of rtpproxy or part of kamailio as well. When all in kamailio, you can see the pairs of modules such as presence_dialoginfo and pua_dialoginfo. You already have presence_confgerece. Cheers, Daniel On 28/05/15 14:28, Surendra Pullaiah wrote: > > Hello Daniel, > > > > I am implementing conference bridge using kamalio and > RTP porxy without media mixing. Since for now we are ok with this. > My question is as per the flow of RFC 4579, UA may send SUBSCRIBE to > the conference URI with event as conference. In kamalio modules > presence_conference where they mentioned such way that it will support > the same what I am looking for. But I simulated using sipP by sending > subscriber with conference event. I am not seeing any notify XML which > will have the conference users list. One more doubt where it will pick > the conference users, since I am not seeing any specific data base > table for the same. > > > > Can you please clarify what exactly for > presence_conference module. > > > > Note: I have loaded three modules presence, presence_xml, > presence_conference, in route config I am calling handle_subscribe > when SUBCRIBE method receives. > > > > Regards > > Surendra > > India: +91-8124625001 > > > > > > _______________________________________________ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > sr-users(a)lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015 Berlin, Germany - http://www.kamailioworld.com

1 0

Forward register to multiple Asterisk
by Nelson Migliaro 01 Jun '15

01 Jun '15

Hello, I am trying to forward the register to multiple Asterisk using Kamailio. The basic Idea is: Softphone A---->Kamailio-----> Asterisk 1 ------> Asterisk 2. I follow Asipto howto http://lylix.net/kamailio, but the problem I see in my case, is that registration IP in Asterisk is Kamailio´s IP. This causes calls going from kamailio to asterisk and then back to kamailio. In my scenario, I need that softphone A IP appeard in Asterisk realtime contact IP. The call path would be: Softphone B -> kamailio -> Asterisk 1 or Asterisk 2 (depending on dispatcher) -> Softphone A Following Asipto how to the call goes Softphone A -> kamailio -> asterisk -> kamailio Softphone B Hope I explain myself clearly. Thank you in advance.

2 1

Kamailio , RTPProxy and NAT
by Mir Jee 01 Jun '15

01 Jun '15

HI! I need help to configure RTPProxy. I have working Kamailio on Centos 6.5, On LAN everything is working fine. Now I want my other users to connect using 3G or any other network. Please help me with that. Statis Public IP (DSL Modem) ----- Proxy Box with 2 Lan cards --- 192.168.2.0 and 192.168.0.0 (Lan Side)

2 1

Kamailio 300 Multiple choices
by Ali Taher 29 May '15

29 May '15

Hello, We need to integrate Kamailio with an exchange switch in order to have routing decision. Kamailio must send to the switch the list of available gateways in the contact tag of SIP response as shown in the below example: SIP/2.0 300 Multiple choices Via: SIP/2.0/UDP 172.16.5.112:5060;branch=z9hG4bK1sansay9906915rdb2243 Via: SIP/2.0/UDP 216.53.4.5:5060;branch=z9hG4bK_1852370774_4741_1 To: <sip:86532917453592@69.41.186.186:5060 <http://sip:86532917453592@69.41.186.186:5060> > From: <sip:+249964642906@216.53.4.5:5060;otg=024050>;tag=1852370774_C Call-ID: sbcsipuac.2_169.132.137.51_b55sb12_1_1_2015052909455960_1852370774_487698 CSeq: 1 INVITE Contact: <sip:2917453592@036310>, <sip:2917453592@016500>, <sip:138295#2917453592@044610>, <sip:2917453592@020100> Server: Invoice SIP-server Content-Length: 0 Is this can be done through drouting module , or we need to use another module ? Your help is highly appreciated. Regards, Ali

2 7

"Multiple Phone Numbers" registration
by Al S 29 May '15

29 May '15

Hi, Does Kamilio have a predefined module to support "Multiple Phone Numbers" registration with a single Registration?I am trying to register multiple numbers on behalf of IP-PBXs. Thanks,Al

2 3

hash table not loading
by Olli Attila 29 May '15

29 May '15

Hello, I am trying to load a test hash table on kamailio startup but I keep getting the following error with kamctl after i restart Kamailio and try to list all the tables in memory: kamcmd> htable.listTables error: 500 - No htables I have the following configured in kamailio.cfg: # ---- loading the htable module loadmodule "htable.so" # ----- htable params ----- modparam("htable", "htable", "abc=>size=8;autoexpire=0;dbtable=htable;") modparam("htable", "db_url", DBURL) modparam("htable", "fetch_rows", 1000) The DBURL is pointed to the kamailio database on the same machine. #!ifndef DBURL #!define DBURL "mysql://kamailio:kamailiorw@localhost/kamailio" #!endif I have also added the following values for testing purposes to the kamailio.htable: id key_name key_type value_type key_value expires ------ ---------- -------- ---------- --------- --------- 1 test 0 0 12345 0 Is there anything else that i might be missing here? Im running kamailio v.4.2.4. Cheers, -- Olli

3 8

Kamailio V4.2.5 append prefix to Request Uri problem.
by Yasin CANER 29 May '15

29 May '15

Hello; i try to append prefix to $rU like below in Kamailio V4.2.5 . i get error even if i set string value. it works only when i append like that $rU="3002"+$rU; --------- 1 test------------ $var(prefix)=$avp(s:69); $rU=$var(prefix)+$rU; -FAILED ---------2 test ------------ $rU=$avp(s:69)+$rU; -FAILED ------- 3 test ------------ $rU=$avp(i:69)+$rU; -FAILED -------ERROR--------- May 29 12:06:57 group1-imslab11 /usr/local/sbin/kamailio[26196]: ERROR: pv [pv_core.c:2115]: pv_set_ruri_user(): str value required to set R-URI user May 29 12:06:57 group1-imslab11 /usr/local/sbin/kamailio[26196]: ERROR: <core> [lvalue.c:363]: lval_pvar_assign(): setting pvar failed May 29 12:06:57 group1-imslab11 /usr/local/sbin/kamailio[26196]: ERROR: <core> [lvalue.c:416]: lval_assign(): assignment failed at pos: (790,7-790,22) it work on Version 4.1.7 like below correctly; $rU=$avp(i:69)+$rU; Thanks Yasin

3 3

Kamailio users creation mechanism
by Alexandru Covalschi 29 May '15

29 May '15

Hello! My goal is to create a mechanism for dynamic creation/deletion of SIP users on Kamailio. First question: is it possible to create users not via kamctl command, but directly inserting new entries to this tables? And the second one: if it is possible, which hash alghorythm Kamailio uses when creating a new user on subscriber table? Becase I see 2 fields with hashes. Thank you -- Alexandru Covalschi VoIP engineer and system administrator phone: +37367398493 <http://abs-telecom.com/>

2 1

Elastix MT (3.0) issue with NAT (ACK is not received for 200 OK)
by Mainul Haque 28 May '15

28 May '15

Hello. I think I understand the problem, but I do not know how to fix it. I have done the following when the problem accord: -Download Elastix MT 64bit (downloaded from - http://www.elastix.com/en/downloads/) -Install it in VMware ESXi 5.1. Elastix works fine within the LAN -Then I pushed the VM to EC2 by exporting VMware OVF -I noticed that I could not registered my softphone (eyebeam 1.5) -After doing research online, I had to modify /etc/kamailio/kamailio-mhomed-elastix.cfg to know about the new IP of EC2 instance. See below of what I had to change: Old settings: [root@new-host-2 endpoint_configurator]# grep 192 /etc/kamailio/kamailio-mhomed-elastix.cfg if (is_in_subnet($var(target_remote_ip), "192.168.1.0/24")) { $var(rtpproxy_if) = "192.168.1.62"; $var(rtpproxy_if) = "192.168.1.6"; To New Settings: [root@new-host-2 ~]# grep 172 /etc/kamailio/kamailio-mhomed-elastix.cfg if (is_in_subnet($var(target_remote_ip), "172.31.48.0/18")) { $var(rtpproxy_if) = "172.31.55.101"; $var(rtpproxy_if) = "172.31.55.101"; -Now I can register my eyebeam softphone. -When ever I dial anything, the connection would *drop after 10 to 30 seconds.* -When I enable SIP debug, I get the following: ############################################################# [May 28 16:07:58] VERBOSE[2688] chan_sip.c: <--- SIP read from UDP:127.0.0.1:5060 ---> INVITE sip:*65@voiptosave.com SIP/2.0 Record-Route: <sip:127.0.0.1;r2=on;lr=on;ftag=f133137e;vsf=BhoZSgsAAW82GQYZBBscEhcTS00MAi0xMjcuMC4wLjE6NTA4MA--;vst=HxoZShAcA2o2GQYZBBscEhcTS00MAi0xMjcuMC4wLjE6NTA4MA--;nat=yes> Record-Route: <sip:192.168.1.62;r2=on;lr=on;ftag=f133137e;vsf=BhoZSgsAAW82GQYZBBscEhcTS00MAi0xMjcuMC4wLjE6NTA4MA--;vst=HxoZShAcA2o2GQYZBBscEhcTS00MAi0xMjcuMC4wLjE6NTA4MA--;nat=yes> Via: SIP/2.0/UDP 127.0.0.1;branch=z9hG4bK0499.3cc1dc7f932835a200ec1f8feafd0895.0 Via: SIP/2.0/UDP 192.168.1.6:29470 ;branch=z9hG4bK-d87543-182127345f1d7b4f-1--d87543-;rport=29470 Max-Forwards: 69 Contact: <sip:110@192.168.1.6:29470> To: "*65"<sip:*65_voiptosave.com@127.0.0.1:5080> From: "Manny"<sip:110_voiptosave.com@127.0.0.1:5080>;tag=f133137e Call-ID: Mjk2YjBjZjA2NDYzOTUxZDVmOGZjNTgwYzVmMjg3YjA. CSeq: 2 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO Content-Type: application/sdp User-Agent: eyeBeam release 1011w stamp 42237 Content-Length: 457 v=0 o=- 2 2 IN IP4 192.168.1.62 s=CounterPath eyeBeam 1.5 c=IN IP4 192.168.1.62 t=0 0 m=audio 18598 RTP/AVP 100 106 6 0 105 8 18 3 5 101 a=alt:1 1 : KjAnzMl+ lOdYVIyR 192.168.1.6 15880 a=fmtp:18 annexb=yes a=fmtp:101 0-15 a=rtpmap:100 SPEEX/16000 a=rtpmap:106 SPEEX-FEC/16000 a=rtpmap:105 SPEEX-FEC/8000 a=rtpmap:18 G729/8000 a=rtpmap:101 telephone-event/8000 a=sendrecv a=x-rtp-session-id:60C3A67CD0E643D8A6945053F94B1D3E a=nortpproxy:yes <-------------> [May 28 16:07:58] VERBOSE[2688] chan_sip.c: --- (15 headers 17 lines) --- [May 28 16:07:58] VERBOSE[2688] chan_sip.c: Sending to 127.0.0.1:5060 (NAT) [May 28 16:07:58] VERBOSE[2688][C-00000021] chan_sip.c: Sending to 127.0.0.1:5060 (NAT) [May 28 16:07:58] VERBOSE[2688][C-00000021] chan_sip.c: Using INVITE request as basis request - Mjk2YjBjZjA2NDYzOTUxZDVmOGZjNTgwYzVmMjg3YjA. [May 28 16:07:58] VERBOSE[2688][C-00000021] chan_sip.c: Found peer ' 110_voiptosave.com' for '110_voiptosave.com' from 127.0.0.1:5060 [May 28 16:07:58] VERBOSE[2688][C-00000021] netsock2.c: == Using SIP RTP TOS bits 184 [May 28 16:07:58] VERBOSE[2688][C-00000021] netsock2.c: == Using SIP RTP CoS mark 5 [May 28 16:07:58] VERBOSE[2688][C-00000021] chan_sip.c: Found RTP audio format 100 [May 28 16:07:58] VERBOSE[2688][C-00000021] chan_sip.c: Found RTP audio format 106 [May 28 16:07:58] VERBOSE[2688][C-00000021] chan_sip.c: Found RTP audio format 6 [May 28 16:07:58] VERBOSE[2688][C-00000021] chan_sip.c: Found RTP audio format 0 [May 28 16:07:58] VERBOSE[2688][C-00000021] chan_sip.c: Found RTP audio format 105 [May 28 16:07:58] VERBOSE[2688][C-00000021] chan_sip.c: Found RTP audio format 8 [May 28 16:07:58] VERBOSE[2688][C-00000021] chan_sip.c: Found RTP audio format 18 [May 28 16:07:58] VERBOSE[2688][C-00000021] chan_sip.c: Found RTP audio format 3 [May 28 16:07:58] VERBOSE[2688][C-00000021] chan_sip.c: Found RTP audio format 5 [May 28 16:07:58] VERBOSE[2688][C-00000021] chan_sip.c: Found RTP audio format 101 [May 28 16:07:58] VERBOSE[2688][C-00000021] chan_sip.c: Found audio description format SPEEX for ID 100 [May 28 16:07:58] VERBOSE[2688][C-00000021] chan_sip.c: Found unknown media description format SPEEX-FEC for ID 106 [May 28 16:07:58] VERBOSE[2688][C-00000021] chan_sip.c: Found unknown media description format SPEEX-FEC for ID 105 [May 28 16:07:58] VERBOSE[2688][C-00000021] chan_sip.c: Found audio description format G729 for ID 18 [May 28 16:07:58] VERBOSE[2688][C-00000021] chan_sip.c: Found audio description format telephone-event for ID 101 [May 28 16:07:58] VERBOSE[2688][C-00000021] chan_sip.c: Capabilities: us - (gsm|ulaw|alaw), peer - audio=(gsm|ulaw|alaw|adpcm|g729|speex16)/video=(nothing)/text=(nothing), combined - (gsm|ulaw|alaw) [May 28 16:07:58] VERBOSE[2688][C-00000021] chan_sip.c: Non-codec capabilities (dtmf): us - 0x1 (telephone-event|), peer - 0x1 (telephone-event|), combined - 0x1 (telephone-event|) [May 28 16:07:58] VERBOSE[2688][C-00000021] chan_sip.c: Peer audio RTP is at port 192.168.1.62:18598 [May 28 16:07:58] VERBOSE[2688][C-00000021] chan_sip.c: Looking for *65 in voiptosave.com-from-internal (domain voiptosave.com) [May 28 16:07:58] VERBOSE[2688][C-00000021] chan_sip.c: list_route: hop: <sip:127.0.0.1;r2=on;lr=on;ftag=f133137e;vsf=BhoZSgsAAW82GQYZBBscEhcTS00MAi0xMjcuMC4wLjE6NTA4MA--;vst=HxoZShAcA2o2GQYZBBscEhcTS00MAi0xMjcuMC4wLjE6NTA4MA--;nat=yes> [May 28 16:07:58] VERBOSE[2688][C-00000021] chan_sip.c: list_route: hop: <sip:192.168.1.62;r2=on;lr=on;ftag=f133137e;vsf=BhoZSgsAAW82GQYZBBscEhcTS00MAi0xMjcuMC4wLjE6NTA4MA--;vst=HxoZShAcA2o2GQYZBBscEhcTS00MAi0xMjcuMC4wLjE6NTA4MA--;nat=yes> [May 28 16:07:58] VERBOSE[2688][C-00000021] chan_sip.c: <--- Transmitting (NAT) to 127.0.0.1:5060 ---> SIP/2.0 100 Trying Via: SIP/2.0/UDP 127.0.0.1;branch=z9hG4bK0499.3cc1dc7f932835a200ec1f8feafd0895.0;received=127.0.0.1;rport=5060 Via: SIP/2.0/UDP 192.168.1.6:29470 ;branch=z9hG4bK-d87543-182127345f1d7b4f-1--d87543-;rport=29470 Record-Route: <sip:127.0.0.1;r2=on;lr=on;ftag=f133137e;vsf=BhoZSgsAAW82GQYZBBscEhcTS00MAi0xMjcuMC4wLjE6NTA4MA--;vst=HxoZShAcA2o2GQYZBBscEhcTS00MAi0xMjcuMC4wLjE6NTA4MA--;nat=yes> Record-Route: <sip:192.168.1.62;r2=on;lr=on;ftag=f133137e;vsf=BhoZSgsAAW82GQYZBBscEhcTS00MAi0xMjcuMC4wLjE6NTA4MA--;vst=HxoZShAcA2o2GQYZBBscEhcTS00MAi0xMjcuMC4wLjE6NTA4MA--;nat=yes> From: "Manny"<sip:110_voiptosave.com@127.0.0.1:5080>;tag=f133137e To: "*65"<sip:*65_voiptosave.com@127.0.0.1:5080> Call-ID: Mjk2YjBjZjA2NDYzOTUxZDVmOGZjNTgwYzVmMjg3YjA. CSeq: 2 INVITE Server: Asterisk PBX 11.13.0 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Supported: replaces, timer Contact: <sip:*65@127.0.0.1:5080> Content-Length: 0 <------------> [May 28 16:07:58] VERBOSE[9110][C-00000021] pbx.c: -- Executing [*65@voiptosave.com-from-internal:1] Answer("SIP/110_voiptosave.com-0000001a", "") in new stack [May 28 16:07:58] VERBOSE[9110][C-00000021] chan_sip.c: Audio is at 17370 [May 28 16:07:58] VERBOSE[9110][C-00000021] chan_sip.c: Adding codec 100003 (ulaw) to SDP [May 28 16:07:58] VERBOSE[9110][C-00000021] chan_sip.c: Adding codec 100004 (alaw) to SDP [May 28 16:07:58] VERBOSE[9110][C-00000021] chan_sip.c: Adding codec 100002 (gsm) to SDP [May 28 16:07:58] VERBOSE[9110][C-00000021] chan_sip.c: Adding non-codec 0x1 (telephone-event) to SDP [May 28 16:07:58] VERBOSE[9110][C-00000021] chan_sip.c: <--- Reliably Transmitting (NAT) to 127.0.0.1:5060 ---> SIP/2.0 200 OK Via: SIP/2.0/UDP 127.0.0.1;branch=z9hG4bK0499.3cc1dc7f932835a200ec1f8feafd0895.0;received=127.0.0.1;rport=5060 Via: SIP/2.0/UDP 192.168.1.6:29470 ;branch=z9hG4bK-d87543-182127345f1d7b4f-1--d87543-;rport=29470 Record-Route: <sip:127.0.0.1;r2=on;lr=on;ftag=f133137e;vsf=BhoZSgsAAW82GQYZBBscEhcTS00MAi0xMjcuMC4wLjE6NTA4MA--;vst=HxoZShAcA2o2GQYZBBscEhcTS00MAi0xMjcuMC4wLjE6NTA4MA--;nat=yes> Record-Route: <sip:192.168.1.62;r2=on;lr=on;ftag=f133137e;vsf=BhoZSgsAAW82GQYZBBscEhcTS00MAi0xMjcuMC4wLjE6NTA4MA--;vst=HxoZShAcA2o2GQYZBBscEhcTS00MAi0xMjcuMC4wLjE6NTA4MA--;nat=yes> From: "Manny"<sip:110_voiptosave.com@127.0.0.1:5080>;tag=f133137e To: "*65"<sip:*65_voiptosave.com@127.0.0.1:5080>;tag=as3a404cf6 Call-ID: Mjk2YjBjZjA2NDYzOTUxZDVmOGZjNTgwYzVmMjg3YjA. CSeq: 2 INVITE Server: Asterisk PBX 11.13.0 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Supported: replaces, timer Contact: <sip:*65@127.0.0.1:5080> Content-Type: application/sdp Content-Length: 275 v=0 o=root 153043023 153043023 IN IP4 127.0.0.1 s=Asterisk PBX 11.13.0 c=IN IP4 127.0.0.1 t=0 0 m=audio 17370 RTP/AVP 0 8 3 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:3 GSM/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=sendrecv <------------> [May 28 16:07:58] VERBOSE[9110][C-00000021] pbx.c: -- Executing [*65@voiptosave.com-from-internal:2] Wait("SIP/110_voiptosave.com-0000001a", "1") in new stack [May 28 16:07:58] VERBOSE[2688] chan_sip.c: Retransmitting #1 (NAT) to 127.0.0.1:5060: SIP/2.0 200 OK Via: SIP/2.0/UDP 127.0.0.1;branch=z9hG4bK0499.3cc1dc7f932835a200ec1f8feafd0895.0;received=127.0.0.1;rport=5060 Via: SIP/2.0/UDP 192.168.1.6:29470 ;branch=z9hG4bK-d87543-182127345f1d7b4f-1--d87543-;rport=29470 Record-Route: <sip:127.0.0.1;r2=on;lr=on;ftag=f133137e;vsf=BhoZSgsAAW82GQYZBBscEhcTS00MAi0xMjcuMC4wLjE6NTA4MA--;vst=HxoZShAcA2o2GQYZBBscEhcTS00MAi0xMjcuMC4wLjE6NTA4MA--;nat=yes> Record-Route: <sip:192.168.1.62;r2=on;lr=on;ftag=f133137e;vsf=BhoZSgsAAW82GQYZBBscEhcTS00MAi0xMjcuMC4wLjE6NTA4MA--;vst=HxoZShAcA2o2GQYZBBscEhcTS00MAi0xMjcuMC4wLjE6NTA4MA--;nat=yes> From: "Manny"<sip:110_voiptosave.com@127.0.0.1:5080>;tag=f133137e To: "*65"<sip:*65_voiptosave.com@127.0.0.1:5080>;tag=as3a404cf6 Call-ID: Mjk2YjBjZjA2NDYzOTUxZDVmOGZjNTgwYzVmMjg3YjA. CSeq: 2 INVITE Server: Asterisk PBX 11.13.0 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Supported: replaces, timer Contact: <sip:*65@127.0.0.1:5080> Content-Type: application/sdp Content-Length: 275 v=0 o=root 153043023 153043023 IN IP4 127.0.0.1 s=Asterisk PBX 11.13.0 c=IN IP4 127.0.0.1 t=0 0 m=audio 17370 RTP/AVP 0 8 3 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:3 GSM/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=sendrecv --- [May 28 16:07:58] VERBOSE[2688] chan_sip.c: <--- SIP read from UDP:127.0.0.1:5060 ---> ACK sip:*65@127.0.0.1:5080 SIP/2.0 Via: SIP/2.0/UDP 127.0.0.1;branch=z9hG4bK0499.1131e459ea9f93c78896b0fdaf99b3be.0 Via: SIP/2.0/UDP 192.168.1.6:29470 ;branch=z9hG4bK-d87543-9f74bc13426dd510-1--d87543-;rport=29470 Max-Forwards: 69 Contact: <sip:110@192.168.1.6:29470> To: "*65"<sip:*65@voiptosave.com>;tag=as3a404cf6 From: "Manny"<sip:110@voiptosave.com>;tag=f133137e Call-ID: Mjk2YjBjZjA2NDYzOTUxZDVmOGZjNTgwYzVmMjg3YjA. CSeq: 2 ACK Proxy-Authorization: Digest username="110",realm="voiptosave.com ",nonce="VWd2ylVndZ5Yo3kaAdjLh/W6zc+CeoE1",uri="sip:*65@voiptosave.com ",response="ed5ad3dd093d74414340aa68dca6a246",algorithm=MD5 User-Agent: eyeBeam release 1011w stamp 42237 Content-Length: 0 <-------------> [May 28 16:07:58] VERBOSE[2688] chan_sip.c: --- (12 headers 0 lines) --- [May 28 16:07:58] VERBOSE[2688] chan_sip.c: <--- SIP read from UDP:127.0.0.1:5060 ---> ACK sip:*65@127.0.0.1:5080 SIP/2.0 Via: SIP/2.0/UDP 127.0.0.1;branch=z9hG4bK0499.1131e459ea9f93c78896b0fdaf99b3be.0 Via: SIP/2.0/UDP 192.168.1.6:29470 ;branch=z9hG4bK-d87543-9f74bc13426dd510-1--d87543-;rport=29470 Max-Forwards: 69 Contact: <sip:110@192.168.1.6:29470> To: "*65"<sip:*65@voiptosave.com>;tag=as3a404cf6 From: "Manny"<sip:110@voiptosave.com>;tag=f133137e Call-ID: Mjk2YjBjZjA2NDYzOTUxZDVmOGZjNTgwYzVmMjg3YjA. CSeq: 2 ACK Proxy-Authorization: Digest username="110",realm="voiptosave.com ",nonce="VWd2ylVndZ5Yo3kaAdjLh/W6zc+CeoE1",uri="sip:*65@voiptosave.com ",response="ed5ad3dd093d74414340aa68dca6a246",algorithm=MD5 User-Agent: eyeBeam release 1011w stamp 42237 Content-Length: 0 <-------------> [May 28 16:07:58] VERBOSE[2688] chan_sip.c: --- (12 headers 0 lines) --- [May 28 16:07:59] VERBOSE[9110][C-00000021] pbx.c: -- Executing [*65@voiptosave.com-from-internal:3] Macro("SIP/110_voiptosave.com-0000001a", "voiptosave.com-user-callerid,") in new stack [May 28 16:07:59] VERBOSE[9110][C-00000021] pbx.c: -- Executing [s@macro-voiptosave.com-user-callerid:1] Set("SIP/110_voiptosave.com-0000001a", "EXTUSER=110") in new stack [May 28 16:07:59] VERBOSE[9110][C-00000021] pbx.c: -- Executing [s@macro-voiptosave.com-user-callerid:2] GotoIf("SIP/110_voiptosave.com-0000001a", "0?report") in new stack [May 28 16:07:59] VERBOSE[9110][C-00000021] pbx.c: -- Executing [s@macro-voiptosave.com-user-callerid:3] ExecIf("SIP/110_voiptosave.com-0000001a", "1?Set(REALCALLERIDNUM=110)") in new stack [May 28 16:07:59] VERBOSE[9110][C-00000021] pbx.c: -- Executing [s@macro-voiptosave.com-user-callerid:4] Set("SIP/110_voiptosave.com-0000001a", "EXTUSER=110") in new stack [May 28 16:07:59] VERBOSE[9110][C-00000021] pbx.c: -- Executing [s@macro-voiptosave.com-user-callerid:5] Set("SIP/110_voiptosave.com-0000001a", "EXTUSERCIDNAME=User_110") in new stack [May 28 16:07:59] VERBOSE[9110][C-00000021] pbx.c: -- Executing [s@macro-voiptosave.com-user-callerid:6] GotoIf("SIP/110_voiptosave.com-0000001a", "0?report") in new stack [May 28 16:07:59] VERBOSE[9110][C-00000021] pbx.c: -- Executing [s@macro-voiptosave.com-user-callerid:7] Set("SIP/110_voiptosave.com-0000001a", "EXTUSERCID=110") in new stack [May 28 16:07:59] VERBOSE[9110][C-00000021] pbx.c: -- Executing [s@macro-voiptosave.com-user-callerid:8] Set("SIP/110_voiptosave.com-0000001a", "CALLERID(all)="User_110" <110>") in new stack [May 28 16:07:59] VERBOSE[9110][C-00000021] pbx.c: -- Executing [s@macro-voiptosave.com-user-callerid:9] ExecIf("SIP/110_voiptosave.com-0000001a", "1?Set(CHANNEL(language)=en)") in new stack [May 28 16:07:59] VERBOSE[9110][C-00000021] pbx.c: -- Executing [s@macro-voiptosave.com-user-callerid:10] ExecIf("SIP/110_voiptosave.com-0000001a", "1?Set(CHANNEL(language)=en)") in new stack [May 28 16:07:59] VERBOSE[9110][C-00000021] pbx.c: -- Executing [s@macro-voiptosave.com-user-callerid:11] GotoIf("SIP/110_voiptosave.com-0000001a", "0?continue") in new stack [May 28 16:07:59] VERBOSE[9110][C-00000021] pbx.c: -- Executing [s@macro-voiptosave.com-user-callerid:12] Set("SIP/110_voiptosave.com-0000001a", "__TTL=64") in new stack [May 28 16:07:59] VERBOSE[9110][C-00000021] pbx.c: -- Executing [s@macro-voiptosave.com-user-callerid:13] GotoIf("SIP/110_voiptosave.com-0000001a", "1?continue") in new stack [May 28 16:07:59] VERBOSE[9110][C-00000021] pbx.c: -- Goto (macro-voiptosave.com-user-callerid,s,20) [May 28 16:07:59] VERBOSE[9110][C-00000021] pbx.c: -- Executing [s@macro-voiptosave.com-user-callerid:20] Set("SIP/110_voiptosave.com-0000001a", "CALLERID(number)=110") in new stack [May 28 16:07:59] VERBOSE[9110][C-00000021] pbx.c: -- Executing [s@macro-voiptosave.com-user-callerid:21] Set("SIP/110_voiptosave.com-0000001a", "CALLERID(name)=User_110") in new stack [May 28 16:07:59] VERBOSE[9110][C-00000021] pbx.c: -- Executing [s@macro-voiptosave.com-user-callerid:22] NoOp("SIP/110_voiptosave.com-0000001a", "Using CallerID "User_110" <110>") in new stack [May 28 16:07:59] VERBOSE[9110][C-00000021] pbx.c: -- Executing [*65@voiptosave.com-from-internal:4] Playback("SIP/110_voiptosave.com-0000001a", "your") in new stack [May 28 16:07:59] VERBOSE[9110][C-00000021] file.c: -- <SIP/110_voiptosave.com-0000001a> Playing 'your.gsm' (language 'en') [May 28 16:08:00] VERBOSE[9110][C-00000021] pbx.c: -- Executing [*65@voiptosave.com-from-internal:5] Playback("SIP/110_voiptosave.com-0000001a", "extension") in new stack [May 28 16:08:00] VERBOSE[9110][C-00000021] file.c: -- <SIP/110_voiptosave.com-0000001a> Playing 'extension.gsm' (language 'en') [May 28 16:08:01] VERBOSE[9110][C-00000021] pbx.c: -- Executing [*65@voiptosave.com-from-internal:6] Playback("SIP/110_voiptosave.com-0000001a", "number") in new stack [May 28 16:08:01] VERBOSE[9110][C-00000021] file.c: -- <SIP/110_voiptosave.com-0000001a> Playing 'number.gsm' (language 'en') [May 28 16:08:02] VERBOSE[9110][C-00000021] pbx.c: -- Executing [*65@voiptosave.com-from-internal:7] Playback("SIP/110_voiptosave.com-0000001a", "is") in new stack [May 28 16:08:02] VERBOSE[9110][C-00000021] file.c: -- <SIP/110_voiptosave.com-0000001a> Playing 'is.gsm' (language 'en') [May 28 16:08:03] VERBOSE[9110][C-00000021] pbx.c: -- Executing [*65@voiptosave.com-from-internal:8] SayDigits("SIP/110_voiptosave.com-0000001a", "110") in new stack [May 28 16:08:03] VERBOSE[9110][C-00000021] file.c: -- <SIP/110_voiptosave.com-0000001a> Playing 'digits/1.gsm' (language 'en') [May 28 16:08:03] VERBOSE[9110][C-00000021] file.c: -- <SIP/110_voiptosave.com-0000001a> Playing 'digits/1.gsm' (language 'en') [May 28 16:08:04] VERBOSE[9110][C-00000021] file.c: -- <SIP/110_voiptosave.com-0000001a> Playing 'digits/0.gsm' (language 'en') [May 28 16:08:05] VERBOSE[9110][C-00000021] pbx.c: -- Executing [*65@voiptosave.com-from-internal:9] Wait("SIP/110_voiptosave.com-0000001a", "2") in new stack [May 28 16:08:07] VERBOSE[9110][C-00000021] pbx.c: -- Executing [*65@voiptosave.com-from-internal:10] Hangup("SIP/110_voiptosave.com-0000001a", "") in new stack [May 28 16:08:07] VERBOSE[9110][C-00000021] pbx.c: == Spawn extension (voiptosave.com-from-internal, *65, 10) exited non-zero on 'SIP/110_voiptosave.com-0000001a' [May 28 16:08:07] VERBOSE[9110][C-00000021] pbx.c: -- Executing [h@voiptosave.com-from-internal:1] Macro("SIP/110_voiptosave.com-0000001a", "voiptosave.com-hangupcall") in new stack [May 28 16:08:07] VERBOSE[9110][C-00000021] pbx.c: -- Executing [s@macro-voiptosave.com-hangupcall:1] ExecIf("SIP/110_voiptosave.com-0000001a", "1?Set(CDR(organization_domain)= voiptosave.com)") in new stack [May 28 16:08:07] VERBOSE[9110][C-00000021] pbx.c: -- Executing [s@macro-voiptosave.com-hangupcall:2] GotoIf("SIP/110_voiptosave.com-0000001a", "1?endmixmoncheck") in new stack [May 28 16:08:07] VERBOSE[9110][C-00000021] pbx.c: -- Goto (macro-voiptosave.com-hangupcall,s,7) [May 28 16:08:07] VERBOSE[9110][C-00000021] pbx.c: -- Executing [s@macro-voiptosave.com-hangupcall:7] NoOp("SIP/110_voiptosave.com-0000001a", "End of MIXMON check") in new stack [May 28 16:08:07] VERBOSE[9110][C-00000021] pbx.c: -- Executing [s@macro-voiptosave.com-hangupcall:8] GotoIf("SIP/110_voiptosave.com-0000001a", "1?nomeetmemon") in new stack [May 28 16:08:07] VERBOSE[9110][C-00000021] pbx.c: -- Goto (macro-voiptosave.com-hangupcall,s,14) [May 28 16:08:07] VERBOSE[9110][C-00000021] pbx.c: -- Executing [s@macro-voiptosave.com-hangupcall:14] NoOp("SIP/110_voiptosave.com-0000001a", "MEETME_RECORDINGFILE=") in new stack [May 28 16:08:07] VERBOSE[9110][C-00000021] pbx.c: -- Executing [s@macro-voiptosave.com-hangupcall:15] GotoIf("SIP/110_voiptosave.com-0000001a", "1?noautomon") in new stack [May 28 16:08:07] VERBOSE[9110][C-00000021] pbx.c: -- Goto (macro-voiptosave.com-hangupcall,s,23) [May 28 16:08:07] VERBOSE[9110][C-00000021] pbx.c: -- Executing [s@macro-voiptosave.com-hangupcall:23] NoOp("SIP/110_voiptosave.com-0000001a", "TOUCH_MONITOR_OUTPUT=") in new stack [May 28 16:08:07] VERBOSE[9110][C-00000021] pbx.c: -- Executing [s@macro-voiptosave.com-hangupcall:24] GotoIf("SIP/110_voiptosave.com-0000001a", "1?noautomon2") in new stack [May 28 16:08:07] VERBOSE[9110][C-00000021] pbx.c: -- Goto (macro-voiptosave.com-hangupcall,s,31) [May 28 16:08:07] VERBOSE[9110][C-00000021] pbx.c: -- Executing [s@macro-voiptosave.com-hangupcall:31] NoOp("SIP/110_voiptosave.com-0000001a", "MONITOR_FILENAME=") in new stack [May 28 16:08:07] VERBOSE[9110][C-00000021] pbx.c: -- Executing [s@macro-voiptosave.com-hangupcall:32] GotoIf("SIP/110_voiptosave.com-0000001a", "1?skiprg") in new stack [May 28 16:08:07] VERBOSE[9110][C-00000021] pbx.c: -- Goto (macro-voiptosave.com-hangupcall,s,35) [May 28 16:08:07] VERBOSE[9110][C-00000021] pbx.c: -- Executing [s@macro-voiptosave.com-hangupcall:35] GotoIf("SIP/110_voiptosave.com-0000001a", "1?skipblkvm") in new stack [May 28 16:08:07] VERBOSE[9110][C-00000021] pbx.c: -- Goto (macro-voiptosave.com-hangupcall,s,38) [May 28 16:08:07] VERBOSE[9110][C-00000021] pbx.c: -- Executing [s@macro-voiptosave.com-hangupcall:38] GotoIf("SIP/110_voiptosave.com-0000001a", "1?theend") in new stack [May 28 16:08:07] VERBOSE[9110][C-00000021] pbx.c: -- Goto (macro-voiptosave.com-hangupcall,s,40) [May 28 16:08:07] VERBOSE[9110][C-00000021] pbx.c: -- Executing [s@macro-voiptosave.com-hangupcall:40] Hangup("SIP/110_voiptosave.com-0000001a", "") in new stack [May 28 16:08:07] VERBOSE[9110][C-00000021] app_macro.c: == Spawn extension (macro-voiptosave.com-hangupcall, s, 40) exited non-zero on 'SIP/110_voiptosave.com-0000001a' in macro 'voiptosave.com-hangupcall' [May 28 16:08:07] VERBOSE[9110][C-00000021] pbx.c: == Spawn extension (voiptosave.com-from-internal, h, 1) exited non-zero on 'SIP/110_voiptosave.com-0000001a' [May 28 16:08:07] VERBOSE[9110][C-00000021] chan_sip.c: Scheduling destruction of SIP dialog 'Mjk2YjBjZjA2NDYzOTUxZDVmOGZjNTgwYzVmMjg3YjA.' in 6400 ms (Method: ACK) [May 28 16:08:07] VERBOSE[9110][C-00000021] chan_sip.c: set_destination: Parsing <sip:127.0.0.1;r2=on;lr=on;ftag=f133137e;vsf=BhoZSgsAAW82GQYZBBscEhcTS00MAi0xMjcuMC4wLjE6NTA4MA--;vst=HxoZShAcA2o2GQYZBBscEhcTS00MAi0xMjcuMC4wLjE6NTA4MA--;nat=yes> for address/port to send to [May 28 16:08:07] VERBOSE[9110][C-00000021] chan_sip.c: set_destination: set destination to 127.0.0.1:5060 [May 28 16:08:07] VERBOSE[9110][C-00000021] chan_sip.c: Reliably Transmitting (NAT) to 127.0.0.1:5060: BYE sip:110@192.168.1.6:29470 SIP/2.0 Via: SIP/2.0/UDP 127.0.0.1:5080;branch=z9hG4bK2355deaa;rport Route: <sip:127.0.0.1;r2=on;lr=on;ftag=f133137e;vsf=BhoZSgsAAW82GQYZBBscEhcTS00MAi0xMjcuMC4wLjE6NTA4MA--;vst=HxoZShAcA2o2GQYZBBscEhcTS00MAi0xMjcuMC4wLjE6NTA4MA--;nat=yes>,<sip:192.168.1.62;r2=on;lr=on;ftag=f133137e;vsf=BhoZSgsAAW82GQYZBBscEhcTS00MAi0xMjcuMC4wLjE6NTA4MA--;vst=HxoZShAcA2o2GQYZBBscEhcTS00MAi0xMjcuMC4wLjE6NTA4MA--;nat=yes> Max-Forwards: 70 From: "*65"<sip:*65_voiptosave.com@127.0.0.1:5080>;tag=as3a404cf6 To: "Manny"<sip:110_voiptosave.com@127.0.0.1:5080>;tag=f133137e Call-ID: Mjk2YjBjZjA2NDYzOTUxZDVmOGZjNTgwYzVmMjg3YjA. CSeq: 102 BYE User-Agent: Asterisk PBX 11.13.0 X-Asterisk-HangupCause: Normal Clearing X-Asterisk-HangupCauseCode: 16 Content-Length: 0 --- [May 28 16:08:07] VERBOSE[2688] chan_sip.c: Retransmitting #1 (NAT) to 127.0.0.1:5060: BYE sip:110@192.168.1.6:29470 SIP/2.0 Via: SIP/2.0/UDP 127.0.0.1:5080;branch=z9hG4bK2355deaa;rport Route: <sip:127.0.0.1;r2=on;lr=on;ftag=f133137e;vsf=BhoZSgsAAW82GQYZBBscEhcTS00MAi0xMjcuMC4wLjE6NTA4MA--;vst=HxoZShAcA2o2GQYZBBscEhcTS00MAi0xMjcuMC4wLjE6NTA4MA--;nat=yes>,<sip:192.168.1.62;r2=on;lr=on;ftag=f133137e;vsf=BhoZSgsAAW82GQYZBBscEhcTS00MAi0xMjcuMC4wLjE6NTA4MA--;vst=HxoZShAcA2o2GQYZBBscEhcTS00MAi0xMjcuMC4wLjE6NTA4MA--;nat=yes> Max-Forwards: 70 From: "*65"<sip:*65_voiptosave.com@127.0.0.1:5080>;tag=as3a404cf6 To: "Manny"<sip:110_voiptosave.com@127.0.0.1:5080>;tag=f133137e Call-ID: Mjk2YjBjZjA2NDYzOTUxZDVmOGZjNTgwYzVmMjg3YjA. CSeq: 102 BYE User-Agent: Asterisk PBX 11.13.0 X-Asterisk-HangupCause: Normal Clearing X-Asterisk-HangupCauseCode: 16 Content-Length: 0 --- [May 28 16:08:07] VERBOSE[2688] chan_sip.c: <--- SIP read from UDP:127.0.0.1:5060 ---> SIP/2.0 200 OK Via: SIP/2.0/UDP 127.0.0.1:5080;branch=z9hG4bK2355deaa;rport=5080 Contact: <sip:110@192.168.1.6:29470> To: "Manny"<sip:110_voiptosave.com@127.0.0.1:5080>;tag=f133137e From: "*65"<sip:*65_voiptosave.com@127.0.0.1:5080>;tag=as3a404cf6 Call-ID: Mjk2YjBjZjA2NDYzOTUxZDVmOGZjNTgwYzVmMjg3YjA. CSeq: 102 BYE User-Agent: eyeBeam release 1011w stamp 42237 Content-Length: 0 <-------------> [May 28 16:08:07] VERBOSE[2688] chan_sip.c: --- (9 headers 0 lines) --- [May 28 16:08:07] VERBOSE[2688][C-00000021] chan_sip.c: SIP Response message for INCOMING dialog BYE arrived [May 28 16:08:07] VERBOSE[2688] chan_sip.c: Really destroying SIP dialog 'Mjk2YjBjZjA2NDYzOTUxZDVmOGZjNTgwYzVmMjg3YjA.' Method: ACK [May 28 16:08:08] VERBOSE[2688] chan_sip.c: Reliably Transmitting (NAT) to 127.0.0.1:5060: OPTIONS sip:110@192.168.1.6:29470;rinstance=3180b40a89f2e3f4 SIP/2.0 Via: SIP/2.0/UDP 127.0.0.1:5080;branch=z9hG4bK0bcd981c;rport Max-Forwards: 70 From: "asterisk" <sip:asterisk@127.0.0.1:5080>;tag=as68358641 To: <sip:110@192.168.1.6:29470;rinstance=3180b40a89f2e3f4> Contact: <sip:asterisk@127.0.0.1:5080> Call-ID: 03d50e985a2f08445ad315c83a591412@127.0.0.1:5080 CSeq: 102 OPTIONS User-Agent: Asterisk PBX 11.13.0 Date: Thu, 28 May 2015 20:08:08 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Supported: replaces, timer Content-Length: 0 --- [May 28 16:08:08] VERBOSE[2688] chan_sip.c: <--- SIP read from UDP:127.0.0.1:5060 ---> SIP/2.0 200 OK Via: SIP/2.0/UDP 127.0.0.1:5080;branch=z9hG4bK0bcd981c;rport=5080 Contact: <sip:192.168.1.6:29470> To: <sip:110@192.168.1.6:29470;rinstance=3180b40a89f2e3f4>;tag=86756729 From: "asterisk"<sip:asterisk@127.0.0.1:5080>;tag=as68358641 Call-ID: 03d50e985a2f08445ad315c83a591412@127.0.0.1:5080 CSeq: 102 OPTIONS Accept: application/sdp Accept-Language: en Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO User-Agent: eyeBeam release 1011w stamp 42237 Content-Length: 0 <-------------> [May 28 16:08:08] VERBOSE[2688] chan_sip.c: --- (12 headers 0 lines) --- [May 28 16:08:08] VERBOSE[2688] chan_sip.c: Really destroying SIP dialog ' 03d50e985a2f08445ad315c83a591412@127.0.0.1:5080' Method: OPTIONS ################################################################## Please let me know if you need any settings. I am more than happy to provide it. Thank you.

1 1

log the value of "from_uri" and "myself"
by Al S 28 May '15

28 May '15

Hi, I would like to know how to log the value of "from_uri" and "myself" attributes on kamailio 3.3.7 ?None of the following works: xlog("L_INFO","from_uri: $dlg(from_uri)"); $var(x) = from_uri;xlog("L_INFO","$var(x)"); Thanks,Al

2 3

Kamailio not receiving BYE request
by Ali Taher 28 May '15

28 May '15

Hello, Kamailio is not receiving the BYE request when the call is ended by any of call parties. Noting that when the call is connected, a direct RTP session is established between the user and the gateway , and kamailio doesn't receive since then any message related to this call. Is there any trick to do in order to let kamailio gets the BYE request? Attached is the used configuration. Appreciate your help. Regards, Ali

3 11

Regarding presence conference
by Surendra Pullaiah 28 May '15

28 May '15

Hello Daniel, I am implementing conference bridge using kamalio and RTP porxy without media mixing. Since for now we are ok with this. My question is as per the flow of RFC 4579, UA may send SUBSCRIBE to the conference URI with event as conference. In kamalio modules presence_conference where they mentioned such way that it will support the same what I am looking for. But I simulated using sipP by sending subscriber with conference event. I am not seeing any notify XML which will have the conference users list. One more doubt where it will pick the conference users, since I am not seeing any specific data base table for the same. Can you please clarify what exactly for presence_conference module. Note: I have loaded three modules presence, presence_xml, presence_conference, in route config I am calling handle_subscribe when SUBCRIBE method receives. Regards Surendra India: +91-8124625001

1 0

Kamailio drouting failure not working
by Ali Taher 28 May '15

28 May '15

Dears, I'm trying drouting module in kamailio , it's working good when first gateway in the list is up , yet when first gateway is unrecheable , it's not rerouted to second destination, meaning that fail over is not working. Kindly find attached wireshark trace I'm getting . Below is db entries I'm using : dr_gateways: Dr_gw_lists Dr_groups: Dr_rules: Below is routing block I'm using : request_route{ if (is_method("INVITE")) { if (!do_routing("0")) { send_reply("503", "Test No Rules matching the URI"); exit; } route(10); exit; } } route[10] { if (!do_routing("0")) { xlog("do_routing: No rules matching the URI\n"); send_reply("503","No rules matching the URI"); exit; } if (is_method("INVITE")) { t_on_failure("4"); } route(1); } failure_route[4] { xlog("DEBUG: DROUTING failure route active\n"); if (t_check_status("[34][0-9][0-9]")) { exit; } if (use_next_gw()) { t_relay(); exit; } else { t_reply ("503", "Service not available"); exit; } } route[1] { # send it out now; use stateful forwarding as it works # reliably even for UDP2TCP if (!t_relay()) { sl_reply_error(); }; exit; } Appreciating your prompt reply and assistance. Ali Taher Technical Support Engineer T&F M W A +961-5-457437 Ext 215 +961-70-010600 <http://www.vanrise.com/> http://www.vanrise.com <https://maps.google.com/maps/ms?msa=0&msid=208243362929850217065.0004cbc8d6 12c5f9b4237&ie=UTF8&t=h&vpsrc=0&z=19&iwloc=0004cbc8e4652b4edf71cC:\Users\Mar ie\Documents\My%20Received%20Files> Vanrise Building, Facing Galerie Semaan Hazmiyeh Highway - Beirut, Lebanon Join us at <http://www.facebook.com/pages/Vanrise-Solutions-Offshore/128309743915533> <http://www.linkedin.com/company/vanrise-solutions> <http://twitter.com/VanriseSolution>

3 22

kamailio crash periodically in timer handler
by Péter Barabás 27 May '15

27 May '15

Hi, we have a serious problem with Kamailio v4.2.3, it crashes after some days. We have checked the core dump and the gdb output is the following for bt and full backtrace: #0 0x0000000000602291 in timer_list_expire (t=1432559962, h=0x7f64eb5b6bd0, slow_l=0x7f64eb5ba328, slow_mark=43873) at timer.c:877 #1 0x0000000000602746 in timer_handler () at timer.c:953 #2 0x0000000000602bb9 in timer_main () at timer.c:992 #3 0x00000000004a833c in main_loop () at main.c:1700 #4 0x00000000004ad857 in main (argc=13, argv=0x7fff96697d38) at main.c:2578 #0 0x0000000000602291 in timer_list_expire (t=1432559962, h=0x7f64eb5b6bd0, slow_l=0x7f64eb5ba328, slow_mark=43873) at timer.c:877 tl = 0x7f64ebc3a908 ret = 0 #1 0x0000000000602746 in timer_handler () at timer.c:953 saved_ticks = 1432559962 run_slow_timer = 0 i = 865 __FUNCTION__ = "timer_handler" #2 0x0000000000602bb9 in timer_main () at timer.c:992 No locals. #3 0x00000000004a833c in main_loop () at main.c:1700 i = 4 pid = 0 si = 0x0 si_desc = "udp receiver child=3 sock=127.0.0.1:5060\000\375\362\250/\313\345\v\004\000\000\000\000\000\000\000\004\257\263=\000\000\000\000\200TA\000\000\000\000\000\060}i\226\377\177", '\000' <repeats 19 times>, "{i\226\377\177\000\000\376\366R\000\000\000\000\000\377\377\377\377\377\177\000\000@\350\250\000\000\000\000" nrprocs = 4 __FUNCTION__ = "main_loop" #4 0x00000000004ad857 in main (argc=13, argv=0x7fff96697d38) at main.c:2578 cfg_stream = 0x1b94010 c = -1 r = 0 tmp = 0x7fff96699b17 "" tmp_len = 0 port = 1 proto = 32767 options = 0x703e08 ":f:cm:M:dVIhEeb:l:L:n:vKrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:" ret = -1 seed = 2591880768 rfd = 4 debug_save = 0 debug_flag = 0 dont_fork_cnt = 0 n_lst = 0x0 p = 0x7fff96697c50 "" __FUNCTION__ = "main" In the logs it can be seen: Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4635]: CRITICAL: <core> [pass_fd.c:293]: receive_fd(): EOF on 21 Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4612]: ALERT: <core> [main.c:784]: handle_sigs(): child process 4623 exited by a signal 11 Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4612]: ALERT: <core> [main.c:787]: handle_sigs(): core was generated Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4612]: INFO: <core> [main.c:799]: handle_sigs(): terminating due to SIGCHLD Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4631]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4628]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4634]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4615]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4617]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4626]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4625]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4624]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4632]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4622]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4621]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4620]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4619]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4618]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4616]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4635]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4614]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4629]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4627]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4633]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4630]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4612]: INFO: <core> [mem/f_malloc.c:599]: fm_free(): freeing a free fragment (0x7f64eca19950/0x7f64eca19988) - ignore Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4612]: INFO: <core> [mem/f_malloc.c:599]: fm_free(): freeing a free fragment (0x7f64ed587f20/0x7f64ed587f58) - ignore Kamailio runs on Ubuntu trusty. The interesting thing that we run Kamailio 4.2.3 in an other environment (on Debian Squeeze) and it works perfect, no crashes. The main difference is that in Debian environment we have less number of users and the firewall is not so strength. But the configuration and the source is the same for both. Please help us to solve this problem. Thanks. Dr. Péter Barabás Director of Software Development Arenim Technologies AB. Mob: +36 70 314 56 57 Tel: +36 1 8 555 602 E-mail: peter.barabas(a)arenim.com<mailto:peter.barabas@arenim.com> Postal: Sweden - 11435 Stockholm, Stureplan 4c, 4th. Floor [Arenim_logo]<http://www.arenim.com/> [CryptTalk_Logo]<http://www.crypttalk.com/>

2 11

Kamailio with public ip, users behind nat
by MtK - SmartMtK 27 May '15

27 May '15

Hi, I'm trying to install Kamailio on a server with a public IP, but my users are mostly at their homes (a.k.a behind NAT). I understood I need to install RTPproxy, but all tutorials out there are for servers behind nat, and they talk about the server's private IP, which does not exists in this case. how would I configure RTPproxy and Kamailio to allow users to subscribe to the server and have audio calls between them? MtK

3 2

dbcassandra schema files
by jay binks 26 May '15

26 May '15

Hi all, Im wondering if anyone can share their schema files for dbcassandra. Ive managed to construct a bunch based on what ive found in git, wiki all over the place, I just want to compare my ones, with some others. specifically the location table. -- Sincerely Jay

2 1

Development open again for master branch
by Daniel-Constantin Mierla 26 May '15

26 May '15

Hello, as branch 4.3 was created to host the upcoming release series 4.3, new features can be now pushed to master branch. They will be part of the next future release, likely to be numbered 4.4. Any fixes that affect existing code in branches 4.3 or older version have to be backported - push first to master and then cherry pick -- some guidelines exemplified with branch 3.2 are available at: - https://www.kamailio.org/wiki/devel/backporting-to-3.2.x As usual, the next future release will be out as stable version in like 8-10 months. Cheers, Daniel -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015 Berlin, Germany - http://www.kamailioworld.com

1 0

Branch 4.3 created
by Daniel-Constantin Mierla 26 May '15

26 May '15

Hello, the GIT branch 4.3 was created, it will host the release series 4.3.x. To get this branch from GIT, you can use: git clone https://github.com/kamailio/kamailio.git kamailio cd kamailio git checkout -b 4.3 origin/4.3 Notes about installing Kamailio from this branch are available at: - http://www.kamailio.org/wiki/install/4.3.x/git Hopefully in about two weeks or so the full release of 4.3.0 will be out. >From now on, any corresponding fix has to be pushed first to master branch and then cherry-picked to branch 4.3. No new features can get in branch 4.3. Enhancements to documentation or helping tools are still allowed. Cheers, Daniel -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015 Berlin, Germany - http://www.kamailioworld.com

1 0

Using $avp in evapi:message-received
by DanB 25 May '15

25 May '15

Hey Guys, Was wondering what would be the recommended way to share information between $evapi(msg) received and transaction processors? I have tried $avp() but they do not appear to be available in evapi:message-received route. Trying to avoid here $sht() so I don't need to do extra management to destroy them. Is there any way to "activate" the $avp or $dlg_var based on dialog index, label maybe? Thanks in advance for any kind of tip! DanB //

3 7

info
by Walter Josef 25 May '15

25 May '15

Hi, Do you have any phonenumber for info about your iptel voip phone service ?

2 1

Creating branch 4.3
by Daniel-Constantin Mierla 25 May '15

25 May '15

Hello, I am planning to branch the code for upcoming major release on next Monday, May 25. Testing went fine so far in my side and I don't expect new consistent changes. Any fixes afterwards will be backported as usual to a stable branch. From that moment, master branch will be open again for new features. If someone else has different proposal, let's discuss it on sr-dev mailing list. Cheers, Daniel -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015 Berlin, Germany - http://www.kamailioworld.com

1 1

Re: [SR-Users] Getting 404 From Kamailio for PRACK
by DanB 24 May '15

24 May '15

Hi Austin, Kamailio will not reject by himself (nor handle) PRACK (or any other methods) unless you tell him so. The logic for handling it should be in your .cfg file. I suggest adding xlog statements through your config script and see where that is rejected. 404 would tell me you are trying to locate your endpoint and send the PRACK there but the endpoint is not registered. DanB

1 0

Re: [SR-Users] Increase Simultaneous Registration
by DanB 24 May '15

24 May '15

Hi Austin, Kamailio should be pretty fast on these things. Here are things which you can check: * Increase number of TCP workers/make sure you are using async TCP. * Use in-memory store for your registrations, not DB ones (at least dump async your contacts in DB). * Make sure you allow enough files to be opened in case of TCP connections (I suspect this is your issue there). Regarding performance tests, not sure if you saw already these links: http://www.kamailio.org/docs/openser-performance-tests/ https://sip-router.org/wiki/performance/v3.0-capacity Hope these help! DanB

1 0

disabling Server header in kamailio
by NITESH BANSAL 22 May '15

22 May '15

Hello, I noticed that Kamailio adds a Server header in the replies generated by it, is there anyway to disable it? Thanks in advance for your help, Nitesh

2 1

Find if client is connected.
by Dmytro Bogovych 22 May '15

22 May '15

Greetings. I want to modify INVITE answers processing in this way: 1) receive INVITE answer 2) check if recipient is registered but has no TCP/TLS connection now 3) suspend answer for 30 seconds (for example) 4) resume answer if REGISTER comes from lost client in these 30 seconds 5) terminate INVITE session if 30 seconds are expired What I do not understand - is it possible to find if client is connected now to kamailio? I talk about TCP/TLS connection only - not about registration record. Thank you!

3 7

issues with domain names in the record route
by NITESH BANSAL 22 May '15

22 May '15

Hello, I am trying to play with domain names in the Record-Route header. This is for a case when kamailio is doing the translation between UDP and TLS, so it is doing double record routing. I want to use the ip addresses on inbound UDP leg and domain names on the outbound TLS leg in record-route headers. I'm doing this by calling the following function -- record_route_preset("xyz.com;transport=tls", "1.1.1.1"); ---- This does the trick of adding a Record-Route in initial TLS invite on the outbound leg: ----------------- Record-Route: <sip:xyz.com;transport=tls;lr=on> Record-Route: <sip:1.1.1.1;lr=on> ---------------- My problems start when the calling party sends a ACK to kamailio over UDP with the Route header Route: <sip:1.1.1.1;lr=on>,<sip:xyz.com;transport=tls;lr=on> I call loose_route() function in config file and as per my expectation, Kamailio should see that both these Route headers belong to Kamailio and it should use Request URI for forwarding the ACK, but unfortunately, Kamailio thinks that xyz.com is some other entity and tries to forward the ACK to xyz.com doing a DNS query. What can i do to avoid this problem, i need kamailio to recognize that "xyz.com" is kamailio as i have a defined an alias in the config file too as follows: alias=xyz.com:5060 Thanks for your help in advance, Nitesh

3 3

rtpproxy 2.0
by Klaus Darilion 22 May '15

22 May '15

Hi! I just found out that there is a new rtpproxy release: http://www.rtpproxy.org/post/v2release/ Has anybody tested it and want to share some experiences? Or have people turned to rtpengine meanwhile? (I am still using rtpproxy 1.2 as I do not need new features). regards Klaus

3 2

Re: [SR-Users] Kamailio proxy for far-end nat traversal
by rahul.ultimate 21 May '15

21 May '15

Hi Daniel I have rtpproxy to perform media relaying. The case where it just timeouts: 1. Client A behind NAT (wifi) calling Client B on 3G Sent from Samsung Mobile -------- Original message -------- From: Daniel-Constantin Mierla <miconda(a)gmail.com> Date:05/05/2015 12:52 (GMT+05:30) To: "Kamailio (SER) - Users Mailing List" <sr-users(a)lists.sip-router.org> Subject: Re: [SR-Users] Kamailio proxy for far-end nat traversal Hello, do you have rtpproxy or rtpengine for relaying rtp packets? Kamailio is routing only sip packets, you need the rtp relay application to help with media streams. Cheers, Daniel On 01/05/15 13:15, rahul.ultimate wrote: Hello I need a small guidance on creating a light weight proxy which only forwards the msgs to my sip server and also does supports symmetrical nated clients. The way I have created the configuration is a slight modification of : https://github.com/xlab1/sipfe_kamailio/blob/master/kamailio.cfg Problem is unless the sip clients use STUN media packets are not routed. And sometimes even the signalling does not pass through. Should i not use fix_nated_register and switch to fix _ nated_contact always ? Because in all those cases where signalling does not pass through, I see RTO. My best guess is kamailio trying to communicate with private ip. Anything which I can try that you could suggest from the top of yourmind woyld be muc appreciated. Thanks Rahul Sent from Samsung Mobile _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015 Berlin, Germany - http://www.kamailioworld.com

4 5

XLOG Problem
by Nahum Nir 21 May '15

21 May '15

Hi All, I am using Kamailio 4.0.3 and can't logs. .cfg: #!define WITH_DEBUG ### LOG Levels: 3=DBG, 2=INFO, 1=NOTICE, 0=WARN, -1=ERR #!ifdef WITH_DEBUG debug=4 log_stderror=yes #!else debug=2 log_stderror=no #!endif memdbg=5 memlog=5 log_facility=LOG_LOCAL0 When the server starts there outputs about xlog: 0(20266) DEBUG: <core> [cfg.y:1791]: yyparse(): loading module xlog.so 0(20266) DEBUG: <core> [sr_module.c:499]: load_module(): load_module: module file not found </usr/local/lib/kamailio/modules_k/xlog.so> 0(20266) DEBUG: <core> [sr_module.c:522]: load_module(): load_module: module file not found </usr/local/lib/kamailio/modules_k/xlog/xlog.so> 0(20266) DEBUG: <core> [sr_module.c:564]: load_module(): load_module: trying to load </usr/lib64/kamailio/modules/xlog.so> 0(20266) DEBUG: <core> [sr_module.c:343]: register_module(): register PV from: xlog 0(20266) DEBUG: <core> [sr_module.c:674]: find_mod_export_record(): find_export_record: found <xlog> in module xlog [/usr/lib64/kamailio/modules/xlog.so] 0(20266) DEBUG: <core> [sr_module.c:674]: find_mod_export_record(): find_export_record: found <xlog> in module xlog [/usr/lib64/kamailio/modules/xlog.so] 0(20266) DEBUG: <core> [sr_module.c:674]: find_mod_export_record(): find_export_record: found <xlog> in module xlog [/usr/lib64/kamailio/modules/xlog.so] 0(20266) DEBUG: <core> [sr_module.c:674]: find_mod_export_record(): find_export_record: found <xlog> in module xlog [/usr/lib64/kamailio/modules/xlog.so] 0(20266) DEBUG: <core> [sr_module.c:674]: find_mod_export_record(): find_export_record: found <xlog> in module xlog [/usr/lib64/kamailio/modules/xlog.so] 0(20266) DEBUG: <core> [sr_module.c:674]: find_mod_export_record(): find_export_record: found <xlog> in module xlog [/usr/lib64/kamailio/modules/xlog.so] 0(20266) DEBUG: <core> [sr_module.c:674]: find_mod_export_record(): find_export_record: found <xdbg> in module xlog [/usr/lib64/kamailio/modules/xlog.so] 0(20266) DEBUG: <core> [sr_module.c:674]: find_mod_export_record(): find_export_record: found <xdbg> in module xlog [/usr/lib64/kamailio/modules/xlog.so] 0(20268) DEBUG: <core> [sr_module.c:935]: init_mod(): DEBUG: init_mod: xlog 0(20268) DEBUG: <core> [route.c:928]: fix_actions(): fixing xlog() 0(20268) DEBUG: <core> [route.c:928]: fix_actions(): fixing xlog() 0(20268) DEBUG: <core> [route.c:928]: fix_actions(): fixing xlog() 0(20268) DEBUG: <core> [route.c:928]: fix_actions(): fixing xlog() 0(20268) DEBUG: <core> [route.c:928]: fix_actions(): fixing xlog() 0(20268) DEBUG: <core> [route.c:928]: fix_actions(): fixing xlog() At the beginning of the Main routing block I put: log("~~~~~~~~~~~~route~~~~~~~~~~~~~~~~~~~~\n"); xdbg("~~~~~~~~~ xdbg - route~~~~~~~~~~~~~~~~~~~~\n"); xlog("L_ALERT","~~~~~~~~~ xlog - route~~~~~~~~~~~~~~~~~~~~\n"); But nothing is logging when I send INVITEs Any help? Thanks, Nir

4 3

Kamailio 4.2.4 segfault and crash
by Federico San Martín 21 May '15

21 May '15

Hi all, I just experienced a sudden crash from one of my Kamailio servers. I'm using v4.2.4 built from git repository (branch remotes/origin/4.2). The error logs show this at the time of the crash (I'm using debug=1 on config file) May 15 15:59:53 KAMAILIO-ERS1 kamailio[21162]: CRITICAL: <core> [pass_fd.c:293]: receive_fd(): EOF on 19 May 15 15:59:53 KAMAILIO-ERS1 kamailio[21141]: ALERT: <core> [main.c:784]: handle_sigs(): child process 21149 exited by a signal 11 May 15 15:59:53 KAMAILIO-ERS1 kamailio[21141]: ALERT: <core> [main.c:787]: handle_sigs(): core was not generated May 15 15:59:53 KAMAILIO-ERS1 kernel: [2156637.186585] kamailio[21149]: segfault at 20b6 ip 00000000000020b6 sp 00007ffeb0c2bc88 error 14 in kamailio[400000+3c3000] May 15 15:59:53 KAMAILIO-ERS1 kernel: [2156637.214933] kamailio[21141]: segfault at 2290 ip 0000000000002290 sp 00007ffeb0c2c4d8 error 14 in kamailio[400000+3c3000] The modules I'm using are: loadmodule "mi_fifo.so" loadmodule "db_mysql.so" loadmodule "sqlops.so" loadmodule "tm.so" loadmodule "sl.so" loadmodule "pv.so" loadmodule "xlog.so" loadmodule "maxfwd.so" loadmodule "siputils.so" loadmodule "sanity.so" loadmodule "textops.so" loadmodule "rr.so" loadmodule "statsd.so" Have you noticed this error before? This server has a very simple config, for every invite received, it queries a MySQL database to replace the called number from 3 digits to 8-10 digits (for example 135 is translated to 1152751135) and sends back a 300 Redirect with the new number. Another thing to notice is that this server was working at 3-4% CPU load and when the issue happen it spiked to 53%... Let me know I can provide any other info that could be useful. Thanks! Federico Federico San Martín Ingeniería de Telefonía TeleCentro S.A. Cnel. Apolinario Figueroa 254 Piso 4to CABA - C1414EDF Fijo : +54 11 3977 10 45 Móvil : +54 9 11 5824 3240 e-mail : fsanmartin(a)telecentro.net.ar

2 3

Clear To-tag on '181 Call Is Being Forwarded'
by John Murray 21 May '15

21 May '15

Hello, I am forwarding an incoming call to a destination and on time-out forward to another and them another. I need to send a '181 Call Is Being Forwarded' to my SBC to reset the early media stream when forwarding to the next destiation which I can do with sl_send_reply("181","Call Is Being Forwarded"). However the SBC vendor requires that the To-tag in the 181 is cleared for this to work. How can I clear the To-tag from this 181 response? Thanks John

2 1

setup dbtext issues
by jaflong jaflong 21 May '15

21 May '15

I need some instructions on how to setup dbtext properly I generated dbtext files through "./kamdbctl create" I then add user through "./kamctrl add user1 user1" It seems to have added the user because when I do the show './kamctl show user1' command it displays [1, ' user1', '10.1.1.1', ' user1', '', 'ee2820706921ce44a3f760e03ff19a22', '9e2c9e7df27f474d2b995c7e94ab32f2', ''] However viewing the subscriber file /usr/local/etc/kamailio/dbtext/subscriber id(int,auto) username(string) domain(string) password(string) email_address(string,null) ha1(string,null) ha1b(string,null) rpid(string,null) There is no entry for 'user1'. Where is it storing the user data and why is it not in the subscriber file?. user1 is not recognised when trying to register 3(20432) DEBUG: db_text [dbt_api.c:80]: dbt_get_columns(): allocate 16 bytes for RES_NAMES[0] at 0x7f9e0dd776c0 3(20432) DEBUG: auth_db [authorize.c:196]: get_ha1(): no result for user 'user1@' Regards

2 1

Debian package kamailio-tls-modules potential bug ?
by jay binks 20 May '15

20 May '15

I just found something odd in the Debian package for kamailio-als-modules and I'm looking for someone to verify it for me. I verified that I'm using Kamailio 4.2 # Kamailio -v version: kamailio 4.2.0 (x86_64/linux) 36e695 the docs http://kamailio.org/docs/modules/4.2.x/modules/tls.html#tls.p.tls_method show that I should be able to use "*TLSv1+" however Kamailio crashes on startup with * [tls_mod.c:287]: mod_init(): Invalid tls_method parameter value I have verified that TLSv1.1 and TLSv1.2 both work, but I can not use TLSv1.1+ or TLSv1+ I also tried TLSv1.0+ ( I found it somewhere on the web ) but this doesn't work either. I used strings against tls.so to see what was available, and this is what I found. strings ~/tls.so | grep TLSv1 TLSv1_client_method TLSv1_server_method TLSv1_method TLSv1_1_client_method TLSv1_1_server_method TLSv1_1_method TLSv1_2_client_method TLSv1_2_server_method TLSv1_2_method TLSv1 TLS method used (TLSv1, SSLv3, SSLv2, SSLv23) TLSv1.1 TLSv1.2 Any idea why this is differs from the docs, or what I'm doing wrong ? -- Sincerely Jay

2 1

Kamailio v4.2.5 Released
by Daniel-Constantin Mierla 19 May '15

19 May '15

Hello, Kamailio SIP Server v4.2.5 stable release is out. This is a maintenance release of the latest stable branch, 4.2, that includes fixes since release of v4.2.5. There is no change to database schema or configuration language structure that you have to do on installations of v4.2.x. Deployments running previous v4.x.x versions are strongly recommended to be upgraded to v4.2.5. For more details about version 4.2.5 (including links and guidelines to download the tarball or from GIT repository), visit: * http://www.kamailio.org/w/2015/05/kamailio-v4-2-5-released/ RPM, Debian/Ubuntu packages will be available soon as well. Cheers, Daniel -- Daniel-Constantin Mierla http://twitter.com/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015 Berlin, Germany - http://www.kamailioworld.com

2 1

log_prefix not working in reply_route
by Klaus Darilion 19 May '15

19 May '15

Hi! Should log_prefix also work for xlog in reply routes? In my case it doesn't (Kamailio 4.2.2) Thanks Klaus

2 3

rtpproxy-ng and late SDP
by Sebastian Damm 19 May '15

19 May '15

Hi, I'm working on a setup, where I have to support late SDP. It is working right now, but I have to use an explicit rtpproxy_offer() when processing the reply to an INVITE without SDP. Is there a way to have rtpproxy_manage() handle those calls automatically? I was thinking of setting a flag in the request which is used by the rtpproxy_manage() function later. Best Regards, Sebastian

3 3

SIP Packet identifier
by jay binks 19 May '15

19 May '15

So im logging lots of information to Syslog to assist our helpdesk in diagnosing customer issues. Im seeing LOTS of user agents that re-use the sip Call-ID ( especially in registers ). What im wanting to be able to do is link a log message ( that I log at some point in my dialplan ) to a specific SIP packet ( viewed from voipmonitor, HOMER, wireshark ). I cant REALLY see anything in the SIP to uniquely identify a packet, however if kamailio provided the UDP packet checksum in a pseudo variable then we could combine that with the sip call-id to hopefully do what im after. does anyone else have any ideas about how do what im after ? -- Sincerely Jay

4 3

Planning to release Kamailio v4.2.5
by Daniel-Constantin Mierla 19 May '15

19 May '15

Hello, I am considering to release a new maintenance version from latest stable branch - to be v4.2.5 - next week, most likely on Tuesday (May 19) or Wednesday (May 20). If there is anything important to get in and not discussed yet, bring the topic on development mailing list. Cheers, Daniel -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015 Berlin, Germany - http://www.kamailioworld.com

1 1

NO VOICE AFTER MSILO
by sscc 19 May '15

19 May '15

i have configured msilo module successful but there isn't any voice with msilo. i debug and compare the call flow with and without msilo. with msilo in call flow it didn't follow to relay and consequently didnt activate rtpproxy befor the call is answered. due to which during call there isn't any voice. please help -- View this message in context: http://sip-router.1086192.n5.nabble.com/NO-VOICE-AFTER-MSILO-tp137430.html Sent from the Users mailing list archive at Nabble.com.

3 8

sems-rtpengine-webrtc client audio problem
by Juha Heinanen 19 May '15

19 May '15

i have not been able to figure out, why i can't hear any audio when i call from webrtc client (using UDP/TLS/RTP/SAVPF profile) to sems echo server (using RTP/AVP profile): 1) webrtc client - UDP/TLS/RTP/SAVPF - rtpengine - RTP/AVP - sems echo server if i call from the same webrtc client to baresip, audio works fine: 2) webrtc client - UDP/TLS/RTP/SAVPF - rtpengine - RTP/AVP - baresip also, if i call from baresip using UDP/TLS/RTP/SAVPF profile to sems, audio works fine: 3) basesip - UDP/TLS/RTP/SAVPF - rtpengine - RTP/AVP - sems echo server below is level 7 debug from the problem case (1). stats at the bottom tell that audio packets were flowing both ways fine. what does not seem correct is that the webrtc client is constantly sending "Successful STUN binding requests" to rtpengine. any advise for further debugging this problem would be highly appreciated. -- juha ------------------------------------------------------------------------------ May 18 11:47:34 box /usr/bin/sip-proxy[18299]: INFO: ===== rtpengine_offer(ICE=force replace-session-connection replace-origin via-branch=1 rtcp-mux-demux RTP/AVP) May 18 11:47:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u] Received command 'offer' from 127.0.0.1:43378 May 18 11:47:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u] Dump for 'offer' from 127.0.0.1:43378: { "sdp": "v=0#015#012o=- 4880355588178147449 2 IN IP4 127.0.0.1#015#012s=-#015#012t=0 0#015#012a=group:BUNDLE audio#015#012a=msid-semantic: WMS k2qrqNs5yzQcMjup0H0E85yNYAP5aA0w4SeM#015#012m=audio 35551 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 126#015#012c=IN IP4 93.106.207.11#015#012a=rtcp:35551 IN IP4 93.106.207.11#015#012a=candidate:1603072777 1 udp 2122260223 192.168.43.146 35551 typ host generation 0#015#012a=candidate:1603072777 2 udp 2122260223 192.168.43.146 35551 typ host generation 0#015#012a=candidate:2861 ... May 18 11:47:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u] ... 99801 1 tcp 1518280447 192.168.43.146 0 typ host tcptype active generation 0#015#012a=candidate:286199801 2 tcp 1518280447 192.168.43.146 0 typ host tcptype active generation 0#015#012a=candidate:2466368666 1 udp 1686052607 93.106.207.11 35551 typ srflx raddr 192.168.43.146 rport 35551 generation 0#015#012a=candidate:2466368666 2 udp 1686052607 93.106.207.11 35551 typ srflx raddr 192.168.43.146 rport 35551 generation 0#015#012a=ice-ufrag:U+gG6hyUzfrt859a#015#012a=ice-pwd:FQwGMInhUjWl8bbYIbSJS1pz#015#012a=fingerprint:sha-256 09:D6: ... May 18 11:47:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u] ... AA:5B:F2:9E:D6:A7:CE:69:D3:76:67:EF:36:A6:F4:87:94:B7:37:82:AF:17:9E:4B:E8:B7:F4:F1:8C:A0#015#012a=setup:actpass#015#012a=mid:audio#015#012a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level#015#012a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time#015#012a=sendrec… opus/48000/2#015#012a=fmtp:111 minptime=10; useinbandfec=1#015#012a=rtpmap:103 ISAC/16000#015#012a=rtpmap:104 ISAC/32000#015#012a=rtpmap:9 G722/8000#015#012a=rtpmap:0 PCMU/8000#015#012a=rtpmap:8 PCMA/8000#015#012a=rtpmap:106 CN/32000#015#012a=rtpmap:105 CN/16000#015 ... May 18 11:47:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u] ... #012a=rtpmap:13 CN/8000#015#012a=rtpmap:126 telephone-event/8000#015#012a=maxptime:60#015#012a=ssrc:2202238380 cname:zcLA/sUaZsuYHC73#015#012a=ssrc:2202238380 msid:k2qrqNs5yzQcMjup0H0E85yNYAP5aA0w4SeM 2053b0c2-35f2-48f8-ae79-419a078169f4#015#012a=ssrc:2202238380 mslabel:k2qrqNs5yzQcMjup0H0E85yNYAP5aA0w4SeM#015#012a=ssrc:2202238380 label:2053b0c2-35f2-48f8-ae79-419a078169f4#015#012", "ICE": "force", "replace": [ "session-connection", "origin" ], "transport-protocol": "RTP/AVP", "rtcp-mux": [ "demux" ], "call-id": "e91aj9gq39qr07b6dn6u", "vi ... May 18 11:47:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u] ... a-branch": "z9hG4bK1294663", "received-from": [ "IP4", "<sip-proxy-rtpengine-ip>" ], "from-tag": "0m9av72lp5", "command": "offer" } May 18 11:47:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u] Creating new call May 18 11:47:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u] Opened ports 8012..8013 for media relay May 18 11:47:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u] Opened ports 8028..8029 for media relay May 18 11:47:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u] Learning new ICE candidate 1603072777:1 May 18 11:47:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u] Created candidate pair MmPVRTRG3mIW6Esg:1603072777:1 between <sip-proxy-rtpengine-ip> and 192.168.43.146:35551, type host May 18 11:47:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u] Learning new ICE candidate 1603072777:2 May 18 11:47:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u] Learning new ICE candidate 2466368666:1 May 18 11:47:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u] Created candidate pair MmPVRTRG3mIW6Esg:2466368666:1 between <sip-proxy-rtpengine-ip> and 93.106.207.11:35551, type srflx May 18 11:47:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u] Learning new ICE candidate 2466368666:2 May 18 11:47:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u] Sending ICE/STUN request for candidate pair MmPVRTRG3mIW6Esg:1603072777:1 from <sip-proxy-rtpengine-ip> to 192.168.43.146:35551 May 18 11:47:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u] Replying to 'offer' from 127.0.0.1:43378 May 18 11:47:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u] Response dump for 'offer' to 127.0.0.1:43378: { "sdp": "v=0#015#012o=- 4880355588178147449 2 IN IP4 <sip-proxy-rtpengine-ip>#015#012s=-#015#012t=0 0#015#012a=msid-semantic: WMS k2qrqNs5yzQcMjup0H0E85yNYAP5aA0w4SeM#015#012m=audio 8012 RTP/AVP 111 103 104 9 0 8 106 105 13 126#015#012c=IN IP4 <sip-proxy-rtpengine-ip>#015#012a=rtpmap:111 opus/48000/2#015#012a=fmtp:111 minptime=10; useinbandfec=1#015#012a=rtpmap:103 ISAC/16000#015#012a=rtpmap:104 ISAC/32000#015#012a=rtpmap:9 G722/8000#015#012a=rtpmap:0 PCMU/8000#015#012a=rtpmap:8 PCMA/8000#015#012a=rtpmap:106 CN/32000#015#012a=rtpmap:105 CN/16000#015#012a=rtpmap:13 ... May 18 11:47:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u] ... CN/8000#015#012a=rtpmap:126 telephone-event/8000#015#012a=maxptime:60#015#012a=ssrc:2202238380 cname:zcLA/sUaZsuYHC73#015#012a=ssrc:2202238380 msid:k2qrqNs5yzQcMjup0H0E85yNYAP5aA0w4SeM 2053b0c2-35f2-48f8-ae79-419a078169f4#015#012a=ssrc:2202238380 mslabel:k2qrqNs5yzQcMjup0H0E85yNYAP5aA0w4SeM#015#012a=ssrc:2202238380 label:2053b0c2-35f2-48f8-ae79-419a078169f4#015#012a=sendrecv#015#012a=rtcp:8013#015#012a=ice-ufrag:aEaiKI4d#015#012a=ice-pwd:S0ET0fRwnGLZ6lYSdXuAfvCo9K#015#012a=candidate:MmPVRTRG3mIW6Esg 1 UDP 2130706431 <sip-proxy-rtpengine-ip> 8012 typ host#015#012a=candidate:MmP ... May 18 11:47:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u] ... VRTRG3mIW6Esg 2 UDP 2130706430 <sip-proxy-rtpengine-ip> 8013 typ host#015#012", "result": "ok" } May 18 11:47:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u/0m9av72lp5/1] Sending ICE/STUN request for candidate pair MmPVRTRG3mIW6Esg:2466368666:1 from <sip-proxy-rtpengine-ip> to 93.106.207.11:35551 May 18 11:47:34 box /usr/bin/sip-proxy[18242]: INFO: ===== rtpengine_answer(ICE=force via-branch=2 trust-address) May 18 11:47:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u] Received command 'answer' from 127.0.0.1:49396 May 18 11:47:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u] Dump for 'answer' from 127.0.0.1:49396: { "sdp": "v=0#015#012o=sems 1244512444 1372754 IN IP4 <sip-proxy-rtpengine-ip>#015#012s=sems#015#012c=IN IP4 <sip-proxy-rtpengine-ip>#015#012t=0 0#015#012m=audio 8064 RTP/AVP 0 8 126#015#012a=rtpmap:0 PCMU/8000#015#012a=rtpmap:8 PCMA/8000#015#012a=rtpmap:126 telephone-event/8000#015#012a=sendrecv#015#012a=direction:both#015#012", "ICE": "force", "flags": [ "trust-address" ], "call-id": "e91aj9gq39qr07b6dn6u", "via-branch": "z9hG4bK1294663", "received-from": [ "IP4", "127.0.0.1" ], "from-tag": "0m9av72lp5", "to-tag": "627A71DC-5559A726000163C1 ... May 18 11:47:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u] ... -AA759700", "command": "answer" } May 18 11:47:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u] Shutting down ICE agent (nothing to do) May 18 11:47:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u] Replying to 'answer' from 127.0.0.1:49396 May 18 11:47:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u] Response dump for 'answer' to 127.0.0.1:49396: { "sdp": "v=0#015#012o=sems 1244512444 1372754 IN IP4 <sip-proxy-rtpengine-ip>#015#012s=sems#015#012c=IN IP4 <sip-proxy-rtpengine-ip>#015#012t=0 0#015#012m=audio 8028 UDP/TLS/RTP/SAVPF 0 8 126#015#012a=rtpmap:0 PCMU/8000#015#012a=rtpmap:8 PCMA/8000#015#012a=rtpmap:126 telephone-event/8000#015#012a=direction:both#015#012a=sendrecv#015#012a=rtcp:8028#015#012a=rtcp-mux#015#012a=setup:active#015#012a=fingerprint:sha-1 B0:27:8A:76:DE:C4:2A:18:7D:C9:32:F6:78:79:5E:7B:1D:7C:DB:68#015#012a=ice-ufrag:joFSF896#015#012a=ice-pwd:AMtcYr30DYw7PhCsz1LU1Eoi12#015#012a=candidate:MmPVRTRG ... May 18 11:47:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u] ... 3mIW6Esg 1 UDP 2130706431 <sip-proxy-rtpengine-ip> 8028 typ host#015#012", "result": "ok" } May 18 11:47:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8012] SRTP output wanted, but no crypto suite was negotiated May 18 11:47:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u/0m9av72lp5/1] Sending ICE/STUN request for candidate pair MmPVRTRG3mIW6Esg:1603072777:1 from <sip-proxy-rtpengine-ip> to 192.168.43.146:35551 May 18 11:47:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u/0m9av72lp5/1] Sending ICE/STUN request for candidate pair MmPVRTRG3mIW6Esg:2466368666:1 from <sip-proxy-rtpengine-ip> to 93.106.207.11:35551 May 18 11:47:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Triggering check for MmPVRTRG3mIW6Esg:2466368666:1 May 18 11:47:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] ICE pair MmPVRTRG3mIW6Esg:2466368666:1 has been nominated by peer May 18 11:47:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] ICE not completed yet May 18 11:47:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:47:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u/0m9av72lp5/1] Sending ICE/STUN request for candidate pair MmPVRTRG3mIW6Esg:2466368666:1 from <sip-proxy-rtpengine-ip> to 93.106.207.11:35551 May 18 11:47:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Triggering check for MmPVRTRG3mIW6Esg:2466368666:1 May 18 11:47:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:47:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u/0m9av72lp5/1] Sending ICE/STUN request for candidate pair MmPVRTRG3mIW6Esg:2466368666:1 from <sip-proxy-rtpengine-ip> to 93.106.207.11:35551 May 18 11:47:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Received ICE/STUN response code 0 for candidate pair MmPVRTRG3mIW6Esg:2466368666:1 from 93.106.207.11:35551 to <sip-proxy-rtpengine-ip> May 18 11:47:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Setting ICE candidate pair MmPVRTRG3mIW6Esg:2466368666:1 as succeeded May 18 11:47:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Best succeeded ICE pair with all components is MmPVRTRG3mIW6Esg:2466368666:1 May 18 11:47:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] ICE completed, using pair MmPVRTRG3mIW6Esg:2466368666:1 May 18 11:47:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:47:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u/0m9av72lp5/1] Sending ICE/STUN request for candidate pair MmPVRTRG3mIW6Esg:1603072777:1 from <sip-proxy-rtpengine-ip> to 192.168.43.146:35551 May 18 11:47:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Received ICE/STUN response code 0 for candidate pair MmPVRTRG3mIW6Esg:2466368666:1 from 93.106.207.11:35551 to <sip-proxy-rtpengine-ip> May 18 11:47:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] DTLS: Peer certificate accepted May 18 11:47:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] DTLS handshake successful May 18 11:47:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] DTLS-SRTP successfully negotiated May 18 11:47:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] SRTP keys, incoming: May 18 11:47:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] --- AES_CM_128_HMAC_SHA1_32 key jZlg8WlCjfEiFoilpz7BQg== salt gUcb/yOXBOIuNY1ItSw= May 18 11:47:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] SRTP keys, outgoing: May 18 11:47:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] --- AES_CM_128_HMAC_SHA1_32 key e3hQ8pCcc04HD8I7KWdl/g== salt mrNX5VDOk0+Tif2xv5I= May 18 11:47:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] DTLS-SRTP successfully negotiated May 18 11:47:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] SRTP keys, incoming: May 18 11:47:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] --- AES_CM_128_HMAC_SHA1_32 key jZlg8WlCjfEiFoilpz7BQg== salt gUcb/yOXBOIuNY1ItSw= May 18 11:47:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] SRTP keys, outgoing: May 18 11:47:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] --- AES_CM_128_HMAC_SHA1_32 key e3hQ8pCcc04HD8I7KWdl/g== salt mrNX5VDOk0+Tif2xv5I= May 18 11:47:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u/0m9av72lp5/1] Sending ICE/STUN request for candidate pair MmPVRTRG3mIW6Esg:1603072777:1 from <sip-proxy-rtpengine-ip> to 192.168.43.146:35551 May 18 11:47:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:47:35 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:47:35 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u/0m9av72lp5/1] Sending ICE/STUN request for candidate pair MmPVRTRG3mIW6Esg:1603072777:1 from <sip-proxy-rtpengine-ip> to 192.168.43.146:35551 May 18 11:47:35 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:47:36 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:47:36 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:47:37 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u/0m9av72lp5/1] Sending ICE/STUN request for candidate pair MmPVRTRG3mIW6Esg:1603072777:1 from <sip-proxy-rtpengine-ip> to 192.168.43.146:35551 May 18 11:47:37 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:47:37 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:47:38 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8012] Confirmed peer address as <sip-proxy-rtpengine-ip>:8064 May 18 11:47:38 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Confirmed peer address as 93.106.207.11:35551 May 18 11:47:38 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Kernelizing media stream May 18 11:47:38 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8012] Kernelizing media stream May 18 11:47:38 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:47:38 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:47:39 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:47:39 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:47:40 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:47:40 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u/0m9av72lp5/1] Sending ICE/STUN request for candidate pair MmPVRTRG3mIW6Esg:1603072777:1 from <sip-proxy-rtpengine-ip> to 192.168.43.146:35551 May 18 11:47:40 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:47:41 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:47:41 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:47:42 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:47:42 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:47:43 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:47:43 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:47:43 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:47:44 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:47:44 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:47:45 box proxy_monitor[24109]: SIP test succeeded with proxy 192.98.100.34! May 18 11:47:45 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:47:45 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:47:46 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:47:46 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u/0m9av72lp5/1] Sending ICE/STUN request for candidate pair MmPVRTRG3mIW6Esg:1603072777:1 from <sip-proxy-rtpengine-ip> to 192.168.43.146:35551 May 18 11:47:46 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:47:47 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:47:47 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:47:48 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:47:48 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:47:49 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:47:49 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:47:50 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:47:50 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:47:51 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:47:51 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:47:52 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:47:52 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:47:53 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:47:53 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:47:54 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:47:54 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:47:55 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:47:55 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:47:55 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:47:56 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:47:56 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:47:57 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:47:57 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:47:58 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:47:58 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:47:59 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:47:59 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u/0m9av72lp5/1] Sending ICE/STUN request for candidate pair MmPVRTRG3mIW6Esg:1603072777:1 from <sip-proxy-rtpengine-ip> to 192.168.43.146:35551 May 18 11:47:59 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:00 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:00 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:01 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:01 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:02 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:02 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:03 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:03 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:04 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:04 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:05 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:05 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:06 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:06 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:07 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:07 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:07 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:08 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:08 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:09 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:09 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:10 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:10 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:11 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:11 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:12 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:12 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:13 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:13 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:14 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:14 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:15 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:15 box proxy_monitor[24109]: SIP test succeeded with proxy 192.98.100.34! May 18 11:48:15 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:16 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:16 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:17 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:17 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:18 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:18 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:19 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:19 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:20 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:20 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:20 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:21 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:21 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:22 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:22 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:23 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:23 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:24 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:24 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:25 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u/0m9av72lp5/1] Setting ICE candidate pair MmPVRTRG3mIW6Esg:1603072777:1 as failed May 18 11:48:25 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:25 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:26 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:26 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:27 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:27 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:28 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:28 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:29 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:29 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:30 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:30 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:31 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:31 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:32 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:32 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:32 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:33 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:33 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:34 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:35 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:35 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u port 8028] Successful STUN binding request from 93.106.207.11:35551 May 18 11:48:36 box /usr/bin/sip-proxy[18297]: INFO: ===== rtpengine_delete(via-branch=1) May 18 11:48:36 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u] Received command 'delete' from 127.0.0.1:60722 May 18 11:48:36 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u] Dump for 'delete' from 127.0.0.1:60722: { "call-id": "e91aj9gq39qr07b6dn6u", "via-branch": "z9hG4bK3605983", "received-from": [ "IP4", "<sip-proxy-rtpengine-ip>" ], "from-tag": "0m9av72lp5", "command": "delete" } May 18 11:48:36 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u] Scheduling deletion of call branch '0m9av72lp5' in 30 seconds May 18 11:48:36 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u] Replying to 'delete' from 127.0.0.1:60722 May 18 11:48:36 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u] Response dump for 'delete' to 127.0.0.1:60722: { "created": 1431938854, "last signal": 1431938854, "tags": { "0m9av72lp5": { "tag": "0m9av72lp5", "created": 1431938854, "in dialogue with": "627A71DC-5559A726000163C1-AA759700", "medias": [ { "index": 1, "type": "audio", "protocol": "UDP/TLS/RTP/SAVPF", "streams": [ { "local port": 8028, "endpoint": { "family": "IPv4", "address": "93.106.207.11", "port": 35551 }, "advertised endpoint": { "family": "IPv4", "address": "93.106.207.11", "port": 35551 ... May 18 11:48:36 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u] ... }, "crypto suite": "AES_CM_128_HMAC_SHA1_32", "last packet": 1431938916, "flags": [ "RTP", "RTCP", "filled", "confirmed", "kernelized", "DTLS fingerprint verified" ], "stats": { "packets": 3084, "bytes": 540700, "errors": 0 } }, { "local port": 8029, "endpoint": { "family": "IPv6", "address": "::", "port": 0 }, "advertised endpoint": { "family": "IPv6", "address": "::", "port": 0 }, "crypto suite": "AES_CM_128_HMAC_SHA1_32", "last packet": 1431938854, "flags": [ "RTCP", "fallback RTCP", "filled" ... May 18 11:48:36 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u] ... ], "stats": { "packets": 0, "bytes": 0, "errors": 0 } } ], "flags": [ "initialized", "send", "recv", "rtcp-mux", "DTLS-SRTP", "DTLS role active", "ICE" ] } ] }, "627A71DC-5559A726000163C1-AA759700": { "tag": "627A71DC-5559A726000163C1-AA759700", "created": 1431938854, "in dialogue with": "0m9av72lp5", "medias": [ { "index": 1, "type": "audio", "protocol": "RTP/AVP", "streams": [ { "local port": 8012, "endpoint": { "family": "IPv4", "address": "<sip-proxy-rtpengine-ip>", "port": 8064 }, "advertised endpoin ... May 18 11:48:36 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u] ... t": { "family": "IPv4", "address": "<sip-proxy-rtpengine-ip>", "port": 8064 }, "last packet": 1431938916, "flags": [ "RTP", "filled", "confirmed", "kernelized" ], "stats": { "packets": 3095, "bytes": 533040, "errors": 0 } }, { "local port": 8013, "endpoint": { "family": "IPv4", "address": "<sip-proxy-rtpengine-ip>", "port": 8065 }, "advertised endpoint": { "family": "IPv4", "address": "<sip-proxy-rtpengine-ip>", "port": 8065 }, "last packet": 1431938854, "flags": [ "RTCP", "filled" ], "stats": { "packets": 0, "bytes": 0, "error ... May 18 11:48:36 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u] ... s": 0 } } ], "flags": [ "initialized", "send", "recv" ] } ] } }, "totals": { "RTP": { "packets": 6179, "bytes": 1073740, "errors": 0 }, "RTCP": { "packets": 0, "bytes": 0, "errors": 0 } }, "result": "ok" } May 18 11:49:06 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u] Call branch '0m9av72lp5' deleted, no more branches remaining May 18 11:49:06 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u] Final packet stats: May 18 11:49:06 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u] --- Tag '627A71DC-5559A726000163C1-AA759700', created 1:32 ago, in dialogue with '0m9av72lp5' May 18 11:49:06 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u] ------ Media #1 (audio over RTP/AVP) using PCMU/8000 May 18 11:49:06 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u] --------- Port 8012 <> <sip-proxy-rtpengine-ip>:8064 , 3110 p, 535620 b, 0 e, 1431938917 last_packet May 18 11:49:06 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u] --------- Port 8013 <> <sip-proxy-rtpengine-ip>:8065 (RTCP), 0 p, 0 b, 0 e, 1431938854 last_packet May 18 11:49:06 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u] --- Tag '0m9av72lp5', created 1:32 ago, in dialogue with '627A71DC-5559A726000163C1-AA759700' May 18 11:49:06 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u] ------ Media #1 (audio over UDP/TLS/RTP/SAVPF) using PCMU/8000 May 18 11:49:06 box rtpengine[4025]: [e91aj9gq39qr07b6dn6u] --------- Port 8028 <> 93.106.207.11:35551, 3101 p, 543584 b, 0 e, 1431938917 last_packet

1 1

Issue with Asterisk interconnection for VoiceMail
by Igor Potjevlesch 18 May '15

18 May '15

Hello, I experienced a strange issue with some of VoIP accounts. When the INVITE comes into MANAGE_FAILURE, after timeout, the config identifies, with "dialplan", the right Asterisk instance that should handle the call for voicemail. This part is okay, and results in a new INVITE with the Request-URI formed with the right domain (eg. sip: <sip:%3cNUMBER%3e@asterisk3> <NUMBER>@asterisk3). Then, the request goes to RELAY. Here is the issue: sometimes, the request is forwarded to the IP of the UA (the one initially contacted) instead of the IP of Asterisk. I can't figure out the difference between a succeeded call and a failed one. If someone has an idea. Here is the config that handles the VoiceMail: failure_route[MANAGE_FAILURE] { [.] if (isflagset(24)) { $avp(s:inv_timeout) = "5"; t_set_fr($avp(s:inv_timeout)*1000); if (avp_db_load("$to/username","$avp(s:vm_uri)/usr_vm")) { resetflag(24); avp_pushto("$ruri","$avp(s:vm_uri)"); # Dynamic routing if (avp_db_load("$ruri/username","$avp(s:client)/usr_fai")) { if (dp_translate("2","$avp(s:client)/$avp(s:dest)") == 1) { $ru = "sip:" + $rU + "@" + $avp(s:dest); } else { # Load default voicemail $avp(s:client) = "DEFAULT_VM"; dp_translate("2","$avp(s:client)/$avp(s:dest)"); $ru = "sip:" + $rU + "@" + $avp(s:dest); }; } else { # Load default voicemail $avp(s:client) = "DEFAULT_VM"; dp_translate("2","$avp(s:client)/$avp(s:dest)"); $ru = "sip:" + $rU + "@" + $avp(s:dest); } } else { xlog("L_WARN","time=[$Tf] call id=[$ci] call seq=[$cs] contact header=[$ct] from uri=[$fu] from tag=[$ft] request's method=[$rm] request's uri=[$ru] to uri=[$tu] to tag=[$tt] sip message id=[$mi] process id=[$pp] ip source=[$si] flags=[$mf], User have no mail box\n"); exit; }; prefix("710"); xlog("L_WARN","time=[$Tf] call id=[$ci] call seq=[$cs] contact header=[$ct] from uri=[$fu] from tag=[$ft] request's method=[$rm] request's uri=[$ru] to uri=[$tu] to tag=[$tt] sip message id=[$mi] process id=[$pp] ip source=[$si] flags=[$mf], failure route to Voice Mail\n"); route(RELAY); exit; } Regards, Igor.

3 5

dbtext why is my user not recognised
by jaflong jaflong 18 May '15

18 May '15

cat > /usr/local/etc/kamailio/dbtext/subscriber username(str) password(str) ha1(str) domain(str) ha1b(str) user1:user1:xxx:10.1.1.1:xxx 9350) DEBUG: auth_db [authorize.c:498]: auth_check(): realm [10.31.8.1] table [subscriber] flags [1] 2(9350) DEBUG: auth [api.c:96]: pre_auth(): auth: digest-algo: MD5 parsed value: 1 2(9350) DEBUG: db_text [dbt_file.c:102]: dbt_load_file(): request for table [subscriber] 2(9350) DEBUG: db_text [dbt_file.c:109]: dbt_load_file(): db is [/usr/local/etc/kamailio/dbtext] 2(9350) DEBUG: db_text [dbt_file.c:124]: dbt_load_file(): loading file [/usr/local/etc/kamailio/dbtext/subscriber] 2(9350) DEBUG: db_text [dbt_tb.c:187]: dbt_table_new(): mtime is 1431951381 2(9350) DEBUG: db_text [dbt_file.c:480]: dbt_load_file(): error at row=0 col=0 c= 2(9350) ERROR: db_text [dbt_lib.c:307]: dbt_db_get_table(): could not load database from file [subscriber] 2(9350) ERROR: db_text [dbt_base.c:200]: dbt_query(): table subscriber does not exist! 2(9350) ERROR: auth_db [authorize.c:187]: get_ha1(): failed to query database 2(9350) exec: *** cfgtrace:request_route=[AUTH] c=[/usr/local/etc/kamailio/kamailio.cfg] l=498 a=26 n=auth_challenge 2(9350) DEBUG: auth [challenge.c:127]: get_challenge_hf(): build_challenge_hf: realm='10.31.8.1' 2(9350) DEBUG: auth [challenge.c:269]: get_challenge_hf(): auth: 'Proxy-Authenticate: Digest realm="10.31.8.1", nonce="VVnqGlVZ6O4l1T62BGADuI2p8uAnUYeu" regards

1 1

Setting up a presence AS with Kamailio IMS.
by Mihail Dakov 18 May '15

18 May '15

Hi all, I have successfully setup a Kamailio IMS environment using just a single machine running three kamailio instances. I am using kamailio 4.2.4 compiling it myself. I followed this guide: http://nil.uniza.sk/instant-messaging/simple/configuring-im-and-presence-ka… to setup a presence AS using the scscf instance. I used kamdbctl script to create the presence tables with one inconsistence with the guide. I had to create a db in which I created a couple of columns (table_name, table_version) to satisfy the kamdbctl script as it was failing when running "kamdbctl presence". At the moment the problem is that my kamailio instance is failing with the following error: scscf/scscf[5256]: ERROR: <core> [db.c:422]: db_table_version(): invalid type (3) or nul (0) version columns for presentity ... and then some time later: scscf/scscf[5256]: ERROR: <core> [db.c:440]: db_check_table_version(): querying version for table presentity scscf/scscf[5256]: ERROR: presence [presence.c:322]: mod_init(): error during table version check scscf/scscf[5256]: ERROR: <core> [sr_module.c:968]: init_mod(): Error while initializing module presence (/home/ng40/kamailio-4.2.4/modules/presence/presence.so) scscf/scscf[5256]: DEBUG: cdp_avp [mod.c:224]: cdp_avp_destroy(): Destroying module cdp_avp I suspect that the problem relays on creating manually the db where I inserted the two columns mentioned above (table_name, table_version) so that I could execute "kamdbctl presence". Could someone assist me into solving this issue? br, md.

1 0

critical crash with dbtext
by jaflong jaflong 18 May '15

18 May '15

HI When using dbtext setup I receive a CRITICAL error and shut down. This is the debug log. My config settings are described below. Please advise how I should fo the correct dbtext config 9(21196) DEBUG: <core> [sr_module.c:920]: init_mod_child(): DEBUG: init_mod_child (-4): acc 9(21196) DEBUG: <core> [sr_module.c:920]: init_mod_child(): DEBUG: init_mod_child (-4): auth_db 9(21196) DEBUG: <core> [sr_module.c:920]: init_mod_child(): DEBUG: init_mod_child (-4): debugger 9(21196) DEBUG: debugger [debugger_mod.c:179]: child_init(): rank is (-4) 9(21196) DEBUG: <core> [local_timer.c:74]: init_local_timer(): init_local_timer: timer_list between 0x9e7268 and 0xa2b268 9(21196) DEBUG: <core> [io_wait.h:388]: io_watch_add(): DBG: io_watch_add(0x9e70a0, 8, 4, 0x7f5aaa402364), fd_no=0 9(21196) DEBUG: <core> [io_wait.h:388]: io_watch_add(): DBG: io_watch_add(0x9e70a0, 9, 4, 0x7f5aaa4023f0), fd_no=1 9(21196) DEBUG: <core> [io_wait.h:388]: io_watch_add(): DBG: io_watch_add(0x9e70a0, 10, 4, 0x7f5aaa40247c), fd_no=2 9(21196) DEBUG: <core> [io_wait.h:388]: io_watch_add(): DBG: io_watch_add(0x9e70a0, 11, 4, 0x7f5aaa402508), fd_no=3 9(21196) DEBUG: <core> [io_wait.h:388]: io_watch_add(): DBG: io_watch_add(0x9e70a0, 12, 4, 0x7f5aaa402594), fd_no=4 9(21196) DEBUG: <core> [io_wait.h:388]: io_watch_add(): DBG: io_watch_add(0x9e70a0, 13, 4, 0x7f5aaa402620), fd_no=5 9(21196) DEBUG: <core> [io_wait.h:388]: io_watch_add(): DBG: io_watch_add(0x9e70a0, 14, 4, 0x7f5aaa4026ac), fd_no=6 9(21196) DEBUG: <core> [io_wait.h:388]: io_watch_add(): DBG: io_watch_add(0x9e70a0, 15, 4, 0x7f5aaa402738), fd_no=7 9(21196) CRITICAL: <core> [pass_fd.c:293]: receive_fd(): EOF on 8 9(21196) DEBUG: <core> [tcp_main.c:3537]: handle_ser_child(): DBG: handle_ser_child: dead child 1, pid 21188 (shutting down?) 9(21196) DEBUG: <core> [io_wait.h:610]: io_watch_del(): DBG: io_watch_del (0x9e70a0, 8, -1, 0x0) fd_no=8 called 9(21196) CRITICAL: <core> [pass_fd.c:293]: receive_fd(): EOF on 9 9(21196) DEBUG: <core> [tcp_main.c:3537]: handle_ser_child(): DBG: handle_ser_child: dead child 2, pid 21189 (shutting down?) 9(21196) DEBUG: <core> [io_wait.h:610]: io_watch_del(): DBG: io_watch_del (0x9e70a0, 9, -1, 0x0) fd_no=7 called 9(21196) CRITICAL: <core> [pass_fd.c:293]: receive_fd(): EOF on 10 9(21196) DEBUG: <core> [tcp_main.c:3537]: handle_ser_child(): DBG: handle_ser_child: dead child 3, pid 21190 (shutting down?) 9(21196) DEBUG: <core> [io_wait.h:610]: io_watch_del(): DBG: io_watch_del (0x9e70a0, 10, -1, 0x0) fd_no=6 called 9(21196) CRITICAL: <core> [pass_fd.c:293]: receive_fd(): EOF on 11 9(21196) DEBUG: <core> [tcp_main.c:3537]: handle_ser_child(): DBG: handle_ser_child: dead child 4, pid 21191 (shutting down?) 9(21196) DEBUG: <core> [io_wait.h:610]: io_watch_del(): DBG: io_watch_del (0x9e70a0, 11, -1, 0x0) fd_no=5 called 9(21196) CRITICAL: <core> [pass_fd.c:293]: receive_fd(): EOF on 12 9(21196) DEBUG: <core> [tcp_main.c:3537]: handle_ser_child(): DBG: handle_ser_child: dead child 5, pid 21192 (shutting down?) 9(21196) DEBUG: <core> [io_wait.h:610]: io_watch_del(): DBG: io_watch_del (0x9e70a0, 12, -1, 0x0) fd_no=4 called 9(21196) CRITICAL: <core> [pass_fd.c:293]: receive_fd(): EOF on 13 9(21196) DEBUG: <core> [tcp_main.c:3537]: handle_ser_child(): DBG: handle_ser_child: dead child 6, pid 21193 (shutting down?) 9(21196) DEBUG: <core> [io_wait.h:610]: io_watch_del(): DBG: io_watch_del (0x9e70a0, 13, -1, 0x0) fd_no=3 called 8(21195) INFO: db_text [dbt_base.c:99]: dbt_init(): using database at: /usr/local/etc/kamailio/dbtext 8(21195) DEBUG: db_text [dbt_lib.c:129]: dbt_cache_get_db(): looking for db /usr/local/etc/kamailio/dbtext! 8(21195) DEBUG: db_text [dbt_lib.c:139]: dbt_cache_get_db(): db already cached! 8(21195) DEBUG: <core> [sruid.c:101]: sruid_init(): root for sruid is [ulcx-5555c137-52cb-] (0 / 19) 8(21195) DEBUG: <core> [sr_module.c:920]: init_mod_child(): DEBUG: init_mod_child (-2): acc 8(21195) DEBUG: <core> [sr_module.c:920]: init_mod_child(): DEBUG: init_mod_child (-2): auth_db 8(21195) INFO: db_text [dbt_base.c:99]: dbt_init(): using database at: /usr/local/etc/kamailio/dbtext 8(21195) DEBUG: db_text [dbt_lib.c:129]: dbt_cache_get_db(): looking for db /usr/local/etc/kamailio/dbtext! 8(21195) DEBUG: db_text [dbt_lib.c:139]: dbt_cache_get_db(): db already cached! 8(21195) DEBUG: <core> [sr_module.c:920]: init_mod_child(): DEBUG: init_mod_child (-2): debugger 8(21195) DEBUG: debugger [debugger_mod.c:179]: child_init(): rank is (-2) 8(21195) DEBUG: ctl [ctl.c:325]: mod_child(): ctl: mod_child(0), fork_process=0, csl=0x2682080 8(21195) DEBUG: ctl [ctl.c:332]: mod_child(): ctl: 0 io_listen_loop(1, 0x2682080) 8(21195) INFO: ctl [io_listener.c:225]: io_listen_loop(): io_listen_loop: using epoll_lt io watch method (config) 8(21195) DEBUG: ctl [io_listener.c:257]: io_listen_loop(): io_listen_loop: adding socket 4, type 2, transport 3 (/tmp/kamailio_ctl) 8(21195) DEBUG: ctl [../../io_wait.h:388]: io_watch_add(): DBG: io_watch_add(0x7f5aaf2a36c0, 4, 2, 0x2682080), fd_no=0 --------------------------------------------- cd /usr/local/etc/kamailio mkdir dbtext cd dbtext --------------------------------------------- cat > /usr/local/etc/kamailio/dbtext/version table_name(str) table_version(int) subscriber:6 location:6 aliases:6 --------------------------------------------- cat > /usr/local/etc/kamailio/dbtext/location username(str) contact(str) expires(int) q(double) callid(str) cseq(int) --------------------------------------------- cat > /usr/local/etc/kamailio/dbtext/subscriber username(str) password(str) ha1(str) domain(str) ha1b(str) testuser:testuser:xxx:10.1.1.5:xxx --------------------------------------------- #!define DBURL "text:///usr/local/etc/kamailio/dbtext" #!endif --------------------------------------------- # ----- usrloc params ----- /* enable DB persistency for location entries */ #!ifdef WITH_USRLOCDB modparam("usrloc", "db_url", DBURL) modparam("usrloc", "db_mode", 2) modparam("usrloc", "use_domain", MULTIDOMAIN) #!endif # ----- auth_db params ----- #!ifdef WITH_AUTH modparam("auth_db", "db_url", DBURL) modparam("auth_db", "calculate_ha1", yes) modparam("auth_db", "password_column", "password") modparam("auth_db", "load_credentials", "") modparam("auth_db", "use_domain", MULTIDOMAIN) ---------------------------------------------

2 3

Repeated 200 OK from Enswitch
by Darren Campbell (Primar) 18 May '15

18 May '15

Hi all Experiencing a commonly reported issue where calls drop out after 30 seconds or so. Mainly because the provider hangs up after not recognising/receiving ACK in response to 200 OK. Unfortunately (or maybe fortunately), I haven't had much experience with Enswitch so was hoping someone in the community might help guide me as to which rules Enswitch might be using to match ACKs to calls in progress. Maybe there is another avenue I should be investigating. Here's a sample of the 200 OK and ACK that repeats. 13:44:04.155646 IP PROVIDERIP.5060 > 172.21.0.226.5060: SIP, length: 1058 E..>.M..?..Ug.v..........*J.SIP/2.0 200 OK^M Via: SIP/2.0/UDP 172.21.0.226;rport=5060;branch=z9hG4bKfe94.efbf7fbcaf8bd15243a61fdc9d6d1e78.0^M Via: SIP/2.0/UDP 127.0.0.1:5080;branch=z9hG4bK65f00a0c;rport=5080^M Record-Route: <sip:PROVIDERIP;lr=on>^M Record-Route: <sip:172.21.0.226;r2=on;lr=on;ftag=as65919d92;nat=yes>^M Record-Route: <sip:127.0.0.1;r2=on;lr=on;ftag=as65919d92;nat=yes>^M From: "asterisk" <sip:PROVIDERUSER@PROVIDERIP:5080>;tag=as65919d92^M To: <sip:PHONENUMBER@PROVIDERIP>;tag=as260fefaa^M Call-ID: 271ac7a174d613cd0b94504353733a2c@PROVIDERIP^M CSeq: 103 INVITE^M Server: Enswitch^M Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH^M Supported: replaces^M Contact: <sip:PHONENUMBER@PROVIDERMEDIAIP:5060>^M Content-Type: application/sdp^M Content-Length: 286^M ^M v=0^M o=root 2110894460 2110894461 IN IP4 PROVIDERMEDIAIP^M s=Asterisk PBX 11.3.0^M c=IN IP4 PROVIDERMEDIAIP^M t=0 0^M m=audio 15594 RTP/AVP 0 8 3 101^M a=rtpmap:0 PCMU/8000^M a=rtpmap:8 PCMA/8000^M a=rtpmap:3 GSM/8000^M a=rtpmap:101 telephone-event/8000^M a=fmtp:101 0-16^M a=ptime:20^M a=sendrecv^M 13:44:04.164519 IP 172.21.0.226.5060 > PROVIDERIP.5060: SIP, length: 525 E..)!A..@..v....g.v.......T.ACK sip:PHONENUMBER@PROVIDERIP:5060 SIP/2.0^M Via: SIP/2.0/UDP 172.21.0.226;branch=z9hG4bKfe94.472e9fc0479de79b4f176cc9585d8880.0^M Via: SIP/2.0/UDP 127.0.0.1:5080;branch=z9hG4bK752b5264;rport=5080^M Route: <sip:PROVIDERIP;lr=on>^M Max-Forwards: 69^M From: "asterisk" <sip:PROVIDERUSER@PROVIDERIP:5080>;tag=as65919d92^M To: <sip:PHONENUMBER@PROVIDERIP>;tag=as260fefaa^M Contact: <sip:PROVIDERUSER@127.0.0.1:5080>^M Call-ID: 271ac7a174d613cd0b94504353733a2c@PROVIDERIP^M CSeq: 103 ACK^M User-Agent: Elastix 3.0^M Content-Length: 0^M

2 8

RADIUS Digest Problem
by Sanaii, Maziar 18 May '15

18 May '15

Hello there, I'm trying to configure Kamailio 4.2.4 to authenticate client REGISTERs against a test FreeRADIUS on the localhost, however I have yet to succeed. My installation includes Kamailio 4.2.4, radiusclient 1.1.6, FreeRADIUS 2.2.5 and all of them on a Debian 8.0 machine. I believe I have got all the configurations correct in kamailio.cfg, radiusclient.conf, radius servers file, and freeradius server since the communication between the components are ok. My problem is that when I use a SIP Client such as 3CX SoftPhone, FreeRADIUS gives me an answer included in SIPClient-LOCAL-RADIUS-NOK.txt. I have isolated the problem being in the Digest-Response part since I have ran some other tests that I have included in the zip file attached, but can't figure out why this shouldn't work. From what I have figured out, my SIP Client does not calculate the correct Digest-Response and I have seen this in all the clients I have tested so far. For example, my client sends "5f8dfe8aa4e13994b4ceade49ee0d3d4" although it's supposed to send "528f22527e9cf003df29ede9c243e615". I would really appreciate if you would point out what I did wrong in setting things up. I have done so much googling but have not found anything useful. Regards, Maziar Sanaii Ashtiani

2 1

XLOG To STDERR Not Working
by Nahum Nir 18 May '15

18 May '15

Hi All, I am using Kamailio 4.0.3 and can't logs. .cfg: #!define WITH_DEBUG ### LOG Levels: 3=DBG, 2=INFO, 1=NOTICE, 0=WARN, -1=ERR #!ifdef WITH_DEBUG debug=4 log_stderror=yes #!else debug=2 log_stderror=no #!endif memdbg=5 memlog=5 log_facility=LOG_LOCAL0 When the server starts there outputs about xlog: 0(20266) DEBUG: <core> [cfg.y:1791]: yyparse(): loading module xlog.so 0(20266) DEBUG: <core> [sr_module.c:499]: load_module(): load_module: module file not found </usr/local/lib/kamailio/modules_k/xlog.so> 0(20266) DEBUG: <core> [sr_module.c:522]: load_module(): load_module: module file not found </usr/local/lib/kamailio/modules_k/xlog/xlog.so> 0(20266) DEBUG: <core> [sr_module.c:564]: load_module(): load_module: trying to load </usr/lib64/kamailio/modules/xlog.so> 0(20266) DEBUG: <core> [sr_module.c:343]: register_module(): register PV from: xlog 0(20266) DEBUG: <core> [sr_module.c:674]: find_mod_export_record(): find_export_record: found <xlog> in module xlog [/usr/lib64/kamailio/modules/xlog.so] 0(20266) DEBUG: <core> [sr_module.c:674]: find_mod_export_record(): find_export_record: found <xlog> in module xlog [/usr/lib64/kamailio/modules/xlog.so] 0(20266) DEBUG: <core> [sr_module.c:674]: find_mod_export_record(): find_export_record: found <xlog> in module xlog [/usr/lib64/kamailio/modules/xlog.so] 0(20266) DEBUG: <core> [sr_module.c:674]: find_mod_export_record(): find_export_record: found <xlog> in module xlog [/usr/lib64/kamailio/modules/xlog.so] 0(20266) DEBUG: <core> [sr_module.c:674]: find_mod_export_record(): find_export_record: found <xlog> in module xlog [/usr/lib64/kamailio/modules/xlog.so] 0(20266) DEBUG: <core> [sr_module.c:674]: find_mod_export_record(): find_export_record: found <xlog> in module xlog [/usr/lib64/kamailio/modules/xlog.so] 0(20266) DEBUG: <core> [sr_module.c:674]: find_mod_export_record(): find_export_record: found <xdbg> in module xlog [/usr/lib64/kamailio/modules/xlog.so] 0(20266) DEBUG: <core> [sr_module.c:674]: find_mod_export_record(): find_export_record: found <xdbg> in module xlog [/usr/lib64/kamailio/modules/xlog.so] 0(20268) DEBUG: <core> [sr_module.c:935]: init_mod(): DEBUG: init_mod: xlog 0(20268) DEBUG: <core> [route.c:928]: fix_actions(): fixing xlog() 0(20268) DEBUG: <core> [route.c:928]: fix_actions(): fixing xlog() 0(20268) DEBUG: <core> [route.c:928]: fix_actions(): fixing xlog() 0(20268) DEBUG: <core> [route.c:928]: fix_actions(): fixing xlog() 0(20268) DEBUG: <core> [route.c:928]: fix_actions(): fixing xlog() 0(20268) DEBUG: <core> [route.c:928]: fix_actions(): fixing xlog() At the beginning of the Main routing block I put: log("~~~~~~~~~~~~route~~~~~~~~~~~~~~~~~~~~\n"); xdbg("~~~~~~~~~ xdbg - route~~~~~~~~~~~~~~~~~~~~\n"); xlog("L_ALERT","~~~~~~~~~ xlog - route~~~~~~~~~~~~~~~~~~~~\n"); But nothing is logging when I send INVITEs Any help? Thanks, Nir

2 1

How to Change IP on Kamailio
by Mudasar Choudhary 18 May '15

18 May '15

Hi, Hope you are doing fine. Can you please assist me how can I change the IP for Kamailio. Right now its up on this IP: loading modules under /usr/lib/kamailio/modulesListing onudp: 98.212.180.96 [98.212.180.96] :5060tcp: 192.168.18.99 [192.168.18.99] :8888 I want to change both upd and tcp. Please advise. ThanksMudasar

2 1

Kamailio Load balancing multiple asterisk boxes
by Eric Koome 15 May '15

15 May '15

Hi I have two boxes with internal and external interfaces. Each has Kamailio at the public interface and asterisk on the internal one. Making calls within a box is fine but would like to load balance using the other asterisk box. However using dispatcher I have noticed packets are not being routed from Kamailo to the second asterisk. Packets from Kamailo are originating from the external interface and sent to the second asterisk box using private ip address. Off course this is not routable. I have tried masquerading but no joy. Do I need to change kamailio configuration? I want to have a set of asterisk boxes behind Kamailio using dispatcher. I'm I missing a trick? Eric

2 1

misc_radius and auth_radius configuration question
by Yasin CANER 15 May '15

15 May '15

Hello; i am testing to radius modules. i have found this tutorial http://www.kamailio.org/docs/openser-radius-1.0.x.html . it is old but i changed some variables. i configured radiusclient-ng and free radius. But kamailio cann't start because of 0(17813) ERROR: misc_radius [misc_radius.c:208]: mod_init(): misc_radius: can't get code for the SIP-AVP attribute 0(17813) ERROR: <core> [sr_module.c:968]: init_mod(): Error while initializing module misc_radius (/usr/local/lib64/kamailio/modules/misc_radius.so) i already defined SIP-AVP in dictionary.kamailio. And when i set radius_config in misc_radius , it try to find in default path (/usr/local/etc/radiusclient-ng). So i linked to path /usr/local/etc/radiusclient-ng to solve this problem. ---- kamailio V 4.2.4 ---- ------------------dictionary.kamailio------------ #### Attributes ### ATTRIBUTE Sip-Method 101 integer # Schulzrinne, acc ATTRIBUTE Sip-Response-Code 102 integer # Schulzrinne, acc ATTRIBUTE Sip-Cseq 103 string # Schulzrinne, acc ATTRIBUTE Sip-To-Tag 104 string # Schulzrinne, acc ATTRIBUTE Sip-From-Tag 105 string # Schulzrinne, acc ATTRIBUTE Sip-Translated-Request-URI 107 string # Proprietary, acc ATTRIBUTE Sip-Src-IP 108 string # Proprietary, acc ATTRIBUTE Sip-Src-Port 109 string # Proprietary, acc ATTRIBUTE Digest-Response 206 string # Sterman, auth_radius ATTRIBUTE Sip-Uri-User 208 string # Proprietary, auth_radius ATTRIBUTE Sip-Group 211 string # Proprietary, group_radius ATTRIBUTE Sip-Rpid 213 string # Proprietary, auth_radius ATTRIBUTE SIP-AVP 225 string # Proprietary, avp_radius ATTRIBUTE Digest-Realm 1063 string # Sterman, auth_radius ATTRIBUTE Digest-Nonce 1064 string # Sterman, auth_radius ATTRIBUTE Digest-Method 1065 string # Sterman, auth_radius ATTRIBUTE Digest-URI 1066 string # Sterman, auth_radius ATTRIBUTE Digest-QOP 1067 string # Sterman, auth_radius ATTRIBUTE Digest-Algorithm 1068 string # Sterman, auth_radius ATTRIBUTE Digest-Body-Digest 1069 string # Sterman, auth_radius ATTRIBUTE Digest-CNonce 1070 string # Sterman, auth_radius ATTRIBUTE Digest-Nonce-Count 1071 string # Sterman, auth_radius ATTRIBUTE Digest-User-Name 1072 string # Sterman, auth_radius ### Acct-Status-Type Values ### #VALUE Acct-Status-Type Start 1 # RFC2866, acc #VALUE Acct-Status-Type Stop 2 # RFC2866, acc #VALUE Acct-Status-Type Failed 15 # RFC2866, acc ### Service-Type Values ### #VALUE Service-Type Call-Check 10 # RFC2865, uri_radius VALUE Service-Type Group-Check 12 # Proprietary, group_radius ##VALUE Service-Type Sip-Session 15 # Schulzrinne, acc, auth_radius VALUE Service-Type SIP-Caller-AVPs 30 # Proprietary, avp_radius VALUE Service-Type SIP-Callee-AVPs 31 # Proprietary, avp_radius ### Sip-Method Values ### VALUE Sip-Method Undefined 0 VALUE Sip-Method Invite 1 VALUE Sip-Method Cancel 2 VALUE Sip-Method Ack 4 VALUE Sip-Method Bye 8 VALUE Sip-Method Info 16 VALUE Sip-Method Options 32 VALUE Sip-Method Update 64 VALUE Sip-Method Register 128 VALUE Sip-Method Message 256 VALUE Sip-Method Subscribe 512 VALUE Sip-Method Notify 1024 VALUE Sip-Method Prack 2048 VALUE Sip-Method Refer 4096 VALUE Sip-Method Other 8192 ---------------------------Kamailio.cfg-------------------------------------------------------- #modparam("acc", "log_flag", FLT_ACC) modparam("acc_radius", "radius_extra", "Sip-Src-IP=$si;Sip-Src-Port=$sp") modparam("acc_radius", "radius_config","/etc/radiusclient-ng/radiusclient.conf") modparam("acc_radius", "radius_flag", FLT_ACC) modparam("acc_radius", "radius_missed_flag", FLT_ACCMISSED) modparam("acc_radius", "service_type", 15) modparam("misc_radius", "radius_config", "/etc/radiusclient-ng/radiusclient.conf") modparam("misc_radius", "group_service_type", 12) modparam("misc_radius", "uri_service_type", 10) modparam("misc_radius", "caller_extra", "Calling-Station-Id=$fu") modparam("misc_radius", "callee_extra", "SIP-URI-User=$rU;SIP-URI-Host=$rd") modparam("misc_radius", "group_extra", "My-Special=$avp(i:100)") modparam("misc_radius", "uri_extra", "Called-Station-Id=$tu") ------------------------------------------------------------------------------------------------ Thanks

3 6

t_lookup_request()
by Alex Balashov 13 May '15

13 May '15

Hello, From the documentation for t_lookup_request()[1], it is not clear whether it creates a new transaction if one does not exist: "Checks if a transaction exists. Returns a positive value if so, negative otherwise. Most likely you will not want to use it, as a typical application of a look-up is to introduce a new transaction if none was found. However this is safely (atomically) done using t_newtran." This language is quite unclear in the following respects: 1) Why would I not want to use it? 2) Does the "typical application" mean that t_lookup_request() _will_ create a new transaction if one does not exist? 3) Do I have some means of choosing whether to invoke t_lookup_request() in a "typical" or "atypical" application? 4) This statement "this is safely (atomically) done using t_newtran" implies that creating a new transaction using t_lookup_request() (which also implies that yes, it does create a new transaction) is "unsafe" and "non-atomic". Why is this? 5) Does this mean that the effect here would be to create two transactions? if(!t_lookup_request()) t_newtran(); -- Alex [1] http://kamailio.org/docs/modules/4.2.x/modules/tm.html#tm.f.t_lookup_request -- 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/

2 1

how to delete key from htable?
by Juha Heinanen 13 May '15

13 May '15

there exists rpc command htable.delete that can be used to delete a key from htable. is there a way to delete a key in the config file like assigning $null to it or do i need to use sht_rm_name_re function that feels like an overkill? -- juha

2 4

Kamailio-4.1.5 memory leak
by Bui Minh Yen 13 May '15

13 May '15

Hi everyone, I am using Kamailio-4.1.5. Sometime kamailio was crash because memory leak. Log when out of mem May 2 09:49:00 vnpsip01 /usr/local/sbin/kamailio[30821]: ERROR: tm [t_lookup.c:1472]: t_newtran(): ERROR: t_newtran: new_t failed May 2 09:49:00 vnpsip01 /usr/local/sbin/kamailio[30821]: ERROR: tm [t_lookup.c:1332]: new_t(): ERROR: new_t: out of mem: May 2 09:49:00 vnpsip01 /usr/local/sbin/kamailio[30821]: ERROR: tm [t_lookup.c:1472]: t_newtran(): ERROR: t_newtran: new_t failed May 2 09:49:00 vnpsip01 /usr/local/sbin/kamailio[30821]: ERROR: usrloc [ucontact.c:103]: new_ucontact(): no more shm memory May 2 09:49:00 vnpsip01 /usr/local/sbin/kamailio[30821]: ERROR: usrloc [urecord.c:155]: mem_insert_ucontact(): failed to create new contact May 2 09:49:00 vnpsip01 /usr/local/sbin/kamailio[30821]: ERROR: usrloc [urecord.c:547]: insert_ucontact(): failed to insert contact May 2 09:49:00 vnpsip01 /usr/local/sbin/kamailio[30821]: ERROR: registrar [save.c:708]: update_contacts(): failed to insert contact May 2 09:49:00 vnpsip01 /usr/local/sbin/kamailio[30821]: ERROR: tm [t_lookup.c:1332]: new_t(): ERROR: new_t: out of mem: May 2 09:49:00 vnpsip01 /usr/local/sbin/kamailio[30821]: ERROR: tm [t_lookup.c:1472]: t_newtran(): ERROR: t_newtran: new_t failed May 2 09:49:00 vnpsip01 /usr/local/sbin/kamailio[30821]: ERROR: usrloc [ucontact.c:103]: new_ucontact(): no more shm memory May 2 09:49:00 vnpsip01 /usr/local/sbin/kamailio[30821]: ERROR: usrloc [urecord.c:155]: mem_insert_ucontact(): failed to create new contact May 2 09:49:00 vnpsip01 /usr/local/sbin/kamailio[30821]: ERROR: usrloc [urecord.c:547]: insert_ucontact(): failed to insert contact May 2 09:49:00 vnpsip01 /usr/local/sbin/kamailio[30821]: ERROR: registrar [save.c:521]: insert_contacts(): failed to insert contact Log when kamailio was crash May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30818]: ALERT: <core> [main.c:775]: handle_sigs(): child process 30821 exited by a signal 11 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30818]: ALERT: <core> [main.c:778]: handle_sigs(): core was not generated May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30818]: INFO: <core> [main.c:790]: handle_sigs(): INFO: terminating due to SIGCHLD May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: INFO: <core> [main.c:841]: sig_usr(): INFO: signal 15 received May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: <core> [main.c:852]: sig_usr(): Memory status (pkg): May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: (0x7f6af5968010): May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: heap size= 749731840 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: used= 1110960, used+overhead=1663384, free=748068456 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: max used (+overhead)= 1825240 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: dumping all alloc'ed. fragments: May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: 0. N address=0x7f6af599d528 frag=0x7f6af599d4f8 size=1024 used=1 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: alloc'd from <core>: str_hash.h: str_hash_alloc(69) May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: start check=f0f0f0f0, end check= c0c0c0c0, abcdefed May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: 1. N address=0x7f6af599d988 frag=0x7f6af599d958 size=256 used=1 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30828]: INFO: <core> [main.c:841]: sig_usr(): INFO: signal 15 received May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: alloc'd from <core>: str_hash.h: str_hash_alloc(69) May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: start check=f0f0f0f0, end check= c0c0c0c0, abcdefed May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: 2. N address=0x7f6af599dae8 frag=0x7f6af599dab8 size=176 used=1 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: alloc'd from <core>: counters.c: cnt_hash_add(339) May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: start check=f0f0f0f0, end check= c0c0c0c0, abcdefed May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: 3. N address=0x7f6af599dbf8 frag=0x7f6af599dbc8 size=240 used=1 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: alloc'd from <core>: counters.c: cnt_hash_add(339) May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: start check=f0f0f0f0, end check= c0c0c0c0, abcdefed May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: 4. N address=0x7f6af599dd48 frag=0x7f6af599dd18 size=128 used=1 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: alloc'd from <core>: counters.c: init_counters(129) May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: start check=f0f0f0f0, end check= c0c0c0c0, abcdefed May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: 5. N address=0x7f6af599de28 frag=0x7f6af599ddf8 size=16 used=1 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: alloc'd from <core>: modparam.c: set_mod_param_regex(124) May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: start check=f0f0f0f0, end check= c0c0c0c0, abcdefed May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: 6. N address=0x7f6af599de98 frag=0x7f6af599de68 size=128 used=1 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: alloc'd from <core>: str_hash.h: str_hash_alloc(69) May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: start check=f0f0f0f0, end check= c0c0c0c0, abcdefed May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: 7. N address=0x7f6af599df78 frag=0x7f6af599df48 size=48 used=1 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: alloc'd from <core>: route.c: route_add(159) May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: start check=f0f0f0f0, end check= c0c0c0c0, abcdefed May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: 8. N address=0x7f6af599e008 frag=0x7f6af599dfd8 size=16 used=1 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: alloc'd from <core>: route.c: init_rlist(181) May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: start check=f0f0f0f0, end check= c0c0c0c0, abcdefed May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: 9. N address=0x7f6af599e078 frag=0x7f6af599e048 size=128 used=1 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: alloc'd from <core>: str_hash.h: str_hash_alloc(69) May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: start check=f0f0f0f0, end check= c0c0c0c0, abcdefed May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: 10. N address=0x7f6af599e158 frag=0x7f6af599e128 size=48 used=1 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: alloc'd from <core>: route.c: route_add(159) May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: start check=f0f0f0f0, end check= c0c0c0c0, abcdefed May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: 11. N address=0x7f6af599e1e8 frag=0x7f6af599e1b8 size=16 used=1 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: alloc'd from <core>: route.c: init_rlist(181) May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: start check=f0f0f0f0, end check= c0c0c0c0, abcdefed May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: 12. N address=0x7f6af599e258 frag=0x7f6af599e228 size=128 used=1 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: alloc'd from <core>: str_hash.h: str_hash_alloc(69) May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: start check=f0f0f0f0, end check= c0c0c0c0, abcdefed May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: 13. N address=0x7f6af599e338 frag=0x7f6af599e308 size=48 used=1 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: alloc'd from <core>: route.c: route_add(159) May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: start check=f0f0f0f0, end check= c0c0c0c0, abcdefed May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: 14. N address=0x7f6af599e3c8 frag=0x7f6af599e398 size=16 used=1 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: alloc'd from <core>: route.c: init_rlist(181) May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: start check=f0f0f0f0, end check= c0c0c0c0, abcdefed May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: 15. N address=0x7f6af599e438 frag=0x7f6af599e408 size=128 used=1 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: alloc'd from <core>: str_hash.h: str_hash_alloc(69) May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: start check=f0f0f0f0, end check= c0c0c0c0, abcdefed May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30833]: INFO: <core> [main.c:841]: sig_usr(): INFO: signal 15 received May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30833]: NOTICE: <core> [main.c:852]: sig_usr(): Memory status (pkg): May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30833]: NOTICE: qm_status: (0x7f6af5968010): May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30833]: NOTICE: qm_status: heap size= 749731840 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30833]: NOTICE: qm_status: used= 1110768, used+overhead=1663192, free=748068648 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30833]: NOTICE: qm_status: max used (+overhead)= 1825240 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30833]: NOTICE: qm_status: dumping all alloc'ed. fragments: May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30833]: NOTICE: qm_status: 0. N address=0x7f6af599d528 frag=0x7f6af599d4f8 size=1024 used=1 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30833]: NOTICE: qm_status: alloc'd from <core>: str_hash.h: str_hash_alloc(69) May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30833]: NOTICE: qm_status: start check=f0f0f0f0, end check= c0c0c0c0, abcdefed May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30833]: NOTICE: qm_status: 1. N address=0x7f6af599d988 frag=0x7f6af599d958 size=256 used=1 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30833]: NOTICE: qm_status: alloc'd from <core>: str_hash.h: str_hash_alloc(69) May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30827]: INFO: <core> [main.c:841]: sig_usr(): INFO: signal 15 received May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30830]: INFO: <core> [main.c:841]: sig_usr(): INFO: signal 15 received May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30828]: NOTICE: <core> [main.c:852]: sig_usr(): Memory status (pkg): May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30830]: NOTICE: <core> [main.c:852]: sig_usr(): Memory status (pkg): May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30830]: NOTICE: qm_status: (0x7f6af5968010): May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30830]: NOTICE: qm_status: heap size= 749731840 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30830]: NOTICE: qm_status: used= 1110768, used+overhead=1663192, free=748068648 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30830]: NOTICE: qm_status: max used (+overhead)= 1825240 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30830]: NOTICE: qm_status: dumping all alloc'ed. fragments: May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30828]: NOTICE: qm_status: (0x7f6af5968010): May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30830]: NOTICE: qm_status: 0. N address=0x7f6af599d528 frag=0x7f6af599d4f8 size=1024 used=1 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30830]: NOTICE: qm_status: alloc'd from <core>: str_hash.h: str_hash_alloc(69) May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30832]: INFO: <core> [main.c:841]: sig_usr(): INFO: signal 15 received May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30832]: NOTICE: <core> [main.c:852]: sig_usr(): Memory status (pkg): May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30832]: NOTICE: qm_status: (0x7f6af5968010): May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30832]: NOTICE: qm_status: heap size= 749731840 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30832]: NOTICE: qm_status: used= 1110768, used+overhead=1663192, free=748068648 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30832]: NOTICE: qm_status: max used (+overhead)= 1825240 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30830]: NOTICE: qm_status: start check=f0f0f0f0, end check= c0c0c0c0, abcdefed May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30832]: NOTICE: qm_status: dumping all alloc'ed. fragments: May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30832]: NOTICE: qm_status: 0. N address=0x7f6af599d528 frag=0x7f6af599d4f8 size=1024 used=1 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30830]: NOTICE: qm_status: 1. N address=0x7f6af599d988 frag=0x7f6af599d958 size=256 used=1 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30832]: NOTICE: qm_status: alloc'd from <core>: str_hash.h: str_hash_alloc(69) May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30830]: NOTICE: qm_status: alloc'd from <core>: str_hash.h: str_hash_alloc(69) May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30834]: INFO: <core> [main.c:841]: sig_usr(): INFO: signal 15 received May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30830]: NOTICE: qm_status: start check=f0f0f0f0, end check= c0c0c0c0, abcdefed May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30830]: NOTICE: qm_status: 2. N address=0x7f6af599dae8 frag=0x7f6af599dab8 size=176 used=1 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30830]: NOTICE: qm_status: alloc'd from <core>: counters.c: cnt_hash_add(339) May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30832]: NOTICE: qm_status: start check=f0f0f0f0, end check= c0c0c0c0, abcdefed May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30832]: NOTICE: qm_status: 1. N address=0x7f6af599d988 frag=0x7f6af599d958 size=256 used=1 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30834]: NOTICE: <core> [main.c:852]: sig_usr(): Memory status (pkg): May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30823]: NOTICE: qm_status: 16. N address=0x7f6af599e518 frag=0x7f6af599e4e8 size=48 used=1 May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30834]: NOTICE: qm_status: (0x7f6af5968010): May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30822]: INFO: <core> [main.c:841]: sig_usr(): INFO: signal 15 received May 2 10:50:41 vnpsip01 /usr/local/sbin/kamailio[30822]: NOTICE: <core> [main.c:852]: sig_usr(): Memory status (pkg): Could you help me to fix this problem! Thanks so much! -- --------------------------- *Bui Thi Minh Yen*

2 5

Memory leak or bad setting.
by Kjeld Flarup 13 May '15

13 May '15

Hello We experienced a failure on our kamailio (4.2.1+trusty), which required a restart. May 6 07:40:41 rtpproxy01 /usr/sbin/kamailio[5467]: ERROR: <core> [msg_translator.c:2270]: generate_res_buf_from_sip_res(): out of mem Afterwards we inspected all the settings to be using default, but at a much higher level than an other older kamailio which runs much more traffic. The big difference, is that this kamailio works with rtpengine. Does that require more memory? We also observed that the free memory is constantly falling on some instances. They all started with 16MB but after 1½ day some are on 11.6 Is this normal behaviour that will find a natural level or is there something bad going on? We can also see that there are frags. Is that to be worried about, or is this natural? kamcmd pkg.stats | egrep -e 'free|frag' free: 16362760 total_frags: 17 free: 15835176 total_frags: 232 free: 15845760 total_frags: 205 free: 15829288 total_frags: 188 free: 15847456 total_frags: 181 free: 15853024 total_frags: 183 free: 15873232 total_frags: 225 free: 15858584 total_frags: 231 free: 15834592 total_frags: 205 free: 15852520 total_frags: 132 free: 15869048 total_frags: 120 free: 15824872 total_frags: 100 free: 15828448 total_frags: 113 free: 15858216 total_frags: 109 free: 15861992 total_frags: 82 free: 15871712 total_frags: 110 free: 15813824 total_frags: 109 free: 11583736 total_frags: 121 free: 11588896 total_frags: 106 free: 11580448 total_frags: 118 free: 11586312 total_frags: 134 free: 11592840 total_frags: 159 free: 11632536 total_frags: 120 free: 11582368 total_frags: 127 free: 11660104 total_frags: 97 free: 16352192 total_frags: 14 free: 16351088 total_frags: 13 free: 16341248 total_frags: 46 free: 16351184 total_frags: 19 We use 4.2.1+trusty with these modules, is it possible that a newer version has fixed some memory leak? loadmodule "db_mysql.so" 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" loadmodule "permissions.so" loadmodule "sdpops.so" loadmodule "rtpengine.so" -- Med venlig hilsen / Best regards Kjeld Flarup (Christensen) M.Sc E.E, Teknisk chef Viptel ApS, Benslehøjvej 3, DK-7470 Karup J Telefon: +45 46949949, Telefax: +45 46949950, http://viptel.dk

2 3

Multi-homed Kamailio Modifies ACK
by SamyGo 13 May '15

13 May '15

Hi all, I'm having a scenario where I'm sending call to CISCO IAD2431. The call establishes with 200OK from CISCO and Kamailio sends back modified ACK. Cisco at this points gives out an error and sends 200OK again, Kamailio replies with ACK, and this cycle goes on until the call drops. Here is the error from CISCO: Failed FROM/TO Request check old_from: "Test Phone" <sip:+14432232221@192.168.1.106>;tag=as370915fc old_to: <sip:+14444812211@sip.iamip.com:5041>;tag=9FEC572E-100F new_from: "Test Phone" <sip:+14432232221@192.168.1.106>;tag=as370915fc new_to: <sip:+14444812211@192.168.1.244:5041>;tag=9FE I've #auto_aliases=no and, listen=udp:44.33.22.11:5041 listen=udp:192.168.1.244:5041 Kamailio sends INVITE through the Public IP to the CISCO gw, but decides to change the ACK header. Any advise please. Best Regards, Sammy.

2 3

kamailio slow/no response for requests on particular ports
by Karthik Srinivasan 12 May '15

12 May '15

Hi, I have encountered an issue with kamailio and am hoping someone on this email distro can help: Here's my setup and description of the issue: I am running kamailio version 3.1.4. I have the kamailio process bound to ports 5060, 5070, and 5090. all UDP. I have several client devices registering to the kamailio registrar. The issue I have encountered is this: SIP registrations to port 5070 are fine for a period of time; by fine I mean clients send SIP registration requests to kamailio; and kamailio responds promptly to the request. by period of time I mean (this could be somewhat random) that for10 hours; 12 hours; 1 hour; that kamailo has no issue processing requests. after this random time period has elapsed, kamailo isn't able to respond to sip registrations and other messages in timely manner; to the point where the clients timeout and have to resend their registration requests. at times, kamailio does respond to the requests (with a significant delay) and at other times no response is received by the client. the user experience is intermittent registration delays/failures. The same behavior is seen on port 5090. I have not encountered the issue yet on port 5060. During times when kamailio isn't able to respond timely to requests on a particular port, requests to other ports are responded to timely. for ex: if port 5070 encounters the issue; port 5060 and 5090 seem fine. meaning, I can point my client devices to 5060 or 5090 and kamailio processes the requests timely. I have studied a tcp dump on the server end (kamailio side) and noticed that the network layer shows the messages from the client to be received timely while kamailio is encountering this issue. which indicates to me that it probably isn't a network lag related issue. Something at the application layer is probably causing kamailio to not respond timely. Furthermore the issue resolves itself after a period of time; that is, kamailio begins to respond to messages timely on the problematic port. I haven't had a chance yet to determine exactly how long it takes to recover. it certainly takes some time though. at least 30 minutes; maybe more. I can also state that the load on the kamailio system is minimal. far below than what the performance metrics state it can handle. Has anyone encountered this issue where kamalio isn't responding to registration and other requests timely on a particular port but does so fine for other ports? Any help on this would be appreciated. Thanks, Karthik

2 5

Ims_charging lose all charging information when restart
by Yasin CANER 12 May '15

12 May '15

3 4

DMQ htable replication issue.
by José Seabra 12 May '15

12 May '15

Hello there, I'm using DMQ module to replicate an htable between several kamailio servers, what i'm noticing is that DMQ is sending the information from one server to another, but the htable name is not the same, for example: The original htable name is $sht(fscache=>queue:2), this htable is replicated to another server and the name (queue:2) will be replaced to some random value like this: $sht(fscache=>3c34e55ae6f9-rsf8qhhwntvw) What happens is that the other server cannot get the data replicated, because in script kamailio is looking for $sht(fscache=>queue:2) that is the original name. My kamailio version is 4.2.2, i have tested also with version 4.2.4 but I got the same behavior. This is an expected behavior or a bug? In case of expected behavior how I can configure it in order to get the value replicated from one server to another? Thank you for your help -- Cumprimentos José Seabra

3 7

Handling 407 Proxy Authentication, Elastix MT
by Darren Campbell (Primar) 12 May '15

12 May '15

Hi all Have Asterisk listening on 127.0.0.1 and aiming to route all inbound/outbound SIP via Kamailio listening on 127.0.0.1 and external interface. Inbound calls from the SIP PROVIDER work just fine. Have NAT, rtpproxy configured for successful registration and subsequent INVITEs etc. Experiencing some challenges with the outgoing INVITES, primarily authenticating the outbound INVITEs. The current situation is this: Asterisk > INVITE > Kamailio > INVITE > SIP PROVIDER SIP PROVIDER > 407 Proxy Authenticate > Kamailio > Transaction Cancelled. Asterisk then plays number unavailable message. The desired situation is more like this: Asterisk > INVITE > Kamailio > INVITE > SIP PROVIDER SIP PROVIDER > 407 Proxy Authenticate > Kamailio > Asterisk Asterisk > INVITE (with auth digest etc) > Kamailio > INVITE > SIP PROVIDER An attempted solution was made by having Kamailio authenticate using the uac module. However, ideally Kamailio should be mostly transparent and Asterisk should be handling and responding to the 407 Proxy Authentication. If there is someone in the Kamailio community that has addressed this situation before, guidance would be much appreciated. Regards, Darren

2 8

Media Proxy and STUN
by Nahum Nir 11 May '15

11 May '15

Hi All, After reading the docs I got that it is possible to configure the server so it will change the SDP so clients will send the media to the media proxy. But, what if the clients are not behind a symmetric NAT and using ICE where able to get their real IP:port? How can the server be aware to this and not change the SDP? Thanks, Nir

2 1

Kamailio authentication method
by Mathys Frédéric 10 May '15

10 May '15

Hello, In my scenario with a Kamailio server, I have a VOIP client connecting to the server which, for some reasons, cannot calculate MD5 hashes but only SHA. In this situation, would it be possible to change the authentication algorithm by either modifying Kamailio scripts or writing an external module to do that? As far as I know, the authentication response is calculated as follow (standard HTTP Digest authentication) : HA1=MD5(username:realm:password) HA2=MD5(method:digestURI) response=MD5(HA1:nonce:HA2) For that, I have to save ha1 and ha1b values in the DB with the SHA function directly (with a trigger for example), and then change the authentication method too. What is the best solution to do that? Does a module already exists? Thank you! Frederic Mathys System Integration & Validation

3 6

Diameter message AAR/AAA
by Ramjee Yadav 10 May '15

10 May '15

Dear, With changes incorporate in kamalio.cfg, I am able to REGISTER 200 ok with Rx interface. But I want to send AAR message only after receiving 200 ok at pcscf. Currently message sequences are CER -------> <-------CEA AAR ---------> <------AAA REGISTER---> <-------401 REGISTER----> <----200 ok Screen shot is attached for reference. But I want to Send AAR/AAA only after 200 ok. Below is the Sequence CER -------> <-------CEA REGISTER---> <-------401 REGISTER----> <----200 ok AAR ---------> <------AAA I using PCSCF as Diameter client and Seagull as a Diameter server. With changes in Kamailio.cfg Richard Good on Dec 17, 2014 Updated P-CSCF example with additional Rx_AAR params<https://github.com/kamailio/kamailio/commit/b450a769cff3b5c8ea0962299f6b087…> I am able to REGISTER but not able to send AAR/AAA after 200 ok.(Refer Attachment) Kindly let me know any other changes required in kamailio.cfg or seagull scenario.xml or some where else. and What changes. Thanks in advance. Br, Ramjee Y. ============================================================================================================================ Disclaimer: This message and the information contained herein is proprietary and confidential and subject to the Tech Mahindra policy statement, you may review the policy at http://www.techmahindra.com/Disclaimer.html externally http://tim.techmahindra.com/tim/disclaimer.html internally within TechMahindra. ============================================================================================================================

1 0

Recommended configuration for TCP support
by Mickael Marrache 08 May '15

08 May '15

Hi, We sometimes get issues caused by truncated SDP bodies. Therefore, we are looking at using TCP instead of UDP. What is the recommended configuration when TCP is used? Currently, I only have the following: children=16 listen=udp:<ip>:5060 listen=tcp:<ip>:5060 disable_tcp=no tcp_connection_lifetime=605 (registration expiry is 600) Also, is there a difference with UDP regarding NAT handling? Thanks, Mickael

3 7

db_text error
by jaflong jaflong 08 May '15

08 May '15

db_text error I am getting the following error on using db_text 0(6638) INFO: db_text [dbt_base.c:99]: dbt_init(): using database at: /usr/local/etc/kamailio/ 0(6638) ERROR: db_text [dbt_base.c:207]: dbt_query(): table version not loaded! (too few columns) 0(6638) ERROR: db_text [dbt_base.c:306]: dbt_query(): failed to query the table! I have thisin my kamailio.cfg #!define DBURL "text:///usr/local/etc/kamailio/dbtext" I created the following files cat > /usr/local/etc/kamailio/dbtext/version table_name(str) table_version(int) subscriber:6 location:6 aliases:6 cat > /usr/local/etc/kamailio/dbtext/subscriber username(str) password(str) ha1(str) domain(str) ha1b(str) someuser:someuser:xxx:10.1.1.5:xxx can some advise how to get db_text work for me Regards

2 3

Timer Process versus Slow Timer Process
by Mack Hendricks 08 May '15

08 May '15

Hi All, I'm looking to have a better understanding of when to use the Timer process versus the "Slow Timer" Process. This is what I came up with, but please correct me: - The “*Timer*” process is used to handle core processing within Kamailio. Therefore, you don’t want to put long running logic into the routing handler - The “*Slow Timer*” process can be used for long running processes

2 1

kamailio V 4.2.4 IMS_Charging ro_session_timeout question
by Yasin CANER 08 May '15

08 May '15

Hello; i am trying to understand how is ims_charging working . Kamailio is a S-CSCF here. kamailio and call dont have a problem but ro_session. i always get ro_session_ontimeout() ERROR. when look diameter trace , ims_charging module dont request for 30 more sec for granted and kill dialog. Thanks for helps. 14:22:51 S-CSCF ----->CC-Time 15 .. Sec CCR ---> Java-Diamaeter Server (INITIAL REQ) 14:22:51 S-CSCF <-----CC-Time 15 .. Sec CCA <--- Java-Diamaeter Server (INITIAL REQ) 14:23:01 S-CSCF ----->CC-Time 10 .. Sec CCR ---> Java-Diamaeter Server (UPDATE ) 14:23:01 S-CSCF <-----CC-Time 30 .. Sec CCA <--- Java-Diamaeter Server (UPDATE ) 14:23:31 S-CSCF ----->CC-Time 30 .. Sec CCR ---> Java-Diamaeter Server (TERMINATE ) 14:23:31 S-CSCF <-----CC-Time 30 .. Sec CCA <--- Java-Diamaeter Server (TERMINATE ) ------ LOG ----- May 7 14:23:31 /usr/local/sbin/kamailio[7602]: ERROR: ims_charging [ro_timer.c:449]: ro_session_ontimeout(): Diameter call session - event [2] May 7 14:23:31 /usr/local/sbin/kamailio[7602]: INFO: ims_charging [ro_timer.c:452]: ro_session_ontimeout(): Call/session must be ended - no more funds. May 7 14:23:31 /usr/local/sbin/kamailio[7600]: WARNING: ims_charging [dialog.c:167]: dlg_terminated(): inconsistent ro timer data on ro_session 0x7ff1eb4543b8 [] ---- CFG ------ $var(cc_ret) = Ro_CCR("CHARGING_CCR_REPLY", "orig", "SCUR", "", "15", "location"); ---- CFG ------

3 2

Make deb
by jay binks 07 May '15

07 May '15

is there any way to make deb packages for only 1 of the modules ?? currently it takes a long time to run "make deb" im simply trying to build and package db_cassandra ( need the package for my environment ) As a side note, is there any chance db_cassandra could be added to the kamailio deb packages ? -- Sincerely Jay

4 12

permissions module, regular expression matching Request URI
by Vik Killa 07 May '15

07 May '15

Hello, We would like to match specific calls based on two factors: 1. the source IP address 2. the Request URI I see in the permissions module, it is possible to match based on the Source IP + the From URI. We need two match both in order to return the appropriate 'tag' attribute from table. Would anyone know of a way to accomplish this? Also, I noticed that matching source IP + from uri, you cannot control which result is returned by permissions module based on regular expression. In other words if more than one match is made, permissions module seems to return the first result. Thank you and I look forward to your response. V

3 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