sr-users June 2008

sr-users@lists.kamailio.org

124 participants
231 discussions

[OpenSER-Users] OpenSer not matching a correct reply to its transaction ???
by Iñaki Baz Castillo 22 Jun '08

22 Jun '08

Hi, I'm experimenting a annoying problem since it seems that my OpenSer, sometimes, doesn't match correct replies from my gateway to client transactions initiated by OpenSer. AFAIK all is correct but OpenSer doesn't match the "100 Trying", neither the "183" and ends the transactoion after "fr_timer" (and before it OpenSer sends INVITE retransmissions). The following is n example of non mathed response. I can't understand why, the top branch matches and also the CSeq (as RFC 3261 17.1.3 indicates): INVITE from OpenSer to gateway: --------------------------- INVITE sip:0034687105267@66.44.0.144 SIP/2.0 Record-Route: <sip:88.99.3.10;lr=on;ftag=as5fc7617f> Via: SIP/2.0/UDP 88.99.3.10;branch=z9hG4bK87ab.47b6f072.0 Via: SIP/2.0/UDP 192.168.1.203:5060;received=88.99.1.192;branch=z9hG4bK20b50ef9;rport=10000 From: <sip:202@sip.domain.net>;tag=as5fc7617f To: <sip:XXXXXXXXX@sip.domain.net> Contact: <sip:202@88.99.1.192:10000> Call-ID: 70af31e43126fa0917146b5523ea4add(a)sip.domain.net CSeq: 103 INVITE User-Agent: domain - Asterisk PBX Max-Forwards: 69 Date: Thu, 19 Jun 2008 10:45:03 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Content-Type: application/sdp Content-Length: 284 X-Called-E164: +34XXXXXXXXX P-Asserted-Identity: <sip:XXXXXXXXX@88.99.3.10> v=0 o=root 1468 1469 IN IP4 192.168.1.203 s=session c=IN IP4 88.99.3.10 t=0 0 m=audio 60884 RTP/AVP 8 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - - a=ptime:20 a=sendrecv ----------------------------------------------- "100 Trying" from gateway ----------------------------------------------- SIP/2.0 100 Trying From: <sip:202@sip.domain.net>;tag=as5fc7617f To: <sip:XXXXXXXXX@sip.domain.net>;tag=5ad3254683132008619125120 Call-ID: 70af31e43126fa0917146b5523ea4add(a)sip.domain.net CSeq: 103 INVITE Allow: ACK,BYE,CANCEL,INVITE,OPTIONS,INFO,SUBSCRIBE,REFER,NOTIFY,PRACK Via: SIP/2.0/UDP 88.99.3.10;branch=z9hG4bK87ab.47b6f072.0 Via: SIP/2.0/UDP 192.168.1.203:5060;received=88.99.1.192;rport=10000;branch=z9hG4bK20b50ef9 Contact: <sip:66.44.0.144:5060;transport=UDP> Content-Length: 0 ----------------------------------------------- This just occurs some times (3% of outgoing calls, that's really enough). I'm using OpenSer 1.3.2 complied in Debian Etch as deb package and of course use t_relay(). Any idea? IMHO this error doesn't make sense :( -- Iñaki Baz Castillo ibc(a)in.ilimit.es

4 4

[OpenSER-Users] OpenSER Proxy & Presence Server
by Ross Beer 21 Jun '08

21 Jun '08

Hi, I have a working OpenSER Proxy to asterisk and would like the proxy server to handle Presence. I have tried adding all of the usual presence code, however it seams that messages are not getting back to the clients. I can see time outs in the SIP messages. Can anyone see what has gone wrong with this code? The setup is: Calls & Registrations: Client --> OpenSER --> Asterisk SIP Messages & Presence: Client --> OpenSER Thank you for your help in advance. Ross ----------------------------- CONFIG ---------------------- # ----------- global configuration parameters ------------------------ debug=3 # debug level (cmd line: -dddddddddd) fork=yes log_stderror=yes # (cmd line: -E) #/* Uncomment these lines to enter debugging mode #fork=no #log_stderror=yes #*/ check_via=yes # (cmd. line: -v) dns=no # (cmd. line: -r) rev_dns=no # (cmd. line: -R) listen=udp:<IP>:5065 #port=5065 children=4 # --- module loading mpath="/usr/local/lib64/openser/modules/" loadmodule "mysql.so" loadmodule "sl.so" loadmodule "tm.so" loadmodule "rr.so" loadmodule "maxfwd.so" loadmodule "usrloc.so" loadmodule "registrar.so" loadmodule "textops.so" loadmodule "nathelper.so" loadmodule "auth.so" loadmodule "auth_db.so" loadmodule "mi_fifo.so" loadmodule "presence.so" loadmodule "presence_xml.so" loadmodule "xcap_client.so" loadmodule "avpops.so" #loadmodule "siptrace.so" # --- setting module parameters # -- mi_fifo params -- modparam("mi_fifo", "fifo_name", "/tmp/openser_fifo") modparam("usrloc|auth_db|presence|presence_xml|xcap_client","db_url","mysql://openser:openserrw@<address>/openser") # -- usrloc params -- modparam("usrloc", "db_mode", 2) modparam("usrloc", "nat_bflag", 6) # -- registrar params -- modparam("registrar|nathelper", "received_avp", "$avp(i:42)") # -- auth params -- modparam("auth_db", "calculate_ha1", yes) modparam("auth_db", "password_column", "password") # -- rr params -- modparam("rr", "enable_full_lr", 1) # -- nathelper params --- modparam("nathelper", "rtpproxy_sock", "udp:127.0.0.1:7890") modparam("nathelper", "natping_interval", 30) modparam("nathelper", "ping_nated_only", 1) modparam("nathelper", "sipping_bflag", 7) modparam("nathelper", "sipping_from", "sip:<address>") # -- presence parameters --- modparam("presence", "max_expires", 3600) modparam("presence", "server_address", "sip:<IP>:5065" ) modparam("xcap_client", "periodical_query", 0) modparam("xcap_client", "query_period", 50) modparam("presence_xml", "integrated_xcap_server", 1) #modparam("presence_xml", "xcap_server", "") modparam("presence","fallback2db",1) #modparam("siptrace", "trace_flag", 0) #modparam("siptrace", "trace_on", 1) #modparam("siptrace", "table", "sip_trace") # --- main routing logic route { ###################################################### # CHECK FOR BAD SIP MESSAGES # ###################################################### if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); exit; }; if (msg:len >= 2048 ) { sl_send_reply("513", "Message too big"); exit; }; ###################################################### # CHECK FOR CLIENT BEHIND A NAT ROUTER # ###################################################### route(2); if (!method=="REGISTER") record_route(); ###################################################### # PROCESS SUBSCRIBE & NOTIFY MESSAGES # ###################################################### if(method=="PUBLISH") { route(4); } if(method=="SUBSCRIBE") { route(4); } if (loose_route()) { append_hf("P-hint: rr-enforced\r\n"); route(1); }; ##################################################### # SAVE LOCATION OF CLIENT FOR MESSAGES # ##################################################### if (method=="REGISTER") { save("location","0x02"); } #################################################### # CHECK IF REGISTERED LOCALY ELSE PASS TO ASTERISK # #################################################### if (!lookup("location")) { append_hf("P-hint: outbound\r\n"); } else { append_hf("P-hint: usrloc applied\r\n"); } route(1); } route[1] { if (subst_uri('/(sip:.*);nat=yes/\1/')){ setbflag(6); }; if (isflagset(5)||isbflagset(6)) { route(3); } if (!t_relay()) { sl_reply_error(); }; exit; } route[2]{ force_rport(); if (nat_uac_test("19")) { if (method=="REGISTER") { fix_nated_register(); } else { fix_nated_contact(); }; setflag(5); }; } route[3] { if (is_method("BYE")) { unforce_rtp_proxy(); } else if (is_method("INVITE")) { force_rtp_proxy(); t_on_failure("2"); }; if (isflagset(5)) { search_append('Contact:.*sip:[^>[:cntrl:]]*', ';nat=yes'); } t_on_reply("1"); } route[4] { # absorb retransmissions if (! t_newtran()) { sl_reply_error(); exit; }; if(is_method("PUBLISH")) { if($hdr(Sender)!= NULL) { handle_publish("$hdr(Sender)"); } else { handle_publish(); } t_release(); } if(is_method("SUBSCRIBE")) { handle_subscribe(); t_release(); }; exit; } branch_route[4] { log("new branch at $ru\n"); } onreply_route[4] { log("incoming reply\n"); } failure_route[2] { if (isbflagset(6) || isflagset(5)) { unforce_rtp_proxy(); } } onreply_route[1] { if ((isflagset(5) || isbflagset(6)) && status=~"(183)|(2[0-9][0-9])" && is_method("INVITE")) { force_rtp_proxy(); } search_append('Contact:.*sip:[^>[:cntrl:]]*', ';nat=yes'); if (isbflagset(6)) { fix_nated_contact(); } exit; } _________________________________________________________________ http://clk.atdmt.com/UKM/go/msnnkmgl0010000002ukm/direct/01/

3 2

[OpenSER-Users] Loading user preferences using avp_load_radius
by Ruchir 21 Jun '08

21 Jun '08

Hi Everyone, I have a problem. I use avp_load_radius to load caller or callee preferences and use them. But when I do call forwarding, it will load original caller's preferences for further processing instead of the user who has configured call forwarding. Ideally we should load the preferences of the user who forwarded the call as caller preferences. We can do this using avp_db_load but I think there should be provision in avp_load_radius as well. Currently it supports "caller", "callee" & "digest". I think it should support parameters same as avp_db_load. Let me know your thoughts about this.

2 2

[OpenSER-Users] Perl module autoload.
by Alex Balashov 20 Jun '08

20 Jun '08

Perhaps this has been asked before, but where are all these core and module functions that the Perl module documentation alleges to be exposed via "autoload"? When I try to run any of them as methods of the OpenSER object, the Perl module tells me they exist but are unavailable, or something to that general effect. So, for now, the only use I get out of the perl module is to be able to communicate to the OpenSER route plan via setting AVPs. Is this going to change any time soon? Will functions like $m->rewrite_ruri() eventually work? Or am I missing some kind of autoload option? -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599

2 1

[OpenSER-Users] setting caller id in FROM
by David Villasmil 20 Jun '08

20 Jun '08

Hello all, I'm required to set a specific caller id on an outbound call. I've tried with P-Asserted-Id but it seems the carrier wants me to change the FROM-URI, I'm trying to set $fU but I get an error saying: line 380, column 17-18: invalid left operand in assignment So I assume $fU is not readable? How do i change it? thanks

4 4

[OpenSER-Users] About openser redirect - forward
by Valerio Di Marino 20 Jun '08

20 Jun '08

Hi to all, I am able to start correctly openser, using mysql for authentication and user location. Then, I would configure redirect, but I don't know how. I have this situation: Internal network behind parallel NAT (any port open) Possibility to have a public IP Users should authenticate on openser, to being redirect (or forwarded ?) all to a single SIP provider, using the same credentials. As you can see, I an not clear if I have to use redirect or forward (I suspect forward). Is it possible ? Can you help me, suggesting also a possible configuration ? Thanks to all. Valerio

2 1

[OpenSER-Users] OpenSER Proxy to Asterisk & MESSAGE handler
by Ross Beer 20 Jun '08

20 Jun '08

Hi All, I am using OpenSER as a NAT proxy for asterisk and would like to use it to deliver SIP 'MESSAGES' between clients. At the moment I have the following configuration however messages are not being sent to the other clients. Instead they are being passed to asterisk. I would be very grateful if anyone could point me in the right direction. Ross ---------- Config -------------- debug=5 # debug level (cmd line: -dddddddddd) fork=yes log_stderror=yes # (cmd line: -E) #/* Uncomment these lines to enter debugging mode #fork=no #log_stderror=yes #*/ check_via=yes # (cmd. line: -v) dns=no # (cmd. line: -r) rev_dns=no # (cmd. line: -R) port=5065 children=4 # --- module loading mpath="/usr/local/lib64/openser/modules/" loadmodule "mysql.so" loadmodule "sl.so" loadmodule "tm.so" loadmodule "rr.so" loadmodule "maxfwd.so" loadmodule "usrloc.so" loadmodule "registrar.so" loadmodule "textops.so" loadmodule "nathelper.so" loadmodule "auth.so" loadmodule "auth_db.so" loadmodule "mi_fifo.so" # --- setting module parameters # -- mi_fifo params -- modparam("mi_fifo", "fifo_name", "/tmp/openser_fifo") modparam("usrloc|auth_db","db_url","<MYSQL CONNECTION STRING>") # -- usrloc params -- modparam("usrloc", "db_mode", 2) modparam("usrloc", "nat_bflag", 6) # -- registrar params -- modparam("registrar|nathelper", "received_avp", "$avp(i:42)") # -- auth params -- modparam("auth_db", "calculate_ha1", yes) modparam("auth_db", "password_column", "password") # -- rr params -- modparam("rr", "enable_full_lr", 1) # -- nathelper params --- modparam("nathelper", "rtpproxy_sock", "udp:127.0.0.1:7890") modparam("nathelper", "natping_interval", 30) modparam("nathelper", "ping_nated_only", 1) modparam("nathelper", "sipping_bflag", 7) modparam("nathelper", "sipping_from", "sip:<ADDRESS>") # --- main routing logic route{ if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); exit; }; if (msg:len >= 2048 ) { sl_send_reply("513", "Message too big"); exit; }; # NAT detection route(2); if (!method=="REGISTER") { record_route(); } if (loose_route()) { append_hf("P-hint: rr-enforced\r\n"); route(1); }; if (!uri==myself) { append_hf("P-hint: outbound\r\n"); route(1); }; if (uri==myself) { if (method=="REGISTER") { if (!www_authorize("", "subscriber")) { www_challenge("", "0"); exit; }; if (isflagset(5)) { # set branch flag -- when someone will call this user # the INVITE will have branch flag 6 set after lookup("location") setbflag(6); # if you want OPTIONS natpings uncomment next # setbflag(7); }; save("location"); exit; }; if (!lookup("location")) { sl_send_reply("404", "Not Found"); exit; }; append_hf("P-hint: usrloc applied\r\n"); }; if(method=="MESSAGE") { if (!lookup("location")) { sl_send_reply("404", "User Offline"); exit; } route(4); } if (method=="REGISTER") { save("location"); } route(1); } route[1] { if (subst_uri('/(sip:.*);nat=yes/\1/')){ setbflag(6); }; if (isflagset(5)||isbflagset(6)) { route(3); } if (!t_relay()) { sl_reply_error(); }; exit; } route[2]{ force_rport(); if (nat_uac_test("19")) { if (method=="REGISTER") { fix_nated_register(); } else { fix_nated_contact(); }; setflag(5); }; } route[3] { if (is_method("BYE")) { unforce_rtp_proxy(); } else if (is_method("INVITE")) { force_rtp_proxy(); t_on_failure("2"); }; if (isflagset(5)) { search_append('Contact:.*sip:[^>[:cntrl:]]*', ';nat=yes'); } t_on_reply("1"); } route[4] { if (!t_relay()) { sl_reply_error(); }; exit; } failure_route[2] { if (isbflagset(6) || isflagset(5)) { unforce_rtp_proxy(); } } onreply_route[1] { if ((isflagset(5) || isbflagset(6)) && status=~"(183)|(2[0-9][0-9])" && is_method("INVITE")) { force_rtp_proxy(); } search_append('Contact:.*sip:[^>[:cntrl:]]*', ';nat=yes'); if (isbflagset(6)) { fix_nated_contact(); } exit; } ---------- End Config -------------- _________________________________________________________________ http://clk.atdmt.com/UKM/go/msnnkmgl0010000007ukm/direct/01/

2 1

[OpenSER-Users] Resolved: OpenSER Proxy to Asterisk & MESSAGE handler
by Ross Beer 20 Jun '08

20 Jun '08

Hi, I have resolved the issue I was having. Just used 'save and no reply' instead of just save. Thanks! Ross _________________________________________________________________ http://clk.atdmt.com/UKM/go/msnnkmgl0010000002ukm/direct/01/

1 0

[OpenSER-Users] Doubt about OpenSER REGISTER by third-party
by Marcio 20 Jun '08

20 Jun '08

Hi all, I have a doubt, about to constructing a REGISTER Request by third-party, if is possible with OpenSER`s modules??? and how? If can to force a "Proxy A", to perform a Register of the UAc on behalf of an UAc to Proxy/Registrar "B".... 10.2 item rfc3261....."Registration on behalf of a particular address-of-record can be performed by a suitably authorized third party."... best regards, Marcio

2 2

[OpenSER-Users] NEW FEATURE: dialog profiling
by Bogdan-Andrei Iancu 20 Jun '08

20 Jun '08

Hi, I just committed in SVN trunk (1.4, next major release) support for dialog profiling. What dialog profiling is ========================= Dialog profiling is a mechanism that helps in classifying, sorting and keeping trace of certain types of dialogs, using whatever properties of the dialog (like caller, destination, type of calls, etc). Dialogs can be dynamically added in different (and several) profile tables - logically, each profile table can have a special meaning (like dialogs outside the domain, dialogs terminated to PSTN, etc). Information provided by the profiles can be used also for doing real load-balancing - by real, I mean routing decisions based on load. So far dispatcher module can do probabilistic dispatching with no feedback on the actual load of the peer (or about the call success). See example 3 - load balancing between 2 asterisk boxes with identical capacities. Being able to actually trace the ongoing dialog, gives liberty to do more complex routing logics. There are two types of profiles: * with no value - a dialog simply belongs to a profile. (like outbound calls profile). There is no other additional information to describe the dialog's belonging to the profile; * with value - a dialog belongs to a profile having a certain value (like in caller profile, where the value is the caller ID). The belonging of the dialog to the profile is strictly related to the value. A dialog can be added to multiple profiles in the same time. What it should be used for =========================== Example 1: Count the calls terminating to PSTN in order to monitor the load. Before routing the call the GW, check if the number of ongoing calls (to the GW) do not exceed some value. modparam("dialog","profiles_no_value","pstn_calls") .... /* do some checking */ get_dialog_size("pstn_calls","$avp(cnt)"); if ( $avp(cnt) > 32 ) { sl_send_reply("500","GW full"); exit; } set_dlg_profile("pstn_calls"); /* route to the GW */ ..... Example 2: Allow only 2 parallel calls per user - use a profile with value to count the outgoing calls for each subscriber modparam("dialog","profiles_with_value","caller") .... /* do some checking */ get_dialog_size("caller","$fu","$avp(cnt)"); if ( $avp(cnt) > 2 ) { sl_send_reply("403","Not allowed"); exit; } set_dlg_profile("caller","$fu"); /* route the call */ ..... Example 3: Do load balancing between 2 asterisk boxes with identical capacities - use a profile with values to count the ongoing calls through each Asterisk box. modparam("dialog","profiles_with_value","asterisk") .... /* do some checking */ get_dialog_size("asterisk","box1","$avp(cnt1)"); get_dialog_size("asterisk","box2","$avp(cnt2)"); if ( $avp(cnt1) > $avp(cnt2) ) { setdsturi("sip:IP_BOX2:PORT_BOX2"); set_dlg_profile("asterisk","box2"); } else { setdsturi("sip:IP_BOX1:PORT_BOX1"); set_dlg_profile("asterisk","box1"); } /* route the call */ ..... Of course, this can be extended for asymmetric load or for multiple boxes. Regards, Bogdan

2 3

← Newer
1
...
4
5
6
7
8
9
10
...
24
Older →

Jump to page:

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 June 2008