for Mitel MiVoice MX-ONE TS - New Voice International...CoF for MobiCall and MX-ONE 5.0 10 6 TEST...

© Copyright 2014, Mitel Networks Corporation. All Rights Reserved. The Mitel word and logo are trademarks of Mitel Networks Corporation. Any reference to third party trademarks are for reference only and Mitel makes no representation of ownership of these marks.

Mitel.com

Certificate of Function for

Mitel MiVoice MX-ONE TS with

NewVoice International AG MobiCall

Template: qm-0227 / 2.0

Doc-Id: depl-2285 / 1.0

Author: Oliver Linke

Date: 07.04.2015

CoF for MobiCall and MX-ONE 5.0 2

CONTENTS

1 Management Summary ............................................................................................... 3 1.1 Purpose of the test ............................................................................................................................ 3 1.2 Result of the test ............................................................................................................................... 3

1.2.1 Summary of supported functionality ........................................................................................... 3 1.2.2 Summary of restrictions and limitations ...................................................................................... 3 1.2.3 Conclusion .................................................................................................................................. 3

1.3 Open Topics / Next Steps ................................................................................................................. 3

2 General Information ..................................................................................................... 4 2.1 Partner Company .............................................................................................................................. 4 2.2 Mitel Product Line / Mitel CSU ......................................................................................................... 4

3 Product information .................................................................................................... 5 3.1 Hardware Components ..................................................................................................................... 5

3.1.1 IP PBX system and Terminals .................................................................................................... 5 3.1.2 Partner Product Hardware Components ..................................................................................... 5

3.2 Software Components ...................................................................................................................... 5 3.2.1 Version details ............................................................................................................................ 6

3.3 Application Type ............................................................................................................................... 6 3.3 Language Support ............................................................................................................................ 6 3.4 Interfaces ........................................................................................................................................... 7

4 Application overview ................................................................................................... 7 4.1 Brief Description of the Application ................................................................................................ 7

4.1.1 Overview ..................................................................................................................................... 8 4.2 System Architecture of Application and Validation Environment ............................................... 8

5 Installation and Configuration .................................................................................... 9 5.1 Pre-conditions ................................................................................................................................... 9 5.2 Installation of the Application .......................................................................................................... 9 5.3 Configuration of the Switch ............................................................................................................. 9 5.4 Configuration of the Application ..................................................................................................... 9

6 Test Execution ........................................................................................................... 10 6.1 Alarming functionality .................................................................................................................... 10

6.1.1 Pre-conditions ........................................................................................................................... 10 6.1.2 SIP trunk ................................................................................................................................... 10 6.1.3 eSMS ........................................................................................................................................ 14 6.1.4 XML ........................................................................................................................................... 17 6.1.5 Screenshot of several test cases .............................................................................................. 18

7 ANNEX A: Installation & Configuration ................................................................... 25 7.1 Details on Installation of the Application ..................................................................................... 25 7.2 Details on Configuration of the Switch ......................................................................................... 25 7.3 Details on Configuration of the Application ................................................................................. 26

7.3.1 Main Confguration of MobiCall ................................................................................................. 26 7.3.2 VOIP Settings ........................................................................................................................... 27 7.3.3 nvt.ini SIP Settings .................................................................................................................... 28 7.3.4 Alarm Configuration .................................................................................................................. 29

8 ANNEX B: Support and Escalation Processes ....................................................... 30 8.1 Pre-Conditions ................................................................................................................................ 30 8.2 Qualified Products being sold by Partner Company ................................................................... 30

8.2.1 Support Responsibilities ........................................................................................................... 30 8.2.2 Support Process ....................................................................................................................... 30

9 ANNEX C: General Rules to use this Template ....................................................... 32


1 MANAGEMENT SUMMARY

1.1 PURPOSE OF THE TEST

The purpose is validating the interoperability of the MobiCall Alarm Server from New Voice and MiVoice MX-ONE TS

1.2 RESULT OF THE TEST

1.2.1 SUMMARY OF SUPPORTED FUNCTIONALITY

MobiCall functionality via MiVoice MX-ONE TS

