Filter
Top Products
Dialogic
®
Global Call IP Technology Guide — November 2007 163
Dialogic Corporation
IP-Specific Operations
To formulate a specific SDP answer, an application inserts appropriate media capability parameter
elements into the GC_PARM_BLK parameter block that it passes to gc_AcceptModifyCall( ).
Each parameter element is of the following format:
GCSET_CHAN_CAPABILITY
IPPARM_LOCAL_CAPABILITY
• value = IP_CAPABILITY data structure
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.
To accept an on-hold request, the application must insert a parameter element with an
IP_CAPABILITY structure that contains one of the direction values that specifies inactive
streaming. If the application does not specify a capability that matches a proposed capability in the
re-INVITE’s SDP offer, the library treats the situation as a rejection of the modification request,
sends a 488 Not Acceptable Here response to the remote party to terminate the re-INVITE dialog,
and generates a GCEV_REJECT_MODIFY_CALL to the application.
If the re-INVITE request specifies a change in the codec, the library makes the change effective on
the local media platform as soon as the gc_AcceptModifyCall( ) function is called. All further
packets sent by the local media platform will use the new codec, and only packets using the new
codec will be accepted from the remote endpoint. This may cause some audible artifact, such as a
click or a brief silence, if the remote endpoint is not able to synchronize codecs promptly.
When the remote UA acknowledges the 200 OK response, the library generates a
GCEV_ACCEPT_MODIFY_CALL event to notify the application that the re-invite transaction
has completed successfully. If the transmission of the 200 OK message fails for some reason, the
library generates a GCEV_ACCEPT_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 re-INVITE request.
4.7.5 Sending a SIP re-INVITE Request
This section focuses primarily on library behavior in 1PCC operating mode. In 3PCC, the
application is responsible for constructing the SDP offer that will be contained in the re-INVITE.
To send a SIP re-INVITE request, an application begins by constructing a GC_PARM_BLK that
contains parameter elements for the dialog and media session properties that it wishes to change.
Then the application passes that parameter block in a call to the gc_ReqModifyCall( ) function.
Note that there can be only a single re-INVITE transaction pending at any given time; if there is a
re-INVITE already pending (initiated by either endpoint), calling gc_ReqModifyCall( ) produces
an error result.
If a re-INVITE request times out, the library generates a GCEV_MODIFY_CALL_FAIL event to
the application with a cause value of IPEC_SIPReasonStatus408RequestTimeout. In compliance
with RFC 3261 the 408 timeout condition causes the library to send BYE to terminate the dialog,
and it notifies the application of this termination with a GCEV_DISCONNECTED event.