SIPREC Re-INVITE Collision and Back-off Support

The Oracle SBC acts a back-to-back User Agent (B2BUA) in all call scenarios. However 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.

During a recording session, when the SRS establishes a recording dialog, 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 now sends a 491 Request Pending response back to the SRS and then waits for a random amount of time before re-trying the INVITE. It also acknowledges (ACK) any 491 response received from the other side. RFC 3261 and RFC 6141 describes 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 (i.e., 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 (i.e., 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.