sr-users February 2006

sr-users@lists.kamailio.org

189 participants
373 discussions

by unplug

For the normal cancel situation. UA1 OPENSER UA2 --------INVITE-----------------> <-----------100----------------- --------------------INVITE----------> <---------------100------------------- ----------CANCEL----------> --------------CANCEL-------------> <--------------200------------------ <------------487------------------- --------------ACK-----------------> <---------487--------------- -------------ACK------------> But in my case, I found that there are many 487 created from openser to UA1. The multiple 487 may cause a call drop in the following call. Why does openser create so many 487 for UA1? How can I prevent it? UA1 OPENSER UA2 --------INVITE-----------------> <-----------100----------------- --------------------INVITE----------> <---------------100------------------- ----------CANCEL----------> --------------CANCEL-------------> <--------------200------------------ <------------487------------------- --------------ACK-----------------> <---------487--------------- -------------ACK------------> <---------487------------- -------------ACK------------> <---------487--------------- -------------ACK------------> <---------487------------- -------------ACK------------> <---------487------------- -------------ACK------------> <---------487------------- -------------ACK------------> <---------487------------- -------------ACK------------> ...

18 years, 4 months

[Users] call drop in a few seconds

by unplug

When UA1 calls UA2, UA1 drop the call before UA2 take the call. After a few second, UA1 makes another call to UA3. The call established and it will drop after a few second. I expect the situation below. UA1 ------INVITE ----> UA2 UA2 (ringing) UA1 ------CANCEL----> UA2 UA2 (ringing) UA1 -----INVITE--------> UA3 (in few seconds) UA1 ------call established----UA3 UA1 <-------BYE------- UA2 UA1 -----call drop--------UA3 What can I do to reduce the situation above?

18 years, 4 months

[Users] add/rewrite a tag/parameter in SDP

by Lenir

Hey guys, What is the best way to modify the SDP message to always include (if not replace) the a= tags in a SDP message? My problem is specifically with g729, according to the RFC, if the parameter: "a=fmtp:18 annexb=yes" is present or missing then it is assumed that g729b (g729 with VAD) and if "a=fmtp:18 annexb=no" is present then the devices will use g729a (g729 with VAD Disabled). My problem is that some cisco gateways and ATAs behave differently (of course Cisco always doing it their way), if "a=fmtp:18 annexb=no" is missing then it assumes that g729a will be used, instead of following the RFC where it should negotiate g729b. Also, asterisk doesn't support g729b so I want to avoid using g729b everywhere in my network. So what is the best way or is there a way, to either: a) insert "a=fmtp:18 annexb=no" if is not present b) replace "a=fmtp:18 annexb=yes" for "a=fmtp:18 annexb=no" if it is present Thanks in advance!! Lenir p.s. Please see the below excerpt from RFC 3555 regarding how to specify G729. RFC 3555 MIME Type Registration of RTP Payload Formats July 2003 4.1.9. Registration of MIME media type audio/G729 MIME media type name: audio MIME subtype name: G729 Required parameters: None Optional parameters: ptime, maxptime annexb: indicates that Annex B, voice activity detection, is used or preferred. Permissible values are "yes" and "no" (without the quotes); "yes" is implied if this parameter is omitted

18 years, 4 months

[Users] NEW FUNCTIONALITY: add_rr_param() in BRANCH / FAILURE routes

by Bogdan-Andrei Iancu

