- sr-users - kamailio.org

Re: [SR-Users] kamailio starts looping invites(some) back to itself.
by SamyGo 10 Aug '16

10 Aug '16

Hi Aqs, How about putting a loop protection of some sort additionally like $si != myself. Is there any chance the API http call is getting skipped to relay w/o getting any reply back and hence looping back to itself ? Regards, Sammy On Jul 22, 2016 14:17, "Aqs Younas" <aqsyounas(a)gmail.com> wrote: Hi, I am using http_async_client and dispatcher modules of Kamailio. Here is scenario! http_async_client makes calls to an API to get groupid upon which dispatcher sends calls. I am using SIPp to generate calls with 100 cps. I see some calls being failed with an error cause, 483 Too Many Hops. Taking the trace shows Kamailio routing some calls to itself. I think this is not a configuration issue since all calls are same(follow same logic) and some calls get failed. Any pointer is much appreciated. Best Regards. _______________________________________________ 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

5 13

Problem receiving large payloads from JSONRPC-S
by Alex Balashov 10 Aug '16

10 Aug '16

Hi, I'm requesting 'dlg.list' from JSONRPC-S via XHTTP on a rather busy server, i.e. event_route[xhttp:request] { xlog("L_INFO", 'action=ER-XHTTP-REQUEST | ret=LOG_HTTP_REQ | data={"method": "$rm", "path": "$hu", "source": "$si:$sp"}'); # Digest challenge omitted. if($hu =~ "^/rpc") { xlog("L_INFO", 'action=ER-XHTTP-REQUEST | ret=JSON_RPC_REQUEST | data={"path": "$hu"}'); jsonrpc_dispatch(); } else { xhttp_reply("404", "Not Found", "text/html", ""); } } # curl --digest -v \ -X POST -H 'Content-Type: application/json' \ -H 'Call-ID: abc12' \ -d '{"jsonrpc": "2.0", "method": "dlg.list", "id": "0deadb33f"}' \ 'http://sipus_adm:raSheinmet4@10.0.62.74:5060/csrp_rpc/' and finding that when there's more than a hundred or so dialogs in play, Kamailio abruptly closes the connection in the middle of returning the output: ----- "tag": "AF5DA9B4-6D5", "contact": "sip:14045551212@xxx.xxx.xxx.xxx:5060", "cseq": "0", "route_set": "", "socket": "udp:xxx.xxx.xxx.xxx:5060" }, * transfer closed with 151674 bytes remaining to read * Closing connection #0 curl: (18) transfer closed with 151674 bytes remaining to read "profiles": ["total",[root@proxy kamailio]# ------ I can't seem to figure out what parameters regulate this. I'm using the following TCP settings: tcp_async=yes tcp_connect_timeout=5 tcp_crlf_ping=no tcp_keepalive=yes tcp_keepidle=30 tcp_linger2=10 tcp_max_connections=4096 tcp_send_timeout=3 tcp_accept_no_cl=yes tcp_wq_blk_size=65535 tcp_wq_max=20971520 But this doesn't seem to have had any effect. Any help appreciated! Thanks, -- Alex -- Alex Balashov | Principal | Evariste Systems LLC 1447 Peachtree Street NE, Suite 700 Atlanta, GA 30309 United States Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

2 6

Duplicate ACC records in db when using db_cluster
by Jan Hazenberg 09 Aug '16

09 Aug '16

Hi, I have a issue with the db_cluster module. All works fine but when i enable ACC records to the database i get duplicate entry's in the acc table. I have 2 nodes enabled: # ----- db_cluster params ----- modparam("db_cluster", "connection", "con1=>mysql://kamailio:password@10.1.1.1/kamailio") modparam("db_cluster", "connection", "con2=>mysql://kamailio:password@10.1.1.2/kamailio") modparam("db_cluster", "cluster", "cls1=>con1=9s8p;con2=9s8p") When i remove one node from the pool the acc records look fine. Could this be a bug? Or should i bypass the db_cluster for accounting? I'm running kamailio 4.4.2. Thanks, Jan Hazenberg

3 5

When Not Found
by Nahum Nir 09 Aug '16

09 Aug '16

Hi List, When sending an invite and the calle not found or responding with an ACK I want my script do some costume work. When can I do it (using regular script)? Thanks, Nir

3 2

Kamailio Regiser
by Rodrigo Moreira 09 Aug '16

09 Aug '16

Hello everyone, I am deploying an IMS core, however I can not register the user (Bob). The entities are all working PCSCF, ICSCF SCSCF and HSS, I suppose. However after utiliizar Wireshark is returned the following error: 604 Does not exist anywhere - HSS User Unknow 400 Bad Request - P-visited-Network-ID header missing. What am I doing wrong? I ask for help, the great community. Or methods to better understand what is causing the problem. Is it DNS? Regards. -- Rodrigo M. (37) 9132-4539 (34) 9889-3069 rodrigo.moreira2007

2 1

open websocket connction from kamailio
by Uri Shacked 08 Aug '16

08 Aug '16

Hi, Is it possible to open a websocket connection from kamailio to another websocket server. not something based on sip, just a websocket to send to the websocket server messages from cfg file. (like http_query) ?? Uri

1 0

Feature Request CarrierRoute To and Contact header Strip
by Yasin CANER 08 Aug '16

08 Aug '16

2 1

app_python access to message body content
by Anthony Joseph Messina 08 Aug '16

08 Aug '16

I'm trying to play around a bit with app_python using the examples in the source. I'd like to access the content of the body of the SIP message, but can't figure out how to do that. I can get headers, method, etc. How does one access body content with app_python? Thanks. -A -- Anthony - https://messinet.com/ - https://messinet.com/~amessina/gallery F9B6 560E 68EA 037D 8C3D D1C9 FF31 3BDB D9D8 99B6

3 4

TCP message parsing & connection close issue
by Alex Balashov 08 Aug '16

08 Aug '16