1.2.2 SUMMARY OF RESTRICTIONS AND LIMITATIONS

No known restrictions

1.2.3 CONCLUSION

TEST RESULT DECISION CRITERIA FOR CATEGORIZING THE TEST RESULT

fully acceptable

acceptable with restrictions

not acceptable

1.3 OPEN TOPICS / NEXT STEPS

No open topics


2 GENERAL INFORMATION

2.1 PARTNER COMPANY

COMPANY NAME: NewVoice Systems GmbH

COMPANY ADDRESS: Mörikestraße 17

71636 Ludwigsburg

Germany

CONTACT PARTNER

NAME:

TEL:

E-MAIL:

ROLE:

Oliver Linke / Michael Köllner

+49 7141 94759 754

[email protected]

System engineer

SUPPORT HOTLINE

TEL:

E-MAIL:

+41 58 750 11 11

[email protected]

2.2 MITEL PRODUCT LINE / MITEL CSU

COMPANY NAME: DAMOVO Deutschland GmbH & Co KG

COMPANY ADDRESS: 40549 Düsseldorf

Heerdter Lohweg 35

Germany

www.damovo.com

www.damovo.de

CONTACT PARTNER:

NAME:

TEL:

E-MAIL:

ROLE:

Thomas Pohl

+49 211 8755 4263

[email protected]

System Support Engineer / Technical Consultant

CT VoIP / Mitel MX-ONE TS

SUPPORT HOTLINE

TEL:

E-MAIL:

+49 211 8755 5555

[email protected]


3 PRODUCT INFORMATION

3.1 HARDWARE COMPONENTS

3.1.1 IP PBX SYSTEM AND TERMINALS

Product Version Details

Mitel PBX Appliance

MX ONE TS With MGU Media Gateway and Integrated DECT, ASU as a server, single-server, no server or network redundancy

Mitel PBX Software

TS5.0 SP5 HF2

Mitel IP Dect Base Station

SIP-DECT 5.0 SP1

Desk Phone Mitel 6739i Mitel 6865i

SW 3.3.1.2234 SW 4.0.0.92

Dect Phone Mitel DT423 Mitel 630d

DT423 used with Integrated DECT: SW 4.2.5 630d used with SIP-DECT: 5.00.SP3 SW 128.7.24 BT 1.3.7

Note: The SIP-DECT devices did not send or receive SMS. SIP-DECT devices were tested as another kind of SIP terminal, just like any desk phone.

3.1.2 PARTNER PRODUCT HARDWARE COMPONENTS

Product Version Details

MobiBBox Version 2.0

- Windows 7 Embedded Operating System - CPU 2x 1,86 GHz | 4 GB RAM | 60 GB SSD - 2 Gigabit LAN | 6 USB 2.0 | 2 Display (VGA, HDMI) - Dimensions 43,0 x 220,0 x 135,0mm - 4 x COM-Port for the connection of 3 interfaces - + SMS-Modul/Watchdog-Box

Switch

3.2 SOFTWARE COMPONENTS

PRODUCT NAME

PRODUCT SW VERSION

COMMUNICATION SYSTEM NAME

COMMUNICATION SYSTEM SW VERSION

MobiCall 7.8.1 MiVoice MX-ONE TS TS5.0 SP5 HF2


3.2.1 VERSION DETAILS

NV 7.8.1 - 20150123

WEB 7.8.1 – 20140711

Module:

Dateiname: Datum:

Cb5.dll 10.09.2013 11:04

NVC.exe 25.03.2014 8:21

NVE.exe 14.07.2014 10:31

nvPTLib.dll 29.10.2013 11:41

NVTAF.exe 14.07.2014 10:31

NVTDAC.exe 14.07.2014 10:31

NVTDVR.exe 14.07.2014 10:31

Nvtme.exe 14.07.2014 10:31

Nvtmt.exe 14.07.2014 10:31

Nvtvoip.dll 04.09.2014 17:17

NVTVOIP.exe 07.10.2014 16:49

Opal.dll 03.10.2013 13:58

