sr-users July 2015

sr-users@lists.kamailio.org

86 participants
150 discussions

by Loic Chabert

Hello, I'm writing a new module for influxdb stats. I've wrote my code and now i need to compile it. How can i compile it ? I don't want to compile all modules, only this one. Thanks in advance, Regards.

9 years, 4 months

usage of t_flush_flags() in event_route

by Andrew Pogrebennyk

Hi Daniel and others, I'm having a problem with acc module if I'm using the event_route/ branch-failure: say, the call comes from the app server and goes to the registered user. We arm the the failure route and per-branch failure route for the 302 redirect from the UA. We explicitly reset the accounting flags because we don't want to account the calls from the app server. The transaction is created implicitly by the t_relay(). Now if the UA responds with the 302 response and we are going to process that, we want to create an acc record for the new target from 302 message because this call may incur additional costs. I'm setting the accounting flags and calling t_flush_flags() but that doesn't work (no accounting record). Any idea if I'm doing something wrong or maybe there's a bug when changing the flags and then calling t_flush_flags from the event_route? Here are the module parameters: modparam("acc", "early_media", 0) modparam("acc", "report_ack", 0) modparam("acc", "report_cancels", 1) modparam("acc", "detect_direction", 1) modparam("acc", "db_flag", 1) modparam("acc", "db_missed_flag", 2) modparam("acc", "failed_transaction_flag", 3) modparam("acc", "db_url", PAIR_URL) modparam("acc", "db_extra", "src_user=$fU;src_domain=$fd;dst_ouser=$tU;dst_user=$rU;dst_domain=$rd") modparam("acc", "multi_leg_info", "src_leg=$avp(i:901);dst_leg=$avp(i:902)") modparam("acc", "time_mode", 2) modparam("acc", "time_attr", "time_hires") modparam("acc", "cdr_log_enable", 0) FTR, we tried 4.1.6 and 4.1.8. And here is the event route (with flags defined like this: flags FLAG_ACC_DB:1, FLAG_ACC_MISSED:2, FLAG_ACC_FAILED:3, ...): event_route[tm:branch-failure:redirect] { route(ROUTE_STOP_RTPPROXY_BRANCH); if($T_rpl($rs) == 301 || $T_rpl($rs) == 302) { # initialise variables when entering failure route route(ROUTE_INITVARS); # these need to be avps because we need it in reply/failure-route $(avp(s:from_faxserver)[*]) = 0; $(avp(s:to_faxserver)[*]) = 0; $(avp(s:cf_from_pstn)[*]) = 0; $(avp(s:from_pstn)[*]) = 0; $(avp(s:proxylu_from_pstn)[*]) = 0; $(avp(s:lcr_flags)[*]) = 0; $(avp(s:em_call)[*]) = 0; $(avp(s:from_pbx)[*]) = 0; $(avp(s:p_to_device)[*]) = 0; $(avp(s:p_to_group)[*]) = 0; $(avp(s:is_primary)[*]) = 0; # now let's process a 30x $(avp(s:acc_state)[*]) = "cfb"; $(avp(s:orig_acc_caller_user)[*]) = $avp(s:acc_caller_user); $(avp(s:orig_acc_caller_domain)[*]) = $avp(s:acc_caller_domain); $(avp(s:acc_caller_user)[*]) = $avp(s:acc_callee_user); $(avp(s:acc_caller_domain)[*]) = $avp(s:acc_callee_domain); $(avp(s:caller_uuid)[*]) = $avp(s:callee_uuid); $(avp(s:callee_uuid)[*]) = $null; # the $var(no_acc) is 0 at this point but the flags may have been reset # if this is a call from PBX user - we do want accounting for the 302 redirect if(isflagset(FLAG_ACC_DB)) { xlog("L_NOTICE", "++++++ ACC flag is set - [% logreq -%]\n"); } else { xlog("L_NOTICE", "------ ACC flag is NOT set - [% logreq -%]\n"); } setflag(FLAG_ACC_FAILED); setflag(FLAG_ACC_DB); t_flush_flags(); # get last URI from destination-set and set it as R-URI $var(contact) = $T_rpl($ct); $var(contact) = $(var(contact){nameaddr.uri}); if($var(contact) == 0 || $var(contact) == $null) { xlog("L_ERROR", "Failed to fetch contact '$ct' from 301/302 - [% logreq -%]\n"); acc_db_request("480", "acc"); $var(announce_handle) = "callee_tmp_unavailable"; $var(announce_set) = $xavp(callee_real_prefs[0]=>sound_set); $(avp(s:announce_code)[*]) = 480; $(avp(s:announce_reason)[*]) = "Temporarily Unavailable"; route(ROUTE_EARLY_REJECT); } $ru = $var(contact); xlog("L_NOTICE", "Redirect from UAC intercepted - [% logreq -%]\n"); $(avp(s:forwarder_cli_userprov)[*]) = $T_rpl($tU); $(avp(s:forwarder_domain_userprov)[*]) = $T_rpl($td); $var(forward) = 1; $var(redirected_forward) = 1; route(ROUTE_LOAD_CALLER_PREF); route(ROUTE_FIND_CALLEE); } } Thanks. Andrew

