Current Publication | x


SIP Registration

You can set up your phones to periodically register with the ProxyServer or the RegistrarServer by enabling the SPn Service::X_RegisterEnable parameter. ProxyServer and RegistrarServer could be different, although they’re rarely so in practice. ProxyServer is a required parameter that you must configure on your phone while RegistrarServer is optional and assumed to be the same as the ProxyServer if not specified in the configuration.


If the server isn’t listening at the standard port, configure the correct port value in ProxyServerPort (and RegistrarServerPort as needed).

The main purpose of registration is to create and maintain a dynamic binding of the SIP/SP account to your phone’s local contact address. Service providers can also rely on this periodic message to see if your phone is online and functional. Each phone takes only one local IP address that is either statically assigned in the phone’s configuration or dynamically obtained from a local DHCP server. The method to get an IP address assigned is determined by the value of WAN Settings::AddressingType.

The SPn services for n = 1 – 6 each use a different local contact port for sending and receiving SIP messages (the default is 5060, 5061, 5062, …, and 5065 respectively). You can configure this port in the SPn Service::X_UserAgentPort parameter. ProxyServer and RegistrarServer must use the same transport protocol for SIP messages that you can set in the ProxyServerTransport parameter.

Your phones support UDP, TCP, and TLS for SIP transport. The default server port is 5060 for UDP/TCP and 5061 for TLS. When using TCP/TLS, the phones initiate a TCP/TLS connection only with the ProxyServer. All subsequent SIP messages are exchanged between the phones, and the servers must use the same connection. If for any reason the connection is closed, your phone attempts to re-establish the connection following an exponential back-off retry pattern.


Dynamic address binding through periodic registration isn’t strictly necessary if the local IP address of your phone doesn’t change. You can statically configure your phone’s contact address on the Registration Server. Also, your network administrator may be able to reconfigure the duration of your DHCP lease so that your DHCP address effectively doesn’t change.

Here is a typical REGISTER request generated by your phone:


Call-ID: 7107d244@

Content-Length: 0

CSeq: 10722 REGISTER

From: <>;tag=SP337b73f3bf7a504c3

Max-Forwards: 70

To: <>

Via: SIP/2.0/UDP;branch=z9hG4bK-f9e9e56c;rport

User-Agent: OBIHAI/OBi1062-

Contact: <sip:2404982564@>;expires=60;



Supported: replaces, eventlist, record-aware

In this example, your phone doesn’t use the Expires header in REGISTER requests. Instead, the Expires value (in seconds) is encoded as a parameter in the Contact header. The two methods are equivalent in this usage per RFC3261. Note that your phone also includes the +sip-instance parameter in the Contact header that specifies your phone’s MAC address in the UUID. You can suppress this parameter by disabling the ITSP Profile X – SIP::X_RegisterIncludeInstance option.

In some cases, your phone may not receive any response to its REGISTER from the server if an upstream router blocks the outgoing message sent by it. To cope with such a case, tell your phone to try other SIP user agent ports by specifying a comma-separated list of as many as 10 alternative ports in the SPn Service::X_UserAgentPorts parameter. Your phone then cycles through those ports to retry REGISTER until it receives a response from the server.

Third-Party Registration

You can configure your phone to use a third-party registration that registers it for an Address of Record (AOR) that isn’t the same as the account user-id. That is, the user-id in the TO header of the SIP REGISTER request is different from that in the FROM header, which always carries the account user-id.

One application is in the implementation of a shared line using the Bridged Line Appearance (BLR) method. To enable third-party registration, set the user-id to register for in the SPx Service – SIP Credentials::X_ShareLineUserID parameter.

Registration Period

You can configure the nominal registration Expires header value (implemented as a Contact header parameter value in seconds) used by your phone in REGISTER requests using the ITSP Profile X – SIP::RegistrationPeriod parameter. The server determines the actual Expires value. The server may reject the REGISTER request with 423 with a Min-Expires header value (in seconds). If that happens, your phone quickly retries with an Expires header value equal to the Min-Expires header value from the server. When the server accepts the registration, it replies with a 2xx response for the REGISTER and includes an Expires parameter value in the Contact header that matches the Contact your phone uses in the REGISTER request. However, if it isn’t found in the Contact, your phone takes the server-supplied Expires value from the Expires header of the 2xx response. If still not found, your phone assumes the server-supplied value is 3600 seconds.

