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.
- Plays music on hold, assuming you have configured the tone to
be played by the ESBC during hold.
- 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:
- Suppresses this re-INVITE from forwarding out the egress
- Replies to the sender with a 200 OK
- Supports the new media
- 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.