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 form, though a form may be assigned to several SIP phones, for example, one SIP Device Capabilities 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 |
|
Allow MWI Notifications without Subscription |
Some SIP phones do not support the SUBSCRIBE method for message waiting indication (MWI). Select Yes to allow NOTIFY messages carrying MWI status to be generated without subscription. Select No to require subscription. |
No |
|
Select Yes to allow SIP phones to support the Callback, Camp-on, and Busy Override features. There is additional system programming required to enable these features. Click above links to access programming details.
|
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 media description line (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 |
|
Allow Using UPDATE For Early Media Renegotiation |
Select Yes to allow the media source to be switched prior to the call being answered.
|
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. sending the Initial Invite. |
No |
|
Limit to one Offer/Invite per INVITE |
Select Yes to ignore the SDP in the initial Invite message when media has already been established. Enable this option only if your service provider expects you to discard the SDP. Disable this option (select No) if your service provider expects a response. |
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 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 |
|
Select Yes to allow the system to update SIP phone displays with connected party name and number information during transfers, conferences, and call forwarding scenarios. |
No | |
|
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 |
|
A mid-call feature, such call park, can be activated on a SIP device by sending the feature access code in a REFER message (RFC3515). This is essentially the same as performing an unattended transfer to a feature access code. In some cases, mid-call features such as call park with page will renegotiate a new media stream to the device as part of the feature functionality. Unfortunately most implementation react to a successful REFER response by assuming the call is to be removed from the set. If this option is set to Yes, then a 420 Bad Request is sent in response to a successful REFER in order to force the device to keep the call active. In the event of a failure, a 603 Decline message is sent. The use of this option may cause a SIP device to play an error tone or display an error message even when the feature has succeeded. If this option is set to No, then in the success case the REFER is processed properly and the message/sipfrag body defined by RFC 3515 is used to relay information on the persistence of the call. |
No | |
|
Require Reliable Provisional Responses on Outgoing Calls |
Select Yes to require the use of reliable provisional responses (PRACK) on outgoing calls. This enables the SIP device to receive display updates while a call is ringing. For more information, see RFC 3262.
|
No |
|
Use P-Asserted Identity Header |
Select Yes to enable sending the P-Asserted Identity header within SIP messages. This option is used to convey identity information both at call setup and during a call. When privacy is enabled, or CPN is restricted, this field will still contain calling/called party information. The 3300 ICP relies on the use of the “Privacy: id” header to inform other SIP Peers that this information is to be kept private. If the peer is not trusted, select No for this option. The P-Asserted Identity Header is used by some SIP vendors to present display information (name and number) on SIP phones. |
No |
|
Enable Distinctive Ringing |
Select Yes to allow distinctive ring tones for internal calls, external calls, and callbacks to SIP phones. Enter a text string in the field provided for each ring type that matches the Alert-Info header for the ring tone supported by the SIP device. When you set this option to Yes, the following default Alert header strings are entered in the fields: Internal Ring: ;info=alert-internal External Ring: ;info=alert-external Callback Ring: ;info=alert-priority |
No |