Dialogic Global Call IP Benutzerhandbuch
180
Dialogic
®
Global Call IP Technology Guide — November 2007
Dialogic Corporation
IP-Specific Operations
application requires the ability to send and receive SIP header fields that are longer than this default
maximum length (up to a maximum of 4096 bytes), it can overwrite the default value after
initializing the IPCCLIB_START_DATA but before calling gc_Start( ). The following code
snippet provides an example of setting a maximum length of 1024 bytes for SIP header fields (and
other parameter types that specifically support extended-length data) for each of two virtual boards:
maximum length (up to a maximum of 4096 bytes), it can overwrite the default value after
initializing the IPCCLIB_START_DATA but before calling gc_Start( ). The following code
snippet provides an example of setting a maximum length of 1024 bytes for SIP header fields (and
other parameter types that specifically support extended-length data) for each of two virtual boards:
INIT_IPCCLIB_START_DATA(&ipcclibstart, 2, ip_virtboard);
INIT_IP_VIRTBOARD(&ip_virtboard[0]);
INIT_IP_VIRTBOARD(&ip_virtboard[1]);
ipcclibstart.max_parm_data_size = 1024; /* set maximum SIP header length to 1k */
ip_virtboard[0].sip_msginfo_mask = IP_SIP_MSGINFO_ENABLE; /* override SIP message default */
ip_virtboard[1].sip_msginfo_mask = IP_SIP_MSGINFO_ENABLE; /* override SIP message default */
INIT_IP_VIRTBOARD(&ip_virtboard[0]);
INIT_IP_VIRTBOARD(&ip_virtboard[1]);
ipcclibstart.max_parm_data_size = 1024; /* set maximum SIP header length to 1k */
ip_virtboard[0].sip_msginfo_mask = IP_SIP_MSGINFO_ENABLE; /* override SIP message default */
ip_virtboard[1].sip_msginfo_mask = IP_SIP_MSGINFO_ENABLE; /* override SIP message default */
Note:
Features that are enabled or configured via the IPCCLIB_START_DATA structure cannot be
disabled or reconfigured once the library has been started. All items set in this data structure take
effect when the gc_Start( ) function is called and remain in effect until gc_Stop( ) is called when
the application exits.
disabled or reconfigured once the library has been started. All items set in this data structure take
effect when the gc_Start( ) function is called and remain in effect until gc_Stop( ) is called when
the application exits.
4.9.4
Registering SIP Header Fields to be Retrieved
In order to receive specific SIP header fields, the application must register the field names. The
registration is accomplished by constructing a GC_PARM_BLK where each element contains
registration information for an individual header field to be retrieved, then calling
gc_SetConfigData( ) to set the registration list in the library. Each element in the parm block uses
the IPSET_CONFIG set ID and the parameter ID IPPARM_REGISTER_SIP_HEADER, plus the
header field name as the parameter value. The registration of header fields only needs to be
performed once for a board device, but the application is free to set a different registration list at
some other time, if desired.
registration is accomplished by constructing a GC_PARM_BLK where each element contains
registration information for an individual header field to be retrieved, then calling
gc_SetConfigData( ) to set the registration list in the library. Each element in the parm block uses
the IPSET_CONFIG set ID and the parameter ID IPPARM_REGISTER_SIP_HEADER, plus the
header field name as the parameter value. The registration of header fields only needs to be
performed once for a board device, but the application is free to set a different registration list at
some other time, if desired.
When registering standard SIP header fields (that is, header fields which are defined in the IETF
RFC documents), the field names must be spelled consistently so that the SIP stack can recognize
the header fields properly. Be certain that the spelling matches the following list (noting that case
does not matter). Note that Request-URI is handled just like a standard header field, even though it
is technically distinct from true header fields.
RFC documents), the field names must be spelled consistently so that the SIP stack can recognize
the header fields properly. Be certain that the spelling matches the following list (noting that case
does not matter). Note that Request-URI is handled just like a standard header field, even though it
is technically distinct from true header fields.
Note:
In this list, header fields that are assumed to be accessible to applications to support functionality
documented in this guide are marked with a †, and fields that are accessible in part or in whole via
deprecated header-specific parameter defines are marked with an *.
documented in this guide are marked with a †, and fields that are accessible in part or in whole via
deprecated header-specific parameter defines are marked with an *.
•
Accept †
•
Accept-Encoding †
•
Accept-Language †
•
Allow †
•
Allow-Events
•
Authentication
•
Authentication-Info
•
Authorization
•
Call-ID † *
•
Contact † *