[OpenSIPS-Users] B2BUA REFER scenario

[Tony Ward]

Thanks Bogdan, I set up an account and opened a ticket as you requested.
Let me know if you need any other info.

Tony Ward

-----Original Message-----
From: Bogdan-Andrei Iancu [mailto:bogdan at opensips.org] 
Sent: Friday, March 07, 2014 5:12 AM
To: OpenSIPS users mailling list; Tony Ward
Subject: Re: [OpenSIPS-Users] B2BUA REFER scenario

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
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>