If the server-supplied Expires value is less than the Expires header value used by your phone, it takes the server version to compute the next renewal interval. Otherwise, your phone uses its own Expires header value to do the same.


The server shouldn’t supply explicitly or implicitly an Expires value that is larger than what your phone has asked for, as that would be a protocol violation. Your phone, however, ignores such an error.

Your phone computes the next renewal time by subtracting a percentage of the Expires value derived from the 2xx response returned by the server. Use the ITSP Profile – SIP::X_RegistrationMargin parameter to control how the margin to subtract is computed. For example: If X_RegistrationMargin is 0 or not specified, the renewal time is half-way before the expiration, if the Expires value is less than 1200s, or 600s before the expiration otherwise. If X_RegistrationMargin ≥ 1, it’s interpreted as the number of seconds (with any fractional part dropped) before the expiration time to renew registration. If X_RegistrationMargin < 1, it’s interpreted as the fraction of the current expires value to subtract from the expiration time to get the time for the next renewal. For example, if X_RegistrationMargin = 0.01 and the Expires value is 300, then the next renewal goes out 3 seconds before the expiration time.

REGISTER Final Non-2xx Response Handling

When registration encounters an error, your phone can schedule retries based on the type of error. Each recognizable error type is represented by a 3-digit code. Error codes 300 – 699 are the error response codes returned by the server, while 900-999 are used to indicate other errors. The following 9xx error codes are related to registration:

900 = Timeout waiting for a response from the server

901 = Cannot resolve the server name or the host is not reachable

For 3xx class responses with a valid Contact header, your phone follows the given Contact to retry registration quickly. If a valid Contact is not found, or if the number of consecutive redirections has reached 5, your phone considers the 300 response an error and performs standard error handling.

For 401 and 407 responses with a valid Proxy-Authenticate or WWW-Authenticate header, your phone retries registration quickly and includes the properly computed Proxy-Authorization or Authorization header. However, if the error response contains no valid Proxy-Authenticate or WWW-Authenticate header, and if the number of consecutive 401/407 responses received has reached 2, your phone considers the 401/407 a true error and performs standard error handling.

For 423 responses with a valid Min-Expires header value, your phone retries registration quickly with a new Expires value that conforms to the Min-Expires value from the server. However, if the Min-Expires header is not present in the response or the value is not larger than the current Expires value sent by your phone, your phone considers it an error and performs standard error handling.

For 5xx – 6xx responses with a Retry-After header, your phone schedules a retry after the specified value.

The standard handling is by waiting for a certain number of seconds before trying to register again. The number of seconds to wait is determined by the rules specified in the ITSP Profile X – SIP::RegisterRetryResponseCodes parameter on the actual error code. The format of this parameter is the same as a digit map. Let’s consider the default value of this parameter:


Each rule is a substitution where a certain error code or error code pattern is mapped to the number of seconds to wait. With this example, your phone waits for 120 seconds for 401 and 407 error codes, 120 seconds for 403 and 404 error codes, randomly between 120 and 200 seconds for 990 and 991 error codes, and a fixed default value for all other error codes. The fixed default value is configured in the ITSP Profile X – SIP::RegisterRetryInterval parameter. The syntax w{a}{b} specifies a random range of between {a} seconds and {b} seconds. Error codes not covered by these rules cause your phone not to retry registration after the error.

SIP Outbound Proxy Server

An OutboundProxy server can be configured on your phone such that all outbound requests are sent via the outbound proxy server instead of directly to the ProxyServer or RegistrarServer. If the outbound proxy server is listening at a non-standard port, the correct port value must be specified in the OutboundProxyPort parameter. The OutboundProxy may use a different transport protocol from the ProxyServer. The transport protocol to use to communicate with the OutboundProxy can be set in the OutboundProxyTransport parameters. If OutboundProxyTransport is TCP/TLS, your phone initiates a TCP/TLS connection only with the OutboundProxy. All subsequent messages exchanged between your phone and the servers MUST use the same connection. If for any reason the connection is closed, your phone attempts to re-establish the connection with the OutboundProxy following an exponential back-off retry pattern.

Even though your phone only exchanges messages directly with the OutboundProxy, the ProxyServer, ProxyServerPort, and ProxyServerTransport parameters are still very much relevant and important since the SIP requests sent by your phone to the server are still formed based on these values, not based on the OutboundProxy value. In fact, the OutboundProxy value should never appear in the SIP requests generated by your phone (unless the OutboundProxy has the same value as the ProxyServer).

