sr-users December 2005

sr-users@lists.kamailio.org

158 participants
312 discussions

by Bogdan-Andrei Iancu

Doug, in failure route, the RURI was already consumed (you already got reply for it) - so, if you want to relay again, you need to append a new branch. regards, bogdan Douglas Garstang wrote: >Bogdan, > >I don't understand why I need to do this. Doesn't rewritehostport rewrite the current URI so that t_relay can statefully deliver? If so, what's the point of append_branch? It seems redundant, which is why I don't understand the need for it. > >Doug. > >-----Original Message----- >From: Bogdan-Andrei Iancu [mailto:bogdan@voice-system.ro] >Sent: Wednesday, December 14, 2005 8:47 AM >To: Douglas Garstang >Cc: users(a)openser.org >Subject: Re: [Users] More Routing.... > > >Hi Doug, > >in failure route, in order to fork a new serial branch, you need to call >append_branch() before t_relay(). > >regards, >bogdan > >Douglas Garstang wrote: > > > >>Can someone please tell me why the following extremely simple example doesn't first attempt to relay to 192.168.10.7, and then if that fails, try 192.168.10.8? What am I missing here? The documentation says that t_relay() simple sends statefully to the current URI.... seems to be what I am doing. What am I missing? Please help! >> >>route(1); >> >>route[1] { >> rewritehostport("192.168.10.7:5060"); >> t_on_failure("2"); >> t_relay(); >>} >> >>failure_route[2] { >> rewritehostport('192.168.10.8:5060"); >> t_relay(); >>} >> >>Doug. >> >> >> >>_______________________________________________ >>Users mailing list >>Users(a)openser.org >>http://openser.org/cgi-bin/mailman/listinfo/users >> >> >> >> >> > > >

18 years, 11 months

[Serusers] problems with RTP proxy

by Anthony Chapellier

Hi, I've got troubles with RTP proxy. When I initiate a call between two UAs, I see RTP packets arriving from both clients to RTP proxy but they don't leave the proxy and of course clients don't receive them... does someone know what the problem could be ? Thanks,

18 years, 11 months

[Users] RE: failure_route.... I could cry...

by Douglas Garstang

