Session Initiation Protocol (SIP) is the Internet Engineering Task Force (IETF) standard for multimedia conferencing over IP. SIP is an ASCII-based, application-layer control protocol (defined in RFC 3261) that can be used to establish, maintain, and terminate calls between two or more endpoints.
Like other VoIP protocols, SIP is designed to address the functions of signaling and session management within a packet telephony network. Signaling allows call information to be carried across network boundaries. Session management provides the ability to control the attributes of an end-to-end call.
SIP provides the capabilities to do the following:
Determine the location of the target endpoint—SIP supports address resolution, name mapping, and call redirection.
Determine the media capabilities of the target endpoint—Via Session Description Protocol (SDP), SIP determines the "lowest level" of common services between the endpoints. Conferences are established using only the media capabilities that can be supported by all endpoints.
Determine the availability of the target endpoint—If a call cannot be completed because the target endpoint is unavailable, SIP determines whether the called party is already on the phone or did not answer in the allotted number of rings. It then returns a message that indicates why the target endpoint was unavailable.
Establish a session between the originating and target endpoint—If the call can be completed, SIP establishes a session between the endpoints. SIP also supports midcall changes, such as the addition of another endpoint to the conference or the changing of a media characteristic or codec.
Handle the transfer and termination of calls—SIP supports the transfer of calls from one endpoint to another. During a call transfer, SIP simply establishes a session between the transferee and a new endpoint (specified by the transferring party) and terminates the session between the transferee and the transferring party. At the end of a call, SIP terminates the sessions between all parties.
Conferences can consist of two or more users and can be established using multicast or multiple unicast sessions.
Note The term conference means an established session (or call) between two or more endpoints. In this
document, the terms conference and call are used interchangeably.
Components of SIP
SIP is a peer-to-peer protocol. The peers in a session are called user agents (UAs). A user agent can function in one of the following roles:
User agent client (UAC)—A client application that initiates the SIP request.
User agent server (UAS)—A server application that contacts the user when a SIP request is received and that returns a response on behalf of the user.
Typically, a SIP endpoint is capable of functioning as both a UAC and a UAS, but functions only as one or the other per transaction. Whether the endpoint functions as a UAC or a UAS depends on the UA that initiated the request.
From an architecture standpoint, the physical components of a SIP network can also be grouped into two categories: clients and servers. Figure 1-1 illustrates the architecture of a SIP network.
Note In addition, the SIP servers can interact with other application services, such as Lightweght Directory
Access Protocol (LDAP) servers, a database application, or an eXtensible Markup Language (XML)
application. These application services provide back-end services such as
directory, authentication, and billing services.
Figure 1-1 SIP Architecture
SIP Clients
SIP clients include the following:
Phones—Acts as either a UAS or UAC. Softphones (PCs that have phone capabilities installed) and Cisco SIP IP phones can initiate SIP requests and respond to requests.
Gateways—Provides call control. Gateways provide many services, the most common being a translation function between SIP conferencing endpoints and other terminal types. This function includes translation between transmission formats and between communications procedures. In addition, the gateway also translates between audio and video codecs and performs call setup and clearing on both the LAN side and the switched-circuit network side.
SIP Servers
SIP servers include the following:
Proxy server—Receives SIP requests from a client and then forwards the requests because it is an intermediate device. Basically, proxy servers receive SIP messages and forward them to the next SIP server in the network. Proxy servers can provide functions such as authentication, authorization, network access control, routing, reliable request retransmission, and security.
Redirect server—Receives SIP requests, strips out the address in the request, checks its address tables for any other addresses that may be mapped to the one in the request, and then returns the results of the address mapping to the client. Basically, redirect servers provide the client with information about the next hop or hops that a message should take, and then the client contacts the next-hop server or UAS directly.
Registrar server—Processes requests from UACs for registration of their current location. Registrar servers are often colocated with a redirect or proxy server.
What Is the Cisco SIP IP Phone?
Cisco SIP IP phones are full-featured telephones that can be plugged directly into an IP network and can be used very much like a standard PBX telephone. The Cisco SIP IP phone is an IP telephony instrument that can be used in VoIP networks.
The Cisco SIP IP phone terminals can attach to the existing data network infrastructure, via 10BASE-T/100BASE-T interfaces on an Ethernet switch. When used with a voice-capable Ethernet switch (one that understands type of service [ToS] bits and can prioritize VoIP traffic), the phones eliminate the need for a traditional proprietary telephone set and key system and PBX.
Figure 1-2 illustrates the physical features of the Cisco SIP IP phone.
Figure 1-2 The Physical Features of the Cisco SIP IP Phone
LCD screen—Desktop, which displays information about your Cisco SIP IP phone, such as the time, date, your phone number, caller ID, line and call status, and the soft key tabs.
Line or speed-dial buttons—Opens a new line or speed dials the number on the LCD screen.
Footstand adjustment—Adjusts the angle of the phone base.
Soft keys—Activates the feature described by the text message directly above on the LCD screen.
Information (i) button—Provides online help for selected keys or features and network statistics about the active call. Pressing the i button and then the up or down scroll key displays a descriptor of the key. For example, pressing the ibutton,then the up or down scroll key, displays a screen instructing you how to scroll up and down on the LCD.
On-screen mode buttons—Retrieves information about current settings, recent calls, available services, and voice-mail messages.
Volume buttons—Adjusts the volume of the handset, headset, speaker, and ringer and adjust the brightness contrast settings on the LCD screen.
Function toggles—Includes the following options:
Headset and speaker—Toggles these functions enabling you to answer the phone using a headset or speakerphone.
Mute—Stops or resumes voice transmission.
Scroll key—Enables you to move among different soft key options displayed on the LCD screen.
Dialing pad—Press the dial-pad buttons to dial a phone number. Dial-pad buttons work exactly like those on your existing telephone.
Handset—Lift the handset and press the dial-pad numbers to place a call, review voice-mail messages, or answer a call.
BTXML Support
Basic Telephony eXtensible Markup Language (BTXML) is supported on the Cisco SIP IP phone. BTXML defines XML elements for controlling the user interface of an IP telephone. BTXML describes what information is displayed on the screen and how the user provides input using soft keys and hard keys. User interface control is internal to the phone; there is no external BTXML user interface control.
Cisco CallManager XML Support
The Cisco SIP IP phone supports customer-written Cisco CallManager XML cards that can be accessed using buttons or soft keys on the phone. These cards can provide data such as stock quotes, calendars, and directory lookups. The XML cards can be accessed by the following methods:
From the Services soft key, configured using the services_url parameter.
By pressing the directory button and selecting External Directory, configured using the directory_url parameter.
By downloading a bit-map to be used as the phone logo (branding), configured using the logo_url parameter.
The Cisco SIP IP phone supports Cisco CallManager XML up to version 3.0 but does not support the XML objects added in Cisco CallManager XML version 3.1, which are:
CiscoIPPhoneIconMenu
CiscoIPPhoneExecute
CiscoIPPhoneError
CiscoIPPhoneResponse
SoftKeyItem
The following exceptions apply to the Cisco SIP IP phone:
External directories cannot be appended to the main list of directories under the directory button. If external directories are provisioned for the Cisco SIP IP phone, they can be accessed by pressing the directory button and selecting the External Directory option.
The Cisco SIP IP phone removes white space when the Cisco CallManager XML cards are displayed. Multiple spaces are consolidated into a single space.
Setting x and y coordinates for the CiscoIPPhoneImage object is not supported. The image always appears at location 0,0. Centering of the image is not supported if x and y are set to -1.
The Cisco SIP IP phone displays any valid title it receives. This differs from the Cisco CallManager phones in that the CiscoIPPhoneGraphicMenu object does not display a title even if it receives one and the CiscoIPPhoneImage object displays the previous menu item or "Services" rather than received titles.
Cisco CallManager phones allow embedded carriage returns and line feeds in menu items. In the Cisco SIP IP phone, carriage returns and line feeds are discarded.
The Cisco SIP IP phone always displays the full set of directory soft keys. For Cisco CallManager phones, the soft keys can change depending on what type of object it receives.
A parameter is sent along with the initial request for a Services or Directory URL, which differentiates the Cisco SIP IP phone from other types of phones.
For more information about using XML on your Cisco SIP IP phone, refer to the following links or documents:
Developing Cisco IP Phone Services by Darrick Deel, Mark Nelson, and Anne Smith, ISBN 1-58705-060-9.
Supported Features
In addition to the features illustrated in Figure 1-2, the Cisco SIP IP phone also provides the following features.
Physical Features
Adjustable ring tone.
Hearing-aid compatible handset.
Headset compatibility.
Integrated two-port Ethernet switch that allows the telephone and a computer to share a single Ethernet jack.
Direct connection to a 10BASE-T or 100BASE-T Ethernet (RJ-45) network (half- or full-duplex connections are supported).
Large (4.25 x 3 in or 10.79 x 7.62 cm) display with adjustable contrast.
Network Features
IP address assignment—Using Dynamic Host Configuration Protocol (DHCP) client or manually configuring using a local setup menu.
Network startup using DHCP and TFTP.
Telnet support—Allows the user to use Telnet to connect directly to the Cisco SIP IP phone to debug and troubleshoot the phone. See the "Managing Cisco SIP IP Phones" section for more information on configuration parameters.
Ping support—Allows the user to use ping to see if a Cisco SIP IP phone is operational and how long the response time is from the phone.
Traceroute support—Allows the user to use traceroute to see the path that a Cisco SIP IP phone traverses in the route to its desired destination.
Configuration Features
The Cisco SIP IP phone provides the ability to do the following:
Configure Ethernet port mode and speed
Register with or unregister from a proxy server
Register with or unregister from a backup proxy server
Specify a TFTP boot directory
Configure a label for phone identification display purposes
Configure a name for caller identification purposes for each active line on a phone
Configure a 12- or 24-hour user interface time display
Lock and unlock the phone from the Settings menu
Codec and Protocol Support
G.711 (u-law and a-law) and G.729a audio compression.
In-band dual tone multifrequency (DTMF) support for touch-tone dialing.
Out-of-band DTMF signaling for codecs that do not transport the DTMF signaling correctly (for example, G.729 or G.729a).
Local (180 Ringing) or remote (183 Session Progress) call progress tone.
Audio/Video Transport (AVT) payload type negotiation.
Current date and time support via Simple Network Time Protocol (SNTP) and time zone and daylight saving time support.
Call redirection information support via the Diversion header.
Third-party call control via delayed media negotiation. A delayed media negotiation is one where the Session Description Protocol (SDP) information is not completely advertised in the initial call setup.
Support for endpoints specified as fully qualified domain names (FQDNs) in the SDP.
Remote reset and dial-plan update support (via the Event header in NOTIFY messages).
Dial-plan support that enables automatic dialing and automatic generation of a secondary dial tone.
Local directory configuration (save and recall) and automatic dial completion—Each time a call is successfully made or received, the number is stored in a local directory that is maintained on the phone. The maximum number of entries is 32. Entries are aged-out according to usage and age. The oldest entry that has been called the least number of times is overwritten first. This feature cannot be programmed by the user; however, up to 20 entries can be "locked" (via the Locked soft key) so that they will never be deleted.
Message waiting indication (via unsolicited NOTIFY)—Lights to indicate that a new voice message is in a subscriber's mailbox. If the subscriber listens to the message but does not save or delete the message, the light remains on. If a subscriber listens to the new message or messages, and saves or deletes them, the light goes off. The message waiting indicator is controlled by the voice-mail server. The indication will be saved over a phone upgrade or reboot.
Speed dial to voice mail using the messages button.
Do not disturb—Allows the user to instruct the system to intercept incoming calls during specified periods of time when the user does not want to be disturbed.
Multiple directory numbers—Allows the Cisco SIP IP phone to have up to six directory numbers or lines.
Call waiting (enabled)—Plays an audible tone to indicate that an incoming call is waiting. The user can then put the existing call on hold and accept the other call. The user can alternate between the two calls.
Call waiting (disabled)—Allows the user to instruct the system to block call waiting calls during a specified period of time.
Direct number dialing—Allows users to initiate or receive a call using a standard E.164 number format in a local, national, or international format.
Direct URL dialing—Provides the ability to place a call using an e-mail address instead of a phone number.
Caller ID blocking—Allows the user to instruct the system to block a phone number or e-mail address from phones that have caller identification capabilities.
Anonymous call blocking—Allows the user to instruct the system to block any calls for which the identification is blocked.
Three-way conferencing—Supports one phone conferencing with two other phones by providing mixing on the initiating phone. To set up a three-way conference call, see the "Making Conference Calls" section in Chapter 3 of the Cisco IP Phone Models 7960 and 7940 User Guide .
Call Options
Call forward (network)—Allows the Cisco SIP IP phone user to request forwarding service from the network (via a third-party tool that enables this feature to be configured). When a call is placed to the user's phone, it is redirected to the appropriate forward destination by the SIP proxy server.
Call hold—Allows the Cisco SIP IP phone user (user A) to place a call (from user B) on hold. When user A places user B on hold, the two-way RTP voice path between user A and user B is temporarily disconnected, but the call session is still connected. When user A takes user B off hold, the two-way RTP voice path is reestablished.
Call transfer—Allows the Cisco SIP IP phone user (user A) to transfer a call from one user (user B) to another user (user C). User A places user B on hold and calls user C. If user C accepts the transfer, a session is established between user B and user C and the session between user A and user B is terminated.
Three-way calling—Allows a "bridged" three-way call. When a three-way call is established, the Cisco SIP IP phone through which the call is established acts as a bridge, mixing the audio media for the other parties.
Routing and Proxy Features
User-defined proxy routing
The Route attribute of the template tag in the dial-plan template file can be used to indicate to which proxy (default, emergency, FQDN) the call should be initially routed. For example, to configure an emergency proxy, specify the value of the Route attribute as "emergency."
Backup SIP proxy
When the primary proxy does not respond to the INVITE message sent by the Cisco SIP IP Phone after the configured number of retries, the Cisco SIP IP Phone sends the INVITE to the backup proxy. This is independent from the proxy defined in the Route attribute in the dial-plan template used.
The Cisco SIP IP phone attempts to register with the backup proxy. All interactions with the backup proxy, such as authentication challenges, are treated the same as the interactions with the primary proxy.
The backup proxy is used only with new INVITE messages that fail to communicate with the primary proxy. Once the backup proxy is used, it is active for the duration of the call.
The location of the backup SIP proxy can be defined as an IP address in the default configuration file. Refer to the proxy_backup and proxy_backup_port parameters in the "Modifying the SIP Settings" section .
Emergency SIP proxy
An optional emergency SIP proxy can be configured with the Route attribute of the template tag in the dial-plan template file.
When an emergency SIP proxy is configured and a call is initiated, the phone generates an INVITE message to the address specified in the proxy_emergency parameter. The emergency proxy is used for the call duration.
The location of the emergency proxy can be defined as an IP address in the default configuration file. Refer to the proxy_emergency and proxy_emergency_port parameters in the "Modifying the SIP Settings" section.
Support of DNS SRV
The Domain Name Server (DNS SRV) is used to locate servers for a given service.
SIP on Cisco SIP IP phones uses a DNS SRV query to determine the IP address of the SIP proxy or redirect server. The query string generated is in compliance with RFC 2782 and prepends the protocol label with an underscore (_), as in "_protocol._transport." The addition of the underscore reduces the risk of the same name being used for unrelated purposes.
In compliance with RFC 2782 and the draft-ietf-sip-srv-01 specification, the system can remember multiple IP addresses and use them properly. In the draft-ietf-sip-srv-01 specification, it is assumed that all proxies returned for the SRV record are equivalent such that the phone can register with any of the proxies and initiate a call using any other proxy.
Configurable voice activity detection
Voice activity detection (VAD) can be enabled or disabled with the enable_vad parameter. Use a value of 0 to disable and a value of 1 to enable. Refer to the enable_vad parameter in "Modifying the SIP Settings" section.
Distinctive alerting
If the INVITE message contains an Alert-Info header, distinctive ringing is invoked. The format of the header is "Alert-info: x". The value of "x" can be any number. This header is received only by the phone and is not generated by the phone.
Distinctive ringing is supported when the phone is idle or during a call. In the idle mode, the phone rings with a different cadence. The selected ringing type plays twice with a short pause in between. In call-waiting mode, two short beeps are generated instead of one long beep.
Network Address Translation and outbound proxy
Network Address Translation (NAT) can be enabled or disabled with the nat_enable parameter. You can configure the address of the NAT or firewall server using the nat_address parameter.
You can configure the IP address and port number of the outbound proxy server. When outbound proxy is enabled, all SIP requests are sent to the outbound proxy server instead of to the proxyN_address. All responses continue to reconcile the normal Via processing rules. The media stream is not routed through the outbound proxy.
NAT and outbound proxy modes can be independently enabled or disabled. The received= tag is added to the Via header of all responses if there is no received= tag in the uppermost Via header and the source IP address is different from the IP address in the uppermost Via header. Responses are sent back to the source under the following conditions:
If a received= tag is in the uppermost Via header, the response is sent back to the IP address contained in the received= tag.
If there is no received= tag and the IP address in the uppermost Via header is different from the source IP address, the response is sent back to the source IP address. Otherwise the response is sent back to the IP address in the uppermost Via header.
Note For information on how to use the standard telephony features and URL dialing, refer to the documents
listed in the "Related Documentation" section
on.
Character Support
The Cisco SIP IP phone supports the ISO 8859-1 Latin1 characters. The following languages are supported:
French (fr), Spanish (es), Catalan (ca), Basque (eu), Portuguese (pt), Italian (it), Albanian (sq), Rhaeto-Romanic (rm), Dutch (nl), German (de), Danish (da), Swedish (sv), Norwegian (no), Finnish (fi), Faroese (fo), Icelandic (is), Irish (ga), Scottish (gd), English (en), Afrikaans (af), and Swahili (sw).
The following languages are not supported:
Zulu (zu) and other Bantu languages using Latin Extended-B letters, Arabic in North Africa, and Guarani (gn) missing GEIUY with tilde (~).
Note The XML cards, information text, and menus are all in English. These items are built into the phone
image and cannot be changed.
ISO 8859-1 Latin1 characters can be used in the following areas:
Caller ID information. When a SIP message is received with ISO 8859-1 Latin1 characters in the caller ID strings, those caller ID strings are displayed on the Cisco SIP IP phone LCD with the correct ISO 8859-1 Latin1 characters.
Services menu applications written in CMXML. The customer can develop language-specific applications for a particular region. For example, an application that displayed the current weather in Sweden using Swedish language characters can be displayed on the Cisco SIP IP phone. If the customer develops the same application for a Spanish town, the application could be translated into Spanish.
Line key labels. The line keys can be configured to support the Latin1 characters. The line key name can be specified in the configuration file, and it will be displayed correctly. The Latin1 characters cannot be used in the lineX_name, but can be used in the lineX_shortname and lineX_displayname. If the proxy supports Latin1 characters in the To/From headers, they can be used in the lineX_name parameter as well.
Supported Protocols
The Cisco SIP IP phone supports the following standard protocols:
Domain Name Server (DNS)—Used in the Internet for translating names of network nodes into addresses. SIP uses DNS to resolve the host names of endpoints to IP addresses.
Dynamic Host Configuration Protocol (DHCP)—Used to dynamically allocate and assign IP addresses. DHCP allows you to move network devices from one subnet to another without administrative attention. If using DHCP, you can connect Cisco SIP IP phones to the network and become operational without having to manually assign an IP address and additional network parameters.
The Cisco SIP IP phone complies with the DHCP specifications documented in RFC 2131. By default, Cisco SIP IP phones are DHCP-enabled.
Internet Control Message Protocol (ICMP)—A network layer Internet protocol that enables hosts to send error or control messages to other hosts. ICMP also provides other information relevant to IP packet processing.
The Cisco SIP IP phone supports ICMP as it is documented in RFC 792.
Internet Protocol (IP)—Anetwork layer protocol that sends datagram packets between nodes on the Internet. IP also provides features for addressing, type-of-service (ToS) specification, fragmentation and reassembly, and security.
The Cisco SIP IP phone supports IP as it is defined in RFC 791.
Real-Time Transport Protocol (RTP)—Transports real-time data (such as voice data) over data networks. RTP also has the ability to obtain quality of service (QoS) information.
The Cisco SIP IP phone supports RTP as a media channel.
Session Description Protocol (SDP)—An ASCII-based protocol that describes multimedia sessions and their related scheduling information.
The Cisco SIP IP phone uses SDP for session description.
Simple Network Time Protocol (SNTP)—Sychronizes computer clocks on an IP network. The Cisco SIP IP phones use SNTP for their date and time support.
Transmission Control Protocol (TCP)—Provides a reliable byte-stream transfer service between two endpoints on an internet. The Cisco SIP IP phone supports TCP for Telnet sessions only.
Trivial File Transfer Protocol (TFTP)—Allows files to be transferred from one computer to another over a network. The Cisco SIP IP phone uses TFTP to download configuration files and software updates.
User Datagram Protocol (UDP)—A simple protocol that exchanges data packets without acknowledgments or guaranteed delivery. SIP can use UDP as the underlying transport protocol. If UDP is used, retransmissions are used to ensure reliability. UDP fragmentation is supported.
The Cisco SIP IP phone supports UDP as it is defined in RFC 768 for SIP signaling.
Hypertext Transfer Protocol (HTTP)—The phone contains limited support for HTTP 1.1. The Cisco SIP IP phone uses HTTP to retrieve Cisco CallManager XML files.
Prerequisites
For the Cisco SIP IP phone to successfully operate as a SIP endpoint in your network, your network must meet the following requirements:
For more information about configuring VoIP, refer to theCisco IOS Voice, Video, and Fax Configuration Guide, Release 12.2, for the appropriate access platform. For more information about configuring SIP VoIP, refer to the "Configuring SIP for VoIP" chapter.
VoIP gateways are configured for SIP.
A TFTP server is active and contains the latest Cisco SIP IP phone firmware image in its root directory.
A proxy server is active and configured to receive and forward SIP messages.
Cisco SIP IP Phone Connections
The Cisco SIP IP phone has connections for connecting to the data network, for providing power to the phone, and for connecting a headset to the phone. Figure 1-3 illustrates the connections on the Cisco SIP IP phone.
Figure 1-3 Cisco SIP IP Phone Cable Connections
Connecting to the Network
The Cisco SIP IP phone has two RJ-45 ports that each support 10/100-Mbps half- or full-duplex Ethernet connections to external devices—a network port (labeled 10/100 SW) and an access port (labeled 10/100 PC). You can use either Category 3 or Category 5 cabling for 10-Mpbs connections, but use Category 5 for 100-Mbps connections. On both the network port and the access port, use full-duplex mode to avoid collisions.
Network Port (10/100 SW)
Use the network port to connect the phone to the network. You must use a straight-through cable on this port. The phone can also obtain inline power from the Catalyst switch over this connection. See the "Connecting to Power" section for details.
Access Port (10/100 PC)
Use the access port to connect a network device, such as a computer, to the phone. You must use a straight-through cable on this port.
Connecting to Power
The Cisco SIP IP phone can be powered by the following sources:
External power source—Optional Cisco AC adapter and power cord for connecting to a standard wall receptacle.
WS-X6348-RJ45V 10/100 switching module—Provides inline power to the Cisco SIP IP phone when connected to a Catalyst 3500, 4000, or 6000 family 10/100BASE-TX switching module.
This module sends power on pins 1 and 2, and 3 and 6.
WS-PWR-PANEL—Power patch panel provides power to the Cisco SIP IP phone, which allows the Cisco SIP IP phone to be connected to existing Catalyst 4000, 5000, and 6000 family 10/100BASE-TX switching modules.
This module sends power on pins 4, 5, 7, and 8.
WS-X4148-RJ45V—48-port 10/100 Ethernet with inline power module for the Catalyst 4006.
WS-X4095-PEM—VoIP DC Power Entry module for the Catalyst 4006.
WS-X4608-2PSU and WS-X4608—External -48VDC power shelf common equipment for the Catalyst 4006 with two AC-to-DC power supply units (PSUs) and one empty bay for redundant option, and the 110V 15A AC-to-48VDC PSU redundant option for the power shelf.
WS-C3524-PWR-XL-EN—Catalyst 3524-PWR XL switch.
Note Only the network port (labeled 10/100 SW) supports inline power from the Catalyst switches.
Using a Headset
The Cisco SIP IP phone supports a four- or six-wire headset jack. Specifically, the Cisco SIP IP phone supports the following Plantronics headset models:
Tristar Monaural
Encore Monaural H91
Encore Binaural H101
The volume and mute controls also adjust volume to the earpiece and mute the speech path of the headset. The headset activation key is located on the front of the Cisco SIP IP phone.
Note When using a headset, an amplifier is not required. However, a coil cord is required to connect the
headset to the headset port on the back of your Cisco IP Phone 7960/7940. For information on ordering
compatible headsets and coil cords for the Cisco IP Phone 7960/7940, go to the following URL:
To function in the IP telephony network, the Cisco SIP IP phone must be connected to a networking device, such as a Catalyst switch, to obtain network connectivity.
The Cisco SIP IP phone has an internal Ethernet switch, which enables it to switch traffic coming from the phone, access port, and network port.
If a computer is connected to the access port, packets traveling to and from the computer and to and from the phone share the same physical link to the switch and the same port on the switch.
This configuration has the following implications for the VLAN configuration on the network:
The current VLANs might be configured on an IP subnet basis, and additional IP addresses might not be available to assign the phone to a port so that it belongs to the same subnet as other devices (PC) connected to the same port.
Data traffic present on the VLAN supporting phones might reduce the quality of VoIP traffic.
You can resolve these issues by isolating the voice traffic onto a separate VLAN on each of the ports connected to a phone. The switch port configured for connecting a phone would have separate VLANs configured for carrying the following traffic:
Voice traffic to and from the Cisco SIP IP phone (auxiliary VLAN).
Data traffic to and from the PC connected to the switch through the access port of the Cisco SIP IP phone (native VLAN).
Isolating the phones on a separate, auxiliary VLAN increases the quality of the voice traffic and allows a large number of phones to be added to an existing network where there are not enough IP addresses.
For redundancy, you can use the Cisco AC adapter even if you are using inline power from the Catalyst switches. The Cisco SIP IP phone can share the power load being used from the inline power and external power source. If either the inline power or the external power goes down, the phone can switch entirely to the other power source.
To use this redundancy feature you must set the inline power mode to auto on the Cisco Catalyst switch. Next, connect the unpowered Cisco SIP IP phone to the network. After the phone powers up, connect the external power supply to the phone.
For more information, refer to the documentation included with the Catalyst switch or available online at the following URL:
