sr-users August 2015

sr-users@lists.kamailio.org

79 participants
123 discussions

Re: [SR-Users] unsupported route_type 64
by Admin 02 Sep '15

02 Sep '15

Here is the output from "event_route[evapi:message-received]" Aug 30 13:18:49 everest /usr/local/kamailio/sbin/kamailio[3897]: INFO: <script>: Message received in evapi: {"Event":"CGR_AUTH_REPLY","TransactionIndex":39453,"TransactionLabel":1341515504,"MaxSessionTime":60,"Suppliers":"","Error":""} Aug 30 13:18:49 everest /usr/local/kamailio/sbin/kamailio[3897]: INFO: <script>: Event received in evapi: "CGR_AUTH_REPLY" Aug 30 13:19:00 everest /usr/local/kamailio/sbin/kamailio[3891]: ERROR: tmx [t_var.c:521]: pv_get_tm_reply_code(): unsupported route_type 64 Thanks.

3 2

OT: some github stuff
by Daniel-Constantin Mierla 01 Sep '15

01 Sep '15

Hello, wondering if people here can shed some light on few github things: 1) is possible to have a multi-line project description (the text at the top of https://github.com/kamailio/kamailio)? Maybe a special format (I tried to add \n or <br />, but they were displayed as is, not interpreted). I would like to add a short note and a link to a page with commit guidelines (http://www.kamailio.org/wiki/devel/github-contributions), so new contributors make proper formatted commits. Displying it at the top will make it easy to spot, as opposity to adding to readme, which is shown at the bottom. 2) is there any specific content/marker to add to README to have it interpreted as markdown (without adding .md extensions)? Something like a special first or last line, ... It will be displayed nicer, but renaming will result in changing lot of other places (makefiles, deb/rpm specs, etc...) and somehow README is the traditional approach for the kind of this file name for Linux/Unix apps. Cheers, Daniel -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Book: SIP Routing With Kamailio - http://www.asipto.com

3 5

Add PSTN gateway with authentication credentials
by Michael Nielsen 01 Sep '15

01 Sep '15

I'm trying to use a PSTN gateway with Kamailio for outbound - and incoming - calls. Everything seems to be routed correctly, except the PSTN gateway denies the call due to missing authentication. How do I add credentials for my PSTN gateway in a secure way? Best regards, Michael

3 6

authorize a client in bulk registration
by Al S 01 Sep '15

01 Sep '15

My PBX registered in bulk to Kamailio successfully.PBX --> Register --> kamailioPBX <-- 401 with nonce value <-- kamailioPBX --> Register with nonce and md5 response values --> kamailioBOX <-- 200ok <-- kamailioHowever, when one of the PBX client sends an invite out, kamailio AUTH module does not authorize this client:client (813-111-1111) --> Invite --> kamailio What would be the right way to authorize a 10-digit client to send a call out when a bulk registration and not 10-digit registration is performed. Your assistance in this matter is greatly appreciatedThanks,Al

3 3

Kamailio TLS configuration
by Alexandru Covalschi 30 Aug '15

30 Aug '15

Hello! I'm having problems with Kamailio configuration with TLS. Or, maybe, that's my misunderstanding about how it should work. So, the issue - inbound TLS works just great, I can call everyone in my domain. I have PositiveSSL certificate, so I have such files: calist.crt AddTrustExternalCARoot.crt + COMODORSAAddTrustCA.crt + COMODORSADomainValidationSecureServerCA.crt divided by \n server.key - key server.crt - cert The configuration of tls.cfg [server:default] method = SSLv23 verify_certificate = no require_certificate = no private_key = /etc/ssl/sectel.io.ssl/sip/server.key certificate = /etc/ssl/sectel.io.ssl/sip/server.crt ca_list = /etc/ssl/sectel.io.ssl/sip/calist.crt #crl = /etc/kamailio/crl.pem (however with or without ca_list nothing changes) [client:default] verify_certificate = yes require_certificate = yes And with that configuration when I'm trying to call to ostel.co (public SIP service supporting TLS) from my server I get such error: ERROR: tls [tls_util.h:42]: tls_err_ret(): TLS write:error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed Putting that in tls.cfg: [client:default] verify_certificate = no require_certificate = no Make everything work. Cross-domain calling is essential and I'm just trying to figure out - what's the problem? Is that my certificate, is that ostel.co certificate or it is just the way it should be? Thanks! -- Alexandru Covalschi ABRISS-Solutions VoIP engineer and system administrator phone: +37367398493 web: http://abs-telecom.com/

3 8

Re: [SR-Users] unsupported route_type 64
by Admin 30 Aug '15

30 Aug '15

Thank you for responding to my post. Here it is. include_file "kamailio-cgrates.cfg" request_route { ... switch ($fU) { case 1001: case 1006: $dlg_var(cgrReqType) = "*prepaid"; break; case 1002: $dlg_var(cgrReqType) = "*postpaid"; break; case 1003: $dlg_var(cgrReqType) = "*pseudoprepaid"; break; default: $dlg_var(cgrReqType) = "*rated"; } $dlg_var(cgrTenant) = "cgrates.org"; $dlg_var(cgrAccount) = $fU; $dlg_var(cgrDestination) = $rU; route(CGRATES_AUTH_REQUEST); # Will be answered in CGRATES_AUTH_REPLY #route(CGRATES_LCR_REQUEST); exit; } # Here will land requests after processing them with CGRateS. # Call RELAY or other routes following this route route[CGRATES_AUTH_REPLY] { if $var(CgrError) != "" { xlog("CGR_AUTH_ERROR: $var(CgrError)"); sl_send_reply("503","CGR_ERROR"); exit; } if $var(CgrMaxSessionTime) != -1 { if $var(CgrMaxSessionTime) == 0 { // Not enough balance, do not allow the call to go through sl_send_reply("403","Insufficient credit"); exit; } else if !dlg_set_timeout("$var(CgrMaxSessionTime)") { sl_send_reply("503","CGR_MAX_SESSION_TIME_ERROR"); exit; } } if $var(CgrSuppliers) != "" { # Enforce the supplier variable to the first one received from CGRateS $dlg_var(cgrSupplier) = $(var(CgrSuppliers){s.select,0,,}); } route(RELAY); } ==================================================================== # kamailio-cgrates.cfg # Kamailio-CGRateS related route blocks # Called on new connection over evapi, should normally be the case of CGRateS engine event_route[evapi:connection-new] { $sht(cgrconn=>cgr) = $evapi(srcaddr) + ":" + $evapi(srcport); # Detect presence of at least one connection } # Called when the connection with CGRateS closes event_route[evapi:connection-closed] { $var(connClosed) = $evapi(srcaddr) + ":" + $evapi(srcport); if $sht(cgrconn=>cgr) == $var(connClosed) { $sht(cgrconn=>cgr) = $null; } } # Message received from CGRateS, dispatch it to own route event_route[evapi:message-received] { json_get_field("$evapi(msg)", "Event", "$var(Event)"); route($(var(Event){s.rm,"})); # String characters are kept by json_get_field, remove them here } # Called by Kamailio on new dialog event_route[dialog:start] { route(CGR_CALL_START); } # Called by Kamailio on dialog end event_route[dialog:end] { route(CGR_CALL_END); } # Called by Kamailio on local disconnect event_route[tm:local-request] { route(CGR_CALL_END); } # Send AUTH_REQUEST to CGRateS route[CGRATES_AUTH_REQUEST] { # Auth INVITEs with CGRateS if $sht(cgrconn=>cgr) == $null { sl_send_reply("503","Charging controller unreachable"); exit; } evapi_async_relay("{\"event\":\"CGR_AUTH_REQUEST\", \"tr_index\":\"$T(id_index)\", \"tr_label\":\"$T(id_label)\", \"cgr_reqtype\":\"$dlg_var(cgrReqType)\", \"cgr_tenant\":\"$dlg_var(cgrTenant)\", \"cgr_account\":\"$dlg_var(cgrAccount)\", \"cgr_destination\":\"$dlg_var(cgrDestination)\", \"cgr_setuptime\":\"$TS\", \"cgr_computelcr\":\"true\"}"); } # Process AUTH_REPLY from CGRateS route[CGR_AUTH_REPLY] { json_get_field("$evapi(msg)", "TransactionIndex", "$var(TransactionIndex)"); json_get_field("$evapi(msg)", "TransactionLabel", "$var(TransactionLabel)"); json_get_field("$evapi(msg)", "MaxSessionTime", "$var(MaxSessionTime)"); json_get_field("$evapi(msg)", "Suppliers", "$var(Suppliers)"); json_get_field("$evapi(msg)", "Error", "$var(Error)"); $var(id_index) = $(var(TransactionIndex){s.int}); $var(id_label) = $(var(TransactionLabel){s.int}); $var(CgrMaxSessionTime) = $(var(MaxSessionTime){s.int}); $var(CgrSuppliers) = $(var(Suppliers){s.rm,"}); $var(CgrError) = $(var(Error){s.rm,"}); t_continue("$var(id_index)", "$var(id_label)", "CGRATES_AUTH_REPLY"); # Unpark the transaction } # Send AUTH_REQUEST to CGRateS route[CGRATES_LCR_REQUEST] { # Auth INVITEs with CGRateS if $sht(cgrconn=>cgr) == $null { sl_send_reply("503","Charging controller unreachable"); exit; } evapi_async_relay("{\"event\":\"CGR_LCR_REQUEST\", \"tr_index\":\"$T(id_index)\", \"tr_label\":\"$T(id_label)\", \"cgr_tenant\":\"$dlg_var(cgrTenant)\", \"cgr_account\":\"$dlg_var(cgrAccount)\", \"cgr_destination\":\"$dlg_var(cgrDestination)\", \"cgr_setuptime\":\"$TS\"}"); } # Process LCR_REPLY from CGRateS route[CGR_LCR_REPLY] { json_get_field("$evapi(msg)", "TransactionIndex", "$var(TransactionIndex)"); json_get_field("$evapi(msg)", "TransactionLabel", "$var(TransactionLabel)"); json_get_field("$evapi(msg)", "MaxSessionTime", "$var(MaxSessionTime)"); json_get_field("$evapi(msg)", "Suppliers", "$var(Suppliers)"); json_get_field("$evapi(msg)", "Error", "$var(Error)"); $var(id_index) = $(var(TransactionIndex){s.int}); $var(id_label) = $(var(TransactionLabel){s.int}); $var(CgrMaxSessionTime) = $(var(MaxSessionTime){s.int}); $var(CgrSuppliers) = $(var(Suppliers){s.rm,"}); $var(CgrError) = $(var(Error){s.rm,"}); t_continue("$var(id_index)", "$var(id_label)", "CGRATES_AUTH_REPLY"); # Unpark the transaction } # CGRateS request for session disconnect route[CGR_SESSION_DISCONNECT] { json_get_field("$evapi(msg)", "HashEntry", "$var(HashEntry)"); json_get_field("$evapi(msg)", "HashId", "$var(HashId)"); json_get_field("$evapi(msg)", "Reason", "$var(Reason)"); jsonrpc_exec('{"jsonrpc":"2.0","id":1, "method":"dlg.end_dlg","params":[$(var(HashEntry){s.rm,"}), $(var(HashId){s.rm,"})]}'); #$jsonrpl($var(reply)); } # Inform CGRateS about CALL_START (start prepaid sessions loops) route[CGR_CALL_START] { if $sht(cgrconn=>cgr) == $null { xlog("Charging controller unreachable"); exit; } evapi_async_relay("{\"event\":\"CGR_CALL_START\", \"callid\":\"$dlg(callid)\", \"from_tag\":\"$dlg(from_tag)\", \"h_entry\":\"$dlg(h_entry)\", \"h_id\":\"$dlg(h_id)\", \"cgr_reqtype\":\"$dlg_var(cgrReqType)\", \"cgr_tenant\":\"$dlg_var(cgrTenant)\", \"cgr_account\":\"$dlg_var(cgrAccount)\", \"cgr_destination\":\"$dlg_var(cgrDestination)\", \"cgr_answertime\":\"$TS\", \"cgr_supplier\":\"$dlg_var(cgrSupplier)\"}"); } # Inform CGRateS about CALL_END (stop debit loops, perform accounting if desired in this way) route[CGR_CALL_END] { if $sht(cgrconn=>cgr) == $null { xlog("Charging controller unreachable"); exit; } $var(callDur) = $TS - $dlg(start_ts); evapi_async_relay("{\"event\":\"CGR_CALL_END\", \"callid\":\"$dlg(callid)\", \"from_tag\":\"$dlg(from_tag)\", \"cgr_reqtype\":\"$dlg_var(cgrReqType)\", \"cgr_tenant\":\"$dlg_var(cgrTenant)\", \"cgr_account\":\"$dlg_var(cgrAccount)\", \"cgr_destination\":\"$dlg_var(cgrDestination)\", \"cgr_answertime\":\"$dlg(start_ts)\", \"cgr_duration\":\"$var(callDur)\", \"cgr_supplier\":\"$dlg_var(cgrSupplier)\", \"cgr_disconnectcause\":\"$T_reply_code\"}"); }

2 1

presence_dialoginfo- first NOTIFY - force_dummy_dialog
by evoip＠ukr.net 29 Aug '15

29 Aug '15

||Hello, we use Kamailio 4.2 with Presence_DIALOGINFO module for BLF notifications (blinking lamps on phone panel). Since version 4.1 Kamailio has a new module parametr " modparam("presence_dialoginfo", "force_dummy_dialog", 1)" - this option generate first NOTIFY to Subscribed phone (without PUBLISH message) and it's lamps became GREEN ( <state>terminated</state>). Without this module parametr the first NOTIFY won't be sent to phone and lamps will stay turned off until first PUBLISH will be handled by presence server. The first NOTIFY sip message with xml body look like this: NOTIFY sip:1005@22.22.22.22:1120 SIP/2.0. To: <sip:1005@11.11.11.11>;tag=867246696. From: <sip:9095@11.11.11.11>;tag=495949c4c25d687c77ca707bd10a0818-5171. CSeq: 2 NOTIFY. Call-ID: 662126467-5060-6(a)BJC.BGI.E.CDD. Route: <sip:10.60.1.3;r2=on;lr=on>, <sip:11.11.11.11;r2=on;lr=on>. Content-Length: 272. User-Agent: kamailio (4.2.3 (x86_64/linux)). Max-Forwards: 70. Event: dialog. Subscription-State: active;expires=600. Content-Type: application/dialog-info+xml. . <?xml version="1.0"?> <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="1" ух state="full" entity="sip:9095@10.60.1.3"> <dialog direction="recipient"> <state>terminated</state> </dialog> </dialog-info> Especially pay attention on XML body. But for some SIP phones this xml body with state = terminated is not enough to turn the BLF lamp on. (for example Grandstream phones). It requires one more or two more fields: "dialog id", "call-id". <?xml version="1.0"?> <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="28" state="full" entity="sip:9093@10.60.1.3"> <dialog id="830b4fd4-c75d-1233-ca9f-0050569560f4" call-id="830b4fd4-c75d-1233-ca9f-0050569560f4" direction="recipient"> <state>terminated</state> </dialog> </dialog-info> The question is how to modify this first NOTIFY XML body message to add "dialog id" and "call-id" to </dialog>. For example latest Kamailio Kazoo fixed that already. :) Kind Regards Ewgeny

4 8

unsupported route_type 64
by Admin 29 Aug '15

29 Aug '15

Hi, I am running Kamailio (4.4.0-dev2 (x86_64/linux)) with cgrates real-time billing application. At the end of a basic call (prepaid to postpaid), I receive the following error: ERROR:tmx [t_var.c:521]:pv_get_tm_reply_code():unsupported route_type 64 8(6740) DEBUG:tmx [t_var.c:526]:pv_get_tm_reply_code():reply code is <0> What does route_type 64 mean? I checked the archive posts (FS#456) and seemed to be fixed in branch 4.1 (part of 4.1.5). Thanks.

2 1

Parser error when enabling siptrace functionality
by Asgaroth 28 Aug '15

28 Aug '15

Hi All, I have a strange issue occuring, when I enable the siptrace functionality within the routing logic, I begin to get a bunch of parser error as show below. Is this normal behaviour or, more than likely, am I doing something wrong? I enable siptrace as follows: request_route { route("InitialMessageChecks"); sip_trace(); setflag(22); ... } event_route[tm:local-request] { sip_trace(); ... } When I enable this functions in the routing logic, I begin to see alot of the following messages in the log file: ERROR: <core> [parser/parse_fline.c:257]: parse_first_line(): parse_first_line: bad message (offset: 39) ERROR: <core> [parser/msg_parser.c:688]: parse_msg(): ERROR: parse_msg: message=<#002#020#002#021® #023ÄÔ#002 ÊÂÕ#035mùLàU{#002> INFO: <core> [parser/parse_fline.c:144]: parse_first_line(): ERROR:parse_first_line: method not followed by SP ERROR: <core> [parser/parse_fline.c:257]: parse_first_line(): parse_first_line: bad message (offset: 0) ERROR: <core> [parser/msg_parser.c:688]: parse_msg(): ERROR: parse_msg: message=<#002#020#002#021#023Ä#023Ä#012#007> ERROR: <core> [parser/parse_fline.c:257]: parse_first_line(): parse_first_line: bad message (offset: 39) ERROR: <core> [parser/msg_parser.c:688]: parse_msg(): ERROR: parse_msg: message=<#002#020#002#021® #023ÄÔ#002 ÊÂÕ#035mùLàUÞž#002> ERROR: <core> [parser/parse_fline.c:257]: parse_first_line(): parse_first_line: bad message (offset: 35) ERROR: <core> [parser/msg_parser.c:688]: parse_msg(): ERROR: parse_msg: message=<#002#020#002#021® #023ÄÔ#002 ÊÂÕ#035mùLàU #011#003> INFO: <core> [parser/parse_fline.c:144]: parse_first_line(): ERROR:parse_first_line: method not followed by SP ERROR: <core> [parser/parse_fline.c:257]: parse_first_line(): parse_first_line: bad message (offset: 0) ERROR: <core> [parser/msg_parser.c:688]: parse_msg(): ERROR: parse_msg: message=<#002#020#002#021#023Ä#023Ä#012#007> INFO: <core> [parser/parse_fline.c:144]: parse_first_line(): ERROR:parse_first_line: method not followed by SP ERROR: <core> [parser/parse_fline.c:257]: parse_first_line(): parse_first_line: bad message (offset: 0) ERROR: <core> [parser/msg_parser.c:688]: parse_msg(): ERROR: parse_msg: message=<#002#020#002#021#023Ä#023Ä#012#007> INFO: <core> [parser/parse_fline.c:144]: parse_first_line(): ERROR:parse_first_line: method not followed by SP ERROR: <core> [parser/parse_fline.c:257]: parse_first_line(): parse_first_line: bad message (offset: 0) ERROR: <core> [parser/msg_parser.c:688]: parse_msg(): ERROR: parse_msg: message=<#002#020#002#021#023Ä#023Ä#012#007> INFO: <core> [parser/parse_fline.c:144]: parse_first_line(): ERROR:parse_first_line: method not followed by SP ERROR: <core> [parser/parse_fline.c:257]: parse_first_line(): parse_first_line: bad message (offset: 0) ERROR: <core> [parser/msg_parser.c:688]: parse_msg(): ERROR: parse_msg: message=<#002#020#002#006y|#023ÄN˜#036ÂÕ#035múLàUÅ±#012> INFO: <core> [parser/parse_fline.c:144]: parse_first_line(): ERROR:parse_first_line: method not followed by SP ERROR: <core> [parser/parse_fline.c:257]: parse_first_line(): parse_first_line: bad message (offset: 0) ERROR: <core> [parser/msg_parser.c:688]: parse_msg(): ERROR: parse_msg: message=<#002#020#002#021#023Ä#023Ä#012#007> INFO: <core> [parser/parse_fline.c:144]: parse_first_line(): ERROR:parse_first_line: method not followed by SP ERROR: <core> [parser/parse_fline.c:257]: parse_first_line(): parse_first_line: bad message (offset: 0) ERROR: <core> [parser/msg_parser.c:688]: parse_msg(): ERROR: parse_msg: message=<#002#020#002#021#023Ä#023Ä#012#007> INFO: <core> [parser/parse_fline.c:144]: parse_first_line(): ERROR:parse_first_line: method not followed by SP ERROR: <core> [parser/parse_fline.c:257]: parse_first_line(): parse_first_line: bad message (offset: 0) ERROR: <core> [parser/msg_parser.c:688]: parse_msg(): ERROR: parse_msg: message=<#002#020#002#021#023Ä#023Ä#012#007> INFO: <core> [parser/parse_fline.c:144]: parse_first_line(): ERROR:parse_first_line: method not followed by SP ERROR: <core> [parser/parse_fline.c:257]: parse_first_line(): parse_first_line: bad message (offset: 0) ERROR: <core> [parser/msg_parser.c:688]: parse_msg(): ERROR: parse_msg: message=<#002#020#002#021#023Ä#023Ä#012#007> INFO: <core> [parser/parse_fline.c:144]: parse_first_line(): ERROR:parse_first_line: method not followed by SP ERROR: <core> [parser/parse_fline.c:257]: parse_first_line(): parse_first_line: bad message (offset: 0) ERROR: <core> [parser/msg_parser.c:688]: parse_msg(): ERROR: parse_msg: message=<#002#020#002#021#023Ä#023Ä#012#007> INFO: <core> [parser/parse_fline.c:144]: parse_first_line(): ERROR:parse_first_line: method not followed by SP ERROR: <core> [parser/parse_fline.c:257]: parse_first_line(): parse_first_line: bad message (offset: 0) ERROR: <core> [parser/msg_parser.c:688]: parse_msg(): ERROR: parse_msg: message=<#002#020#002#021#023Ä#023Ä#012#007> INFO: <core> [parser/parse_fline.c:144]: parse_first_line(): ERROR:parse_first_line: method not followed by SP ERROR: <core> [parser/parse_fline.c:257]: parse_first_line(): parse_first_line: bad message (offset: 0) ERROR: <core> [parser/msg_parser.c:688]: parse_msg(): ERROR: parse_msg: message=<#002#020#002#021#023Ä#023Ä#012#007> Is there any way I can disable seeing these messages? What are these messages? Any thoughts are appreciated. Thanks

2 4

kamailio_fifo
by Sven Juhkam 28 Aug '15

28 Aug '15

After updating kamailio I get: ERROR: Error opening Kamailio's FIFO /var/run/kamailio/kamailio_fifo ERROR: Make sure you have the line 'modparam("mi_fifo", "fifo_name", "/var/run/kamailio/kamailio_fifo")' in your config ERROR: and also have loaded the mi_fifo module. Any solution? Best regards Sven

3 2

← Newer
1
2
3
4
5
6
7
...
13
Older →

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 2015