SIPREC Re-INVITE Collision and Back-off Support

The Oracle SBC acts a back-to-back User Agent (B2BUA) in all call scenarios. With SIPREC, the Oracle SBC acts as a User Agent Client (UAC) when connected with a Session Recording Server (SRS). Therefore, SIP requests can originate from the Oracle SBC.

When the SRS establishes a recording dialog during a recording session, the  Oracle SBC and the SRS may send Re-INVITES to each other with updated information. When the Oracle SBC receives an INVITE, while it is still waiting for the response to a previous INVITE it sent out, this produces an INVITE collision.

To avoid an INVITE collision, the Oracle SBC sends a 491 Request Pending response back to the SRS and then waits for a random amount of time before re-trying the INVITE. The SBC also acknowledges (ACK) any 491 response received from the other side. RFC 3261 and RFC 6141 describe the way the User Agent (UA) resolves the INVITE collision. The random wait time is chosen based on the following guidelines from RFC 3261:

If the UAC is the owner of the Call-ID of the dialog ID (it generated the value), T (the wait time) is a randomly chosen value between 2.1 and 4 seconds in units of 10 milliseconds.
If the UAC is not the owner of the Call-ID of the dialog ID (it did not generate the value), T (the wait time) is a randomly chosen value between 0 and 2 seconds in units of 10 milliseconds.

The following call flow diagram shows the Oracle SBC’s feature to avoid INVITE collision.

This illustration shows a ladder diagram in which the SBC and the Session Recording Server exchange invites. The SBC sends a 491 Request Pending response to the SRS, while waitng for a response. The diagram shows where in the invite exchange the SBC waits a random amounti of time before re-sending the Invite.