Hello, I've got an odd issue where: 1. TCP client makes call out through Kamailio. 2. Call is answered, TCP client sends e2e ACK. 3. Parser chokes on ACK, closes TCP connection (SYN+FIN). 4. Subsequent messages from the client, immediately following the ACK (about 240 ms later), come through because the client is halfway around the world - about 250 ms away - and is not yet aware the connection has been closed. Otherwise, it would presumably try to re-establish the connection before sending anything. Anyway, messages from the parser concerning the ACK are: --- Aug 4 21:55:57 sip-proxy /usr/local/kamailio/sbin/kamailio[14680]: INFO: <core> [parser/parse_fline.c:144]: parse_first_line(): ERROR:parse_first_line: method not followed by SP Aug 4 21:55:57 sip-proxy /usr/local/kamailio/sbin/kamailio[14680]: ERROR: <core> [parser/parse_fline.c:257]: parse_first_line(): parse_first_line: bad message (offset: 0) Aug 4 21:55:57 sip-proxy /usr/local/kamailio/sbin/kamailio[14680]: ERROR: <core> [parser/msg_parser.c:690]: parse_msg(): ERROR: parse_msg: message=<0#015#012a=rtcp:4007 IN IP4 1.1.1.1:1071#015#012a=sendrecv#015#012a=rtpmap:0 PCMU/8000#015#012a=rtpmap:8 PCMA/8000#015#012a=rtpmap:96 telephone-event/8000#015#012a=fmtp:96 0-16#015#012ACK sip:*98*0b3ff883-a89d-4317-b758-8979682f5357@10.0.2.53:5060;transport=udp SIP/2.0#015#012Via: SIP/2.0/TCP 1.1.1.1:61979;branch=z9hG4bKPjc15bf9fdded940cab7f859634b9f036e;alias#015#012Max-Forwards: 70#015#012From: sip:4b57be8d-267d-48c4-aa82-0f3a269d74cb@sip.evaristesys.com;tag=dd1d7fd0344d47b7b22c4017091df17a#015#012To: sip:*98*0b3ff883-a89d-4317-b758-8979682f5357@sip.evaristesys.com;tag=2rZDKcBFmU65S#015#012Call-ID: 5ba5a84451074159aaaa931eb1f98fe5#015#012CSeq: 3071 ACK#015#012Route: <sip:2.2.2.2;transport=tcp;lr;r2=on;ftag=dd1d7fd0344d47b7b22c4017091df17a;rtp_set_id=1>#015#012Route: <sip:10.0.2.119;lr;r2=on;ftag=dd1d7fd0344d47b7b22c4017091df17a;rtp_set_id=1>#015#012Content-Length: 0#015#012#015#012> Aug 4 21:55:57 sip-proxy /usr/local/kamailio/sbin/kamailio[14680]: ERROR: <core> [receive.c:173]: receive_msg(): core parsing of SIP message failed (1.1.1.1:61979/2) --- That doesn't look like a clean message buffer to me. The message should start here: ACK sip:*98*0b3ff883-a89d-4317-b758-8979682f5357@10.0.2.53:5060;transport=udp SIP/2.0#015#012Via: SIP/2.0/TCP ... But instead it's got these SDP attributes prepended: 0#015#012a=rtcp:4007 IN IP4 1.1.1.1:1071#015#012a=sendrecv#015#012a=rtpmap:0 PCMU/8000#015#012a=rtpmap:8 PCMA/8000#015#012a=rtpmap:96 telephone-event/8000#015#012a=fmtp:96 0-16#015#012 These SDP attribute appear to have fallen off the back of the SDP offer in the initial INVITE: v=0 o=- 3679365582 3679365582 IN IP4 10.0.0.200 s=pjmedia t=0 0 m=audio 4006 RTP/AVP 0 8 96 c=IN IP4 1.1.1.1 The relationship between the 4006 RTP port and the 4007 RTCP port suggests that these two things belong together. This is on kamailio 4.4.0 (x86_64/linux) d4f23c. Any help would be greatly appreciated! The issue is consistently reproducible and this happens every time. Cheers, -- Alex -- Alex Balashov | Principal | Evariste Systems LLC 1447 Peachtree Street NE, Suite 700 Atlanta, GA 30309 United States Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

2 6

Synonyms User Name
by Nahum Nir 07 Aug '16

07 Aug '16

Hello List, I wonder if there is a way to define synonyms. For example, I there is a person by the name of John Smith with extention 5555 I would like to have a user john_smith that will also be available if some INVITE 5555. Thanks, Nahum

2 3

Prepaid system using dialog and sqlops
by Infinicalls Infinicalls 06 Aug '16

06 Aug '16

Hi, I am still struggling to get a prepaid system for my service. After installing SIREMIS, I am able to get the CDRs updated. But even after adding the cron settings, the call duration doesn't get updated. And also in http://lists.sip-router.org/pipermail/sr-users/2012-January/071517.html it has been mentioned that "If it is the case of 1 call per user at a time, then practically can be done from kamailio config only. When call starts, compute the max duration for that call based on caller/destination (e.g., call a stored procedure via sqlops) and set the dialog timeout to that duration. When call ends (BYE in main route or timeout route) update the credit accordingly." Can somebody let me know if my understanding is correct. 1) Add a field called "credits" in the database. And topup that field. 2) First compute max permitted duration for that user by multiplying the cost for number prefix (say +91) and pulse. 3) And finally add this value to timeout of dialog. modparam("dialog", "default_timeout", 100000) $dlg_ctx(timeout_bye) = 1; Will this work? Any help would be appreciated. regards Ganesh Kumar

3 4

segfault when using sipt modifications
by david 05 Aug '16

05 Aug '16

