sr-users

sr-users@lists.kamailio.org

4 participants
37456 discussions

[Users] LCR failure_route appending characters to invite
by Lyle Thaut 17 Apr '07

17 Apr '07

Hello All, I'm having problems when calling next_gw from a failure_route. It appears that extra characters are getting appended after the transport=udp portion of the INVITE. This first INVITE that goes out on the wire looks normal. I'm intentionally causing the 1st gateway to be offline (time out) so it failure routes to the next gw: SIP/SD Request: INVITE sip:1310xxxyyyy@192.168.18.13:5060;transport=udp The next INVITE to the next gw (called from failure_route) fails due to extra characters. Note the \000dp after the transport=udp: SIP/SD Request: INVITE sip:1310xxxyyyy@192.168.142.40:5060;transport=udp\000dp And the same thing happens on the next failure route with the \0009b SIP/SD Request: INVITE sip:1310xxxyyyy@192.168.101.202:5060;transport=udp\0009b Looks like I've got extras characters on each of the bad INVITES. \0009b = .9b & \000dp = .dp A sample config that reproduces the problem looks like this: # ------------------------------------------------------------- route{ ...snip... route(1); } # ------------------------------------------------------------- route[1] { if(!load_gws()){ sl_send_reply("500", "Internal server error\n"); xlog("LCR Failure: Unable to load gateways\n"); exit; }; if(!next_gw()){ sl_send_reply("503", "Service not available"); xlog("LCR Failure: No gateways found\n"); exit; }; t_on_failure("1"); # Process Failures if (!t_relay()) { sl_reply_error(); }; exit; } # ------------------------------------------------------------- failure_route[1]{ if(!next_gw()){ t_reply("503", "Service not available"); xlog("$CwrLCR Failure: No gateways found$Cxx\n"); exit; }; t_relay(); exit; } # ------------------------------------------------------------- If I replace the next_gw call in the failure_route with a rewrite_uri(), append_branch() and a t_relay() then it works as desired so I believe that the problem is LCR related. Debug shows the URI's seem to be correct in the gw_uri_avp: 2(12902) load_gws(): DEBUG: Added gw_uri_avp <sip:1|0@192.168.101.202:5060;transport=udp> 2(12902) load_gws(): DEBUG: Added gw_uri_avp <sip:1|0@192.168.142.40:5060;transport=udp> 2(12902) load_gws(): DEBUG: Added gw_uri_avp <sip:|0@192.168.18.13:5060;transport=udp> System: Solaris10/Sparc64 OpenSER: 1.2.0 with TLS Any suggestions or thoughts? Thanks, Lyle

3 3

[Users] ds_select_dst("1","0"): hash on callid
by Mark Price 17 Apr '07

17 Apr '07

Hi, I'm having some interesting results with using the ds_select_dst function to load balance asterisk boxes. I.e. packets with method==INVITE are routed with ds_select_dst. when using two destinations in the dispatcher.txt file, the calls get disproportionately sent to one destination, unless i'm using the callid hash. However callid's property of changing with every invite (reinvite, etc) causes me to question it's suitableness. For example: A calls B, puts B on hold, takes B off hold. Error prone or not? A calls B, puts B on hold, calls C, conferences. Ad nauseum. Am I missing something? Is there a better approach? Should it Just Work, even hashing on callid? Mark Price

2 1

[Users] Openser 1.1.0 Debian and OSF module
by Howard Tang 17 Apr '07

17 Apr '07

Hi All, I found that the Openser 1.1.0 Debian package doesn't install the OSF module. I would like to make use of the OSF module now, what will the best way to get the OSF module? can i just simple do apt-get install openser again to upgarde to 1.1.1 ? will that come with OSF module? Since the system is currently production, i want to avoid any downtime or server reboot. Regards, Howard

2 3

[Users] MI_XMLRPC Compilation problem on OpenSUSE 10.2 - 64 bits
by Edson 16 Apr '07

16 Apr '07

