Implementation Details

This section describes the details of how the Oracle® Enterprise Session Border Controller behaves in SIP REFER scenarios with the changes made in Oracle® Enterprise Session Border Controller Release S-C(X)6.1.0M2. The Oracle® Enterprise Session Border Controller makes the new call between Party A and Party C appear as though A were participating to allow the Oracle® Enterprise Session Border Controller’s natural media setup occur in the same way as if the REFER had actually been sent to A and A had sent a new INVITE.

When the Oracle® Enterprise Session Border Controller receives a REFER request and determines it needs to handle it locally, it creates a new INVITE made to look like one from Party A. And the Oracle® Enterprise Session Border Controller actually processes this INVITE as though it were from Party A. As a result, new SIP and new media sessions are created with new media ports for Parties A and C. When the INVITE to Party C receives a final response, the Oracle® Enterprise Session Border Controller sends the result to Party B using a SIP NOTIFY request.

If the new INVITE succeeds, the old context and flows disappear and the new context and flows for the A-to-C connection remain in place. Because of the new media ports, the Oracle® Enterprise Session Border Controller sends a re-INVITE to Party A, directing media to the new port and forwarded to Party C. Next, the original dialog with Party B needs to be terminated; if the Oracle® Enterprise Session Border Controller has not received Party B’s BYE, it will wait five second and then send Party B a BYE.

If the INVITE to Party C fails, the new SIP and media sessions are deleted as are the new context and flows. The Oracle® Enterprise Session Border Controller treats Party A differently depending on whether or not a BYE was received from Party B. If a BYE was received from Party B. then the Oracle® Enterprise Session Border Controller sends a BYE to Party A. If not, the original SIP and media sessions as well as the context and media flows remain in tact. This way, Party B can re-establish the call with Party A using a re-INVITE. In the case, the Oracle® Enterprise Session Border Controller waits 32 second before sending a BYE.

If the Oracle® Enterprise Session Border Controller receives a BYE while processing the INVITE to Party C, it sends a CANCEL message to Party C in an attempt to cancel the call. The BYE passes to Party B, and associated sessions, contexts, and flows terminate normally. Still, the Oracle® Enterprise Session Border Controller waits for the final response to the INVITE to Party C. If the Oracle® Enterprise Session Border Controller receives a successful response, it sends an ACK and then a BYE to terminate the abandoned call. If the Oracle® Enterprise Session Border Controller receives an unsuccessful final response, it uses its normal response error handling processes. In either of these last two cases, all sessions, context, and flow are deleted.

Please note that the Oracle® Enterprise Session Border Controller does not remove the a=sendonly attribute from the SDP it sends to Party A during the A-to-B call, and extra media ports are not allocated for the original media session.