PTLib.dll 03.10.2013 13:25

3.3 APPLICATION TYPE

APPLICATION TYPE VERTICAL APPLICATION TYPE

Call Center (ACD)

Alarming

Call Data Recording (CDR)

Computer Telephony Integration (CTI)

Fixed Mobile Convergence (FMC)

Interactive Voice Response (IVR)

Unified Messaging System (UMS)

<other>

Healthcare

Hotel

<other>

3.3 LANGUAGE SUPPORT

LANGUAGE SUPPORT

Brazilian

Danish

Dutch

English

Finnish

French

German

Greece

Italian

Norwegian

Portuguese

Russian

Spanish

Swedish

<other>


3.4 INTERFACES

MIVOICE MX-ONE

AL / CSTA III

AL / CSTA I

AL / TAPI

CSTA III

ISDN

SIP subscriber

SIP trunk

Message Link ( SMS to MX-ONE Integrated DECT)

XML

1) In case of connecting an application to Mitel 5000 via CSTA one needs to include multiple CSTA servers, backup, redundancy and dual homing into account when testing the application integration

4 APPLICATION OVERVIEW

4.1 BRIEF DESCRIPTION OF THE APPLICATION

With MobiCall it is possible for all critical important communication needs to enable the best, most effective responsiveness of the responsible group of people. In traditional solutions the paradigm was in such situation to transmit alarms via SMS, Pager, or Email, or a Voice call, but this process was not closed, securing at the end that somebody will act and confirms his responsibility. In most cases there was only text messaging or Voice messaging available, not the use of all multimedia communication capabilities which are available today in a given customer premise through state of the art converged PBXs, Call servers and other modern IT applications and state of the communication infrastructure.


4.1.1 OVERVIEW

4.2 SYSTEM ARCHITECTURE OF APPLICATION AND VALIDATION ENVIRONMENT

MX ONE TS

Alarm devices

SIP

Message Link

XML HTTP


5 INSTALLATION AND CONFIGURATION

5.1 PRE-CONDITIONS

The application is installed on the following operating systems:

APPLICATION OPERATING SYSTEM REMARKS

Server application OS: Windows 7 Embedded SP: 7

Client application OS: MobiCall SP: 7.8.1

5.2 INSTALLATION OF THE APPLICATION

ACTIVITY FOR SERVER APPLICATION RESULT 1 REMARKS

Installation

on separate Server PC

embedded (Mitel 400 CPU-2) 2

5.3 CONFIGURATION OF THE SWITCH

MX-ONE's basic setup followed standard installation routines for TS5.0 SP5 HF2, for the Germany market.

No special SW patches were applied.

The configuration of the DECT-subsystem and SMS-interface followed instructions given in MX-ONE's CPI, Operational Directions of Cordless Extension, short CX, Generic Extensions, short GE and Short Message Service. Specifically the DECT extensions were SMS-enabled (check extension profile). SMS server and client were configured and tested using the TCP ports 1814 and 1815 (default).

Configuration of the SIP route (between MobiCall and MX-ONE) is printed in Annex A. It was configured to force media streams via the gateway, i.e. no direct media between MobiCall and SIP users was allowed. It was not tested with direct media allowed.

The SIP-DECT system was configured with a basic setup, in particular there users were not SMS enabled, because SMS to SIP-DECT was not a part of the test.

No special preparations of the DT423 DECT portable part were needed to support the tested functionality (no specific virtual SIM parameters, no device setup via user menu etc.). The devices were ready to complete the tests when they were ready to do basic call between them.

No special preparations of the SIP 67xxi/68xxi desk phones were needed to support the tested functionality (no specific configuration file parameters, no device setup via administrator menu etc.). The devices were ready to complete the tests when they were ready to do basic call between them.

5.4 CONFIGURATION OF THE APPLICATION

ACTIVITY RESULT REMARKS

1 Use one of the following status codes: OK, Fail, NE (not executed), NA (not applicable), NS (not supported) 2 If the embedded Mitel 400 CPU2-S is used for installing the Server Application, please add a remark if it’s a new