Hi, Folks... When I try to compile OpenSER 1.2.0 with MI_XMLRPC support, I get this error: mi_xmlrpc.c:44:26: error: xmlrpc_abyss.h: No such file or directory mi_xmlrpc.c: In function âmod_child_initâ: mi_xmlrpc.c:162: warning: implicit declaration of function âxmlrpc_server_abyss_init_registryâ mi_xmlrpc.c:172: error: âxmlrpc_server_abyss_rpc2_handlerâ undeclared (first use in this function) mi_xmlrpc.c:172: error: (Each undeclared identifier is reported only once mi_xmlrpc.c:172: error: for each function it appears in.) mi_xmlrpc.c:178: error: âxmlrpc_server_abyss_default_handlerâ undeclared (first use in this function) make[1]: *** [mi_xmlrpc.o] Error 1 I know that its because of the lack of the xmlrpc_abyss.h file, but my problem is where to find this file? In which package did it reside? As sad on the subject Im using OpenSUSE 10.2 - 64 bits on a Xeon machine. Edson. ------ "It wouldn't be sell if it were easy..." (myself)

2 2

[Users] lcr for failover broken after upgrade to 1.2
by Brandon Price 16 Apr '07

16 Apr '07

I was using lcr for failover with a route that looks like.... ------------------------------------------------------------------------ ------------ { if(!t_check_status("200")){ xlog("got to failure route 2 lcr"); if (!next_gw()) { xlog ("503, service not available - no more gateways"); t_reply("503", "Service not available - no more gateways"); exit; } else { t_on_failure("2"); xlog("lcr forwarding invite from $fu to -> $ru"); t_relay(); return; }; }; } ------------------------------------------------------------------------ ------------ The t_relay after the line that says xlog("lcr forwarding invite from $fu to -> $ru"); no longer works. I can see the correct $fu and $ru values in the xlog output but the t_relay is never done. For example.. my.sip.proxy.ip -> my.pstn.gw.ip SIP/SDP Request: INVITE sip: +13143212222@my.pstn.gw.ip:5060;transport=udp, with session description my.pstn.gw.ip -> my.sip.proxy.ip SIP Status: 100 Trying my.pstn.gw.ip -> my.sip.proxy.ip SIP Status: 604 Invalid Number Format my.sip.proxy.ip -> my.pstn.gw.ip SIP Request: ACK sip: +13143212222@my.pstn.gw.ip:5060;transport=udp just ends there where as witn 1.1 it would then forward the invite to the next gw in the lcr table. Any help would be greatly appreciated.

1 0

[Users] MI_XMLRPC Compilation problem on OpenSUSE 10.2 -64
by Edson 16 Apr '07

16 Apr '07

Hi, Folks... When I try to compile OpenSER 1.2.0 with MI_XMLRPC support, I get this error: mi_xmlrpc.c:44:26: error: xmlrpc_abyss.h: No such file or directory mi_xmlrpc.c: In function âmod_child_initâ: mi_xmlrpc.c:162: warning: implicit declaration of function âxmlrpc_server_abyss_init_registryâ mi_xmlrpc.c:172: error: âxmlrpc_server_abyss_rpc2_handlerâ undeclared (first use in this function) mi_xmlrpc.c:172: error: (Each undeclared identifier is reported only once mi_xmlrpc.c:172: error: for each function it appears in.) mi_xmlrpc.c:178: error: âxmlrpc_server_abyss_default_handlerâ undeclared (first use in this function) make[1]: *** [mi_xmlrpc.o] Error 1 I know that its because of the lack of the xmlrpc_abyss.h file, but my problem is where to find this file? In which package did it reside? As sad on the subject Im using OpenSUSE 10.2 - 64 bits on a Xeon machine Edson Gellert Schubert Phone :(0xx47) 3422-6556 Celular:(0xx47) 9107-6556 MSN :egschubert@hotmail.com Brasil - (GMT-3)

1 0