9 years, 4 months

File Transfer

by Abdul Hakeem

Hello, Is there a support for file transfer between registered SIP clients, If not, how can this be achieved ? Regards, Abdul Hakeem

9 years, 4 months

Kamailio v4.3.1 Released

by Daniel-Constantin Mierla

Hello, Kamailio SIP Server v4.3.1 stable release is out. This is a maintenance release of the latest stable branch, 4.3, that includes fixes since release of v4.3.0. There is no change to database schema or configuration language structure that you have to do on installations of v4.3.0. Deployments running previous v4.x.x versions are strongly recommended to be upgraded to v4.3.1. For more details about version 4.3.1 (including links and guidelines to download the tarball or from GIT repository), visit: * http://www.kamailio.org/w/2015/07/kamailio-v4-3-1-released/ RPM, Debian/Ubuntu packages will be available soon as well. Cheers, Daniel -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

9 years, 4 months

Missing BYE at the far end

by Kliment Toshkov, Netfinity JSC

Dear colleagues, We have an issue with a couple of peers - when the called party hangs up, they (the peer) does not receive the appropriate BYE message and call appears as still connected at peers end. Then it drops after 30 seconds and sends us BYE. Current setup is the following: PEER IP > KAMAILIO 4.2.2 > (Asterisk PBX 1, 2, 3, …, N) We provision only termination services, which is: 1) peer calls us 2) Kamailio chooses destination using dispatcher module 3) forwards the call to it. Attached is captured trace. Clearly BYE is retransmitted a few times, then request for UPDATE is received but it is not possible to answer it because the call is already hung up (as far as I understand). Kamailio routing file is available upon request. Thank you in advance! Климент Тошков Изпълнителен директор 24/7: 0700 30000 w: www.netfinity.bg <http://www.netfinity.bg/> t: +359 2 4918888 f: +359 2 4815555 <http://www.netfinity.bg/> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

9 years, 4 months

Planing to release v4.3.1

by Daniel-Constantin Mierla

Hello, I am considering to release the first patch version in 4.3 series by beginning of next week (Monday or Tuesday, July 20 or 21). If you are aware of issues not reported yet, then open an item on the tracker to be taken care: - https://github.com/kamailio/kamailio/issues Cheers, Daniel -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Book: SIP Routing With Kamailio - http://www.asipto.com

9 years, 4 months

Kamailio & Asterisk SIP Registration Forwarding - Asterisk replies 401 Unauthorized

by Ben Fitzgerald

