Filter
Top Products
160 Dialogic
®
Global Call IP Technology Guide — November 2007
Dialogic Corporation
IP-Specific Operations
RFC3261 specifies that either party in a SIP dialog can initiate a re-INVITE transaction, so Global
Call applications must be able to receive and handle incoming re-INVITE requests whenever
application access to re-INVITE is enabled.
When the IP Call Control Library receives a re-INVITE request, the library first examines the
request to determine whether it specifies media properties that are acceptable by the local endpoint.
If the received re-INVITE request specifies media capabilities that are not supported by the local
system, the library automatically sends a 488 Not Acceptable Here response to the requesting party
and generates a GCEV_REQ_MODIFY_UNSUPPORTED event to the application. This
unsolicited event contains a CCLIB cause code of IPEC_SIPReasonStatus488NotAcceptableHere.
This event is sent for informational purposes only; the library has already sent the appropriate
response to the remote UA, so the local application does not need to take any action upon receiving
this informational event.
If the received re-INVITE request does not contain an SDP offer, or if it contains an SDP offer that
specifies media capabilities that are supported by the local media device, the call control library
automatically sends a 100 Trying response to the requester and generates an unsolicited
GCEV_REQ_MODIFY_CALL event to notify the application. The METAEVENT associated with
this event contains a pointer to a GC_PARM_BLK structure that the library has populated with the
following information from the re-INVITE request:
• a parameter element that indicates the DTMF mode
• parameter elements for any SIP header fields that the application has registered to receive (as
described in Section 4.9.4, “Registering SIP Header Fields to be Retrieved”, on page 180)
• one or more parameter elements that contain media session properties that were specified in
the received SDP offer (if there was one)
• a parameter element that contains the remote RTP transport address from the received SDP
offer (if there was one)
The DTMF mode specified in the re-INVITE may or may not match the properties of the current
session. It is the application’s responsibility to determine whether the DTMF mode is different
from the current mode, and to decide whether any change being proposed is acceptable. The DTMF
mode is contained in a parameter element of the type:
IPSET_DTMF
IPPARM_SUPPORT_DTMF_BITMASK
• value = IP_DTMF_TYPE_INBAND_RTP or IP_DTMF_TYPE_RFC_2833
The parameter elements associated with the Call-ID, To, and From headers will contain the same
values that were used in the original INVITE request that established the dialog. All other header
fields and parameters have potentially been changed, and it is the application’s responsibility to
parse and compare the values if appropriate. The header fields that the application has registered to
receive are reported in parameter elements of the following type:
IPSET_SIP_MSGINFO
IPPARM_SIP_HDR
• value = complete header string, including name, value, and any parameters
If the re-INVITE request contains an SDP offer, the media capabilities proposed in the offer may or
may not match the properties of the current media session. It is the application’s responsibility to
analyze the media properties proposed in the SDP offer, to determine whether the properties are