This form provides configuration options that can be applied to various types of SIP devices. The association between the SIP device and the form is similar to how the Class of Service options work.
The SIP Device Capabilities number provides a SIP profile that can be applied to particular SIP devices to allow for alternate capabilities as recommended through the Mitel interop process.
A SIP phone can only be associated with a single SIP Device Capabilities Assignment form, though a form may be assigned to several SIP phones, for example, one SIP Device Capabilities Assignment form can be assigned to all of one type of generic SIP phone.
The SIP Device Capabilities forms are shared across all nodes in a cluster (see SDS sharing for more information).
Use this form when performing the following tasks:
Parameter |
Description |
Default Value |
SIP Device Capabilities Number |
System-generated, protected field. Indicates the number of the SIP Device Capabilities that you want to edit. There can be up to 64 different device capability numbers. This number is similar to a Class of Service Option. All entries contain system defaults, unless otherwise modified. |
|
Comment |
Enter a meaningful name to describe the type of SIP devices assigned to this number. The Comment can be up to 15 characters in length. |
Blank |
Call Routing and Administration Options |
||
Outbound Proxy Server |
Select the network element that is being used as the Outbound Proxy Server for SIP devices. The Outbound Proxy Server will then be added to the Trusted Domains for Registration. The default is to leave this field blank, which means that no Outbound Proxy Server is deployed between SIP devices and the 3300 ICP. |
Blank |
Replace System based with Device based In-Call Features |
Some SIP phones support the Transfer and Conference features independently of the 3300 ICP system. Select "Yes" to use the Transfer and Conference feature functionality that is provided by the SIP phone. Select "No" to use the Transfer and Conference features that are provided by the 3300 ICP. |
No |
SDP Options |
||
Allow Device to use Multiple Active M-Lines |
When enabled, the 3300 will allow the device to negotiate more than one active m-line for the Session Description Protocol. For devices capable of negotiating multiple m-lines, such as audio, image, video, and applications, the recommended setting is Yes. |
No |
Force Sending SDP in initial Invite message |
Select Yes to always insert SDP into the initial Invite message. This option allows inter-working with SIP peers that require SDP in the Initial Invite. In many situations, the 3300 ICP already includes SDP in the initial invite. The forced SDP may contain a default inactive SDP if the SDP is not available at call setup time. |
No |
Prevent SDP Renegotiation if Peer is on Hold |
Select Yes to prevent sending SDP renegotiation messages to the peer device when the peer is on hold. |
No |
Prevent the Use of IP Address 0.0.0.0. in SDP Messages |
Select Yes to prevent the IP Address of 0.0.0.0 from being used as the connection address in the SENDONLY or INACTIVE SDP sent by the 3300 ICP. Enable this option if there are specific 0.0.0.0 issues detected with the SDP. |
No |
Renegotiate SDP To Enforce Symmetric Codec |
Enable this option to force the use of the same codec--for example, G.729--in both incoming and outgoing directions. When a SDP negotiation is answered with a list of codecs it can be unclear which codec will be used in either direction. This option will send a Re-invite with a single codec if the 3300 ICP detects this situation to ensure there is no misunderstanding. |
Disabled |
Repeat SDP Answer If Duplicate Offer Is Received |
Select "Yes" to treat identical SDP offers received in the same session as a session refresh instead of responding with a new answer that repeats the previous SDP. By default, all SDP Offers (duplicate or not) are treated as a new offer, resulting in audio renegotiation and the restart of RTP streaming. This option should be enabled if changing/restarting RTP streaming causes audio issues when the remote peer simply refreshes the media connection. |
Disabled |
Suppress the Use of SDP Inactive Media Streams |
Select Yes to allow the 3300 ICP to minimize the use of INACTIVE messaging if it is not fully supported by the service provider. While media connections are transitioning (hold/transfer/conference, etc.), or in some cases at call setup, the media may be temporarily unavailable causing the 3300 ICP to send an inactive SDP. If this option is set to Yes the 3300 ICP will instead attempt to use the IP 0.0.0.0 or mark streams as sendonly/recvonly to avoid the use of inactive which is not supported by some SIP Peers. |
Yes |
Signaling and Header Manipulation |
||
Minimum Registration Period |
This field sets the minimum time period in seconds allowed between Register requests to the primary ICP and secondary ICP. The range is from 120 to 3,600 seconds. CAUTION: Frequent Register requests from large numbers of SIP devices can significantly degrade system performance. Therefore, we recommend that the Minimum Registration Period be set to no less than the default of 300 seconds. Note that in cases where there are few SIP devices, or where most SIP devices support the P-Alternate-Server header, you can set the minimum registration period to a lower value. |
300 seconds |
Session Timer |
Set the SIP timeout value (90 to 9999 seconds). If the device does not respond within the allocated time, the session (call) is torn down. Set the Session Timer to 0 to disable it. It is recommended that this be set to a non-zero value unless there is a specific reason to disable it. The benefit of this option is that it can help clear calls that get stuck due to signaling errors. If the peer responds with a 422 “Session Interval too Small,” you may want to increase the session timer to the value indicated by the peer to minimize delays in call setup. |
Disabled |
Disable Reliable Provisionable Responses |
Select Yes to disable the use of reliable provisional responses (PRACK) on outgoing and incoming calls, unless the required header is used on incoming calls. |
No |