sr-users August 2016

sr-users@lists.kamailio.org

80 participants
107 discussions

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

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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users August 2016