With generic SIP Phone support in the 3300 ICP, SIP endpoints can make use of the rich functionality provided by the 3300 ICP. This capability enables seamless integration of Mitel features with new values of SIP endpoints (e.g., instant messaging). This capability allows the creation of multi-vendor solutions based on open standards and ensures a natural fit of SIP Phones into the 3300 ICP management paradigm. SIP Phone support provides many 3300 ICP call processing features, billing capability, registrar functions, and 3300 configuration and management. See the descriptions below for more information.
Generic SIP Phones support 9-1-1 emergency service and can be assigned a CESID number. CESID support is also provided for the 5302 IP Phone extensions. However, any moves are not automatically reflected in the CESID table; the table must be updated manually (see SIP Phone Support Features).
SIP Phones are configured within the 3300 ICP, 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.
All calls from Generic SIP phones are represented in SMDR as calls from local extensions.
Every generic SIP Phone requires an IP user license in order to be configured.
SIP devices must register with the 3300 ICP 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 as per RFC3261 during registration and while making calls (on SIP REGISTER and INVITE methods).
SIP endpoint (lineside) resiliency comparable with MiNET devices is supported for Ascom IP-DECT and WiFi phones and Mitel 5302 SIP phones. No proprietary signaling is required, so SIP Phones from other vendors should be compatible with 3300 ICP resilient configuration via DNS. For more information about resiliency, refer to Mitel 3300 IP Communications Platform Resiliency Guidelines.
The following Mitel phones are supported:
5302 SIP Phone
5320, 5330 and 5340 IP Phones
Dual Mode SIP sets (5212, 5224, 5235, 5304, 5312, 5324, and Navigator sets with v6.0 software and later)
Notes:
Mitel does not recommend that Mitel dual mode sets be deployed in SIP mode on the 3300 ICP 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 the 3300 ICP.
In order to successfully work with the 3300 ICP 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 1889 shall be used to transport media streams between the 3300 ICP 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 2833, and
(b) In-band with G.711 codec
Conformance with the following RFC specifications is required to fully interoperate with capabilities provided by the 3300 ICP. 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 1321 The MD-5 Message Digest Algorithm
RFC 2976 The SIP INFO Method
RFC 3261 SIP: Session Initiation Protocol
RFC 3262 Reliability of Provisional Responses in SIP
RFC 3265 SIP-Specific Event Notification
RFC 3311 The Session Initiation Protocol UPDATE Method
RFC 3515 The Session Initiation Protocol (SIP) Refer Method
RFC 3891 The Session Initiation Protocol (SIP) 'Replaces' Header
RFC 3892 The SIP Referred-By Mechanism
RFC 3966 The Tel URI for Telephone Numbers
RFC 4028 Session Timers in the Session Initiation
RFC 3665 Session Initiation Protocol Basic Call Flow Examples
RFC 3824 Using E.164 numbers with the Session Initiation Protocol (SIP)
RFC 3842 A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP)
RFC 4566 SDP: Session Description Protocol
RFC 3264 An Offer/Answer Model with SDP
RFC 2833 RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals
RFC 3550 RTP: A Transport Protocol for Real-Time Applications
RFC 3551 RTP Profile for Audio and Video Conferences with Minimal Control
draft-levy-sip-diversion-08.txt Diversion Indication in SIP