Hi, I've been following this integration tutorial http://kb.asipto.com/asterisk:realtime:kamailio-4.0.x-asterisk-11.3.0-astdb and have a successful registration and I can even make calls through my asterisk box. However what is unusual to me is that every time a phone registers with Kamailio, that is forwarded to Asterisk (as expected), yet Asterisk replies with 401 Unauthorized. Oddly enough the phone registers and can still make calls. What worries me is that as we scale to 100's of cps, this seemingly erroneous message may slow down Asterisk because it's trying to handle authentication for users which have already been authenticated by Kamailio. If this behavior is expected, then that would be good to know as well. This is the sip debug from ASTERISK (I have replaced IP's with the names of the servers): <--- SIP read from TCP:kamailio:41205 ---> REGISTER sip:asteriskIP:5060;transport=tcp SIP/2.0 Via: SIP/2.0/TCP kamailio;branch=z9hG4bK998f.2846e405000000000000000000000000.0 To: <sip:40081@asteriskIP> From: <sip:40081@asteriskIP>;tag=32fda68bf54efeeb04e3edc67b53c63d-cfb0 CSeq: 10 REGISTER Call-ID: 0005ce130bcee5c4-26538@kamailio Max-Forwards: 70 Content-Length: 0 User-Agent: kamailio (4.3.0 (x86_64/linux)) Contact: <sip:40081@kamailio:5060> Expires: 3600 <-------------> --- (11 headers 0 lines) --- Sending to kamailio:5060 (no NAT) Sending to kamailio:5060 (no NAT) <--- Transmitting (no NAT) to kamailio:5060 ---> SIP/2.0 401 Unauthorized Via: SIP/2.0/TCP kamailio;branch=z9hG4bK998f.2846e405000000000000000000000000.0;received= kamailio From: <sip:40081@asteriskIP>;tag=32fda68bf54efeeb04e3edc67b53c63d-cfb0 To: <sip:40081@asteriskIP>;tag=as404bac9a Call-ID: 0005ce130bcee5c4-26538@ kamailio CSeq: 10 REGISTER Server: Asterisk PBX 11.6-cert2 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH Supported: replaces, timer WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="262b338e" Content-Length: 0 <------------> Scheduling destruction of SIP dialog '0005ce130bcee5c4-26538@ kamailio' in 32000 ms (Method: REGISTER) Scheduling destruction of SIP dialog '0005ce130bcee5c4-26538@ kamailio' in 32000 ms (Method: REGISTER) Really destroying SIP dialog '0005ce130bcee5c1-26536@ kamailio' Method: REGISTER ========================= sip.conf for kamailio trunk: [kamailio-inbound] type=friend dtmfmode=auto host=kamailioIP allow=all context=sipout insecure=port,invite canreinvite=no ======================== Asterisk version: 11.6-cert2 Kamailio version: 4.3 Benjamin Fitzgerald LETS Corporation (925) 235-1154 ben(a)letscorp.us *******Confidential Notice: This message is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this message in error, please delete this message from all computers and contact Orion Systems/LETS Corp immediately by return e-mail and/or telephone at (925) 566-5600

9 years, 4 months

Double Record-Route to subscriber with multiple locations on different SIP transports

by Andrey Utkin

