Filter
Top Products
188 Dialogic
®
Global Call IP Technology Guide — November 2007
Dialogic Corporation
IP-Specific Operations
4.10 Using MIME Bodies in SIP Messages (SIP-T)
When using SIP, the Dialogic
®
Global Call API library supports the sending and receiving of
messages that include a single-part or multipart MIME body.
This feature was implemented primarily to allow applications to send and receive SIP Telephony
(SIP-T) information, which is encoded in a MIME message body as defined in RFC 3372, a
document which describes a framework for SIP-PSTN interworking gateways. This capability
allows the encapsulation of ISUP in the SIP body during or after call setup, and the use of the INFO
method for mid-call signaling. With the use of a separate SS7 signaling stack to translate the ISUP
information, applications can route SIP messages with dependencies on ISUP to provide ISUP
transparency across SS7-ISUP internetworking.
The Global Call implementation of SIP MIME messages is very general, so that it should support
MIME for a variety of other purposes besides SIP-T, such as text messaging. The call control
library only copies data to and from a SIP MIME body. With the exception of SDP (Session
Description Protocol), the Global Call library treats MIME body information as raw data and does
not parse or translate information that is encapsulated in SIP MIME messages. (SDP is not exposed
to the application like other MIME-encoded data because the call control library controls media
negotiations internally.)
4.10.1 SIP MIME Overview
The Dialogic
®
Global Call API library handles single-part MIME and multipart MIME in the same
way to simplify application coding. The library uses two levels of GC_PARM_BLK data structures
to contain information being embedded into or extracted from MIME messages. The top-level
GC_PARM_BLK structure contains a list of one or more lower-level GC_PARM_BLK structures
that contain the header and body information for each MIME part. When an application sends a
single MIME part in a SIP message that already includes a MIME part for SDP (which is not
exposed to applications in 1PCC mode and is not exposed using the mechanism described in this
section in 3PCC mode), the library transparently creates a multipart MIME message with the
appropriate multipart headers. In the case where an incoming message has multipart MIME
embedded in a multipart MIME part (nested parts), the Global Call library parses through all the
parts in order and extracts them to a flat list of data structures.
For incoming SIP messages with MIME information, the call control library creates a Global Call
event corresponding to the message type with GC_PARM_BLK structures attached. Standard
Global Call practices are used to retrieve the GC_PARM_BLK structures, and all information in
each MIME part is accessed through parameters in the corresponding GC_PARM_BLK structure.
It is important to note that the specific parameters that contain the MIME part header fields have
been defined as parameters that may exceed the 255 byte length limit of most Global Call
parameters. (The actual maximum size is configured via the max_parm_data_size field in the
IPCCLIB_START_DATA structure when initializing the library.) For this reason, applications
should always use the extended gc_util_..._ex( ) functions when retrieving MIME information
from incoming messages.
For outgoing SIP messages, the application must populate GC_PARM_BLK structures with
parameters that specify the content of all the MIME parts to be sent, and then set the MIME
information before or at the time of calling the relevant Global Call function that sends the SIP