Some server implementations include the outbound proxy server in a Record-Route header such that your phone should not respect the locally configured OutboundProxy value after the initial INVITE is sent for a new call. This behavior can be achieved by enabling the option ITSP Profile X – SIP::X_BypassOutboundProxyInCall. However, this option has no effect when the OutboundProxyTransport is TCP/TLS, as your phone always uses the same connection to send messages to the server.

DNS Lookup of SIP Servers   

When sending out SIP requests to the server, your phone looks up the IP address of the server, using DNS query if the server is specified as a domain name instead of an IP address. If an Outbound Proxy Server is configured, it is used instead of the SIP Proxy Server or SIP Registration Server. The resolution of the server domain name into IP address is performed in the following manner:

If ITSP Profile X – SIP::X_DnsSrvAutoPrefix is enabled, resolve the name as DNS A Record, DNS SRV Record and as DNS SRV record with a service prefix prepended to the name in parallel by sending 3 queries to each DNS server at the same time. The service prefix to prepend to the name depends on the transport protocol being used; for SIP, _sip._udp. for UDP, _sip._tcp. for TCP and _sip._tls. for TLS. If more than one valid result is returned from the queries, the DNS SRV result for the name with prefix has the highest priority, then the DNS SRV result for the name without the prefix, then the DNS A result.

Otherwise, resolve the name as a DNS A record and as a DNS SRV Record in parallel by sending 2 queries to each DNS server. If both queries return a valid result, the DNS SRV result is taken over the DNS A result.

If no valid results are returned, your phone considers the SIP request failed with the error code 901.

If the result from the DNS query is an SRV record, the server port is also taken from that record (the server port value configured on your phone is ignored). Otherwise, the server port is taken from the configured value. If no value is specified, 5060 is used. We recommend setting the ProxyServerPort to 0 (that is, the unspecified value) if DNS SRV lookup is intended for the service.

NAT Traversal Considerations

If your phone is located behind NAT with respect to the service provider equipment, it can discover the mapped external address corresponding to its local SIP contact address as seen by the server. This may help in some cases where a gateway router’s SIP ALG implementation is causing communication problems between your phone and the server. Your phone can discover the mapped external address in one of the following ways:

From the “received=” and “rport=” parameters of the VIA header of the REGISTER response sent by the server. These two parameters tell your phone its mapped IP address and port number, respectively. This method is used if periodic registration is enabled on your phone.

From the response to a STUN binding request your phone sent to a STUN server. This method is used by enabling X_KeepAliveEnable and setting the X_KeepAliveMsgType parameter to “stun”. In this case, the STUN server is taken from the X_KeepAliveServer parameter, if it is specified. Otherwise, the keep-alive messages are sent to the same server where a REGISTER request would be sent to. The latter is the most effective way of using STUN to discover the mapped external contact address.

From the value of the ITSP Profile X – SIP::X_PublicIPAddress parameter.

If discovered by one of the methods above, your phone uses the discovered external IP address and port to replace its private address and port when generating SIP requests when the ITSP Profile X – SIP::X_DiscoverPublicAddress option is also enabled. The substitution of private addresses with public addresses applies to the Contact header of any SIP requests and the c= line in SDP. If the option X_UsePublicIPAddressInVia is also enabled, the Via address is also substituted. However, this usually isn’t necessary.

Your phone can also include an empty rport parameter in the Via header of outbound SIP requests if the option ITSP Profile X – SIP::X_UseRport option is enabled. This parameter is sometimes needed to prompt the server to insert an rport parameter value in the response. It should also prompt the server to send the response to the port where the request originated from (that is, according to the source port of the IP header of the packet). However, as such behavior on the server is considered standard by many, the empty rport parameter has become superfluous in practice.

Keep Alive Messages

In addition to periodic registration with the server, your phone can be instructed to send out periodic keep alive messages on the same network path to keep the NAT pinhole open. For this purpose, it is recommended the keep alive messages are sent to the same proxy server responsible for registration. The keep alive messages may be dropped by the server unprocessed. However if STUN binding request are used as keep alive messages, it is recommended that the server return a valid STUN binding response to each request. The parameters that control the sending of keep alive messages are:

Keep Alive Messages

Parameter Group



SPn Service
Enable sending of keep alive message. If set to true, your phone sends periodic keep-alive messages to the destination specified in X_KeepAliveServer and X_KeepAliveServerPort, at the interval specified in X_KeepAliveExpires. The content of this message is the ASCII string keep-alive\r\n
SPn Service
Keep alive period in seconds.
SPn Service
Hostname or IP address of keep alive server.
SPn Service
UDP port of the keep alive server.
SPn Service
The type of keep alive messages to send out periodically if keep-alive is enabled. One of the following:

keep-alive: The string keep-alive

empty: A blank line

stun: A standard STUN binding request. Your phone uses the binding response to form its contact address for REGISTRATION

custom: use the value of X_CustomeKeepAliveMsg 

options: a valid SIP OPTIONS request. No response to this request from the server triggers a proxy failover if proxy redundancy is enabled

notify: a valid SIP NOTIFY request. No response to this request from the server triggers a proxy failover if proxy redundancy is enabled.

SPn Service
Defines the custom message to be used when X_KeepAliveMsgType is custom. The value should have the following format:

NOTIFY may be replaced by any other SIP method, such as PING, the event parameter is optional and is only applicable if the method is NOTIFY.

If event is not specified, the 'keep-alive' event is used with NOTIFY.

The user parameter is optional. If not specified, the request-uri won’t have a userid, and the TO header field uses the same userid as the FROM header, which is the local account userid. If user is specified, it is used as the userid in the Request-URI and TO header.

SIP messages for keep-alive are sent only once without retransmission. Response to the SIP messages are ignored by the phone.

SIP Proxy Server Redundancy and Dual REGISTRATION

Server Redundancy specifically refers to your phone’s capability to:

Look for a working server to REGISTER with from a list of candidates

Switch to another server once the server that it currently registers with becomes unresponsive

As such, device registration must be enabled to use the server redundancy feature. Other SIP requests, such as INVITE or SUBSCRIBE, are sent to the same server that your phone currently registers with.

If the Outbound Proxy Server is provided, server redundancy is applied to the Outbound Proxy Server instead of the REGISTRATION server. Server redundancy behavior is enabled by enabling the ITSP Profile X – SIP::X_ProxyServerRedundancy parameter (which is disabled by default).

Another requirement for using the server redundancy feature is that the underlying server must be configured in your phone as a domain name instead of an IP address. This allows your phone to collect a list of candidate servers based on DNS query. The domain name may be looked up as DNS A record or DNS SRV record. For A records, all the IP addresses returned by the DNS server are considered to have the same priority. For SRV records, the hosts returned by the DNS server can be each assigned a different priority.

After a list of candidate servers is obtained, your phone first looks for a working server according to the stated priority. A working server means one that your phone can successfully register with. This is known as the Primary Server. Subsequently, your phone maintains registration with the primary server the usual way. However, if no working server is found after traversing the entire list, your phone takes a short break and repeats the search in the same order.

While maintaining registration with the Primary Server, your phone continually attempts to fall back to one of the candidate servers that has higher priority than the primary server, if any. The list of candidate servers that your phone is trying to fall back on is known as the primary fallback list, which may be empty.

In addition, your phone can be configured to maintain a secondary registration with a server that has lower or equal priority than the primary server. Secondary registration can be enabled by setting the X_SecondaryRegistration parameter to true. If X_ProxyServerRedundancy is false, however, X_SecondaryRegistration does not have any effect. If this feature is enabled, as soon as a primary server is found, your phone searches for a working secondary server in the same manner from the list of candidate servers that are of lower or equal priority than the primary server. Similarly, once a secondary server is found, your phone forms a secondary fallback list to continually attempt to fall back on if the list is not empty.

The interval for checking the primary fallback list and the secondary fallback list are configured in the X_CheckPrimaryFallbackInterval and X_CheckSecondaryFallbackInterval parameters, respectively. These parameters are specified in seconds and the default value is 60 for both.


Secondary server exists implies primary server exists.

If the secondary server exists, it immediately becomes the primary server when the current primary server fails. Your phone then starts searching for a new secondary server if the candidate set is not empty.

The candidate list may change (lengthened, shortened, priority changed, and so forth) on every DNS renewal (based on the entry’s TTL). Your phone rearranges the primary and secondary servers and fallback lists accordingly, whichever is applicable.

