How to Forward re-INVITE Messages

Overview

SBC Core provides end-to-end support for SIP re-INVITE and UPDATE messages. SBC can be configured to relay (forward) re-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 re-INVITE messages with same or different SDP or without SDP. Additionally, the control flags are also available to suppress the relay of re-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 re-INVITE messages are:

• minimizeRelayingOfMediaChangesFromOtherCallLegAll: This existing flag suppresses re-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 rrrrrrre-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 re-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 re-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.