Dialogic Dialogic Global Call IP IP Phone User Manual


 
Dialogic
®
Global Call IP Technology Guide — November 2007 397
Dialogic Corporation
accept proposed modification of call characteristics — gc_AcceptModifyCall( )
The function returns either <0 (to indicate failure) or 0 depending only upon the validity of the
parameters. The function return does not indicate any status as to the success or failure of the
sending of the response message. The final result of the attempt to send the response is provided in
termination events.
First Party Call Control (1PCC) Mode
When an application receives a GCEV_REQ_MODIFY_CALL event, it must retrieve the
parameter elements from the associated metaevent and analyze them to determine whether the
proposed changes are acceptable before it calls gc_AcceptModifyCall( ).
In cases where one or more media sessions are present in an SDP offer within the re-INVITE, those
session proposals that are supported by the given media platform are indicated as Global Call
parameter elements associated with the GCEV_REQ_MODIFY_CALL event. Each proposed
media type is indicated by a separate parameter within the parameter block using the following:
GCSET_CHAN_CAPABILITY
IPPARM_LOCAL_CAPABILITY
value = IP_CAPABILITY structure
For a symmetrical, full-duplex media proposal, at least two such parameters—one for transmit and
one for receive—are forwarded in the parameter block. For a half-duplex proposal or for an on-
hold request, there may be only a single parameter element with the given set of session attributes.
In addition to being informed of the media session proposals, the application is also informed of the
remote RTP transport addresses. Each RTP port that is proposed in an SDP offer received within a
re-INVITE (one per “m=” line) is indicated as a separate parameter within the parameter block
associated with the GCEV_REQ_MODIFY_CALL event. These remote RTP address parameters
are identified as follows:
IPSET_RTP_ADDRESS
IPPARM_REMOTE
value = RTP_ADDR structure
Because SDP does not communicate RTCP ports, only RTP ports are exchanged; the RTCP port
will have the typical “plus one” offset from the RTP port.
To accept the changes to the dialog and media session exactly as proposed, the application calls
gc_AcceptModifyCall( ) with a NULL pointer as parmblkp.
An application can also formulate a specific SDP answer by inserting appropriate media session
parameter elements (GCSET_CHAN_CAPABILITY / IPPARM_LOCAL_CAPABILITY) into the
GC_PARM_BLK parameter block that it references in the gc_AcceptModifyCall( ) function call.
A full-duplex connection requires two such parameter elements, one for each direction. A half-
duplex connection requires one parameter element with the direction field of the IP_CAPABILITY
structure set appropriately. Accepting an on-hold request requires a single parameter with the
proposed codec capability and one of the direction values that specifies inactive streaming.
If the capabilities to be used in the SDP answer—whether specified by the application or derived
from the initial INVITE—do not match the capabilities that were contained in the SDP offer (both
codec capability and direction), the library treats the situation as a rejection of the call modification