Hi! We found that we need double Record-Route when we call from one SIP transport to another (let's say, TCP -> TLS), because without |transport=" hint in Record-Route, mobile Linphone app sends messages (INVITE reply, ACK, BYE) via UDP, even if configured for another transport. record_route_advertised_address() is told to add double RR if needed, automatically, so we use it. But the subscriber (the receiver of call) can have multiple registered locations, let's say, one connected via TCP, and another via TLS. So we need to handle each call branch added by lookup(). But adding record_route_advertised_address() ONLY to branch_route attached by t_on_branch() doesn't execute if there's only one location. Having record_route_advertised_address() just in routing script after lookup() seems wrong because it seems unable to edit it for other branches (I don't remember if I have tested this and have proven a failure, or this is just my speculation). So we have added it in both places - right under lookup(), and in branch_route. But in this case we have an error logged: ERROR: rr [rr_mod.c:337]: w_record_route_advertised_address(): Double attempt to record-route Could anyone explain what would be the most correct solution? What is intended behaviour of branch_route? Is it omitted from execution on "primary" branch of call? Is there any parameter which could help? Thanks in advance. -- Andrey Utkin

9 years, 4 months

Dialogue restore after initial processing

by Joao Alves

Hi, I'm trying to restore a SIP session dialogue context and found dlg_get(callid, ftag, ttag) function for that. However, I cannot access the To tag. I noticed on the 180 RINGING there was already an self-generated included on this response, but I also could not access its value. When receiving the SIP INVITE request I used the dlg_manage() and the context was initially stored. if(is_known_dlg()) { xlog("Request $rm from $ci is in-dialog\n"); xlog(">>From tag is $ft and To tag is $tt\n"); # Needed to later restore the dialog $shv(ftag)=$ft; $shv(ttag)=$tt; } 15(49100) ERROR: <script>: Request INVITE from 76589ZWQ5NzIyYjMzNDI1YjVjM2E5ZWU5NjhkYzEyNjE3MzQ is in-dialog 15(49100) exec: *** cfgtrace:request_route=[MATRIX] c=[/etc/kamailio/kamailio.cfg] l=1021 a=25 n=xlog 15(49100) DEBUG: pv [pv_core.c:376]: pv_get_xto_attr(): no Tag parameter 15(49100) ERROR: <script>: >>From tag is 8fd06474 and To tag is <null> Since there was a self-generated one (after the 180 RINGING being sent), I rechecked the $tt and $dlg(to_tag) values and both still returned null values. 15(49100) DEBUG: tm [t_lookup.c:1083]: t_check_msg(): DEBUG: t_check_msg: T already found! 15(49100) DEBUG: <core> [tcp_main.c:2196]: tcpconn_send_put(): send from reader (49100 (15)), reusing fd 15(49100) DEBUG: <core> [tcp_main.c:2430]: tcpconn_do_send(): sending... 15(49100) DEBUG: <core> [tcp_main.c:2464]: tcpconn_do_send(): after real write: c= 0x7effdf7da860 n=396 fd=5 15(49100) DEBUG: <core> [tcp_main.c:2465]: tcpconn_do_send(): buf= SIP/2.0 180 ringing Via: SIP/2.0/TCP 192.168.1.5:58751;branch=z9hG4bK-524287-1---a64e0a42199ee419;rport=61134;received=85.138.200.8 To: <sip:1001@decasa.website>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-f6a3 From: "1000"<sip:1000@decasa.website>;tag=8fd06474 Call-ID: 76589ZWQ5NzIyYjMzNDI1YjVjM2E5ZWU5NjhkYzEyNjE3MzQ CSeq: 1 INVITE Server: kamailio (4.3.0 (x86_64/linux)) Content-Length: 0 ..., shmem=0x7effdf7e1e00: SIP/2.0 180 ringingght(): DEBUG: reply sent out. buf=0x7effec023bf8: SIP/2.0 180 ringing 15(49100) DEBUG: tm [t_reply.c:657]: _reply_light(): DEBUG: _reply_light: finished 15(49100) DEBUG: sl [sl.c:272]: send_reply(): reply in stateful mode (tm) 15(49100) exec: *** cfgtrace:request_route=[MATRIX] c=[/etc/kamailio/kamailio.cfg] l=1031 a=25 n=xlog 15(49100) DEBUG: dialog [dlg_hash.c:640]: dlg_lookup(): ref dlg 0x7effdf7e1bf0 with 1 -> 2 15(49100) DEBUG: dialog [dlg_hash.c:642]: dlg_lookup(): dialog id=5769 found on entry 128 15(49100) DEBUG: dialog [dlg_hash.c:858]: dlg_unref(): unref dlg 0x7effdf7e1bf0 with 1 -> 1 15(49100) ERROR: <script>: Dialog To Tag: <null> <== xlog("Dialog To Tag: $dlg(to_tag)\n"); 15(49100) exec: *** cfgtrace:request_route=[MATRIX] c=[/etc/kamailio/kamailio.cfg] l=1033 a=25 n=xlog 15(49100) DEBUG: pv [pv_core.c:376]: pv_get_xto_attr(): no Tag parameter 15(49100) ERROR: <script>: >>From2 tag is 8fd06474 and To tag is <null> Many thanks, Joao Alves Solution Architect, Unified Communications This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at http://www.amdocs.com/email_disclaimer.asp

9 years, 4 months

Configuring Kamailio as SIP Proxy

by Djamel Bahamid

Hi, I have terminals of video conference which are in public IP ( *DMZ*). I installed kamailio (4.2) which works correctly, it is also in IP pulique (*DMZ*). I wish configured the /kamailio.cfg/ file, so that kamailio works in *proxy SIP*. And declared my CODEC of visoconférence in URI, example: 'DR London(a)domaine.fr'. In what part of the file ( *kamailio.cfg* ) do I have to make these modifications ? This to avoid the flooding. How possibly write the rule of corresponding ACL. Thank you for your help. Best Regards,

9 years, 4 months

← Newer
1
...
5
6
7
8
9
10
11
...
15
Older →

Jump to page:

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 July 2015