Oh dear... it's failing because as far as t_relay() is concerned, the packet has been delivered, and the transaction is complete, right? If that's the case, how can I also send the REGISTRATION packet to another destination? Can I use forward() with failure_route? Arrgh!. > -----Original Message----- > From: Douglas Garstang > Sent: Tuesday, December 13, 2005 6:01 PM > To: 'users(a)openser.org' > Subject: failure_route.... I could cry... > > I am trying to have OpenSER forward registration requests to multiple Asterisk boxes with failover. Each Asterisk box has two ip addresses. My logic tries to relay to the first IP on the first Asterisk box (192.168.10.100). If that fails, it tries to relay to the second IP on the first Asterisk box (192.168.10.17). It then goes on and repeats the process with another Asterisk box who's IP's are 192.168.10.10.101 and 192.168.10.8. > > Actually the first IP address on each Asterisk system is fake (100 and 101)... that's how I am testing that it will fail to the second one. > > The openser.cfg below is causing this to be logged to messages: > Dec 13 17:50:08 bil-pdev-3 openser[22318]: route10: Asterisk-1, NIC-1 > Dec 13 17:50:08 bil-pdev-3 openser[22318]: route20: Asterisk-2, NIC-1 > Dec 13 17:50:08 bil-pdev-3 openser[22318]: ERROR: t_newtran: transaction already in process 0xb6126560 < --- Why? > Dec 13 17:50:08 bil-pdev-3 openser[22318]: route20: t_relay returned error <--- Why? > Dec 13 17:50:09 bil-pdev-3 openser[22328]: failure21: Failed to register with Asterisk-2, NIC-1 > Dec 13 17:50:09 bil-pdev-3 openser[22328]: route22: Asterisk-2, NIC-2 > Dec 13 17:50:09 bil-pdev-3 openser[22328]: route22: End of routine > Dec 13 17:50:10 bil-pdev-3 openser[22322]: User local found > Dec 13 17:50:10 bil-pdev-3 openser[22320]: User local found > > Why am I getting the t_newtran and t_relay errors in there? What am I doing wrong? I'm just calling rewritehostport(next-ip), followed by append_branch() and t_relay. In fact something really weird happens. When I have the code there for route[20], failure_route[21] and route[22], it causes the code for the first three routing blocks, route[10], failure_route[11] and route[12] to act differently. It seems to make route20 fail to connect eventhough it comes AFTER it in the code. > > I'd really appreciate some help! Am I doing something wrong with rewritehostport and append_branch, because quite frankly the docs are terrible. > > > if ( method == REGISTER ) { > if ( !www_authorize("voip.com", "subscriber") ) { > www_challenge("voip.com", "0"); > }; > save("location"); > route(10); > route(20); > > # > # First Asterisk System. > # > > # Try first IP on this system (fake - will fail) > route[10] { > xlog ("L_INFO","route10: Asterisk-1, NIC-1"); > t_on_failure("11"); > rewritehostport("192.168.10.100:5060"); > append_branch(); > if ( !t_relay() ) { > xlog ("L_INFO","route10: t_relay returned error"); > } > } > > failure_route[11] { > xlog ("L_INFO","failure11: Failed to register with Asterisk-1, NIC-1"); > route(12); > } > > # Try second IP on this system (real - should work) > route[12] { > xlog ("L_INFO","route12: Asterisk-1, NIC-2"); > t_on_failure("13"); > rewritehostport("192.168.10.17:5060"); > append_branch(); > if ( !t_relay() ) { > xlog ("L_INFO","route12: t_relay returned error"); > } > xlog ("L_INFO","route12: End of routine"); > return; > } > > # > # Second Asterisk System > # > > # Try first IP on this system (fake - will fail) > route[20] { > xlog ("L_INFO","route20: Asterisk-2, NIC-1"); > t_on_failure("21"); > rewritehostport("192.168.10.101:5060"); > append_branch(); > if ( !t_relay() ) { > xlog ("L_INFO","route20: t_relay returned error");> > } > } > > failure_route[21] { > xlog ("L_INFO","failure21: Failed to register with Asterisk-2, NIC-1"); > route(22); > } > > # Try second IP on this system (real - should work) > route[22] { > xlog ("L_INFO","route22: Asterisk-2, NIC-2"); > t_on_failure("23"); > rewritehostport("192.168.10.8:5060"); > append_branch(); > if ( !t_relay() ) { > xlog ("L_INFO","route22: t_relay returned error"); > } > xlog ("L_INFO","route22: End of routine"); > return; > } > > Doug > >

18 years, 11 months

[Users] More Routing....

by Douglas Garstang

Can someone please tell me why the following extremely simple example doesn't first attempt to relay to 192.168.10.7, and then if that fails, try 192.168.10.8? What am I missing here? The documentation says that t_relay() simple sends statefully to the current URI.... seems to be what I am doing. What am I missing? Please help! route(1); route[1] { rewritehostport("192.168.10.7:5060"); t_on_failure("2"); t_relay(); } failure_route[2] { rewritehostport('192.168.10.8:5060"); t_relay(); } Doug.

18 years, 11 months

[Users] Routing Examples

by Douglas Garstang

I'm having a terrible time trying to get failure routes to work. Can someone point me to some USEFUL examples please? The examples that come with OpenSER are trivial. They all use append_branch("sip:user@domain") which in the real world is barely useful. I need to try sending messages to a specified host with the current user's URI. For example, is this the correct usage for trying to connect in sequence to multple destinations? rewritehostport("192.168.10.7:5060"); append_branch(); t_on_failure("2"); t_relay(); failure_route[2] { rewritehostport("192.168.10.7:5060"); append_branch(); t_relay(); } The second route is never tried. In general, what should I be doing here? Which is correct? rewritehostport(ip-addr) append_branch() t_relay() or maybe... append_branch(ip-addr) t_relay() or maybe... append_branch(ip-addr1) append_branch(ip-addr2) t_relay() Do you get my point? The docs are really bad and don't cover exactly how this stuff is supposed to be implemented! if I do a google search on this stuff, I get almost no matches. There's no books either. I'm out of ideas. I'm just trying to connect to multiple destinations in sequence....

