sr-users January 2008

sr-users@lists.kamailio.org

131 participants
218 discussions

[OpenSER-Users] Why RPID related functions instead of PAI?
by Iñaki Baz Castillo 21 Jan '08

21 Jan '08

Hi, "Remote-Party-ID" is a draft ("draft-ietf-sip-privacy-04") [1] expired in 2002 while "P-Asserted-Identity" is a official RFC (3325) [2]. I'd like to know why OpenSer manages RPID in some functions ("auth" module) instead of PAI. I assume that some gateways just implement RPID and so, but can't understand why PAI is ignored (the use of PAI is extended in gateways). As a curiosity, both draft and RFC have really **common** parts, as chapter "Introduction" (4 in draft, 3 in RFC): "3/4 Introduction Various providers offering a telephony service over IP networks have selected SIP as a call establishment protocol. Their environments require a way for trusted network elements operated by the service providers (for example SIP proxy servers) to communicate the identity of the subscribers to such a service, yet also need to withhold this information from entities that are not trusted when necessary. Such networks typically assume some level of transitive trust amongst providers and the devices they operate. These networks need to support certain traditional telephony services and meet basic regulatory and public safety requirements. These include Calling Identity Delivery services, Calling Identity Delivery Blocking, and the ability to trace the originator of a call ... " So my question is again:why OpenSer supports RPID related functions and not PAI functions? Thanks for any explanation. [1] RPID: http://tools.ietf.org/html/draft-ietf-sip-privacy-04 [2] PAI: http://www.faqs.org/rfcs/rfc3325.html -- Iñaki Baz Castillo

3 3

[OpenSER-Users] Openser + Mediaproxy not working with 2 domains
by Andreti 21 Jan '08

21 Jan '08

