The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
Upon deployment of a new IP telephony system, system administrators and network administrators must complete several initial configuration tasks to prepare the network for IP telephony service.
For the phone to operate successfully as an endpoint in your network, your network must meet specific requirements.
Note | The phone displays the date and time from Third-Party Call Control. The time displayed on the phone can differ from the Third-Party Call Control time by up to 10 seconds. |
After the phone connects to the network, the phone startup process begins, and the phone registers with Third-party Call Control System . You need to configure the network settings on the phone if you disable the DHCP service.
If you used autoregistration, you need to update the specific configuration information for the phone such as associating the phone with a user, changing the button table, or directory number.
After the phone connects, it determines if a new firmware load should be installed on the phone.
Step 1 | Choose the power source for the phone:
For more information, see Ways to Provide Power to Your Conference Phone. |
Step 2 | Connect the phone to the switch.
Each phone ships with one Ethernet cable in the box. |
Step 3 | Monitor the phone startup process. This step verifies that the phone is configured properly. |
Step 4 | If you do not use autoregistration, manually configure the network settings on the phone. |
Step 5 | Make calls with the phone to verify that the phone and features work correctly. |
Step 6 | Provide information to end users about how to use their phones and how to configure their phone options. This step ensures that users have adequate information to successfully use their Cisco phones. |
Your conference phone needs power from one of these sources:
The following figure shows the PoE and midspan cable power options.
The phone includes many configurable network settings that you may need to modify before it is functional for your users. You can access these setting through the phone menus.
The Network configuration menu provides you with options to view and configure a variety of network settings.
You can configure settings that are display-only on the phone in your Third-Party Call Control system.
When you edit the value of an option setting, follow these guidelines:
Use the arrows on the navigation pad to highlight the field that you wish to edit. Press Select in the navigation pad to activate the field. After the field is activated, you can enter values.
Use the keys on the keypad to enter numbers and letters.
To enter letters by using the keypad, use a corresponding number key. Press the key one or more times to display a particular letter. For example, press the 2 key once for "a," twice quickly for "b," and three times quickly for "c." After you pause, the cursor automatically advances to allow you to enter the next letter.
Press the softkey if you make a mistake. This softkey deletes the character to the left of the cursor.
Press Revert before pressing Apply to discard any changes that you made.
To enter a period (for example, in an IP address), press * on the keypad.
Note | The Cisco IP Phone provides several methods to reset or restore option settings, if necessary. |
After the Cisco IP Phone has power connected to it, the phone automatically cycles through a startup diagnostic process.
A codec resource is considered allocated if it has been included in the SDP codec list of an active call, even though it eventually might not be chosen for the connection. Negotiation of the optimal voice codec sometimes depends on the ability of the Cisco IP Phone to match a codec name with the far-end device or gateway codec name. The phone allows the network administrator to individually name the various codecs that are supported such that the correct codec successfully negotiates with the far-end equipment.
The Cisco IP Phone supports voice codec priority. You can select up to three preferred codecs. The administrator can select the low-bit-rate codec that is used for each line. G.711a and G.711u are always enabled.
If you use a virtual LAN (VLAN), your phone voice packets are tagged with the VLAN ID.
In the VLAN Settings section of the Voice > System window, you can configure these settings:
Cisco Discovery Protocol (CDP) is negotiation-based and determines which virtual LAN (VLAN) the Cisco IP Phone resides in. If you are using a Cisco switch, Cisco Discovery Protocol (CDP) is available and is enabled by default. CDP has these attributes:
If you are using a VLAN without CDP, you must enter a VLAN ID for the Cisco IP Phone.
The Cisco IP Phone supports Link Layer Discovery Protocol for Media Endpoint Devices (LLDP-MED) for deployment with Cisco or other Third-Party network connectivity devices that use a Layer 2 auto discovery mechanism. Implementation of LLDP-MED is done in accordance with IEEE 802.1AB (LLDP) Specification of May 2005, and ANSI TIA-1057 of April 2006.
The Cisco IP Phone operates as a LLDP-MED Media End Point Class III device with direct LLDP-MED links to Network Connectivity Devices, according to the Media Endpoint Discovery Reference Model and Definition (ANSI TIA-1057 Section 6).
The Cisco IP Phone supports only the following limited set of Type-Length-Values (TLV) as an LLDP-MED Media Endpoint device class III:
IEEE 802.3 MAC/PHY Configuration/Status TLV (for wired network only)
LLDP-MED Network Policy TLV (for application type=Voice only)
LLDP-MED Extended Power-Via-MDI TLV (for wired network only)
The outgoing LLDPDU contains all the preceding TLVs if applicable. For the incoming LLDPDU, the LLDPDU is discarded if any of the following TLVs are missing. All other TLVs are not validated and ignored.
The Cisco IP Phone sends out the shutdown LLDPDU if applicable. The LLDPDU frame contains the following TLVs:
There are some restrictions in the implementation of LLDP-MED on the Cisco IP Phones:
Storage and retrieval of neighbor information are not supported.
Recording and retrieval of statistical counters are not supported.
Full validation of all TLVs does not take place; TLVs that do not apply to the phones are ignored.
Protocol state machines as stated in the standards are used only for reference.
For the outgoing LLDPDU, the TLV supports subtype=5 (Network Address). When the IP address is known, the value of the Chassis ID is an octet of the INAN address family number followed by the octet string for the IPv4 address used for voice communication. If the IP address is unknown, the value for the Chassis ID is 0.0.0.0. The only INAN address family supported is IPv4. Currently, the IPv6 address for the Chassis ID is not supported.
For the incoming LLDPDU, the Chassis ID is treated as an opaque value to form the MSAP identifier. The value is not validated against its subtype.
The Chassis ID TLV is mandatory as the first TLV. Only one Chassis ID TLV is allowed for the outgoing and incoming LLDPDUs.
For the outgoing LLDPDU, the TLV supports subtype=3 (MAC address). The 6 octet MAC address for the Ethernet port is used for the value of Port ID.
For the incoming LLDPDU, the Port ID TLV is treated as an opaque value to form the MSAP identifier. The value is not validated against its subtype.
The Port ID TLV is mandatory as the second TLV. Only one Port ID TLV is allowed for the outgoing and incoming LLDPDUs.
For the outgoing LLDPDU, the Time to Live TTL value is 180 seconds. This differs from the 120-second value that the standard recommends. For the shutdown LLDPDU, the TTL value is always 0.
The Time to Live TLV is mandatory as the third TLV. Only one Time to Live TLV is allowed for the outgoing and incoming LLDPDUs.
The value is 2-octet, all zero. This TLV is mandatory and only one is allowed for the outgoing and incoming LLDPDUs.
For the outgoing LLDPDU, in the Port Description TLV, the value for the port description is the same as “Port ID TLV” for CDP. The incoming LLDPDU, the Port Description TLV, is ignored and not validated. Only one Port Description TLV is allowed for outgoing and incoming LLDPDUs.
For the Cisco IP Phone, the value is SEP+MAC address.
The incoming LLDPDU, the System Name TLV, is ignored and not validated. Only one System Name TLV is allowed for the outgoing and incoming LLDPDUs.
For the outgoing LLDPDU, in the System Capabilities TLV, the bit values for the 2 octet system capabilities fields should be set for Bit 2 (Bridge) and Bit 5 (Phone) for a phone with a PC port. If the phone does not have a PC port, only Bit 5 should be set. The same system capability value should be set for the enabled capability field.
For the incoming LLDPDU, the System Capabilities TLV is ignored. The TLV is not validated semantically against the MED device type.
The System Capabilities TLV is mandatory for outgoing LLDPDUs. Only one System Capabilities TLV is allowed.
The TLV identifies an address associated with the local LLDP agent (that may be used to reach higher layer entities) to assist discovery by network management. The TLV allows the inclusion of both the system interface number and an object identifier (OID) that are associated with this management address, if either or both are known.
The TLV allows the network management to advertise the system description.
TLV information string length—This field indicates the exact length (in octets) of the system description.
System description—This field contains an alphanumeric string that is the textual description of the network entity. The system description includes the full name and version identification of the system hardware type, software operating system, and networking software. If implementations support IETF RFC 3418, the sysDescr object should be used for this field.
The TLV is not for autonegotiation, but for troubleshooting purposes. For the incoming LLDPDU, the TLV is ignored and not validated. For the outgoing LLDPDU, for the TLV, the octet value autonegotiation support/status should be:
Bit 0—Set to 1 to indicate that the autonegotiation support feature is supported.
Bit 1—Set to 1 to indicate that autonegotiation status is enabled.
The bit values for the 2 octets PMD autonegotiation advertised capability field should be set to:
Bit 10, 11, 13 and 14 should be set.
The value for 2 octets operational MAU type should be set to reflect the real operational MAU type:
For example, usually, the phone is set to 100BASE-TX full duplex. The value 16 should then be set. The TLV is optional for a wired network and not applicable for a wireless network. The phone sends out this TLV only when in wired mode. When the phone is not set for autonegotiation but specific speed/duplexity, for the outgoing LLDPDU TLV, bit 1 for the octet value autonegotiation support/status should be clear (0) to indicate that autonegotiation is disabled. The 2 octets PMD autonegotiation advertised capability field should be set to 0x8000 to indicate unknown.
For the outgoing LLDPDU, the TLV should have the device type 3 (End Point Class III) with the following bits set for 2-octet Capability field:
Bit Position |
Capability |
---|---|
0 |
LLDP-MED Capabilities |
1 |
Network Policy |
For the incoming TLV, if the LLDP-MED TLV is not present, the LLDPDU is discarded. The LLDP-MED Capabilities TLV is mandatory and only one is allowed for the outgoing and incoming LLDPDUs. Any other LLDP-MED TLVs will be ignored if they present before the LLDP-MED Capabilities TLV.
In the TLV for the outgoing LLDPDU, before the VLAN or DSCP is determined, the Unknown Policy Flag (U) is set to 1. If the VLAN setting or DSCP is known, the value is set to 0. When the policy is unknown, all other values are set to 0. Before the VLAN is determined or used, the Tagged Flag (T) is set to 0. If the tagged VLAN (VLAN ID > 1) is used for the phone, the Tagged Flag (T) is set to 1. Reserved (X) is always set to 0. If the VLAN is used, the corresponding VLAN ID and L2 Priority will be set accordingly. VLAN ID valid value is range from 1-4094. However, VLAN ID=1 will never be used (limitation). If DSCP is used, the value range from 0-63 is set accordingly.
In the TLV for the incoming LLDPDU, Multiple Network Policy TLVs for different application types are allowed.
In the TLV for the outgoing LLDPDU, the binary value for Power Type is set to “0 1” to indicate the power type for phone is PD Device. The Power source for the phone is set to “PSE and local” with binary value “1 1”. The Power Priority is set to binary “0 0 0 0” to indicate unknown priority while the Power Value is set to maximum power value. The Power Value for the Cisco IP Phone is 12900mW.
For the incoming LLDPDU, the TLV is ignored and not validated. Only one TLV is allowed in the outgoing and incoming LLDPDUs. The phone will send out the TLV for the wired network only.
The LLDP-MED standard was originally drafted in the context of Ethernet. Discussion is ongoing for LLDP-MED for Wireless Networks. Refer to ANSI-TIA 1057, Annex C, C.3 Applicable TLV for VoWLAN, table 24. It is recommended that the TLV is not applicable in the context of the wireless network. This TLV is targeted for use in the context of PoE and Ethernet. The TLV, if added, will not provide any value for network management or power policy adjustment at the switch.
This TLV is optional for Device Class III. For the outgoing LLDPDU, we support only Firmware Revision TLV. The value for the Firmware Revision is the version of firmware on the phone. For the incoming LLDPDU, the TLVs are ignored and not validated. Only one Firmware Revision TLV is allowed for the outgoing and incoming LLDPDUs.
VLAN=0, VLAN=1, and VLAN=4095 are treated the same way as an untagged VLAN. Because the VLAN is untagged, Class of Service (CoS) is not applicable.
If there is no network policy from CDP or LLDP-MED, the default network policy is used. CoS is based on configuration for the specific extension. It is applicable only if the manual VLAN is enabled and manual VLAN ID is not equal to 0, 1, or 4095. Type of Service (ToS) is based on configuration for the specific extension.
If there is a valid network policy from CDP:
If the VLAN=0, 1, or 4095, the VLAN will not be set, or the VLAN is untagged. CoS is not applicable, but DSCP is applicable. ToS is based on the default as previously described.
If the VLAN > 1 and VLAN< 4095, the VLAN is set accordingly. CoS and ToS are based on the default as previously described. DSCP is applicable.
If CoS is applicable and if CoS=0, the default is used for the specific extension as previously described. But the value shown on L2 Priority for TLV for outgoing LLDPDU is based on the value used for extension 1. If CoS is applicable and if CoS!= 0, CoS is used for all extensions.
If DSCP (mapped to ToS) is applicable and if DSCP=0, the default is used for the specific extension as previously described. But the value show on DSCP for TLV for outgoing LLDPDU is based on value used for the extension 1. If DSCP is applicable and if DSCP!= 0, DSCP is used for all extensions.
If the VLAN > 1 and VLAN < 4095, the VLAN is set accordingly. CoS and ToS are based on the default as previously described. DSCP is applicable.
If there is a valid network policy for the voice application from LLDP-MED PDU and if the tagged flag is set, the VLAN, L2 Priority (CoS), and DSCP (mapped to ToS) are all applicable.
If there is a valid network policy for the voice application from LLDP-MED PDU and if the tagged flag is not set, only the DSCP (mapped to ToS) is applicable.
The Cisco IP Phone reboots and restarts the fast start sequence.
If both CDP and LLDP-MED are enabled, the network policy for the VLAN determines the last policy set or changed with either one of the discovery modes. If both LLDP-MED and CDP are enabled, during startup the phone sends both CDP and LLDP-MED PDUs at the same time.
Inconsistent configuration and behavior for network connectivity devices for CDP and LLDP-MED modes could result in an oscillating rebooting behavior for the phone due to switching to different VLANs.
If the VLAN is not set by CDP and LLDP-MED, the VLAN ID that is configured manually is used. If the VLAN ID is not configured manually, no VLAN is supported. DSCP is used and the network policy determines LLDP-MED if applicable.
You can use the same application type for network policy. However, phones receive different Layer 2 or Layer 3 QoS Network policies from multiple network connectivity devices. In such a case, the last valid network policy is accepted.
The Cisco IP Phone does not support IEEE 802.X and does not work in a 802.1X wired environment. However, IEEE 802.1X or Spanning Tree Protocols on network devices could result in delay of fast start response from switches.
The Cisco IP Phone uses Session Initiation Protocol (SIP), which allows interoperation with all IT service providers that support SIP. SIP is an IETF-defined signaling protocol that controls voice communication sessions in an IP network.
SIP handles signaling and session management within a packet telephony network. Signaling allows call information to be carried across network boundaries. Session management controls the attributes of an end-to-end call.
In typical commercial IP telephony deployments, all calls go through a SIP Proxy Server. The receiving phone is called the SIP user agent server (UAS), while the requesting phone is called the user agent client (UAC).
SIP message routing is dynamic. If a SIP proxy receives a request from a UAS for a connection but cannot locate the UAC, the proxy forwards the message to another SIP proxy in the network. When the UAC is located, the response routes back to the UAS, and the two UAs connect using a direct peer-to-peer session. Voice traffic transmits between UAs over dynamically assigned ports using Real-time Protocol (RTP).
RTP transmits real-time data such as audio and video; RTP does not guarantee real-time delivery of data. RTP provides mechanisms for the sending and receiving applications to support streaming data. Typically, RTP runs on top of UDP.
To guarantee state-oriented communications, the Cisco IP Phone can use TCP as the transport protocol for SIP. This protocol provides guaranteed delivery that assures that lost packets are retransmitted. TCP also guarantees that the SIP packages are received in the same order that they were sent.
TCP overcomes the problem of UDP port-blocking by corporate firewalls. With TCP, new ports do not need to be open or packets dropped, because TCP is already in use for basic activities, such as internet browsing or e-commerce.
An average SIP Proxy Server can handle tens of thousands of subscribers. A backup server allows an active server to be temporarily switched out for maintenance. Cisco phones support the use of backup SIP Proxy Servers to minimize or eliminate service disruption.
A static list of proxy servers is not always adequate. If your user agent serves different domains, for example, you do not want to configure a static list of proxy servers for each domain into every Cisco IP Phone.
A simple way to support proxy redundancy is to configure a SIP Proxy Server in the Cisco IP Phone configuration profile. The DNS SRV records instruct the phones to contact a SIP Proxy Server in a domain named in SIP messages. The phone consults the DNS server. If configured, the DNS server returns an SRV record that contains a list of SIP Proxy Servers for the domain, with their hostnames, priority, listening ports, and so forth. The Cisco IP Phone tries to contact the hosts in the order of their priority.
If the Cisco IP Phone currently uses a lower-priority proxy server, the phone periodically probes the higher-priority proxy and switches to the higher-priority proxy when available.
The phone always registers to both primary (or primary outbound) and alternate (or alternate outbound) proxies. After registration, the phone sends out Invite and Non-Invite SIP messages through primary proxy first. If there is no response for the new INVITE from the primary proxy, after timeout, the phone attempts to connect with the alternate proxy. If the phone fails to register to the primary proxy, it sends an INVITE to the alternate proxy without trying the primary proxy.
Dual registration is supported on a per-line basis. Three added parameters can be configured through web user interface and remote provisioning:
After you configure the parameters, reboot the phone for the feature to take effect.
Note | Specify a value for primary proxy (or primary outbound proxy) and alternate proxy (or alternate outbound proxy) for the feature to function properly. |
When Dual Registration is enabled, DNS SRV Proxy Fallback or Recovery must be disabled.
Do not use Dual Registration along with other Fallback or Recovery mechanisms. For example: Broadsoft mechanism.
There is no recovery mechanism for feature request. However, the administrator can adjust the reregistration time for a prompt update of the registration state for primary and alternate proxy.
When the Dual Register parameter is set to No, Alternate Proxy is ignored.
Failover—The phone performs a failover when transport timeout/failure or TCP connection failures; if Try Backup RSC and Retry Reg RSC values are datafilled.
Recovery—The phone attempts to reregister with the primary proxy while registered or actively connected to the secondary proxy.
Auto register when failover parameter controls the failover behavior when there is an error. When this parameter is set to yes, the phone re-registers upon failover or recovery.
The fallback occurs when the current registration expires or Proxy Fallback Intvl fires.
If the Proxy Fallback Intvl is exceeded, all the new SIP messages go to primary proxy.
For example, when the value for Register Expires is 3600 seconds and Proxy Fallback Intvl is 600 seconds, the fallback triggers 600 seconds later.
When the value for Register Expires is 800 seconds and Proxy Fallback Intvl is 1000 seconds, the fallback triggers at 800 seconds.
After successful registration back to the primary server, all SIP messages go to the primary server.
The Cisco IP Phone supports RFC-3311, the SIP UPDATE Method.
The Cisco IP Phone supports the SIP NOTIFY XML-Service event. On receipt of a SIP NOTIFY message with an XML-Service event, the phone challenges the NOTIFY with a 401 response if the message does not contain correct credentials. The client must furnish the correct credentials using MD5 digest with the SIP account password for the corresponding line of the IP phone.
The body of the message can contain the XML event Message. For example:
<CiscoIPPhoneExecute> <ExecuteItem Priority="0" URL="http://xmlserver.com/event.xml"/> </CiscoIPPhoneExecute>
challenge = MD5( MD5(A1) ":" nonce ":" nc-value ":" cnonce ":" qop-value ":" MD5(A2) ) where A1 = username ":" realm ":" passwd and A2 = Method ":" digest-uri
SIP settings for the Cisco IP Phone are configured for the phone in general and for the extensions.
Step 1 | In the phone web user interface, navigate to . |
Step 2 | In the SIP Parameters section, set the SIP parameters as described in the SIP Parameters table. |
Step 3 | Click Submit All Changes. |
Step 1 | In the phone web user interface, navigate to . |
Step 2 | In the SIP Timer Values section, set the SIP timer values in seconds as described in the SIP Timer Values table. |
Step 3 | Click Submit All Changes. |
Step 1 | In the phone web user interface, navigate to . |
Step 2 | In the Response Status Code Handling section, set the values as specified:
|
Step 3 | Click Submit All Changes. |
Step 1 | In the phone web user interface, navigate to . |
Step 2 | In the RTP Parameters section, set the Real-Time Transport Protocol (RTP) parameter values as described in the RTP Parameters table. |
Step 3 | Click Submit All Changes. |
Configured dynamic payloads are used for outbound calls only when the Cisco IP Phone presents a Session Description Protocol (SDP) offer. For inbound calls with an SDP offer, the phone follows the caller’s assigned dynamic payload type.
The Cisco IP Phone uses the configured codec names in outbound SDP. For incoming SDP with standard payload types of 0-95, the phone ignores the codec names. For dynamic payload types, the phone identifies the codec by the configured codec names (comparison is case-sensitive).
Step 1 | In the phone web user interface, navigate to . |
Step 2 | In the SDP Payload Types section, set the value as specified in the SDP Payload Types table. |
Step 3 | Click Submit All Changes. |
Step 1 | In the phone web user interface, navigate to , where n is an extension number. |
Step 2 | In the SIP Settings section, set the parameter values as described in the SIP Settings table. |
Step 3 | Click Submit All Changes. |
Step 1 | In the phone web user interface, navigate to , where n is an extension number. |
Step 2 | In the Proxy and Registration section, set the parameter values as described in the Proxy and Registration table. |
Step 3 | Click Submit All Changes. |
Step 1 | In the phone web user interface, navigate to , where n is an extension number. |
Step 2 | In the Subscriber Information section, set the parameter values as described in the Subscriber Information table. |
Step 3 | Click Submit All Changes. |
Network Address Translation (NAT) allows multiple devices to share a single, public, routable, IP address to establish connections over the Internet. NAT is present in many broadband access devices to translate public and private IP addresses. For VoIP to coexist with NAT, NAT traversal is required.
Step 1 | On the Configuration Utility page, select . |
Step 2 | Set up the fields as described in the NAT Settings table. |
Step 3 | Click Submit All Changes . |
We recommend that you choose an service provider that supports NAT mapping through a Session Border Controller. With NAT mapping provided by the service provider, you have more choices in selecting a router.
NAT mapping can be achieved by using a router that has a SIP Application Layer Gateway (ALG). By using a SIP-ALG router, you have more choices in selecting an service provider.
You must have an external (public) IP address that is static .
The NAT mechanism used in the router must be symmetric. See Determining Symmetric or Asymmetric NAT
Use NAT mapping only if the service provider network does not provide a Session Border Controller functionality. To configure NAT mapping on the phone:
Step 1 | In the phone web user interface, navigate to . |
Step 2 | In the NAT Support Parameters section, set Handle VIA received, Insert VIA received, Substitute VIA Addr, Handle VIA rport, Insert VIA rport, Send Resp To Src Port fields to Yes. |
Step 3 | In the NAT Support Parameters section, set a value for the NAT Keep Alive Intvl field. |
Step 4 | Enter the public IP address for your router in the EXT IP field. |
Step 5 | Click the Ext(n) tab. |
Step 6 | In the NAT Settings section, set NAT Mapping Enable to Yes. |
Step 7 | (Optional) Set NAT Keep Alive Enable to Yes. The service provider might require the phone to send NAT keep alive messages to keep the NAT ports open. Check with your service provider to determine the requirements. |
Step 8 | Click Submit All Changes. |
Configure the firewall settings on your router to allow SIP traffic.
The router must use asymmetric NAT . See Determining Symmetric or Asymmetric NAT
A computer running STUN server software is available on the network. You can also use a public STUN server or set up your own STUN server.
Step 1 | In the phone web user interface, navigate to . |
Step 2 | In the NAT Support Parameters section, set Handle VIA received, Insert VIA received, Substitute VIA Addr, Handle VIA rport, Insert VIA rport, Send Resp To Src Port fields to Yes. |
Step 3 | In the NAT Support Parameters section, set STUN Enable field to Yes. |
Step 4 | Enter the IP address for your STUN server in the STUN Server field. |
Step 5 | Click the Ext(n) tab. |
Step 6 | In the NAT Settings section, set NAT Mapping Enable to Yes. |
Step 7 | (Optional) Set NAT Keep Alive Enable to Yes. The service provider might require the phone to send NAT keep alive messages to keep the NAT ports open. Check with your service provider to determine the requirements. |
Step 8 | Click Submit All Changes. |
Configure the firewall settings on your router to allow SIP traffic.
STUN does not work on routers with symmetric NAT. With symmetric NAT, IP addresses are mapped from one internal IP address and port to one external, routable destination IP address and port. If another packet is sent from the same source IP address and port to a different destination, a different IP address and port number combination is used. This method is restrictive because an external host can send a packet to a particular port on the internal host only if the internal host first sent a packet from that port to the external host.
This procedure assumes that a syslog server is configured and is ready to receive syslog messages.
To Determine Whether the Router Uses Symmetric or Asymmetric NAT:
Step 1 | Verify that the firewall is not running on your PC. (It can block the syslog port.) By default, the syslog port is 514. |
Step 2 | Click Voice>System and navigate to Optional Network Configuration. |
Step 3 | Enter the IP address for the Syslog Server, if the port number is anything
other than the default, 514. It is not necessary to include the port number if it is the
default.
The address and port number must be reachable from the Cisco IP phone. The port number appears on the output log file name. The default output file is syslog.514.log (if port number was not specified). |
Step 4 | Set the Debug Level to Error, Notice, or Debug. |
Step 5 | To capture SIP signaling messages, click the Ext tab and navigate to SIP Settings. Set the SIP Debug Option to Full. |
Step 6 | To collect information about what type of NAT your router uses click the SIP tab and navigate to NAT Support Parameters. |
Step 7 | Click Voice>SIP and navigate to NAT Support Parameters. |
Step 8 | Set STUN Test Enable to Yes. |
Step 9 | Determine the type of NAT by viewing the debug messages in the log file. If the messages indicate that the device is using symmetric NAT, you cannot use STUN. |
Step 10 | Click Submit All Changes. |
Dial plans determine how digits are interpreted and transmitted. They also determine whether the dialed number is accepted or rejected. You can use a dial plan to facilitate dialing or to block certain types of calls such as long distance or international.
Use the phone web user interface to configure dial plans on the IP phone.
This section includes information that you must understand about dial plans, and procedures to configure your own dial plans.
The Cisco IP Phone has various levels of dial plans and processes the digits sequence.
When a user presses the speaker button on the phone, the following sequence of events begins:
The phone begins to collect the dialed digits. The interdigit timer starts to track the time that elapses between digits.
If the interdigit timer value is reached, or if another terminating event occurs, the phone compares the dialed digits with the IP phone dial plan. This dial plan is configured in the phone web user interface in Voice > Ext(n) under the Dial Plan section.
A dial plan contains a series of digit sequences, separated by the | character. The entire collection of sequences is enclosed within parentheses. Each digit sequence within the dial plan consists of a series of elements that are individually matched to the keys that the user presses.
White space is ignored, but can be used for readability.
Digit Sequence |
Function |
---|---|
0 1 2 3 4 5 6 7 8 9 0 * # |
Characters that represent a key that the user must press the phone keypad. |
x |
Any character on the phone keypad. |
[sequence] |
Characters within square brackets create a list of accepted key presses. The user can press any one of the keys in the list. A numeric range, for example, [2-9] allows a user to press any one digit from 2 through 9. A numeric range can include other characters. For example, [35-8*] allows a user to press 3, 5, 6, 7, 8, or *. |
A period indicates element repetition. The dial plan accepts 0 or more entries of the digit. For example, 01. allows users to enter 0, 01, 011, 0111, and so forth. |
|
This format indicates that certain dialed digits are replaced by the substituted characters when the sequence is transmitted. The dialed digits can be zero to 9. For example: <8:1650>xxxxxxx When the user presses 8 followed by a seven-digit number, the system automatically replaces the dialed 8 with the sequence 1650. If the user dials 85550112, the system transmits 16505550112. If the dialed parameter is empty and there is a value in the substituted field, no digits are replaced and the substituted value is always prepended to the transmitted string. For example: <:1>xxxxxxxxxx When the user dials 9725550112, the number 1 is added at the beginning of the sequence; the system transmits 19725550112. |
|
An intersequence tone played (and placed) between digits plays an outside line dial tone. For example: 9, 1xxxxxxxxxx An outside line dial tone plays after the user presses 9. The tone continues until the user presses 1. |
|
Prohibits a dial sequence pattern. For example: 1900xxxxxxx! |
|
For Interdigit Timer Master Override, enter S0 to reduce the short interdigit timer to 0 seconds, or enter L0 to reduce the long interdigit timer to 0 seconds. |
|
To pause, enter P, the number of seconds to pause, and a space. This feature is typically used for implementation of a hotline and warm line, with a 0 delay for the hot line, and a nonzero delay for a warm line. For example: P5 |
The following examples show digit sequences that you can enter in a dial plan.
( [1-8]xx | 9, xxxxxxx | 9, <:1>[2-9]xxxxxxxxx | 8, <:1212>xxxxxxx | 9, 1 [2-9] xxxxxxxxx | 9, 1 900 xxxxxxx ! | 9, 011xxxxxx. | 0 | [49]11 )
( [1-8]xx | 9, xxxxxxx | 9, <:1>[2-9]xxxxxxxxx | 8, <:1212>xxxxxxx | 9, 1 [2-9] xxxxxxxxx | 9, 1 900 xxxxxxx ! | 9, 011xxxxxx. | 0 | [49]11 )
[1-8]xx Allows a user dial any three-digit number that starts with the digits 1 to 8. If your system uses four-digit extensions, enter the following string: [1-8]xxx
( [1-8]xx | 9, xxxxxxx | 9, <:1>[2-9]xxxxxxxxx | 8, <:1212>xxxxxxx | 9, 1 [2-9] xxxxxxxxx | 9, 1 900 xxxxxxx ! | 9, 011xxxxxx. | 0 | [49]111)
9, xxxxxxx After a user presses 9, an external dial tone sounds. The user can enter any seven-digit number, as in a local call.
( [1-8]xx | 9, xxxxxxx | 9, <:1>[2-9]xxxxxxxxx | 8, <:1212>xxxxxxx | 9, 1 [2-9] xxxxxxxxx | 9, 1 900 xxxxxxx ! | 9, 011xxxxxx. | 0 | [49]11 )
9, <:1>[2-9]xxxxxxxxx This example is useful where a local area code is required. After a user presses 9, an external dial tone sounds. The user must enter a 10-digit number that begins with a digit 2 through 9. The system automatically inserts the 1 prefix before it transmits the number to the carrier.
( [1-8]xx | 9, xxxxxxx | 9, <:1>[2-9]xxxxxxxxx | 8, <:1212>xxxxxxx | 9, 1 [2-9] xxxxxxxxx | 9, 1 900 xxxxxxx ! | 9, 011xxxxxx. | 0 | [49]11 )
8, <:1212>xxxxxxx This example is useful where a local area code is required by the carrier but most calls go to one area code. After the user presses 8, an external dial tone sounds. The user can enter any seven-digit number. The system automatically inserts the 1 prefix and the 212 area code before it transmits the number to the carrier.
( [1-8]xx | 9, xxxxxxx | 9, <:1>[2-9]xxxxxxxxx | 8, <:1212>xxxxxxx | 9, 1 [2-9] xxxxxxxxx | 9, 1 900 xxxxxxx ! | 9, 011xxxxxx. | 0 | [49]11 )
9, 1 [2-9] xxxxxxxxx After the user presses 9, an external dial tone sounds. The user can enter any 11-digit number that starts with 1 and is followed by a digit 2 through 9.
( [1-8]xx | 9, xxxxxxx | 9, <:1>[2-9]xxxxxxxxx | 8, <:1212>xxxxxxx | 9, 1 [2-9] xxxxxxxxx | 9, 1 900 xxxxxxx ! | 9, 011xxxxxx. | 0 | [49]11 )
9, 1 900 xxxxxxx ! This digit sequence is useful if you want to prevent users from dialing numbers that are associated with high tolls or inappropriate content, such as 1-900 numbers in the U.S. After the user press 9, an external dial tone sounds. If the user enters an 11-digit number that starts with the digits 1900, the call is rejected.
( [1-8]xx | 9, xxxxxxx | 9, <:1>[2-9]xxxxxxxxx | 8, <:1212>xxxxxxx | 9, 1 [2-9] xxxxxxxxx | 9, 1 900 xxxxxxx ! | 9, 011xxxxxx. | 0 | [49]11 )
9, 011xxxxxx After the user presses 9, an external dial tone sounds. The user can enter any number that starts with 011, as in an international call from the U.S.
( [1-8]xx | 9, xxxxxxx | 9, <:1>[2-9]xxxxxxxxx | 8, <:1212>xxxxxxx | 9, 1 [2-9] xxxxxxxxx | 9, 1 900 xxxxxxx ! | 9, 011xxxxxx. | 0 | [49]11 )
0 | [49]11 This example includes two-digit sequences, separated by the pipe character. The first sequence allows a user to dial 0 for an operator. The second sequence allows the user to enter 411 for local information or 911 for emergency services.
When a user dials a series of digits, each sequence in the dial plan is tested as a possible match. The matching sequences form a set of candidate digit sequences. As the user enters more digits, the set of candidates diminishes until only one or none is valid. When a terminating event occurs, the IP PBX either accepts the user-dialed sequence and initiates a call, or else rejects the sequence as invalid. The user hears the reorder (fast busy) tone if the dialed sequence is invalid.
The following table explains how terminating events are processed.
Dialed digits have not matched any sequence in the dial plan. |
|
If the dial plan allows the sequence, the number is accepted and is transmitted according to the dial plan. If the dial plan blocks the sequence, the number is rejected. |
|
The number is rejected if the dialed digits are not matched to a digit sequence in the dial plan within the time that the applicable interdigit timer specifies. The Interdigit Long Timer applies when the dialed digits do not match any digit sequence in the dial plan. The Interdigit Short Timer applies when the dialed digits match one or more candidate sequences in the dial plan. Default: 3 seconds. |
|
A user presses the # key or the dial softkey on the IP phone screen. |
If the sequence is complete and is allowed by the dial plan, the number is accepted and is transmitted according to the dial plan. If the sequence is incomplete or is blocked by the dial plan, the number is rejected. |
You can think of the Dial Plan Timer as the off-hook timer. This timer starts when the phone goes off hook. If no digits are dialed within the specified number of seconds, the timer expires and the null entry is evaluated. Unless you have a special dial plan string to allow a null entry, the call is rejected. The default length of the Dial Plan Timer is 5 seconds.
s: The number of seconds; if no number is entered after P, the default timer of 5 seconds applies. With the timer set to 0 seconds, the call transmits automatically to the specified extension when the phone goes off hook.
n: (optional): The number to transmit automatically when the timer expires; you can enter an extension number or a DID number. No wildcard characters are allowed because the number is transmitted as shown. If you omit the number substitution, <:n>, the user hears a reorder (fast busy) tone after the specified number of seconds.
Allow more time for users to start dialing after taking a phone off hook:
(P9 | (9,8<:1408>[2-9]xxxxxx | 9,8,1[2-9]xxxxxxxxx | 9,8,011xx. | 9,8,xx.|[1-8]xx)
P9 means that after taking a phone off hook, a user has 9 seconds to begin dialing. If no digits are pressed within 9 seconds, the user hears a reorder (fast busy) tone. By setting a longer timer, you allow more time for users to enter digits.
To create a hotline for all sequences on the System Dial Plan:
(P9<:23> | (9,8<:1408>[2-9]xxxxxx | 9,8,1[2-9]xxxxxxxxx | 9,8,011xx. | 9,8,xx.|[1-8]xx)
P9<:23> means that after taking the phone off hook, a user has 9 seconds to begin dialing. If no digits are pressed within 9 seconds, the call is transmitted automatically to extension 23.
( P0 <:1000>)
With the timer set to 0 seconds, the call is transmitted automatically to the specified extension when the phone goes off hook. Enter this sequence in the Phone Dial Plan for Ext 2 or higher on a client phone.
You can think of this timer as the incomplete entry timer. This timer measures the interval between dialed digits. It applies as long as the dialed digits do not match any digit sequences in the dial plan. Unless the user enters another digit within the specified number of seconds, the entry is evaluated as incomplete, and the call is rejected. The default value is 10 seconds.
This section explains how to edit a timer as part of a dial plan. Alternatively, you can modify the Control Timer that controls the default interdigit timers for all calls.
s: The number of seconds; if no number is entered after L:, the default timer is 5 seconds. With the timer set to 0 seconds, the call is transmitted automatically to the specified extension when the phone goes off hook.
Note that the timer sequence appears to the left of the initial parenthesis for the dial plan.
L:15, (9,8<:1408>[2-9]xxxxxx | 9,8,1[2-9]xxxxxxxxx | 9,8,011xx. | 9,8,xx.|[1-8]xx)
L:15 means that this dial plan allows the user to pause for up to 15 seconds between digits before the Interdigit Long Timer expires. This setting is especially helpful to users such as sales people, who are reading the numbers from business cards and other printed materials while dialing.
You can think of this timer as the complete entry timer. This timer measures the interval between dialed digits. The timer applies when the dialed digits match at least one digit sequence in the dial plan. Unless the user enters another digit within the specified number of seconds, the entry is evaluated. If the entry is valid, the call proceeds. If the entry is invalid, the call is rejected.
Use this syntax to apply the new setting to the entire dial plan within the parentheses.
Use this syntax to apply the new setting to a particular dialing sequence.
s: The number of seconds; if no number is entered after S, the default timer of 5 seconds applies.
S:6, (9,8<:1408>[2-9]xxxxxx | 9,8,1[2-9]xxxxxxxxx | 9,8,011xx. | 9,8,xx.|[1-8]xx)
S:6 means that while the user enters a number with the phone off hook, the user can pause for up to 15 seconds between digits before the Interdigit Short Timer expires. This setting is especially helpful to users such as sales people, who are reading the numbers from business cards and other printed materials while dialing.
Set an instant timer for a particular sequence within the dial plan:
(9,8<:1408>[2-9]xxxxxx | 9,8,1[2-9]xxxxxxxxxS0 | 9,8,011xx. | 9,8,xx.|[1-8]xx)
9,8,1[2-9]xxxxxxxxxS0 means that with the timer set to 0, the call is transmitted automatically when the user dials the final digit in the sequence.
Step 1 | In the phone web user interface, navigate to , where n is an extension number. | ||
Step 2 | Scroll to the Dial Plan section. | ||
Step 3 | Enter the digit sequences in the Dial Plan field. The default (US-based) systemwide dial plan appears automatically in the field. | ||
Step 4 | You can delete digit sequences, add digit sequences, or replace the entire dial plan with a new dial plan. Separate each digit sequence with a pipe character, and enclose the entire set of digit sequences within parentheses. Example: (9,8<:1408>[2-9]xxxxxx | 9,8,1[2-9]xxxxxxxxx | 9,8,011xx. | 9,8,xx.|[1-8]xx) | ||
Step 5 | Click Submit All Changes. | ||
Step 6 | Verify that you can successfully complete a call with each digit sequence that you entered in the dial plan.
|
If you need to edit a timer setting only for a particular digit sequence or type of call, you can edit the dial plan.
In the phone web user interface, use the Regional tab to configure regional and local settings, such as control timer values, dictionary server script, language selection, and locale to change localization. The Regional tab includes these sections:
Call Progress Tones—Displays values of all ringtones.
Distinctive Ring Patterns—Ring cadence defines the ringing pattern that announces a telephone call.
Vertical Service Activation Codes—Includes Call Back Act Code and Call Back Deact Code.
Outbound Call Codec Selection Codes—Defines the voice quality.
Time—Includes local date, local time, time zone, and Daylight Saving Time.
Language—Includes Dictionary Server Script, Language Selection, and Locale.
The Cisco IP Phone obtains the time settings in one of three ways:
Note | NTP time takes priority over the time you set using the menu options on the phone screen. When you manually enter a time, this setting takes effect. On the next NTP synchronization, the time id is corrected so that the NTP time is displayed. When you manually enter the phone time, a pop-up is available that alerts you of this behavior. |
SIP Messages—Each SIP message (request or response) sent to the phone can contain a Date header with the current time information. If the header is present, the phone uses it to set its clock.
Manual Setup—You can use the phone web user interface to enter the time and date manually. However, the NTP time or SIP Message Date overwrites this value when either is available to the phone. Manual setup requires that you enter the time in 24-hour format only.
The time that the NTP Server and the SIP Date Header serve is expressed in GMT time. The local time is obtained by offsetting the GMT according to the time zone of the region.
You can configure the Time Zone parameter with the phone web user interface or through provisioning. This time can be further offset by the Time Offset (HH/mm) parameter. This parameter must be entered in 24-hour format and can also be configured from the IP phone screen.
Note | The time of the log messages and status messages are in UTC time and are not affected by the time zone setting. |
Note | The time of the log messages and status messages are in UTC time. The time zone setting does not affect them. |
The following example configures daylight saving time for the U.S, adding one hour starting at midnight on the first Sunday in April and ending at midnight on the last Sunday of October; add 1 hour (USA, North America):
start=4/1/7/0:0:0;end=10/31/7/0:0:0;save=1 start=4/1/7;end=10/-1/7;save=1 start=4/1/7/0;end=10/-1/7/0;save=1
The following example configures daylight saving time for Egypt, starting at midnight on the last Sunday in April and ending at midnight on the last Sunday of September:
start=4/-1/7;end=9/-1/7;save=1 (Egypt)
The following example configures daylight saving time for New Zealand (in version 7.5.1 and higher), starting at midnight on the first Sunday of October and ending at midnight on the third Sunday of March.
start=10/1/7;end=3/22/7;save=1 (New Zealand)
The following example reflects the new change starting in March. DST starts on the second Sunday in March and ends on the first Sunday in November:
start=3/8/7/02:0:0;end=11/1/7/02:0:0;save=1
The following example configures the daylight saving time starting on the last Monday (before April 8) and ending on the first Wednesday (after May 8.)
start=4/-8/1;end=5/8/3;save=1
You can define up to nineteen languages, in addition to English, to be available and host the dictionaries for each of the languages on the HTTP or TFTP provisioning server. Language support follows Cisco dictionary principles.
Use the Language Selection parameter to select the phone default display language. The value must match one of the languages that the dictionary server supports. The script (dx value) is as follows:
The Language Selection parameter defaults to blank; the maximum number of characters is 512. For example:
<Language_Selection ua=”na”> Spanish </Language_Selection>
During startup, the phone checks the selected language and downloads the dictionary from the TFTP/ HTTP provisioning server that the phone configuration indicates. The dictionaries are available at the support website.
The Dictionary Server Script defines the location of the dictionary server, the available languages, and the associated dictionary. The script recognizes up to 19 language entries. The syntax is:
Dictionary_Server_Script serv=tftp://192.168.1.119/ ;d0=English;x0=enS_v101.xml;d1=Spanish;x1=esS_v101.xml
Note | TFTP, HTTP, and HTTPS support exists for the dictionary download. |
Default to blank; the maximum number of characters is 512. The detailed format is as follows:
serv={server ip port and root path}; d0=language0;x0=dictionary0 filename; d1=language1;x1=dictionary1 filename; d2=language2;x2=dictionary2 filename; d3=language3;x3=dictionary3 filename; d4=language4;x4=dictionary4 filename; d5=language5;x5=dictionary5 filename; d6=language6;x6=dictionary6 filename; d7=language7;;x7=dictionary7 filename; d8=language8;x8=dictionary8 filename; d9=language9;x9=dictionary9 filename;
The following languages locales are supported on the Cisco IP Phone:
(Entry dx must match one of the languages that the dictionary server supports.)
Refer to publications that are specific to your language and phone model, and phone firmware release. Navigate from the following documentation URL:
http://www.cisco.com/c/en/us/support/collaboration-endpoints/unified-ip-phone-7800-series/tsd-products-support-series-home.html