Hi Louis,
There is actually no issue here - when you move the call to the backup
destination, opensips fires first a re-INVITE with no SDP to the caller
(in order to get its SDP in 200 OK). Then opensips sends a new call to
the new destination and waits for the 200 OK from it, it order to take
the SDP from it and pushed it on the caller side as ACK + SDP.
The b2bua does this trick with late negotiation in order to avoid to
inter-pose itself in SDPs and to allow direct exchange of SDPs between
the end points.
Shortly, there is not ACK to caller because there is no 200 OK from the
new callee.
Regards,
Bogdan
On 04/02/2012 05:48 PM, LRochon wrote:
We are having a problem where we believe that OpenSIPS B2BUA is failing to
send an ACK to a 200 ok message. Everything else works great, but we have
tried alot of different things to get around this issue, with no good
results.
We are using OpenSIPS 1.7.2 8878
Phone A 172.16.6.254 (number 1001)
Phone B 192.168.130.103 (Number 8195553185, this is actually a SIP gateway,
but from the point of view of OpenSIPS, it might has well be a phone)
Phone C 172.16.1.83 (number 5555)
OpenSIPS 192.168.130.105
Under normal operation, Phone A calls Phone B via OpenSIPS B2BUA.
If phone B fails or goes off-air for whatever reason, two things need to
happen: 1, new calls must be redirected to phone C, and 2, any calls that
are
currently progress between Phone A and Phone B must be redirected so that
Phone A talks to Phone C.
It's part 2 we are having a problem with. We have a job that does a SIP keep
alive towards Phone B. If Phone B fails, we do two things:
1. Launch command "opensipsctl fifo b2b_list"
That results in:
tuple:: 0 key=328.0 scenario_state=1 lifetime=106223 db_flag=2
scenario=FailOver next_scenario_state=1
servers:: 0 scenario_id=Server1 key=B2B.311.172 disconnected=0
state=1 no=0 type=0 peer=B2B.330.7393716
to_uri:: sip:8195553185@192.168.130.105
from_uri:: sip:1001@192.168.130.105
clients:: 0 scenario_id=phone1 key=B2B.330.7393716 disconnected=0
state=1 no=1 type=1 peer=B2B.311.172
to_uri:: sip:8195553185@192.168.130.103
from_uri:: sip:1001@192.168.130.105
bridge_entities:: 0 scenario_id=Server1 key=B2B.311.172
disconnected=0 state=1 no=0 type=0 peer=B2B.330.7393716
to_uri:: sip:8195553185@192.168.130.105
from_uri:: sip:1001@192.168.130.105
bridge_entities:: 1 scenario_id=phone1 key=B2B.330.7393716
disconnected=0 state=1 no=1 type=1 peer=B2B.311.172
to_uri:: sip:8195553185@192.168.130.103
from_uri:: sip:1001@192.168.130.105
2. We extract the key (328.0 in this case)
and then launch command:
opensipsctl fifo b2b_bridge 328.0 sip:5555@172.16.1.83 0
PhoneA OpenSIPS PhoneB
PhoneC
----Invite---------->
<---Trying----------
-----Invite------>
<----Trying-------
<--183 Progress---
<---183 Progress----
<---200 OK--------
<---200 OK----------
-----ACK ---------->
------ACK-------->
Here, PhoneA talks to PhoneB.
Simulate failure of phone B, so we do
"opensipsctl fifo b2b_list" and "opensipsctl fifo b2b_bridge 328.0
sip:5555@172.16.1.83 0"
Call flow continues:
-------BYE------->
<--Invite (no SDP)--
<--200 OK (no SDP)-
---200 OK --------->
-------------Invite-------------->
<------------Trying---------------
<---------180 Ringing-------------
---200 OK---------->
<-Missing ACK!!!----
---200 OK---------->
---200 OK---------->
---BYE------------->
<----200 OK---------
--------Cancel------------------->
<-----487 Request Cancel----------
---------ACK--------------------->
<-----------200 OK----------------
--
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