18 years, 11 months

[Users] Debug Destionation Set

by Douglas Garstang

Is there a way to see what's in the current destionation set? Either by a command or debug output from OpenSER. It doesn't seem to display anything in debug about the destination set at all. Doug.

18 years, 11 months

[Users] connection failed

by maillisting

Hi all, Anyone knows the meaning of the following errors? Anyway to solve it? Dec 9 17:16:00 ow01 ./openser[19379]: ERROR: tcp_blocking_connect: timeout (10) Dec 9 17:16:00 ow01 ./openser[19379]: ERROR: tcpconn_connect: tcp_blocking_connect failed Dec 9 17:16:00 ow01 ./openser[19379]: ERROR: tcp_send: connect failed Dec 9 17:16:00 ow01 ./openser[19379]: msg_send: ERROR: tcp_send failed Dec 9 17:16:00 ow01 ./openser[19379]: ERROR:tm:t_forward_nonack: sending request failed Dec 9 17:16:00 ow01 ./openser[19379]: ERROR:tm: _reply_light: can't generate 477 reply when a final 487 was sent out Dec 9 17:16:00 ow01 ./openser[19379]: ERROR: sl_reply_error used: Unfortunately error on sending to next hop occurred (477/SL)

18 years, 11 months

[Users] Use of append_branch

by Douglas Garstang

How can I call append branch and use a variable name in the user port (ie the user for which this message is addressed) of the URI? _ALL_ the examples have something like: append_branch("sip:nonsense@192.168.2.16:5064"); which is completely useless. I need to call append_branch and have the user portion of the uri inserted. Something like: append_branch("sip:$to_user@192.168.2.16:5064"); How can I do this? Doug.

18 years, 11 months

Re: [Devel] [Users] nathelper/rtpproxy when both SIP UA are behind same NAT

by Norman Brandinger