Hi everybody, I'm working with Openser + Mediaproxy 1.9.0 and it seems that everything is working when the calls are establised between users attached to the same proxy server, even with different kind of NATs. However It doen't work in 2 different scenarios, and the result is exactly the same , the video and audio is only sent in one way. Scenario 1 ======== User A attached to the SIP proxy xxx.xxx.xxx.13 (Public IP) calls to a GW xxx.xxx.xxx.11 (Public IP) with several users internally associated. In this case the user A can see the video and audio sent by the GW, but the GW doesn't receive any RTSP stream. It seems that the mediaproxy doesn't do anything, why? maybe because the GW blongs to other domain (xxx.xxx.xxx.11) ? What can I do? If the GW calls to user A, it works fine (I can see the session in the mediaproxy with sessions.py) Scenario 2 ======== In this case, I have another GW with Public IP address xxx.xxx.xxx.14, but it doesn't include in the INVITE message the SDP body. The GW calls to the same user attached to the SIP proxy xxx.xxx.xxx.13 , and the behaviour is exactly the same as scenario 1, the calling site can sse the video and audio but the called can't. Unlike the previous scenario, the signalling is: INVITE without SDP --> 200 OK (SDP) -- > ACK (SDP) In theory, Mediaproxy 1.9.0 should support this procedure since it's a SIP standard mechanism, however the called party doesn't receive RTP stream. In my opinion, the problem could be related to scenario 1, I mean , the calling party is not attached to the SIP proxy (belongs to other domain) and when the 200 OK (SDP) message arrives to the SIP proxy, the mediaproxy doesn't do anything Sorry for the complex explanation. I've waste a lot of time trying to solve this solution and honestly I don't know what to do. Please, could somebody help?? I attach my openser.conf. I hope it helps. Andreti debug=5 # debug level (cmd line: -dddddddddd) #fork=yes #log_stderror=no # (cmd line: -E) log_facility=LOG_LOCAL0 # Uncomment these lines to enter debugging mode #fork=no log_stderror=yes listen=xxx.xxx.10.12 check_via=no # (cmd. line: -v) dns=no # (cmd. line: -r) rev_dns=no # (cmd. line: -R) #port=5060 #children=4 fifo="/tmp/openser_fifo" fifo_db_url="mysql://openser:openserrw@localhost/openser" # ------------------ module loading ---------------------------------- mpath = "/usr/local/lib/openser/modules/" # Uncomment this if you want to use SQL database loadmodule "mysql.so" loadmodule "domain.so" loadmodule "mediaproxy.so" loadmodule "uri_db.so" loadmodule "sl.so" loadmodule "tm.so" loadmodule "rr.so" loadmodule "maxfwd.so" loadmodule "usrloc.so" loadmodule "registrar.so" loadmodule "textops.so" loadmodule "avpops.so" loadmodule "uri.so" loadmodule "xlog.so" loadmodule "acc.so" loadmodule "auth_radius.so" loadmodule "group_radius.so" loadmodule "avp_radius.so" loadmodule "nathelper.so" # Uncomment this if you want digest authentication # mysql.so must be loaded ! loadmodule "auth.so" loadmodule "auth_db.so" # ----------------- setting module-specific parameters --------------- # -- usrloc params -- #modparam("usrloc", "db_mode", 0) # Uncomment this if you want to use SQL database # for persistent storage and comment the previous line modparam("usrloc", "db_mode", 2) modparam("usrloc", "timer_interval", 20) # -- auth params -- # Uncomment if you are using auth module # modparam("auth_db", "calculate_ha1", yes) # # If you set "calculate_ha1" parameter to yes (which true in this config), # uncomment also the following parameter) # modparam("auth_db", "password_column", "password") # -- acc params -- modparam("acc", "radius_flag", 1) modparam("acc", "radius_missed_flag", 1) #cambio 16_04_07 modparam("acc", "radius_missed_flag", 2) modparam("acc", "log_flag", 1) modparam("acc", "log_missed_flag", 1) modparam("acc", "service_type", 15) modparam("acc|auth_radius|group_radius|avp_radius", "radius_config", "/usr/local/etc/radiusclient-ng/radiusclient.conf") #modparam("acc", "radius_extra", "Sip-Src-IP=$si;Sip-Src-Port=$sp") #puesto para el CDRTool modparam("acc", "failed_transaction_flag", 1) modparam("acc", "report_cancels", 0) modparam("acc", "report_ack", 0) modparam("acc", "early_media", 0) modparam("acc", "log_level", 1) #modparam("acc", "radius_config", "/etc/openser/radius/client.conf") modparam("acc", "radius_extra", "Sip-Src-IP=$si;Sip-Src-Port=$sp;\ Sip-RPid=$avp(s:rpid); \ Source-IP=$si; \ Source-Port=$sp; \ Canonical-URI=$avp($can_uri); \ Billing-Party=$avp($billing_party); \ Divert-Reason=$avp(s:divert_reason); \ X-RTP-Stat=$avp(s:rtp_statistics); \ From-Header=$hdr(from); \ User-Agent=$hdr(user-agent); \ Contact=$hdr(contact); \ Event=$hdr(event)") # SIP-Proxy-IP=$avp(s:sip_proxy_ip)") # -- group_radius params -- modparam("group_radius", "use_domain", 1) # -- avpops params -- #modparam("avpops", "avp_aliases", "day=i:101;time=i:102") modparam("avpops","avp_aliases","can_uri=i:34") modparam("avpops","avp_aliases","billing_party=i:1") # -- rr params -- # add value to ;lr param to make some broken UAs happy modparam("rr", "enable_full_lr", 1) modparam("mediaproxy", "natping_interval", 60) modparam("registrar", "nat_flag", 2) # ------------------------- request routing logic ------------------- # main routing logic route{ # initial sanity checks -- messages with # max_forwards==0, or excessively long requests 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; }; # setflag(ACCOUNTING_FLAG); # avp_write("SER_IP","$avp(s:sip-proxy)"); # avp_write("$ru", "$avp(can_uri)"); # we record-route all messages -- to make sure that # subsequent messages will go through our proxy; that's # particularly good if upstream and downstream entities # use different transport protocol if (!method=="REGISTER") record_route(); # subsequent messages withing a dialog should take the # path determined by record-routing if (loose_route()) { # mark routing logic in request append_hf("P-hint: rr-enforced\r\n"); if(is_method("BYE")) { # log it all the time acc_rad_request("200 ok"); acc_log_request("200 ok"); setflag(1); } route(1); }; if (src_ip==193.36.177.227) { fix_nated_sdp("2"); }; if(is_method("INVITE") && !has_totag()) { # set the acc flags setflag(1); setflag(2); }; if (method=="MESSAGE") { setflag(1); }; if (!uri==myself) { # mark routing logic in request append_hf("P-hint: outbound\r\n"); route(1); }; # if the request is for other domain use UsrLoc # (in case, it does not work, use the following command # with proper names and addresses in it) if (uri==myself) { if (method=="REGISTER") { # Uncomment this if you want to use digest authentication # if (!www_authorize("sip.com", "subscriber")) { # www_challenge("sip.com", "0"); # exit; # }; if (!radius_www_authorize("")) { www_challenge("","1"); exit; } if (client_nat_test("3")) { setflag(2); force_rport(); fix_contact(); }; save("location"); exit; }; lookup("aliases"); if (!uri==myself) { append_hf("P-hint: outbound alias\r\n"); route(1); }; # native SIP destinations are handled using our USRLOC DB if (!lookup("location")) { # log to acc as missed call acc_rad_request("404 Not Found"); acc_log_request("404 Not Found"); sl_send_reply("404", "Not Found"); exit; }; }; if (method=="INVITE") { t_on_failure("1"); } else if (method == "BYE" || method == "CANCEL") { end_media_session(); }; if (loose_route()) { if (method=="INVITE" || method=="ACK") { use_media_proxy(); }; #if ((method=="INVITE" || method=="ACK") && !to_uri=="sip:frog1@xxx.xxx.10.12") { # use_media_proxy(); #}; t_relay(); return; }; if (client_nat_test("3") && !search("^Record-Route:")) { # Mark as NAT'ed force_rport(); fix_contact(); }; if (method=="INVITE") { t_on_reply("1"); }; if (method=="INVITE" || method=="ACK") { use_media_proxy(); }; #if ((method=="INVITE" || method=="ACK") && !to_uri=="sip:frog1@xxx.xxx.10.12") { # use_media_proxy(); #}; if (!t_relay()) { if (method=="INVITE" || method=="ACK") { end_media_session(); }; sl_reply_error(); }; append_hf("P-hint: usrloc applied\r\n"); # route(1); } route[1] { # send it out now; use stateful forwarding as it works reliably # even for UDP2TCP if (!t_relay()) { sl_reply_error(); }; exit; } failure_route[1] { end_media_session(); } onreply_route[1] { if (status=~"(183)|(2[0-9][0-9])") { if (client_nat_test("1")) { fix_contact(); }; use_media_proxy(); }; } -- View this message in context: http://www.nabble.com/Openser-%2B-Mediaproxy-not-working-with-2-domains-tp1… Sent from the OpenSER Users Mailing List mailing list archive at Nabble.com.