installation from scratch or if it’s a delta installation using the pre-installed Applications


6 TEST EXECUTION

6.1 ALARMING FUNCTIONALITY

6.1.1 PRE-CONDITIONS

The Alarming system is connected to the PBX/OIP as follows.

System Interface Remarks

PBX TCP/IP

V.24

V.24 over PA

SMS MX-ONE to MobiCall: TCP 1815

SMS MobiCall to MX-ONE: TCP 1814

SIP used UDP 5060 (UAS) on both sides.

Alarm protocol SNMP

Text message (eSMS)

Alarm readout (ATAS)

Message Link

XML

The term eSMS designates the Integrated DECT SMS feature of the MX-ONE TS.

The term Message Link designates a simple SIP trunk interface between MX-ONE TS and MobiCall.

6.1.2 SIP TRUNK

Activity Result Remarks

#1 Outgoing call from MobiCall

to IP Dect

OK OK --- CLI always displayed

OK --- Correct announcement

OK --- Correct call behavior

630d received a text message of 100 characters in “From-URI” name field. While alerting and after answer the device displayed the first 18 characters of the message. The “call list” stored the complete message.

The device showed the correct calling number beside the received text message for all test cases.

Audio messages were received clearly.


to IP Desk Phone




Both 67xxi and 68xxi received a text message of 100 characters in “From-URI” name field. While alerting and after answer the devices displayed the first 18 characters of the message. The “call list” stored the complete message.

The device showed the correct calling number beside the received text message for all test cases.




#2a Outgoing call from MobiCall

to Integrated DECT




DT423 received text messages of 100 characters in “From-URI” name field of the MobiCall SIP INVITE towards MX-ONE. While alerting and after answer the devices displayed the first 12 characters of the message. It is not possible to read more than 12 characters from the “call list”.

While ringing the device showed the correct calling number beside the received text message.

After answer the text message disappears from the display and only the calling number information remains.



to IP Dect requesting DTMF

“press 3 to confirm alarm”

“3” is pressed on Phone

OK OK --- DTMF “3” if recognized by MobiCall

OK --- Phone Status “Dialling” followed by “Answered” followed by “Confirmed” shown in Alarm viewer

630d could send DTMF after the announcement ended or during ongoing announcements. MobiCall responded correctly in either test case.


to IP Desk requesting DTMF

“press 3 to confirm alarm”

“3” is pressed on Phone

OK OK --- DTMF “3” if recognized by MobiCall

OK --- Phone Status “Dialling” followed by “Answered” followed by “Confirmed” shown in Alarm viewer

67xxi and 68xxi could send DTMF after the announcement ended or during ongoing announcements. MobiCall responded correctly in either case.

#5 Call Status Test:

Phone is called and answered.

OK OK --- Phone Status “Dialling” followed by “Answered” shown in alarm viewer

#6 Call Status Test:

Phone is called, call is rejected

OK OK --- Phone Status “Dialling” followed by “No Answer” shown in alarm viewer

This was tested with a 67xxi, 68xxi and Integrated DECT phone DT423.

#7 Alarm to different phones types OK OK --- Phones ring simultaneously

OK --- Announcement provided correctly

OK --- 4 Phones called

Tested with 1 x 67xxi, 1 x 68xxi, 2 x DT423

#8 Incoming call to MobiCall from internal user IP Dect

OK OK --- Receive correct CLI from PBX


630d called MobiCall alarm service. Caller could listen to voice prompts and trigger an alarm action by sending DTMF digits. The caller was correctly identified by MobiCall and the caller's ID was correctly reproduced in following alarm calls/messages to other devices.



#8a Incoming call to MobiCall from external user



Public external user called MobiCall alarm service. Caller could listen to voice prompts and trigger an alarm action by sending DTMF digits. The caller was correctly identified by MobiCall and the caller's ID was correctly reproduced in following alarm calls/messages to other devices.

#9 Incoming call to MobiCall from internal user IP Desk Phone



68xxi called MobiCall alarm service. Caller could listen to voice prompts and trigger an alarm action by sending DTMF digits. The caller was correctly identified by MobiCall and the caller's ID was correctly reproduced in following alarm calls/messages to other devices.