Hi Rafael, You would use the "example code snippet" when you want to decide whether or not to use rtpproxy or mediaproxy based on the fact that both the caller and the callee are behind the same NAT device. Please review the mailing lists as this topic has been discussed many times. I added some additional comments in regard to the setting of flags 2 and 3 in the posted example at: http://openser.org/dokuwiki/doku.php?id=avp_examples Generally, I have found that if OpenSER fails to start with an error indicating that the function can't be found, it's time to find the correct module to add. In response to your last question "etc." I suggest that you review the three web sites: openser.org, iptel.org and onsip.org. The last one has some really great material that explains alot. Regards, Norm Rafael R. GV wrote: > Hi > I am using nathelper/rtpproxy in ser , please see my ser.cfg attached > and tell me where do I have to use this code snippet? where did you > set flags 2 and 3?, what other modules I need?, etc. > > thank you > Rafael > Lima-Peru > > On 12/7/05, *Norman Brandinger* <norm(a)goes.com <mailto:norm@goes.com>> > wrote: > > Thanks go out to Klaus and Tavis. > > I took the results of this thread and placed it in the docuwiki > for the > rest of the user community to use (at least, the rest of the user > community that reads the docuwiki :) > > http://openser.org/dokuwiki/doku.php?id=avp_examples > > If I made any typos, please feel free to correct them. > > Regards, > Norm > > _______________________________________________ > Users mailing list > Users(a)openser.org <mailto:Users@openser.org> > http://openser.org/cgi-bin/mailman/listinfo/users > <http://openser.org/cgi-bin/mailman/listinfo/users> > > > ------------------------------------------------------------------------ > > # > # If you don't want to enforce RTP proxy for some destinations > # then simply use t_relay() instead of route(1) > # > # Modificado para MYSQL_ACC support > # Handling of Unavailable user and Voicemail redirection (404|408|486) > # > # Log Missed Calls (403|404|408|415|484|486|487). > # > # Group checking and PSTN credentials. > # > # 18/07/2005 Prepaid & B2bua support added > # 11/11/2005 LDI a 192.168.2.132 with a2billing > # > # Pendientes !! - Administrar Multi-Dominio para otros Códigos de Area. > # - Completar Logica para tratamiento de llamadas entre > # un mismo NAT usando avpops. > # > # ----------- global configuration parameters ------------------------ > > #/* Uncomment these lines to enter debugging mode > debug=2 > fork=yes > log_stderror=yes > #*/ > > listen=192.168.2.130 > listen=127.0.0.1 > port=5060 > > # hostname matching an alias will satisfy the condition uri==myself". > alias=mydomain.com.pe > alias=127.0.0.1 > > check_via=no # (cmd. line: -v) > dns=no # (cmd. line: -r) > rev_dns=no # (cmd. line: -R) > children=4 > fifo="/tmp/ser_fifo" > fifo_mode=0666 # Fifo permissions can be changes from here. > > # sip_warning - Should replies include extensive warnings? > # By default yes, it is good for trouble-shooting. > sip_warning=yes > > # ------------------ module loading ---------------------------------- > loadmodule "/usr/local/lib/ser/modules/domain.so" > loadmodule "/usr/local/lib/ser/modules/avpops.so" > 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/group.so" > loadmodule "/usr/local/lib/ser/modules/uri.so" > loadmodule "/usr/local/lib/ser/modules/uri_db.so" > loadmodule "/usr/local/lib/ser/modules/acc.so" > loadmodule "/usr/local/lib/ser/modules/textops.so" > > # digest authentication > loadmodule "/usr/local/lib/ser/modules/auth.so" > loadmodule "/usr/local/lib/ser/modules/auth_db.so" > > # !! Nathelper > loadmodule "/usr/local/lib/ser/modules/nathelper.so" > > # ----------------- setting module-specific parameters --------------- > > modparam("usrloc", "db_mode", 2) > > # minimize write back window - default is 60 seconds > modparam("usrloc", "timer_interval", 10) > > # database location > modparam("usrloc", "db_url", "mysql://ser:heslo@localhost/ser") > > modparam("usrloc", "use_domain", 1) > modparam("auth_db", "use_domain", 1) > > > modparam("domain", "db_mode", 1) > modparam("domain", "domain_table", "domain") > modparam("domain", "domain_col", "domain") > > > # ------------- Mysql Accounting parameters > modparam("acc", "log_flag", 1) > modparam("acc", "log_level", 2) > modparam("acc", "db_flag", 1) > modparam("acc", "db_missed_flag", 3) > modparam("acc", "log_missed_flag", 3) > modparam("acc", "db_url", "mysql://seradmin:heslo@localhost/ser") > modparam("acc", "report_ack", 0) # 1 reporta dos starts en acc (para INVITE y ACK) > modparam("acc", "failed_transactions", 1) # *all* non-200 transactions marked for acc will be logged too. > > modparam("acc", "log_fmt", "miocfsputdr") > > modparam("tm", "fr_timer", 20 ) > modparam("tm", "fr_inv_timer", 40 ) # Timer which hits if no final reply for an INVITE > modparam("tm", "wt_timer", 20 ) > > # add value to ;lr param to make some broken UAs happy > modparam("rr", "enable_full_lr", 1) > > modparam("group", "db_url", "mysql://seradmin:heslo@localhost/ser") > modparam("uri_db", "db_url", "mysql://seradmin:heslo@localhost/ser") > > # ------------- registration parameters > modparam("registrar", "nat_flag", 6) > modparam("registrar", "min_expires", 60) > modparam("registrar", "max_expires", 86400) > modparam("registrar", "default_expires", 3600) > modparam("registrar", "desc_time_order", 1) > modparam("registrar", "append_branches", 1) > > modparam("registrar", "use_domain", 1) > > # !! Nathelper > # modparam("registrar", "nat_flag", 6) > modparam("nathelper", "natping_interval", 30) # Ping interval 30 s > modparam("nathelper", "ping_nated_only", 1) # Ping only clients behind NAT > > # -------------------------- request routing logic -------------------------- > > route { > > log(1, "-------------------------------------------\n"); > log(1, "entering main loop\n"); > > > # 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"); > break; > }; > if ( msg:len >= max_len ) { > sl_send_reply("513", "Message too big"); > 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("19")) { > # 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 > }; > }; > > > # set flag for Radius Accounting: > > > if (!method=="OPTIONS") setflag(3); # SET MISSED_CALLS FLAG FOR ACC > > if (method=="INVITE") { > log(1, "INVITE MESSAGE RECEIVED - START ACC\n"); > setflag(1); /* set for accounting (the same value as in log_flag!) */ > }; > > if (method=="BYE") { > log (1, "BYE - STOP ACCOUNTING\n"); > setflag(1); > }; > > if (method=="CANCEL") { > log (1, "CANCEL - STOP ACCOUNTING\n"); > setflag(1); > }; > > > # 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 > # Excluding packets from b2bua (port 5070) > if (loose_route() ) { > log(1," Mark routing logic in request --> rr-enforced \n"); > append_hf("P-hint: rr-enforced\r\n"); > # t_relay(); > route(1); # Nathelper!! > break; > }; > > if (!uri==myself ) { > log(1," Mark routing logic in request --> outbound\r \n"); > append_hf("P-hint: outbound\r\n"); > # t_relay(); > route(1); # Nathelper!! > break; > }; > > if (uri==myself) { > > if (method == "REGISTER") { > > log(1, "ANALYZING REGISTER REQUEST\n"); > # to use digest authentication > if (is_user_in("Request-URI", "desactivado")) { > sl_send_reply("402", "Su cuenta fue desactivada"); > break; > }; > > if (!www_authorize("mydomain.com.pe", "subscriber")) { > log(1," ----- Fails to Register \n"); > www_challenge("mydomain.com.pe", "0"); > break; > }; > > # only signed users are allowed > if (!check_to()) { > log(1, "LOG: Hijack!!!--> unsigned user registration attempt\n"); > sl_send_reply("403", "hijack attempt!!!! Only signed users are allowed"); > break; > }; > log(1," Registered!!! \n"); > if (!save("location")) { > sl_reply_error(); > }; > break; > }; > > > #For *B2bua: First check the source of the call > #********************************************** > # If the call comes from the gateways, no authentication is required. > if (src_ip==192.168.2.145 || src_ip==192.168.2.132 || src_ip==192.168.2.131) { > log(1,"Call from pstn|*, no authentication is required. \n"); > > # If the call comes from B2BUA, no authentication is required, > # The first leg of the call has already been authenticated. > } else if (src_ip==192.168.2.130 && src_port==5070) { > log(1,"Call from B2BUA, no authentication is required. \n"); > } else { > # We check user credentials > if ((method == "INVITE" || method== "CANCEL" || method== "BYE" || method== "ACK") && (!src_ip==192.168.2.130 && !src_port==5070)){ > log(1, "ANALYZING INVITE||CANCEL REQUESTs\n"); > if (!proxy_authorize("mydomain.com.pe", "subscriber")) { > # log(1," ----- Fails to ...proxy_authorize \n"); > proxy_challenge("mydomain.com.pe", "0"); > break; > } else { > if (method == "INVITE" && !check_from()) { > sl_send_reply("403", "Only registered users are allowed"); > log(1," ----> Only registered users are allowed \n"); > break; > }; > }; > > # Not all the users are PREPAID, so we check the database > # to see if the call will be routed through B2BUA. > # If every call is to be routed through B2BUA the "is_user_in" > # conditional is not required. > # Do not use b2bua for local calls > > if (is_user_in("From", "prepaidb") && uri=~"^sip:00") { > log(1," ----> Usuario PREPAGO!!! enviando a b2bua... \n"); > rewritehostport("192.168.2.130:5070"); > t_relay_to_udp("192.168.2.130", "5070"); > break; > }; > > };# End of if (method == "INVITE" |... > }; > > > /* *********** Dial out to Local and PSTN logic ********* */ > > > # Forward +9n digit requests to gateway Cisco-AS5350 (Celulares): > > if(uri=~"^sip:9" ){ > log(1," digit expression match - Celulares \n"); > if (!is_user_in("from", "movlim")) { > sl_send_reply("403", "No permission for mobile calls"); > acc_db_request("403 Forbidden", "missed_calls"); > break; > }; > rewritehostport("192.168.2.145:5060"); > route(1); > break; > }; > > > /* ******************************************************************** */ > > lookup("aliases"); > > > # does the user wish redirection on no availability? (i.e., is he > # in the voicemail group?) -- determine it now and store it in > # flag 4, before we rewrite the flag using UsrLoc > > if (is_user_in("Request-URI", "voicemail")) { > log(1, "requested user is in voicemail group \n"); > setflag(4); > }; > > > # native SIP destinations are handled using our USRLOC DB: > > # LOOKUP (location)!!!! > > if (!lookup("location")) { > log(1,"unable to locate user X ... sending to route(4)! \n"); > # handle user which was not found > route(4); > break; > }; > > ### Test if UAS are in the same NAT: > > # get the host part of the final uri (IP part) and store it in AVP ID 13 > > avp_write("$ruri/domain", "i:13"); > if (avp_check("i:13","eq/$src_ip/i")) { > log(1, "source IP is the same as destination IP\n"); > route(3); > break; > }; > avp_delete("i:13/g"); > > > }; # End of "if(uri==myself)" > > > append_hf("P-hint: usrloc applied\r\n"); > route(1); > > # if user is on-line and is in Voicemail group, enable redirection > if (method == "INVITE" && isflagset(4)) { > log(1, "invite for voicemail user->initiate failureroute[1]\n"); > t_on_failure("1"); > }; > } > > ### ##### ####### ########## - ROUTES - ############### ################# ################## > > route[1] > { > > # if client or server know to be behind a NAT, enable relay > if (isflagset(6)) { > log(1, "Route1: force rtp proxy!!!\n"); > force_rtp_proxy(); > }; > > # NAT processing of replies; apply to all transactions (for example, > # re-INVITEs from public to private UA are hard to identify as > # NATed at the moment of request processing); look at replies > t_on_reply("1"); > > # send it out now; use stateful forwarding as it works reliably > # even for UDP2TCP > if (!t_relay()) { > sl_reply_error(); > }; > log(1, "Route[1]: Send it out now!!!\n"); > break; > } > > # !! Nathelper > onreply_route[1] { > # NATed transaction ? > # Not all 2xx messages have a content body so here we > # make sure our Content-Length > 0 to avoid a parse error > > if (isflagset(6) && status =~ "(183)|2[0-9][0-9]") { > fix_nated_contact(); > if (!search("^Content-Length:\ 0")) { > force_rtp_proxy(); > }; > # otherwise, is it a transaction behind a NAT and we did not > # know at time of request processing ? (RFC1918 contacts) > } else if (nat_uac_test("1")) { > fix_nated_contact(); > }; > } > > # -------------- SIP-to-PSTN call routed --------------------- > > route[2]{ > log(1,"route[2]:SIP-to-GW call routed \n"); > if(!t_relay()){ > sl_reply_error(); > }; > log(1, "Route[2]: Send it out now!!!\n"); > } > > # -------------- Same NAT Call Routing (no force rtpproxy) ---- > > route[3]{ > log(1," route[3]: UAs are in the same nat, NO force_rtp_proxy "); > > # What do I have to do here? > > if(!t_relay()){ > sl_reply_error(); > }; > log(1, "Route[3]: Send it out now!!!\n"); > } > > # --------------- Handling of Unavailable user ---------------- > route[4] { > > # non-Voip -- just send "off-line" > if (!(method=="INVITE" || method=="ACK" || method=="CANCEL" || method=="BYE" || method=="OPTIONS")) { > sl_send_reply("404", "Not Found"); > acc_db_request("404 Not Found", "missed_calls"); > log(1, "acc 404 Not Found 1 \n"); > break; > }; > > if (!isflagset(4) && !method=="OPTIONS" && !method=="ACK" && !method=="BYE") { > sl_send_reply("404", "Not Found and no voicemail turned on !! "); > acc_db_request("404 Not Found", "missed_calls"); > log(1, " acc 404 Not Found and no voicemail \n"); > break; > }; > > # forward to voicemail adding prefix to simplify asterisk "extension.conf" > prefix("vm"); > acc_db_request("404 Not Found -> Vm", "missed_calls"); > rewritehostport("192.168.2.131:5070"); > t_relay_to_udp("192.168.2.131", "5070"); > } > > # if forwarding downstream did not succeed, try voicemail running at Asterisk > > failure_route[1]{ > if (t_check_status("408")){ > # revert_uri (); back to the original URI, makes me loose all lookup/rewrite stuff > prefix("vm"); > rewritehostport ("192.168.2.131:5070"); > acc_db_request("408 Timeout -> Vm", "missed_calls"); > append_branch(); > t_relay(); > break; > } else if (t_check_status("486")){ > # revert_uri (); back to the original URI, makes me loose all lookup/rewrite stuff > prefix("vm"); > rewritehostport ("192.168.2.131:5070"); > acc_db_request("486 Busy -> Vm", "missed_calls"); > append_branch(); > t_relay(); > break; > } > } > > ### The End ###