2 2

[OpenSER-Users] Calls disconnect automatically
by VoIP Forums www.Go4Calls.com 21 Jan '08

21 Jan '08

Hi Friends, I start getting one problem, the calls disconnect automatically in 30 and 32 sec. I am using openser + rtpproxy before with the same openser.cfg it was running smoothly and once traffic increased this problem appeared. Could you please help me to solve this issue because i put openser in production and now no one can make long call. Regards, www.Go4Calls.Com VoIP Forums _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

2 1

Re: [OpenSER-Users] xlite with openser / hello world posts SOLVED
by A.smith 21 Jan '08

21 Jan '08

Hi Moujane, In case you haven´t worked it out yet, I managed to get an openser.cfg to work for simple testing between XLite or other SIP client. Its a shame there isnt a working config easily findable on the openser site or other internet resource for those people new to SIP and OpenSER.... :S Try this, for me it works on OpenSER 1.2.2 # SECTION 1 - GLOBAL DEFINTIONS debug=3 fork=yes log_stderror=no #fork=no #log_stderror=yes listen=10.10.10.10 #put your server IP here port=5060 disable_dns_blacklist=yes dns=no rev_dns=no children=4 # SECTION 2 - MODULE DEFINTION mpath="/usr/local/lib/openser/modules" loadmodule "sl.so" loadmodule "tm.so" loadmodule "rr.so" loadmodule "maxfwd.so" loadmodule "usrloc.so" loadmodule "textops.so" loadmodule "xlog.so" loadmodule "registrar.so" # SECTION 3 - MODULE CONFIGURATION modparam("usrloc", "db_mode", 0) modparam("rr", "enable_full_lr", 1) # main routing logic FOR RADIUS ACC ACCOUNTING route{ if (!mf_process_maxfwd_header("15")) { sl_send_reply("483","Too Many Hops"); exit; }; if (msg:len >= max_len ) { sl_send_reply("513", "Message too big"); exit; }; if (method=="REGISTER") { record_route(); if (!save("location")) { sl_reply_error(); }; exit; }; 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 (!lookup("location")) { sl_send_reply("404", "Not Found"); exit; }; append_hf("P-hint: usrloc applied\r\n"); }; route(1); } # SECTION 5 - SECONDARY ROUTE BLOCKS route[1] { if (!t_relay()) { sl_reply_error(); }; exit; } ________________________________________________ Message sent using UK Grid Webmail 2.7.9

