- Verify the Network Setup
- Install the Cisco IP Phone
- Configure the Network from the Phone
- Set Up Wireless LAN from the Phone
- Verify Phone Startup
- Video Transmit Resolution Setup
- Configure the Voice Codecs
- Configure the Video Codec
- Set the Optional Network Servers
- VLAN Settings
- Cisco Discovery Protocol
- LLDP-MED
- Chassis ID TLV
- Port ID TLV
- Time to Live TLV
- End of LLDPDU TLV
- Port Description TLV
- System Name TLV
- System Capabilities TLV
- Management Address TLV
- System Description TLV
- IEEE 802.3 MAC/PHY Configuration/Status TLV
- LLDP-MED Capabilities TLV
- Network Policy TLV
- LLDP-MED Extended Power-Via-MDI TLV
- LLDP-MED Inventory Management TLV
- Final Network Policy Resolution and QoS
- Configure VLAN Settings
- SIP and NAT Configuration
- SIP and the Cisco IP Phone
- SIP Configuration
- Configure the Basic SIP Parameters
- Configure the SIP Timer Values
- Configure the Response Status Code Handling
- Configure NTP Server
- Configure the RTP Parameters
- Control SIP and RTP Behaviour in Dual Mode
- Configure the SDP Payload Types
- Configure the SIP Settings for Extensions
- Configure the SIP Proxy Server
- Configure the Subscriber Information Parameters
- Managing NAT Transversal with Phones
Cisco IP Phone Installation
- Verify the Network Setup
- Install the Cisco IP Phone
- Configure the Network from the Phone
- Set Up Wireless LAN from the Phone
- Verify Phone Startup
- Video Transmit Resolution Setup
- Configure the Voice Codecs
- Configure the Video Codec
- Set the Optional Network Servers
- VLAN Settings
- SIP and NAT Configuration
- Dial Plan
- Regional Parameters and Supplementary Services
- Cisco IP Phone 8800 Series Documentation
Verify the Network Setup
For the phone to operate successfully as an endpoint in your network, your network must meet specific requirements.
Install the Cisco IP Phone
After the phone connects to the network, the phone startup process begins, and the phone registers with Third-Party Call Control system. To finish installing the phone, configure the network settings on the phone depending on whether you enable or disable 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.
 Note | Before using external devices, read External Devices. |
