Suppress-reinvite Not Suppressing Re-INVITEs

Asset ID:	1-71-1994020.1
Update Date:	2017-04-24
Keywords:

Solution Type Technical Instruction Sure

Solution 1994020.1 : Suppress-reinvite Not Suppressing Re-INVITEs

Applies to:

Acme Packet 4500 - Version S-Cx6.3.0 and later
Acme Packet 3820 - Version S-Cx6.3.0 and later
Acme Packet 6300 - Version S-Cz7.1.2 and later
Acme Packet 6100 - Version S-Cz7.1.2 and later
Information in this document applies to any platform.

Goal

Customer wants to suppress re-INVITE from IVR on core side of the network and allow the SBC to respond locally and not forward this re-INVITE. The fact that the first re-INVITE is forwarded by the SBC surprises some customers. This document details why this first re-INVITE is forwarded by the SBC.

Solution

The documentation regarding this feature requires enhancement.
Using a call flow similar to that seen below (with suppress-reinvite option enabled on core sip-interface):
UAC --> SBC(access) | SBC (core) --> UAS

Many customers configure this option on the core side of networks to suppress multiple re-INVITEs from IVR systems. Assuming this type of call flow (call to IVR) for this document, the notes below apply.

When this option is enabled on the core sip-interface, the SBC will forward the first INVITE received from the called party or UAS. This first INVITE from the called party is not suppressed, but is stored along with the 200-OK response instead.

Per the documentation in the ACLI Configuration Guide, you can configure the suppress-reinvite option on your Net-Net SBC, allowing it to store the previous INVITE and its 200-OK response. Having this information allows the system to reply locally when a re-INVITE that changes only the media transport addresses is recieved. As this is the first INVITE received from this direction and the first 200-OK response sent in this direction, the INVITE is forwarded (but stored for later reference).
If a subsequent INVITE is received and matches the previous INVITE received (and stored), the SBC will suppress or not forward this INVITE to the other party.
If the SDP is modified within any of the re-INVITE requests, the INVITE will be forwarded and not suppressed.

Example configuration on the core sip-interface - Please remember to prefix the option with a + character, so as not to lose additional options that may already be configured.

ACMEPACKET(sip-interface)# options +suppress-reinvite

sip-interface
        state                          enabled
        realm-id                       core
        description
        sip-port
                address                        1.20.14.10
                port                           5060
                transport-protocol             UDP
                tls-profile
                multi-home-addrs
                allow-anonymous                all
                ims-aka-profile
        <...>
        uri-fqdn-domain
        options                        suppress-reinvite

A working call flow may look like:

UAC --> SBC(access) | SBC (core) --> UAS

UAC <-- SBC(access) - re-INVITE forwarded | SBC (core) <-- UAS -re-INVITE sent and 200-OK response forwarded from UAC to UAS

re-INVITE not forwarded SBC(access) | SBC (core) <-- UAS -next re-INVITE(s) sent with no SDP change and 200-OK response sent locally from SBC, not from UAC

Attachments

This solution has no attachment