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