[Serusers] handling failure after directing to application server
Greg Martin
Greg.Martin at TELUS.COM
Thu Apr 28 17:42:23 CEST 2005
What I see happen is a 404 comes back (in the reply route) and then is identified as a failure. At that point I revert to the original address, set a flag and relay. The relay cause the route logic to run so I check for the flag so not to send to the application server but the flag is never set. I
tried sending a trying before sending to the application server but it doesn't change the behaviour.
> -----Original Message-----
> From: Iqbal [mailto:iqbal at gigo.co.uk]
> Sent: Thursday, April 28, 2005 9:28 AM
> To: Greg Martin
> Cc: serusers at lists.iptel.org
> Subject: Re: [Serusers] handling failure after directing to
> application server
>
> Hi
>
> I re-read my reply, and didnt follow it either :-)
>
> From what I understand , if there is a loose_route then it
> goes to route[1], and then in route[1] call is relayed, and
> when there is a reply goto on_reply route, and you should see
>
> xlog("L_NOTICE", "Reply status %rs: Reason %rr\n"); }
>
> After this Log is displayed, where are you going back to. If
> you get a reply, then you will not goto into failure route
> and get your flag set, and the failure, shouldnt that be
> after the relay. Even I'm getting confused now :-).
>
> In fact I have a question , is a failure, also considered a
> reply, which means that t_on_failure should come before
> t_on_reply....I am not sure about this so will post a
> separate question
>
> iqbal
>
>
>
> Greg Martin wrote:
>
> >
> >I don't understand your reply. At the bottom of the config
> there is a onreply_route and a failure_route and the logging
> statements in each do get written out. What I don't see is
> isflagset(1) return true.
> >
> >
> >
> >>-----Original Message-----
> >>From: Iqbal [mailto:iqbal at gigo.co.uk]
> >>Sent: Wednesday, April 27, 2005 4:51 PM
> >>To: Greg Martin; serusers at lists.iptel.org
> >>Subject: Re: [Serusers] handling failure after directing to
> >>application server
> >>
> >>
> >>on failure and reply you are telling it where to go, but that route
> >>doesnt exist, or not at least in ur config given below.
> >>
> >>Also route [2] doesnt really do anything..
> >>
> >>Iqbal
> >>
> >>On 4/27/2005, "Greg Martin" <Greg.Martin at TELUS.COM> wrote:
> >>
> >>
> >>
> >>>I'm trying to direct requests to registered users to another proxy
> >>>which has an application server. Right now the proxy simply
> >>>
> >>>
> >>sends a 404 back. In that case I want to simply complete the call.
> >>What I am doing is looping until the ser has had enough.
> I've tried to
> >>set a flag to prevent it but the flag is in fact never set although
> >>the logs indicate it's the same transaction. Any comments?
> >>
> >>
> >>>debug=3
> >>>fork=yes
> >>>log_stderror=no
> >>>dns=no
> >>>rev_dns=no
> >>>fifo="/tmp/ser_fifo"
> >>>fifo_db_url="mysql://ser:heslo@localhost/ser"
> >>>
> >>>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/exec.so"
> >>>loadmodule "/usr/local/lib/ser/modules/xlog.so"
> >>>
> >>>modparam("usrloc", "db_mode", 1)
> >>>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;
> >>> };
> >>>
> >>> xlog("L_NOTICE", "Method <%rm> r-uri <%ru>\n");
> >>>
> >>> #
> >>>
> >>>
> >>--------------------------------------------------------------
> >>----------
> >>
> >>
> >>> # Record Route Section
> >>> #
> >>>
> >>>
> >>--------------------------------------------------------------
> >>----------
> >>
> >>
> >>> if (method != "REGISTER") {
> >>> record_route();
> >>> };
> >>>
> >>> #
> >>>
> >>>
> >>--------------------------------------------------------------
> >>----------
> >>
> >>
> >>> # Loose Route Section
> >>> #
> >>>
> >>>
> >>--------------------------------------------------------------
> >>----------
> >>
> >>
> >>> if (loose_route()) {
> >>> route(1);
> >>> break;
> >>> };
> >>>
> >>> #
> >>>
> >>>
> >>--------------------------------------------------------------
> >>----------
> >>
> >>
> >>> # Call Type Processing Section
> >>> #
> >>>
> >>>
> >>--------------------------------------------------------------
> >>----------
> >>
> >>
> >>> if (uri != myself) {
> >>> route(1);
> >>> break;
> >>> };
> >>>
> >>> if (uri == myself) {
> >>> if (method == "REGISTER") {
> >>> route(2);
> >>> break;
> >>> };
> >>>
> >>> if (!lookup("location")) {
> >>> sl_send_reply("404", "User Not Found");
> >>> break;
> >>> };
> >>>
> >>> route(1);
> >>> };
> >>>}
> >>>
> >>>route[1] {
> >>> #
> >>>
> >>>
> >>--------------------------------------------------------------
> >>----------
> >>
> >>
> >>> # Default Message Handler
> >>> #
> >>>
> >>>
> >>--------------------------------------------------------------
> >>----------
> >>
> >>
> >>> xlog("L_NOTICE", "route[1] *****\n");
> >>>
> >>> t_on_reply("1");
> >>>
> >>> if(isflagset(1))
> >>> {
> >>> xlog("L_NOTICE", "RELAYING.\n");
> >>> resetflag(1);
> >>> if (!t_relay()) {
> >>> sl_reply_error();
> >>> break;
> >>> };
> >>> };
> >>>
> >>> t_on_failure("1");
> >>>
> >>> t_relay_to_udp("app_servers_address", "5060");
> >>>
> >>>
> >>>}
> >>>
> >>>route[2] {
> >>> #
> >>>
> >>>
> >>--------------------------------------------------------------
> >>----------
> >>
> >>
> >>> # REGISTER Message Handler
> >>> #
> >>>
> >>>
> >>--------------------------------------------------------------
> >>----------
> >>
> >>
> >>> if (!save("location")) {
> >>> sl_reply_error();
> >>> };
> >>>}
> >>>
> >>>onreply_route[1] {
> >>> xlog("L_NOTICE", "Reply status %rs: Reason %rr\n"); }
> >>>
> >>>failure_route[1] {
> >>> setflag(1);
> >>> xlog("L_NOTICE", "FAILURE LOGIC.\n");
> >>> revert_uri();
> >>> append_branch();
> >>> t_relay();
> >>>}
> >>>
> >>>Greg Martin
> >>>Technology & Operations
> >>>TELUS Communication Inc.
> >>>office: 780-493-2786
> >>>cell: 780-718-4139
> >>>
> >>>_______________________________________________
> >>>Serusers mailing list
> >>>serusers at lists.iptel.org
> >>>http://lists.iptel.org/mailman/listinfo/serusers
> >>>
> >>>
> >>>
> >>>
> >
> >_______________________________________________
> >Serusers mailing list
> >serusers at lists.iptel.org
> >http://lists.iptel.org/mailman/listinfo/serusers
> >
> >.
> >
> >
> >
>
More information about the sr-users
mailing list