Support for PAID PPID Privacy PCPID and PAURI Headers on the Cisco Unified Border Element
Last Updated: December 20, 2011
The figure below shows a typical network topology where the Cisco Unified Border Element is configured to route messages between a call manager system (such as the Cisco Unified Call Manager) and a Next Generation Network (NGN).
Figure 1
Cisco Unified Border Element and Next Generation Topology
Devices that connect to an NGN must comply with the User-Network Interface (UNI) specification. The Cisco Unified Border Element supports the NGN UNI specification and can be configured to interconnect NGN with other call manager systems, such us the Cisco Unified Call Manager.
The Cisco Unified Border Element supports the following:
the use of P-Preferred Identity (PPID), P-Asserted Identity (PAID), Privacy, P-Called Party Identity (PCPID), in INVITE messages
the translation of PAID headers to PPID headers and vice versa
the translation of From: or RPID headers to PAID or PPID headers and vice versa
the configuration and/or pass through of privacy header values
the use of the PCPID header to route INVITE messages
the use of multiple PAURI headers in the response messages (200 OK) it receives to REGISTER messages
P-Preferred Identity and P-Asserted Identity Headers
NGN servers use the PPID header to identify the preferred number that the caller wants to use. The PPID is part of INVITE messages sent to the NGN. When the NGN receives the PPID, it authorizes the value, generates a PAID based on the preferred number, and inserts it into the outgoing INVITE message towards the called party.
However, some call manager systems, such as Cisco Unified Call Manager 5.0, use the Remote-Party Identity (RPID) value to send calling party information. Therefore, the Cisco Unified Border Element must support building the PPID value for an outgoing INVITE message to the NGN, using the RPID value or the From: value received in the incoming INVITE message. Similarly, CUBE supports building the RPID and/or From: header values for an outgoing INVITE message to the call manager, using the PAID value received in the incoming INVITE message from the NGN.
In non-NGN systems, the Cisco Unified Border Element can be configured to translate between PPID and PAID values, and between From: or RPID values and PAID/PPID values, at global and dial-peer levels.
In configurations where all relevant servers support the PPID or PAID headers, the Cisco Unified Border Element can be configured to transparently pass the header.
Note
If the NGN sets the From: value to anonymous, the PAID is the only value that identifies the caller.
The table below describes the types of INVITE message header translations supported by the Cisco Unified Border Element. It also includes information on the configuration commands to use to configure P-header translations.
The table below shows the P-header translation configuration settings only. In addition to configuring these settings, you must configure other system settings (such as the session protocol).
Table 1
P-header Configuration Settings
Incoming Header
Outgoing Header
Configuration Notes
From:
PPID
To enable the translation to PPID headers in the outgoing header at a global level, use the
asserted-idppi command in voice service VoIP SIP configuration mode. For example: Router(conf-serv-sip)#
asserted-idppi
To enable the translation to PPID headers in the outgoing header on a specific dial peer, use the
voice-classsipasserted-idppi command in dial peer voice configuration mode. For example: Router(config-dial-peer)#
voice-classsipasserted-idppi
From:
PAID
To enable the translation to PAID headers in the outgoing header at a global level, use the
asserted-idpai command in voice service VoIP SIP configuration mode. For example: Router(conf-serv-sip)#
asserted-idpai
To enable the translation to PAID headers in the outgoing header on a specific dial peer, use the
voice-classsipasserted-idpai command in dial peer voice configuration mode. For example: Router(config-dial-peer)#
voice-classsipasserted-idpai
From:
RPID
To enable the translation to RPID headers in the outgoing header, use the
remote-party-id command in SIP user-agent configuration mode. For example: Router(config-sip-ua)#
remote-party-id
This is the default system behavior.
Note
If both,
remote-party-id and
asserted-id commands are configured, then the
asserted-id command takes precedence over the
remote-part-id command.
PPID
PAID
To enable the translation to PAID privacy headers in the outgoing header at a global level, use the
asserted-idpai command in voice service VoIP SIP configuration mode. For example: Router(conf-serv-sip)#
asserted-idpai
To enable the translation to PAID privacy headers in the outgoing header on a specific dial peer, use the
voice-classsipasserted-idpai command in dial peer voice configuration mode. For example: Router(config-dial-peer)#
voice-classsipasserted-idpai
PPID
From:
By default, the translation to RPID headers is enabled and the system translates PPID headers in incoming messages to RPID headers in the outgoing messages. To disable the default behavior and enable the translation from PPID to From: headers, use the
noremote-party-id command in SIP user-agent configuration mode. For example: Router(config-sip-ua)#
noremote-party-id
PPID
RPID
To enable the translation to RPID headers in the outgoing header, use the
remote-party-id command in SIP user-agent configuration mode. For example: Router(config-sip-ua)#
remote-party-id
This is the default system behavior.
PAID
PPID
To enable the translation to PPID privacy headers in the outgoing header at a global level, use the
asserted-idppi command in voice service VoIP SIP configuration mode. For example: Router(conf-serv-sip)#
asserted-idppi
To enable the translation to PPID privacy headers in the outgoing header on a specific dial peer, use the
voice-classsipasserted-idppi command in dial peer voice configuration mode. For example: Router(config-dial-peer)#
voice-classsipasserted-idppi
PAID
From:
By default, the translation to RPID headers is enabled and the system translates PPID headers in incoming messages to RPID headers in the outgoing messages. To disable the default behavior and enable the translation from PPID to From: headers, use the
noremote-party-id command in SIP user-agent configuration mode. For example: Router(config-sip-ua)#
noremote-party-id
PAID
RPID
To enable the translation to RPID headers in the outgoing header, use the
remote-party-id command in SIP user-agent configuration mode. For example: Router(config-sip-ua)#
remote-party-id
This is the default system behavior.
RPID
PPID
To enable the translation to PPID privacy headers in the outgoing header at a global level, use the
asserted-idppi command in voice service VoIP SIP configuration mode. For example: Router(conf-serv-sip)#
asserted-idppi
To enable the translation to PPID privacy headers in the outgoing header on a specific dial peer, use the
voice-classsipasserted-idppi command in dial peer voice configuration mode. For example: Router(config-dial-peer)#
voice-classsipasserted-idppi
RPID
PAID
To enable the translation to PAID privacy headers in the outgoing header at a global level, use the
asserted-idpai command in voice service VoIP SIP configuration mode. For example: Router(conf-serv-sip)#
asserted-idpai
To enable the translation to PAID privacy headers in the outgoing header on a specific dial peer, use the
voice-classsipasserted-idpai command in dial peer voice configuration mode. For example: Router(config-dial-peer)#
voice-classsipasserted-idpai
RPID
From:
By default, the translation to RPID headers is enabled and the system translates PPID headers in incoming messages to RPID headers in the outgoing messages. To disable the default behavior and enable the translation from PPID to From: headers, use the
noremote-party-id command in SIP user-agent configuration mode. For example: Router(config-sip-ua)#
noremote-party-id
Privacy
If the user is subscribed to a privacy service, the Cisco Unified Border Element can support privacy using one of the following methods:
Using prefixes
The NGN dial plan can specify prefixes to enable privacy settings. For example, the dial plan may specify that if the caller dials a prefix of 184, the calling number is not sent to the called party.
The dial plan may also specify that the caller can choose to send the calling number to the called party by dialing a prefix of 186. Here, the Cisco Unified Border Element transparently passes the prefix as part of the called number in the INVITE message.
The actual prefixes for the network are specified in the dial plan for the NGN, and can vary from one NGN to another.
Using the Privacy header
If the Privacy header is set to None, the calling number is delivered to the called party. If the Privacy header is set to a Privacy:id value, the calling number is not delivered to the called party.
Using Privacy values from the peer call leg
If the incoming INVITE has a Privacy header or a RPID with privacy on, the outgoing INVITE can be set to Privacy: id. This behavior is enabled by configuring
privacypstn command globally or
voice-classsipprivacypstn command on the selected dial-per.
Incoming INVITE can have multiple privacy header values, id, user, session, and so on. Configure the
privacy-policypassthru command globally or
voice-classsipprivacy-policypassthru command to transparently pass across these multiple privacy header values.
Some NGN servers require a Privacy header to be sent even though privacy is not required. In this case the Privacy header must be set to none. The Cisco Unified Border Element can add a privacy header with the value None while forwarding the outgoing INVITE to NGN. Configure the
privacy-policysend-always globally or
voice-classsipprivacy-policysend-always command in dial-peer to enable this behavior.
If the user is not subscribed to a privacy service, the Cisco Unified Border Element can be configured with no Privacy settings.
P-Called Party Identity
The Cisco Unified Border Element can be configured to use the PCPID header in an incoming INVITE message to route the call, and to use the PCPID value to set the To: value of outgoing INVITE messages.
The PCPID header is part of the INVITE messages sent by the NGN, and is used by Third Generation Partnership Project (3GPP) networks. The Cisco Unified Border Element uses the PCPID from incoming INVITE messages (from the NGN) to route calls to the Cisco Unified Call Manager.
Note
The PCPID header supports the use of E.164 numbers only.
P-Associated URI
The Cisco Unified Border Element supports the use of PAURI headers sent as part of the registration process. After the Cisco Unified Border Element sends REGISTER messages using the configured E.164 number, it receives a 200 OK message with one or more PAURIs. The number in the first PAURI (if present) must match the contract number. The Cisco Unified Border Element supports a maximum of six PAURIs for each registration.
Note
The Cisco Unified Border Element performs the validation process only when a PAURI is present in the 200 OK response.
The registration validation process works as follows:
The Cisco Unified Border Element receives a REGISTER response message that includes PAURI headers that include the contract number and up to five secondary numbers.
The Cisco Unified Border Element validates the contract number against the E.164 number that it is registering:
If the values match, the Cisco Unified Border Element completes the registration process and stores the PAURI value. This allows administration tools to view or retrieve the PAURI if needed.
If the values do not match, the Cisco Unified Border Element unregisters and then reregisters the contract number. The Cisco Unified Border Element performs this step until the values match.
Random Contact Support
The Cisco Unified Border Element can use random-contact information in REGISTER and INVITE messages so that user information is not revealed in the contact header.
To provide random contact support, the Cisco Unified Border Element performs SIP registration based on the random-contact value. The Cisco Unified Border Element then populates outgoing INVITE requests with the random-contact value and validates the association between the called number and the random value in the Request-URI of the incoming INVITE. The Cisco Unified Border Element routes calls based on the PCPID, instead of the Request-URI which contains the random value used in contact header of the REGISTER message.
The default contact header in REGISTER messages is the calling number. The Cisco Unified Border Element can generate a string of 32 random alphanumeric characters to replace the calling number in the REGISTER contact header. A different random character string is generated for each pilot or contract number being registered. All subsequent registration requests will use the same random character string.
The Cisco Unified Border Element uses the random character string in the contact header for INVITE messages that it forwards to the NGN. The NGN sends INVITE messages to the Cisco Unified Border Element with random-contact information in the Request URI. For example: INVITE sip:FefhH3zIHe9i8ImcGjDD1PEc5XfFy51G@10.12.1.46:5060.
The Cisco Unified Border Element will not use the To: value of the incoming INVITE message to route the call because it might not identify the correct user agent if supplementary services are invoked. Therefore, the Cisco Unified Border Element must use the PCPID to route the call to the Cisco Unified Call Manager. You can configure routing based on the PCPID at global and dial-peer levels.
Your software release may not support all the features documented in this module. For the latest feature information and caveats, see the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the Feature Information Table at the end of this document.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to
www.cisco.com/go/cfn. An account on Cisco.com is not required.
Prerequisites for Support for PAID PPID Privacy PCPID and PAURI Headers on the Cisco UBE
Cisco Unified Border Element
Cisco IOS Release 12.4(22)YB or a later release must be installed and running on your Cisco Unified Border Element.
Cisco Unified Border Element (Enterprise)
Cisco IOS XE Release 3.1S or a later release must be installed and running on your Cisco ASR 1000 Series Router.
Restrictions for Support for PAID PPID Privacy PCPID and PAURI Headers on the Cisco UBE
To enable random-contact support, you must configure the Cisco Unified Border Element to support SIP registration with random-contact information. In addition, you must configure random-contact support in VoIP voice-service configuration mode or on the dial peer.
If random-contact support is configured for SIP registration only, the system generates the random-contact information, includes it in the SIP REGISTER message, but does not include it in the SIP INVITE message.
If random-contact support is configured in VoIP voice-service configuration mode or on the dial peer only, no random contact is sent in either the SIP REGISTER or INVITE message.
Configuring P-Header and Random-Contact Support on the Cisco Unified Border Element
To enable random contact support you must configure the Cisco Unified Border Element to support Session Initiation Protocol (SIP) registration with random-contact information, as described in this section.
To enable the Cisco Unified Border Element to use the PCPID header in an incoming INVITE message to route the call, and to use the PCPID value to set the To: value of outgoing INVITE messages, you must configure P-Header support as described in this section.
Enables the SIP gateways to register E.164 numbers on behalf of analog telephone voice ports (FXS), IP phone virtual voice ports (EFXS), and Skinny Client Control Protocol (SCCP) phones with an external SIP proxy or SIP registrar.
The random-contact keyword configures the Cisco Unified Border Element to send the random string from the REGISTER message to the registrar.
Step 6
exit
Example:
Router(config-sip-ua)# exit
Exits the current mode.
Step 7
voiceservicevoip
Example:
Router(config)# voice service voip
Enters VoIP voice-service configuration mode.
Step 8
sip
Example:
Router(conf-voi-serv)# sip
Enters voice service VoIP SIP configuration mode.
Step 9
random-contact
Example:
Router(conf-serv-sip)# random-contact
Enables random-contact support on a Cisco Unified Border Element.
Step 10
exit
Example:
Router(conf-serv-sip)# exit
Exits the current mode.
Configuring Random-Contact Support for an Individual Dial Peer
To configure configure random-contact support for an individual dial peer, perform the steps in this section.
Feature Information for PAID PPID Privacy PCPID and PAURI Headers on the Cisco Unified Border Element
The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to
www.cisco.com/go/cfn. An account on Cisco.com is not required.
Feature History Table entry for the Cisco Unified Border Element.
Table 2
Feature Information for PAID, PPID, Privacy, PCPID, and PAURI Headers on the UBE
Feature Name
Releases
Feature Information
PAID, PPID, Privacy, PCPID, and PAURI Headers on the Cisco Unified Border Element
12.4(22)YB 15.0(1)M
This feature enables Cisco UBE platforms to support:
P-Preferred Identity (PPID), P-Asserted Identity (PAID), Privacy, P-Called Party Identity (PCPID), in INVITE messages
Translation of PAID headers to PPID headers and vice versa
Translation of From: or RPID headers to PAID or PPID headers and vice versa
Configuration and/or pass through of privacy header values
PCPID header to route INVITE messages
Multiple PAURI headers in the response messages (200 OK) it receives to REGISTER messages
P-Preferred Identity and P-Asserted Identity Headers
The following commands were introduced:
call-routep-called-party-id,
privacy-policy,
random-contact,
random-request-urivalidate,
voice-classsipcall-routep-called-party-id,
voice-classsipprivacy-policy,
voice-classsiprandom-contact, and
voice-classsiprandom-request-urivalidate.
Feature History Table entry for the Cisco Unified Border Element (Enterprise) .
Table 3
Feature Information for PAID, PPID, Privacy, PCPID, and PAURI Headers on the Cisco UBE
Feature Name
Releases
Feature Information
PAID, PPID, Privacy, PCPID, and PAURI Headers on the Cisco Unified Border Element
Cisco IOS XE Release 3.1S
This feature enables Cisco UBE platforms to support:
P-Preferred Identity (PPID), P-Asserted Identity (PAID), Privacy, P-Called Party Identity (PCPID), in INVITE messages
Translation of PAID headers to PPID headers and vice versa
Translation of From: or RPID headers to PAID or PPID headers and vice versa
Configuration and/or pass through of privacy header values
PCPID header to route INVITE messages
Multiple PAURI headers in the response messages (200 OK) it receives to REGISTER messages
P-Preferred Identity and P-Asserted Identity Headers
The following commands were introduced:
call-routep-called-party-id,
privacy-policy,
random-contact,
random-request-urivalidate,
voice-classsipcall-routep-called-party-id,
voice-classsipprivacy-policy,
voice-classsiprandom-contact, and
voice-classsiprandom-request-urivalidate.
Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL:
www.cisco.com/go/trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.