- About This Document
- Get Started
- Customize Standard Features
- Configure SIP and NAT
- Configure Security, Quality, and Network Features
- Provisioning
- Configure Dial Plan
- Configure Regional Parameters and Supplementary Services
- Cisco Unified IP Conference Phone 8831 for Third-Party Call Control Field Reference
- Related Documentation
Configure SIP and NAT
The Cisco Unified IP Conference Phone 8831 for Third-Party Call Control uses the following protocol:
This chapter describes how to configure the SIP phone protocol:
SIP and Cisco Unified IP Conference Phone 8831 for Third-Party Call Control
The Cisco Unified IP Conference Phone 8831 for Third-Party Call Control 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 requesting phone is called the SIP user agent server (UAS), while the receiving 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 is routed back to the UAS, and a direct peer-to-peer session is established between the two UAs. Voice traffic is transmitted between UAs over dynamically-assigned ports using Real-time Protocol (RTP).
RTP transmits real-time data such as audio and video; it 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
To guarantee state-oriented communications, Cisco conference 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 UDP ports have of being blocked by corporate firewalls. With TCP, new ports do not need to be opened 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 agents are served by different domains, for example, you would 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 conference 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 host names, priority, listening ports, and so forth. The Cisco conference phone tries to contact the hosts in the order of their priority.
If the Cisco conference 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 via primary proxy first. If there is no response for the new INVITE from the primary proxy, after timeout, the phone should attempt with the alternate proxy.
Dual registration is supported per line basis. Three new parameters are added which can be configured via Web GUI and remote provisioning:
- Alternate Proxy—Default is empty
- Alternate Outbound Proxy—Default is empty
- Dual Registration—Default is NO (turned off)
Upon configuring the parameters, reboot the phone for the feature to take effect.
Note The administrator should specify a value for primary proxy (or primary outbound proxy) and alternate proxy (or alternate outbound proxy) for the feature to function properly.
Limitations for Dual Registration and DNS SRV Redundancy
The limitations for Dual Registration and DNS SRV redundancy are as follows:
- When Dual Registration is enabled, DNS SRV Proxy Fallback/Recovery must be disabled.
- Do not use Dual Registration in conjunction with other Fallback/Recovery mechanisms. For example: Broadsoft mechanism.
- There is no recovery mechanism for feature request. However, the administrator can adjust the re-registration time for a prompt update of the registration state for primary and alternate proxy.
Alternate Proxy and Dual Registration
When the Dual Register parameter is set to No, Alternate Proxy is ignored.
Register Upon Failover/Recovery
Fallback Behavior
The fallback occurs when the current registration expires or Proxy Fallback Intvl fires.
If the Proxy Fallback Intvl exceeds, 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 is triggered 600 seconds later.
When the value for Register Expires is 800 seconds and Proxy Fallback Intvl is 1000 seconds, the fallback is triggered at 800 seconds.
After successfully registering back to primary server, all the SIP messages go to primary server.
RFC3261 Support
The Cisco Unified IP Conference Phone 8831 for Third-Party Call Control supports RFC-3261, the SIP UPDATE Method.
Support for SIP NOTIFY XML-Service
The Cisco Unified IP Conference Phone 8831 for Third-Party Call Control support 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 be 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:
Configure SIP
SIP settings for the Cisco Unified IP Conference Phone 8831 for Third-Party Call Control are configured for the phone in general and for the extensions.
Configure Basic SIP Parameters
To configure general SIP parameters, navigate to Admin Login > advanced > Voice > SIP. Under SIP Parameters, make these changes:
Configure SIP Timer Values
All SIP timer values are in seconds. To configure SIP timer values, navigate to Admin Login > advanced > Voice > SIP. Under SIP Timer Values (sec), make these changes:
|
|
---|---|
RFC-3261 T1 value (RTT estimate). Ranges from 0 to 64 seconds. Defaults to 0.5 seconds. |
|
RFC-3261 T2 value, the maximum retransmit interval for non-INVITE requests and INVITE responses. Ranges from 0 to 64 seconds. Defaults to 4 seconds. |
|
The length of time the INVITE is valid. If you enter 0, the Expires header is not included in the request. Ranges from 0 to 2000000. Defaults to 240 seconds. |
|
ReINVITE request Expires header value. If you enter 0, the Expires header is not included in the request. Ranges from 0 to 2000000. Defaults to 30 |
|
Reg Retry Intvl1 |
Interval to wait before the phone retries registration after failing during the previous registration. The range is from 1 to 2147483647. Do not enter 0. Defaults to 30 seconds. |
When registration fails with a SIP response code that does not match the Retry Reg response status code (RSC) value (see next table), the phone waits for this length of time before retrying. If this interval is 0, the phone stops trying. This value should be much larger than the Reg Retry Intvl value. The range is from 0 to 2147483647. Defaults to 1200 seconds. |
|
Random delay added to the Register Retry Intvl value when retrying REGISTER after a failure. Minimum and maximum random delay to be added to the short timer. The range is from 0 to 2147483647. Defaults to 0, which disables this feature. |
|
Random delay added to Register Retry Long Intvl value when retrying REGISTER after a failure. Minimum and maximum random delay to be added to the long timer. Random delay range (in seconds) to add to the Register Retry Long Intvl when retrying REGISTER after a failure. Defaults to 0, which disables this feature. |
|
Reg_Retry_Intvl_Cap—Maximum value of the exponential delay. The maximum value to cap the exponential backoff retry delay (which starts at the Register Retry Intvl and doubles every retry). Defaults to 0, which disables the exponential backoff (that is, the error retry interval is always at the Register Retry Intvl). When this feature is enabled, the Reg Retry Random Delay is added to the exponential backoff delay value. The range is from 0 to 2147483647. |
Configure Response Status Code Handling
To configure response status code handling, under Response Status Code Handling make these changes:
Configure RTP Parameters
To configure Real-time Transport Protocol (RTP), navigate to Admin Login > advanced > Voice > SIP. Under RTP Parameters, configure these fields:
- RTP Port Min —Minimum port number for RTP transmission and reception. <RTP Port Min> and <RTP Port Max> defines a range that contains at least 10 even number ports (twice the number of lines); for example, 100–106. Defaults to 16384.
- RTP Port Max —Maximum port number for RTP transmission and reception. <RTP Port Min> and <RTP Port Max> should define a range that contains at least 10 even number ports (twice the number of lines); for example, 100–106. Defaults to 16482.
- RTP Packet Size —Packet size in seconds. The range is from 0.01 to 0.16. Valid values must be a multiple of 0.01 seconds. Defaults to 0.02.
- RTCP Tx Enable —To enable Real-Time Transport Control Protocol (RTCP) sender report on an active connection. Defaults to no.
During an active connection, the Cisco Unified IP Conference Phone 8831 for Third-Party Call Control sends out compound RTCP packets. Each compound RTP packet, except the last one, contains a sender report (SR) and a source description (SDES). The last RTCP packet contains an additional BYE packet. Each SR, except the last one, contains one receiver report (RR); the last SR carries no RR.
The SDES contains CNAME, NAME, and TOOL identifiers:
– NAME — Display Name (or Anonymous if user blocks caller ID)
Configure SDP Payload Types
Configured dynamic payloads are used for outbound calls only when the conference phone presents a Session Description Protocol (SDP) offer. For inbound calls with a SDP offer, the phone follows the caller’s assigned dynamic payload type.
The IP phone conference phones use the configured codec names in outbound SDP. For incoming SDP with standard payload types of 0-95, the IP conference phone ignores the codec names. For dynamic payload types, the phone identifies the codec by the configured codec names (comparison is case-sensitive).
To configure SDP payload types, navigate to Admin Login > advanced > Voice > SIP. Under SDP Payload Types, configure these parameters:
|
|
---|---|
Any non-standard data. Both sender and receiver must agree on a number. Ranges from 96 to 127. Defaults to 101. |
Configure SIP Settings for Extensions
To configure SIP settings, navigate to Admin Login > advanced > Voice > Extension. Under SIP Settings, configure the following fields:
Configure a SIP Proxy Server
To configure SIP proxy and registration parameters, navigate to Admin Login > advanced > Voice > Extension. Under Proxy and Registration, configure the following fields:
Configure Subscriber Information Parameters
To configure subscriber information parameters for each extension, navigate to Admin Login > advanced > Voice > Extension. Under Subscriber Information, configure the following fields:
Configure NAT Support Parameters
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.
To configure NAT support parameters on the phone:
Step 1 Click Voice > SIP and navigate to NAT Support Parameters.
Step 2 Set a value to the parameter NAT Keep Alive Intvl.
Step 3 Enter the public IP address for your router.
Step 4 Click the Extension tab and navigate to NAT Settings.
Step 5 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 6 Click Submit All Changes.
Step 7 Configure the firewall settings on your router to allow SIP traffic. See the “Configure SIP” section.