# SIP Device Capabilities

## 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.

A SIP Device Capability profile can be applied to particular SIP devices (or set of devices) to allow for proper operation as recommended through the Mitel interop process. It also enables a set of features for the particular device. Some features are not device dependent and may be changed (enabled/disabled) based on site/customer requirements.

The SIP Device Capabilities forms are shared across all nodes in a cluster (see SDS sharing for more information).

There are 64 fully user-configurable SIP Device Capabilities, which can be programmed based on a successful interop for generic SIP sets. Pre-configured SIP Device Capabilities are available for Device Types 5603, 5604, 5607, 5610, 5613, 5614, 5624, 5634, 5505, UC Endpoint, Single Line UC Endpoint, and SIP-DECT 612, 622 and 632, 650, and Analog-FXS. The pre-configured profiles already provide for proper operation of these devices and do not need to be changed unless additional site/customer features are required.

Use this form when performing the following tasks:

- Programming SIP Phones

- Managing Configuration Profiles

The default values in this form are the defaults for the 64 fully user-configurable SIP Device Capabilities. In some cases Mitel recommends a different setting -- indicated in the following table with a '**' beside the original default value. The factory defaults, provided when SIP support was first introduced, remained largely unchanged to ensure backward compatibility with existing installations as they upgrade.

NOTE: The recommendations are based on extensive in-house testing but are not guaranteed to work in all installations. You are strongly urged to test your configuration before deploying it to ensure it meets your customer's needs.

## Field Descriptions