If the server redundancy feature is disabled, your phone resolves only one IP address from the server’s domain name and won’t attempt to try other IP addresses if the server is not responding.

SIP Privacy

Your phone observes inbound caller privacy and decodes the caller’s name and number from SIP INVITE requests by checking the FROM, P-Asserted-Identity (PAID for short), and Remote-Party-ID (RPID for short) message headers. All these headers may carry the caller’s name and number information.

If PAID is present, your phone takes the name and number from it. Otherwise, it takes name and number from RPID if it is present, or from the FROM header otherwise. RPID, if present, includes the privacy setting desired by the caller. The privacy setting may indicate one of the following options:

off = No privacy requested. Your phone shows name and number.

full = Full privacy requested. Your phone hides both name and number.

name = Name privacy requested. Your phone shows the number but hides the name.

uri = URI privacy requested. Your phone shows the name but hides the number.

Regardless, if PAID exists or not, your phone always takes the privacy setting from the RPID if it is present in the INVITE request.


If the resulting caller name is “Anonymous” (case-insensitive), your phone treats it as if the caller is requesting full privacy.

For outbound calls, the caller’s preferred privacy setting can be stated by phone in an RPID header of the outbound INVITE request. To enable this behavior, the ITSP Profile X – SIP::X_InsertRemotePartyID parameter must be set to true, which is the default value of this parameter. Your phone supports only two outbound caller privacy settings: privacy=off or privacy=full. The RPID header generated by your phone carries the same name and number as the FROM header. If outbound caller-ID is blocked, phone sets privacy=full in RPID and also sets the display name in the FROM and RPID headers to “Anonymous” for backward compatibility. Your phone won’t insert PAID in outbound INVITE requests. You can further instruct your phone to use sip:anonymous@localhost in the FROM header by enabling the option X_UseAnonymousFROM (that is, in this case your phone uses From: “Anonymous” <sip:anonymous@localhost>).

Your phone also includes a Privacy: id header if X_InsertPrivacyHdr is also enabled.


Your phone supports standard STUN based on RFC3489 and RFC5389 for passing inbound RTP packets to phone when behind NAT. The parameters that control the STUN feature can be found under the section ITSP Profile X – General::

STUNEnable – Enable this feature (default is false).

STUNServer – The IP address or domain name of the external STUN server to use. STUN feature is disabled if this value is blank, which is the default.

X_STUNServerPort – The STUN Server’s listening UDP port. Default value 3478 (standard STUN port).

It should be noted that the STUN feature used in this context is only for RTP packets, not SIP signaling packets (which typically do not require STUN). Your phone sends out a STUN binding request right before making or answering a call on SPx. If the request is successful, your phone decodes the mapped external address and port from the binding response and uses them in the m= and c= lines of its SDP offer or answer sent to the peer device. If the request fails, such as STUN server not found or not responding, the call goes on without using an external address in the SDP.

Standard RTP requires the use of even numbered ports in the m= line. If the external port is not an even number, your phone changes the local RTP port, retries STUN, and continues to do this as many as four times or until an even-numbered external port is found. If the fourth trial still results in an odd-numbered external port number, the call goes on without using external address in the SDP.

Your phone supports standard ICE based on RFC5245. ICE is done on a per-call basis to automatically discover which peer address is the best route for sending RTP packets. To enable ICE on your phone, set the ITSP Profile X – General::X_ICEEnable parameter to yes (or true). The default is no (or false).

Note that ICE is more effective if STUN is also enabled. However, STUN not a requirement for using ICE on your phone. If STUN is enabled and an external RTP address different from its local address is discovered, your phone offers two ICE candidates in its SDP:

The local (host) address (highest priority)

The external (srflx or server reflexive) address

Otherwise only the local host candidate is shown in your phone’s SDP.


Your phone uses the srflx address in the m= and c= lines of the SDP if STUN is enabled and successful.

If ICE is enabled and the peer’s SDP has more than one candidate, your phone sends STUN requests to each peer candidate from its local RTP port. As soon as it receives a response from the highest priority candidate, your phone concludes ICE and uses this candidate to communicate with the peer subsequently. Otherwise your phone allows as long as 5 seconds to wait for a response from all candidates and selects the highest priority one that responds. Once ICE is completed successfully, your phone further applies the symmetric RTP concept to determine the peer’s RTP address (that is, sends to the address where the peer’s RTP packets are coming from).

