Contents

Introduction

Prerequisites

Requirements

Verify

Troubleshoot

Introduction

This document describes how to configure enableDelayQuickReinvite to prevent the Application Server (AS) to send a re-INVITE too quickly after an ACK.

Prerequisites

- Basic Session Initiation Protocol (SIP) knowledge

- Basic AS knowledge

- Basic BW bwcli knowledge

Requirements

- Be able to use the AS bwcli and an admin user

- Be able to review the AS XSLogs

Run a get command to check the current values of both parameters.

By default enableDelayQuickReInvite is disabled (false) and the default value of delayQuickReInviteMilliseconds is 1000 (1000ms, or 1 second).

Part of the get command output is omitted to enhnace readability.

AS_CLI/Interface/SIP> get

...

enableDelayQuickReInvite = false

delayQuickReInviteMilliseconds = 1000

...

Configure the delayQuickReInviteMilliseconds parameter.

Accept the default value or use the one most suitable to your enivronment.

Use the lowest possible value. Start with the value of 100ms, and increase it enough to allow the problem to be solved.

AS_CLI/Interface/SIP> set delayQuickReInviteMilliseconds 100

...Done

After the value for delayQuickReInviteMilliseconds has been configured, enable enableDelayQuickReInvite.

AS_CLI/Interface/SIP> set enableDelayQuickReInvite true

...Done

Verify

When the configuration is finished, run the call scenario again to ascertain that the AS adds the delay between the ACK and the re-INVITE.

For example, if the AS has been configured to add 100ms, expect the delay to be at least 100ms or somewhat higher.

100ms are normally enough to prevent the ACK and re-INVITE to be received out of order.

The value is possibly higher, based on the network environment and the involved SIP entities in the signal path.

Troubleshoot

If the device still responds with a 500 error code, and the ACK and re-INVITE have been delivered in the correct order, further investigation is needed on the device.

Use the XSLogs on the AS to verify that the AS added the delay as configured.

Use a packet capture or the device logs to make sure that the delay was enough for the messages to be delivered in the correct order.

Note that this only works when the AS sends a re-INVITE just after it sent an ACK.

It does not work in case the AS receives an ACK and that causes the AS to send a re-INVITE.