Polycom SIP 2.0 User Manual

Download

SIP 2.0 Administrator’s Guide

SoundPoint®/SoundStation® IP SIP

Version 2.0.3B Addendum

Version 2.1 Addendum

January 2007

Notices

1. Specifications subject to change without notice.

Polycom, Inc.

1565 Barber Lane, Milpitas CA 95035, USA

www.polycom.com

Part Number: 1725-11530-210 Rev A

Administrator’s Guide - SoundPoint® IP / SoundStation® IP Addendum

1Addendum

This addendum addresses changes to the SoundPoint IP / SoundStation IP SIP 2.0 Administrator’s Guide made by the release of the SoundPoint IP 650 phone.

The SoundPoint IP 650 phone behaves in a similar manner to the SoundPoint IP 601 (supports the SoundPoint IP Expansion Module) unless otherwise specified.

For more information, refer to the Release Notes for the SIP Application, Version

2.0.3 B.

Note

The various .hd. parameters in sip.cfg (such as voice.aec.hd.enable, voice.ns.hd.enable, and voice.agc.hd.enable) are headset parameters. There are not connected to high definition or HD voice.

1.1 Added or Changed Features

1.1.1 Configurable Feature Keys

The SoundPoint IP 650 phone’s default SIP key layouts is the same as the SoundPoint IP 600 and 601. Refer to 3.1.7 Configurable Feature keys on page 29.

1.1.2 Handset, Headset, and Speakerphone

The SoundPoint IP 650 phones are full-duplex speakerphones. Changes can be found in the following parameters in the sip.cfg configuration file:

• Gains <gain/>

Attribute Default

voice.handset.rxag.adjust.IP_650 1 voice.handset.txag.adjust.IP_650 9 voice.handset.sidetone.adjust.IP_650 -3

Administrator’s Guide - SoundPoint® IP / SoundStation® IP Addendum

Attribute Default

voice.headset.rxag.adjust.IP_650 1 voice.headset.txag.adjust.IP_650 18

voice.headset.sidetone.a

just.IP_650 -3

Important

Polycom recommends that you do not change these values.

1.1.3 LCD Backlight

Backlight intensity on the SoundPoint IP 650 phone has three modes:

• Backlight On

• Backlight Idle

• Dim

You can modify the Backlight On intensity and the Backlight Idle intensity separately. You can select high, medium, low, and off levels for both. Dim mode intensity is determined by the Backlight On intensity and the Backlight Idle intensity together.

Backlight settings can be found in the User Preferences <up/> parameter in the sip.cfg configuration file.

Permitted

Attribute

up.backlight.onIntensity 0 (off),

up.backlight.idleIntensity 0 (off),

Values

1 (low), 2 (medium), 3 (high)

Default Interpretation

3 This parameter controls the intensity

of the LCD backlight when it turns on during normal use of the phone.

1 This parameter controls the intensity

of the LCD backlight when the phone is idle.

Note: If idleIntensity is set higher than onIntensity, it will be replaced with the onIntensity value.

Administrator’s Guide - SoundPoint® IP / SoundStation® IP Addendum

1.1.4 Expanded Memory and Expanded Flash Memory

Changes can be found in the following parameters in the sip.cfg configuration file:

• Directory <dir/>

Permitted

Attribute

dir.local.volatile.maxSize 1 to 100 100 Maximum size in Kbytes of

dir.local.volatile.8meg 0, 1 0 Attribute applies only to

Values

Default Interpretation

volatile directory will be permitted to consume.

platforms with flash memory. If set to 1, use volatile storage for phone-resident copy of the directory larger size.

storage that the

8 M

bytes of

to allow for

dir.local.nonVolatile.maxSize.8meg

• Provisioning <prov/>

Attribute

prov.fileSystem.rfs0.minFreeSpace 5-512 5 Minimum free space in prov.fileSystem.ffs0.8meg.min-

FreeSpace

1 to 100 100 Attribute applies only to

Permitted Values

platforms with 8 M flash memory. This is the maximum size of non-volatile storage that the directory will be permitted to consume.

Default Interpretation

512

Kbytes to reserve in the file system when loading files from the boot

er.

serv

Note: Polycom recomm

ends that you do not

ange these parameters.

bytes of

down-

Administrator’s Guide - SoundPoint® IP / SoundStation® IP Addendum

• RAM Disk <ramdisk/>

Permitted

Attribute

Values

Default Interpretation

ramdisk.bytesPerBlock 0, 32, 33,

..., 1024

These three parameters use internal defaults when value is set to 0.

• Finder <finder/>

Permitted

Attribute

res.finder.sizeLimit positive

Values

ger

inte

Default Interpretation

300 If a resource that is being downloaded to

the phone is larger than this value * 1000 bytes (= the maximum size), the resource will be automatically truncated to the maximum size defined.

res.finder.minfree 1 to 2048 1200 A resource will not be downloaded to the

e if the amount of free memory is

ph less than this value * 1000 bytes (= the minimum size). This parameter is used for 16MB SDRAM platforms and scaled up for platforms with more SDRAM.

Administrator’s Guide - SoundPoint® IP / SoundStation® IP Addendum

1.1.5 MicroBrowser

The SoundPoint IP 650 phones support an XHTML microbrowser. This can be launched by pressing the Services key.

MicroBrowser parameter changes in the sip.cfg configuration file are as follows:

Attribute Permitted Values Default Interpretation

mb.limits.nodes positive integer 256 Limits the number of tags which the

XML parser will handle. This limits the amount of memory used by complicated pages. A maximum total of 500 (256 each) is recommended. This value is used as referent values for 16MB of SDRAM.

Note: Increasing this value may have a detrimental effect on performance of the phone.

mb.limits.cache positive integer 200 Limits the total size of objects down-

loaded for each page (both XHTML and images). Once this limit is reached, no more images are downloaded until the next page is requested. Units = kBytes. This value is used as referent values for 16MB of SDRAM.

Note: Increasing this value may have a detrimental effect on performance of the phone.

Administrator’s Guide - SoundPoint® IP / SoundStation® IP Addendum

1.1.6 G.722 Audio Codec

The SoundPoint IP 650 supports the G.722 audio codec. Changes can be found in the following parameters in the sip.cfg configuration file:

• Codec Preferences <codecPref/>

Permitted

Attribute

voice.codecPref.IP_650.G711MuNull, 1-3 2 Specifies the codec preferences

voice.codecPref.IP_650.G711A 3 voice.codecPref.IP_650.G729A

Values

Default Interpretation

SoundPoint IP 650

for the platform. 1 = highest

3 = lowest Null = do not use

