Filter
Top Products
162 Dialogic
®
Global Call IP Technology Guide — November 2007
Dialogic Corporation
IP-Specific Operations
There will always be at least one of these parameter elements if the re-INVITE request contains an
SDP offer (which is the typical case for re-INVITE requests).
Note: SDP does not explicitly communicate RTCP port addresses, but these can be inferred from RTP
addresses according to the “plus one” offset convention.
4.7.4 Responding to SIP re-INVITE Requests
This section focuses primarily on library behavior in 1PCC operating mode. In 3PCC, the
application is responsible for constructing the SDP answer.
After an application has received an unsolicited GCEV_REQ_MODIFY_CALL event that signals
reception of a re-INVITE request, and has retrieved and analyzed the parameter elements from the
GC_PARM_BLK associated with the METAEVENT, it is able to accept or reject the proposed
change by calling the appropriate Global Call API.
4.7.4.1 Rejecting a SIP re-INVITE Request
When an application determines that it is unable to or does not wish to accept the changes that were
proposed in a received re-INVITE request, it simply calls the gc_RejectModifyCall( ) function to
send a final response message with the specified 3xx–6xx reason code. The reason code to send is
specified using the appropriate IPEC_SIPReasonStatus… defines as defined in gcip_defs.h and
documented in Section 11.5, “Failure Response Codes When Using SIP”, on page 584.
When the remote user agent acknowledges the rejection response, the library generates a
GCEV_REJECT_MODIFY_CALL completion event to notify the application and the media
session continues unchanged, just as if a re-INVITE request had never been issued.
If the transmission of the rejection message fails for some reason, the library generates a
GCEV_REJECT_MODIFY_CALL_FAIL event. In the case of such a failure, the re-INVITE
transaction is still in progress, and the application should make another attempt to respond to the
request.
4.7.4.2 Accepting a SIP re-INVITE Request
When an application determines that the changes to the existing dialog or media session that were
proposed in a received re-INVITE request are acceptable, it calls the gc_AcceptModifyCall( )
function to send a 200 OK response. But because the SDP offer contained in a re-INVITE request
may contain more than one session proposal, the application has the opportunity to specify which
proposal it wishes to accept.
If the application calls gc_AcceptModifyCall( ) with a NULL pointer as the parmblkp parameter,
the library uses the codec preferences that were used in the original INVITE dialog to formulate the
SDP response. In this case, if the SDP offer in the re-INVITE proposed a codec that the application
did not indicate as acceptable in the original INVITE dialog, the library treats the situation as a
rejection of the call modification request. In this case, a 488 Not Acceptable Here response is sent
to the remote party to terminate the re-INVITE dialog, and a GCEV_REJECT_MODIFY_CALL
event is sent to the application.