| Step 1 | Choose the
power source for the phone:
For more information, see Phone Power Requirements. |
| Step 2 | Connect the
handset to the handset port.
The wideband-capable handset is designed especially for use with a Cisco IP Phone. The handset includes a light strip that indicates incoming calls and waiting voice messages. |
| Step 3 | Connect a headset to the headset port. You can add a headset later if you do not connect one now. |
| Step 4 | Connect a wireless headset. You can add a wireless headset later if you do not want to connect one now. For more information, see your wireless headset documentation. |
| Step 5 | Connect a
straight-through Ethernet cable from the switch to the network port labeled
10/100/1000 SW on the Cisco IP Phone.
Each Cisco IP Phone ships with one Ethernet cable in the box.
Use Category 3, 5, 5e, or 6 cabling for 10 Mbps connections; Category 5, 5e, or 6 for 100 Mbps connections; and Category 5e or 6 for 1000 Mbps connections. For more information, see Network and Computer Port Pinouts. |
| Step 6 | Connect a straight-through Ethernet cable from another network
device, such as a desktop computer, to the computer port on the Cisco IP Phone.
You can connect another network device later if you do not connect one now.
Use Category 3, 5, 5e, or 6 cabling for 10 Mbps connections; Category 5, 5e, or 6 for 100 Mbps connections; and Category 5e or 6 for 1000 Mbps connections. For more information, see Network and Computer Port Pinouts for guidelines. |
| Step 7 | If the phone is on a desk, adjust the footstand. For more information, see Connect the Footstand. With a wall-mounted phone, you might need to adjust the handset rest to ensure that the receiver cannot slip out of the cradle. |
| Step 8 | Monitor the phone startup process. This step verifies that the phone is configured properly. |
| Step 9 | If you are configuring the network settings on the phone, you can set up an IP address for the phone by either using DHCP or manually entering an IP address. |
| Step 10 | Upgrade the
phone to the current firmware image.
Firmware upgrades over the WLAN interface may take longer than upgrading over the wired interface, depending on the quality and bandwidth of the wireless connection. Some upgrades may take more than one hour. |
| Step 11 | Make calls with the Cisco IP Phone to verify that the phone and features work correctly. |
| Step 12 | 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 IP Phones. |
Configure the Network from the Phone
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.
. Network Configuration Fields
|
Field |
Field Type or Choices |
Default |
Description |
|---|---|---|---|
|
Ethernet configuration |
See the Ethernet configuration submenu table below. |
||
|
Wi-Fi configuration |
See Set Up Wireless LAN from the Phone For 8861 only. |
||
|
IPv4 address settings |
DHCP Static IP Release DHCP IP |
DHCP |
See the IPv4 address submenu table below. |
|
Web server |
On Off |
On |
Indicates whether the phone has web server enabled or disabled. |
|
DHCP option to use |
66,160,159, 150, 60 |
Indicates the order in which the phone uses the IP address provided by DHCP server. |
|
|
Transport protocol |
HTTP HTTPS TFTP |
This protocol is only configurable on phone Configuration Utility page. |
Text and Menu Entry From the Phone
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 Back before pressing Set 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. |
Set Up Wireless LAN from the Phone
Only the Cisco IP Phone 8861 supports wireless LAN.
Ensure that the phone is not connected to ethernet and has direct power supply.
A fast-secure roaming method is recommended for Wi-Fi users.
For complete configuration information, see the Cisco IP Phone 8800 Wireless LAN Deployment Guide at this location:
The Cisco IP Phone 8800 Wireless LAN Deployment Guide includes the following configuration information:
| Step 1 | Press Applications
 . |
