-
Cisco Unified Communications Manager System Guide for Cisco Unified Communications Manager Business Edition, Release 6.0(1)
-
Index
-
Preface
- Understanding Cisco Unified Communications Manager
- Understanding Cisco Unified Communications Manager System Configuration
- Dial Plan Architecture
- User Configuration and Credential Policy
- Media Resources
- System Features
-
Devices and Protocols
-
Understanding Cisco Unified Communications Manager Voice Gateways
-
Understanding IP Telephony Protocols
-
Understanding Session Initiation Protocol
-
Understanding Cisco Unified Communications Manager Trunk Types
-
Cisco Unified IP Phones
-
Understanding Video Telephony
-
Computer Telephony Integration
-
Cisco ATA 186
-
- System Maintenance
-
Feedback
Table Of Contents
Understanding Session Initiation Protocol (SIP)
SIP and Cisco Unified Communications Manager
Media Termination Point (MTP) Devices
Configuring Regions (Region Relationship) for SIP Devices with the MTP Required Option Enabled
Supported Application Media Type
SIP Trunks Between Cisco Unified Communications Manager Release 4.x and 6.0 Systems
SIP Functions That Are Supported in Cisco Unified Communications Manager
Basic Calls Between SIP Endpoints and Cisco Unified Communications Manager
DTMF Relay Calls Between SIP Endpoints and Cisco Unified Communications Manager
Generating DTMF Digits for Dissimilar DTMF Methods
Supplementary Services That Are Initiated If an MTP Is Allocated
Ringback Tone During Blind Transfer
Supplementary Services That Are Initiated by SIP Endpoint
Enhanced Call Identification Services
Calling Line and Name Identification Presentation
Calling Line and Name Identification Restriction
Connected Line and Name Identification Presentation
Connected Line and Name Identification Restriction
Redirecting Dial Number Identification Service (RDNIS)
SIP Trunk Configuration Checklist
Cisco Unified Communications Manager SIP Endpoints Overview
RFC3261, RFC3262 (PRACK), RFC3264 (offer/answer), RFC3311 (UPDATE), 3PCC
RFC3515 (REFER) also Replaces and Referred-by Headers
RFC3265 + RFC3842 MWI Package (unsolicited notify)
Cisco Unified Communications Manager Functionality That Is Supported by SIP Phones
Where to Find More Information
Understanding Session Initiation Protocol (SIP)
This chapter describes SIP and the interaction between SIP and Cisco Unified Communications Manager.
This section covers the following topics:
•
SIP and Cisco Unified Communications Manager
•
•
•
•
•
SIP Networks
A SIP network uses the following components:
•
•
•
•
SIP uses a request/response method to establish communications between various components in the network and to ultimately establish a call or session between two or more endpoints. A single session may involve several clients and servers.
Identification of users in a SIP network works through
•
•
sip:<userID>@<domain>. The user ID can comprise either a user name or an E.164 address. Cisco Unified Communications Manager only supports E.164 addresses; it does not support e-mail addresses.•
SIP and Cisco Unified Communications Manager
All protocols require that either a signaling interface (trunk) or a gateway be created to accept and originate calls. For SIP, the user must configure a SIP trunk. For more information, refer to Trunk Configuration in the Cisco Unified Communications Manager Administration Guide.
SIP trunks connect Cisco Unified Communications Manager networks and SIP networks that are served by a SIP proxy server. As with other protocols, SIP components fit under the device layer of Cisco Unified Communications Manager architecture. As is true for the H.323 protocol, you can configure multiple logical SIP trunks in the Cisco Unified Communications Manager database and associated with route groups, route lists, and route patterns. To provide redundancy, in the event of failure of one logical SIP interface, other logical SIP interfaces provide services in the same route group list. Assigning multiple Cisco Unified Communications Manager nodes under SIP trunk device pools also achieves redundancy.
SIP trunks support multiple port-based routing. Multiple SIP trunks on Cisco Unified Communications Manager can use port 5060, the default, which is configurable from the SIP Trunk Security Profile Configuration window. For TCP/UDP, SIP trunks use the remote host and local listening port to do the routing (the remote host can be IP, FQDN, or SRV). For TLS, SIP trunks use X.509 Subject Name to do the routing. For SIP trunks, Cisco Unified Communications Manager only accepts calls from the SIP device whose IP address matches the destination address of the configured SIP trunk. In addition, the port on which the SIP message arrives must match the one that is configured on the SIP trunk.
Figure 35-1 SIP and Cisco Unified Communications Manager Interaction
Media Termination Point (MTP) Devices
You can configure Cisco Unified Communications Manager SIP devices (lines and trunks) to always use an MTP. If the configuration parameters are set to not use an MTP (default case), Cisco Unified Communications Manager will attempt to dynamically allocate an MTP if the DTMF methods for the call are not compatible. For example, SCCP phones support only out-of-band DTMF, and Cisco Unified IP Phones using SIP (7905, 7912, 7940, 7960) support only RFC2833. Because the DTMF methods are not identical, Cisco Unified Communications Manager will dynamically allocate an MTP. If, however, a SCCP phone that supports RFC2833 and out of band, such as Cisco Unified IP Phone 7971, calls a Cisco Unified IP Phone 7940 that is using SIP, Cisco Unified Communications Manager will not allocate an MTP because both phones support RFC2833. By having the same type of DTMF method supported on each phone, no need for an MTP exists.
Note
Configuring Regions (Region Relationship) for SIP Devices with the MTP Required Option Enabled
When you configure a region relationship, you must ensure that you choose an audio codec that has sufficient bandwidth for all the devices that will be used in a call. This includes configuring the codec for devices that will be in the same region as well as devices that are in different regions. When you configure a trunk or third-party phone to use the SIP protocol and Media Termination Point Required is enabled, Cisco Unified Communications Manager Administration only allows you to choose a G.711 codec in the MTP Preferred Originating Codec field. When you assign the SIP trunk or third-party SIP phone with the MTP Required option enabled to the device pool for that region, you must verify that the region relationship between the SIP device and the MTP device is configured to use a codec with equal or greater bandwidth (G.711 or Wideband/AAC codec).
SIP Service Parameters
You can individually configure SIP timers and counters for functionality on different servers. Refer to Service Parameters Configuration in the Cisco Unified Communications Manager Administration Guide for full information on how to configure service parameters.
SIP Timers and Counters
SIP timers and counters act as configurable service parameters. The following tables describe the various SIP timers and counters and give their default values and range values:
Note
Supported Audio Media Types
The following table describes the various supported audio media types:
Supported Video Media Types
The following table describes the various supported video media types:
Supported Application Media Type
The following table describes the supported application media types:
Table 35-5 Supported Application Media Types
H.224 FECC
H224
Acceptable range comprises 96 - 127
Supported T38fax Payload Type
The following table describes the various supported application media types:
Table 35-6 Supported T38fax Payload type
T38fax
Not applied
Not applicable
SIP Profiles for Trunks
SIP trunks and SIP endpoints use SIP profiles. SIP trunks use SIP profiles to define the Default Telephony Event Payload Type and the Disable Early media on 180. For more information on SIP profiles, see the "SIP Profiles for Endpoints" section and "SIP Profile Configuration" in the Cisco Unified Communications Manager Administration Guide.
SIP Trunk Security Profiles
Cisco Unified Communications Manager Administration groups security-related settings for the SIP trunk to allow you to assign a single security profile to multiple SIP trunks. Security-related settings include device security mode, digest authentication, and incoming/outgoing transport type settings. You apply the configured settings to the SIP trunk when you choose the security profile in the Trunk Configuration window. For more information, see the Cisco Unified Communications Manager Security Guide.
SIP Trunks Between Cisco Unified Communications Manager Release 4.x and 6.0 Systems
Cisco Unified Communications Manager Release 6.0 and later and Cisco Unified Communications Manager Release 4.0 and later support TCP and UDP as Transport Types when they are used with SIP trunks. However, release 4.x uses one TCP connection per SIP call; 6.0 supports multiple SIP calls over the same TCP connection (referred to as TCP connection reuse).
The following Cisco products support TCP; however, not all support TCP Reuse (see Table 35-7 for more information):
•
•
•
•
•
•
•
•
Table 35-7 lists the SIP trunk connectivity that is supported among Cisco Unified Communications Manager Release 4.x, 5.x, and 6.x and the IOS gateway.
If a Release 6.x system makes multiple calls over a TCP-based SIP trunk to a 4.x system, the 4.x system will only connect one call. The rest of the calls will not get connected.When using SIP trunks between 4.x and 6.x systems, you must configure both systems to use UDP as the Outgoing Transport Type, so calls between the release 4.x and 6.x systems will connect properly. (See Table 35-7.)
To configure UDP, use Cisco Unified Communications Manager Administration.
•
•
For more information about SIP trunks and transport types, see the Cisco Unified Communications Manager Security Guide and the Cisco Unified Communications Manager Administration Guide.
SIP Forking for SIP Trunk
Call setup (INVITE) requests sent by Cisco Unified Communications Manager on a SIP trunk may be replicated and forwarded to multiple destinations by a SIP proxy (called forking). Cisco Unified Communications Manager Releases 4.x, 5.x, and 6.0 support forking, subject to the following limitations:
•
•
•
•
No other configuration options affect Cisco Unified Communications Manager support of downstream SIP forking.
SIP Functions That Are Supported in Cisco Unified Communications Manager
Cisco Unified Communications Manager supports the following functions and features for SIP calls:
•
•
•
•
•
•
•
Basic Calls Between SIP Endpoints and Cisco Unified Communications Manager
This section includes three basic calling scenarios. Two scenarios describe incoming and outgoing calls, while the other one describes the use of early media, which is a media connection prior to the connection or answer of a call. The section describes the following calling scenarios:
Basic Outgoing Call
You can initiate outgoing calls to a SIP device from any Cisco Unified Communications Manager device. A Cisco Unified Communications Manager device includes SCCP or SIP IP phones or fax devices that are connected to Foreign Exchange Station (FXS) gateways. For example, an SCCP IP phone can place a call to a SIP endpoint. The SIP device answering the call triggers media establishment.
Basic Incoming Call
Any device on the SIP network, including SIP IP Phones or fax devices that are connected to FXS gateways, can initiate incoming calls. For example, a SIP endpoint can initiate a call to an SCCP IP phone. The SCCP IP phone that answers the call triggers media establishment.
Use of Early Media
While the PSTN provides inband progress information to signal early media (such as a ring tone or a busy signal), the same thing does not occur for SIP. The originating party includes Session Description Protocol (SDP) information, such as codec usage, IP address, and port number, in the outgoing INVITE message. In response, the terminating party sends its codec, IP address, and port number in a 183 Session Progress message to indicate possible early media.
The 183 Session Progress response indicates that the message body contains information about the media session. Both 180 Alerting and 183 Session Progress messages may contain SDP, which allows an early media session to be established prior to the call being answered.
When early media needs to be delivered to SIP endpoints prior to connection, Cisco Unified Communications Manager always sends a 183 Session Progress message with SDP. Although Cisco Unified Communications Manager does not generate a 180 Alerting message with SDP, it does support the 180 Alerting message with SDP when it receives one.
The SIP Profile Configuration window contains a Disable Early Media on 180 check box. Check the check box to play local ringback on the called phone and connect the media upon receipt of the 200OK response. See the "SIP Profile Configuration Settings" section on page 92-3.
DTMF Relay Calls Between SIP Endpoints and Cisco Unified Communications Manager
MTPs now dynamically get allocated, if needed, based on the DTMF methods that are used on each endpoint.
Forwarding DTMF Digits from SIP Devices to Gateways or Interactive Voice Response (IVR) Systems for Dissimilar DTMF Methods
The following example (Figure 35-2) shows the MTP software device that is processing inband DTMF digits from the SIP phone to communicate with the Primary Rate Interface (PRI) gateway. The RTP stream carries RFC 2833 DTMF, as indicated by a dynamic payload type.
Figure 35-2 Forwarding DTMF Digits
Figure 35-2 begins with media streaming, and the MTP device has been informed of the DTMF dynamic payload type.
1.
2.
3.
Generating DTMF Digits for Dissimilar DTMF Methods
As discussed in DTMF Relay Calls Between SIP Endpoints and Cisco Unified Communications Manager, SIP sends DTMF in-band digits, while Cisco Unified Communications Manager only supports out-of-band digits. The software MTP device receives the DTMF out-of-band tones and generates DTMF in-band tones to the SIP client.
Figure 35-3 Generating DTMF Digits
Figure 35-3 begins with media streaming, and the MTP device has been informed of the dynamic DTMF payload type.
1.
2.
3.
Supplementary Services That Are Initiated If an MTP Is Allocated
The system supports all supplementary services that the SCCP endpoint initiates during a SIP call. Cisco Unified Communications Manager internally manages SCCP endpoints without affecting the connecting SIP device. Any changes to the original connecting information get updated with re-INVITE or UPDATE messages that use the Remote-Party-ID header. See SIP Extensions for Caller Identity and Privacy for more information on the Remote-Party-ID header.
The "Ringback Tone During Blind Transfer" section describes a blind transfer, which is unique as a supplementary service because it requires Cisco Unified Communications Manager to provide a media announcement.
Ringback Tone During Blind Transfer
For SCCP-initiated blind transfers, Cisco Unified Communications Manager needs to generate tones or ringback after a call already has connected. In other words, Cisco Unified Communications Manager provides a media announcement for blind transfers.
A blind transfer works when the transferring phone connects the caller to a destination line before the target of the transfer answers the call. A blind transfer differs from a consultative, or attended transfer, in which one transferring party either connects the caller to a ringing phone (ringback received) or speaks with the third party before connecting the caller to the third party.
Blind transfers that are initiated from an SCCP IP phone allow ringback to the original, connected SIP device user. To accomplish ringback, Cisco Unified Communications Manager uses an annunciator software device that is often located with an MTP device.
With an annunciator, Cisco Unified Communications Manager can play predefined tones and announcements to SCCP IP phones, gateways, and other IP telephony devices. These predefined tones and announcements provide users with specific information on the status of the call.
Supplementary Services That Are Initiated by SIP Endpoint
The following sections describe supplementary services that a SIP endpoint can initiate.
SIP-Initiated Call Transfer
Cisco Unified Communications Manager supports SIP-initiated call transfer and accepts REFER requests or INVITE messages that include a Replaces header.
Call Hold
Cisco Unified Communications Manager supports call hold and retrieve that a SIP device initiates or that a Cisco Unified Communications Manager device initiates. For example, when a SCCP IP phone user retrieves a call that another user placed on hold, Cisco Unified Communications Manager sends a re-INVITE message to the SIP proxy. The re-INVITE message contains updated Remote-Party-ID information to reflect the current connected party. If Cisco Unified Communications Manager originally initiated the call, the Party field in the Remote-Party-ID header gets set to calling; otherwise, it gets set to called. For more information on the Party field parameter, see Enhanced Call Identification Services.
Call Forward
Cisco Unified Communications Manager supports call forward that a SIP device initiates or that a Cisco Unified Communications Manager device initiates. With call forwarding redirection requests from SIP devices, Cisco Unified Communications Manager processes the requests. For call forwarding that is initiated by Cisco Unified Communications Manager, the system uses no SIP redirection messages. Cisco Unified Communications Manager handles redirection internally and then conveys the connected party information to the originating SIP endpoint through the Remote-Party-ID header.
Enhanced Call Identification Services
This section describes the following SIP identification services in Cisco Unified Communications Manager and how Cisco Unified Communications Manager conveys these identification services in the SIP:
•
–
–
•
–
–
Cisco Unified Communications Manager provides flexible configuration options to provide these identification services either on a call-by-call or a statically preconfigured for each SIP signaling interface basis.
Calling Line and Name Identification Presentation
Cisco Unified Communications Manager includes the calling line (or number) and name presentation information in the From and Remote-Party-ID headers of the initial INVITE message from Cisco Unified Communications Manager. The From header field indicates the initiator of the request. Cisco Unified Communications Manager uses Remote-Party-ID headers in 18x, 200 and re-INVITE messages to convey connected name and identification information. The Remote-Party-ID header also gives detailed descriptions of caller identity and privacy. Cisco Unified Communications Manager sets the Party field of the Remote-Party-ID header to calling for calling ID services.
Note
Example:
Bob Jones (with external phone number=8005550100) dials out to a SIP signaling interface; the From and Remote-Party-ID headers contain
From: "Bob Jones" <sip:8005550100@localhost>Remote-Party-ID: "Bob Jones"<8005550100@localhost; user=phone>; party=calling;screen=no;privacy=offCalling Line and Name Identification Restriction
Calling line (or number) and name restrictions configuration occurs on the SIP signaling interface level or on a call-by-call basis. The SIP trunk level configuration takes precedence over the call-by-call configuration. To configure on a call-by-call basis, refer to the Route Group Configuration in the Cisco Unified Communications Manager Administration Guide.
Calling line and name restrictions configuration also occurs independently of each other. For example, you may choose to restrict only numbers and allow names to be presented.
Example 1
With a restricted calling name, Cisco Unified Communications Manager sets the calling name in the From header to a configurable string. Cisco Unified Communications Manager sets the display field in the Remote-Party-ID header to include the actual name but sets the Privacy field to name:
From: "Anonymous" <sip:8005550100@localhost>Remote-Party-ID: "Bob Jones"<sip:9728135001@localhost; ;user=phone>; party=calling;screen=no;privacy=nameExample 2
With a restricted calling number, Cisco Unified Communications Manager leaves out the calling line in the From header; however, Cisco Unified Communications Manager still includes the calling line in the Remote-Party-ID header but sets the Privacy field to privacy=uri:
From: "Bob Jones" <sip:@localhost>Remote-Party-ID: "Bob Jones"<sip:8005550100@localhost; ;user=phone>; party=calling;screen=no;privacy=uriExample 3
With a restricted calling name and number, Cisco Unified Communications Manager sets the Privacy field to privacy=full in the Remote-Party-ID header:
From: "Anonymous" <sip:localhost>Remote-Party-ID: "Bob Jones"<sip:8005550100@localhost;user=phone>; party=calling;screen=no;privacy=fullConnected Line and Name Identification Presentation
Cisco Unified Communications Manager uses connected line and name identification as a supplementary service to provide the calling party with the connected party number and name. The From header field indicates the initiator of the request. Cisco Unified Communications Manager uses Remote-Party-ID headers in 18x, 200, and re-INVITE messages to convey connected information. Cisco Unified Communications Manager sets the Party field of Remote-Party-ID header to called.
Example 1
Cisco Unified Communications Manager receives an INVITE message with a destination address of 800555. Cisco Unified Communications Manager includes the connected party name in 18x and 200 messages as follows:
Remote-Party-ID: "Bob Jones"<98005550100@localhost; user=phone>; party=called;screen=no;privacy=offConnected Line and Name Identification Restriction
You can configure connected line (or number) and name restrictions on the SIP trunk level or on a call-by-call basis. The SIP trunk level configuration takes precedence over the call-by-call configuration. To configure on a call-by-call basis, refer to the Route Group Configuration in the Cisco Unified Communications Manager Administration Guide.
Similar to Calling ID services, users can restrict connected number and name independently of each other.
Example 1
Cisco Unified Communications Manager sets the display field in the Remote-Party-ID header to include the actual name but sets the Privacy field to privacy=name:
Remote-Party-ID: "Bob Jones"<8005550100@localhost; user=phone>; party=called;screen=no;privacy=nameExample 2
With a restricted connected number, Cisco Unified Communications Manager still includes the connected number in the Remote-Party-ID header but sets the Privacy field to privacy=uri:
Remote-Party-ID: "Bob Jones"<8005550100@localhost; user=phone>; party=called;screen=no;privacy=uriExample 3
With a restricted connected name and number, Cisco Unified Communications Manager sets the Privacy field to privacy=full in the Remote-Party-ID header:
Remote-Party-ID: "Bob Jones"<8005550100@localhost; user=phone>; party=called;screen=no;privacy=fullRedirecting Dial Number Identification Service (RDNIS)
Cisco Unified Communications Manager uses the SIP Diversion header in the initial INVITE message to carry available RDNIS information.
Redirection
The following scenario represents the behavior that you will get if the Redirect by Application check box on the SIP Profile Configuration window is unchecked. Previously, the redirection from the SIP network got handled at the SIP stack level, and the system accepted and forwarded all redirection requests to the contacts in the redirection response out to the same trunk on which the redirection response was received. No consulting or applying of any additional logic to handle or restrict how the call is redirected occurred. For example, if the redirection contact in a 3xx response to an outgoing INVITE was a Cisco Unified Communications Manager registered phone and the stack is handling redirection, the call gets redirected back out over the same trunk instead of being routed directly to the Cisco Unified Communications Manager phone. Getting redirected to a restricted phone number (such as an international number) means that handling redirection at the stack level will cause the call to be routed instead of being blocked.
Checking the Redirect by Application check box that is on the SIP Profile Configuration window and configuring this option on the SIP trunk allows the Cisco Unified Communications Manager administrator to
•
•
•
•
For more information, see the "SIP Profile Configuration Settings" section on page 92-3 and "Trunk Configuration" in the Cisco Unified Communications Manager Administration Guide.
SIP PUBLISH
SIP PUBLISH provides the preferred mechanism for Cisco Unified Communications Manager Release 6.0 to send IP phone presence information to Cisco Unified Presence (CUP) Release 6.0 over a SIP trunk because it provides improved performance. PUBLISH also provides presence information on a line basis; for example, for do not disturb and mobility. Only outbound PUBLISH gets supported. (Cisco Unified Communications Manager Release 5.0 and 6.0 use SUBSCRIBE/NOTIFY for presence when communicating to CUP release 1.0.)
PUBLISH represents a SIP method for event state publication. RFC 3903 provides a framework for the publication of event state from a user agent to an entity that is responsible for the composition of this event state and distributing it to interested parties through the SIP Events framework. The mechanism that is described in RFC 3903 can extend to support publication of any event state for which an appropriate event package exists.
In addition, RFC 3903 defines a concrete usage of that framework for the publication of presence state by a presence user agent to a presence compositor.
SIP trunk works with CUPS to provide the presence information for the Cisco Unified Communications Manager registered phones. In release 5.0, CUP collected the presence information from Cisco Unified Communications Manager through the SIP subscription mechanism.
The Cisco Unified Communications Manager to CUP presence interaction works properly when the SIP subscription mechanism is used; however, this mechanism brings some performance concerns. Both Cisco Unified Communications Manager and CUP must maintain a separate subscription dialog for each phone that is being watched. Moreover, if a phone is interested by two different users, and each user has a different watch rule, CUP will issue two different SUBSCRIBE requests to the Cisco Unified Communications Manager SIP trunk for the same number.
In Cisco Unified Communications Manager Release 6.0, a SIP trunk can use PUBLISH as the mechanism for the presence interaction with CUP. Cisco Unified Communications Manager acts as the Event Publication Agent (EPA), publishing the presence information of its managed phones; CUP acts as the Event State Compositor (ESC), receiving the published presence information, aggregating it, and updating the watcher phone displays accordingly.
Cisco Unified Communications Manager and Cisco Unified Presence (CUP) High-Level Architecture Overview
Figure 35-4 shows how Cisco Unified Communications Manager, CUP, and Cisco Unified IP Phones work together.
•
•
•
Figure 35-4 SIP PUBLISH High-Level Architecture
Cisco Unified Communications Manager Administration Configuration Tips for PUBLISH
The following configuration tips apply to Cisco Unified Communications Manager Administration when a SIP trunk is configured for PUBLISH:
•
Tip
•
•
•
Note
•
•
•
•
Service Parameters for PUBLISH
The following Cisco CallManager service parameters get used to configure PUBLISH:
•
•
•
•
•
Serviceability Performance Counters
Cisco Unified Serviceability collects and displays the following PUBLISH-related performance counters:
•
•
•
•
The following performance counters exist in Cisco Unified Communications Manager Release 5.0, but the PUBLISH feature impacts their values:
•
•
•
Security Recommendations
RFC 3903 suggests the use of TLS and digest authentication against issues such as Access Control, Denial of Service Attacks, Replay Attacks, and Man in the Middle Attacks. Because Cisco Unified Communications Manager and Cisco Unified Presence support TLS and digest authentication, no changes occurred in release 6.0. The administrator can configure and enable TLS and digest authentication for Cisco Unified Communications Manager and Cisco Unified Presence. Additionally, you can use IPSec as an alternative to TLS.
BAT Support
The following BAT tools assist in migrating CUP users to Cisco Unified Communications Manager Release 6.0:
•
•
•
SIP Trunk Configuration Checklist
Table 35-8 provides an overview of the steps that are required to configure SIP trunk in Cisco Unified Communications Manager, along with references to related procedures and topics.
Configuration Considerations
Because Cisco Unified Communications Manager does not perform validation on your configuration, consider the following restrictions when you configure SIP trunks:
•
•
–
–
The Incoming Transport Protocol, Incoming Port, and X.509 Subject Name parameters get configured in SIP Trunk Security Profile Configuration in Cisco Unified Communications Manager Administration. Choose System > Security Profile > SIP Trunk Security Profile. This menu option yields the Find and List SIP Trunk Security Profile window. Use this window to search for existing SIP Trunk Security Profiles or click Add New to add a new profile.
The Destination Address and the selected SIP Trunk Security profile gets configured on the Trunk Configuration window in Cisco Unified Communications Manager. Choose Device > Trunk. This menu option yields the Find and List Trunks window. Use this window to search for existing trunks or click Add New to add a new trunk and choose SIP trunk as the Trunk Type.
The following example shows a valid configuration:
Trunk#1: Incoming Transport Protocol=TCP/UDP, Incoming Port=5060, Destination Address=10.10.10.1Trunk#2: Incoming Transport Protocol=TCP/UDP, Incoming Port=5060, Destination Address=10.10.10.2Trunk#3: Incoming Transport Protocol=TCP/UDP, Incoming Port=5080, Destination Address=10.10.10.1Trunk#4: Incoming Transport Protocol=TLS, Incoming Port=5061, X.509 Subject Name=my_ccm1, my_ccm2Trunk#5: Incoming Transport Protocol=TLS, Incoming Port=5061, X.509 Subject Name=my_ccm3Trunk#6: Incoming Transport Protocol=TLS, Incoming Port=5081, X.509 Subject Name=my_ccm_1The following example shows an invalid configuration:
Trunk#1: Incoming Transport Protocol=TCP/UDP, Incoming Port=5060, Destination Address=10.10.10.1Trunk#2: Incoming Transport Protocol=TCP/UDP, Incoming Port=5060, Destination Address=10.10.10.1Trunk#3: Incoming Transport Protocol=TLS, Incoming Port=5061, X.509 Subject Name=my_ccm1, my_ccm2Trunk#4: Incoming Transport Protocol=TLS, Incoming Port=5081, X.509 Subject Name=my_ccm2Trunk#5: Incoming Transport Protocol=TLS, Incoming Port=5061, X.509 Subject Name=my_ccm2Trunk#6: Incoming Transport Protocol=TLS, Incoming Port=5081, X.509 Subject Name=my_ccm2Trunk#7: Incoming Transport Protocol=TCP/UDP, Incoming Port=5060, Destination Address=myhost.domain.comTrunk #2 conflicts with Trunk #1 because the protocol, incoming port, and destination address are identical.
Trunk #5 conflicts with Trunk #3 because the protocol and incoming port are identical, and both trunks include my_ccm2 in their list of X.509 Subject Names.
Trunk #6 conflicts with Trunk #4 because the protocol, incoming port, and X.509 Subject Name are identical.
Trunk #7 conflicts with Trunk #1, because if myhost.domain.com resolves to 10.10.10.1, the protocol, incoming port, and destination address are identical.
Table 35-8 Trunk Configuration Checklist
Step 1
Create a SIP profile (optional).
Create a SIP trunk security profile (optional).
Create a SIP trunk.
Configure the destination address.
Configure the destination port.
Configuring SIP Profiles, Cisco Unified Communications Manager Administration Guide
Configuring a Trunk, Cisco Unified Communications Manager Administration Guide
Trunk Configuration Settings, Cisco Unified Communications Manager Administration Guide
Step 2
Associate the SIP trunk to a Route Pattern or Route Group.
SIP Route Pattern Configuration, Cisco Unified Communications Manager Administration Guide
Route Group Configuration, Cisco Unified Communications Manager Administration Guide
Route List Configuration, Cisco Unified Communications Manager Administration Guide
Step 3
Reset the SIP trunk.
Configuring a Trunk, Cisco Unified Communications Manager Administration Guide
Step 4
Configure SIP timers, counters, and service parameters, if necessary.
If using PUBLISH to communicate to a Cisco Unified Presence, choose the configured trunk in the CUP PUBLISH Trunk field of the Service Parameters Configuration window.
Service Parameters Configuration, Cisco Unified Communications Manager Administration Guide.
For specific configurable values, see the "SIP Timers and Counters" section.
Cisco Unified Communications Manager SIP Endpoints Overview
The Cisco Unified IP Phones 7911, 7941, 7961, 7970, and 7971 get deployed as a SIP endpoint in a Cisco Unified Communications Manager Back to Back User Agent (B2BUA) environment. The SIP protocol provides the primary interface between the phone and other network components. In addition to SIP, other protocols get used for various functions such as DHCP for IP address assignment, DNS for domain name to address resolution, and TFTP for downloading image and configuration data.
This section provides an example illustration and brief description of the B2BUA and peer-to-peer environments.
Note
Figure 35-5 Cisco Unified Communications Manager B2BUA Network
Figure 35-5 shows a simplified example of a Cisco Unified Communications Manager B2BUA network that shows a main site and a branch office deployment. Each site includes a mixture of SIP and SCCP phones. The main site contains the Cisco Unified Communications Manager cluster and Voice Mail server. Each phone at the main site and the branch office site homes to a set of primary, secondary, and tertiary Cisco Unified Communications Managers. This provides redundancy of call control in the event of the failure of an individual Cisco Unified Communications Manager server.
SIP phones at the main site direct all session invitations to Cisco Unified Communications Manager. Based on routing configuration and destination, Cisco Unified Communications Manager will either extend a call locally to another SIP or SCCP phone, through the main site voice gateway across the IP WAN to one of the phones in the branch office, or through the main site voice gateway to the PSTN. Calls originating from phones in the branch office get routed similarly with the added ability of routing calls to the PSTN through the branch office voice gateway.
The branch office includes an SRST gateway that is deployed for access to the main site IP WAN and for PSTN access. SIP phones in the branch office will direct all session invitations to the Cisco Unified Communications Manager at the main site. Similarly to the phones at the main site, Cisco Unified Communications Manager may extend the call to a phone at the main site, through the main site voice gateway across the IP WAN to a phone in the branch office, or to the PSTN. Depending on the routing configuration of the Cisco Unified Communications Manager cluster, PSTN calls that originate from the phones in the branch office can get routed to the PSTN through the gateway at the main site, or they can be routed locally to the PSTN through the branch office gateway.
The SRST gateway also acts as a backup call control server in the event of an IP WAN outage. Both the SIP and SCCP phones will fail over to the SRST gateway during a WAN failure. By doing so, the phones in the branch office can have their calls routed by the SRST gateway. This includes calls that originate and terminate within the branch office and calls that originate and terminate in the PSTN.
SIP Line Side Overview
The SIP line side feature affects Cisco Unified Communications Manager architecture, the TFTP server, and the Cisco Unified IP Phones. The SIP phone features, which are equivalent to the SCCP phone features, behave similarly. Cisco Unified IP Phones 7941/61/71/70/11 support all features and most CTI applications. Cisco Unified IP Phones 7905/12/40/60 support a reduced feature set (for example, limited MOH and failover capabilities). SIP trunk side applications work for both SCCP and SIP phones.
For detailed information on the SIP phone features capabilities, refer to the user guide for the specific Cisco IP SIP Phone.
SIP Standards
The following SIP standards get supported in Cisco Unified Communications Manager:
•
•
•
•
RFC3261, RFC3262 (PRACK), RFC3264 (offer/answer), RFC3311 (UPDATE), 3PCC
This SIP standard supports the following Cisco Unified Communications Manager features:
•
•
•
•
•
•
•
•
•
•
•
•
RFC3515 (REFER) also Replaces and Referred-by Headers
These SIP standards support the following Cisco Unified Communications Manager features:
•
•
•
Remote Party Id (RPID) Header
This SIP standard supports the following Cisco Unified Communications Manager features:
•
•
•
•
RPID represents a SIP header that is used for identification services. RPID indicates the calling, called, and connected remote party information to the other party for identification and call-back, legal intercept, indication of user identification and user location to emergency services, and the identification of users for accounting and billing services.
Diversion Header
This SIP standard supports the following Cisco Unified Communications Manager features:
•
•
Replaces Header
This SIP standard supports the following Cisco Unified Communications Manager feature:
•
Join Header
This SIP standard supports the following Cisco Unified Communications Manager feature:
•
RFC3265 + Dialog Package
This SIP standard supports the following Cisco Unified Communications Manager feature:
•
RFC3265 + Presence Package
These SIP standards support the following Cisco Unified Communications Manager features:
•
•
RFC3265 + KPML Package
These SIP standards support the following Cisco Unified Communications Manager features:
•
•
RFC3265 + RFC3842 MWI Package (unsolicited notify)
These SIP standards support the following Cisco Unified Communications Manager feature:
•
Remotecc
This SIP standard supports the following Cisco Unified Communications Manager features:
•
•
•
•
•
•
•
RFC4028 Session Timers
This SIP standard allows periodic refresh of the SIP sessions through re-INVITE and allows Cisco Unified Communications Manager to determine whether the signalling connection to the remote is still active.
Cisco Unified Communications Manager Functionality That Is Supported by SIP Phones
The following Cisco Unified Communications Manager functions get supported on Cisco Unified IP Phones:
•
Dial Plans
Unlike the SCCP phones, the SIP phones collect digits locally before sending them to Cisco Unified Communications Manager. The SIP phones use a local dial plan to know when enough digits have been entered and to trigger an INVITE with the collected digits. SIP phones that are in SRST mode will continue to use any configured dial plans that they receive from Cisco Unified Communications Manager. See SIP Dial Rules, page 17-4, for more information.
Do Not Disturb
Cisco Unified Communications Manager supports do not disturb (DND) that a SIP device initiates or that a Cisco Unified Communications Manager device initiates. A DND status change gets signaled from a SIP device to Cisco Unified Communications Manager that is using the SIP PUBLISH method. A DND status change gets signaled from a Cisco Unified Communications Manager to a SIP device that is using a dndupdate Remote-cc REFER request. Cisco Unified Communications Manager can also publish the do not disturb status for a device, along with the busy and idle status for the device.
PLAR
Private Line Automatic Ringdown (PLAR), a term that is used by traditional telephony systems, refers to a phone configuration whereby any time the user goes off hook, the phone immediately dials a preconfigured number. The user cannot dial any other numbers from that phone (or line). This gets implemented in SCCP IP phones in Cisco Unified Communications Manager by using partitions, calling search space (CSS), and translation patterns; neither the device configuration nor line configuration indicates that PLAR is set up for the phone.
Administrators use SIP Dial Rules for configuring PLAR in SIP phones. Phones that are configured for PLAR will have a one-line dial plan configuration that specifies the appropriate target pattern. When the user goes off hook, the phone will populate the INVITE with the target string and immediately send the request to Cisco Unified Communications Manager. The user does not enter any digits. See Configuring SIP Dial Rules, page 34-3, for more information.
Softkey Handling
The administrator uses Cisco Unified Communications Manager Administration to modify the softkey sets that the phone displays. You can add and remove keys, and their positions can get changed. This data gets written to the database and gets sent to the SCCP phone via Station messages as part of the phone registration/initialization process. For Cisco Unified IP Phones that support SIP, however, instead of sending the keys in Station Messages, the Cisco Unified Communications Manager TFTP server builds the file that contains the softkey sets. The SIP phone retrieves these files from the TFTP server, and the new softkey sets overwrite the softkey sets that are built into the phone. This allows Cisco Unified Communications Manager to modify the default softkeys and also lets Cisco Unified Communications Manager manipulate the softkey events, so it can directly control some phone-level features.
For features that are configured by using the Softkey Configuration window but are not supported by the SIP phone, the softkey will display, but the phone will display a message that the key is not active, which is consistent with the SCCP phone behavior.
The Dial softkey appears as part of the default softkey set when the SIP phone is operating in SRST mode.
Note
DSCP Configuration
Cisco Unified IP Phones that are running SIP get their DSCP information from the configuration file that gets downloaded to the device. The DSCP setting applies for the device, whereas, the SCCP phones can get the DSCP setting for a call. DSCP values get configured in the Enterprise Parameters Configuration window, and in the Cisco Unified Communications Manager Service Parameters Configuration window.
SIP Profiles for Endpoints
Because SIP attributes rarely change, Cisco Unified Communications Manager uses SIP profiles to define SIP attributes that are associated with SIP trunks and Cisco Unified IP Phones. Having these attributes in a profile instead of adding them individually to every SIP trunk and SIP phone decreases the amount of time administrators spend configuring SIP devices and allows the administrator to change the values for a group of devices. Because the SIP profile is a required field when SIP trunks and phones are configured, Cisco Unified Communications Manager provides a default SIP; however, administrators can create customized SIP profiles. SIP profiles get assigned to SIP devices by using Cisco Unified Communications Manager Administration.
The software on the SIP phone uses the majority of SIP values that are sent via TFTP to the phones.
For information on configuring SIP profiles, see "Configuring SIP Profiles" in the Cisco Unified Communications Manager Administration Guide.
Network Time Protocol (NTP)
You can configure phone Network Time Protocol (NTP) references in Cisco Unified Communications Manager Administration to ensure that a Cisco Unified IP Phone that is running SIP gets its date and time from the NTP server. If all NTP servers do not respond, the SIP phone uses the date header in the 200 OK response to the REGISTER message for the date and time.
After you add the phone NTP reference to Cisco Unified Communications Manager Administration, you must add it to a date/time group. In the date/time group, you prioritize the phone NTP references, starting with the first server that you want the phone to contact.
The date/time group configuration gets specified in the device pool, and the device pool gets specified on the phone page.
For information on configuring the NTP reference, refer to the "Phone NTP Reference Configuration" chapter in the Cisco Unified Communications Manager Administration Guide.
CTI Support
Line-side SIP includes CTI functionality, which allows CTI applications such as Cisco Unified Communications Manager Assistant to support Cisco Unified IP Phones that are running SIP (for example, Cisco Unified IP Phone 7961). CTI capabilities on SIP phones equate to those on SCCP phones with a few exceptions. Some CTI features that are supported on SIP phones include display text, set lamp, play tone, call park, and privacy support. For more information about CTI and Cisco Unified Communications Manager, see Computer Telephony Integration.
Where to Find More Information
Additional Cisco Documentation
•
Related Topics
•
•
•
•
•
•
•
•
•
•
•