voice.codecPref.IP_650.G722

• Audio Profiles <audioProfile/>

Attribute

voice.audioProfile.G722.payloadSize

voice.audioProfile.G722.jitterBufferMin

Permitted Values

10, 20, 30, ... 80

20, 40, 50, 60, ... (multiple

)

of 10

Default Interpretation

20 Prefe

40 The smallest jitter buffer depth (in

rred Tx payload size in mil-

liseconds to be provided in SDP

rs and used in the absence of

offe ptime negotiations. This is also the range of supported Rx payload sizes.

milliseconds) that must be achieved before play out begins for the first time. Once this depth has been achieved initially, the depth may fall below this point and play out will still continue. This parameter should be set to the smallest possible value which is at least two packet payloads, and larger than the expected short term average jitter.

Administrator’s Guide - SoundPoint® IP / SoundStation® IP Addendum

Permitted

Attribute

Values

Default Interpretation

voice.audioProfile.G722.jitterBufferShrink

voice.audioProfile.G722.jitterBufferMax

10, 20, 30, ... (multiple

10)

> jitterBufferMin, multiple

of 10 <=500 for IP 430, 500, 501, and 600, <= 160 for IP

0 an

30 301

500 The absolute minimum duration

time (in milliseconds) of RTP packet Rx with no packet loss between jitter buffer size shrinks. Use smaller values (1000 ms) to minimize the delay on known good networks. Use larger values to minimize packet loss on networks with large jitter (3000 ms).

160 The largest jitter buffer depth to

be supported (in mi

lliseconds). Jitter above this size will always ca

use lost packets. This parameter should be set to the smallest possible value that will support the expected network jitter.

• Gains <gain/>

Attribute Default

voice.gain.rx.analog.chassis.IP_650 2 voice.gain.rx.analog.ringer.IP_650 0 voice.gain.rx.digital.chassis.IP_650 -9 voice.gain.rx.digital.ringer.IP_650 -21

hassis.IP_650 36

voice.gain.tx.analog

voice.gain.tx.digital.chassis.IP_650 0

Important

Polycom recommends that you do not change these values.

Administrator’s Guide - SoundPoint® IP / SoundStation® IP Addendum

• Receive <rxEq/>

Attribute Default

voice.rxEq.hs.IP_650.preFilter.enable 1

ter

voice.rxEq.hs.IP_650.postFil

.enable 0 voice.rxEq.hd.IP_650.preFilter voice.rxEq.hd.IP_650.postFilter. voice.rxEq.hf.IP_650.preFilter. voice.rxEq.hf.IP_650.postFilter

.enable 1

enable 0

enable 1

.enable 0

Important

Polycom recommends that you do not change these values.

• Transmit <txEq/>.

Attribute Default

voice.txEq.hs.IP_650.preFilter. voice.txEq.hs.IP_650.postFilter voice.txEq.hd.IP_650.preFilter.enable 1 voice.txEq.hd.IP_650.postFilter

enable 1

.enable 1

enable 0 voice.txEq.hf.IP_650.preFilter. voice.txEq.hf.IP_650.postFilter

enable 1

.enable 1

Important

Polycom recommends that you do not change these values.

Administrator’s Guide - SoundPoint® IP / SoundStation® IP Addendum

1.1.7 USB Diagnostics

The SoundPoint IP 650 phone has a USB port, which will be supported by future releases of the SIP application.

USB port parameters can be found in the USB <usb/> parameter in the sip.cfg configuration file.

Attribute Permitted Values Default Interpretation

usb.enable 0, 1 0 This parameter enables or disables the

USB port on the phone.

usb.bulkDrive.enable0, 1 0 This parameter enables or disables

support for a USB bulk drive connected to the USB port on the phone.

usb.bulkDrive.namealphanumeric

string

usbDrive

This parameter is a string which specifies the name of the mounted USB drive.

Other changes to support a USB port can be found in the following parameter in the sip.cfg configuration file:

• Basic Logging <log/>

Permitted

Attribute

log.level.change.usb 0-5 4 Control

Values

Default Interpretation

the logging detail level for the usb component. These are the input filters into the internal memory-base

d log system.

Administrator’s Guide - SoundPoint® IP / SoundStation® IP Addendum

2 Addendum

This addendum addresses changes to the SoundPoint IP / SoundStation IP SIP 2.0 Administrator’s Guide made by the release of the SIP 2.1 application.

For more information, refer to the Release Notes for the SIP Application, Version 2.1 .

Note

The various .hd. parameters in sip.cfg (such as voice.aec.hd.enable, voice.ns.hd.enable, and voice.agc.hd.enable) are headset parameters. They are not connected to high definition or HD voice.

2.1 Added or Changed Features

2.1.1 Digit Map

Enhancements have been made to the local digit maps that can eliminate the need for using the Dial or Send soft key when making outgoing calls. Refer to the “Technical

Bulletin 11572: Changes to Local Digit Maps on SoundPoint® IP Phones ” at www.polycom.com/support/voip/ .

2.1.2 Billing Code

Billing codes let administrators assign specific codes to all of their organization’s outgoing calls. The prompt to signal employees to enter their billing codes has changed.

Refer to the “Technical Bulletin 9268: Billing Code Entry on SoundPoint with Sylantro ” at www.polycom.com/support/voip/ .

2.1.3 Syslog

IP phones

Syslog is a de facto standard for forwarding log messages in an IP network. The SIP application has been enhanced to support logging system level messages and error conditions with communications networks to a centralized location. Refer to the

“Technical Bulletin 17124: Syslog on SoundPoint www.polycom.com/support/voip/ .

IP Phones” at

Administrator’s Guide - SoundPoint® IP / SoundStation® IP Addendum

2.1.4 Server Redundancy

Server redundancy enhancements provides backup to other SIP server(s) by providing basic registration and redirection services. Refer to the “Technical Bulletin 5844: SIP

Server Fallback Enhancements on SoundPoint® IP Phones” at www.polycom.com/ support/voip/ .

2.1.5 MicroBrowser

An XHTML microBrowser is now supported on the SoundPoint IP 430 and 501 phones. The tables shows the platforms where the XHTML microBrowser is supported and where it is not.

Supported Platforms Unsupported Platforms

IP 430 IP 300, 301 IP 501 IP 500 IP 600, 601, 650 IP 4000

This can be launched by pressing the Services key , or through the Menu key by selecting Features, and then Services, if there is no Services key on the phone.

The microBrowser auto-navigates to the first visible, selectable item on the web page (a hyperlink, for example):

• after initial page load

• after scrolling further down page (after the se key press)

cond or third down arrow

Note