| Step 2 | Select . |
| Step 3 | In the Connect to Wi-Fi screen, click Scan to get a list of available Wi-Fi networks (SSIDs). |
| Step 4 | Select an SSID when the scan is complete, and set up the fields for your phone to connect to that network as described in the Scan List Menus table.
You can also click Cancel to stop the scan process. If your phone is associated with an SSID, the associated SSID appears at the top of scanned list with a check mark in front of it. |
| Step 5 | (Optional) Press Other to add a new network name to which you want to connect your phone. Set up the fields as described in the Wi-Fi Other Menu table. |
Scan List Menus
Wi-Fi Other Menu
Verify Phone Startup
After the Cisco IP Phone has power connected to it, the phone automatically cycles through a startup diagnostic process.
Video Transmit Resolution Setup
Cisco IP Phone 8845 and 8865 supports the following video formats:
-
720p (1280x720)
-
WVGA (800x480)
-
360p (640x360)
-
240p (432x240)
-
VGA (640x480)
-
CIF (352x288)
-
SIF (352x240)
-
QCIF (176x144)
Cisco IP Phones that support video negotiate the best bandwidth and resolution based on the phone configuration and phone screen limitations.
The next table shows the resolutions, frames per second, and video bit rate range for each of the supported video types.
|
Video type |
Video resolution |
Frames per second (fps) |
Video bit rate range |
|---|---|---|---|
|
720p |
1280 x 720 |
30 |
1360–2500 kbps |
|
720p |
1280 x 720 |
15 |
790–1359 kbps |
|
WVGA |
800 x 480 |
30 |
660–789 kbps |
|
WVGA |
800 x 480 |
15 |
350–399 kbps |
|
360p |
640 x 360 |
30 |
400–659 kbps |
|
360p |
640 x 360 |
15 |
210–349kbps |
|
240p |
432 x 240 |
30 |
180–209kbps |
|
240p |
432 x 240 |
15 |
64–179kbps |
|
VGA |
640 x 480 |
30 |
520–1500kbps |
|
VGA |
640 x 480 |
15 |
280–519kbps |
|
CIF |
352 x 288 |
30 |
200–279 kbps |
|
CIF |
352 x 288 |
15 |
120–199 kbps |
|
SIF |
352 x 240 |
30 |
200–279 kbps |
|
SIF |
352 x 240 |
15 |
120–199 kbps |
|
QCIF |
176 x 144 |
30 |
94–119 kbps |
|
QCIF |
176 x 144 |
15 |
64–93 kbps |
Configure the Voice Codecs
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.
Configure the Video Codec
Video codecs enable compression or decompression of digital video. You can enable or disable video codecs from the phone web page.
The Cisco IP Phone 8845 and 8865 supports the H.264 High Profile packetization mode 0 and Base Profile packetization mode 0 codecs.
For all codecs, the Real Time Protocol (RTP) payload type is dynamic and you can configure it on the phone web page from . For more information, see SDP Payload Types.
| Step 1 | On the phone web page, select . |
| Step 2 | In the Video Configuration section, set up the fields as described in Video Configuration. |
| Step 3 | Click Submit All Changes. |
Set the Optional Network Servers
Optional network servers provide resources such as DNS lookup, network time, logging, and device discovery. It also enables you to add PC port mirroring on the user phone. Your user can also enable or disable this service from the phone.
| Step 1 | In the phone web page, navigate to Admin Login > advanced > Voice > System. |
| Step 2 | In the Optional Network Configuration section, set up the fields as described in Optional Network Configuration. |
| Step 3 | Click Submit All Changes. |
VLAN Settings
If you use a virtual LAN (VLAN), your phone voice packets are tagged with the VLAN ID.
In the VLAN Settings section of the window, you can configure these settings:
Cisco Discovery Protocol
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.
LLDP-MED
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.
- Chassis ID TLV
- Port ID TLV
- Time to Live TLV
- End of LLDPDU TLV
- Port Description TLV
- System Name TLV
- System Capabilities TLV
- Management Address TLV
- System Description TLV
- IEEE 802.3 MAC/PHY Configuration/Status TLV
- LLDP-MED Capabilities TLV
- Network Policy TLV
- LLDP-MED Extended Power-Via-MDI TLV
- LLDP-MED Inventory Management TLV
Chassis ID TLV
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.
Port ID TLV
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.
Time to Live TLV
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.
End of LLDPDU TLV
The value is 2-octet, all zero. This TLV is mandatory and only one is allowed for the outgoing and incoming LLDPDUs.
Port Description TLV
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.
System Name TLV
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.
System Capabilities TLV
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.
Management Address TLV
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.
System Description TLV
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.
IEEE 802.3 MAC/PHY Configuration/Status TLV
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.
LLDP-MED Capabilities TLV
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.
Network Policy 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.
LLDP-MED Extended Power-Via-MDI TLV
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.
LLDP-MED Inventory Management TLV
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.
Final Network Policy Resolution and QoS
Special VLANs
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.
Default QoS for SIP Mode
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.
QoS Resolution for CDP
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.
QoS Resolution for LLDP-MED
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.
Coexistence with CDP
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 CDP and LLDP-MED PDUs.
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.
LLDP-MED and Multiple Network Devices
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.
LLDP-MED and IEEE 802.X
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.
Configure VLAN Settings
SIP and NAT Configuration
SIP and the Cisco IP Phone
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.
- SIP Over TCP
- SIP Proxy Redundancy
- Dual Registration
- Failover and Recovery Registration
- RFC3311
- SIP NOTIFY XML-Service
SIP Over TCP
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.
SIP Proxy Redundancy
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.
Dual Registration
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. |
Dual Registration and DNS SRV Limitations
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.
Dual Registration and Alternate Proxy
When the Dual Register parameter is set to No, Alternate Proxy is ignored.
Failover and Recovery Registration
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.
Fallback Behavior
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.
RFC3311
The Cisco IP Phone supports RFC-3311, the SIP UPDATE Method.
SIP NOTIFY XML-Service
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 Configuration
SIP settings for the Cisco IP Phone are configured for the phone in general and for the extensions.
- Configure the Basic SIP Parameters
- Configure the SIP Timer Values
- Configure the Response Status Code Handling
- Configure NTP Server
- Configure the RTP Parameters
- Control SIP and RTP Behaviour in Dual Mode
- Configure the SDP Payload Types
- Configure the SIP Settings for Extensions
- Configure the SIP Proxy Server
- Configure the Subscriber Information Parameters
Configure the Basic SIP Parameters
| Step 1 | In the phone web user interface, navigate to . |
| Step 2 | In the SIP Parameters section, set the SIP parameters as described in SIP Parameters. |
| Step 3 | Click Submit All Changes. |
Configure the SIP Timer Values
| 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 SIP Timer Values (sec). |
| Step 3 | Click Submit All Changes. |
Configure the Response Status Code Handling
Configure NTP Server
You can configure NTP servers with IPv4 and IPv6. You can also configure NTP server with DHCPv4 option 42 or DHCPv6 option 56. Configuring NTP with Primary NTP Server and Secondary NTP server parameters has higher priority over configuring NTP with DHCPv4 option 42 or DHCPv6 option 56.
| Step 1 | On the phone web page, select . |
| Step 2 | In the Optional Network Configuration section, enter IPv4 or IPv6 address in the Primary NTP Server and Secondary NTP Server . |
| Step 3 | Click Submit All Changes. |
Configure the RTP Parameters
| 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 RTP Parameters. |
| Step 3 | Click Submit All Changes. |
Control SIP and RTP Behaviour in Dual Mode
You can control SIP and RTP parameters with SIP IP Preference and SDP IP Preference fields when phone is in dual mode.
SIP IP Preference parameter defines which IP address phone tries first when it is in dual mode.
|
IP Mode |
SIP IP Preference |
Address List from DNS, Priority, Result P1 - First Priority Address P2 - Second Priority Address |
Failover Sequence |
|---|---|---|---|
|
Dual Mode |
IPv4 |
P1- 1.1.1.1, 2009:1:1:1::1 P2 - 2.2.2.2, 2009:2:2:2::2 Result: Phone will send the SIP messages to 1.1.1.1 first. |
1.1.1.1 ->2009:1:1:1:1 -> 2.2.2.2 -> 2009:2:2:2:2 |
|
Dual Mode |
IPv6 |
P1- 1.1.1.1, 2009:1:1:1::1 P2 - 2.2.2.2, 2009:2:2:2::2 Result: Phone will send the SIP messages to 2009:1:1:1::1 first. |
2009:1:1:1:1 -> 1.1.1.1 -> 2009:2:2:2:2 -> 2.2.2.2 |
|
Dual Mode |
IPv4 |
P1- 2009:1:1:1::1 P2 - 2.2.2.2, 2009:2:2:2::2 Result: Phone will send the SIP messages to 2009:1:1:1::1 first. |
2009:1:1:1:1 -> 2.2.2.2 -> 2009:2:2:2:2 |
|
Dual Mode |
IPv6 |
P1- 2009:1:1:1::1 P2 - 2.2.2.2, 2009:2:2:2::2 Result: Phone will send the SIP messages to 1.1.1.1 first. |
2009:1:1:1:1 -> 2009:2:2:2:2 ->2.2.2.2 |
|
IPv4 Only |
IPv4 or IPv6 |
P1 - 1.1.1.1, 2009:1:1:1::1 P2 - 2.2.2.2, 2009:2:2:2::2 Result: Phone will send the SIP messages to 1.1.1.1 first. |
1.1.1.1 -> 2.2.2.2 |
|
IPv6 Only |
IPv4 or IPv6 |
P1 - 1.1.1.1, 2009:1:1:1::1 P2 - 2.2.2.2, 2009:2:2:2::2 Result: Phone will send the SIP messages to 2009:1:1:1::1 first. |
2009:1:1:1:1 -> 2009:2:2:2::2 |
| Step 1 | On the phone web page, select . |
| Step 2 | In the SIP Parameters section, select IPv4 or IPv6 in the SIP IP Preference field. |
| Step 3 | In the RTP Parameters section, select IPv4 or IPv6 in the SDP IP Preference field.
For details, see SDP IP Preference in RTP Parameters. |
Configure the SDP Payload Types
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 inSDP Payload Types. |
| Step 3 | Click Submit All Changes. |
Configure the SIP Settings for Extensions
| 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 SIP Settings. |
| Step 3 | Click Submit All Changes. |
Configure the SIP Proxy Server
| 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 Proxy and Registration. |
| Step 3 | Click Submit All Changes. |
Configure the Subscriber Information Parameters
| 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 Subscriber Information. |
| Step 3 | Click Submit All Changes. |
Managing NAT Transversal with Phones
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.
- Enable NAT Mapping
- NAT Mapping with Session Border Controller
- NAT Mapping with SIP-ALG Router
- NAT Mapping with the Static IP Address
- Configure NAT mapping with STUN
Enable NAT Mapping
| Step 1 | On the Configuration Utility page, select . |
| Step 2 | Set up the fields as described in NAT Settings. |
| Step 3 | Click Submit All Changes. |
NAT Mapping with Session Border Controller
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 with SIP-ALG 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.
NAT Mapping with the Static IP Address
You can configure NAT mapping on the phone to ensure interoperability with the service provider.
-
You must have an external (public) IP address that is static .
-
The NAT mechanism used in the router must be symmetric. for more information, see Determining Symmetric or Asymmetric NAT .
Use NAT mapping only if the service provider network does not provide a Session Border Controller functionality.
What to Do Next
Configure the firewall settings on your router to allow SIP traffic.
Configure NAT mapping with STUN
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.
What to Do Next
Configure the firewall settings on your router to allow SIP traffic.
Determining Symmetric or Asymmetric NAT
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:
Dial Plan
Dial Plan Overview
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.
- Digit Sequences
- Digit Sequence Examples
- Acceptance and Transmission of the Dialed Digits
- Dial Plan Timer (Off-Hook Timer)
- Interdigit Long Timer (Incomplete Entry Timer)
- Interdigit Short Timer (Complete Entry Timer)
Digit Sequences
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 Examples
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 )
Extensions on your system: ( [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 to 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
Local dialing with seven-digit number: ( [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.
Local dialing with 3-digit area code and a 7-digit local number: ( [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.
Local dialing with an automatically inserted 3-digit area code: ( [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.
U.S. long-distance dialing: ( [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.
Blocked number: ( [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 presses 9, an external dial tone sounds. If the user enters an 11-digit number that starts with the digits 1900, the call is rejected.
U.S. international dialing: ( [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.
Informational numbers: ( [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.
Acceptance and Transmission of the Dialed Digits
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.
Dial Plan Timer (Off-Hook Timer)
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.
Syntax for the Dial Plan Timer
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.
Examples for the Dial Plan Timer
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.
Interdigit Long Timer (Incomplete Entry Timer)
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.
Syntax for the Interdigit Long Timer
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.
Example for the Interdigit Long Timer
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.
Interdigit Short Timer (Complete Entry Timer)
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.
Syntax for the Interdigit Short Timer
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.
Examples for the Interdigit Short Timer
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.
Edit the Dial Plan on the IP Phone
Reset the Control Timers
If you need to edit a timer setting only for a particular digit sequence or type of call, you can edit the dial plan.
Regional Parameters and Supplementary Services
Regional Parameters
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.
Set the Control Timer Values
Localize Your Cisco IP Phone
Time and Date Settings
The Cisco IP Phone obtains the time settings in one of three ways:
NTP Server—When the phone boots up, it tries to contact the first Network Time Protocol (NTP) server to get the time. The phone periodically synchronizes its time with the NTP server. The synchronization period is fixed at 1 hour. Between updates, the phone tracks time with its internal clock.
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.
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.
The Time Zone and Time Offset (HH/mm) offset values are not applied to manual time and date setup
Note | The time of the log messages and status messages are in UTC time and are not affected by the time zone setting. |
Configure Daylight Saving Time
The phone supports automatic adjustment for daylight saving time.
Note | The time of the log messages and status messages are in UTC time. The time zone setting does not affect them. |
Daylight Saving Time Examples
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
Select a Display Language on the Phone
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.
Dictionary Server Script
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:
Localization Configuration Example
(Entry dx must match one of the languages that the dictionary server supports.)
Cisco IP Phone 8800 Series Documentation
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-8800-series/tsd-products-support-series-home.html
Feedback