RFC 3261 specifies that User Agents must be able to send and respond to additional INVITE
requests after a dialog has been established to allow modification of the dialog or the media
session. These subsequent INVITE requests in an existing dialog are known as re-INVITE requests
to distinguish them from an initial INVITE request that initiates a new dialog. Re-INVITE requests
contain the same Call-ID and To and From tags as the original INVITE request that established the
dialog. Either party in a dialog can issue a re-INVITE, and only one re-INVITE can be pending at
any given time.

The re-INVITE method is a general purpose mechanism that potentially can be used to modify or
update nearly any property of a dialog (notably excluding the header fields that are used to identify
the message as a subsequent INVITE rather than a new INVITE) or the associated media session.
But it is important to note that different IP telephony platforms support re-INVITE requests to
varying degrees. For example, some platforms may only support changing the RTP address while
others may also support changing the direction(s) of media streaming or even the codec
characteristics. Each endpoint has to determine whether it supports the changes requested in a re-
INVITE, and whether it wishes to accept requests that it supports. An endpoint must reject any re-
INVITE request that it does not support, and may optionally reject any re-INVITE request for any
reason whatsoever.

In first party call control mode (1PCC), the Dialogic

Global Call API library for Dialogic

Host

Media Processing Software supports the following capabilities for re-INVITE, which are described
in detail in the subsections of this section:

•

specifying, changing, or refreshing header field values or parameters for the existing dialog;
for example, refreshing expiring Contact information

•

changing the DTMF mode

•

changing the direction of the streaming; for example, changing from half-duplex to full-duplex
streaming

•

suspending and resuming streaming to implement hold and retrieve functionality

•

changing the RTP port of the remote endpoint

Note: Global Call does not provide a mechanism for initiating an RTP port change, but

Global Call applications can receive and act on port change requests received from
non-Global Call applications.

•

changing coder properties of the media session; for example, changing from a low bit-rate
coder to reduce resource requirements