#10 Incoming call to MobiCall from internal user with voice recording and replay


OK --- Correct call behavior. DTMF is recognized

68xxi called alarm service. Caller could listen to voice prompts and successfully record a message. Control of message recording by DTMF was tested ending the recording by sending DTMF “#”. The message was replayed completely and clearly during following alarm calls to other users.

#10a Incoming call to MobiCall from internal user with voice recording and replay



SIP-DECT 630d called alarm service. Caller could listen to voice prompts and successfully record a message. Message recording ended at timer expiry. The message was replayed completely and clearly during following alarm calls to other users.

#10b Incoming call to MobiCall from internal user with voice recording and replay

OK OK --- Receive correct CLI from PBX.


Integrated DECT DT423 called alarm service. Caller could listen to voice prompts and successfully record a message. Control of message recording by DTMF was tested ending the recording by sending DTMF “#”. The alarm message was confirmed by sending DTMF “3”. The message was later replayed completely and clearly during alarm calls to other users.

#11 Incoming call to MobiCall from internal user with DTMF recognition



#12 DTMF tones for both incoming and outgoing call.

OK OK --- DTMF digits are recognized by application

OK --- Alarm is triggered after recognizing the DTMF Digit “3”, as expected

#13 Voice connection outgoing from MobiCall (prompts)

OK OK --- Connection established

OK --- Message recorded



#14 MobiCall initiates a conference after dialing an access number

OK OK --- Incoming call launched

OK --- Alarm conference initiated

OK --- Correct call behavior, incl. DTMF

The caller initiated the conference by sending DTMF-“3” when prompted.

There were 4 conference (audio) resources available. If the group was larger than 4 participants surplus members were later added to the conference when participants left the conference and resources became available.

#15 Correct MobiCall interpretation of BUSY if MobiCall calls a busy extension

OK OK --- If called extension is busy, alarm database shows “busy” as call status

When the called user was busy or rejected the call (tested with a DT423 CXN) a next member on the list was invited to join the conference.

When the called device was a 67xxi/68xxi busy on line 1 then the conference call was offered on line 2 (camp-on).

#16 Application start-up OK OK --- After reboot of the Alarmserver, the Alarm management still works.

Application server was disconnected from the network and then rebooted. During reboot the network was re-connected and cases #14, #15 were redone successfully.

#17 PBX reset OK Ok --- After the reboot of the PBX, the Alarm management still works.

ASU (MX-ONE CPU) was disconnected from the network and then rebooted. During reboot the network was re-connected and cases #14, #15 were redone successfully.

#18a Lost LAN connection between PBX and external application

< 30 sec.

Between 30 and 60 sec.

> 60 sec.

OK OK --- After the reconnection of the local network, the Alarm management still works

ASU (MX-ONE CPU) was disconnected from the network for 15 seconds. Then a new alarm was triggered. The called party could listen to a recorded announcement and acknowledged the received notification by sending DTMF digits.

#18b Lost LAN connection between PBX and external application

< 30 sec.


> 60 sec.

OK OK --- After the reconnection of the local network, the Alarm management still works

ASU (MX-ONE CPU) was disconnected from network for 45 seconds. Then a new alarm was triggered. The called party could listen to a recorded announcement and acknowledged the received notification by sending DTMF digits.



#18c Lost LAN connection between PBX and external application

< 30 sec.


> 60 sec.

OK OK --- After the reconnection of the local network, Alarm management still works

ASU (MX-ONE CPU) was disconnected from the network for 75 seconds. Then a new alarm was triggered. The called party could listen to a recorded announcement and acknowledged the received notification by sending DTMF digits.

Disconnecting a MX-ONE TS from the network for a longer time, may cause a loss of the logical link between the TS and its MGWs. As a consequence MGWs may restart after link recovery which in turn may delay new alarm delivery to Integrated DECT terminals for around 1 minute.

6.1.3 ESMS


#30 Sending text message (160 characters) OK MobiCall sent an SMS of 160 characters to Integrated DECT device DT423.