XHTML tables must be properly formatted (should include <tbody> and </tbody> tags). Improperly formatted tables could cause the phone to reboot.

Administrator’s Guide - SoundPoint® IP / SoundStation® IP Addendum

2.1.6 Disable Message Waiting Indicator by Registration

The SIP application has been enhanced to allow the message waiting indicator to be disabled by registration.

• Changes can be found in the following parameters in the phone1.cfg

configuration file:

Permitted

Attribute

Values

Default Interpretation

msg.mwi.x.callBackMode contact or

registration or disabled

“registration”

Disables message

rieval and disables

ret waiting message notification for the line.

If set to “contact”, a call will be placed to contact specified in the callback attribute when the user invokes message retrieval.

If set to “registration”, a call will this registration to the contact registered (the phone will call itself).

If set to “disabled”,

ssage retrieval is dis-

me abled.

2.1.7 Daylight Saving Time Changes for 2007

be placed

the

using

Daylight saving time dates will be changing in North America in 2007. Refer to the “Technical Bulletin 17803: Daylight Savings Time Changes for 2007 on SoundPoint

IP Phones” at www.polycom.com/support/voip/ . Changes to default values and the Interpretations can be found in the following param-

eters in the sip.cfg configuration file:

Administrator’s Guide - SoundPoint® IP / SoundStation® IP Addendum

Permitted

Attribute

Values

Default Interpretation

tcpIpApp.sntp.daylightSavings.fixedDayEnable

tcpIpApp.sntp.daylightSavings.start.month 1-12 3 (March) Month to start DST.

tcpIpApp.sntp.daylightSavings.start.date 1-31 8 Day of the month to

0, 1 0 If set to 0, month, date,

and dayOfWeek are used in DST start date calculation.

If set to 1, then only month and date are used.

Mapping: 1=Jan, 2=Feb, ..., 12=Dec

start DST. Mapping (on or after): 1

= the first occurrence of a given day-of-the-week in a month, 8 = the second occurrence of a given day-of-the-week in a month, 15 = the third occurrence of a given day-of-the-week in a month, 22 = the fourth occurrence of a given day-of-the-week in a month

tcpIpApp.sntp.daylightSavings.start.time 0-23 2 Time of day to start

tcpIpApp.sntp.daylightSavings.start.dayOfWeek

tcpIpApp.sntp.daylightSavings.start.dayOfWeek.lastInMonth

tcpIpApp.sntp.daylightSavings.stop.month 1-12 11 Month to stop DST.

1-7 1 Day of week to apply

0, 1 0 If set to 1 and fixedDay-

DST, in 24 hour clock. Mapping: 2=2 am, 14=2

DST. Mapping: 1=Sun,

2=Mon, ..., 7=Sat

Enable is set to 0, DST starts on the last day (specified by start.dayOfW eek) of the week in the month. The start.date is ignored.

Administrator’s Guide - SoundPoint® IP / SoundStation® IP Addendum

Permitted

Attribute

tcpIpApp.sntp.daylightSavings.stop.date 1-31 1 Day of the month to

tcpIpApp.sntp.daylightSavings.stop.time 0-23 2 Time of day to stop

Values

Default Interpretation

stop DST.

DST in 24 hour clock.

tcpIpApp.sntp.daylightSavings.stop.dayOfWeek

tcpIpApp.sntp.daylightSavings.stop.dayOfWeek.lastInMonth

1-7 1 Day of week to stop

0, 1 0 If set to 1 and fixedDay-

2.1.8 Configurable Feature Keys

It has been determined that only some feature keys can be disabled. The exact feature keys that can be “null”-ified are platform-dependent.

Platform Key IDs

IP 300, 301 5, 7, 16, 23, 29, 31, 32 IP 430 7, 8, 9, 10, 29, 31, 33, 34

DST.

Enable=0, stop DST on the last day of the week (specified by stop.dayOfWeek) in the month. The stop.date is ignored.

IP 500, 501 7, 8, 9, 10, 29, 30, 31, 32, 36, 37 IP 600, 601, 650 7, 8, 9, 30, 32, 36, 37, 40 IP 4000 1, 2, 5, 7, 16, 29

Administrator’s Guide - SoundPoint® IP / SoundStation® IP Addendum

2.1.9 Miscellaneous Configuration File Changes

2.1.9.1 sip.cfg

The following changes have also occurred in the sip.cfg configuration file:

Permitted

Attribute

voIpProt.SIP.useSendonlyHold 0, 1 1 If set to 1, the phone will

Values

Default Interpretation

send a reinvite with a stream mode attribute of “sendonly” when a call is put on hold. This is the same as the previous behavior. If set to 0, the phone will send a reinvite with a stream mode attribute of “inactive” when a call is put on hold.

NOTE: The phone will ignore the value of this parameter if set to 1 when the parameter voIpProt.SIP.useRFC2543hol d is also set to 1 (default is 0).

Administrator’s Guide - SoundPoint® IP / SoundStation® IP Addendum

Permitted

Attribute

Values

Default Interpretation

voIpProt.server.x.transport DNSnaptr or

TCPpreferred or UDPOnly or TLS or TCPOnly

DNSnaptrIf set to Null or

DNSnaptr: If voIpProt.server.x.address is a hostname and voIpProt.server.x.port is 0 or Null, do NAPTR then SRV look-ups to try to discover the transport, ports and servers, as per RFC 3263. If voIpProt.server.x.address is an IP address, or a port is given, then UDP is used. If set to TCPpreferred: TCP is the preferred transport, UDP is used if TCP fails. If set to UDPOnly: Only UDP will be used. If set to TLS: If TLS fails, transport fails. Leave port field empty (will default to

5061) or set to 5061. If set to TCPOnly: Only TCP will be used.

NOTE: TLS is not sup- ported on SoundPoint IP 300 and 500 phones.

Administrator’s Guide - SoundPoint® IP / SoundStation® IP Addendum

Permitted

Attribute

Values

Default Interpretation

voIpProt.SIP.outboundProxy.transport DNSnaptr or

TCPpreferred or UDPOnly or TLS or TCPOnly

DNSnaptrIf set to Null or

DNSnaptr: If voIpProt.SIP.outboundProxy.address is a hostname and voIpProt.SIP.outboundProxy.port is 0 or Null, do NAPTR then SRV lookups to try to discover the transport, ports and servers, as per RFC 3263. If voIpProt.SIP.outboundProxy.address is an IP address, or a port is given, then UDP is used. If set to TCPpreferred: TCP is the preferred transport, UDP is used if TCP fails. If set to UDPOnly: Only UDP will be used. If set to TLS: If TLS fails, transport fails. Leave port field empty (will default to

5061) or set to 5061. If set to TCPOnly: Only TCP will be used.