[Users] rtpproxy - ICMP unreacheable host
by Amanda Mattiuz 16 Apr '07

16 Apr '07

Hello! I'm using rtpproxy to handle NAT, but right now I have problems of unreacheable host... I believe client's firewalls are blocking UDP traffic coming from the proxy ... I tried to change port range and nothing seem to make it work... I was wondering if any of you kows something that may fix it.... Thanks -- ------------------------------------------------------------------- Amanda Remes Mattiuz amattiuz(a)gmail.com

3 10

[Users] usrloc, presence etc. cleanup rate: OpenSER mysql backend
by Bernard Chan 16 Apr '07

16 Apr '07

Hello, I would like to know how frequently OpenSER are cleaning up stale records with the mysql backend of various modules? For instance, active_watchers, location, presentity, watchers etc. mysql tables, or are stale records automatically removed at all? As I found a row in the location table with an "expires" date more than a month ago, but was still not cleaned up today. Or OpenSER takes a different strategy? This is because we expect to deploy OpenSER on a fairly large network and we are estimating database size and related overhead, and we are a bit worry that accumulation of these stale records may increase our processing costs. Thank you in advance for any insights. Regards, Bernard Chan.

3 6

Re: [Users] caller and callee behind diff NAT - ACK of 200OK is not reaching to callee
by shankar 16 Apr '07

16 Apr '07

