[OpenSER-Devel] [ openser-Patches-1495434 ] New OpenSER function: t_add_final_response

[SourceForge.net]

Patches item #1495434, was opened at 2006-05-26 10:26
Message generated for change (Comment added) made by henningw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743022&aid=1495434&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: modules
Group: ver devel
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Bogdan (bogdan_iancu)
Assigned to: Nobody/Anonymous (nobody)
Summary: New OpenSER function: t_add_final_response

Initial Comment:
We've encountered a problem with the current branch
handling. Suppose the 
following setup:

Phones A, X, Y all in the same net, connected to
OpenSER. Phones X and Y are 
both registered with the same number. Additionally
phone X has a redirection 
to some other phone.

Phone A calls the number of phone X. OpenSER branches
and the INVITE is sent 
to both X and Y.

Phone Y is ringing and Phone X sends 302 to OpenSER.
Here's the problem: the 
302 is held while Y still rings. A gets bored and hangs
up, which releases 
the 302: it is sent to the hung up phone A.

In behalf of Marc Haisenko <haisenko at comdasys.com>

What we want to happen instead is to consider 302 to be
a final response in 
this case and immediately forward it to A, and cancel Y.

First I've hardcoded this as I needed to understand
what's happening, how the 
branching works and generally where I need OpenSER to
kick  ;-)  After I've 
found out I thought about implementing this in a more
clean way as we'll 
probably need to handle other responses the same way.

My current solution looks like this: I've added new
function 
t_add_final_response("123") for reply routes which adds
123 to the list of 
response codes that should be considered final. The
patch I've attached 
allows you to specify up to 8 such responses, definable
through config.h.

It works as expected, but before I finalize and submit
the patch I'd like some 
feedback from you, especially on where to put methods
and whether the 
approach I've used is good or whether you know a better
way.

Thanks a lot,
	Marc

----------------------------------------------------------------------

>Comment By: Henning Westerholt (henningw)
Date: 2007-09-27 07:45

Message:
Logged In: YES 
user_id=337916
Originator: NO

This patch is rather old, is it still needed? 

Cheers,

Henning

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743022&aid=1495434&group_id=139143