ITSP Driven Distinctive Ringing

Your phone offers 10 ring and 10 call-waiting tone patterns in each ring profile. These patterns are numbered from 1 to 10. Each pattern also comes with a configurable name. A different default ring may be assigned to each trunk on your phone.

An ITSP can instruct your phone which ring to use (by name) for a call routed to SPn by inserting an Alert-Info header in the SIP INVITE sent to your phone. The Alert-Info must include a URI. For example:


When your phone receives this, it looks for a ring tone name or call-waiting tone name in the ring profile that matches the Alert-Info URI. Ring tone names are not case sensitive when compared. If a match is found, your phone plays the corresponding ring or call-waiting tone. Otherwise, your phone plays the default ring.

RTP Statistics – the X-RTP-Stat Header

When ending an established call, your phone can include a summary of the RTP statistics collected during the call in the SIP BYE request or the 200 response to the SIP BYE request sent by the peer device. The summary is carried in an X-RTP-Stat header in the form of a comma-separated list of fields. The reported fields are:

PS = Number of Packets Sent

PR = Number of Packets Received

OS = Number of bytes sent

OR = Number of bytes received

PL = Number of packets lost

JI = Jitter in milliseconds

LA = Decode latency or jitter buffer size in milliseconds

DU = Call duration in seconds

EN = Last Encoder Used

DE = Last Decoder Used

For example:

X-RTP-Stat:PS=1234,OS=34560,PR=1236,OR=24720,JI=1,DU=1230,PL=0,EN=G711U, DE=G711U

To enable the X-RTP-Stat feature, the ITSP Profile X – SIP::X_InsertRTPStats parameter must be set to true.


Your phone supports RTCP (RFC 3550) and RTCP-XR (RFC3611) with MOS statistics for VQ reporting.

Media Loopback Service

Your phone supports the media loopback draft as described in draft-mmusic-media-loopback-13.txt. Your phone supports the following media loopback features:

Loopback modes: loopback-source and loopback-mirror

Loopback types: rtp-media-loopback and rtp-packet-loopback

Loopback packet formats: encaprtp, loopbkprimer

When acting as a loopback mirror, your phone always sends primer packets so that incoming packets can get through NAT or a firewall. The media loopback feature is controlled by the following parameters (under the Phone Settings – Calling Features section):

AcceptMediaLoopback – Enable your phone to accept incoming calls that request media loopback. Default is YES.

MediaLoopbackAnswerDelay – The delay in milliseconds before your phone answers a media loopback call. Default is 0.

MediaLoopbackMaxDuration – The maximum duration to allow for an incoming media loopback call. Default is 0, which means the duration is unlimited.


Your phone rejects an incoming media loopback call if:

Phone is off hook.

Phone is ringing.

One or more calls are on hold.

Your phone terminates an inbound media loopback call already in progress when:

Phone is off-hook.

Phone is ringing.

To make an outgoing loopback call, dial one of the following star codes before dialing the target number:

*03 – Make a Media Loopback Call.

*04 – Make a RTP Packet Loopback Call.


Outbound Media Loopback Call is not subject to a call duration limit. It lasts until you hang up or until the called number ends the call.

A SIP/SP Configuration Example

The following table details a configuration example where the ITSP Profile to use is B with two SP services, SP1 and SP3, both pointing to the same ITSP Profile.

Configuration Example

Parameter Group


Example Value


ITSP Profile B – General
Standard default value is SIP
ITSP Profile B – SIP
ITSP Profile B – SIP
ITSP Profile B – SIP
SP1 Service
SP1 Service – Credentials
SP1 Service – Credentials
SP1 Service – Credentials
SP3 Service
SP3 Service – Credentials
SP3 Service – Credentials
SP3 Service – Credentials
Phone Settings


Related Topics

Machine Translation

You are cautioned that the translation of this document is generated by a machine; therefore, the translated document may have errors and be inconsistent with the original English language version of the document.

The English language version of this document shall be considered the governing document related to the Polycom product.

If there is any contradiction between the English language version of the document and the translated version of the document, the English language version of the document shall take precedence.

The translation is provided for your convenience only. Neither Google nor Polycom shall be responsible for translated content or for the performance of the translation tool. If you require further assistance on non-translation issues, please contact Polycom support.

Translated documents are not available in PDF format.