Parameter | Description | Default Value
Basic
SIP Device Capabilities Number | System-generated, protected field. Indicates the number of the SIP Device Capabilities profile that you want to edit. NOTE: SIP Device Capabilities profile number 65 and up are pre-configured for specific Mitel SIP devices. |
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
Basic - 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 MiVoice Business. | Blank
Emergency Info Provided by Device | Select Yes to enable only if the SIP endpoint is providing location information to the MiVoice Business. | No
Replace System based with Device based In-Call Features | Recommend setting: 'Yes'. The original default value was 'No', but most current SIP phones handle multiple calls well and should maintain information about calls in progress, making use of transfer and conference features on the phone if available. Phones that do not support conferencing can still in most cases use the Conference Call capability of the MiVoice Business, using the appropriate Feature Access Code. | 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
Enable Digit Collection In Busy or Alerting State | Select Yes to enable support for the Callback, Camp-on, and Busy Override features on these devices. There is additional system programming required to enable these features. Use the links above to access programming details. NOTE: Enabling this option prevents cut-through audio and pre-recorded messages that may be played from a Central Office. Instead, the user will have access to MiVoice Business Features, such as Callback, Camp-on and Busy Override and hear locally generated Busy or Alerting tones. | No
TLS Only | Indicates whether to allow devices only with TLS to register and place calls. | No
SDP Options
Allow Device To Use Multiple Active M-Lines | When set to 'Yes', MiVoice Business allows 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'. NOTE: For Secure Real-time Protocol (SRTP) negotiations generally this option is enabled. | No **
Allow Using UPDATE For Early Media Renegotiation | Select 'Yes' to allow the media source to be switched using an UPDATE message prior to the call being answered. NOTE: Enable this option only if the SIP set or trunk supports early media negotiation. See RFC 3311 for details. | No **
AVP Only Device | The default 'Yes' indicates that the device is to be used for unencrypted media only (either the device is not capable or not configured to use Secure Real-time Protocol [SRTP]). This is the same mode (unencrypted) that devices used in pre-7.0 MiVoice Business releases. If you want the SIP devices to allow SRTP encryption, set this option to 'No' and option Allow Device To Use Multiple Active M-Lines to 'Yes'. This is necessary because many SIP implementations use two or more m-lines to negotiate either SRTP or non-SRTP (one m-line for each). The System Option "Voice/Video SRTP Encryption Enabled" is also required to be set for SRTP to be negotiated. If this option is set to "No", calls may negotiate as either SRTP or non-SRTP, depending on the capabilities of the devices that are being connected. See Voice Streaming Security for more information. | Yes
Enable Mitel Proprietary SDP | Select 'Yes' only if communicating with a MiVoice Border Gateway. This enables proprietary encryption to be enabled if SRTP is not negotiated. | 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 devices that require SDP in the Initial Invite. In some situations, MiVoice Business 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. If the real SDP is not available, a renegotiation is necessary to get media working. | No
Ignore SDP Answers in Provisional Responses | Select "Yes" to improve interoperability with SIP systems that adhere to RFC 3960 and do not always provide audio when sending SDP information in the 18x messages. As a result, the device placing the call may hear silence. With this option enabled, the SDP Answer is ignored during ringback and local ringback tone is provided to the device placing the call. Once the call is answered the media is connected. | No
IP Media Default | Select the addressing type (ipv4, ipv6, dual-anat, or dual-altc) for SDP. For SIP devices that support dual media (IPv4 and IPv6) with RFC 4091 or RFC 4092, select dual-anat (Alternative Network Address Type). For SIP devices that support dual media (IPv4 and IPv6) with RFC 6947, select dual-altc (Alternate Connectivity Attribute). | ipv4
Limit to one Offer/Answer per INVITE | Recommended setting: 'Yes'. Most vendors expect just one Offer/Answer exchange in the initial Invite transaction. If the device can begin a second offer in the 200ok and expects a response, set this option to 'No'. | No **
Prevent Codec Selection on Answer | Select 'Yes' to prevent the MiVoice Business from making a codec selection on a list of codecs in the received SDP before sending an SDP Answer. Select 'No' to allow the MiVoice Business to apply a default policy to make an audio/image codec selection before sending an SDP Answer. | No
Prevent SDP Renegotiation if Peer Initiated Hold | Select 'Yes' to prevent sending SDP renegotiation messages to the peer device when the peer initiated the hold request. In some cases the MiVoice Business may attempt renegotiations while on hold. Some devices may become confused and prevent the call from being retrieved. Set this option to Yes if issues are detected. | No
Prevent the Use of IP Address 0.0.0.0 in SDP Messages | Recommended setting: 'Yes'. IP Address 0.0.0.0 is the deprecated indicator of hold. When this option is set to 'Yes', the media signaling includes the direction indicators, such as ‘sendonly’, ‘inactive’, etc., as well as the real IP address. When this option is set to 'No', in some cases it can prevent audio from being available when prompts or music-on-hold is being played to specific devices, which require knowledge of the transmitters IP address. | No **
Renegotiate SDP To Enforce Symmetric Codec | Recommended setting: 'Yes'. This option forces the use of the same codec (for example, G.729) in both incoming and outgoing directions and prevents the possible media failure. When an SDP Answer is received with a list of codecs with a different ordering, it can be unclear which codec will be used in either direction. If MiVoice Business detects this situation, this option will send a Re-invite with a single codec to ensure that there is no misunderstanding. | No **
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 renegotiating media. This is the RFC recommendation. Devices should increase the session-version when modification is made to SDP session data. The default is still 'No' because not all vendors adhere to this recommendation and usually this is the safer option. The interop process should detect whether the device increments the session-version as expected or not, and set this option accordingly. The drawbacks to renegotiating on a duplicate offer is the restart of RTP streaming and possible change of the media attributes, which may not be expected by the device. | No
Send Answer only after renegotiation is complete | Recommended setting for most customers: 'Yes'. During a transfer it is possible to send a renegotiation request to a MiVoice IP Phone to change the endpoint it is streaming to. This option is used to determine when the renegotiation request should be answered. For some SIP phones the best option is to answer immediately rather than wait for the renegotiation to complete since this might take slightly longer. If MiVoice Business answers too early, it will cause a second renegotiation to connect the user to the final destination. | No **
Support CTI Hold/Retrieve | Select Yes to enable a CTI application to hold and retrieve calls on a SIP endpoint using the hold and talk event packages. This option is enabled only on SIP endpoints that support the hold and talk event packages. | No
Suppress Use of SDP Inactive Media Streams | Recommended setting: 'No'. With this setting, MiVoice Business provides the actual direction attribute ‘inactive’ instead of pretending media is available when it is not. While media connections are transitioning (hold/transfer/conference, etc.), or in some cases at call setup, the media may be temporarily unavailable causing MiVoice Business to send an inactive SDP. If this option is set to 'Yes', MiVoice Business will instead attempt to use the IP address 0.0.0.0 or mark streams as sendonly/recvonly to avoid the use of inactive, which is not supported by some SIP devices. | Yes **
Signaling and Header Manipulation
Allow Display Update | Recommended setting: 'Yes'. This setting allows the system to update SIP phone displays with connected party name and number information during transfers, conferences, and call forwarding scenarios. | No **
Allow FQDN for Resiliency | Indicates the type addressing for resiliency signalling. NOTES: This parameter is disabled for 5505 and 5610 IP phones. For cMiVB, regardless of this option's setting, FQDNs are used for resiliency. | No Yes (for cMiVB only)
Disable Reliable Provisional Responses | Select 'Yes' to disable the use of reliable provisional responses (PRACK) on outgoing and incoming calls. However, an incoming call that uses the Require header may negotiate PRACK despite this option being enabled. PRACK is useful for early-media negotiations and should be used if supported. NOTE: This option takes precedence over the "Require Reliable Provisional Responses on Outgoing Calls" option. | No
Disable Use of User-Agent and Server Headers | Select 'Yes' to disable the insertion of "User-Agent" headers in Request and "Server" headers in Response messages. This option should be enabled only if the product has known deficiencies which place the system at risk of attack. | No
To Keep Call Active On Mid-Call Feature | 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
If TLS use 'sips:' Scheme | Select Yes to use the "sips:" (Secure SIP) scheme to signal secure (TLS) SIP messaging. Select No to use the "sip:" signaling scheme, where security is indicated by the "transport=TLS" parameter. | No
Mode for Out-of-Band DTMF | Enables delivering Out-of-Band DTMF from a MiVoice Business system to a SIP service without interrupting audio playback. Select RFC 4733 DTMF to deliver Out-of-Band DTMF in the audio playback, using RFC 4733 formatted digits. This mode causes interruptions in the audio playback. Select SIP INFO dtmf-relay to deliver Out-of-Band DTMF through SIP INFO messages in the application/dtmf-relay content-body. This mode does not cause interruptions in the audio playback. | RFC 4733 DTMF
Multilingual Name Display | Select 'Yes' to enable the Multilingual Name Display feature for a specific SIP device. This option will activate only if the 'Multilingual Name Display' System Option is enabled. Selecting 'No' for this option does not disable the feature for the whole system - only for the selected device capability number. | No
Override Auto-Answer Headers | Select Yes to override the headers normally used to provide auto-answer functionality. The replacement header is specified below, in the "Override Auto-Answer Headers With" field. | No
Override Auto-Answer Headers With | If "Override Auto-Answer Headers" is set to "Yes," enter the SIP auto-answer header. For standard SIP devices that support RFC 5373, enter "Answer-Mode: Auto". For non-standard SIP devices, enter the appropriate proprietary header. | Blank
Q.850 Reason Headers | Select Yes to include the Q.850 cause code in the Reason Header field of the CANCEL, BYE, 3xx, 4xx, 5xx, and 6xx SIP messages. See RFC 3326 and RFC 6432. | No
Remove Anonymous User | Select Yes to omit the word "anonymous" from call setup messages for private calls. Thus, instead of "John Doe - Anonymous" the called party sees only "John Doe" displayed on their phone (or "Private" instead of "Private - Anonymous" if both name and number are marked private). | No
Require Reliable Provisional Responses on Outgoing Calls | Recommended setting: 'Yes'. This setting requires the use of reliable provisional responses (PRACK, RFC 3262) on outgoing calls. Unless required, most device will not default to use PRACK, allowing for early-media negotiations. NOTE: Enable this option only for SIP devices that support the PRACK method. This option has no effect if it is enabled and "Disable Reliable Provisional Responses" is also enabled. | No **
Suppress Redirection Headers | Select 'Yes' to omit redirection headers (Diversion and History-Info Headers for Call Forwarding and Referred-By Header for Transfer) in call setup messages. This option is provided for users who do not want their phones to display this information on calls forwarded or transferred to them by MiVoice Business. | 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 and is often used to update display information on SIP phones. This header is omitted when the callers information is private. | Yes
Use P-Call-Leg-ID Header | Select 'Yes' to include the Call Leg Call ID within the SIP trunk messages exchanged between MiVoice Business and third-party applications. This ID is always included in MiVoice Business-based MiTAI events, so enabling this field allows for SIP sessions to be aligned with MiTAI events. A new ID will be generated for each call. The header will be in the Invite message - for outgoing calls. For incoming calls, it will be in the 18x message and, if answered, in the 200 OK message OR in a clearing message, such as 3xx, 4xx, 5xx, 6xx (not authentication 401/407). | No
Use user=phone | Select Yes to insert the "user=phone" parameter into SIP URIs. | No
Distinctive Ring Tones
Enable Distinctive Ringing | Recommended setting: 'Yes'. This setting allows distinctive ring tones for internal calls, external calls, and callbacks to SIP phones. This option is safe and provides additional value for phones that use it. | No **
Internal Ring | Enter a text string for the internal ring tone. The string must match the Alert-Info header for the ring tone supported by the SIP device. | ;info=alert-internal
External Ring | Enter a text string for the external ring tone. The string must match the Alert-Info header for the ring tone supported by the SIP device. | ;info=alert-external
Callback Ring | Enter a text string for the callback ring tone. The string must match the Alert-Info header for the ring tone supported by the SIP device. | ;info=alert-priority
Timers
Registration Period Minimum | This field sets the minimum negotiated time period 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, you can set the minimum registration period to a lower value. For a new set, it is beneficial to check how frequently the set actually re-registers. Most sets re-register close to the negotiated period but some ignore it and re-register much more frequently and may cause performance issues on the system. | 300 seconds
Session Timer | Enter a value of 0 or 90 to 9999 seconds. 0 will disable the timer. If the device does not respond within the allocated time, the session (call) is torn down. It is recommended that this be set to a non-zero value unless there is a specific reason to disable it (set to 0). The benefit of this option is that it can help clear calls that get stuck due to signaling errors. If the device responds with a 422 “Session Interval too Small,” you may want to increase the session timer to the value indicated by the device to minimize delays in call setup. The Session Timer will use the UPDATE message if it is supported by the peer. If not supported we will use ReINVITE messages as described in RFC 4028. The Session Timer refresh is sent at half the Session Timer value. For example, if the value is 120 seconds, then the messaging (UPDATE or ReINVITE) will occur every 60 seconds. To limit extra messaging a larger value (e.g. 3600 seconds) can be used for the Session Timer to eventually cleanup any possible stuck resources. | 0 **
Session Timer: Local as Refresher | Selecting 'Yes' sets MiVoice Business (local), instead of the device, as the Session Timer Refresher (in accordance with RFC 4028). ). Some device will require the MiVoice Business to be the refresher. Session timer refresh information will be included in Reinvite messages sent by MiVoice Business, as well as in Updates. | No
Subscription Period | Enter a value between "120" and "99999" seconds, in increments of 1 second, to define the initial period for SIP outgoing subscriptions. | 3600
Subscription Period Minimum | Enter a value between "120" and "3600" seconds, in increments of 1 second, to define the minimum amount of time that the system maintains incoming SIP subscriptions (for example, message-waiting indications). | 300
Subscription Period Refresh (%) | Enter a value between "50" and "99" percent to define the outgoing subscription refreshment interval. When this percentage of the Subscription Period is reached, the subscription is refreshed. | 80
Invite Ringing Response Timer | Enter a value between 1 and 30 seconds to define the time the system waits to receive a ringing response before it redirects a call using out-of-service handling. NOTE: This is an important feature for SIP Wireless or SIP-DECT sets that may lose service temporarily or for resilient solutions that need to make sure the call gets delivered in a reasonable amount of time. Since most wired SIP phones respond quickly, a timeout value of 2 to 3 seconds is usually enough for basic calls. In some circumstances the SIP phone may require more time (up to 10 seconds) to start alerting the phone. There is a trade-off between waiting too long (the caller hangs up because they hear no ringback) and too short (the call doesn't get presented to the user and goes to out-of-service handling). Without the timer, callers to a SIP phone could get a full 32 seconds of silence (if they wait that long) before they are re-routed to some other destination. If Hot Desk PIN Security is in use, the recommended default is 6 seconds. | 0 **
Key Press Event Options
Allow Out Subscriptions for Remote Digit Monitoring | Set this option to 'Yes' if an outbound proxy or session border controller is expected to perform outgoing KPML digit collection. | No
Force Out Subscriptions for Remote Digit Monitoring | Set this option to 'Yes' to force MiVoice Business to request outgoing KPML digit collection from other SIP servers that wish to inject mid-call digits. | No
Called Party Inward Dialing Modification
Index | Read-only, protected field. Each index number represents a unique inward dialing modification rule. The rules are applied in consecutive order; for example, rule 1 is applied before rule 2. |
Digits to Match | Read-only, protected field. The digits to match at the beginning of the dial string in inbound calls. | Blank
Digit Length Operator | Display-only, protected field. The digit length operator to apply to the incoming call. Valid operators: undefined equal to less than greater than greater than or equal to less than or equal to | undefined
Digit Length | Read-only, protected field. The number of digits to match (0-32) at the beginning of the dial string in inbound calls. | 0
Number of Digits to Absorb | Read-only, protected field. The number of digits to absorb (0-32) at the beginning of the dial string in inbound calls. | 0
Digits to be Inserted | Read-only, protected field. The string to insert at the beginning of the dial string in inbound calls. | Blank
Record Information
Date Created | Read-only field. Displays the creation date of the SIP Device Capabilities profile. For a new profile, this field defaults to the current date. | MM DD YY
Creator | Enter the name of the person responsible for creating the SIP Device Capabilities profile. For a new profile, this field defaults to "Local." | Local
Created with Version | Read-only field. Displays the MiVoice Business software version number of the SIP Device Capabilities profile. For a new profile, this field defaults to the current software version. |
SIP Device | Enter the name of the SIP device using this profile. | Blank
Vendor Notes | Enter additional information concerning the SIP device using this profile. For example, enter the release date and version number of the SIP device software. | Blank
Advanced
Dial Plan | Applies to 5505 SIP Phones only. The Dial Plan is the mechanism used to determine the end of dialing. Your dial plan should be able to handle at least 90% of calls with inter-digit timers handling the rest. Enter the plan as a series of digit strings separated by semi-colons to a maximum of 80 characters. Use an ‘x’ in the digit string to represent any single digit (0 through 9). For example, the string 1xx; 2xx; 9613xxxxxxx; would terminate dialing automatically when the following numbers are dialed: 100-199 / 200-299 / any 7-digit number in the 613 area code (assuming 9 is used to get an outside line). | Blank