hello all i'm trying to add a ISUP multipart in a regular call using the textops module, and despite seeing one previous issue int he mail list, i'm finding some issue here i'm using this commands msg_apply_changes(); set_body_multipart(,"2123894789_1257887457"); msg_apply_changes(); append_body_part("\x01\x12\x49\x00\x0a\x03\x02\x0a\x08\x84\x90\x33 \x41\x72\x17\x00\x06\x0a\x08\x04\x13\x93\x70\x21\x73\x23\x10\x08\x01\x00 \x00","application/isup;version=itu-t92+","signal;handling=optional"); msg_apply_changes(); sipt_destination($rU, 31, 4); sipt_set_calling($fU, 4, 0, 3); msg_apply_changes(); before the record_route command, and when using sipt_destination($rU, 31, 4); i'm getting asegfault here you have the logs could you please give me any clue about something i'm missing or doing wrong? thanks alot and regards david 5(24552) DEBUG: <core> [parser/msg_parser.c:608]: parse_msg(): SIP Request: 5(24552) DEBUG: <core> [parser/msg_parser.c:610]: parse_msg(): method: <INVITE> 5(24552) DEBUG: <core> [parser/msg_parser.c:612]: parse_msg(): uri: <sip:34666988297@79.170.71.132:5060> 5(24552) DEBUG: <core> [parser/msg_parser.c:614]: parse_msg(): version: <SIP/2.0> 5(24552) DEBUG: <core> [parser/parse_via.c:1254]: parse_via_param(): Found param type 235, <rport> = <n/a>; state=6 5(24552) DEBUG: <core> [parser/parse_via.c:1254]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK7ma5t4FKS0SKa>; state=16 5(24552) DEBUG: <core> [parser/parse_via.c:2642]: parse_via(): end of header reached, state=5 5(24552) DEBUG: <core> [parser/msg_parser.c:496]: parse_headers(): parse_headers: Via found, flags=2 5(24552) DEBUG: <core> [parser/msg_parser.c:498]: parse_headers(): parse_headers: this is the first via 5(24552) DEBUG: <core> [receive.c:178]: receive_msg(): After parse_msg... 5(24552) DEBUG: <core> [receive.c:221]: receive_msg(): preparing to run routing scripts... 5(24552) DEBUG: maxfwd [mf_funcs.c:85]: is_maxfwd_present(): value = 65 5(24552) DEBUG: <core> [parser/parse_addr_spec.c:894]: parse_addr_spec(): end of header reached, state=10 5(24552) DEBUG: <core> [parser/msg_parser.c:173]: get_hdr_field(): DEBUG: get_hdr_field: <To> [49]; uri=[sip:34666988297@79.170.71.132:5060;user=phone] 5(24552) DEBUG: <core> [parser/msg_parser.c:175]: get_hdr_field(): DEBUG: to body [<sip:34666988297@79.170.71.132:5060;user=phone> ] 5(24552) DEBUG: <core> [parser/msg_parser.c:153]: get_hdr_field(): get_hdr_field: cseq <CSeq>: <94568362> <INVITE> 5(24552) DEBUG: <core> [parser/msg_parser.c:187]: get_hdr_field(): DEBUG: get_hdr_body : content_length=104 5(24552) DEBUG: <core> [parser/msg_parser.c:89]: get_hdr_field(): found end of header 5(24552) DEBUG: <core> [parser/parse_addr_spec.c:172]: parse_to_param(): DEBUG: add_param: tag=5jBBFae4D90rg 5(24552) DEBUG: <core> [parser/parse_addr_spec.c:894]: parse_addr_spec(): end of header reached, state=29 5(24552) DEBUG: sanity [mod_sanity.c:248]: w_sanity_check(): sanity checks result: 1 5(24552) DEBUG: siputils [checks.c:97]: has_totag(): no totag 5(24552) DEBUG: <core> [socket_info.c:564]: grep_sock_info(): checking if host==us: 13==13 && [79.170.71.132] == [79.170.71.132] 5(24552) DEBUG: <core> [socket_info.c:567]: grep_sock_info(): checking if port 5060 (advertise 0) matches port 5060 5(24552) DEBUG: tm [t_lookup.c:1011]: t_check_msg(): DEBUG: t_check_msg: msg id=1 global id=0 T start=0xffffffffffffffff 5(24552) DEBUG: tm [t_lookup.c:466]: t_lookup_request(): t_lookup_request: start searching: hash=46859, isACK=0 5(24552) DEBUG: tm [t_lookup.c:424]: matching_3261(): DEBUG: RFC3261 transaction matching failed 5(24552) DEBUG: tm [t_lookup.c:648]: t_lookup_request(): DEBUG: t_lookup_request: no transaction found 5(24552) DEBUG: tm [t_lookup.c:1080]: t_check_msg(): DEBUG: t_check_msg: msg id=1 global id=1 T end=(nil) 5(24552) DEBUG: tm [t_lookup.c:1312]: t_newtran(): DEBUG: t_newtran: msg id=1 , global msg id=1 , T on entrance=(nil) 5(24552) DEBUG: tm [t_lookup.c:466]: t_lookup_request(): t_lookup_request: start searching: hash=46859, isACK=0 5(24552) DEBUG: tm [t_lookup.c:424]: matching_3261(): DEBUG: RFC3261 transaction matching failed 5(24552) DEBUG: tm [t_lookup.c:648]: t_lookup_request(): DEBUG: t_lookup_request: no transaction found 5(24552) DEBUG: tm [t_hooks.c:358]: run_reqin_callbacks_internal(): DBG: trans=0x7fb3fb0c64e0, callback type 1, id 0 entered 5(24552) DEBUG: <core> [md5utils.c:67]: MD5StringArray(): MD5 calculated: 5ea9736b3bdcf90a4c3043a5a492b31f 5(24552) DEBUG: <core> [select.c:412]: run_select(): Calling SELECT 0x7fb404252ef8 5(24552) INFO: Theseus-Test Call 69672589-67f5-4edd-8844-f6ad2ee5b208 / Call-ID 69672589-67f5-4edd-8844-f6ad2ee5b208: Call-ID = 69672589-67f5-4edd-8844-f6ad2ee5b208 5(24552) DEBUG: app_lua [app_lua_api.c:643]: app_lua_run(): reload deactivated 5(24552) DEBUG: app_lua [app_lua_api.c:644]: app_lua_run(): executing Lua function: [[allow_src_uri]] 5(24552) DEBUG: app_lua [app_lua_api.c:645]: app_lua_run(): lua top index is: 4 5(24552) DEBUG: app_lua [app_lua_sr.c:979]: lua_sr_pv_get(): pv get: $avp(s:call_obj) 5(24552) DEBUG: <core> [pvapi.c:321]: pv_cache_lookup(): pvar [$avp(s:call_obj)] found in cache 5(24552) DEBUG: app_lua [app_lua_sr.c:979]: lua_sr_pv_get(): pv get: $ci 5(24552) DEBUG: <core> [pvapi.c:321]: pv_cache_lookup(): pvar [$ci] found in cache 5(24552) DEBUG: app_lua [app_lua_sr.c:1101]: lua_sr_pv_sets(): pv set: $var(authorized) 5(24552) DEBUG: <core> [pvapi.c:321]: pv_cache_lookup(): pvar [$var(authorized)] found in cache 5(24552) INFO: Theseus-Test Call 69672589-67f5-4edd-8844-f6ad2ee5b208 / Call-ID 69672589-67f5-4edd-8844-f6ad2ee5b208: Method INVITE from 79.170.64.130:5080 authorized 5(24552) INFO: Theseus-Test Call 58825 / Call-ID 69672589-67f5-4edd-8844-f6ad2ee5b208: Object 58825 assigned to Call-ID 69672589-67f5-4edd-8844-f6ad2ee5b208 5(24552) INFO: Theseus-Test Call 58825 / Call-ID 69672589-67f5-4edd-8844-f6ad2ee5b208: The call has been sent to RG 106406 5(24552) DEBUG: app_lua [app_lua_api.c:643]: app_lua_run(): reload deactivated 5(24552) DEBUG: app_lua [app_lua_api.c:644]: app_lua_run(): executing Lua function: [[get_rg_info]] 5(24552) DEBUG: app_lua [app_lua_api.c:645]: app_lua_run(): lua top index is: 4 5(24552) DEBUG: app_lua [app_lua_sr.c:979]: lua_sr_pv_get(): pv get: $ci 5(24552) DEBUG: <core> [pvapi.c:321]: pv_cache_lookup(): pvar [$ci] found in cache 5(24552) DEBUG: app_lua [app_lua_sr.c:979]: lua_sr_pv_get(): pv get: $avp(s:call_obj) 5(24552) DEBUG: <core> [pvapi.c:321]: pv_cache_lookup(): pvar [$avp(s:call_obj)] found in cache 5(24552) DEBUG: app_lua [app_lua_sr.c:979]: lua_sr_pv_get(): pv get: $shv(flag_list) 5(24552) DEBUG: <core> [pvapi.c:293]: pv_cache_add(): pvar [$shv(flag_list)] added in cache 5(24552) INFO: app_lua [app_lua_sr.c:96]: lua_sr_log(): Call 58825 / Call-ID 69672589-67f5-4edd-8844-f6ad2ee5b208: RG 106406 attributes: 5(24552) INFO: app_lua [app_lua_sr.c:96]: lua_sr_log(): Call 58825 / Call-ID 69672589-67f5-4edd-8844-f6ad2ee5b208: RG OUT 106406 description = PBX--NOC-TEST 5(24552) INFO: app_lua [app_lua_sr.c:96]: lua_sr_log(): Call 58825 / Call-ID 69672589-67f5-4edd-8844-f6ad2ee5b208: RG OUT 106406 admin_status = 1 5(24552) INFO: app_lua [app_lua_sr.c:96]: lua_sr_log(): Call 58825 / Call-ID 69672589-67f5-4edd-8844-f6ad2ee5b208: RG OUT 106406 cir_direction = 2 5(24552) INFO: app_lua [app_lua_sr.c:96]: lua_sr_log(): Call 58825 / Call-ID 69672589-67f5-4edd-8844-f6ad2ee5b208: RG OUT 106406 ani_posttranslation = 0 5(24552) INFO: app_lua [app_lua_sr.c:96]: lua_sr_log(): Call 58825 / Call-ID 69672589-67f5-4edd-8844-f6ad2ee5b208: RG OUT 106406 ani_posttranslation_table = 0 5(24552) INFO: app_lua [app_lua_sr.c:96]: lua_sr_log(): Call 58825 / Call-ID 69672589-67f5-4edd-8844-f6ad2ee5b208: RG OUT 106406 posttranslation = 1 5(24552) INFO: app_lua [app_lua_sr.c:96]: lua_sr_log(): Call 58825 / Call-ID 69672589-67f5-4edd-8844-f6ad2ee5b208: RG OUT 106406 posttranslation_table = 106384 5(24552) INFO: app_lua [app_lua_sr.c:96]: lua_sr_log(): Call 58825 / Call-ID 69672589-67f5-4edd-8844-f6ad2ee5b208: RG OUT 106406 pound = 2 5(24552) INFO: app_lua [app_lua_sr.c:96]: lua_sr_log(): Call 58825 / Call-ID 69672589-67f5-4edd-8844-f6ad2ee5b208: RG OUT 106406 gw_port = 5060 5(24552) INFO: app_lua [app_lua_sr.c:96]: lua_sr_log(): Call 58825 / Call-ID 69672589-67f5-4edd-8844-f6ad2ee5b208: RG OUT 106406 custom_flags = None 5(24552) DEBUG: app_lua [app_lua_sr.c:1101]: lua_sr_pv_sets(): pv set: $avp(s:description) 5(24552) DEBUG: <core> [usr_avp.c:882]: parse_avp_ident(): Parsing 's:description' 5(24552) DEBUG: <core> [pvapi.c:293]: pv_cache_add(): pvar [$avp(s:description)] added in cache 5(24552) DEBUG: app_lua [app_lua_sr.c:1101]: lua_sr_pv_sets(): pv set: $avp(s:admin_status) 5(24552) DEBUG: <core> [pvapi.c:321]: pv_cache_lookup(): pvar [$avp(s:admin_status)] found in cache 5(24552) DEBUG: app_lua [app_lua_sr.c:1101]: lua_sr_pv_sets(): pv set: $avp(s:cir_direction) 5(24552) DEBUG: <core> [usr_avp.c:882]: parse_avp_ident(): Parsing 's:cir_direction' 5(24552) DEBUG: <core> [pvapi.c:293]: pv_cache_add(): pvar [$avp(s:cir_direction)] added in cache 5(24552) DEBUG: app_lua [app_lua_sr.c:1101]: lua_sr_pv_sets(): pv set: $avp(s:ani_posttranslation_table) 5(24552) DEBUG: <core> [pvapi.c:321]: pv_cache_lookup(): pvar [$avp(s:ani_posttranslation_table)] found in cache 5(24552) DEBUG: app_lua [app_lua_sr.c:1101]: lua_sr_pv_sets(): pv set: $avp(s:posttranslation_table) 5(24552) DEBUG: <core> [pvapi.c:321]: pv_cache_lookup(): pvar [$avp(s:posttranslation_table)] found in cache 5(24552) DEBUG: app_lua [app_lua_sr.c:1101]: lua_sr_pv_sets(): pv set: $avp(s:pound) 5(24552) DEBUG: <core> [pvapi.c:321]: pv_cache_lookup(): pvar [$avp(s:pound)] found in cache 5(24552) DEBUG: app_lua [app_lua_sr.c:1101]: lua_sr_pv_sets(): pv set: $avp(s:gw_ip) 5(24552) DEBUG: <core> [pvapi.c:321]: pv_cache_lookup(): pvar [$avp(s:gw_ip)] found in cache 5(24552) DEBUG: app_lua [app_lua_sr.c:1101]: lua_sr_pv_sets(): pv set: $avp(s:gw_port) 5(24552) DEBUG: <core> [pvapi.c:321]: pv_cache_lookup(): pvar [$avp(s:gw_port)] found in cache 5(24552) INFO: app_lua [app_lua_sr.c:96]: lua_sr_log(): Call 58825 / Call-ID 69672589-67f5-4edd-8844-f6ad2ee5b208: Custom flags = None 5(24552) DEBUG: app_lua [app_lua_sr.c:979]: lua_sr_pv_get(): pv get: $shv(custom_flag_list) 5(24552) DEBUG: <core> [pvapi.c:293]: pv_cache_add(): pvar [$shv(custom_flag_list)] added in cache 5(24552) DEBUG: app_lua [app_lua_sr.c:979]: lua_sr_pv_get(): pv get: $shv(custom_flag_list_branch) 5(24552) DEBUG: <core> [pvapi.c:293]: pv_cache_add(): pvar [$shv(custom_flag_list_branch)] added in cache 5(24552) DEBUG: textopsx [textopsx.c:231]: msg_apply_changes_f(): SIP message content updated - reparsing 5(24552) DEBUG: <core> [parser/msg_parser.c:608]: parse_msg(): SIP Request: 5(24552) DEBUG: <core> [parser/msg_parser.c:610]: parse_msg(): method: <INVITE> 5(24552) DEBUG: <core> [parser/msg_parser.c:612]: parse_msg(): uri: <sip:34666988297@79.170.71.132:5060> 5(24552) DEBUG: <core> [parser/msg_parser.c:614]: parse_msg(): version: <SIP/2.0> 5(24552) DEBUG: <core> [parser/parse_via.c:1254]: parse_via_param(): Found param type 235, <rport> = <n/a>; state=6 5(24552) DEBUG: <core> [parser/parse_via.c:1254]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK7ma5t4FKS0SKa>; state=16 5(24552) DEBUG: <core> [parser/parse_via.c:2642]: parse_via(): end of header reached, state=5 5(24552) DEBUG: <core> [parser/msg_parser.c:496]: parse_headers(): parse_headers: Via found, flags=2 5(24552) DEBUG: <core> [parser/msg_parser.c:498]: parse_headers(): parse_headers: this is the first via 5(24552) DEBUG: textops [textops.c:1577]: set_multibody_helper(): delimiter<21>:[2123894789_1257887457] 5(24552) DEBUG: <core> [parser/parse_addr_spec.c:894]: parse_addr_spec(): end of header reached, state=10 5(24552) DEBUG: <core> [parser/msg_parser.c:173]: get_hdr_field(): DEBUG: get_hdr_field: <To> [49]; uri=[sip:34666988297@79.170.71.132:5060;user=phone] 5(24552) DEBUG: <core> [parser/msg_parser.c:175]: get_hdr_field(): DEBUG: to body [<sip:34666988297@79.170.71.132:5060;user=phone> ] 5(24552) DEBUG: <core> [parser/msg_parser.c:153]: get_hdr_field(): get_hdr_field: cseq <CSeq>: <94568362> <INVITE> 5(24552) DEBUG: <core> [parser/msg_parser.c:187]: get_hdr_field(): DEBUG: get_hdr_body : content_length=104 5(24552) DEBUG: <core> [parser/msg_parser.c:89]: get_hdr_field(): found end of header 5(24552) DEBUG: textops [textops.c:1486]: generate_boundary(): adding final CRLF+CRLF 5(24552) DEBUG: textops [textops.c:1714]: set_multibody_helper(): content-type<48>:[multipart/mixed;boundary="2123894789_1257887457"] 5(24552) DEBUG: textops [textops.c:1768]: set_multibody_helper(): set flag FL_BODY_MULTIPART 5(24552) INFO: <core> [msg_translator.c:1692]: get_boundary(): Content-Type hdr has no params <application/sdp> 5(24552) WARNING: <core> [msg_translator.c:1958]: build_req_buf_from_sip_req(): check_boundaries error 5(24552) DEBUG: <core> [msg_translator.c:422]: clen_builder(): content-length: 189 (189) 5(24552) DEBUG: textopsx [textopsx.c:231]: msg_apply_changes_f(): SIP message content updated - reparsing 5(24552) DEBUG: <core> [parser/msg_parser.c:608]: parse_msg(): SIP Request: 5(24552) DEBUG: <core> [parser/msg_parser.c:610]: parse_msg(): method: <INVITE> 5(24552) DEBUG: <core> [parser/msg_parser.c:612]: parse_msg(): uri: <sip:34666988297@79.170.71.132:5060> 5(24552) DEBUG: <core> [parser/msg_parser.c:614]: parse_msg(): version: <SIP/2.0> 5(24552) DEBUG: <core> [parser/parse_via.c:1254]: parse_via_param(): Found param type 235, <rport> = <n/a>; state=6 5(24552) DEBUG: <core> [parser/parse_via.c:1254]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK7ma5t4FKS0SKa>; state=16 5(24552) DEBUG: <core> [parser/parse_via.c:2642]: parse_via(): end of header reached, state=5 5(24552) DEBUG: <core> [parser/msg_parser.c:496]: parse_headers(): parse_headers: Via found, flags=2 5(24552) DEBUG: <core> [parser/msg_parser.c:498]: parse_headers(): parse_headers: this is the first via 5(24552) ERROR: <core> [lvalue.c:345]: lval_pvar_assign(): non existing right pvar 5(24552) ERROR: <core> [lvalue.c:405]: lval_assign(): assignment failed at pos: (390,18-390,44) 5(24552) DEBUG: <core> [parser/parse_addr_spec.c:894]: parse_addr_spec(): end of header reached, state=10 5(24552) DEBUG: <core> [parser/msg_parser.c:173]: get_hdr_field(): DEBUG: get_hdr_field: <To> [49]; uri=[sip:34666988297@79.170.71.132:5060;user=phone] 5(24552) DEBUG: <core> [parser/msg_parser.c:175]: get_hdr_field(): DEBUG: to body [<sip:34666988297@79.170.71.132:5060;user=phone> ] 5(24552) DEBUG: <core> [parser/msg_parser.c:153]: get_hdr_field(): get_hdr_field: cseq <CSeq>: <94568362> <INVITE> 5(24552) DEBUG: <core> [parser/msg_parser.c:187]: get_hdr_field(): DEBUG: get_hdr_body : content_length=189 5(24552) DEBUG: <core> [parser/msg_parser.c:89]: get_hdr_field(): found end of header 5(24552) DEBUG: textops [textops.c:1486]: generate_boundary(): adding final CRLF+CRLF 5(24552) DEBUG: <core> [msg_translator.c:1719]: get_boundary(): boundary is <--2123894789_1257887457> 5(24552) DEBUG: <core> [msg_translator.c:1839]: check_boundaries(): last bondary without -- at the end 5(24552) DEBUG: <core> [msg_translator.c:1639]: replace_body(): old size body[189] actual[319] 5(24552) DEBUG: <core> [msg_translator.c:422]: clen_builder(): content-length: 319 (319) 5(24552) DEBUG: textopsx [textopsx.c:231]: msg_apply_changes_f(): SIP message content updated - reparsing 5(24552) DEBUG: <core> [parser/msg_parser.c:608]: parse_msg(): SIP Request: 5(24552) DEBUG: <core> [parser/msg_parser.c:610]: parse_msg(): method: <INVITE> 5(24552) DEBUG: <core> [parser/msg_parser.c:612]: parse_msg(): uri: <sip:34666988297@79.170.71.132:5060> 5(24552) DEBUG: <core> [parser/msg_parser.c:614]: parse_msg(): version: <SIP/2.0> 5(24552) DEBUG: <core> [parser/parse_via.c:1254]: parse_via_param(): Found param type 235, <rport> = <n/a>; state=6 5(24552) DEBUG: <core> [parser/parse_via.c:1254]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK7ma5t4FKS0SKa>; state=16 5(24552) DEBUG: <core> [parser/parse_via.c:2642]: parse_via(): end of header reached, state=5 5(24552) DEBUG: <core> [parser/msg_parser.c:496]: parse_headers(): parse_headers: Via found, flags=2 5(24552) DEBUG: <core> [parser/msg_parser.c:498]: parse_headers(): parse_headers: this is the first via 5(24552) DEBUG: <core> [parser/parse_addr_spec.c:894]: parse_addr_spec(): end of header reached, state=10 5(24552) DEBUG: <core> [parser/msg_parser.c:173]: get_hdr_field(): DEBUG: get_hdr_field: <To> [49]; uri=[sip:34666988297@79.170.71.132:5060;user=phone] 5(24552) DEBUG: <core> [parser/msg_parser.c:175]: get_hdr_field(): DEBUG: to body [<sip:34666988297@79.170.71.132:5060;user=phone> ] 5(24552) DEBUG: <core> [parser/msg_parser.c:153]: get_hdr_field(): get_hdr_field: cseq <CSeq>: <94568362> <INVITE> 5(24552) DEBUG: <core> [parser/msg_parser.c:187]: get_hdr_field(): DEBUG: get_hdr_body : content_length=319 5(24552) DEBUG: <core> [parser/parse_body.c:87]: get_boundary_param(): boundary is "2123894789_1257887457" 5(24552) DEBUG: <core> [parser/msg_parser.c:89]: get_hdr_field(): found end of header 5(24552) DEBUG: <core> [parser/parse_body.c:87]: get_boundary_param(): boundary is "2123894789_1257887457" 5(24552) CRITICAL: <core> [data_lump.c:297]: del_lump(): offset + len exceeds message size (1176 + 51 > 1201) 35(24582) CRITICAL: <core> [pass_fd.c:275]: receive_fd(): EOF on 17 35(24582) DEBUG: <core> [tcp_main.c:3448]: handle_ser_child(): dead child 5, pid 24552 (shutting down?) 35(24582) DEBUG: <core> [io_wait.h:598]: io_watch_del(): DBG: io_watch_del (0xa2ae40, 17, -1, 0x0) fd_no=39 called 0(24547) ALERT: <core> [main.c:739]: handle_sigs(): child process 24552 exited by a signal 6 0(24547) ALERT: <core> [main.c:742]: handle_sigs(): core was not generated 0(24547) INFO: <core> [main.c:754]: handle_sigs(): terminating due to SIGCHLD 0(24547) DEBUG: <core> [main.c:756]: handle_sigs(): terminating due to SIGCHLD 34(24581) INFO: <core> [main.c:809]: sig_usr(): signal 15 received 33(24580) INFO: <core> [main.c:809]: sig_usr(): signal 15 received 32(24579) INFO: <core> [main.c:809]: sig_usr(): signal 15 received 31(24578) INFO: <core> [main.c:809]: sig_usr(): signal 15 received 30(24577) INFO: <core> [main.c:809]: sig_usr(): signal 15 received 29(24576) INFO: <core> [main.c:809]: sig_usr(): signal 15 received 28(24575) INFO: <core> [main.c:809]: sig_usr(): signal 15 received 27(24574) INFO: <core> [main.c:809]: sig_usr(): signal 15 received 26(24573) INFO: <core> [main.c:809]: sig_usr(): signal 15 received 25(24572) INFO: <core> [main.c:809]: sig_usr(): signal 15 received 24(24571) INFO: <core> [main.c:809]: sig_usr(): signal 15 received 23(24570) INFO: <core> [main.c:809]: sig_usr(): signal 15 received 22(24569) INFO: <core> [main.c:809]: sig_usr(): signal 15 received 21(24568) INFO: <core> [main.c:809]: sig_usr(): signal 15 received 20(24567) INFO: <core> [main.c:809]: sig_usr(): signal 15 received 19(24566) INFO: <core> [main.c:809]: sig_usr(): signal 15 received 18(24565) INFO: <core> [main.c:809]: sig_usr(): signal 15 received 17(24564) INFO: <core> [main.c:809]: sig_usr(): signal 15 received 16(24563) INFO: <core> [main.c:809]: sig_usr(): signal 15 received 15(24562) INFO: <core> [main.c:809]: sig_usr(): signal 15 received 14(24561) INFO: <core> [main.c:809]: sig_usr(): signal 15 received 13(24560) INFO: <core> [main.c:809]: sig_usr(): signal 15 received 12(24559) INFO: <core> [main.c:809]: sig_usr(): signal 15 received 11(24558) INFO: <core> [main.c:809]: sig_usr(): signal 15 received 10(24557) INFO: <core> [main.c:809]: sig_usr(): signal 15 received 9(24556) INFO: <core> [main.c:809]: sig_usr(): signal 15 received 8(24555) INFO: <core> [main.c:809]: sig_usr(): signal 15 received 7(24554) INFO: <core> [main.c:809]: sig_usr(): signal 15 received 6(24553) INFO: <core> [main.c:809]: sig_usr(): signal 15 received 4(24551) INFO: <core> [main.c:809]: sig_usr(): signal 15 received 3(24550) INFO: <core> [main.c:809]: sig_usr(): signal 15 received 2(24549) INFO: <core> [main.c:809]: sig_usr(): signal 15 received 1(24548) INFO: <core> [main.c:809]: sig_usr(): signal 15 received 35(24582) INFO: <core> [main.c:809]: sig_usr(): signal 15 received 0(24547) DEBUG: rtpengine [rtpengine.c:2014]: mod_destroy(): rtpengine_hash_table_destroy() success! 0(24547) DEBUG: db_text [dbtext.c:110]: destroy(): destroy ... 0(24547) DEBUG: tm [t_funcs.c:86]: tm_shutdown(): DEBUG: tm_shutdown : start 0(24547) DEBUG: tm [t_funcs.c:89]: tm_shutdown(): DEBUG: tm_shutdown : emptying hash table 0(24547) DEBUG: tm [h_table.c:127]: free_cell_helper(): freeing transaction 0x7fb3fb0c64e0 from h_table.c:449 0(24547) DEBUG: tm [t_funcs.c:91]: tm_shutdown(): DEBUG: tm_shutdown : removing semaphores 0(24547) DEBUG: tm [t_funcs.c:93]: tm_shutdown(): DEBUG: tm_shutdown : destroying tmcb lists 0(24547) DEBUG: tm [t_funcs.c:96]: tm_shutdown(): DEBUG: tm_shutdown : done 0(24547) INFO: <core> [sctp_core.c:53]: sctp_core_destroy(): SCTP API not initialized 0(24547) DEBUG: <core> [mem/shm.c:174]: shm_core_lock_destroy(): destroying the shared memory lock 0(24547) DEBUG: <core> [mem/shm.c:266]: shm_destroy_manager(): destroying memory manager: f_malloc 0(24547) DEBUG: <core> [mem/pkg.c:89]: pkg_destroy_manager(): destroying memory manager: f_malloc

