[OpenSIPS-Users] B2BUA REFER scenario

[Bogdan-Andrei Iancu]

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
>
>