Page History

Overview

SBC Core provides end-to-end support for SIP Rere-INVITE and UPDATE messages. SBC can be configured to relay (forward) Rere-INVITE messages received from one leg (with or without Session Description Protocol (SDP)) to the other leg. Similarly, SBC can be configured to relay the UPDATE message received from one leg to another leg, and also forwards the confirmed dialog with the UPDATE message to other leg.

End-To-End

re-INVITE

When endToEndReInvite flag is enabled, SBC relays Rere-INVITE messages with same or different SDP or without SDP. Additionally, the control flags are also available to suppress the relay of Rere-INVITE messages from one leg to the other leg. In such cases, endToEndReInvite flag takes precedence over the control flags in passing messages to the other leg.

The control flags suppressing the Rere-INVITE messages are:

• minimizeRelayingOfMediaChangesFromOtherCallLegAll: This existing flag suppresses Rere-INVITE messages when the new offer contains common codec list (comprising the list previously offered to the egress peer and the last received list from the egress peer).
• lockDownPreferredCodec: This flag locks down the last negotiated codec. If this flag is present in the new offer, the received Rere-INVITE is internally answered with that codec.

Session Refresh

re-INVITE

Currently, SBC handles session refresh on a per-leg basis. As a back-to-back user agent (B2BUA) entity, SBC handles the session timer at each leg independently. If SBC takes the refresher role for the leg towards the Application Server, it generates the keep-alive Rere-INVITEs towards the Application Server.

Session timers support is handled at the SIP stack layer and the application layer may not be always involved. Currently, if the refresh Rere-INVITEs are challenged, the call fails and ends.

End-To- End UPDATE

When endToEndUpdate flag is enabled, SBC forwards the UPDATE message with same or different SDP from the SDP received earlier to other leg.