Caller Information Delivery Content for AT&T Trunks

SIP Server can pass the multipart body content received in INVITE messages (as described in RFC 5621) to make it available to URS/ORS and/or GVP. The only content type currently supported is Caller Information Delivery (CID), as defined in the AT&T specification for AT&T IP Toll Free Service SIP trunks.

SIP Server communicates with URS/ORS using T-Library to pass the CID content that it receives in a multipart INVITE body, as an attribute of an EventRouteRequest message. See Passing CID content to T-Library clients (URS/ORS) below.

SIP Server communicates with GVP using SIP to pass the CID content that it receives in a multipart INVITE body in the relayed INVITE. See Passing CID content to SIP Destinations (GVP) below.

Notes:

• CID content that is received in a multipart INVITE body is still delivered following an MCP failure or a SIP Server failure in HA Hot-Standby mode.
• CID content is handled in Presence Information Data Format (PIDF), as RFC 3863 describes in detail.

Enabling CID Content Retrieval

Configure the DN-level option sip-accept-body to enable SIP Server to retrieve CID content from the INVITE that it receives from a Trunk DN.

Setting: DN-level
Section: TServer
Option: sip-accept-body
Default Value: An empty string
Valid Values: cid or empty
Changes Take Effect: For the next call

This option specifies the content type that SIP Server retrieves from the incoming INVITE with a multipart body received from an origination DN.

• If set to an empty string (default), SIP Server ignores the multipart body of an INVITE.
• If set to cid, SIP Server extracts the CID body from the INVITE and stores it as the caller's property.

This option...

• ...does not affect SDP.
• ...is supported only on Trunk DNs, ignored by all other DN types.

Passing CID Content to T-Library Clients (URS/ORS)

SIP Server previously mapped the SDP portion of a SIP message body to a T-Library event attribute; see the section "Mapping SIP Headers and SDP Messages" in Chapter 5 of the SIP Server Deployment Guide. Now it can also perform CID mapping to T-Library clients (URS/ORS). SIP Server sends EventRouteRequest with the CID content passed in AttributeExtensions.

To enable CID mapping to T-Library clients, add this configuration option to the INVITE section:

• extensions-1 = CID

By default, CID content is passed to T-Library clients unchanged (UTF-8 encoding). If conversion to a local charset is enabled for SIP-to-TLib mapping (set with the encoding option), then this conversion is also applied to CID content.

Note: CID can be mapped to AttributeExtensions only. CID mapping to AttributeUserData is not supported.

Example

message EventRouteRequest
 AttributeThisDN '5001'
 AttributeThisDNRole 2
 AttributeThisQueue '5001'
 AttributeOtherDN '31001'
 AttributeOtherDNRole 1
 AttributeConnID 2266025dfcd2c001
 AttributeExtensions
       'CID'  
       'Content-Type: application/pidf+xml
       <presence xmlns="urn:ietf:params:xml:ns:pidf"
       xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
       xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
       xmlns:gml="http://www.opengis.net/gml"
       xmlns:gs="http://www.opengis.net/pidflo/1.0"
       xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
       xmlns:tf="http://www.att.com/iptf"
       entity="pres:tfas1@att.net">
       <tf:dataresponse status="available"/>
       <dm:device id="3754348893">
           <gp:geopriv>
               <gp:location-info>
                   <gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
                       <gml:pos>40.3958 -74.1322</gml:pos>
                       <gs:radius uom="urn:ogc:def:uom:EPSG::9001">113</gs:radius>
                   </gs:Circle>
                   <cl:civicAddress>
                       <cl:A1>Daly City</cl:A1>
                       <cl:A3>CA</cl:A3>
                       <cl:PC>94014</cl:PC>
                       <tf:streetaddress>2001 Junipero Serra</tf:streetaddress>
                       <tf:name>Genesys</tf:name>
                       <tf:givenName></tf:givenName>
                       <tf:mailableVerified>true</tf:mailableVerified>
                       <tf:listType>Bus</tf:listType>
                   </cl:civicAddress>
               </gp:location-info>
           </gp:geopriv>
       </dm:device>
       </presence>'

Passing CID Content to SIP Destinations (GVP)

Configure the DN-level option sip-pass-body to specify that the CID content (taken from one of the call parties) is included in the initial INVITE that is sent to the DN.

Setting: DN-level
Section: TServer
Option: sip-pass-body
Default Value: An empty string
Valid Values: cid
Changes Take Effect: For the next call

This option specifies the content type that should be passed in the multipart body of the origination INVITE to this device, if that content type is received from the caller.

• If set to an empty string (default), SIP Server does not send any special content types.
• If set to cid, SIP Server sends the CID body to the DN.

This option...

• ...does not affect SDP.
• ...is supported on Trunk DNs, Trunk Group DNs, and VoIP Service DNs with service-type set to msml and voicemail.

Configure the Application-level option cid-enable-on-vtp to simplify provisioning of the IVR configured through the Voice Treatment Port (VTP) DNs. Set to true to specify that CID content is passed to the VTP DN in the initial INVITE.

Setting: Application-level
Section: TServer
Option: cid-enable-on-vtp
Default Value: false
Valid Values: true, false
Changes Take Effect: For the next call

Use this option to simplify provisioning of the IVR that is configured through the Voice Treatment Port DNs.

• If set to true, SIP Server passes the CID content to the VTP DN in the initial INVITE.
• If set to false, SIP Server does not pass the CID content to the VTP DN in the initial INVITE.

Note: CID content default encoding is in UTF-8. No content re-encoding and no URL encoding is performed; CID is passed to SIP destinations as it is received.