The device received 140 characters of the message.

#31 Confirmation OK MobiCall sent an SMS to Integrated DECT device DT423 and requested a confirmation.

The device received the message. Reading of the message has been confirmed by pressing soft-key “accept” on the device. MobiCall received the confirmation.

#32 Ringtone 0 OK MobiCall sent an SMS to Integrated DECT device DT423 requesting ringtone 0.

Ringtone “0” is “silence”.

No audible indication.

Vibration alarm, when activated, indicated new message.


Ringtone “1” corresponds to the tone selection under “Message Alert” in the local settings of the phones (Sounds & Alerts).

#34 Ringtone 2 N/A MX-ONE Integrated DECT DT423 distinguish tones “0” (silence), “1” (normal tone) and “7” (alarm tone). Tone selections “1” to “6” all map to the same “normal tone” as chosen in the local settings of the phones.








Device alerted the user with a loud and aggressive alarm sound, clearly distinguishable from other indications.

#40 Flash N/A No available on DT423.

#41 Special characters in Message äöüéèà ÄÖÜÉÈÀ

OK MobiCall sent a message to DT423 including the characters "äöüßÄÖÜáèÉâ".

All characters were displayed correctly with exception of the “â” which resulted in a “white space”.

#42 Erase after timeout OK MobiCall deletes SMS orders when the called user does not receive, confirm or reject the message within a given period.

#43a Alarm triggering from device OK DT423 triggered manual user alarm by long keypress.

MobiCall received an alarm message indicating alarm type “1”.

#43b Alarm triggering from device OK DT423 triggered manual user alarm by double keypress.


#43c Alarm triggering from device OK DT423 triggered “man-down” alarm.


#43d Alarm triggering from device OK DT423 triggered “no-movement” alarm.


#44 Supervision with empty message as “silent”

OK MobiCall actively monitored a DT423 device.

The monitored device did not indicate this to the user (no audible notification).

The battery was removed from the device.

MobiCall detected the outage.

#45 Application start-up OK Application server was disconnected from network and then rebooted. During reboot the network was re-connected.

After the reboot SMS were successfully delivered to devices.

During the application reboot MX-ONE reported alarm 358 = SMS, Faulty communication channel; "No SMSC's Alive". After the reboot the alarm severity changed to ”0” (cleared).

#46 PBX reset OK ASU (MX-ONE CPU) was disconnected from network and then rebooted. During reboot the network was re-connected.




#47a Lost LAN connection between PBX and external application

< 30 sec.


> 60 sec.

OK ASU (MX-ONE CPU) was disconnected from network for 15 seconds.

Thereafter a SMS was successfully delivered to a DT423.

#47b

Lost LAN connection between PBX and external application

< 30 sec.


> 60 sec.



#47c Lost LAN connection between PBX and external application

< 30 sec.


> 60 sec.



Disconnecting a MX-ONE TS from the network for a long time may cause a loss of the logical link between the TS and its MGWs. As a consequence MGWs may restart after link recovery which in turn may delay new SMS delivery from/to Integrated DECT terminals for around 1 minute.

#48 Heartbeat (HB) OK MobiCall actively monitored a DT423 device.

The battery was removed from the device.

MobiCall detected the outage after two consecutive unsuccessful “heartbeats” (silent SMS).

Time between heartbeats is configurable.

This triggered an alarm.


6.1.4 XML


#30 Sending text message (160 characters) OK MobiCall sent an SMS of 160 characters to IP Desk Phone 6739i.

The device received 140 characters of the message.

#32 Ringtone 0 OK MobiCall sent an SMS to IP Desk Phone 6739i requesting ringtone 0.

Ringtone “0” is “silence”.

No audible indication.

Vibration alarm, when activated, indicated new message.

#45 Application start-up OK Application server was disconnected from network and then rebooted. During reboot the network was re-connected.


During the application reboot MX-ONE reported alarm 358 = SMS, Faulty communication channel; "No SMSC's Alive". After the reboot the alarm severity changed to ”0” (cleared).

