[Devel] Reconsideration/Dialog - RE:[ openser-Bugs-1534126 ] Strange behaviour regarding sl_send_reply and failure_route

[Tavis P]

SourceForge.net wrote:
> Bugs item #1534126, was opened at 2006-08-03 23:50
> Message generated for change (Comment added) made by bogdan_iancu
> You can respond by visiting: 
> https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1534126&group_id=139143
>
> Please note that this message will contain a full copy of the comment thread,
> including the initial issue submission, for this request,
> not just the latest update.
> Category: core
> Group: ver 1.0.x
>   
>> Status: Closed
>> Resolution: Invalid
>>     
> Priority: 5
> Submitted By: reticent (unspin)
>   
>> Assigned to: Bogdan (bogdan_iancu)
>>     
> Summary: Strange behaviour regarding sl_send_reply and failure_route
>
> Initial Comment:
> I'm encountering an issue using sl_send_reply in a
> route referenced from route
>
> failure_route snippet
> ---
>     if ( t_check_status("486") )
>     {
>         route(15);
>         drop();
>     }
> ---
>
> Inside which i call another route() block
> ---
> route[15]
> {
>     sl_send_reply("404", "Well i tried, but they're
> nowhere to be found");
> }
> ---
>
> After returning to the failure_route drop() is executed
>
> What i'm seeing is that both the message i'm generating
> with
> sl_send_reply and the "486 Busy" are being sent on to
> the client.  I was expecting the message created by
> sl_send_reply to be sent and the original message to be
> dropped
>
>
> I've attached a really simple configuration that will
> reproduce this issue.
>
> This config is designed to handle incoming
> registrations (so that you
> can register a phone and then leave it off hook so that
> it will respond
> "486" to any incoming INVITE) and store the location
> information in
> memory. 
> It will the handle incoming INVITE and execute a
> lookup("location"); so
> that the call may be routed to a registered user. 
> A failure route is defined that looks for a status of
> 486, upon finding
> this it will execute route(15) which simply calls
> sl_send_reply and then
> returns, at this point a drop() will be executed and
> you will see both
> the result of the sl_send_reply sent to the client AND
> the "486 Busy".
>
> This was found on an OpenSER 1.0 cvs checkout about 2
> weeks ago
>
> tavis
>
> ----------------------------------------------------------------------
>
>   
>> Comment By: Bogdan (bogdan_iancu)
>>     
> Date: 2006-08-04 10:26
>
> Message:
> Logged In: YES 
> user_id=1275325
>
> it's not a bug - the problem is the mixing of stateful and
> stateless processing.
> First of all you cannot drop a final reply in failure route
> - drop will be equivalent to exit in this case; the
> transaction engine has to close a transaction by sending a
> *stateful* final reply; what you can do is the explicitly
> send a different one from the script (via t_reply).
> Second is the mixing of stateful (via failure route) and
> stateless (via sl_send_reply) - the transaction engine is
> not aware of any of the stateless replies you send from the
> script, so it will send a stateful reply also.
>
> So it's a script error.
>
> Regards,
> Bogdan
>
> ----------------------------------------------------------------------
>
> You can respond by visiting: 
> https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1534126&group_id=139143
>
> _______________________________________________
> Devel mailing list
> Devel at openser.org
> http://openser.org/cgi-bin/mailman/listinfo/devel
>
>
>   


It could be seen as a script error, however first let me explain what
i'm trying to do

I'm using failure_route to trigger call forwarding logic (busy or
unavailable), to do this i execute a route() statement which in turn
executes several other route() statements to gather the necessary
information (call destination, authorization, additional call forwarding
(if destination is another subscriber account) and finally routing the call.

I came across this problem when it was determined by my script logic
that the forwarded number wasn't available and as such i desired to send
a "404 Not Found" reply in response

Perhaps this situation exposes what i found to be a very ideal
possibility created by the addition of branch_route functionality, and
that is:  Rather than forwarding the message back to myself over IP, i
can simply call the necessary script logic from within the failure_route
(or branch_route) which makes the situation much less complicated and
more efficient (but does introduce many issues, most of which can be
worked around)

This was a very attractive possibility (as i was previously forwarding
calls back to the server over IP when call forwarding rules were
triggered) however i'm not sure if this approach is recommended by the
developers of OpenSER


I would just like to express how useful this logic has been to me (the
ability to execute most of the main script logic from within
failure_route or branch_route) in allowing me to facilitate my
requirements with openser and to open dialog regarding any issues that i
may experience with this logic.


I've already got a script that i've been working on for a few monthes
that incorporates all this functionality and the only problem that i've
come across (aside from the one mentioned in the bug ticket, which is
not really an issue but i thought it was could be interesting to bring
up) is sporadic segmentation faults when using add_rr_param() inside
route blocks that are called from failure_route (after revert_uri has
been called).


thanks

tavis