3 13

e2e ACK. Kamailio. Cantact. Route.
by pavel＠eremina.net 05 Aug '16

05 Aug '16

Hello, I have this scheme: SIP Carrier (external IP 22.203) < > (local ip 1.21) mikrotik < > (local ip 1.21) Kamailio - (local ip 1.15) Asterisk. Carrier does not know what is Route header. that is why Carrier send ACK directly to 1.15 and fail. I change Contact at Kamailio to 1.21 then ACK is coming to Kamailio. But i think it's wrong way... How can i get ACK from CArrier to Kamalio and route it in right way? Thanks

1 0

e2e ACK
by Pavel Eremin 05 Aug '16

05 Aug '16

Hello, I have this scheme: SIP Carrier (external IP 22.203) < > (local ip 1.21) mikrotik < > (local ip 1.21) Kamailio - (local ip 1.15) Asterisk. Carrier does not know what is Route header. that is why Carrier send ACK directly to 1.15 and fail. I change Contact at Kamailio to 1.21 then ACK is coming to Kamailio. But i think it's wrong way... How can i get ACK from CArrier to Kamalio and route it in right way? Thanks

1 0

Re: [SR-Users] Textops and Multipart Body - adding ISUP segfaults Kamailio
by david 05 Aug '16

05 Aug '16

