A-party is unable to hear B-party after bridge operation

Document ID:KM00867740
Creation Date:23-Apr-2014
Modified Date:23-Apr-2014
- Micro Focus Products:
  ocmp

Summary

On OCMP, there could be an issue here A-party is unable to hear B-party after bridge operation is done, however B-party able to hear A-party just fine. This problem happens due to A-party call leg is still connected full duplex to a VXML dialog and join occurs before the leg is released.

Question

OCMP: OpenCall Media Platform
IVR: Interactive Voice Responder
XML: eXtensible Markup Language
CCXML: Call Control XML
VXML: Voice XML

On HP OCMP platform with below scenario, there could be an issue here A-party is unable to hear B-party after bridge operation is done, however B-party able to hear A-party just fine:

1. A-party dial in to IVR consist of OCMP and CCXML/VXML application
2. IVR application creates a VXML dialog (i.e. hold music)
3. IVR perform a "creatcall" CCXML tag to B-party
4. When B-party answers the call, A-pary and B-party gets connected in full duplex mode.

Notes: No CCXML, VXML errors are visible and same application works fine in OCMP 3.2 version

Answer

This problem happens due to A-party call leg is still connected full duplex to a VXML dialog and join occurs before the leg is released.

Example of Call Detailed Record (CDR) analysis:

1. A-party calls OCMP (callleg_85680_86383)
<incomingcallinitiated callid="xxx@ocmp1"
from="sip:yyy@10.210.1.49" msec="0" to="sip:zzz@10.210.1.17;user=phone"/>

2. Dialog prepare, start, started (callleg_85680_86383 connected to dialog vxi_dialog_104_234_89521)
   <dialogprepare audioendpoint="callleg_85680_86383"
    dialogid="vxi_dialog_104_234_89521"
   <event id="vxi_dialog_104_234_89521" msec="72" name="dialog.prepared">
   <event id="callleg_85680_86383" msec="119" name="connection.connected">
   <dialogstart audioendpoint="callleg_85680_86383"
    dialogid="vxi_dialog_104_234_89521" direction="both"/>
   <event id="vxi_dialog_104_234_89521" msec="119" name="dialog.started"/>

3. Dialog exit (vxi_dialog_104_234_89521)
<event msec="14311" name="dialog.exit">

4. Another Dialog start, started and createcall to B-party (callleg_85680_86383 connected to dialog vxi_dialog_104_234_89553)
   <dialogstart audioendpoint="callleg_85680_86383"
    dialogid="vxi_dialog_104_234_89553" direction="both"
    src=http://10.62.229.138:8080/hold.vxml type="application/voicexml+xml"/>
   <createcall callerid="sip:aaa@10.210.7.21"
    connectionid="callleg_85709_86413" dest="sip:bbb@10.210.1.49" timeout="50000ms"/>
   <event id="vxi_dialog_104_234_89553" msec="14348" name="dialog.started"/>

5. B-party connected, dialogterminate and join A-party to B-party
   <event id="callleg_85709_86413" msec="30518" name="connection.connected">
      <transition state="placingCall">
         <dialogterminate dialogid="vxi_dialog_104_234_89553" immediate="false"/>
         <join duplex="full" id1="callleg_85680_86383" id2="callleg_85709_86413"/>
      </transition>
   </event>

6. Join happens between callleg_85680_86383 and callleg_85709_86413, however callleg_85680_86383 still connected to vxi_dialog_104_234_89553
<event id1="callleg_85680_86383" id2="callleg_85709_86413" msec="30518" name="conference.joined"/>

7. Dialog exit (vxi_dialog_104_234_89553)
<event msec="30548" name="dialog.exit"/>

Problem happens on sequence #6, as the A-party call leg is still connected (both direction) to dialog vxi_dialog_104_234_89553, and join occurs before the call leg is released.

Resolution:
<join> needs to wait till dialog.exit event occurs i.e. perform join *after*/*inside* dialog.exit event

While why it works on OCMP 3.2 version is very likely caused by the operation of dialog.exit happens before join.