# SIP Phone Support - Description

## Overview

With generic SIP Phone Support, SIP endpoints can make use of the rich functionality provided by MiVoice Business. It also enables seamless integration of new SIP-based features, such as instant messaging, with traditional Mitel telephony features.

### 911 Support

Generic SIP Phones support 911 emergency service and can be assigned a CESID number. CESID support is also provided for the 5302 IP Phone. However, any moves are not automatically reflected in the CESID table; the table must be manually updated.

### MiVoice Business Management and Configuration

SIP Phones are configured in MiVoice Business, similar to Multi-line sets and Hotdesk users. Each SIP phone has a main DN associated with it. Additional lines can be programmed for the SIP Phone allowing calls for alternate DNs to be delivered to the SIP Phone.

Additionally, the behavior of a given SIP device can be characterized using the SIP Device Capabilities form and then applied to SIP phones to support alternate capabilities.

### Billing and SMDR

All calls from Generic SIP phones are represented in SMDR as calls from local extensions.

### Licensing

A generic SIP Phone requires an IP User license in order to be configured. However, if a generic SIP Phone is configured as a Single Line Phone, it consumes a Single Line Users (formerly Analog Lines) license instead of an IP User license.

### Secure SIP Signaling with TLS

MiVoice Business supports secure SIP signaling with the following endpoints:

- Mitel-branded TLS-capable SIP Devices, including 5603, 5604, 5607, 5613, and 5614

- 3rd party SIP devices as approved by Mitel's SIP Center of Excellence

NOTE: TLS connections from these devices to MiVoice Business may be direct or through the MiVoice Border Gateway.

SIP requires standard security implementation; therefore, Transport Layer Security (TLS) protocol is used for SIP message encryption, as described in RFC 2246. See Transport Layer Security (TLS) for more information on TLS for SIP signaling.

### Registration and Authentication

SIP devices must register with MiVoice Business using the SIP Register method as described in RFC3261. Registration cannot occur unless the device has been configured (see SIP Phone Support Programming).

Authentication can be enabled on a per SIP device basis (see SIP Phone Support Programming). If authentication is enabled, the SIP device will be challenged in accordance with RFC3261 during registration and while making calls (on SIP REGISTER and INVITE methods), and in accordance with RFC3265 for Subscription (MWI) authentication.

When TLS is used for secure connections, most SIP devices can be configured to initiate a TLS connection at Registration time (SIP REGISTER) and to maintain the TLS connection opened for subsequent phone calls (incoming and outgoing). To establish those connections, MiVoice Business uses the TLS Server Authentication method, where the server's security certificate is used to identify the server by its IP address or its FQDN (see SIP Phone Support - Programming).

NOTE: Most SIP phones use the IP address to authenticate the server.

If a TLS connection is closed, it must be re-established by the set and not MiVoice Business. SIP sets that keep the TLS connection open only for the duration of a call are not supported.

When MiVoice Business reboots, either because of a planned upgrade or unplanned event such as a power outage, MiVoice Business remembers the registration information for non-resilient SIP devices and automatically re-creates the registrations. This allow the SIP devices to place and receive calls without having to wait for the devices to re-register on their own at some later time.

### SIP Media Security

SIP requires standard security implementation; therefore, Secure Real-time Transport Protocol (SRTP) as defined by RFC 4568 is used to ensure secure end-to-end media streaming for SIP connections.

SRTP requires consistent end-to-end encrypted media negotiations; therefore, every component that negotiates SRTP with a SIP endpoint must comply with RFC 4568. Many SIP devices can also negotiate SRTP (preferred) or regular unencrypted RTP. Negotiation is preferred over a strict SRTP-only implementation since it allows connection to both SRTP and non-SRTP devices. If your system includes SIP Phones that offer only SRTP, it is recommended that the entire network is SRTP compliant. By default on upgrade and during configuration the system uses the AVP Only Device option to avoid incompatibility issues. You can enable SRTP by changing the AVP Only Device option to "No" once your endpoint is configured for SRTP.

SIP devices that are not SRTP-capable accept only unencrypted messages. For SRTP-capable devices, MiVoice Business system supports two types of media negotiations:

- Strict Security - SRTP only; if the far endpoint is unable to negotiate standard SRTP, the call will fail to connect

- SRTP (SAVP - Secure Audio Video Profile) or non-secure (AVP); if the far endpoint does not support SRTP, non-secure option will be used

NOTE: Mitel 5603/5604/5607 (Ascom) devices offer SRTP only, but will accept an SRTP or RTP answer. If you decide to configure the base station to enable Mitel 5603/5604/5607 (Ascom) devices to offer SRTP, you also need System Option "Voice/Video SRTP Encryption Enabled" set to "Yes" and SIP Device Capabilities option "AVP Only Device" set to "No" for each phone type. When SRTP is enabled for these devices they are capable of doing either SRTP or unencrypted RTP.

See MiVoice Business Engineering Guidelines for the list of devices (sets and applications) that support or do not support SRTP encryption.

### Resiliency