#46 PBX reset OK ASU (MX-ONE CPU) was disconnected from network and then rebooted. During reboot the network was re-connected.



6.1.5 SCREENSHOT OF SEVERAL TEST CASES

Outgoing call from MobiCall to IP Desk Phone 6739i with text message

Outgoing call from MobiCall to IP Desk Phone 6739i and answered with text message


Outgoing call from MobiCall to IP Desk Phone Mitel 6865i with text message

Outgoing call from MobiCall to IP Desk Phone Mitel 6865i and answered with text message


Outgoing call from MobiCall to IP Dect Mitel 630d with text message

Outgoing call from MobiCall to IP Dect Mitel 630d and answered with text message


Outgoing call from MobiCall to IP Dect Mitel DT423 with text message

Outgoing call from MobiCall to IP Dect Mitel DT423 and answered


Alarm to different phones types IP Desk Phone 6739i

Alarm to different phones types IP Desk Phone Mitel 6865i


Alarm to different phones types IP Dect Mitel DT423

Alarm to different phones types IP Dect Mitel 630d


Sending text message (160 characters) to IP Dect Mitel DT423

Sending text message across XML (160 characters) to IP Desk Phone 6739i


7 ANNEX A: INSTALLATION & CONFIGURATION

7.1 DETAILS ON INSTALLATION OF THE APPLICATION

7.2 DETAILS ON CONFIGURATION OF THE SWITCH

Configuration details of the SIP trunk between MX-ONE TS 5.0 and MobiCall follow.

Note: Parameters may depend on market selection (TRM) and numbering scheme (RODDI). The setup is to be seen as an example. Adjust this according to individual requirements.

The given example shows a simple SIP trunk hosted on TS LIM 1. Selection code is digit “5”. All digits following are sent in Request- and To-URI (e.g. dialing “5123” triggers INVITE to sip:123@{MobiCalls-IP}:5060).

ROCAI:ROU=95,SEL=0110000000000010,SIG=0111111000A0,TRAF=00151515,TRM=4,SERV=3100000001,BCAP=001100;

RODAI:ROU=95,TYPE=TL66,VARI=00000000,VARO=00000950,VARC=00001000,FILTER=NO;

RODDI:DEST=5,ROU=95,ADC=0505100000000250000001010000,TRC=0,SRT=2,NUMACK=0;

ROEQI:ROU=95,TRU=1-1,INDDAT=000000000000;

sip_route -set -route 95 -uristring0 "sip:?@{MobiCalls-IP}" -accept REMOTE_IP -match {MobiCalls-IP} -profile Default


7.3 DETAILS ON CONFIGURATION OF THE APPLICATION

7.3.1 MAIN CONFGURATION OF MOBICALL


7.3.2 VOIP SETTINGS


7.3.3 NVT.INI SIP SETTINGS

;------------------------------------------ SIP settings

[SIP]

;Activate SIP protocol for nvtvoip application

Enabled=1

;SIP default domain IP address

DefaultDomain=10.16.100.31

;Local interface in format: <prot type>$<local IP>:<port> (exmpl: udp$192.168.0.3:5060)

Interface=udp$10.16.100.36:5060

;Optional IP address or DNS name of SIP proxy server

Proxy=

;SIP Registrar address (DNS or IP) and username / password

Registrar=

UserName=

Password=

RegisterExpire=3600

;Optional list of IP addresses from alternative domains, separated by commas. no spaces allowed

AlternateDomains=

;Payload type for RFC2833 (DTMF tones)

RFC2833_PayloadType=101

AssertedIdentityMode=0

;Allow reinvite for media change. If ringing but connection terminated after connect, set to 1.

AllowMediaChange=1

;Call presentation mode

CallPresentationMode=1

EnableSIPQ=0

ReuseTCPTransport=0


7.3.4 ALARM CONFIGURATION


8 ANNEX B: SUPPORT AND ESCALATION PROCESSES

8.1 PRE-CONDITIONS

The following general rules are applicable for analyzing and solving customer problems with solutions provided by Mitel equipment in combination with 3rd party equipment:

Only qualified and certified solutions are officially supported by Mitel.