Hello all i'm having the same error on kam 4.4 when doing set_body_multipart(); msg_apply_changes(); i see in the logs 5(17797) DEBUG: textops [textops.c:1577]: set_multibody_helper(): delimiter<17>:[unique-boundary-1] 5(17797) DEBUG: textops [textops.c:1486]: generate_boundary(): adding final CRLF+CRLF 5(17797) DEBUG: textops [textops.c:1714]: set_multibody_helper(): content-type<44>:[multipart/mixed;boundary="unique-boundary-1"] 5(17797) DEBUG: textops [textops.c:1768]: set_multibody_helper(): set flag FL_BODY_MULTIPART 5(17797) INFO: <core> [msg_translator.c:1692]: get_boundary(): Content-Type hdr has no params <application/sdp> 5(17797) WARNING: <core> [msg_translator.c:1958]: build_req_buf_from_sip_req(): check_boundaries error 5(17797) DEBUG: <core> [msg_translator.c:422]: clen_builder(): content-length: 191 (191) the original INVITE is like .... Content-Type: application/sdp. Content-Disposition: session. Content-Length: 104. P-Asserted-Identity: "10707334" <sip:10707334@3.3.3.3>. . v=0. o=user1 53655765 23536 IN IP4 79.170.68.171. s=-. c=IN IP4 2.2.2.2. t=0 0. m=audio 6001 RTP/AVP 8. .... do you have any idea why these messages appear thanks a lot and regards david

