SIP Device Capabilities Assignment

Purpose:

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:

Field Descriptions

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