[OpenSIPS-Devel] [opensips] B2BUA REFER scenario update (#196)

aisrx notifications at github.com
Wed Apr 9 23:37:28 CEST 2014


Currently the B2BUA REFER scenario follows this logic:
Accept the refer
Drop the transferor
Re-Invite the transferee
Invite the transfer target.
Send transfer target SDP to transferee.

A better flow would be this
Accept the refer
Invite the transfer target
If successful...
   Reinvite the transferee using SDP of transfer target
   Drop the trasnferor
end if

This would have 2 advantages:
1.  the re-invite to the transferee could be faster because call setup is already done.  This would reduce timeout issues when the transferee is waiting for an SDP while the INVITE to the transfer target is in progress.
2.  The original call would be preserved and maintained in the event the transfer fails as outlined in rfc 5589 (http://tools.ietf.org/html/rfc5589#section-6.3 ).

See email included below for a specific example:
Hello Tony,

That's definitely a good idea that must be considered - of course, such a change is not trivial, but I will open a TODO ticket on the GitHub tracker. Or if you have a github account, it will be wonderful if you could open the bug report.

Best regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 06.03.2014 21:04, Tony Ward wrote:
> Thanks for explaining this, Bogdan.
>
> I'm curious, though - would things work better if the late-SDP 
> negotiation were done the other way around i.e., since call3 is a new 
> call it could take longer for setup to occur, and during this time call1
> times out.   If we were to send the initial INVITE to call3, get the
> OK+SDP from call3, then invite+SDP  call1, perhaps it would respond 
> OK+more
> quickly since the call is already set up, and when it does we can send
> ACK+SDP to call3 to complete the transfer.   This may also provide the
> ability in the future to avoid disconnecting call1 leg to the IVR so 
> that it can be retained in the event call3 fails.
>
> Just a thought...
> Tony Ward
>
> -----Original Message-----
> From: Bogdan-Andrei Iancu [mailto:bogdan at opensips.org]
> Sent: Thursday, March 06, 2014 12:13 PM
> To: OpenSIPS users mailling list; Tony Ward
> Subject: Re: [OpenSIPS-Users] B2BUA REFER scenario
>
> Hello Tony,
>
> You may consider this a side effect of how the OpenSIPS B2BUA works. 
> As we want to be transparent from media point of view, OpenSIPS does 
> not get involved into SDP negotiation -> it is transparent, passing 
> the SDPs between the end points. This is mainly based on the late-SDP 
> negotiation
> - and combining this with normal SDP negation may lead into ACK delays.
>
> In this particular case the ACK for Call1 is delaied because the B2BU 
> is waiting for the 200 OK on Call3 - because the SDP from the 200 OK 
> in
> Call3 must be pushed in the ACK for Call1 (to allow direct SDP 
> negotiation between the end points involved in call1 and call3). So 
> the ACK for call1 will be delayed until Call3 gets answered - there is 
> no work around this at this point. In most of the cases the UA are a 
> bit flexible in waiting for ACK, like at least performing 200OK 
> retransmission (as per RFC3261). I would say your PSTN device is a bit 
> picky ;) when comes to firing the BYE in 6 sec (no retransmission, 
> short period of time).
>
> Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developer
> http://www.opensips-solutions.com
>
> On 05.03.2014 20:06, Tony Ward wrote:
>> Hello,
>> I currently have this configuration:
>> PSTN <====> SIP/ALG Router <====> OpenSips 1.10 <====> IVR OpenSips 
>> has a single IP on the private network.
>>
>> I have configured opensips using top hiding in the dialog module and
> it
>> works fine for calls to ptsn  and calls from pstn.
>> I have also configured opensips using B2BUA top hiding and it also
> works
>> fine for calls to ptsn  and calls from pstn.
>>
>> Now I want to test B2BUA REFER scenario (where calls from PSTN are 
>> answered by IVR, then IVR does a REFER to another PSTN number).
>>
>> When the IVR sends REFER the call is dropped after .6 seconds.  The
> flow
>> that I've seen in the trace is below:
>> PSTN			     opensips			IVR	
>> 	invite+SDP (Call1) ---->  |	
>> 	<----- Trying (Call1)	|
>> 			    	|	invite+SDP (Call2)----->
>> 			    	|	<----- OK+SDP (Call2)
>> 	<----- OK+SDP (Call1)   	|
>> 	Ack (Call1) ---->    	|
>> 			    	| 	ACK (Call2) 	----->
>>
>> 		<Ivr dialog take place here>
>>
>> 				|	<----- REFER (Call2)
>> 	<----- Invite (Call1)	|
>> 			    	|	Accepted (Call2) ----->
>> 			    	|	BYE (Call2) 	----->
>> 	Trying (Call1) ---->           |
>> 	OK+SDP (Call1) ---->       |
>> 	<----- Invite+SDP(Call3)|
>> 			    	|	<----- OK (Call2)
>> 	Trying (Call3) ----->  	|
>> 	OK+SDP (Call1) ----->  	|
>> 	OK+SDP (Call1) ----->  	|
>>
>> 		<0.6 seconds elapse here>
>>
>> 	Bye (Call1) ----->	|
>> 	<----- OK (Call1)   	|
>> 	<----- Cancel (Call3)   	|
>> 	OK (Call3) ----->	|
>> 	Req Termd (Call3) ----->|
>> 	<----- Ack (Call3)   	|
>>
>> It looks as though the PSTN times out waiting for an ACK after 
>> sending
>> OK+SDP(Call1) a couple times and then waiting .6 seconds.
>> The question is - what should the flow look like?  According to this
>> post:
> http://lists.opensips.org/pipermail/users/2012-April/021352.html,
>> things appear to be working as expected up to the point where we
> receive
>> Trying (Call3).  Should I be seeing the OK+SDP from call 3 next?
>> I'd like to troubleshoot further but I'm not sure where to look.
>>
>> Thanks!
>> Tony


 

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/196
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20140409/f3f65324/attachment.htm>


More information about the Devel mailing list