2 1

Re: [SR-Users] Kamailio on multiple interface
by Daniel-Constantin Mierla 05 Aug '16

05 Aug '16

Hello, if you know the ip address associated with the network interfaces, you can use keyword dst_ip to check which of the ip addresses was used to receive the packet (or use $Ri instead of dst_ip). Cheers, Daniel On 05/08/16 08:41, Marino Mileti wrote: > > Hi guys, > > > > I've my Kamailio box that works great J > > > > Now I would like to enable wifi on the board (in AP mode) in order to > allow mobile devices to connect and receive and place calls. > > Is it possible? Is it possible to configure Kama like a "gateway" > between two network cards? > > > > I've find a guide regarding gateway between IPv4 and IPV6 but i can't > use "af" to discriminate message between eth0 or wlan0. Is there a > command to detect if a message is received from a specific interface card? > > > > Any help or any cfg example is very appreciate J > > > > /Marino Maria Mileti/// > > /marino.mileti(a)alice.it <mailto:marino.mileti@alice.it>/ > > / / > > /cid:006a01cb6b0e$67eecdae$_CDOSYS2.0//Reduce your energy consumption > and keep polar bears on ice!/ > > > > > > ------------------------------------------------------------------------ > Avast logo > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> > > > Questa e-mail è stata controllata per individuare virus con Avast > antivirus. > www.avast.com > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> > > > > > > _______________________________________________ > 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://www.asipto.com - http://www.kamailio.org http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

