Dialogic IP Phone 05-2239-009 User Manual
164
Dialogic
®
Global Call IP Technology Guide — November 2007
Dialogic Corporation
IP-Specific Operations
The GC_PARM_BLK that the application constructs may contain three types of parameter
elements. There may be an element to specify the DTMF mode, one or more elements to specify
SIP header fields to change in order to update the properties of the dialog (such as the Contact or
Via information), and one or more elements to specify media capabilities to be included in the SDP
offer within the re-INVITE request.
elements. There may be an element to specify the DTMF mode, one or more elements to specify
SIP header fields to change in order to update the properties of the dialog (such as the Contact or
Via information), and one or more elements to specify media capabilities to be included in the SDP
offer within the re-INVITE request.
4.7.5.1
Specifying DTMF Mode in a re-INVITE Request
An application may request a change in the DTMF mode in re-INVITE request by inserting a
parameter element of the following type in the GC_PARM_BLK it passes to the
parameter element of the following type in the GC_PARM_BLK it passes to the
function:
IPSET_DTMF
IPPARM_SUPPORT_DTMF_BITMASK
•
value = IP_DTMF_TYPE_INBAND_RTP or IP_DTMF_TYPE_RFC_2833
4.7.5.2
Inserting SIP Header Fields in a re-INVITE Request
SIP header fields to be sent in a re-INVITE are specified using the standard technique. The
application simply inserts parameter elements of the following type into the GC_PARM_BLK it
passes to
application simply inserts parameter elements of the following type into the GC_PARM_BLK it
passes to
:
IPSET_SIP_MSGINFO
IPPARM_SIP_HDR
•
value = complete header string, including header field name
The header fields are inserted in the SIP message in the same order in which they are inserted into
the GC_PARM_BLK. See
the GC_PARM_BLK. See
page 183 for more details on sending SIP headers.
When setting header fields in SIP re-INVITE requests, there are some restrictions to note:
•
Request-URI and Call-ID cannot be set by the application because they are used to identify the
request as a subsequent INVITE request (re-INVITE).
request as a subsequent INVITE request (re-INVITE).
•
CSeq cannot be set by the application.
•
In the From and To headers, the URI and Tag cannot be changed because they are used to
identify the request as a re-INVITE. In both cases, the Display and some of the URI
parameters can be changed, but the application must ensure that the URI and Tag substrings
that it includes when specifying the header string are identical to those in the original INVITE.
identify the request as a re-INVITE. In both cases, the Display and some of the URI
parameters can be changed, but the application must ensure that the URI and Tag substrings
that it includes when specifying the header string are identical to those in the original INVITE.
•
Max-Forwards can be set by the application, but if the application does not set it the library
automatically sets it to 70.
automatically sets it to 70.
•
Contact and Via can be set by the application, but if the application does not provide them the
library automatically inserts the corresponding header field from the last INVITE or 2xx
response that the application sent in the current dialog.
library automatically inserts the corresponding header field from the last INVITE or 2xx
response that the application sent in the current dialog.
All other header fields, including proprietary headers, can be set without restriction.