NOTE: TLS is not sup- ported on SoundPoint IP 300 and 500 phones.

voice.gain.rx.analog.chassis.IP_650 0 Gain setting. voice.handset.sidetone.adjust.IP_430 -13 Handset sidetone. call.enableOnNotRegistered 0,1 1 If set to 1, calls will be

allowed when the phone is not successfully registered. If set to 0, calls will not be permitted without a valid registration. If a user picks up handset, presses the New Call soft key, or presses the speaker phone, speed dial or the line keys to get a dial tone, “Service unavailable” is displayed.

Administrator’s Guide - SoundPoint® IP / SoundStation® IP Addendum

Permitted

Attribute

Values

Default Interpretation

call.stickyAutoLineSeize.onHookDialing Null, 0, 1 Null If

2.1.9.2 phone1.cfg

call.stickyAutoLineSeize is set to 1, this parameter has no effect. The regular stickyAutoLineSeize behavior is followed.

call.stickyAutoLineSeize

If is set to 0 or Null and this parameter is set to 1, this overrides the stickyAutoLineSeize behavior for hot dial only. (Any New Call scenario seizes the next available line.)

call.stickyAutoLineSeize

If is set to 0 or Null and this parameter is set to 0 or Null, there is no difference between hot dial and New Call scenarios.

The following changes has also occurred in the phone1.cfg configuration file:

Permitted

Attribute

reg.x.server.y.transpo rt DNSnaptr or

reg.x.outboundProxy.transport DNSnaptr or

Values

TCPpreferred or UDPOnly or TLS or TCPOnly

Default Interpretation

DNSnaptrRefer to Interpretation

of voIpProt.server.x.transport in 2.1.9.1 sip.cfg on page 6, the previous section. If specified, this attribute may override the value in sip.cfg.

DNSnaptrRefer to Interpretation

of voIpProt.SIP.outboundProxy.transport in

2.1.9.1 sip.cfg on page 6, the previous section. If specified, this attribute may override the value in sip.cfg.

Administrator’s Guide - SoundPoint® IP / SoundStation® IP Addendum

2.1.9.3 device Parameter

The following changes has also occurred in the device parameter:

Permitted

Attribute

device.prov.redunAttemptLimit 10, Null 10 Refer to the File Trans-

device.prov.redunInterAttemptDelay 300, Null 300 Refer to the Retry Wait

Values

Default Interpretation

mit Tries parameter in

2.2.1.3.3 Server Menu on page 11 of the SIP

2.0 Administrator’s Guide.

parameter in 2.2.1.3.3 Server Menu on page 11 of the SIP 2.0 Administrator’s Guide.

device.em.power Enabled,

Disabled

Null Refer to the EM Power

parameter in 2.2.1.3.1 Main Menu on page 8 of the SIP 2.0 Administrator’s Guide.

Technical Bulletin 11572

Changes to Local Digit Maps on SoundPoint® IP Phones

This technical bulletin provides detailed information on how to modify the configuration files to automate the setup phase of number-only calls.

This information applies to SoundPoint IP phones running SIP application version 2.1 or later.

Introduction

Enhancements have been made to this feature that can eliminate the need for using the Dial or Send soft key when making outgoing calls. For example, it can match the behavior of removing the 9 or 0 from a string of dialed digits or adding the area code before dialed digits when a switch to 10 digit phone numbers occurs.

As soon as a digit pattern matching the digit map is found, the call setup process will complete automatically. The configuration syntax is the same as that specified in 2.1.5 of RFC 3435. The phone’s behavior when the user dials digits that do not match the digit map is configurable. It is also possible to strip a trailing ‘#’ from the digits sent, prepend a ‘+’ to digits, or to replace certain matched digits with the introduction of ‘R’ to the digit map.

Configuration File Changes

If a single dial plan is used for the entire company, the dial plan is best specified in the application configuration file (sip.cfg). You can also create multiple dial plans and specify which phones are to use which in the phone-specific configuration file (phone1.cfg).

Configuration changes can performed centrally at the boot server or locally:

Central (boot server)

<December, 2006> 3725-17471-001/A

Configuration file:

sip.cfg

Configuration file:

phone1.cfg

Specify impossible match behavior, trailing # behavior, digit map matching strings, and time out value.

• For more information, refer to Dial Plan in Application

Configuration File on page 2.

Specify per-registration impossible match behavior, trailing # behavior, digit map matching strings, and time out values that override those in sip.cfg.

• For more information, refer to Dial Plan in Per-Phone

Configuration File on page 4.

Technical Bulletin

SoundPoint

IP, SIP 2.1

Local Web Server

(if enabled)

Specify impossible match behavior, trailing # behavior, digit map matching strings, and time out value.

Navigate to: http://<phoneIPAddress>/appConf.htm#ls Changes are saved to local flash and backed up to

<Ethernet address>-phone.cfg on the boot server. Changes will permanently override global settings unless deleted through the Reset Local Config menu selection.

Dial Plan in Application Configuration File

The

• Digit Map <digitmap/> on page 3.

Note

The dial plan is not applied against Placed Call List, VoiceMail, last call return, and remote control dialed numbers.

This configuration attribute is defined as follows:

Attribute

dialplan.applyToCallListDial 0, 1 0 This attribute covers dialing from

attribute is described below and also includes:

Permitted Values

Default Interpretation

Received Call List and Missed Call List including dialing from Edit or Info submenus.

If set to 0, the dial plan is not applied against the dialed number.

if set to 1, the dial plan is applied against the dialed number.

dialplan.applyToDirectoryDial 0, 1 0 This attribute covers dialing from

Directory as well as Speed Dial List. Value interpretation is the same as for

dialplan.applyToCallListDial

Note: An Auto Call Contact number is considered a dial from directory.

dialplan.applyT oUserDial 0, 1 1 This attribute covers the case when the

user presses the Dial soft key to send dialed number when in idle state display.

Value interpretation is the same as for

dialplan.applyToCallListDial.

Technical Bulletin

SoundPoint

IP, SIP 2.1

Permitted

Attribute

dialplan.applyT oUserSend 0, 1 1 This attribute covers the case when the

dialplan.impossibleMatchHandling0, 1 or 2 0 If set to 0, the digits entered up to and

dialplan.removeEndOfDial 0, 1 1 If set to 1, strip trailing # digit from digits

Values Default Interpretation

user presses the Send soft key to send the dialed number.

Value interpretation is the same as for

dialplan.applyToCallListDial.

including the point where an impossible match occurred are sent to the server immediately.

