[Devel] Re: New OpenSER function: t_add_final_response

Bogdan-Andrei Iancu bogdan at voice-system.ro
Fri May 26 12:28:59 CEST 2006


Hi Marc,

sorry for delay, but I had no spare time to review your patch and to 
include it in the next release.
I will take care of it as soon as the release is out. In the mean while 
I uploaded the patch on the tracker not to forget about it.

Thanks and regards,
Bogdan

Marc Haisenko wrote:

>Hi Bogdan,
>I thought I'd discuss with you directly before posting a patch on the list.
>
>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.
>
>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
>  
>




More information about the Devel mailing list