3 3

[OpenSER-Users] Adding "Reason: SIP ; cause=200" header when CANCEL in forking scenarios
by Iñaki Baz Castillo 21 Jan '08

21 Jan '08

Hi, according to RFC 3326 [1] (Reason Header): 3.1 Call Completed Elsewhere A proxy forks an INVITE request and one of the branches returns a 200 (OK). The forking proxy includes this status code in a Reason header field in the CANCEL request that it sends to the rest of the branches. Reason: SIP ;cause=200 ;text="Call completed elsewhere" With this behaviour, if an AoR is registered in two phones and one of them answers a call, that call will not appear as MISSED in the other phone (if the phone supports "Reason" headers). Is it possible OpenSer to add this header when cancelling the rest of ringing branches? If not, do you think it could be a feature request? [1] http://www.faqs.org/rfcs/rfc3326.html -- Iñaki Baz Castillo

3 2

[OpenSER-Users] Routing logic Check
by SP GLE 21 Jan '08

21 Jan '08

Hi, Is there any tool to validate an OpenSer Routing Configuration Logic ? We would like to validate a configuration to avoid regressions on routing behaviour. Regards. _____________________________________________________________________________ Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail http://mail.yahoo.fr

2 1

Re: [OpenSER-Users] Calls disconnect automatically
by VoIP Forums www.Go4Calls.com 21 Jan '08

21 Jan '08