18 years, 11 months

Re: [Serusers] Changing Sip Port

by Voipers Portugal

There are 2 port setting that you can change. Either you change the signalling port to contact SER: when specifying the SIP Server just do: sip_server:port In this case, if you change the port, make sure that your SER Server is listening on that port as well. Or you can change the listen port of your Softphone. In this case, you don't need to alter anything else. Not sure about what you wanted. Can you provide the SIP messages log? Jose Simoes On 12/13/05, Juan <juan(a)uwtcallback.com> wrote: > > > Hi Jose. > I tried your way but I did not get it registred. I used many ports but > couldn't get it registred. > I am not using any authentication and when using port 5060 the softphone > registres OK. > My SER and my softphone (X- lite) are on the same network. > Any ideas? > Thanks in advance, > > Juan Ferrari > United World Telecom > > > ------------------------------ > *From:* serusers-bounces(a)iptel.org [mailto:serusers-bounces@lists.iptel.org] *On > Behalf Of *Voipers Portugal > *Sent:* Saturday, December 10, 2005 8:48 AM > *Cc:* serusers(a)lists.iptel.org > *Subject:* Re: [Serusers] Changing Sip Port > > > Most softphones allow that. When you are specifying a SIP server, for > default (normally) it uses 5060. If you want to alter this port just do the > following: > > ser_IP_address:port_number > > 127.0.0.1:5090 > > Jose Simoes > > p.s. this works with X-Lite > > On 12/5/05, Andrey Kouprianov <andrey.kouprianov(a)gmail.com> wrote: > > > > I guess it depends on your softphone... if it chooses to communicate > > from port 5060, there's nothing you can do about it, unless you can > > change it in the phone's settings... > > Some softphones, for instance, get a random port... > > > > On 12/5/05, sagar <vids_cs(a)yahoo.com> wrote: > > > Hi All, > > > > > > I am using ser 0.8.14 +asterisk B2bua. > > > > > > Currently softphone is registering on standard sip port 5060 . > > > Is it possibe to use any other port like 5090 or 8069 > > > > > > > > > I tried to do so by changing the listining port to 5090 in ser.cfgbut in > > > case the softphone is not getting register. > > > > > > > > > Here is the ser log > > > > > > > > > 0(11348) SIP Request: > > > 0(11348) method: <REGISTER> > > > 0(11348) uri: <sip: 192.168.1.100> > > > 0(11348) version: <SIP/2.0> > > > 0(11348) parse_headers: flags=1 > > > 0(11348) end of header reached, state=5 > > > 0(11348) parse_headers: Via found, flags=1 > > > 0(11348) parse_headers: this is the first via > > > 0(11348) After parse_msg... > > > 0(11348) preparing to run routing scripts... > > > 0(11348) DEBUG : is_maxfwd_present: searchi ng for max_forwards > > header > > > 0(11348) parse_headers: flags=128 > > > 0(11348) DEBUG: is_maxfwd_present: value = 70 > > > 0(11348) parse_headers: flags=8 > > > 0(11348) DEBUG: add_param: > > > tag=fa37b062306344d68023aed26289e820 > > > 0(11348) DEBUG: add_param: epid=f657995ecc > > > 0(11348) end of header reached, state=29 > > > 0(11348) parse_headers: flags=256 > > > 0(11348) end of header reached, state=9 > > > 0(11348) DEBUG: get_hdr_field: <To> [37]; > > > uri=[sip:2851816416@192.168.1.100:5090] > > > 0(11348) DEBUG: to body [<sip:2851816416@192.168.1.100:5090> > > > ] > > > 0(11348) get_hdr_field: cseq <CSeq>: <1> <REGISTER> > > > 0(11348) DEBUG: get_hdr_body : content_length=0 > > > 0(11348) found end of header > > > 0(11348) find_first_route(): No Route headers found > > > 0(11348) loose_route(): There is no Route HF > > > 0(11348) parse_headers: flags=64 > > > 0(11348) parse_headers: flags=64 > > > 0(11348) parse_headers: flags=33554432 > > > 0(11348) check_self - checking if host==us: 13==13 && [ > > 192.168.1.100] == > > > [192.168.1.100 ] > > > 0(11348) check_self - checking if port 5090 matches port 5060 > > > 0(11348) check_self: host != me > > > 0(11348) DEBUG: t_addifnew: msg id=1 , global msg id=0 , T on > > > entrance=0xffffffff > > > 0(11348) parse_headers: flags=-1 > > > 0(11348) parse_headers: flags=60 > > > 0(11348) t_lookup_request: start searching: hash=58712, isACK=0 > > > 0(11348) DEBUG: proceeding to pre-RFC3261 transaction matching > > > 0(11348) DEBUG: t_lookup_request: no transaction found > > > 0(11348) DEBUG: mk_proxy: doing DNS lookup... > > > 0(11348) check_via_address(192.168.1.2, 192.168.1.2, 0) > > > 0(11348) DEBUG: add_to_tail_of_timer[4]: 0xb6165fe8 > > > 0(11348) DEBUG: add_to_tail_of_timer[0]: 0xb6165ffc > > > 0(11348) SER: new transacti on fwd'ed > > > 0(11348) DEBUG:destroy_avp_list: destroing list (nil) > > > 0(11348) receive_msg: cleaning up > > > > > > Please advise. > > > > > > Thanks In Advance. > > > > > > > > > ________________________________ > > > Yahoo! Personals > > > Single? There's someone we'd like you to meet. > > > Lots of someones, actually. Yahoo! Personals > > > > > > > > > _______________________________________________ > > > Serusers mailing list > > > serusers(a)lists.iptel.org > > > http://lists.iptel.org/mailman/listinfo/serusers > > > > > > > > > > > > > _______________________________________________ > > Serusers mailing list > > serusers(a)lists.iptel.org > > http://lists.iptel.org/mailman/listinfo/serusers > > > >

18 years, 11 months

← Newer
1
...
10
11
12
13
14
15
16
...
32
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 December 2005