If set to 1, give reorder tone. If set to 2, allow user to accumulate

digits and dispatch call manually with the Send soft key.

sent out.

Digit Map <digitmap/>

A digit map is defined either by a “string” or by a list of strings. Each string in the list is an alternative numbering scheme, specified either as a set of digits or timers, or as an expression over which the gateway will attempt to find a shortest possible match.

Digit map extension letter “R” indicates that certain matched strings are replaced. The following examples shows the semantics of the syntax:

R9RRxxxxxxx

•

—remove 9 at the beginning of the dialed number

— For example, if a customer dials 914539400, the first 9 is removed

when the call is placed.

•

RR604Rxxxxxxx

—prepend 604 to all 7 digit numbers

— For example, if a customer dials 4539400, 604 is added to the front of

the number, so a call 6044539400 is placed.

•

R9R604Rxxxxxxx

•

R999R911R

•

xxR601R600Rxx

•

xR60xR600Rxxxxxxx

—replaces 9 with 604

—convert 999 to 911

—when applied on 1160122 gives 1160022

—any 60x will be replaced with 600 in the middle of

the dialed number that matches

— For example, if a customer dials 16092345678, a call is placed to

16002345678.

Technical Bulletin

SoundPoint

IP, SIP 2.1

The following guidelines should be noted:

• You must use only *, #, or 0-9 between second and third R

• If a digit map does not comply, it is not included in the digit plan as a valid

one. That is, no matching is done against it.

• There is no limitation on the number of R triplet sets in a digit map. However, a digitmap that contains less than full number of triplet sets (for example, a total of 2Rs or 5Rs) is considered an invalid digit map.

• Using T in the left part of RRR syntax is not recommended. For example, R0TR322R should be avoided.

This configuration attribute is defined as follows:

Attribute Permitted Values Default Interpretation

dialplan.digitmap string compatible with

the digit map feature of MGCP described in

2.1.5 of RFC 3435. String is limited to 768 characters and 30 segments; a comma is also allowed; when reached in the digit map, a comma will turn dial tone back on;’+’ is allowed as a valid digit; extension letter ‘R’ is used as defined above.

dialplan.digitmap.timeOut string of positive

integers separated by ‘|’

3 | 3 | 3 | 3 | 3 | 3 | 3 Timeout in seconds for each

When this attribute is present, number-only dialing during the setup phase of new calls will be compared against the patterns therein and if a match is found, the call will be initiated automatically eliminating the need to press Send.

Attributes

dialplan.applyToCallListDial dialplan.applyToDirectoryDial dialplan.applyToUserDial dialplan.applyToUserSend

control the use of match and replace in the dialed number in the different scenarios. Refer to page 2.

segment of digitmap.

Note: If there are more digit maps than timeout values, the default value of 3 will be used. If there are more timeout values than digit maps, the extra timeout values are ignored.

, and

Dial Plan in Per-Phone Configuration File

Per-registration dial plan configuration is supported.

The

• Digit Map <digitmap/> on page 3.

attribute is described below and also includes:

Technical Bulletin

SoundPoint

IP, SIP 2.1

In the following tables, x is the registration number. IP 300, 301, and 430: x=1-2; IP 500 and 501: x=1-3; IP 600: x=1-6; IP 601: x=1-12; IP 4000: x=1

Permitted

Attribute

dialplan.x.applyToCallListDial 0, 1 0 When present, and if

dialplan.x.applyToDirectoryDial 0, 1 0 When present, and if

Values

Default Interpretation

dialplan.x.digitmap

Null, this attribute overrides the global dial plan defined in the sip.cfg configuration file.

For interpretation, refer to

Dial Plan in Application Configuration File on page 2.

dialplan.x.digitmap

Null, this attribute overrides the global dial plan defined in the sip.cfg configuration file.

For interpretation, refer to

Dial Plan in Application Configuration File on page 2.

is not

dialplan.x.applyToUserDial 0, 1 1 When present, and if

dialplan.x.digitmap

Null, this attribute overrides the global dial plan defined in the sip.cfg configuration file.

For interpretation, refer to

Dial Plan in Application Configuration File on page 2.

dialplan.x.applyToUserSend 0, 1 1 When present, and if

dialplan.x.digitmap

Null, this attribute overrides the global dial plan defined in the sip.cfg configuration file.

For interpretation, refer to

Dial Plan in Application Configuration File on page 2.

is not

Technical Bulletin

SoundPoint

IP, SIP 2.1

Permitted

Attribute

Values Default Interpretation

dialplan.x.impossibleMatchHandling 0, 1 or 2 0 When present, and if

dialplan.x.digitmap

Null, this attribute overrides the global dial plan defined in the sip.cfg configuration file.

For interpretation, refer to

Dial Plan in Application Configuration File on page 2.

dialplan.x.removeEndOfDial 0, 1 1 When present, and if

dialplan.x.digitmap

Null, this attribute overrides the global dial plan defined in the sip.cfg configuration file.

For interpretation, refer to

Dial Plan in Application Configuration File on page 2.

is not

Digit Map <digitmap/>

The digit map syntax is the same as for the application configuration file (refer to Digit Map <digitmap/> on page 3).

This configuration attribute is defined as follows:

Permitted

Attribute

dialplan.x.digitmap A string compatible with

Values Default Interpretation

the digit map feature of MGCP described in

2.1.5 of RFC 3435; string is limited to 768 characaters and 30 segments; a comma is also allowed; when reached in the digit map, a comma will turn dial tone back on;’+’ is allowed as a valid digit; extension letter ‘R’ is used as defined above.

Null When present, this attribute

overrides the global dial plan defined in the sip.cfg configuration file.

For more information, refer to Digit Map <digitmap/> on page 3.

Technical Bulletin

SoundPoint

IP, SIP 2.1

Attribute

Permitted Values Default Interpretation

dialplan.x.digitmap.timeOut string of positive integers

separated by ‘|’

Null When present, and if

dialplan.x.digitmap

not Null, this attribute overrides the global dial plan defined in the sip.cfg configuration file.

For more information, refer to Digit Map <digitmap/> on page 3.

Trademark Information

Polycom®, SoundPoint®, and the Polycom logo design are registered trademarks of Polycom, Inc. in the U.S. and various countries. All other trademarks are the property of their respective companies.

Technical Bulletin 9268

Billing Code Entry on SoundPoint® IP Phones with Sylantro

This technical bulletin provides detailed information on how the SIP application has been modified for billing code entry when managed by a Sylantro call server.

This information applies to SoundPoint IP phones running SIP application version 2.1 or later.

Introduction

Note