I am very sorry Bogdan due to comany policy I can not attach any file. Regards, Shankar ----- Original Message ---- From: Bogdan-Andrei Iancu <bogdan(a)voice-system.ro> To: shankar <shankar_bandal(a)yahoo.com> Cc: users(a)openser.org Sent: Monday, 16 April, 2007 1:29:56 PM Subject: Re: [Users] caller and callee behind diff NAT - ACK of 200OK is not reaching to callee Hi there, unfortunately your msg flow is not comprehensive due text misalignment. Make it a simple text file and attach it to the email . regards, bogdan shankar wrote: > Hi ALL, > > Currently I am useing ser 0.9.6 version, I am switching to openser but before that I want to find out whether my scenario is valid. If it is valid then how can I solve this problem using openser. > > Belo is message sequence for my scenario. > > user1 NAT router 1 SER Proxy SIP Server NAT router 2 User2 > (192.x.x.3) (107.x.x.78) (107.x.x.201) (107.x.x.150) (107.x.y.249) (192.x.x3) > | REGISTER(user1) |REGISTER(user1) |REGISTER(user1)| | | > |-------------------> |---------------> |--------------> | | | > | | |REGISTER(user2)| | | > | | | ------------> | | | > | | | REGISTER(user2) | REGISTER(user2)| > | | | <--------------------------------------------------------|<------------------------ | > | INVITE | INVITE | INVITE | INVITE | INVITE | > |----------------------------->|-------------------------->| ----------------------->|------------------------------>|------------------------->| > | | | | | | > | 100 trying | 100 trying | | | | > | <-------------------------- |<------------------------- | | | | > | 180 Ringing | 180 Ringing | 180 Ringing | 180 Ringing | 180 Ringing | > | <--------------------------- | <----------------------- |<---------------------- | <---------------------------- | <---------------------- | > | | | | | | > | 200 OK | 200 OK | 200 OK | 200 OK | 200 OK | > | <--------------------------- | <---------------------- | <---------------------- | <---------------------------- | <---------------------- | > | | | | | | > | ACK | ACK | ACK | | | > | -----------------> | -----------------------> | ----------------------> | ?????? | | > Set up: > user 1: > Internal IP: 192.x.x.3 > external ip: 107.x.x.78 > user 2: > Internal IP: 192.x.x.3 > external ip: 107.x.y.249 > > Nat routers are FC5 linux PCs on which I have enabled SNAT and posrt forwarding. > > In above case user2 is not getting ACK. fix_nated_contact() API of SER is modifying contact > header to the destination ip of receiving message. e.g. SER proxy receives REGISTER meassage > from user 1 from NAT router 1 then it changing contact ip to the dst ip of REGISTER message i.e. > Nated ip of user1. Because of this RFEGISTER and INVITE goes fine. > But in case of 200 OK of INVITE comming from user 2 dst ip is IP of SIP server, so SER adds server ip in the contact header of 200Ok because of this user1 is sending ACK to SERVER but not to user2. > If I ignore the ACK (just for testing) and start media using RTPPROXY then media packets are > going to SERVER but not to user2 because force_rtp_proxy follows the same principle like > fix_nated_contact(). > > Please provide me some pointers. I am not able to unserstand how use1 will know that 200OK is came from user 2. In 200OK message there no reference of the nated IP of user2 > > below is my SER config file. > # $Id: nat-mediaproxy.cfg 51 2006-01-31 13:28:04Z /CN=Paul Hazlett/emailAddress=paul(a)onsip.org $ > debug=6 > fork=no > log_stderror=yes > listen=107.108.70.201 # INSERT YOUR IP ADDRESS HERE > port=5060 > children=4 > dns=no > rev_dns=no > fifo="/tmp/ser_fifo" > fifo_db_url="mysql://ser:heslo@localhost/ser" > #unix_sock="/tmp/ser_sock" > loadmodule "/usr/local/lib/ser/modules/mysql.so" > loadmodule "/usr/local/lib/ser/modules/sl.so" > loadmodule "/usr/local/lib/ser/modules/tm.so" > loadmodule "/usr/local/lib/ser/modules/rr.so" > loadmodule "/usr/local/lib/ser/modules/maxfwd.so" > loadmodule "/usr/local/lib/ser/modules/usrloc.so" > loadmodule "/usr/local/lib/ser/modules/registrar.so" > #loadmodule "/usr/local/lib/ser/modules/auth.so" > #loadmodule "/usr/local/lib/ser/modules/auth_db.so" > loadmodule "/usr/local/lib/ser/modules/uri.so" > loadmodule "/usr/local/lib/ser/modules/uri_db.so" > #loadmodule "/usr/local/lib/ser/modules/domain.so" > #loadmodule "/usr/local/lib/ser/modules/mediaproxy.so" > loadmodule "/usr/local/lib/ser/modules/nathelper.so" > loadmodule "/usr/local/lib/ser/modules/textops.so" > modparam("auth_db|domain|uri_db|usrloc", "db_url", "mysql://ser:heslo@localhost/ser") > #modparam("auth_db", "calculate_ha1", 1) > #modparam("auth_db", "password_column", "password") > modparam("nathelper", "natping_interval", 30) > modparam("nathelper", "ping_nated_only", 1) > modparam("nathelper", "rtpproxy_sock", "unix:/var/run/rtpproxy.sock") > modparam("usrloc", "db_mode", 2) > modparam("registrar", "nat_flag", 6) > modparam("rr", "enable_full_lr", 1) > route { > # ----------------------------------------------------------------- > # Sanity Check Section > # ----------------------------------------------------------------- > if (!mf_process_maxfwd_header("10")) { > sl_send_reply("483", "Too Many Hops"); > break; > }; > if (msg:len > max_len) { > sl_send_reply("513", "Message Overflow"); > break; > }; > # !! Nathelper > # Special handling for NATed clients; first, NAT test is > # executed: it looks for via!=received and RFC1918 addresses > # in Contact (may fail if line-folding is used); also, > # the received test should, if completed, should check all > # vias for rpesence of received > if (nat_uac_test("3")) { > # Allow RR-ed requests, as these may indicate that > # a NAT-enabled proxy takes care of it; unless it is > # a REGISTER > if (method == "REGISTER" || ! search("^Record-Route:")) { > log("LOG: Someone trying to register from private IP, rewriting\n"); > # This will work only for user agents that support symmetric > # communication. We tested quite many of them and majority is > # smart enough to be symmetric. In some phones it takes a configuration > # option. With Cisco 7960, it is called NAT_Enable=Yes, with kphone it is > # called "symmetric media" and "symmetric signalling". > fix_nated_contact(); # Rewrite contact with source IP of signalling > # if (method == "INVITE") { > # fix_nated_sdp("1"); # Add direction=active to SDP > # }; > force_rport(); # Add rport parameter to topmost Via > setflag(6); # Mark as NATed > }; > }; > > # 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(); > # ----------------------------------------------------------------- > # Call Tear Down Section > # ----------------------------------------------------------------- > if (method=="BYE" || method=="CANCEL") { > unforce_rtp_proxy(); > }; > # ----------------------------------------------------------------- > # Loose Route Section > # ----------------------------------------------------------------- > if (loose_route()) { > if ((method=="INVITE" || method=="REFER") && !has_totag()) { > sl_send_reply("403", "Forbidden"); > break; > }; > if (method=="INVITE") { > # if (!proxy_authorize("","subscriber")) { > # proxy_challenge("","0"); > # break; > # } else if (!check_from()) { > # sl_send_reply("403", "Use From=ID"); > # break; > # }; > # consume_credentials(); > > if (nat_uac_test("19")) { > setflag(6); > force_rport(); > fix_nated_contact(); > }; > force_rtp_proxy("l"); > }; > route(1); > break; > }; > # ----------------------------------------------------------------- > # Call Type Processing Section > # ----------------------------------------------------------------- > if (uri!=myself) { > route(4); > route(1); > break; > }; > if (method=="ACK") { > route(1); > break; > } else if (method=="CANCEL") { > route(1); > break; > } else if (method=="INVITE") { > route(3); > break; > } else if (method=="REGISTER") { > route(2); > break; > }; > lookup("aliases"); > if (uri!=myself) { > append_hf("P-hint: outbound alias\r\n"); > route(4); > route(1); > break; > }; > if (!lookup("location")) { > sl_send_reply("404", "User Not Found"); > break; > }; > route(1); > } > route[1] { > # ----------------------------------------------------------------- > # Default Message Handler > # ----------------------------------------------------------------- > t_on_reply("1"); > if (!t_relay()) { > if (method=="INVITE" && isflagset(6)) { > unforce_rtp_proxy(); > }; > sl_reply_error(); > }; > } > route[2] { > # ----------------------------------------------------------------- > # REGISTER Message Handler > # ---------------------------------------------------------------- > if (!search("^Contact:[ ]*\*") && nat_uac_test("19")) { > setflag(6); > fix_nated_register(); > force_rport(); > }; > sl_send_reply("100", "Trying"); > # if (!www_authorize("","subscriber")) { > # www_challenge("","0"); > # break; > # }; > # if (!check_to()) { > # sl_send_reply("401", "Unauthorized"); > # break; > # }; > # consume_credentials(); > if (!save("location")) { > sl_reply_error(); > }; > } > > > Send a FREE SMS to your friend's mobile from Yahoo! Messenger. Get it now at http://in.messenger.yahoo.com/ > > _______________________________________________ > Users mailing list > Users(a)openser.org > http://openser.org/cgi-bin/mailman/listinfo/users > > Send a FREE SMS to your friend's mobile from Yahoo! Messenger. Get it now at http://in.messenger.yahoo.com/

