Last updated on OCTOBER 10, 2016
Applies to:Oracle Communications Service Broker - Version 3.1.1 to 3.1.1 [Release 3.1.0]
Information in this document applies to any platform.
In multiple call-leg application scenario triggered from CAP4, OCSB 3.1.1 is behaving inconsistently.
After the call is successfully set up, OCSB immediately decides to disconnect the call.
Scenario is the following:
- InitialDP is sent, and INVITE for incoming leg sent to AS (Application Server)
- 8 Invites, translated to ICA (InitiateCallAttempt), got ICARes, sent RRBCSM (RequestReportBCSMEventArg) on ICA leg and CWA (ContinueWithArgument)
- 8 outgoing legs send eventTypeBCSM oTermSeized
- Leg7 send EventReportBCSM of Oanswer, IMSCF send OK to AS, CWA to network
- AS cancel all other 7 legs
- IMSCF send 7 disconnectLeg to network
- AS send OK to first leg with sdp of leg7 in order to connect them
- IMSCF start the moveLeg operation of moving leg7 to CS1, first stage of this operation is disconnectLeg2 (dummyleg "leg2") in order to be able to perform moveLeg operation.
- disconnectLegResult of one of the other 7 legs is coming from network and by mistake translated in IMSCF sib to part of the moveLeg operation, this cause ContinueWithArgument to CS1 and this is forbidden before RRBCSM.
- DisconnectLegResult of leg2 is coming, IMSCF want to finish the moveLeg operation and send RRBCSM for leg1 + moveLeg to network, this RRBCSM got error because of the previous CWA on CS1.
Sign In with your My Oracle Support account
Don't have a My Oracle Support account? Click to get started
Million Knowledge Articles and hundreds of Community platforms