Hi All,
I am using serweb stable 0.9.2 version and I followed all the steps in INSTALL
file that comes with the installation. After my configuration when I try to
load the url
http://serweb.mantragroup.com/serweb/html/admin/index.php
strangly nothing is getting displayed and no error messages are logged in any
log. I am using
Apache/2.0.51
PHP 4.4.1
Mysql 4.0.25
Did anyone experience this problem before? Please tell me what should I do to
configure serweb properly?
Thanks,
Kumar.
Hi
We have a running IMS test - system without HSS functionality at the
moment.
Next step to realize are the Initial Filter Criteria.
->
I want to create my own db_scheme, where I can store the required values
of the user profile.
My questions are:
- How can use the db_scheme beside the default avp_table (
usr_preferences ) ?
- Avp's only have 1 value column. How can I load different
attributes , if the parameters are stored in different columns of the
self defined table
Mfg
Andreas Broch
FTW
Hi,
I have an OpenSER DISPATCHER instance successfully forwarding requests
to one of four OpenSER "worker" instances. I need to authorize by
originating IP on the worker machines but of course requests are only
coming from the dispatcher machine.
I had thought of having the dispatcher drop the originating IP in the
headers but haven't been able to figure out how to do that. Something
like append_hf( "origin: $si\r\n" );?
I had also thought about having the dispatcher send back a 302 Moved
Temporarily but can't figure out how to get at the dispatched IP.
Is there a better way to be doing this short of checking for the IP on
the dispatcher? I had hoped to avoid that in favor of having the
dispatcher handle extreme load.
Thanks.
-Anders
hi everyone! i've just installed ser_0.9.6 on my debian pc, included also ser-mysql and ser-jabber and ser-acc...etc. i've included my ser.cfg and restarted ser and it displays an error at the end saying Segmentation fault.. i don't know what to do with it since i'm still new to ser... here's my config file...can anyone help me work this out?
ryan
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Dear Greger V. Teigre,
Take it easy. I really appreciate your spending time to help me figure it out. Of course I have tested the onr.cfg, a non-altered version of the onsip.org script, for many times. As I said before, the following lines:
#when caller cancel, terminate the call
if (t_check_status("487")) {
log("cancel received\n");
t_reply("487", "Request Terminated");
break;
};
in failure_route[1] never took effect in my test, because there is no corresponding log in debug info at all! Those lines only work under this circumstance: when ua1 calls ua2, ua1 cancels the call before timer hits. So, please check the debug info, I sent out last time, again
to confirm my thought.
Thanks a million.
>Your INVITE to seturi() to 200@ times out:
>0(20167) receive_msg: cleaning up
> 1(20168) DEBUG: timer routine:4,tl=0x422b9e50 next=(nil)
> 1(20168) DEBUG: retransmission_handler : request resending (t=0x422b9d38,
>INVITE si ... )
> 1(20168) DEBUG: add_to_tail_of_timer[5]: 0x422b9e50
> 1(20168) DEBUG: retransmission_handler : done
> 1(20168) DEBUG: timer routine:5,tl=0x422b9e50 next=(nil)
> 1(20168) DEBUG: retransmission_handler : request resending (t=0x422b9d38,
>INVITE si ... )
> 1(20168) DEBUG: add_to_tail_of_timer[6]: 0x422b9e50
> 1(20168) DEBUG: retransmission_handler : done
> 1(20168) DEBUG: timer routine:6,tl=0x422b9e50 next=(nil)
> 1(20168) DEBUG: retransmission_handler : request resending (t=0x422b9d38,
>INVITE si ... )
> 1(20168) DEBUG: add_to_tail_of_timer[7]: 0x422b9e50
> 1(20168) DEBUG: retransmission_handler : done
> 1(20168) DEBUG: timer routine:0,tl=0x422b9e60 next=(nil)
> 1(20168) DEBUG: final_response_handler:stop retr. and send CANCEL
>(0x422b9d38)
> 1(20168) ->>>>>>>>> T_code=100, new_code=408
> 1(20168) DEBUG: t_check: msg id=0 global id=0 T start=0x422b9d38
> 1(20168) DEBUG: t_check: T already found!
> 1(20168) DEBUG:t_check_status: checked status is <408>
>
>then it's forwarded in t_on_failure to 300@
>
>The CANCEL is received ok, forwarded ok and the 487 should NOT be met with a
>t_reply, but just break in t_on_failure!!
>
>
>As you have effectively dealt with the 487, SER only has a 408 left to send
>back.
>
>:-( I told you to use the callfwd script from onsip.org!! But you used your
>own f... up test script instead, and stupid me spent time on trying to
>figure it out. Have you tried a non-altered version of the onsip.org script
>at all?!
>
>g-(
>
>----- Original Message -----
>From: "zhangshuai" <zhangshuai(a)goldentek.biz>
>To: "serusers" <serusers(a)lists.iptel.org>
>Cc: "wuyuan" <wuyuan(a)goldentek.biz>
>Sent: Wednesday, February 15, 2006 10:18 AM
>Subject: Re: Re: Re: Re: [Serusers] a question about "cancel"
>inforwardingscenario
>
>
>> Dear Greger V. Teigre,
>>
>>
>> Thanks for your suggestion.
>>
>> I've reset the fr_inv_timer and debug level, and put some log functions
>> into ser.cfg:
>>
>> # ----------- global configuration parameters ------------------------
>>
>> debug=7 # debug level (cmd line: -dddddddddd)
>> fork=no
>> log_stderror=yes # (cmd line: -E)
>>
>> listen=218.97.252.39
>> check_via=no # (cmd. line: -v)
>> dns=no # (cmd. line: -r)
>> rev_dns=no # (cmd. line: -R)
>> #port=5060
>> #children=4
>> alias=localhost.localdomain
>> alias=218.97.252.39
>>
>> # ------------------ 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", 120 )
>> modparam("tm", "fr_timer", 10 )
>>
>> # ------------------------- request routing logic -------------------
>>
>> # main routing logic
>>
>>
>> route{
>> # for testing purposes, simply okay all REGISTERs
>> if (method=="REGISTER") {
>> log("REGISTER\n");
>> sl_send_reply("200", "ok");
>> break;
>> };
>> seturi("sip:200@218.97.252.35:5060");
>> # if we do not get a positive reply, continue at reply_route[1]
>> log("for test\n");
>> 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")) {
>> log("cancel received\n");
>> 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();
>> }
>>
>> Here is my test:
>>
>> When ua1(sip:100@localhost.localdomain:5060) call
>> <sip:400@localhost.localdomain:5060>, SER, at once, rewrites uri and sends
>> invite to ua2(sip:200@218.97.252.35:5060). But because ua2 is offline, SER
>> forwards the invite to ua3(sip:300@218.97.252.44:5060) and then ua3 begins
>> ringing. Now, ua1 sends cancel to SER, SER sends cancel to ua3. ua3
>> returns "487" to SER and SER sends "408" to ua1. I don't know whether the
>> timers were reset properly before forwarding.
>>
>> And with the attachment is the ser debug info. Please have a look.
>>
>> Thanks again.
>>
>>>I think you need to make an ngrep SIP trace of the two scenarios. SER will
>>>not generate a 408 unless the timer hits. Increase the timer (it will be
>>>easier to see what happens). You use a very low timer value
>>>(fr_inv_timer=15). Set it to 120. Then look for the CANCEL from ua3. Does
>>>SER receive the CANCEL and process it (use debug mode 7)?
>>>I'm not sure if this is the same as mentioned in the bug referred to in
>>>another reply, but let's try to find out.
>>>Please post the ngrep trace for the two scenarios.
>>>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 9:41 AM
>>>Subject: Re: Re: Re: [Serusers] a question about "cancel" in
>>>forwardingscenario
>>>
>>>
>>>> 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-)
>>>>>
>>>>>----- 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
>>>>>>
>>>>>
>>>>>
>>>>
>>>> = = = = = = = = = = = = = = = = = = = =
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
>
>
= = = = = = = = = = = = = = = = = = = =
Ray,
I think there is a problem in the script - if you see the gw_uri avps,
it's quite impossible not to see them also before and after the
next_gw() call in request route. Disregarding the ruri_avp, the gw_uri
avps should be visible.
are you sure you do not delete all the avps in your script. Try placing
avp_print before and after each lcr function call.
regards,
bogdan
Raymond Chen wrote:
>Hi bogdan,
>
>I put avp_print after next_gw , no avp output.
>
>
>1(1334) load_gws(): DEBUG: Added gw_uri_avp <sip:@xxx.xxx.xxx.138:5060>
> 1(1334) load_gws(): DEBUG: Added gw_uri_avp <sip:@xxx.xxx.xxx.139:5060>
> 1(1334) does_uri_exit(): User in request uri does not exist
> 1(1334) is_user_in(): User is in group 'local'
> 1(1334) db_flags=3, flags=12
> 1(1334) DEBUG:avpops:load_avps: loaded avps = 1
> 1(1334) parse_headers: flags=ffffffffffffffff
> 1(1334) DEBUG:avpops:pushto_avps: 1 avps were processed
>1(1334) next_gw(): No ruri_user AVP
>
>
>
>
>
>
>-----Original Message-----
>From: Bogdan-Andrei Iancu [mailto:bogdan@voice-system.ro]
>Sent: Wednesday, February 15, 2006 4:39 AM
>To: Raymond Chen
>Cc: daniel(a)voice-system.ro; Users(a)openser.org
>Subject: Re: [Users] next_gw(): No ruri_user AVP
>
>Ray,
>
>the ruri_avp is added by next_gw after its usage from the REQUEST route.
>You may check this by placing an avp_print after you did next_gw() in
>request route (after calling route 3, for example). Check if there is
>any avp with ID 1402.
>
>regards,
>bogdan
>
>Raymond Chen wrote:
>
>
>
>>Hi bogdan,
>>
>>We called Load_gw and next-gw from request route. We have no problem with
>>next_gw if the if (avp_pushto("$ruri", "s:fwdnoanswer")) happens in the
>>
>>
>main
>
>
>>route. But when it does in the failure_route the next_gw can't find the
>>ruri_user avp.
>>
>>Raymond
>>
>>
>>
>>Route {
>>
>> ..........
>>
>> Route(3);
>>
>> ...........
>>
>>}
>>
>>failure_route[1] {
>>
>> if (t_check_status("(480)|(408)")) {
>> if (avp_pushto("$ruri", "s:fwdnoanswer")) {
>> avp_delete("s:fwdnoanswer");
>> route(3);
>> };
>> };
>>
>>}
>>
>>Route[3] {
>>
>> if (!load_gws()) {
>> sl_send_reply("500", "Server Internal Error - Cannot load
>>gateways");
>> return;
>> };
>>
>> ...............
>>
>> Route(5);
>>
>>}
>>
>>Route[5] {
>>
>> if (!next_gw()) {
>> rewriteuri("sip:userbusy@211.102.91.134:443");
>> t_relay();
>> return;
>> };
>>
>> ..............
>>
>>}
>>
>>
>>
>>-----Original Message-----
>>From: Bogdan-Andrei Iancu [mailto:bogdan@voice-system.ro]
>>Sent: Wednesday, February 15, 2006 2:25 AM
>>To: Raymond Chen
>>Cc: daniel(a)voice-system.ro; Users(a)openser.org
>>Subject: Re: [Users] next_gw(): No ruri_user AVP
>>
>>Hi Ray,
>>
>>do you call load_gws() from failure route? if so, not that this is not
>>supported.
>>For LCR to work properly, you need to call load_gws() and next_gw() from
>>the request route and later next_gw() from failure routes.
>>
>>regards,
>>bogdan
>>
>>Raymond Chen wrote:
>>
>>
>>
>>
>>
>>>Hi Bogdan,
>>>
>>>Here is the debug
>>>
>>>1(2584) load_gws(): DEBUG: Added gw_uri_avp <sip:@xxx.xxx.xxx.138:5060>
>>>1(2584) load_gws(): DEBUG: Added gw_uri_avp <sip:@xxx.xxx.xxx.139:5060>
>>>1(2584) DEBUG:avpops:print_avp: p=0xf4f167c8, flags=2
>>>1(2584) DEBUG: id=<1400>
>>>1(2584) DEBUG: val_str=<sip:@xxx.xxx.xxx.139:5060>
>>>1(2584) DEBUG:avpops:print_avp: p=0xf4f16790, flags=2
>>>1(2584) DEBUG: id=<1400>
>>>1(2584) DEBUG: val_str=<sip:@xxx.xxx.xxx.138:5060>
>>>1(2584) does_uri_exit(): User in request uri does not exist
>>>1(2584) is_user_in(): User is in group 'local'
>>>1(2584) db_flags=3, flags=12
>>>1(2584) DEBUG:avpops:print_avp: p=0xf4f167f8, flags=B
>>>1(2584) DEBUG: id=<1400>
>>>1(2584) DEBUG: val_str=<sip:@xxx.xxx.xxx.139:5060>
>>>1(2584) DEBUG:avpops:print_avp: p=0xf4f16790, flags=2
>>>1(2584) DEBUG: id=<1400>
>>>1(2584) DEBUG: val_str=<sip:@xxx.xxx.xxx.xxx:5060>
>>>1(2584) next_gw(): No ruri_user AVP
>>>
>>>
>>>
>>>Raymond
>>>
>>>
>>>-----Original Message-----
>>>From: Bogdan-Andrei Iancu [mailto:bogdan@voice-system.ro]
>>>Sent: Tuesday, February 14, 2006 10:55 AM
>>>To: Raymond Chen
>>>Cc: daniel(a)voice-system.ro; Users(a)openser.org
>>>Subject: Re: [Users] next_gw(): No ruri_user AVP
>>>
>>>Hi Ray,
>>>
>>>use avp_print() after the load_gw() to see what avps were loaded and
>>>again just before next_gw() to see the available avp.
>>>this will help to see if it's a problem at the load or search part.
>>>
>>>regards,
>>>bogdan
>>>
>>>
Ray,
the ruri_avp is added by next_gw after its usage from the REQUEST route.
You may check this by placing an avp_print after you did next_gw() in
request route (after calling route 3, for example). Check if there is
any avp with ID 1402.
regards,
bogdan
Raymond Chen wrote:
>Hi bogdan,
>
>We called Load_gw and next-gw from request route. We have no problem with
>next_gw if the if (avp_pushto("$ruri", "s:fwdnoanswer")) happens in the main
>route. But when it does in the failure_route the next_gw can't find the
>ruri_user avp.
>
>Raymond
>
>
>
>Route {
>
> ..........
>
> Route(3);
>
> ...........
>
>}
>
>failure_route[1] {
>
> if (t_check_status("(480)|(408)")) {
> if (avp_pushto("$ruri", "s:fwdnoanswer")) {
> avp_delete("s:fwdnoanswer");
> route(3);
> };
> };
>
>}
>
>Route[3] {
>
> if (!load_gws()) {
> sl_send_reply("500", "Server Internal Error - Cannot load
>gateways");
> return;
> };
>
> ...............
>
> Route(5);
>
>}
>
>Route[5] {
>
> if (!next_gw()) {
> rewriteuri("sip:userbusy@211.102.91.134:443");
> t_relay();
> return;
> };
>
> ..............
>
>}
>
>
>
>-----Original Message-----
>From: Bogdan-Andrei Iancu [mailto:bogdan@voice-system.ro]
>Sent: Wednesday, February 15, 2006 2:25 AM
>To: Raymond Chen
>Cc: daniel(a)voice-system.ro; Users(a)openser.org
>Subject: Re: [Users] next_gw(): No ruri_user AVP
>
>Hi Ray,
>
>do you call load_gws() from failure route? if so, not that this is not
>supported.
>For LCR to work properly, you need to call load_gws() and next_gw() from
>the request route and later next_gw() from failure routes.
>
>regards,
>bogdan
>
>Raymond Chen wrote:
>
>
>
>>Hi Bogdan,
>>
>>Here is the debug
>>
>>1(2584) load_gws(): DEBUG: Added gw_uri_avp <sip:@xxx.xxx.xxx.138:5060>
>>1(2584) load_gws(): DEBUG: Added gw_uri_avp <sip:@xxx.xxx.xxx.139:5060>
>>1(2584) DEBUG:avpops:print_avp: p=0xf4f167c8, flags=2
>>1(2584) DEBUG: id=<1400>
>>1(2584) DEBUG: val_str=<sip:@xxx.xxx.xxx.139:5060>
>>1(2584) DEBUG:avpops:print_avp: p=0xf4f16790, flags=2
>>1(2584) DEBUG: id=<1400>
>>1(2584) DEBUG: val_str=<sip:@xxx.xxx.xxx.138:5060>
>>1(2584) does_uri_exit(): User in request uri does not exist
>>1(2584) is_user_in(): User is in group 'local'
>>1(2584) db_flags=3, flags=12
>>1(2584) DEBUG:avpops:print_avp: p=0xf4f167f8, flags=B
>>1(2584) DEBUG: id=<1400>
>>1(2584) DEBUG: val_str=<sip:@xxx.xxx.xxx.139:5060>
>>1(2584) DEBUG:avpops:print_avp: p=0xf4f16790, flags=2
>>1(2584) DEBUG: id=<1400>
>>1(2584) DEBUG: val_str=<sip:@xxx.xxx.xxx.xxx:5060>
>>1(2584) next_gw(): No ruri_user AVP
>>
>>
>>
>>Raymond
>>
>>
>>-----Original Message-----
>>From: Bogdan-Andrei Iancu [mailto:bogdan@voice-system.ro]
>>Sent: Tuesday, February 14, 2006 10:55 AM
>>To: Raymond Chen
>>Cc: daniel(a)voice-system.ro; Users(a)openser.org
>>Subject: Re: [Users] next_gw(): No ruri_user AVP
>>
>>Hi Ray,
>>
>>use avp_print() after the load_gw() to see what avps were loaded and
>>again just before next_gw() to see the available avp.
>>this will help to see if it's a problem at the load or search part.
>>
>>regards,
>>bogdan
>>
>>Raymond Chen wrote:
>>
>>
>>
>>
>>
>>>Hi Daniel,
>>>
>>>The problem we have is not about next_gw forward to
>>>userbusy(a)xxx.xxx.xxx.xxx. We have no problem with load_gw, it loads two
>>>gateways against ruri_user correctly. but when next_gw called, it saids
>>>
>>>next_gw(): No ruri_user AVP
>>>
>>>looks like ruri_user avp is not saved when load_gw was called. So next_gw
>>>can't find the ruri_user avp.
>>>
>>>Thanks
>>>
>>>Ray
>>>
>>>
>>>-----Original Message-----
>>>From: Daniel-Constantin Mierla [mailto:daniel@voice-system.ro]
>>>Sent: Tuesday, February 14, 2006 1:44 AM
>>>To: Raymond Chen
>>>Cc: Users(a)openser.org
>>>Subject: Re: [Users] next_gw(): No ruri_user AVP
>>>
>>>Hello,
>>>
>>>On 02/14/06 13:43, Raymond Chen wrote:
>>>
>>>
>>>
>>>
>>>
>>>
>>>>[...]
>>>> if (!next_gw()) {
>>>> rewriteuri("sip:userbusy@211.102.91.134:443");
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>here you must call append_branch() so the rewriteuri() has the desired
>>>effect.
>>>
>>>Cheers,
>>>Daniel
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>> t_relay();
>>>> return;
>>>> };
>>>>
>>>> ...........
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>_______________________________________________
>>>Users mailing list
>>>Users(a)openser.org
>>>http://openser.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>
>
>
>
>
>
hi! i've installed SER using apt-get in debian and having some errors when running it while when i installed it from source using centos it accepts my cfg file but i've seen that it's easy to install it on debian systems only that i'm having this kind of problem, can anyone direct me to some link wherein i can read about having this error "segmentation fault" at the end when running SER?
thanks in advance! :-)
ryanalupa
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Hi,
I'm having some problem forwarding to Asterisk VM. What i want is when ever
486, 404, 408 or 480 error triger then ser should forward INVITE to
Asterisk.
Some one please tell me where and what i write in my
features-callfwd.5.0.cfg so it will forward to my asterisk box.
Thanks,
Ali... :lol:
Hi Ray,
do you call load_gws() from failure route? if so, not that this is not
supported.
For LCR to work properly, you need to call load_gws() and next_gw() from
the request route and later next_gw() from failure routes.
regards,
bogdan
Raymond Chen wrote:
>Hi Bogdan,
>
>Here is the debug
>
>1(2584) load_gws(): DEBUG: Added gw_uri_avp <sip:@xxx.xxx.xxx.138:5060>
> 1(2584) load_gws(): DEBUG: Added gw_uri_avp <sip:@xxx.xxx.xxx.139:5060>
> 1(2584) DEBUG:avpops:print_avp: p=0xf4f167c8, flags=2
> 1(2584) DEBUG: id=<1400>
> 1(2584) DEBUG: val_str=<sip:@xxx.xxx.xxx.139:5060>
> 1(2584) DEBUG:avpops:print_avp: p=0xf4f16790, flags=2
> 1(2584) DEBUG: id=<1400>
> 1(2584) DEBUG: val_str=<sip:@xxx.xxx.xxx.138:5060>
> 1(2584) does_uri_exit(): User in request uri does not exist
> 1(2584) is_user_in(): User is in group 'local'
> 1(2584) db_flags=3, flags=12
>1(2584) DEBUG:avpops:print_avp: p=0xf4f167f8, flags=B
>1(2584) DEBUG: id=<1400>
> 1(2584) DEBUG: val_str=<sip:@xxx.xxx.xxx.139:5060>
> 1(2584) DEBUG:avpops:print_avp: p=0xf4f16790, flags=2
> 1(2584) DEBUG: id=<1400>
> 1(2584) DEBUG: val_str=<sip:@xxx.xxx.xxx.xxx:5060>
> 1(2584) next_gw(): No ruri_user AVP
>
>
>
>Raymond
>
>
>-----Original Message-----
>From: Bogdan-Andrei Iancu [mailto:bogdan@voice-system.ro]
>Sent: Tuesday, February 14, 2006 10:55 AM
>To: Raymond Chen
>Cc: daniel(a)voice-system.ro; Users(a)openser.org
>Subject: Re: [Users] next_gw(): No ruri_user AVP
>
>Hi Ray,
>
>use avp_print() after the load_gw() to see what avps were loaded and
>again just before next_gw() to see the available avp.
>this will help to see if it's a problem at the load or search part.
>
>regards,
>bogdan
>
>Raymond Chen wrote:
>
>
>
>>Hi Daniel,
>>
>>The problem we have is not about next_gw forward to
>>userbusy(a)xxx.xxx.xxx.xxx. We have no problem with load_gw, it loads two
>>gateways against ruri_user correctly. but when next_gw called, it saids
>>
>>next_gw(): No ruri_user AVP
>>
>>looks like ruri_user avp is not saved when load_gw was called. So next_gw
>>can't find the ruri_user avp.
>>
>>Thanks
>>
>>Ray
>>
>>
>>-----Original Message-----
>>From: Daniel-Constantin Mierla [mailto:daniel@voice-system.ro]
>>Sent: Tuesday, February 14, 2006 1:44 AM
>>To: Raymond Chen
>>Cc: Users(a)openser.org
>>Subject: Re: [Users] next_gw(): No ruri_user AVP
>>
>>Hello,
>>
>>On 02/14/06 13:43, Raymond Chen wrote:
>>
>>
>>
>>
>>>[...]
>>> if (!next_gw()) {
>>> rewriteuri("sip:userbusy@211.102.91.134:443");
>>>
>>>
>>>
>>>
>>>
>>here you must call append_branch() so the rewriteuri() has the desired
>>effect.
>>
>>Cheers,
>>Daniel
>>
>>
>>
>>
>>
>>> t_relay();
>>> return;
>>> };
>>>
>>> ...........
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>_______________________________________________
>>Users mailing list
>>Users(a)openser.org
>>http://openser.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>>
>>
>
>
>
>
>
>