2 1

[Users] caller and callee behind diff NAT - ACK of 200OK is not reaching to callee
by shankar 16 Apr '07

16 Apr '07

Hi ALL, Currently I am useing ser 0.9.6 version, I am switching to openser but before that I want to find out whether my scenario is valid. If it is valid then how can I solve this problem using openser. Belo is message sequence for my scenario. user1 NAT router 1 SER Proxy SIP Server NAT router 2 User2 (192.x.x.3) (107.x.x.78) (107.x.x.201) (107.x.x.150) (107.x.y.249) (192.x.x3) | REGISTER(user1) |REGISTER(user1) |REGISTER(user1)| | | |-------------------> |---------------> |--------------> | | | | | |REGISTER(user2)| | | | | | ------------> | | | | | | REGISTER(user2) | REGISTER(user2)| | | | <--------------------------------------------------------|<------------------------ | | INVITE | INVITE | INVITE | INVITE | INVITE | |----------------------------->|-------------------------->| ----------------------->|------------------------------>|------------------------->| | | | | | | | 100 trying | 100 trying | | | | | <-------------------------- |<------------------------- | | | | | 180 Ringing | 180 Ringing | 180 Ringing | 180 Ringing | 180 Ringing | | <--------------------------- | <----------------------- |<---------------------- | <---------------------------- | <---------------------- | | | | | | | | 200 OK | 200 OK | 200 OK | 200 OK | 200 OK | | <--------------------------- | <---------------------- | <---------------------- | <---------------------------- | <---------------------- | | | | | | | | ACK | ACK | ACK | | | | -----------------> | -----------------------> | ----------------------> | ?????? | | Set up: user 1: Internal IP: 192.x.x.3 external ip: 107.x.x.78 user 2: Internal IP: 192.x.x.3 external ip: 107.x.y.249 Nat routers are FC5 linux PCs on which I have enabled SNAT and posrt forwarding. In above case user2 is not getting ACK. fix_nated_contact() API of SER is modifying contact header to the destination ip of receiving message. e.g. SER proxy receives REGISTER meassage from user 1 from NAT router 1 then it changing contact ip to the dst ip of REGISTER message i.e. Nated ip of user1. Because of this RFEGISTER and INVITE goes fine. But in case of 200 OK of INVITE comming from user 2 dst ip is IP of SIP server, so SER adds server ip in the contact header of 200Ok because of this user1 is sending ACK to SERVER but not to user2. If I ignore the ACK (just for testing) and start media using RTPPROXY then media packets are going to SERVER but not to user2 because force_rtp_proxy follows the same principle like fix_nated_contact(). Please provide me some pointers. I am not able to unserstand how use1 will know that 200OK is came from user 2. In 200OK message there no reference of the nated IP of user2 below is my SER config file. # $Id: nat-mediaproxy.cfg 51 2006-01-31 13:28:04Z /CN=Paul Hazlett/emailAddress=paul(a)onsip.org $ debug=6 fork=no log_stderror=yes listen=107.108.70.201 # INSERT YOUR IP ADDRESS HERE port=5060 children=4 dns=no rev_dns=no fifo="/tmp/ser_fifo" fifo_db_url="mysql://ser:heslo@localhost/ser" #unix_sock="/tmp/ser_sock" loadmodule "/usr/local/lib/ser/modules/mysql.so" loadmodule "/usr/local/lib/ser/modules/sl.so" loadmodule "/usr/local/lib/ser/modules/tm.so" loadmodule "/usr/local/lib/ser/modules/rr.so" loadmodule "/usr/local/lib/ser/modules/maxfwd.so" loadmodule "/usr/local/lib/ser/modules/usrloc.so" loadmodule "/usr/local/lib/ser/modules/registrar.so" #loadmodule "/usr/local/lib/ser/modules/auth.so" #loadmodule "/usr/local/lib/ser/modules/auth_db.so" loadmodule "/usr/local/lib/ser/modules/uri.so" loadmodule "/usr/local/lib/ser/modules/uri_db.so" #loadmodule "/usr/local/lib/ser/modules/domain.so" #loadmodule "/usr/local/lib/ser/modules/mediaproxy.so" loadmodule "/usr/local/lib/ser/modules/nathelper.so" loadmodule "/usr/local/lib/ser/modules/textops.so" modparam("auth_db|domain|uri_db|usrloc", "db_url", "mysql://ser:heslo@localhost/ser") #modparam("auth_db", "calculate_ha1", 1) #modparam("auth_db", "password_column", "password") modparam("nathelper", "natping_interval", 30) modparam("nathelper", "ping_nated_only", 1) modparam("nathelper", "rtpproxy_sock", "unix:/var/run/rtpproxy.sock") modparam("usrloc", "db_mode", 2) modparam("registrar", "nat_flag", 6) modparam("rr", "enable_full_lr", 1) route { # ----------------------------------------------------------------- # Sanity Check Section # ----------------------------------------------------------------- if (!mf_process_maxfwd_header("10")) { sl_send_reply("483", "Too Many Hops"); break; }; if (msg:len > max_len) { sl_send_reply("513", "Message Overflow"); break; }; # !! Nathelper # Special handling for NATed clients; first, NAT test is # executed: it looks for via!=received and RFC1918 addresses # in Contact (may fail if line-folding is used); also, # the received test should, if completed, should check all # vias for rpesence of received if (nat_uac_test("3")) { # Allow RR-ed requests, as these may indicate that # a NAT-enabled proxy takes care of it; unless it is # a REGISTER if (method == "REGISTER" || ! search("^Record-Route:")) { log("LOG: Someone trying to register from private IP, rewriting\n"); # This will work only for user agents that support symmetric # communication. We tested quite many of them and majority is # smart enough to be symmetric. In some phones it takes a configuration # option. With Cisco 7960, it is called NAT_Enable=Yes, with kphone it is # called "symmetric media" and "symmetric signalling". fix_nated_contact(); # Rewrite contact with source IP of signalling # if (method == "INVITE") { # fix_nated_sdp("1"); # Add direction=active to SDP # }; force_rport(); # Add rport parameter to topmost Via setflag(6); # Mark as NATed }; }; # 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(); # ----------------------------------------------------------------- # Call Tear Down Section # ----------------------------------------------------------------- if (method=="BYE" || method=="CANCEL") { unforce_rtp_proxy(); }; # ----------------------------------------------------------------- # Loose Route Section # ----------------------------------------------------------------- if (loose_route()) { if ((method=="INVITE" || method=="REFER") && !has_totag()) { sl_send_reply("403", "Forbidden"); break; }; if (method=="INVITE") { # if (!proxy_authorize("","subscriber")) { # proxy_challenge("","0"); # break; # } else if (!check_from()) { # sl_send_reply("403", "Use From=ID"); # break; # }; # consume_credentials(); if (nat_uac_test("19")) { setflag(6); force_rport(); fix_nated_contact(); }; force_rtp_proxy("l"); }; route(1); break; }; # ----------------------------------------------------------------- # Call Type Processing Section # ----------------------------------------------------------------- if (uri!=myself) { route(4); route(1); break; }; if (method=="ACK") { route(1); break; } else if (method=="CANCEL") { route(1); break; } else if (method=="INVITE") { route(3); break; } else if (method=="REGISTER") { route(2); break; }; lookup("aliases"); if (uri!=myself) { append_hf("P-hint: outbound alias\r\n"); route(4); route(1); break; }; if (!lookup("location")) { sl_send_reply("404", "User Not Found"); break; }; route(1); } route[1] { # ----------------------------------------------------------------- # Default Message Handler # ----------------------------------------------------------------- t_on_reply("1"); if (!t_relay()) { if (method=="INVITE" && isflagset(6)) { unforce_rtp_proxy(); }; sl_reply_error(); }; } route[2] { # ----------------------------------------------------------------- # REGISTER Message Handler # ---------------------------------------------------------------- if (!search("^Contact:[ ]*\*") && nat_uac_test("19")) { setflag(6); fix_nated_register(); force_rport(); }; sl_send_reply("100", "Trying"); # if (!www_authorize("","subscriber")) { # www_challenge("","0"); # break; # }; # if (!check_to()) { # sl_send_reply("401", "Unauthorized"); # break; # }; # consume_credentials(); if (!save("location")) { sl_reply_error(); }; } Send a FREE SMS to your friend's mobile from Yahoo! Messenger. Get it now at http://in.messenger.yahoo.com/

2 1

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