AS-SIP Overview
Assured Services SIP (AS-SIP) endpoints are compliant with MLPP, DSCP, TLS/SRTP, and IPv6 requirements. AS-SIP provides for multiple endpoint interfaces on the Unified Communications Manager.
Many Cisco IP phones support AS-SIP. In addition, the Third-Party AS-SIP Endpoint device type allows a third-party AS-SIP compliant endpoint to be configured and used with Cisco Unified Communications Manager. In addition, the Third-Party AS-SIP Endpoint device type allows a third-party AS-SIP-compliant generic endpoint to be configured and used with Cisco Unified Communications Manager
AS-SIP Capabilities
The following capabilities are implemented or made available for AS-SIP endpoints:
-
MLPP
-
TLS
-
SRTP
-
DSCP for precedence levels
-
Error responses
-
V.150.1 MER
-
Conference Factory flow support
-
AS-SIP Line Early Offer
Third-Party AS-SIP Phones
Third-party phones can be provisioned in Cisoc Unified Communications Manager using the Third-Party AS-SIP Endpoint device type.
Third-party phones that are running AS-SIP do not get configured through the Cisco Unified Communications Manager TFTP server. The customer must configure them by using the native phone configuration mechanism (usually a web page or TFTP file). The customer must keep the device and line configuration in the Cisco Unified Communications Manager database synchronized with the native phone configuration (for example, extension 1002 on the phone and 1002 in Cisco Unified Communications Manager). Also, if the directory number of a line is changed, the customer must ensure that it gets changed in both Cisco Unified CM Administration and in the native phone configuration mechanism.
Identification of Third-Party Phones
The third-party phones that are running SIP do not send a MAC address, they must identify themselves by using username. The REGISTER message includes the following header:
Authorization: Digest
username=”swhite”,realm=”ccmsipline”,nonce=”GBauADss2qoWr6k9y3hGGVDAqnLfoLk5”,uri =”sip:172.18.197.224”,
algorithm=MD5,response=”126c0643a4923359ab59d4f53494552e”
The username, swhite, must match a user that is configured in the End User Configuration window of Cisco Unified CM Administration. The administrator configures the SIP third-party phone with the user; for example, swhite, in the Digest User field of Phone Configuration window.
Note |
You can assign each user ID to only one third-party phone. If the same user ID is assigned as the Digest User for multiple phones, the third-party phones to which they are assigned will not successfully register. |
Configuration of Third Party AS-SIP Phones and Cisco IP Phones
The following table provides a comparison overview of the configuration differences between Cisco Unified IP Phones and third-party phones that are running AS-SIP.
Phone Running AS-SIP | Integrated with Centralized TFTP | Sends MAC Address | Downloads Softkey File | Downloads Dial Plan File | Supports Unified Communications Manager Failover and Fallback | Supports Reset and Restart |
---|---|---|---|---|---|---|
Cisco IP Phone | Yes | Yes | Yes | Yes | Yes | Yes |
Third-party AS-SIP device | No | No | No | No | No | No |
Note |
Not all Cisco IP Phones support AS-SIP. See the phone administration guide for your phone model for support information |
Use Cisco Unified CM Administration to configure third-party phones that are running SIP (For more information, see "Configure SIP Profile" topic in System Configuration Guide for Cisco Unified Communications Manager
the ). The administrator must perform configuration steps on the third-party phone that is running SIP; see the following examples:
-
Ensure that proxy address in the phone is the IP or Fully Qualified Domain Name (FQDN) of Cisco Unified Communications Manager.
-
Ensure directory numbers in the phone match the directory numbers that are configured for the device in Cisco Unified CM Administration.
-
Ensure digest user ID (sometimes referred to as Authorization ID) in the phone matches the Digest User ID in the Cisco Unified CM Administration.
For more information, refer to the documentation that came with the third-party phone.
AS-SIP Conferencing
MOH is applied to its target (a held party, transferee just before transfer, or conferee just before joining the conference), if the feature invoker (holder, transferor, or conference initiator) supports Cisco-proprietary feature signaling. If the feature invoker does not support Cisco-proprietary feature signaling, then MOH is not applied to its target. Also, if an endpoint explicitly signals that it is a conference mixer, then MOH will not be played to the target. There are two forms of AS-SIP Conferencing:
-
Local mixing
-
Conference Factory
Local mixing
To the Unified CM, the conference initiator simply appears to have established simultaneously active calls, one to each of the other conference attendees. The initiator host the conference locally and the voices are mixed there. The calls from the conference initiator have special signaling that prevent it from being connected to an MOH source.
Conference Factory
The conference initiator calls a Conference Factory Server located off a SIP trunk. Through IVR signaling, the conference initiator instructs the Conference Factory to reserve a conference bridge. The Conference Factory gives the numeric address (a routable DN) to the conference initiator, who then establishes a subscription with the bridge to receive conference list information to track the participants. The Conference Factory sends special signaling that prevent it from being connected to an MOH Source.