Hi sorry, I forget to give my openser.cfg, there is one more point if i am using STUN server in our linksys device the call goes normal for long time till user finish the call. It seems something wrong in NAT configuration. # # sample config file to be used with nathelper/rtpproxy # # # ----------- global configuration parameters ------------------------ debug=7 # 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=no # (cmd. line: -v) dns=no # (cmd. line: -r) rev_dns=no # (cmd. line: -R) listen=212.XXX.XXX.XXX:5064 #port=5064 children=4 disable_dns_blacklist = yes # --- module loading mpath="/usr/local/lib/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" modparam("mi_fifo", "fifo_name", "/tmp/openser_fifo") modparam("usrloc", "db_mode", 2) modparam("auth_db", "calculate_ha1", yes) modparam("auth_db", "password_column", "password") modparam("usrloc|auth_db","db_url","mysql://proxy:MoHaKa21@192.168.1.50/emafone") # -- usrloc params -- modparam("usrloc", "nat_bflag", 6) # -- registrar params -- modparam("registrar|nathelper", "received_avp", "$avp(i:42)") # -- auth params -- # -- rr params -- modparam("rr", "enable_full_lr", 1) # -- nathelper modparam("nathelper", "natping_interval", 0) modparam("nathelper", "ping_nated_only", 1) modparam("nathelper", "rtpproxy_sock", "unix:/var/run/rtpproxy.sock") modparam("nathelper", "rtpproxy_disable", 0) modparam("nathelper", "rtpproxy_disable_tout", 60) modparam("nathelper", "rtpproxy_tout", 1) modparam("nathelper", "rtpproxy_retr", 5) modparam("nathelper", "sipping_method", "OPTIONS") modparam("nathelper", "received_avp", "$avp(i:801)") #modparam("nathelper", "rtpproxy_sock", "udp:212.100.235.229:22222") #modparam("nathelper", "rtpproxy_sock", "/var/run/rtpproxy.sock") #modparam("nathelper", "natping_interval", 30) #modparam("nathelper", "ping_nated_only", 1) #modparam("nathelper", "sipping_bflag", 7) #modparam("nathelper", "sipping_from", "sip:pinger@openser.org") # --- 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("212.XXX.XXX.XXX", "subscriber")) { www_challenge("212.XXX.XXX.XXX", "0"); exit; }; if (isflagset(5)) { setbflag(6); # if you want OPTIONS natpings uncomment next # setbflag(7); }; save("location"); exit; }; #########PSTTN CALL ############################################# if (uri=~"sip:00[1-9][0-9]+@.*") { strip(2); rewritehostport("212.XXX.XXX.XXX:5060"); route(1); exit; }; ################################################################### if (!lookup("location")) { sl_send_reply("404", "Not Found"); exit; }; 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(6); }; } route[3] { if (is_method("BYE|CANCEL")) { unforce_rtp_proxy(); } else if (is_method("INVITE")){ force_rtp_proxy(); t_on_failure("1"); }; if (isflagset(5)) search_append('Contact:.*sip:[^>[:cntrl:]]*', ';nat=yes'); t_on_reply("1"); } failure_route[1] { if (isbflagset(6) || isflagset(5)) { unforce_rtp_proxy(); } } onreply_route[1] { if ((isflagset(5) || isbflagset(6)) && status=~"(183)|(2[0-9][0-9])") { force_rtp_proxy(); } search_append('Contact:.*sip:[^>[:cntrl:]]*', ';nat=yes'); if (isbflagset(6)) { fix_nated_contact(); } exit; } Regards, www.Go4Calls.Com VoIP Forums From: go4calls(a)hotmail.com To: users(a)lists.openser.org; users(a)openser.org Subject: Calls disconnect automatically Date: Sun, 20 Jan 2008 18:01:48 +0800 Hi Friends, I start getting one problem, the calls disconnect automatically in 30 and 32 sec. I am using openser + rtpproxy before with the same openser.cfg it was running smoothly and once traffic increased this problem appeared. Could you please help me to solve this issue because i put openser in production and now no one can make long call. Regards, www.Go4Calls.Com VoIP Forums Express yourself instantly with MSN Messenger! MSN Messenger _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

5 9

[OpenSER-Users] hor to register ?
by Aaash shah 21 Jan '08

21 Jan '08

hi i am making project on SIP handoffs i already install openSER on fedora i dont know how to register it so please give me reply thanks -- "Never Ignore Anyone Who Cares 4 u, Becoz one day u will Realize that u have lots a diamond while u were buzy in collecting stones...."

1 0

[Serusers] lookup_contacts for natted clients returns local ip
by Tomasz Zieleniewski 21 Jan '08

21 Jan '08

Hi, I have the followning natted contact in my location table: mysql> select * from location where uid ='tw(a)sip.touk.pl'; +--------------------+-------+-----------------------------------------------------------+ | contact | flags | received | +--------------------+-------+-----------------------------------------------------------+ | sip:tw@192.168.7.2 | 1 | sip:80.53.110.142:61066;dstip=192.168.129.74;dstport=5060 | +--------------------+-------+-----------------------------------------------------------+ when I invoke lookup_contacts the ruri has local address 192.168.7.2instead of public one. Is this correct behaviour? Please point me is this should work as I think. Thank You for any help Tomasz

2 3

[OpenSER-Users] Obtaining the domain of "Refer-to" URI
by Iñaki Baz Castillo 21 Jan '08

21 Jan '08

Hi, in order to match the domain of "Refer-to" header I must do a dirty string substitution: $avp(s:rt) = $rt; avp_subst("$avp(s:rt)", "/(.*(a)|[;?].*)//gi"); If for example: Refer-To: <sip:bob@biloxi.example.net?Accept-Contact=sip:bobsdesk. biloxi.example.net&Call-ID%3D55432%40alicepc.atlanta.example.com> Then $avp(s:rt) is "biloxi.example.net". Couldn't be possible to have generic string transformations to get part of a URI in any header/variable? Is there any other way I don't know to get it easily? Thanks. -- Iñaki Baz Castillo ibc(a)in.ilimit.es

6 14

← Newer
1
...
7
8
9
10
11
12
13
...
22
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 January 2008