1 0

Kamailio on multiple interface
by Marino Mileti 05 Aug '16

05 Aug '16

Hi guys, I've my Kamailio box that works great J Now I would like to enable wifi on the board (in AP mode) in order to allow mobile devices to connect and receive and place calls. Is it possible? Is it possible to configure Kama like a "gateway" between two network cards? I've find a guide regarding gateway between IPv4 and IPV6 but i can't use "af" to discriminate message between eth0 or wlan0. Is there a command to detect if a message is received from a specific interface card? Any help or any cfg example is very appreciate J Marino Maria Mileti <mailto:marino.mileti@alice.it> marino.mileti(a)alice.it cid:006a01cb6b0e$67eecdae$_CDOSYS2.0Reduce your energy consumption and keep polar bears on ice! --- Questa e-mail è stata controllata per individuare virus con Avast antivirus. https://www.avast.com/antivirus

1 0

Kamailio RTP Engine
by Jack Stevens 05 Aug '16

05 Aug '16

Hi Guys, Looking for some help on configuring RTP Engine with Dispatcher on my Kamailio Box Please see this paste for the kamailio configuration = http://pastebin.com/yZzSEJmK When I run a call the dispatcher does it job perfectly but the rtpengine is not been used does anyone know why -- CONFIDENTIAL EMAIL FROM NETCALL TELECOM LIMITED This email, and any attachments, is intended only for the above addressee. It may contain private and/or confidential information. If you have received this email in error you are on notice of its status, please immediately notify the sender by return email then delete this message and any attachments. If you are not the addressee, except to notify the sender, you must not use, disclose, copy or distribute this email and/or its attachments. Netcall Telecom accepts no responsibility for any changes made to this message after it has been sent by the original author. Opinions or views expressed in this email may be those of the individual sender and not Netcall Telecom. Nothing in this email shall bind Netcall Telecom in any contract or obligation Netcall Telecom Ltd Registered in England 2831215. Registered Office : 3rd Floor, Hamilton House, 111 Marlowes, Hemel Hempstead, Herts, HP1 1BB

2 1

Kamailio 4.4 wont start on CentOS 7 using script
by Fabian Borot 04 Aug '16

04 Aug '16

Hello I installed/compiled version 4.4 on CentOS 7. When I start the server like this: "./kamctl start" it works but when I try to use the script: "/etc/init.d/kamailio" it fails [root@ar-mia-proxy-01 sbin]# /etc/init.d/kamailio start Starting kamailio (via systemctl): Job for kamailio.service failed because the control process exited with error code. See "systemctl status kamailio.service" and "journalctl -xe" for details. [FAILED] [root@ar-mia-proxy-01 sbin]# when running the "status" I see this: [root@ar-mia-proxy-01 sbin]# /etc/init.d/kamailio status â kamailio.service - LSB: Kamailio (OpenSER) - the Open Source SIP Server Loaded: loaded (/etc/rc.d/init.d/kamailio) Active: failed (Result: exit-code) since Thu 2016-08-04 15:25:59 GMT; 14s ago Docs: man:systemd-sysv-generator(8) Process: 5556 ExecStart=/etc/rc.d/init.d/kamailio start (code=exited, status=1/FAILURE) Aug 04 15:25:59 ar-mia-proxy-01.dom.com systemd[1]: Starting LSB: Kamailio (OpenSER) - the Open Source SIP Server... Aug 04 15:25:59 ar-mia-proxy-01.dom.com kamailio[5556]: Starting kamailio: Aug 04 15:25:59 ar-mia-proxy-01.dom.com systemd[1]: kamailio.service: control process exited, code=exited status=1 Aug 04 15:25:59 ar-mia-proxy-01.dom.com systemd[1]: Failed to start LSB: Kamailio (OpenSER) - the Open Source SIP Server. Aug 04 15:25:59 ar-mia-proxy-01.dom.com systemd[1]: Unit kamailio.service entered failed state. Aug 04 15:25:59 ar-mia-proxy-01.dom.com systemd[1]: kamailio.service failed. [root@ar-mia-proxy-01 sbin]# I welcome all ideas, thank you in advance

3 4

Kamailio and RTPProxy in-front of freeswitch
by Achintha 04 Aug '16

04 Aug '16

hi all, i have configured kamailio and RTPProxy on one ubuntu server then freeswitch on another server. all servers installed on digital ocean. i was tried to build following setup, SIP_Call------> kamailio+RTPPROXY-------> freeswitch put following configurations on kamailio. modparam("rtpproxy", "rtpproxy_sock", "udp:localhost:7722") modparam("rtpproxy", "rtpproxy_retr", 2) modparam("rtpproxy", "ice_candidate_priority_avp", "$avp(ice_priority)") mhomed=1 route[FROM_TRUNK] #force_send_socket("pu.bl.ic.ip "); rtpproxy_manage("","pu.bl.ic.ip "); $du="sip:ip.of.free.switch:5080"; route(RELAY); call was connected but rtp is not going through the kamailio server like folows, SIP FLOOR SIP_Call------> kamailio-------> freeswitch SIP_Call<------ kamailio<------- freeswitch RTP FLOOR SIP_Call ------> freeswitch SIP_Call <------ freeswitch please help me to configure kamailio and RTPProxy to manage RTP -- thanking you.. Achintha

1 0

Re: [SR-Users] Path & Loose Route
by Luke Milbourne 04 Aug '16

04 Aug '16