Billing codes let administrators assign specific codes to all of their organization’s outgoing calls.

When a SoundPoint IP phone managed by a Sylantro call server is configured to require billing codes, calls are not connected until the a valid billing code is entered.

The modified user interface on a SoundPoint IP phone running SIP 2.1 is described in the following section, Billing Code Entry.

Billing Code Entry

This section describes the steps the user must perform to enter a billing code.

To enter a billing code when placing a call:

1. Do one of the following to a place a call:

This feature is only supported on Sylantro call servers.

a With the handset on-hook, enter the long-distance number (including

prefix).

<December, 2006> 3725-17483-001/A

You may need to press the Dial soft key to indicate you are finished entering the number.

b Pick up the handset and enter the long-distance number (including

prefix).

Technical Bulletin

SoundPoint

IP, SIP 2.1

You may need to press the Send soft key to indicate you are finished entering the number.

The cursor pauses after the last digit has been entered. The call is not placed at this time.

A secondary dial tone is played and the text “Enter more digits” appears on the display just above the soft keys.

2. Enter the billing code.

If the billing code is accepted, the call is placed at this time.

If the billing code is not accepted, you will hear a fast busy tone and the call is not placed.

Trademark Information

Polycom®, SoundPoint®, and the Polycom logo design are registered trademarks of Polycom, Inc. in the U.S. and various countries. All other trademarks are the property of their respective companies.

Technical Bulletin 17124

Syslog on SoundPoint® IP Phones

This technical bulletin provides detailed information on how the SIP application has been modified to support logging system level messages and error conditions with communications networks to a centralized location.

This information applies to SoundPoint IP phones running SIP application version 2.1 or later.

Introduction

Syslog is a de facto standard for forwarding log messages in an IP network. The term "syslog" is often used for both the actual syslog protocol, as well as the application or library sending syslog messages.

The syslog protocol is a very simplistic protocol: the syslog sender sends a small textual message (less than 1024 bytes) to the syslog receiver. The receiver is commonly called "syslogd", "syslog daemon" or "syslog server". Syslog messages can be sent through UDP or TCP. The data is sent in cleartext.

Syslog is supported by a wide variety of devices and receivers. Because of this, syslog can be used to integrate log data from many different types of systems into a central repository.

The syslog protocol is defined in RFC 3164. For more information on syslog, go to http://www.ietf.org/rfc.html .

log.render.level

The

0 -> SeverityDebug (7) 1 -> SeverityDebug (7) 2 -> SeverityInformational (6) 3 -> SeverityInformational (6) 4 -> SeverityError (3) 5 -> SeverityCritical (2) 6 -> SeverityEmergency (0) 7 -> SeverityNotice (5)

For more information on <level/><change/> and <render/> on page 138 of the SIP 2.1 Administrator’s Guide.

Network configuration changes required to support this feature are described in the following section, Network Configuration Changes.

maps to syslog severity as follows:

log.render.level

, refer to Basic Logging

<December, 2006> 3725-17482-001/A

Technical Bulletin

SoundPoint

IP, SIP 2.1

Network Configuration Changes

The Network Configuration menu on the SoundPoint IP phone running SIP

2.1 has been modified to include:

• Syslog Menu

To access the Syslog menu:

1. From the idle display on a SoundPoint IP phone, press the Menu key.

2. Using the Down Arrow key and the Select soft key, select Settings >

Advanced > Admin Settings > Network Configuration.

You must enter the administrative password to access this menu. The default value is “456”.

3. Using the Down Arrow key and the Select soft key, scroll down to Syslog Menu.

Syslog Menu

The following syslog configuration parameters can be modified on the Syslog menu:

Name Possible Values Description

Server Address dotted-decimal IP address

OR domain name string

Server Type None=0,

UDP=1, TCP=2

Facility 0 to 23 A description of what generated the log message.

Render Level 1 to 6 Specifies the lowest class of event that will be

Prepend MAC Address

Enabled, Disabled If enabled, the phone’s MAC address is prepended

The syslog server IP address or host name. The default value is NULL.

The protocol that the phone will use to write to the syslog server.

If set to “None”, transmission is turned off, but the server address is preserved.

For more information, refer to section 4.1.1 of RFC

3165. The default value is 16, which maps to “local 0”.

rendered to syslog. It is based on

log.render.level

Refer to Basic Logging <level/><change/> and <render/> on page 138 of the

Administrator’s Guide

to the log message sent to the syslog server.

and can be a lower value.

SIP 2.0

Technical Bulletin

SoundPoint

IP, SIP 2.1

Flash Parameter Configuration

The global

device

parameter has been modified to include the following:

Name Possible Values Description

device.syslog.serverName dotted-decimal IP address

OR domain name string

device.syslog.transport None=0,

UDP=1, TCP=2

device.syslog.facility 0 to 23 A description of what generated the log message.

device.syslog.renderLevel 1 to 6 Specifies the lowest class of event that will be

device.syslog.prependMac Enabled, Disabled If enabled, the phone’s MAC address is prepended

The syslog server IP address or host name. The default value is NULL.

The protocol that the phone will use to write to the syslog server.

If set to “None”, transmission is turned off, but the server address is preserved.

For more information, refer to section 4.1.1 of RFC

3165. The default value is 16, which maps to “local 0”.

rendered to syslog. It is based on

log.render.level

Refer to Basic Logging <level/><change/> and <render/> on page 138 of the SIP 2.0

Administrator’s Guide

to the log message sent to the syslog server.

and can be a lower value.

Note

The parameters for this feature should be put in separate configuration files to simplify maintenance. Do not add them to existing configuration files (such as sip.cfg). Create a new configuration file for parameters that should apply to all phones.

Polycom recommends that you test the new configuration files on two phones before initializing all phones.

Trademark Information

Polycom®, SoundPoint®, and the Polycom logo design are registered trademarks of Polycom, Inc. in the U.S. and various countries. All other trademarks are the property of their respective companies.

Technical Bulletin 5844

SIP Server Fallback Enhancements on SoundPoint® IP Phones

This technical bulletin provides detailed information on how the SIP application has been enhanced to support SIP server fallback.

This information applies to SoundPoint IP phones running SIP application version 2.1 or later.

Introduction

Server redundancy is often required in VoIP deployments to ensure continuity of phone service for events where the call server needs to be taken offline for maintenance, the server fails, or the connection from the phone to the server fails.

Two types of redundancy are possible:

•Fail-over: In this mode, the full phone system functionality is preserved by having a second equivalent capability call server take over from the one that has gone down/off-line. This mode of operation should be done using DNS mechanisms or “IP Address Moving” from the primary to the back-up server.

