Suppressing Re-INVITEs for Call Hold/Resume Dialogs

You can configure the ESBC to suppress Re-INVITEs for Call Hold/Resume dialogs and REPLACES dialogs to reduce excess signaling traffic. From the perspective of the ESBC, a re-INVITE on one side of a session does not necessarily need to be forwarded to other side. When the ESBC receives a Re-INVITE that triggers, for example, a call hold, it can suppress that message from being sent out the egress and handle the transaction locally, between itself and the endstation that sent the re-INVITE.

Within an existing session, SIP allows for re-INVITEs when a station requests a change to dialog parameters, session parameters, or both. To configure this feature, you enable the suppress-hold-resume-reinvite on the applicable realm-config. The applicable realm depends on your design. You enable suppress-hold-resume-reinvite on:

• The ingress realm to suppress hold/resume INVITEs that come from the egress
• The egress realm to suppress hold/resume INVITEs that come from the ingress

In addition, if you enable suppress-hold-resume-reinvite on both the ingress and egress realms, the system does not suppress hold/resume re-INVITEs.

When enabled, the ESBC targets Re-INVITEs for this suppression feature when it receives a Re-INVITE within specific call flow scenarios:

• Call Hold re-INVITE—The ESBC recognizes a hold re-INVITE when it receives an INVITE that is within the existing dialog and includes the SDP media attribute set to inactive or sendonly, or when it receives an INVITE with a connection IP set to 0.0.0.0.

  When it receives a call hold Re-INVITE the ESBC:

  • Plays music on hold, assuming you have configured the tone to be played by the ESBC during hold.

    Note:

    This feature does not require MOH.
  • Suppresses this INVITE
  • Responds locally to the station that sent the hold with a 200 OK

  The ESBC does not suppress these re-INVITEs when it finds the SDP media attribute set to recvonly. Furthermore, the ESBC continues to forward any subsequent re-INVITEs, disabling this re-INVITE suppression feature, after forwarding a recvonly INVITE until the call returns to sendrecv mode. Having returned to sendrecv, the ESBC begins to enforce its re-INVITE suppression feature again.

• Call Resume re-INVITE—The ESBC recognizes a resume re-INVITE when it receives an INVITE after a call hold re-INVITE that is within the existing dialog. In addition, this re-INVITE must include an SDP media attribute set to sendrecv and the connection IP set to the original IP.

  When it receives a resume Re-INVITE the ESBC:

  • Stops MOH
  • Suppresses this INVITE
  • Responds locally to the station that sent the resume with a 200 OK
  • Resumes media support
• re-INVITE with codec change—This scenario can occur when an end-station simply changes codecs. In addition, each of the scenarios above may include a codec change whether or not the ensuing signaling results in transcoding.
• re-INVITE with Replaces header—The ESBC suppresses a Re-INVITE that includes the REPLACES header. This scenario is a hold/resume scenario that includes moving the dialog to a different end station.
  When receiving an INVITE with a replaces header, the ESBC:

  1. Suppresses this re-INVITE from forwarding out the egress
  2. Replies to the sender with a 200 OK
  3. Supports the new media
  4. Sends a BYE to the original station
• Offerless Re-INVITE—When you configure this feature, the ESBC does not forward an offerless re-INVITEs out the egress interface.

Related Configuration

Related configuration considerations include:

• For deployments that need to support dialog replacement, this feature requires that you apply a sip-profile with the replace-dialogs parameter enabled to the sip-interface.
• This feature takes precedence over the suppress-reinvite option available on a sip-interface.
• If you configure a session-timer-profile on an applicable sip-interface, the system generates Re-INVITEs or UPDATEs based on force-reinvite parameter.
• This feature does not work in conjunction with TrFO configurations.

Consider the following functional limitations when deploying this feature:

• This feature does not work within REFER scenarios.
• This feature does not perform INVITE suppression on re-INVITEs and replace INVITEs when they contain multiple m-lines.
• If a call is on hold with music on hold playing, an HA switchover causes the MOH to stop.