Configure the MCD 6.0 for use
with the Commend SIP
Doorphone
SIP CoE 13-4940-00251
NOTICE
The information contained in this document is believed to be accurate in all respects but
is not warranted by Mitel Networks™ Corporation (MITEL
®
). The information is subject to
change without notice and should not be construed in any way as a commitment by Mitel
or any of its affiliates or subsidiaries. Mitel and its affiliates and subsidiaries assume no
responsibility for any errors or omissions in this document. Revisions of this document or
new editions of it may be issued to incorporate such changes.
No part of this document can be reproduced or transmitted in any form or by any means electronic or mechanical - for any purpose without written permission from Mitel Networks
Corporation.
TRADEMARKS
Mitel is a trademark of Mitel Networks Corporation.
Windows and Microsoft are trademarks of Microsoft Corporation.
Other product names mentioned in this document may be trademarks of their respective
companies and are hereby ack nowledge d.
Mitel Technical Configuration Notes – Configure the MCD for use with the Commend SIP
This document provides a reference to Mitel Authorized Solutions Providers for
configuring the Mitel 3300 ICP to host the Commend SIP Doorphone. The different
devices can be configured in various configurations depending on your VoIP solution.
This document covers a basic setup with required option setup.
Interop History
Version Date Reason
1
February 27, 2012 Interop with Mitel 3300 12.0.0.49 and Commend SIP Doorphone
Interop Sta tus
The Interop of the Commend SIP Doorphone has been given a Certification status. This
device will be included in the SIP CoE Reference Guide. The status the Commend SIP
doorphone achieved is:
The most common certification which means the device/service has
been tested and/or validated by the Mitel SIP CoE team. Product
support will provide all necessary support related to the interop, but
issues unique or specific to the 3rd party will be referred to the 3rd party
as appropriate.
Software & Hardware Setup
This was the test setup to generate a basic SIP call between Commend SIP door phone
and the 3300 ICP.
Manufacturer Variant Software Version
Mitel 3300 ICP – Mxe Platform 12.0.0.49
Mitel MBG – Teleworker V7.1.31.0
Mitel 5330 SIP Sets SIP (05.02.00.15)
Mitel 5320 IP Sets Minet (05.02.00.15)
Commend WS800P SIP Doorphone
GE Wireline Analog Set n/a
Firmware: 3.0 Build: 259
13-4940-00251 Commend SIP Doorphone
Tested Features
This is an overview of the features tested during the Interop test cycle and not a detailed
view of the test cases. Please see the SIP Line Side Interoperability Test Pans for
detailed test cases.
Feature Feature Description Issues
Basic Call Making and receiving a call
DTMF Signal Sending DTMF after call setup (i.e. mailbox password)
Call Hold Putting a call on hold N/S
Music-on-Hold The sounds played to other party which is held N/S
Call Transfer Transferring a call to another destination N/S
Call Forward Forwarding a call to another destination N/S
Conference Conferencing multiple calls together N/S
Redial Last Number Redial N/S
MWI Message Waiting Indication N/S
Dynamic Extension Personal Ring Group configuration N/S
Resiliency Basic calls through a Secondary SIP proxy
T.38 Fax Fax Messages N/S
Video Video Capabilities N/S
Teleworker Mitel remote connectivity with Teleworker
- No issues found - Issues found, cannot recommend to use - Issues found
2
13-4940-00251 Commend SIP Doorphone
Resiliency
The following table lists the scenarios of resilience supported by this device when
connected to the MCD 6.0 on the 3300 ICP.
- No issues found - Issues found, cannot recommend use - Issues found
Note: Refer to list of device limitations and known issues later in the document for
recommendations.
The various scenarios are described below. The scenario names are a convenience for
understanding this section of the configuration guide.
Scenario 1: Resiliency is achieved by utilizing the ability of DNS servers to provide
multiple IP addresses against a single FQDN. This is generally achieved by using DNS
SRV or A records. This scenario requires nothing from a SIP Endpoint except that it
supports standard DNS behavior.
Scenario 2: The device has inherent knowledge of the primary and secondary 3300 ICPs
and will switch between them if a SIP request (REGISTER, INVITE, or SUBSCRIBE)
times out. Behavior will be characterized based on whether the device returns to primary
ICP and when this occurs. This scenario has some dependency on user action in order
to detect a failure, especially if configured with a long registration expiry time, so the
chance of a user experiencing a long delay making a call goes up.
Scenario 3: The behavior of the device is the same as that of scenario 2, except that the
device will “ping" the currently active server with an OPTIONS request. If the OPTIONS
request times out, the device will switch to the alternate server for all future requests.
The intent of this scenario is to provide much faster failure detection by the device. This
will allow devices to failover to their alternate ICP much more quickly, and much more
unnoticeably. (If the device can detect a failure of the primary ICP, and can failover
immediately, the chance that the user even notices a lack of service falls dramatically.)
Scenario 4: The device will support a new SIP header designed specifically for
resiliency. The P-Alternate-Server header must be included in a 200 OK or 301 Mov ed Permanently response. This header will include data that designates the potential
servers and which server the UA must use.
Loading...
+ 16 hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.