Note

Warning

• Fallback: In this mode, a second less featured call server (router or gateway device) with SIP capability takes over call control to provide basic calling capability, but without some of the richer features offered by the primary call server (for example, shared lines, presence, and Message Waiting Indicator). Polycom phones support configuration of multiple servers per SIP registration for this purpose.

In some cases, a combination of the two may be deployed.

In SIP 2.1, the fallback behavior has been enhanced and this behavior is described in this document.

Your SIP server provider should be consulted for recommended methods of configuring phones and servers for fail-over configuration.

The server redundancy behavior in SIP2.1 has changed from that implemented in prior releases. Prior to SIP 2.1, the

4.6.2.1 of the SIP 2.0 Administrator's Guide) could be used for fail-over configuration. The older behavior is no longer supported. Customers that are using

reg.x.server.y

the ensure that their current deployments are not adversely affected. For example the phone will only support advanced SIP features such as shared lines, missed calls, presence with the primary server (y=1).

. configuration parameters where y>=2 should take care to

reg.x.server.y

parameters (see section

<January, 2007> 3725-17472-001/A

Technical Bulletin

SoundPoint

IP, SIP 2.1

Terminology

Before you read this document, it is important to understand certain terminology and become familiar with the server/registration configuration as described in the references listed in the References on page 8. The behavior described in this document supersedes that described in section 3.6.5 of the SIP 2.0 Administrator's Guide.

SIP Registrations: SoundPoint IP phones support the ability to have multiple SIP Registrations per phone. This is often used to support multiple “Lines” on a single phone and normally the SIP server(s) used for each Registration are the same. However, they could be different.

Primary and Fallback Servers: Each of these SIP Registrations may be configured for concurrent registration with multiple servers for fallback purposes. For example, a phone may be configured to have two SIP Registrations and each SIP Registration may be configured with two separate servers (a primary server and a fallback server). DNS mechanisms (as described in RFC3263) may be used such that the servers are capable of resolving to multiple physical SIP servers for fail-over purposes.

Note

The primary server is the only one that will be used for advanced SIP features such as shared lines, message waiting indicators, and presence. This is a change in behavior from software releases before SIP 2.1 All other configured servers are referred to as fallback servers.

Working Server: The phone maintains a list of all possible servers gained from both DNS and configuration. The highest priority server which has an active registration is treated as the working server and will be the first server tried for call initiation purposes. At any time, there is only one working server recognized by the phone.

Registrar Server: Servers (both primary and fallback) may be configured with registration enabled or disabled using the

reg.x.server.y.register

configuration parameter. Servers that have this parameter enabled will attempt registrations and are termed a registrar server. If a server is not a registrar server, calls will be attempted on that server if appropriate, but registration will not be attempted. Only a registrar server can become the working server.

For the purposes of this document, we will use examples where the phone has only one SIP Registration.

The sections Server <server/> on page 95 and Registration <reg/> on page 149 of the SIP 2.0 Administrator's Guide describe the parameters that are relevant to the configuration of the phones for server redundancy and fallback behavior.

Configuration file changes for SIP 2.1 are described in Configuration File

Changes on page 7.

Technical Bulletin

PSTN Gateway

Internet

PSTN

Hosted VoIP Service

Provider

VoIP SMB Customer

Premise

DNS Server

Call Server 1A

Call Server 1B

SIP Capable Router

Server2

SoundPoint

IP, SIP 2.1

SIP 2.1 Server Fallback Implementation

In the SIP 2.1 release, the redundancy behavior of Polycom SoundPoint IP and SoundStation IP phones has been changed and improved by adding the ability for a single SIP Registration (Line) to be registered to more than one server concurrently. In previous releases, the phone would only maintain one active server registration per SIP Registration (Line). The concurrent server registration capability adds an ability to do a faster and more efficient hand-over to an independent call server both for incoming as well as outgoing calls.

To assist in explaining the redundancy behavior, an illustrative example of how a system may be deployed is defined in the following section.

Example Deployment

A small medium business (SMB) customer uses a hosted IP-Centrex service from a Service provider. The Service provider has two redundant call servers at their network operations center (NOC) and uses a DNS server to resolve the IP addresses of these servers. The SMB customer also has an on-premise router which has the ability to handle SIP call traffic and has a connection to an on-site PSTN gateway. This gateway is intended to be used in conditions in which the Internet connection to the service provider is not working.

Technical Bulletin

SoundPoint

IP, SIP 2.1

Phone Configuration

The phones at the customer site are configured as follows:

• Server 1 (the primary server) will be configured with the address of the service provider call server. The IP address of the server(s) to be used will be provided by the DNS server. For example:

reg.1.server.1.address="voipserver.serviceprovider.com"

• Server 2 (the fallback server) will be configured to the address of the router/gateway that provides the fallback telephony support and is on-site. For example:

reg.1.server.2.address=172.23.0.1

Note

It is possible to configure the phone for more than two servers per registration, but you need to exercise caution when doing this to ensure that the phone and network load generated by registration refresh of multiple registrations do not become excessive. This would be of particularly concern if a phone had multiple registrations with multiple servers per registration and it is expected that some of these servers will be unavailable.

Phone Operation for Registration

After the phone has booted up, it will register to all the servers that are configured.

Server 1 is the primary server and supports greater SIP functionality than any of servers. For example, SUBSCRIBE/NOTIFY services (used for features such as shared lines, presence, and BLF) will only be established with Server 1.

Upon registration timer expiry of each server registration, the phone will attempt to re-register. If this is unsuccessful, normal SIP re-registration behavior (typically at intervals of 30 to 60 seconds) will proceed and continue until the registration is successful (for example, when the Internet link is once again operational). While the primary server registration is unavailable, the next highest priority server in the list will serve as the working server. As soon as the primary server registration succeeds, it will return to being the working server.

Note

reg.x.server.y.register

However, the INVITE will fail over to that server if all higher priority servers are down.

is set to 0, then phone will not register to that server.

Technical Bulletin

SoundPoint

IP, SIP 2.1

Behavior When the Primary Server Connection Fails

For Outgoing Calls (INVITE Fallback)

When the user initiates a call, the phone will go through the following steps to connect the call:

1. Try to make the call using the working server.

2. If the working server does not respond correctly to the INVITE, then try

and make a call using the next server in the list (even if there is no current registration with these servers). This could be the case if the Internet connection has gone down, but the registration to the working server has not yet expired.

3. If the second server is also unavailable, the phone will try all possible servers (even those not currently registered) until it either succeeds in making a call or exhausts the list at which point the call will fail.

At the start of a call, server availability is determined by SIP signaling failure. SIP signaling failure depends on the SIP protocol being used as described below.

Warning

• If TCP is used, then the signaling fails if the connection fails or the Send fails.

• If UDP is used, then the signaling fails if ICMP is detected or if the signal times out. If the signaling has been attempted with all servers in the list and this is the last server then the signaling fails after the complete UDP timeout defined in RFC 3261. If it is not the last server in the list, the maximum number of retries using the configurable retry timeout is used. For more information, refer to Server <server/> on page 95 and Registration <reg/> on page 149 of the SIP 2.0 Administrator's Guide.

If DNS is used to resolve the address for Servers, the DNS server is unavailable, and the TTL for the DNS records has expired, the phone will attempt to contact the DNS server to resolve the address of all servers in its list before initiating a call. These attempts will timeout, but the timeout mechanism can cause long delays (for example, two minutes) before the phone call proceeds “using the working server”. To mitigate this issue, long TTLs should be used. It is strongly recommended that an on-site DNS server is deployed as part of the redundancy solution.

For Incoming Calls (Incoming Call Fallback)

The primary call server can use mechanisms for detecting that the Internet connection is down and route incoming calls through the PSTN link to the back-up gateway/router on-site. Since the phone is simultaneously registered to both servers, it will receive calls through the gateway even if the primary registration has not expired. This is a key advantage of the new behavior introduced in SIP 2.1.

Technical Bulletin

SoundPoint

IP, SIP 2.1

Changes From Previous Phone Behavior (Releases Before SIP 2.1)

Before SIP 2.1 In SIP 2.1

A Line is only capable of maintaining one server registration.

If two servers are configured (for example,

"server1" reg.1.server.2.address = "server2"

register with Server1 as the working server. Phone calls will be placed and received through Server1 only. If the registration to Server1 fails or expires, then the phone will attempt to register with Server2. If this registration succeeds, then incoming calls will be received using this server. At this point, Server2 takes over as the working server.

The phone will continually attempt registration using SIP registration protocols with Server1. At the point that this succeeds, the registration with Server2 will expire and Server1 will resume as the working server.

The phone attempts to maintain full SIP functionality with each server, but it is questionable how effective this is.

reg.1.server.1.address =

and , the phone will initially

A Line will maintain registrations with all servers that are configured as registrar servers.

If two servers are configured (for example,

"server1" reg.1.server.2.address = "server2"

both Server1 as the working and Server2. Phone calls will be placed through Server1, but may be received through either Server1 or Server2. If the registration to Server1 fails or expires, then the Server2 will become the working server.

The phone will continually attempt to register with Server1 and, when this is successful, will switch back to using Server1 as the working server. The Server2 registration will be maintained.

Only basic SIP registration for INVITE functions is maintained with servers other than the primary server.

reg.1.server.1.address =

and , the phone will register with

Recommended Practices for Server Fallback Deployments

The best method for ensuring optimum server redundancy is to deploy two identical call servers and use either DNS methods or “IP Address Moving” together with call server recommended practices for maintaining synchronization of records between the redundant servers. This is termed fail-over (refer to Terminology on page 2). Deployment varies dependent on the SIP call server being used. Consult your SIP call server supplier for recommended practices for fail-over configuration.

In situations where server redundancy for fall-back purpose is used, the following measures should be taken to optimize the effectiveness of the solution:

1. Deploy an on-site DNS server to avoid long call initiation delays that can result if the DNS server records expire.

Technical Bulletin

SoundPoint

IP, SIP 2.1

2. Do not use OutBoundProxy configurations on the phone if the OutBoundProxy could be unreachable when the fallback occurs. SoundPoint IP phones can only be configured with one OutBoundProxy per registration and all traffic for that registration will be routed through this proxy for all servers attached to that registration. If Server 2 is not accessible through the configured proxy, call signaling with Server 2 will fail.

3. Avoid using too many servers as part of the redundancy configuration as each registration will generate more traffic.

4. Educate users as to the features that will not be available when in “fallback” operating mode.

Configuration File Changes

Configuration changes can performed centrally at the boot server:

Central (boot server)

Configuration file: sip.cfg Specify global primary and fallback server configuration

parameters.

• For more information, refer to Protocol in Application

Configuration File on page 7.

Configuration file:

phone1.cfg

Specify per registration primary and fallback server configuration parameters values that override those in sip.cfg.

• For more information, refer to Registration in Per-Phone

Configuration File on page 8.

Protocol in Application Configuration File

The

• Server <server/> on page 7.

Server <server/>

This configuration attribute now includes:

Attribute Permitted Values Default Interpretation

voIpProt.server.x.lcs 0, 1 0 This attribute overrides the

attribute includes:

voIpProt.SIP.lcs

If set to 1, the proprietary “epid” parameter is added to the From field of all requests to support Microsoft Live Communications Server.

Technical Bulletin

SoundPoint

IP, SIP 2.1

Registration in Per-Phone Configuration File

Per-registration configuration is supported.

The

Permitted

Attribute

reg.x.server.y.lcs 0, 1 0 This attribute overrides the

Values

attribute now includes:

Default Interpretation

reg.x.lcs .

If set to 1, the Microsoft Live Communications Server is supported for registration x.

References

1. SIP 2.0 Administrator’s Guide for the SoundPoint IP and SoundStation IP

Phones, August 2006. Go to

http://www.polycom.com/common/pw_cmp_updateDocKeywords/0, 1687,6314,00.pdf

2. RFC3263 - Locating SIP Servers. Go to

http://www.ietf.org/rfc/rfc3263.txt?number=3263

Trademark Information

Polycom®, SoundPoint®, and the Polycom logo design are registered trademarks of Polycom, Inc. in the U.S. and various countries. All other trademarks are the property of their respective companies.

Polycom SIP 2.0 User Manual

Specifications and Main Features

Frequently Asked Questions

User Manual

1Addendum

1.1 Added or Changed Features

1.1.1 Configurable Feature Keys

1.1.2 Handset, Headset, and Speakerphone

1.1.3 LCD Backlight

1.1.4 Expanded Memory and Expanded Flash Memory

1.1.5 MicroBrowser

1.1.6 G.722 Audio Codec

1.1.7 USB Diagnostics

2 Addendum

2.1 Added or Changed Features

2.1.1 Digit Map

2.1.2 Billing Code

2.1.3 Syslog

2.1.4 Server Redundancy

2.1.5 MicroBrowser

2.1.6 Disable Message Waiting Indicator by Registration

2.1.7 Daylight Saving Time Changes for 2007

2.1.8 Configurable Feature Keys

2.1.9 Miscellaneous Configuration File Changes