While the majority of Internet Telephony Service Providers (ITSP’s) provide a Calling party number look up service, commonly referred to as simply “Caller ID”, there are occasions where this service are not available or limited in some capacity. For example, some carriers will provide lookups for domestic numbers but not provide information for mobile, toll free or international numbers.
Theory Of Operation
Open CNAM provides an number of API’s for this, inclusive of a SIP Redirect API. While there is no SIP RFC for this methodology specifically it’s not an uncommon way to perform a look up against a CNAM lookup service. The diagram below shows an example call flow that the sample configuration will be based on. For simplicity the phone number for Cisco TAC is the example calling party number in this example.
Cisco CUBE will send a SIP INVITE to Open CNAM. Open CNAM will return a 300 Multiple Choices message in response that includes a “P-Asserted-Identity” header similar to this:
P-Asserted-Identity: "CISCO SYSTEMS T"<sip:firstname.lastname@example.org:5060>
The P-Asserted-Identity header value can then be copied into the identity header on the next outgoing call leg that will ultimately be delivered to the end station.
Open CNAM will also return a “Contact” header that will include the calling party number:
CUBE adheres to SIP RFC 3261 for SIP redirects where Contact header is the destination the call is being redirected to. The Contact header from Open CNAM does not follow this convention so it will need to be manipulated as well to specify the final destination for the call.
Globally we do need a few items configured to get started. First, ensure inbound SIP profile processing is enabled.
voice service voip
The configuration can be configured within a single dial-peer as shown below. The dial-peer will match the destination pattern of the call. The call will be routed to sip.opencnam.com and then redirected to the final destination.
dial-peer voice 200 voip
no notify redirect ip2ip
session protocol sipv2
session target dns:sip.opencnam.com
voice-class sip profiles 100 inbound
voice-class sip profiles 101
The inbound SIP profile will repair the contact header to allow the call to be routed to the final destination (the internal call control system). In the example the internal call control systems IP address is 192.168.1.10. This profile also takes a copy of the text string that will then be added into the new outgoing invite to the final destination. The “u02” variable is used for this.
voice class sip-profiles 100
response 300 sip-header To copy "sip:(.)@" u01
response 300 sip-header Contact modify "sip:.@." "sip:\email@example.com:5060>"
response 300 sip-header P-Asserted-Identity copy ":(.)<" u02
This SIP profile is used to modify the outgoing invite to include the caller ID text string stored in the “u02” variable. In my example we are using the Remote-Party-ID identity header to pass the information to the end station.
voice class sip-profiles 101
request INVITE sip-header From modify ":.<" ":\u02<"
request INVITE sip-header Remote-Party-ID modify ":.<" ":\u02<"
This configuration performs the lookup in additional of the CNAM data, however, if the dial-peer cannot reach the OpenCNAM service the call will fail. This is easily remediated by simply creating a second dial-peer with a higher preference value (the default is 0). If the Open CNAM dial-peer fails the call will be retired on the secondary dial-peer. This does introduce the need for a timeout to expire in waiting for the first dial-peer. To tune this behavior the SIP User Agent and be tuned. In the example below the call attempt times out after 2 invites and the timer for each invite is 250 milliseconds to receive a provisional response to the Invite message.
retry invite 2
timers trying 250
With this in place a redundant dial-peer will handle any calls that fail the lookup to Open CNAM by being routed directly to the next call processor.
dial-peer voice 201 voip
session protocol sipv2
session target ipv4:192.168.1.10