SIP endpoint (lineside) resiliency comparable with MiNET devices is supported on Mitel SIP phones (except the 5302) and on Ascom IP-DECT and WiFi phones. No proprietary signaling is required, so SIP Phones from other vendors should be compatible with resilient MiVoice Business configurations via DNS (the same mechanism used to provision resiliency on Mitel SIP phones). For more information about resiliency and how to provision it, refer to MiVoice Business Resiliency Guidelines.

### Single Line Phone Support

A Generic SIP phone can be configured as a Single Line Phone: a Full service device that consumes a Single Line Users (formerly Analog Lines) license instead of an IP Users license.

A Single Line Phone has only one line appearance and cannot have any keys programmed for it on the MiVoice Business system.

To apply the Single Line Phone functionality to a Generic SIP Phone, select the 'Single Line Phone' check box under the Service Profile tab in the User and Services Configuration form. See SIP Phone Support - Programming for details.

Single Line Phone configuration is supported only for the 'Generic SIP Phone' device type with 'Full' service level.

5505 SIP device does not support Single Line Phone configuration.

A Single Line Phone :

- cannot be a hot desk device or a member of a Multi-device User Group (MdUG);

- supports resiliency - if the underlying Generic SIP Phone is programmed as resilient;

- can use Single Line features invoked with Feature Access Codes (FAC).

## Supported Phones

The following Mitel phones are supported:

- 5302, 5320/5320e, 5330/5330e, 5340/5340e, and 5505 SIP desktop phones

- 5610 SIP cordless phone

- 5603, 5604, 5607, 5613, 5614, 5624 and 5634 SIP wireless phones

- Dual Mode SIP desktop phones (5212, 5224, 5304, 5312, 5324, and Navigator sets with v6.0 software and later)

- 612, 622, 632, and 650 SIP-DECT Phones

NOTES

- Mitel does not recommend that Mitel dual mode sets be deployed in SIP mode on MiVoice Business systems because in SIP mode the set provides significantly less functionality than it does in MiNET mode.

- Mitel does not guarantee SIP interoperability with generic SIP sets. We offer a SIP interoperability verification program to allow third parties to verify interop between their SIP devices and MiVoice Business.

- Resiliency is not supported on 5302 SIP phones.

### Generic SIP Endpoint Interoperability Requirements

To work with MiVoice Business the Generic SIP Endpoint must comply with the following specifications:

- Session Description Protocol (SDP) as described in RFC 4566 in conjunction with the offer/answer model described in RFC 3264. Compression and any other techniques that require mutual modification of the media stream shall be negotiated between endpoints using Session Description Protocol (SDP)

- Real-time transport protocol (RTP) as described in RFC 3550 shall be used to transport media streams between MiVoice Business and the SIP Endpoint Server.

- Support ITU G.711 codec with a packetization rate of 20 ms.

- Support the following ways of transportation for DTMF tones:

(a) RTP headers format as described in RFC 4733, and

(b) In-band with G.711 codec

### RFC Compliance

Conformance with the following RFC specifications is required to fully interoperate with capabilities provided by MiVoice Business. While conformance to RFCs is the key element in ensuring interoperability, it is not possible to guarantee compatibility of products without interoperability testing. This is due to the fact that some of the RFCs define several implementation options and compliance with one set of options may impair interoperation with an implementation selecting a different set of options. In addition, differences in the interpretation of respective RFCs may lead to incompatibilities.

Interoperability testing is strongly encouraged.

### RFC Support

RFC 1321 The MD-5 Message Digest Algorithm

RFC 2246 The TLS Protocol Version 1.0

RFC 2976 The SIP INFO Method

RFC 3261 SIP: Session Initiation Protocol

RFC 3262 Reliability of Provisional Responses in SIP

RFC 3264 An Offer/Answer Model with SDP

RFC 3265 SIP-Specific Event Notification

RFC 3311 The Session Initiation Protocol UPDATE Method

RFC 3325 P-Asserted-Identity

RFC 3326 The Reason Header Field for the Session Initiation Protocol (SIP)

RFC 3515 The Session Initiation Protocol (SIP) Refer Method

RFC 3550 RTP: A Transport Protocol for Real-Time Applications

RFC 3551 RTP Profile for Audio and Video Conferences with Minimal Control

RFC 3665 Session Initiation Protocol Basic Call Flow Examples

RFC 3725 Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)

RFC 3842 A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP)

RFC 3891 The Session Initiation Protocol (SIP) 'Replaces' Header

RFC 3892 The SIP Referred-By Mechanism

RFC 4028 Session Timers in the Session Initiation

RFC 4244 History Info

RFC 4566 SDP: Session Description Protocol

RFC 4568 Session Description Protocol (SDP) Security Descriptions for Media Streams

RFC 4730 SIP Event Package for Key Press Stimulus (KPML)

RFC 4733 RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals

RFC 4916 Connected Identity in the Session Initiation Protocol

RFC 5373 Requesting Answering Modes for the Session Initiation Protocol (SIP)

RFC 5806 Diversion Indication in SIP

RFC 5876 Updates to Asserted Identity in the Session Initiation Protocol

RFC 6432 Carrying Q.850 Codes in Reason Header Fields in SIP (Session Initiation Protocol) Responses

Related Topics

- SIP Phone Support - Condition

- SIP Phone Support - Programming

- SIP Phone Support - Maintenance