Dialogic IP Phone 05-2239-009 User Manual

162

Dialogic Corporation

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).

SDP does not explicitly communicate RTCP port addresses, but these can be inferred from RTP 
addresses according to the “plus one” offset convention. 

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.

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 

 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 

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. 

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 

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.