Qualifications and Certifications are based on test results documented within a “Certificate of Function”. This document describes

o main functionality of Partner Company’s product,

o interfaces used for integration,

o details of all involved components (including PCs and operating systems),

o installation and configuration of Partner Company’s product and the configuration of Mitel’s equipment - as far as this is necessary for the interoperability,

o test use cases, which have been executed

o and test results.

The Certificate of Function is published on the A2P2 Extranet together with the certification or qualification diploma.

8.2 QUALIFIED PRODUCTS BEING SOLD BY PARTNER COMPANY

8.2.1 SUPPORT RESPONSIBILITIES

Mitel provides full support for the Mitel IP-PBX, but does not take any support responsibilities for Partner Company’s Product.

1st level support is provided by an Mitel partner (Reseller)

2nd level support is the responsibility of Mitel Country Sales Unit (CSU)

Partner Company provides full support for Partner Company’s Product.

8.2.2 SUPPORT PROCESS

If a problem occurs at a Customer site where Mitel’s IP-PBX systems are used in combination with Partner Company’s Product, and if this problem cannot clearly be assigned to Mitel’s IP-PBX, the Reseller shall open a Support Case at Partner Company.

If the problem cannot be solved within Partner Company’s support, the Reseller must open a support case at Mitel’s 2nd level support. In order to opening a Support Case, Partner Company must

First upgrade all hw,fw and sw to latest supported version.


deliver a detailed description of the problem, including the exact time when it occurred and how to

reproduce it.

specify all components involved;Both hw and fw.

provide all available log file information showing the reported problem and containing a reasonable time

period before (and up to) the time when the problem occurred;

Comply with the support case opening/handling process applicable within the relevant Mitel Country

Sales Unit. Upon receiving all requisite information from Partner Company, Mitel’s 2nd level Support will, jointly accompanied by Partner Company as agreed on within the qualification contract, provide analysis and technical support with respect to the identified problem, but Mitel does not take any commitment on providing a solution fixing problems to end-customers.

Mitel 2nd level Support reserves the right to close the case, if the investigations made are insufficient, don’t clearly show that the problem can be assigned to Mitel’s equipment, don’t contain all relevant data or do not exist.


9 ANNEX C: GENERAL RULES TO USE THIS TEMPLATE

The idea is to provide a check list helping you designing your validation scenarios without forgetting topics, which might be important for your product.

All texts in “arial italic blue” provide hints on how to deal with this template and which contents to be entered in certain areas. Before setting the final document to valid all of these italic blue texts should be deleted.

Please don’t delete contents within chapter 1 – 5 and 7 – 8, just mark parts as NA (not applicable) in case they are not important for your tests.

Chapter 6 contains sub-chapters on different functionality areas (CTI, Attendant, ACD…) and usually only a few (or even only one) of these sub-chapters are needed for validating your product. All other sub-chapters shall be deleted before setting the final document to valid, but please don’t delete test cases within the sub-chapters you decided to keep - and use “NA” (Not Applicable) to indicate that certain use cases are not useful for you.

Validation scenarios within Chapter 6 partly just list the use cases which may have to be executed; partly the tables also offer an area to enter pre-requisites and to already describe expected results. Please use the format of tables with pre-requisites whenever this appears to be useful to help understanding the use cases and reproducing them.

This template shall “live and grow” collecting your most valuable experience when using it and we therefore very much appreciate your feedback on anything which helps us improving this template. Please send your remarks, comments, hints… to [email protected] helping us to improve this document.

Please use the same email address to ask for our latest version of this document when starting new test activities to also benefit from the improvements having been inserted by other people.

Thank you for your support.

Best Regards

Bernd Jobes

+41 32 655 3818

[email protected]

mailto:[email protected]

mailto:[email protected]

for Mitel MiVoice MX-ONE TS - New Voice International...CoF for MobiCall and MX-ONE 5.0 10 6 TEST...

Documents

Transcript of for Mitel MiVoice MX-ONE TS - New Voice International...CoF for MobiCall and MX-ONE 5.0 10 6 TEST...