Hi, the add_rr_param() can be new safely called from BRANCH / FAILURE routes. The behaviour will be: - in BRANCH route - the RR parameters are set only for the current branch, so you can have different RR params for each branch - in FAILURE route - the RR parameters will be set only for the outgoing branch, so during serial forking you may add additional RR param function of the new destination. Additional improvements in the RR module usage: -record_route() may take as parameter a string to be appended as RR param; pseudo-variables may be used. -add_rr_param() and record_route_preset() accepts pseudo_variables in parameter. Here is a short example on what can be done with the new functionality: { ..... record_route(";param1=xxx"); t_on_branch("1"); t_on_failure("1"); ..... t_relay(); } branch_route[1] { add_rr_param(";param2=yyy"); ....... } failure_route[1] { add_rr_param(";param3=zzz"); t_on_branch("0"); #reset append_branch( URI_2 ); t_relay(); } The output will look like: after first relay: ";param1=xxx;param2=yyy" after failure route relay : ";param1=xxx;param3=zzz" regards, bogdan

18 years, 4 months

[Serusers] Ser and Fax over IP and Real-Time Fax configurations

by Elias Kaaria

Dear Tobias, Thanks you for your assistance on As5350 configurations and sip. Now am about to configure Fax over IP and Real-Time Fax in my ser sip server. I will appreciate your input on the same, Thanking you in advance. Yours sincerely, Elias Gitonga kaaria On 1/12/06, Tobias Lindgren <tobias.lindgren(a)ip-only.se> wrote: > > Hello, > > Just an example. > > dial-peer voice 1234567 voip > huntstop > application session > destination-pattern 01234567. > progress_ind setup enable 3 > progress_ind progress enable 8 > voice-class codec 10 > session protocol sipv2 > session target sip-server > dtmf-relay rtp-nte > no vad > ! > > The "session target sip-server" is configured within "sip-ua". > > Br, > /T > > Elias Kaaria said the following on 2006-01-10 06:54: > > Dear all, > > Am about to configure cisco AS5350 to forward calls to Ser Sip server, > > kindly forward any configurations for the same. > > > > > > Kind regards, > > Elias Gitonga > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Serusers mailing list > > serusers(a)lists.iptel.org > > http://lists.iptel.org/mailman/listinfo/serusers >

18 years, 4 months

Re: RE : [Serusers] SER amd Minute Provider

by mkumar＠mantragroup.com

Olivier.taylor,I did not exactly get how this will solve my requirement? I just need two lines for my ser.cfg after invite, I am diverting call to my minute provider but here I do not know how to give my account details supplied by my minute provider here if (uri=~"^sip:6[0-8][0-9]*@mantragroup.com"){ strip(1); log(1, "Trying to forward to Teliax.\n"); rewriteuri("username(a)VOIP-CO2.TELIAX.COM"); rewriteuserpass("username:password"); rewritehost("VOIP-CO2.TELIAX.COM"); forward("username:password@VOIP-CO2.TELIAX.COM"); } Can someone please tell me how can I give uri for whom call has to be sent and username,password supplied by my minute provider. I have been trying from two days mailing this list and searching net but sadly I could not find the solution. Thanks for your time and help, Manoj. Quoting "Olivier.taylor" <Olivier.taylor(a)gmail.com>: > Have a try with us if you want... > U can register your ser as a single user, every calls will be billed to > the same account. > > I really don't use to use the mailing list for my marketing but... > > I can open an test account if needed. > > Kind regards, > > Olivier > > -----Message d'origine----- > De : serusers-bounces(a)iptel.org [mailto:serusers-bounces@lists.iptel.org] De > la part de mkumar(a)mantragroup.com > Envoyé : vendredi 10 février 2006 14:52 > À : Waldo Rubinstein > Cc : serusers(a)lists.iptel.org > Objet : Re: [Serusers] SER amd Minute Provider > > > Waldo Rubinstein, even I am shocked with their resonse. > > Can someone please tell me how can I do this or point me to related > links. > > Quoting Waldo Rubinstein <waldo(a)trianet.net>: > >> I am simply in shock to see/hear/read that Teliax is not >> able/capable/ willing to help you. >> >> - Waldo >> >> On Feb 10, 2006, at 2:16 AM, mkumar(a)mantragroup.com wrote: >> >>> Hi All, >>> >>> I added these lines >>> >>> if (uri=~"^sip:5[0-8][0-9]*@mantragroup.com"){ >>> if (!is_user_in("credentials", "ld")) { >>> sl_send_reply("403", "No permission"); >>> break; >>> }; >>> strip(1); >>> log(1, "Trying to forward to Teliax.\n"); > rewriteuri >>> ("sip:username@VOIP-CO2.TELIAX.COM"); > rewriteuserpass >>> ("username:password"); >>> rewritehost("VOIP-CO2.TELIAX.COM"); >>> } >>> >>> I get a respnse error returned not found from ser and If comment >>> these two lines >>> #rewriteuri("sip:username@VOIP-CO2.TELIAX.COM"); > >>> #rewriteuserpass("username:password"); >>> >>> keeping third line it says error number. >>> >>> Please help me and tell me how can I do this correctly? >>> >>> Thanks, >>> Manoj. >>> >>> >>> Quoting "Greger V. Teigre" <greger(a)teigre.com>: >>> >>>> Teliax is not a DID (Direct Inward Dialing) provider? But just a >>>> regular provider of VoIP service? >>>> So all calls will have the same caller-id? >>>> If that is right, you need to use the uac module for >>>> authenticating. It think it still has an issue with a CSeq not >>>> being incremented correctly, so if their GW is strict, it will not >>>> work. I'm not sure if this has been fixed in openser, but I >>>> thought I saw something on it. >>>> Good luck, >>>> g-) >>>> >>>> ----- Original Message ----- From: <mkumar(a)mantragroup.com> >>>> To: "Greger V. Teigre" <greger(a)teigre.com> >>>> Cc: <serusers(a)lists.iptel.org> >>>> Sent: Friday, February 10, 2006 7:11 AM >>>> Subject: Re: [Serusers] SER amd Minute Provider >>>> >>>> >>>>> I contacted Teliax support they have no idea on how to do this so >>>>> I started >>>>> searching myself and I need GSM codec support and I found only >>>>> Teliax for that >>>>> so I have to stick with them even if they do not help me. >>>>> >>>>> Coming to my problem, >>>>> >>>>> I am asking how to send both uri to whom call must be delivered >>>>> and username and >>>>> password provided by minute provider. Using rewrite I can change >>>>> uri for whom >>>>> call must be sent and forward will forward calls to particular > port and >>>>> destination then where can I send username and password provided >>>>> by minute >>>>> provider so that he can validate and deliver my call to that uri. >>>>> >>>>> Thanks, >>>>> Manoj. >>>>> >>>>> Quoting "Greger V. Teigre" <greger(a)teigre.com>: >>>>> >>>>>> That's highly non-standard if teliax requires you to rewrite the >>>>>> ruri with your credentials. If that is correct, they probably >>>>>> have some equally non-standar way to pick up the callee (maybe >>>>>> From?) and you should ask them. >>>>>> g-) >>>>>> ----- Original Message ----- From: <mkumar(a)mantragroup.com> >>>>>> To: "Voipers Portugal" <voipers(a)gmail.com> >>>>>> Cc: <serusers(a)lists.iptel.org> >>>>>> Sent: Friday, February 10, 2006 6:42 AM >>>>>> Subject: Re: [Serusers] SER amd Minute Provider >>>>>> >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> If I rewriteuri with my account credentials provided by minute >>>>>>> provider and >>>>>>> forward it to him then where I am passing the actual PSTN or >>>>>>> URI for whom the >>>>>>> call has to be sent. I have following lines in ser.cfg >>>>>>> >>>>>>> if (uri=~"^sip:4[0-8][0-9]*@mantragroup.com"){ >>>>>>> if (!is_user_in("credentials", "ld")) { sl_send_reply("403", "No >>>>>>> permission"); break; >>>>>>> }; >>>>>>> strip(1); >>>>>>> log(1, "Trying to forward to Teliax.\n"); >>>>>>> rewriteuri("sip:username:password@VOIP-CO2.TELIAX.COM"); >>>>>>> forward("VOIP-CO2.TELIAX.COM", 5060); >>>>>>> } >>>>>>> >>>>>>> Please tell me what must I do here, I am not finding any related > >>>>>>> info. >>>>>>> >>>>>>> Thanks, >>>>>>> Manoj. >>>>>>> >>>>>>> Quoting Voipers Portugal <voipers(a)gmail.com>: >>>>>>> >>>>>>>> Normally you just have to forward the invite message to the >>>>>>>> provider (after >>>>>>>> rewrite the URI of course). >>>>>>>> >>>>>>>> Jose Simoes >>>>>>>> >>>>>>>> >>>>>>>> On 2/9/06, mkumar(a)mantragroup.com <mkumar(a)mantragroup.com> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi All, >>>>>>>>> >>>>>>>>> I purchased some minutes from a minute provider and looking >>>>>>>>> to configure >>>>>>>>> that >>>>>>>>> with SER. But I did not find any documentation or info on how >>>>>>>>> to do that? >>>>>>>>> Please tell me how can I do this or lead me to related >>>>>>>>> documentaion or >>>>>>>>> links. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Manoj. >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >>> >>> _______________________________________________ >>> 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, 4 months

[Users] next_gw(): No ruri_user AVP

by Raymond Chen

Dear all, We have setup a noanswer call forwarding, below is our configuration much like the example from onsip.org if (t_check_status("(480)|(408)")) { if (avp_pushto("$ruri", "s:fwdnoanswer")) { avp_delete("s:fwdnoanswer"); route(6); break; }; }; if (!load_gws()) { sl_send_reply("500", "Server Internal Error - Cannot load gateways"); return; }; ........... if (!next_gw()) { rewriteuri("sip:userbusy@211.102.91.134:443"); t_relay(); return; }; ........... We are not able to get result from next_gw() , debug as follow: 1(2604) load_gws(): DEBUG: Added gw_uri_avp <sip:@xxx.xxx.xxx.xxx:5060> 1(2604) load_gws(): DEBUG: Added gw_uri_avp <sip:@xxx.xxx.xxx.xxx:5060> 1(2604) does_uri_exit(): User in request uri does not exist 1(2604) is_user_in(): User is in group 'local' 1(2604) db_flags=3, flags=12 1(2604) DEBUG:avpops:load_avps: loaded avps = 1 1(2604) parse_headers: flags=ffffffffffffffff 1(2604) DEBUG:avpops:pushto_avps: 1 avps were processed 1(2604) next_gw(): No ruri_user AVP 1(2604) ERROR:tm:t_forward_nonack: no branch for forwarding 1(2604) ERROR: w_t_relay_to: t_relay_to failed Any idea? Thanks Ray

18 years, 4 months

Re: Re: Re: Re: [Serusers] a question about "cancel" in forwarding scenario

by zhangshuai

Dear Antonio Rabena, You mean parallel forking. Not forwarding, right? I receive the correct signal, "486", in parallel forking scenario. Only after the invite was forwarded, I experience the "cancel" problem, which is bothering so many days. Have you tested serial forking or forwarding? >Hi, > >Im also experiencing the same problem. The only diff. is ua2 and >ua3 are using same sip account so when ua1 sends invite to that sip >account, both ua2 and ua3 ring, and when ua1 cancels the call, it >receives 408 Request Timeout". > > > > >At 04:41 PM 2/14/2006, you wrote: >>Dear Greger V. Teigre, >> >> >>I've tried t_on_failure("2"). >> >>failure_route[2] { >> #when caller cancel, terminate the call >> if (t_check_status("487")) { >> log(1,"cancel received\n"); >> t_reply("487", "Request Terminated"); >> break; >> } >>} >> >>There are similar lines in failure_route[1]. When ua2 is ringing and >>ua1 cancel the call, the value of "t_check_status("487")" in >>failure_route[1] will be true. However, When ua3 is ringing and ua1 >>cancel the call, the value of "t_check_status("487")" in >>failure_route[2] will be false. This time, t_check_status() returns >>"408". I don't know why SER generates "408" under this circumstance. >>My ser's version is 0.9.3 and I just run update_from_cvs. And I >>found similar description here: >>http://bugs.sip-router.org/browse/SER-63 >>Is it an unsolved problem? >> >> >> >Do some logging, what happens in the failure route? To me, it looks like >> >your config appends a branch. BTW, run update_from_cvs in your SER source >> >dir top make sure you get the latest bug fixes! >> >g-) >> > > > >_______________________________________________ >Serusers mailing list >serusers(a)lists.iptel.org >http://lists.iptel.org/mailman/listinfo/serusers >

18 years, 4 months

[Users] refer or hold/transfer

by Frogger

I have a successful implementation of openser 0.9.5 and its been working very nicely. I am faced with transferring of calls from pstn to userC by way of userB and I am struggling. path: PSTN=>GW=>SBC=>openser=>uB uB transfers call to uC Call is failing to transfer as "refer" message is not properly handled by my openser script. Any guidance would be appreciated. Transfer works when all legs are from registered clients. Only when the initial call leg is from the PSTN does it not work. Thanks, Rock __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

18 years, 4 months

Re: Re: Re: [Serusers] a question about "cancel" in forwarding scenario

by zhangshuai

Dear Greger V. Teigre, With the attachment is the signal trace. >Do some logging, what happens in the failure route? To me, it looks like >your config appends a branch. BTW, run update_from_cvs in your SER source >dir top make sure you get the latest bug fixes! >g-) > >----- Original Message ----- >From: "zhangshuai" <zhangshuai(a)goldentek.biz> >To: "serusers" <serusers(a)lists.iptel.org> >Cc: "wuyuan" <wuyuan(a)goldentek.biz> >Sent: Tuesday, February 14, 2006 3:49 AM >Subject: Re: Re: [Serusers] a question about "cancel" in forwarding scenario > > >> Dear Greger V. Teigre, >> >> >> >> Thanks for your quick reply. >> >> I have read the sergettingstarted05.pdf (Based upon SER version 0.9.3) and >> tested the onr.cfg in >> ser-0.9.3.GettingStarted.1.3.tar.gz/ser-0.9.3/examples many times. SER >> sent out "408" to caller immediately after received "486" from ua3. I >> don't know how does ser's failure route deal with this kind of "cancel" >> when the invite has been forwarded. Any ideas will help me a lot. Thanks! >> >> Here is the onr.cfg: >> >> # ------------------ module loading ---------------------------------- >> loadmodule "/usr/local/lib/ser/modules/sl.so" >> loadmodule "/usr/local/lib/ser/modules/tm.so" >> # ----------------- setting module-specific parameters --------------- >> >> # -- tm params -- >> # set time for which ser will be waiting for a final response; >> # fr_inv_timer sets value for INVITE transactions, fr_timer >> # for all others >> modparam("tm", "fr_inv_timer", 15 ) >> modparam("tm", "fr_timer", 10 ) >> >> # ------------------------- request routing logic ------------------- >> >> # main routing logic >> >> route{ >> # for testing purposes, simply okay all REGISTERs >> if (method=="REGISTER") { >> log("REGISTER"); >> sl_send_reply("200", "ok"); >> break; >> }; >> # try these two destinations first in parallel; the second >> # destination is targeted to sink port -- that will make ser >> # wait until timer hits >> seturi("sip:200@218.97.252.35:5060"); >> #append_branch("sip:300@218.97.252.36:5060"); >> # if we do not get a positive reply, continue at reply_route[1] >> t_on_failure("1"); >> # forward the request to all destinations in destination set now >> t_relay(); >> } >> >> failure_route[1] { >> #when caller cancel, terminate the call >> if (t_check_status("487")) { >> t_reply("487", "Request Terminated"); >> break; >> }; >> # forwarding failed -- try again at another destination >> append_branch("sip:300@218.97.252.44:5060"); >> log(1,"first redirection\n"); >> # if this alternative destination fails too, proceed to >> reply_route[2] >> #t_on_failure("2"); >> t_relay(); >> } >> >> >> Thanks in advance. >> >> Have a good day! >> >> >> >> Shuai >> >> >>>The internal SER timer hits and the request times out (the request is not >>>terminated). >>>See SER-GettingStarted doc at ONsip.org for a full example of call >>>features >>>like forwarding. >>>g-) >>>----- Original Message ----- >>>From: "zhangshuai" <zhangshuai(a)goldentek.biz> >>>To: "serusers" <serusers(a)lists.iptel.org> >>>Cc: "wuyuan" <wuyuan(a)goldentek.biz> >>>Sent: Friday, February 10, 2006 11:18 AM >>>Subject: [Serusers] a question about "cancel" in forwarding scenario >>> >>> >>>> Dear All, >>>> >>>> >>>> I want to make use of avpops module to achieve forward on-no-reply. When >>>> ua1 calls ua2 and ua2 is off-line, or busy, or doesn't answer the phone, >>>> the invite should be forwarded to ua3 and ua3 begins ringing. >>>> >>>> In my tests, first, ua1 sends "cancel" when ua2 is ringing. Ua1 receives >>>> "487 Request Terminated" from SER. Second, ua1 sends "cancel" when ua3 >>>> is >>>> ringing. So, theoretically, ua1 should receive "487 Request Terminated" >>>> after "200 canceling" from SER, right? But, ua1 received "408 Request >>>> Timeout" instead. So strange. How come? >>>> >>>> I think something is wrong with my ser.cfg. Could anyone help me about >>>> this? Thanks in advance. >>>> >>>> Here is my ser.cfg: >>>> >>>> # ------------------ module loading ---------------------------------- >>>> >>>> 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/textops.so" >>>> loadmodule "/usr/local/lib/ser/modules/avp.so" >>>> loadmodule "/usr/local/lib/ser/modules/acc.so" >>>> loadmodule "/usr/local/lib/ser/modules/mysql.so" >>>> loadmodule "/usr/local/lib/ser/modules/dbtext.so" >>>> loadmodule "/usr/local/lib/ser/modules/avpops.so" >>>> #loadmodule "/usr/local/lib/ser/modules/postgres.so" >>>> #loadmodule "/usr/local/lib/ser/modules/flatstore.so" >>>> >>>> # Uncomment this if you want digest authentication >>>> # mysql.so must be loaded ! >>>> loadmodule "/usr/local/lib/ser/modules/auth.so" >>>> #loadmodule "/usr/local/lib/ser/modules/auth_db.so" >>>> >>>> loadmodule "/usr/local/lib/ser/modules/auth_radius.so" >>>> loadmodule "/usr/local/lib/ser/modules/group_radius.so" >>>> loadmodule "/usr/local/lib/ser/modules/uri_radius.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", 1) >>>> >>>> # -- 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") >>>> >>>> # -- rr params -- >>>> # add value to ;lr param to make some broken UAs happy >>>> >>>> modparam("rr", "enable_full_lr", 1) >>>> modparam("tm", "fr_timer", 10 ) >>>> modparam("tm", "fr_inv_timer", 20) >>>> modparam("tm", "noisy_ctimer", 1) >>>> >>>> modparam("auth_radius|uri_radius|group_radius", "radius_config", >>>> "/usr/local/etc/radiusclient-ng/radiusclient.conf") >>>> >>>> modparam("avpops","avp_url","mysql://ser:heslo@localhost/ser") >>>> modparam("avpops","avp_table","usr_preferences") >>>> # ------------------------- 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"); >>>> break; >>>> }; >>>> if (msg:len >= 2048 ) { >>>> sl_send_reply("513", "Message too big"); >>>> break; >>>> }; >>>> >>>> if (!method=="REGISTER") record_route(); >>>> >>>> if (loose_route()) { >>>> t_relay(); >>>> break; >>>> }; >>>> >>>> if (method=="INVITE") { >>>> lookup("location"); >>>> #if (!lookup("location")) { >>>> # sl_send_reply("404", "Not Found"); >>>> # break; >>>> #}; >>>> } >>>> >>>> if (method=="REGISTER") { >>>> log("REGISTER\n"); >>>> if (!radius_www_authorize("localhost.localdomain")) { >>>> www_challenge("localhost.localdomain", "0"); >>>> break; >>>> }; >>>> save("location"); >>>> break; >>>> }; >>>> >>>> if (method=="INVITE") { >>>> if (!radius_proxy_authorize("localhost.localdomain")) { >>>> proxy_challenge("localhost.localdomain", "1"); >>>> break; >>>> }; >>>> } >>>> >>>> # if we do not get a positive reply, continue at failure_route[1] >>>> t_on_failure("1"); >>>> # forward the request to all destinations in destination set now >>>> t_relay(); >>>> >>>> #if (!t_relay()) { >>>> # sl_reply_error(); >>>> #}; >>>> } >>>> >>>> failure_route[1] { >>>> >>>> #when caller cancel, terminate the call >>>> if (t_check_status("487")) { >>>> t_reply("487", "Request Terminated"); >>>> break; >>>> }; >>>> >>>> if ( ( avp_db_load("$ruri","s:redirect_on_failure") && >>>> avp_check("redirect_on_failure","eq/i:1"))) { >>>> # User need to forward >>>> log(1, "User wants redirection.\n"); >>>> if ( ( avp_db_load("$ruri","s:redirectnumber") && >>>> !avp_check("redirectnumber","re/^$"))) { >>>> log(1,"first redirect\n"); >>>> #avp_print(); >>>> attr2uri("redirect number"); >>>> lookup("location"); >>>> append_branch(); >>>> #t_on_failure("2"); >>>> t_relay(); >>>> } >>>> else { >>>> t_reply("408", "TimeOut"); >>>> break; >>>> }; >>>> } >>>> else { >>>> t_reply("404", "Not Found"); >>>> break; >>>> }; >>>> } >>>> >>>> >>>> _______________________________________________ >>>> 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, 4 months

← Newer
1
...
18
19
20
21
22
23
24
...
38
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 February 2006