Hi Daniel, Thanks again for your reply again. I remembered about the debug setting and done it yesterday, not at my pc right now but I remember one of the log lines was saying "the topmost route header is me". Still trying to understand it, but will get a copy of the log lines for you, if you wouldn't mind taking a look. Thanks again, Luke On 4 Aug 2016 06:57, "Daniel-Constantin Mierla" <miconda(a)gmail.com> wrote: Hello, set debug=3 in kamailio.cfg and look at log messages in syslog. If you find it too verbose, use dispatcher module and set debug level only for core and rr modules to 3. Cheers, Daniel On 03/08/16 13:22, Luke Milbourne wrote: Hi Daniel, I've added some more logging and can see loose_route() is returning -1 - route calculation has been unsuccessful. Is there a way of finding out why this is the case? Kind regards, Luke On 2 August 2016 at 09:49, Luke Milbourne <luke.milbourne(a)gmail.com> wrote: > I added the below xlog lines into my script: > > xlog("L_NOTICE", "Before loose_route: $si -> $ru - $du\n"); > xlog("L_NOTICE", "Before record_route: $si -> $ru - $du\n"); > xlog("L_NOTICE", "After both: $si -> $ru - $du\n"); > > Which generated the below output in syslog: > > Aug 2 09:46:11 ip-10-10-2-5 /sbin/kamailio[529]: NOTICE: <script>: Before > loose_route: 10.10.0.25 -> sip:201@192.168.1.114:5062 - <null> > Aug 2 09:46:11 ip-10-10-2-5 /sbin/kamailio[529]: NOTICE: <script>: Before > record_route: 10.10.0.25 -> sip:201@192.168.1.114:5062 - <null> > Aug 2 09:46:11 ip-10-10-2-5 /sbin/kamailio[529]: NOTICE: <script>: After > both: 10.10.0.25 -> sip:201@192.168.1.114:5062 - <null> > > Seems that the destination URI is never set, the Route header is below: > > Route: <sip:201@10.10.2.5:5072>;lr;received=sip:[PUBLIC_IP]:45126 > > The use_received modparam for path is also set to 1. > > Any idea's/suggestions are greatly appreciated :) > > Kind regards, > Luke > > On 2 August 2016 at 09:40, Luke Milbourne <luke.milbourne(a)gmail.com> > wrote: > >> Morning Gents, >> >> Firstly, thanks for taking the time to reply :) >> >> Kamailio is doing the NAT detection and simply acting as a passthrough to >> FreeSWITCH (which handles all SIP registrations etc). >> >> Will setup the log lines shortly and share the results. >> >> kamailio -V outputs; >> >> version: kamailio 4.3.4 (x86_64/linux) 83e842 >> flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, >> DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, >> DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, >> USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES >> ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, >> MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB >> poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. >> id: 83e842 >> compiled on 18:22:39 Jan 26 2016 with gcc 4.9.2 >> >> Kind regards, >> Luke - Chicane Support >> >> On 2 August 2016 at 07:52, Daniel-Constantin Mierla <miconda(a)gmail.com> >> wrote: >> >>> Hello, >>> >>> yes, loose_route() should be used there. Can you add a log message and >>> print $ru and $du before and after loose_route() in config and then send >>> the result to this mailing list? >>> >>> Btw, what version of Kamailio are you using? >>> >>> Cheers, >>> Daniel >>> >>> On 01/08/16 14:46, Luke Milbourne wrote: >>> >>> Is it correct to use loose_route() along side the path module? >>> >>> On 1 August 2016 at 13:33, Luke Milbourne <luke.milbourne(a)gmail.com> >>> wrote: >>> >>>> Hi Daniel, >>>> >>>> Yep, I've got the below in my kamailio.cfg >>>> >>>> modparam("path", "use_received", 1) >>>> >>>> Kind regards, >>>> Luke >>>> >>>> On 1 August 2016 at 13:25, Daniel-Constantin Mierla <miconda(a)gmail.com> >>>> wrote: >>>> >>>>> Hello, >>>>> >>>>> On 01/08/16 14:14, Luke Milbourne wrote: >>>>> >>>>> Hi all, >>>>> >>>>> Currently trying to use Kamailio as a passthrough to some FreeSWITCH >>>>> boxes. >>>>> >>>>> When receiving an invite from FreeSWITCH which contains a Route header >>>>> including received information, example below; >>>>> >>>>> Route: <sip:201@10.10.2.5:5072>;lr;received=sip:[PUBLIC_IP]:45126 >>>>> >>>>> When using loose_route() Kamailio still send the invite to the rfc1918 >>>>> address instead of the received IP:PORT in the Route header. >>>>> >>>>> Am I misunderstanding how this should work? >>>>> >>>>> >>>>> if you use path module, have you enabled the option to use the >>>>> received parameter? >>>>> >>>>> >>>>> https://www.kamailio.org/docs/modules/stable/modules/path.html#idp38033932 >>>>> >>>>> Cheers, >>>>> Daniel >>>>> >>>>> -- >>>>> Daniel-Constantin Mierlahttp://www.asipto.com - http://www.kamailio.orghttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>>>> >>>>> >>>> >>>> >>>> -- >>>> Luke Milbourne >>>> >>>> Tel: 07857154817 >>>> Google Talk/Email: luke.milbourne(a)gmail.com >>>> >>> >>> >>> >>> -- >>> Luke Milbourne >>> >>> Tel: 07857154817 >>> Google Talk/Email: luke.milbourne(a)gmail.com >>> >>> >>> _______________________________________________ >>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users >>> >>> >>> -- >>> Daniel-Constantin Mierlahttp://www.asipto.com - http://www.kamailio.orghttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda >>> >>> >>> _______________________________________________ >>> 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 >>> >>> >> >> >> -- >> Luke Milbourne >> >> Tel: 07857154817 >> Google Talk/Email: luke.milbourne(a)gmail.com >> > > > > -- > Luke Milbourne > > Tel: 07857154817 > Google Talk/Email: luke.milbourne(a)gmail.com > -- Luke Milbourne Tel: 07857154817 Google Talk/Email: luke.milbourne(a)gmail.com _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users -- Daniel-Constantin Mierlahttp://www.asipto.com - http://www.kamailio.orghttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda _______________________________________________ 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

1 1

Kamailio on Mac
by Carlos Ruiz Díaz 04 Aug '16

04 Aug '16

Hi all, I'm switching my development environment from Linux to Mac. Is there any tutorial on how to setup Kamailio on this OS? It may be an Unix flavor, but it's still quite different from Linux :). Thanks, -- Carlos http://caruizdiaz.com http://ngvoice.com +52 55 3048 3303

6 9

Kamailio + rtpengine + freeswitch
by Kotb, Amir 04 Aug '16

04 Aug '16

[03:50] <meamo> I have a small query, can anybody assist please? [03:51] <meamo> I am running kamailio + rtpengine on a google compute cloud instance [03:51] <meamo> have setup them to work with devices behind nat, and everything works [03:52] <meamo> no i have added freeswitch. but I don't know how to configure rtpengine to work with both [03:52] <meamo> when I use #!define with_nat and #!define with_freeswitch, I get no voice in the calls. When I remove, #!define with_freeswitch, everything works normally Best regards, Amir -- Amir KOTB, Msc., Bsc. Postgraduate Researcher Department of Electrical Engineering & Electronics, The University of Liverpool, Brownlow Hill, Liverpool L69 3GJ, UK Mobile: +44-(0) 7428844234 Email: A.Kotb(a)liverpool.ac.uk Skype: A.kotb1 Web: Http://uk.linkedin.com/in/AOKotb Please consider the environment before printing this email

2 1

Path & Loose Route
by Luke Milbourne 04 Aug '16

04 Aug '16

Hi all, Currently trying to use Kamailio as a passthrough to some FreeSWITCH boxes. When receiving an invite from FreeSWITCH which contains a Route header including received information, example below; Route: <sip:201@10.10.2.5:5072>;lr;received=sip:[PUBLIC_IP]:45126 When using loose_route() Kamailio still send the invite to the rfc1918 address instead of the received IP:PORT in the Route header. Am I misunderstanding how this should work? -- Luke Milbourne <luke.milbourne(a)gmail.com> Tel: 07857154817 Google Talk/Email: luke.milbourne(a)gmail.com

3 10

Help with dispatcher ping: Kamailo 4.1
by Andy Chen 03 Aug '16

03 Aug '16

Hi, I'm currently running Kamailio 4.1 and was wondering if there is a way to control ds_ping_interval on a dispatcher setid. Thanks. -- Andy Chen Sr. Telephony Lead Engineer 415 516 5535 (M) achen(a)thinkingphones.com

1 0

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