Partner: Khomp Application type: Media Gateway KMG series · The KMG 400 MS MS is a low density...

ALE Application Partner Program – Inter-working report - Edition 1 - page 1/40

Copyright © ALE International 2018

ALE Application Partner Program Inter-Working Report

Partner: Khomp Application type: Media Gateway Application name: KMG series

Alcatel-Lucent Enterprise Platform: OmniPCX Enterprise™

The product and release listed have been tested with the Alcatel-Lucent Enterprise Communication Platform and the release specified hereinafter. The tests concern only the inter-working between the AAPP member’s product and the Alcatel-Lucent Enterprise Communication Platform. The inter-working report is valid until the AAPP member’s product issues a new major release of such product (incorporating new features or functionality), or until ALE issues a new major release of such Alcatel-Lucent Enterprise product (incorporating new features or functionalities), whichever first occurs. ALE MAKES NO REPRESENTATIONS, WARRANTIES OR CONDITIONS WITH RESPECT TO THE APPLICATION PARTNER PRODUCT. WITHOUT LIMITING THE GENERALITY OF THE FOREGOING, ALE HEREBY EXPRESSLY DISCLAIMS ANY AND ALL REPRESENTATIONS, WARRANTIES OR CONDITIONS OF ANY NATURE WHATSOEVER AS TO THE AAPP MEMBER’S PRODUCT INCLUDING WITHOUT LIMITATION THE IMPLIED WARRANTIES OF MERCHANTABILITY, NON INFRINGEMENT OR FITNESS FOR A PARTICULAR PURPOSE AND ALE FURTHER SHALL HAVE NO LIABILITY TO AAPP MEMBER OR ANY OTHER PARTY ARISING FROM OR RELATED IN ANY MANNER TO THIS CERTIFICATE.

The Alcatel-Lucent name and logo are trademarks of Nokia used under license by ALE. To view other trademarks used by

affiliated companies of ALE Holding, visit: www.al-enterprise.com/en/legal/trademarks-copyright. All other trademarks are the

property of their respective owners. The information presented is subject to change without notice. Neither ALE Holding nor

any of its affiliates assumes any responsibility for inaccuracies contained herein. © 2018 ALE International. All rights reserved.



Certification overview

Date of the certification August 2018

ALE International representative AAPP

AAPP member representative Roberta Lingnau de Oliveira

Alcatel-Lucent Enterprise Communication Platform

OmniPCX Enterprise

Alcatel-Lucent Enterprise Communication Platform release

R12.2 (M3 402 15)

AAPP member application release KMG series 4.1.42.0.update02

Application Category Gateway

Author(s): Karthik Padmarajan Reviewer(s): Rachid Himmi, Thierry Chevert Revision History Edition 1: creation of the document – August 2018

Test results

Passed

Refused Postponed

Passed with restrictions

Refer to the section 6 for a summary of the test results.

IWR validity extension The tests where done with KMG 400 device but it should be same for all the KMG series devices.



AAPP Member Contact Information

Contact name: Roberta Lingnau de Oliveira

Title: Partnership Program Manager

Address: Rua Joe Collaço, 253

Zip Code: 88037-010

City: Florianopolis

Country: Brazil

Phone: 55 48 3722 2900 Fax:

Mobile Phone: 55 48 9 99509500

Web site: www.khomp.com

Email address: [email protected]

http://www.khomp.com/

mailto:[email protected]



TABLE OF CONTENTS

1 INTRODUCTION ...................................................................................................................................... 5

2 VALIDITY OF THE INTERWORKING REPORT ............................................................................. 6

3 LIMITS OF THE TECHNICAL SUPPORT ......................................................................................... 7

3.1 CASE OF ADDITIONAL THIRD PARTY APPLICATIONS ............................................................................. 7

4 APPLICATION INFORMATION .......................................................................................................... 8

5 TEST ENVIRONMENT ............................................................................................................................ 9

5.1 HARDWARE CONFIGURATION .............................................................................................................. 9 5.2 SOFTWARE CONFIGURATION .............................................................................................................. 10

6 SUMMARY OF TEST RESULTS ........................................................................................................ 11

6.1 SUMMARY OF MAIN FUNCTIONS SUPPORTED ...................................................................................... 11 6.2 SUMMARY OF PROBLEMS ................................................................................................................... 11 6.3 SUMMARY OF LIMITATIONS ............................................................................................................... 12 6.4 NOTES, REMARKS .............................................................................................................................. 12

7 TEST RESULT TEMPLATE ................................................................................................................. 13

8 TEST RESULTS .................................................................................................................................... 14

8.1 IP LINK BETWEEN HEADQUARTERS AND REMOTE OFFICE LOSS / RECOVER ......................................... 14 8.1.1 Test Objectives .......................................................................................................................... 14 8.1.2 Test Results ............................................................................................................................... 14

8.2 KHOMP GATEWAY USED AS ANALOG / SIP GATEWAY (NORMAL CASE) ...................................... 15 8.2.1 SIP equipment initialization, SIP registration and authentication ........................................... 15 8.2.2 Audio codec negotiation............................................................................................................ 16 8.2.3 Defense ...................................................................................................................................... 17 8.2.4 Basic calls ................................................................................................................................. 18 8.2.5 Telephonic features ................................................................................................................... 20 8.2.6 Voice Mail ................................................................................................................................. 23

8.3 KHOMP USED AS SIP PROXY (IN CASE OF IP NETWORK FAILURE) ...................................................... 24

9 APPENDIX A : AAPP MEMBER’S APPLICATION DESCRIPTION ............................................ 25

10 APPENDIX B: CONFIGURATION REQUIREMENTS OF THE AAPP MEMBER’S

APPLICATION .............................................................................................................................................. 26

11 APPENDIX C: ALCATEL-LUCENT ENTERPRISE COMMUNICATION PLATFORM:

CONFIGURATION REQUIREMENTS ...................................................................................................... 30

SECTION 1: TOPOLOGY AND CALL FLOW ....................................................................................................... 30 SECTION 2: CONFIGURATIONS DONE AT 8770 END ......................................................................................... 31

12 APPENDIX D: AAPP MEMBER’S ESCALATION PROCESS .................................................... 34

13 APPENDIX E: AAPP PROGRAM ................................................................................................... 35

13.1 ALCATEL-LUCENT APPLICATION PARTNER PROGRAM (AAPP)......................................................... 35 13.2 ENTERPRISE.ALCATEL-LUCENT.COM ................................................................................................ 36

14 APPENDIX F: AAPP ESCALATION PROCESS ........................................................................... 37

14.1 INTRODUCTION .................................................................................................................................. 37 14.2 ESCALATION IN CASE OF A VALID INTER-WORKING REPORT ............................................................. 38 14.3 ESCALATION IN ALL OTHER CASES ..................................................................................................... 39 14.4 TECHNICAL SUPPORT ACCESS ............................................................................................................ 40



1 Introduction This document is the result of the certification tests performed between the AAPP member’s application and Alcatel-Lucent Enterprise’s platform. It certifies proper inter-working with the AAPP member’s application. Information contained in this document is believed to be accurate and reliable at the time of printing. However, due to ongoing product improvements and revisions, ALE International cannot guarantee accuracy of printed material after the date of certification nor can it accept responsibility for errors or omissions. Updates to this document can be viewed on:

- the Technical Support page of the Enterprise Business Portal (https://businessportal.alcatel-lucent.com) in the Application Partner Interworking Reports corner (restricted to Business Partners)

- the Application Partner portal (https://www.al-enterprise.com/en/partners/aapp) with free access.

https://businessportal.alcatel-lucent.com/

https://www.al-enterprise.com/en/partners/aapp



2 Validity of the Interworking Report This Interworking report specifies the products and releases which have been certified. This inter-working report is valid unless specified until the AAPP member issues a new major release of such product (incorporating new features or functionalities), or until ALE International issues a new major release of such Alcatel-Lucent Enterprise product (incorporating new features or functionalities), whichever first occurs. A new release is identified as following:

a “Major Release” is any x. enumerated release. Example Product 1.0 is a major product release.

a “Minor Release” is any x.y enumerated release. Example Product 1.1 is a minor product release

The validity of the InterWorking report can be extended to upper major releases, if for example the interface didn’t evolve, or to other products of the same family range. Please refer to the “IWR validity extension” chapter at the beginning of the report.

Note 1: The InterWorking report becomes automatically obsolete when the mentioned product releases are end of life.

Note 2: The renewal of the interoperability test (certification) is under the responsibility of the partner except if the certification fee is included in the program fee (e.g. “Application Partner” membership level) in this case ALE will schedule a new certification every two year



3 Limits of the Technical support

For certified AAPP applications, Technical support will be provided within the scope of the features which have been certified in the InterWorking report. The scope is defined by the InterWorking report via the tests cases which have been performed, the conditions and the perimeter of the testing and identified limitations. All those details are documented in the IWR. The Business Partner must verify an InterWorking Report (see above “Validity of the InterWorking Report) is valid and that the deployment follows all recommendations and prerequisites described in the InterWorking Report.

The certification does not verify the functional achievement of the AAPP member’s application as well as it does not cover load capacity checks, race conditions and generally speaking any real customer's site conditions.

Any possible issue will require first to be addressed and analyzed by the AAPP member before being escalated to ALE International. Access to technical support by the Business Partner requires a valid ALE maintenance contract For details on all cases (3

rd party application certified or not, request outside the scope of this IWR,

etc.), please refer to Appendix F “AAPP Escalation Process”.

3.1 Case of additional Third party applications

In case at a customer site an additional third party application NOT provided by ALE International is included in the solution between the certified Alcatel-Lucent Enterprise and AAPP member products such as a Session Border Controller or a firewall for example, ALE International will consider that situation as to that where no IWR exists. ALE International will handle this situation accordingly (for more details, please refer to Appendix F “AAPP Escalation Process”).



4 Application information Application commercial name: Telephone Adapter / VoIP Gateway Application version: Khomp KMG 400 MS (Series) Interface type: SIP/Ethernet

Brief application description:

The KMG 400 MS MS is a low density E1/T1 media gateway developed for applications in the corporate market, for use by carriers and service providers seeking to integrate TDM and NGN networks or small-scale call centers, combining efficiency and high availability.

Its modular architecture allows for 1 or 2 E1 links inside the cabinet and it has an option for up to 2 additional external telephony modules for E1/T1, GSM 2G or 3G, FXO and/or FXS calls, with a maximum of 60 simultaneous calls.

Ideal for small call centers and VoIP carriers needing a low cost, easy-to-implement upgrade.

WEB INTERFACE for easy configuration, monitoring and diagnostics;

ROUTING SCRIPT for routing functions automation;

RTP BRIDGE to allow for a larger number of simultaneous SIP calls;

DATA ENCRYPTION to protect the VoIP network.



5 Test environment Figure 1 Test environment

5.1 Hardware configuration

List main hardware equipments used for testing

OmniPCX Entreprise: o CS (Virtual ESXI server 6.0) Spatial setup o GD (Gateway driver processing Unit o PRA T2 (ISDN Access) o MIX 2/4/4 (ISDN T0, digital & analog interfaces) o UA digital and analog sets o IP touch 80x8 sets



We have given the IP address information to understand the configuration of gateway.

Headquarters: (Main Office)

OmniPCX Enterprise (common hardware) with two CPU in spatial redundancy

o IP address: 10.9.224.238 (first CPU role address) and 10.9.223.238 (second CPU role address)

o SIP Domain name: r12.prosertesting.com o Attendant: Directory Number 0 o 4645 Voice mail: Directory Number 31300, hosted on first OXE CPU o IPTouch phone: Directory Number 1001 to 1010 o OXE - PSTN (ISDN T0 access): +91-44-45105971, Prefix: 78 o IP domain 6: IP address range 10.9.223.50 to 10.9.223.200

Remote office:

Khomp gateway

o IP address: 10.9.223.135 o SIP phones: Directory Numbers 1008 to 1011 o Emergency number 911

o TCP/IP

5.2 Software configuration

Alcatel-Lucent Enterprise Communication Platform: OmniPCX Enterprise R12.2 (M3.402.15 )

Partner Application : KMG 400 MS 4.1.42.0.update02



6 Summary of test results

6.1 Summary of main functions supported

Features Status Comments

8.1 IP link between headquarters and remote office loss / recover

OK

8.2 Khomp used as SIP Proxy ( Normal Mode)

8.2.1 SIP registration and authentication OK

8.2.2 Audio codec negotiation OK

8.2.3 Defense (call server switch over and reboot) OK

8.2.4 Basic calls OK

8.2.5 Telephonic features

Forward OK

Hold and broker call OK

Transfer OK

Conference OK Conference initiated from the IPTOUCH end.

Voice mail OK

8.3 Khomp used as SIP Proxy ( OXE connection is disconnected )

8.2.1 SIP registration and authentication OK

8.2.2 Audio codec negotiation OK

8.3.3 Basic calls OK

6.2 Summary of problems

None



6.3 Summary of limitations

In case spatial setup the SIP account register to the new main server only after few minutes. During that brief period calls from the SIP extension and IP touch will not work.

During survivability scenario when the link between OXE and Khomp gateway is disconnected, the registration page in Khomp takes few minutes to get updated.

Message waiting indication is not supported by the Khomp devices. This parameter to be implemented in future release of Khomp Firmware

The Khomp extensions will show registered but calls to local phones alone will work and calls to IP touch will work only after OXE is up.

6.4 Notes, remarks

For the purpose of survivability the local SIP communication port to be different from the one of OXE sip port. In our scenario we have declared it as 5059 for Khomp survivability and 5060 default for OXE.

We had issue with outgoing call from the Khomp extension in the initial firmware. Khomp device could not detect the IP address change in SDP of call flow. In the current firmware the issue is fixed and working fine.

FXS port is RJ 45 the connection cable has to be modified according to the color coding specified in the user manual of the document

Only the KMG 400 hardware has been tested. Behavior should be the same with all the KMG gateway family having similar interfaces and SIP versions.

When using OXE prefix to set a forward, only tones are heard during DTMF sent.

Even if some telephonic features may be activated using Khomp phone local possibilities (forward, do not disturb), it is mandatory to use the OmniPCX Enterprise features (prefix and suffix).

The sip gateway as T0/T1 access cards but we did not test them.

The analog phones connected behind the Khomp media gateway are registered as SIP EXTENSION and registered with the IP address of Khomp.

Extensions connected behind the Khomp are referred as SIP phone Z-set or analog extensions throughout out the IWR



7 Test Result Template The results are presented as indicated in the example below:

Test Case

Id Test Case N/A OK NOK Comment

1

Test case 1

Action

Expected result

2

Test case 2

Action

Expected result

The application waits for PBX timer or phone set hangs up

3

Test case 3

Action

Expected result

Relevant only if the CTI interface is a direct CSTA link

4

Test case 4

Action

Expected result

No indication, no error message

… …

Test Case Id: a feature testing may comprise multiple steps depending on its complexity. Each step has to be completed successfully in order to conform to the test. Test Case: describes the test case with the detail of the main steps to be executed the and the expected result N/A: when checked, means the test case is not applicable in the scope of the application OK: when checked, means the test case performs as expected NOK: when checked, means the test case has failed. In that case, describe in the field “Comment” the reason for the failure and the reference number of the issue either on ALE International side or on AAPP member side Comment: to be filled in with any relevant comment. Mandatory in case a test has failed especially the reference number of the issue.



8 Test Results

8.1 IP link between headquarters and remote office loss / recover

8.1.1 Test Objectives

Phone behaviors are checked when the headquarters to remote office IP link goes down and up.

Note: dialing will be based on direct dialing number but also using programming numbers on the SIP phone.

8.1.2 Test Results

Test Case


IP1

IP link is down Check they can receive and make calls from/to

an SIP Phone(located behind the KHOMP GATEWAY),

Check the Analog phone (Ext behind

Khomp) located behind the KHOMP GATEWAY can receive among the extensions.

We can check the registration status in the web GUI of the Khomp device

IP2

IP link is up

Check they can receive and make calls from/to

a headquarters phone, a SIP Phone(located behind the KHOMP GATEWAY).



8.2 KHOMP GATEWAY used as Analog / SIP gateway (Normal case)

This is the normal mode. The IP network is up and used for the calls between the remote office and the headquarters. The KHOMP GATEWAY acts as an SIP gateway.

8.2.1 SIP equipment initialization, SIP registration and authentication

8.2.1.1 Test objectives

These tests check that the equipment’s (SIP phones and fax machines) are able to register to the

OXE with and without SIP authentication. The KHOMP GATEWAY SIP configuration possibilities

are also tested especially for the OXE Call Server redundancy support (alternate proxies, DNS).

Test Case


SP1

Analog phone (Ext behind Khomp) set registration to OXE using alternate proxy The KHOMP GATEWAY is configured to use proxy server’s address. The main and alternate proxy addresses are the OXE CPU address.

Tests are performed when first Call Server is active and then when second Call Server is active.

SIP registration is working fine with the Khomp gateway

SP2

Analog phone (Ext behind Khomp) set registration to OXE using DNS The KHOMP GATEWAY is configured to use a domain name as registrar / proxy server address. The DNS IP addresses are the OXE CPU address. Tests are performed when first Call Server is active and then when second Call Server is active.

SP3

Analog phone (Ext behind Khomp) set registration to OXE using SIP digest authentication SIP digest authentication is activated on OXE and phone side (KHOMP GATEWAY). Check also that outgoing call is authenticated.



8.2.2 Audio codec negotiation


These tests check that the KHOMP GATEWAY is using the configured audio parameters (codec, framing, VAD).

The KHOMP GATEWAY and OXE negotiate the appropriate codec during a basic call between a

UA phone and an Analog phone (Ext behind Khomp) behind the KHOMP GATEWAY. Same test

also between an IP Phone and the SIP phone.

8.2.2.2 Test procedure

Test Case


COD1

The KHOMP GATEWAY is configured to offer G711Alaw, G723 and G729 (in this priority order). The OXE is configured to use G711Alaw. Check that for an incoming and outgoing call, the negotiated codec is G711 Alaw

COD2

The KHOMP GATEWAY is configured to offer G711Alaw, G723 and G729 (in this priority order). The OXE is configured to use G723. Check that for an incoming and outgoing call, the negotiated codec is G723

Not supported. G723 is not in the list of supported codecs of Khomp gateway

COD3

The KHOMP GATEWAY is configured to offer G711Alaw, G723 and G729 (in this priority order). The OXE is configured to use G729. Check that for an incoming and outgoing call, the negotiated codec is G729

COD4

The KHOMP GATEWAY is configured to offer G711Alaw. The OXE is configured to use G711Alaw. Check that for an incoming and outgoing call, the negotiated codec is G711 Alaw

COD5

The KHOMP GATEWAY is configured to offer G723. The OXE is configured to use G723. Check that for an incoming and outgoing call, the negotiated codec is G723.

Not supported. G723 is not in the list of supported codecs.

COD6

The KHOMP GATEWAY is configured to offer G729. The OXE is configured to use G729. Check that for an incoming and outgoing call, the negotiated codec is G729.

COD7 Repeat previous 6 tests by changing Alaw to μlaw

COD8

Codec selection. The KHOMP GATEWAY and OXE do not have any common codec. For example, the KHOMP GATEWAY is configured to offer G723 and the OXE to use only G729 (use of IP domains). Check that for an incoming and outgoing call is properly rejected.

Not supported. G723 is not in the list of supported codecs.



8.2.3 Defense


These tests check the KHOMP GATEWAY defenses against perturbations and OXE Call Servers switch over.


Test Case


DEF1

OXE Call Server CPU switch over while the Analog phones behind the KHOMP GATEWAY are in idle. Check the behavior after a switch from the OXE main to standby CPU. The Analog phone (Ext behind Khomp) must be able to make and receive a call after the switch over.

For registering with the standby server the Khomp gateway takes few minutes after the switch over.

DEF2

OXE Call Server CPU switch over while the Analog phones behind the KHOMP GATEWAY are in conversation with an IPTouch. Check the behavior after a switch from the OXE main to standby CPU. The call is still active. The phone can make and receive a second call and switch from one to another. After on hook, the Analog phone (Ext behind Khomp) must be able to make and receive a call after the switch over.

Active call is not disconnected. After switch over the Khomp gateway takes few minutes to detect the change. Once it re-registers with the standby server, outgoing calls are successful. During the time between switch over and gateway registration with standby server, call between the SIP extensions behind the gateway are successful

DEF3

OXE Call Server reboot while the Analog phones behind the KHOMP GATEWAY are in idle. Check the phone behavior when the OXE Call Server reboots (without standby CPU). As soon as the Call Server is running again, the Analog phone (Ext behind Khomp) is able to make and receive a call.

DEF4

OXE Call Server reboot while the Analog phones behind the KHOMP GATEWAY are in conversation with an IPTouch. Check the behavior when the OXE Call Server reboots (without standby CPU). The call is released. As soon as the Call Server is running again, the Analog phone (Ext behind Khomp) is able to make and receive a call. Check also the behavior when in communication with another SIP set behind the KHOMP GATEWAY (call remains established).

IPtouch 80x8 reboots only after the call is disconnected.



DEF5

After OXE Call Server Switchover try to make new call from the Analog phone (Ext behind Khomp) and check the Analog phone (Ext behind Khomp) is able to make hold the call with IP Touch

8.2.4 Basic calls


These tests check the Analog phone (Ext behind Khomp) located behind the KHOMP GATEWAY behavior during basic incoming and outgoing calls from and to different kind of phone set types (SIP, IPTouch, UA) with different call releases (during ringing, by caller, by callee) and with or without a second incoming call. The descriptions of the following tests are detailed based on the point of view of a user using an Analog phone (Ext behind Khomp) located behind the KHOMP GATEWAY. For example, an outgoing call to an IPTouch means a call made by this Analog phone (Ext behind Khomp) to the IPTouch located in the remote office or headquarters.


Test Case


BA1

Call from and to a SIP phone. The Analog phone (Ext behind Khomp) calls a SIP phone. The Analog phone (Ext behind Khomp) is called by a SIP phone. In both cases, check the display and audio during all steps (dialing, ring back tone, conversation, release).

BA2 Call from and to an IPTouch. Repeat 1 with an IPTouch.

BA3

Call from and to an UA phone. Repeat 1 with an UA phone.

BA4

Call from and to an SIP phone. Repeat 1 with an Analog phone (Ext behind Khomp) located in the headquarters. Repeat 1 with an Analog phone (Ext behind Khomp) located in the remote office behind the KHOMP GATEWAY.

BA5

Incoming call released by the caller during ringing. The caller releases the incoming call to the Analog phone (Ext behind Khomp) before the callee takes the call.

BA6

Outgoing call released by the caller during ringing. The caller releases the outgoing call from the Analog phone (Ext behind Khomp) before the callee takes



the call.

BA7

Incoming call rejected by the callee during ringing. The callee rejects the incoming call to the Analog phone (Ext behind Khomp) during ringing.

BA8

Outgoing call rejected by the callee during ringing. The callee rejects the outgoing call from the Analog phone (Ext behind Khomp) during ringing.

BA9

Call released by the SIP phone. The Analog phone (Ext behind Khomp) releases the call after a conversation period.

BA10

Call released by the other phone. The other phone releases the call after a conversation period.

BA11

Incoming call presentation while already in conversation. The Analog phone (Ext behind Khomp) is already in conversation and receives a new incoming call. Check the display (new call presentation) and audio (new call signalization).

BA12

Call from and to an external number (T0/T2) Call is properly established.

BA13

Call from and to an attendant Call is properly established.

BA14

Incoming external call (T0/T2 for example) to an attendant phone set which transfers the call to the SIP phone. Transfer is done while the Analog phone (Ext behind Khomp) is ringing but also after this one has picked up the call (using the attendant soft key or going on hook). Call is properly established.

BA15

Outgoing call from an Analog phone (Ext behind Khomp) to an attendant with transfers to an external call (T0/T2 for example. Call is properly established.

BA16

Dialing break The Analog phone (Ext behind Khomp) starts dialing another phone number. Before the end, the dialing is stopped. Check that the phone comes back to idle state after the timeout expires.



8.2.5 Telephonic features


These tests check the Analog phone (Ext behind Khomp) (located behind the KHOMP GATEWAY) behavior during OXE telephonic feature use like forward, on hold, transfer, voice mail interactions, conference. Tests are also done using the KHOMP GATEWAY local feature possibilities. For example, setting an immediate forward for calls to the SIP phone.


Test Case


TE1

Immediate forward to another phone. Prefix: 51 The Analog phone (Ext behind Khomp) is forwarded to another phone. Call the Analog phone (Ext behind Khomp) and check that the call is presented on the third phone and can be taken by this one.

TE2

Call to a phone, which is forwarded to another phone. The Analog phone (Ext behind Khomp) calls a phone forwarded to a third phone. The third phone takes the call and the conversation is established.

TE3

Forward on no answer to another phone. Prefix: 53 The Analog phone (Ext behind Khomp) is forwarded on no answer to another phone. Call the Analog phone (Ext behind Khomp) and check that the call is presented on SIP phone. Do not take the call and wait for the call to be presented on the third phone. Take the call on the third phone. Check also the call can be picked up before the call is forwarded.

TE4

Forward on busy to another phone. Prefix: 52 The Analog phone (Ext behind Khomp) is forwarded on busy to another phone. While the Analog phone (Ext behind Khomp) is already in conversation, call the Analog phone (Ext behind Khomp) and check that the call is presented. Do not take the call and wait for the call to be presented on the third phone. Take the call on the third phone.

TE5

Forward on busy / no answer to another phone. Prefix: 54 The Analog phone (Ext behind Khomp) is forwarded on busy / no answer to another phone. While the SIP is already in conversation, call the Analog phone (Ext behind Khomp) and check that the call is presented. Do not take the call and wait for the call to be presented on the third phone. Take the call on the third phone.



Call the Analog phone (Ext behind Khomp) and check that the call is presented on SIP phone. Do not take the call and wait for the call to be presented on the third phone. Take the call on the third phone. Check also the call can be picked up before the call is forwarded.

TE6

Analog phone (Ext behind Khomp) puts call on-hold. The Analog phone (Ext behind Khomp) is in conversation with another phone. This conversation is put on-hold. Check the display and on-hold music on this phone. Check also the display and audio signalization on the SIP phone. Check the conversation can be retrieved.

No Hold tone is played.

TE7

Analog phone (Ext behind Khomp) is put on-hold. The Analog phone (Ext behind Khomp) is in conversation with another phone. The other phone puts this conversation on-hold. Check the display and on-hold music on the SIP phone. Check the conversation can be retrieved.

TE8

Broker call. The Analog phone (Ext behind Khomp) has two active conversations and switches from one to another. Check the display and on-hold music on the phones. Check also the display and audio signalization on the SIP phone.

TE9

Transfer in conversation. The Analog phone (Ext behind Khomp) has two active conversations and transfers the first to the second. Check the new conversation between the two other phones is successful and also the Analog phone (Ext behind Khomp) display (signalization of the transfer and back to idle state).

TE10

Transfer during ringing. The Analog phone (Ext behind Khomp) has one active conversation and another one in ringing step. Before the second callee takes the call, the Analog phone (Ext behind Khomp) transfers its first call to this second callee. Check the new conversation between the two other phones is successful and also the Analog phone (Ext behind Khomp) display (signalization of the transfer and back to idle state).

TE11

Conference. The IPtouch extension has two active conversations initiates a conference (two Khomp extensions) by pressing the DTMF key. Check the new conversation between the three parties is successful (audio and signalization).

TE12

Voice mail message signalization. Call the Analog phone (Ext behind Khomp) and leave a message to its voice mail (for example by forwarding the Analog phone (Ext behind Khomp) to the voice mail). Check that the message is indicated on the Analog phone (Ext behind Khomp) (led, display and/or feedback tone).

Voice signalization is not supported by the Khomp devices



TE13

Voice mail message listening. The Analog phone (Ext behind Khomp) has a voice mail message (see above). Press the voice mail key and interacts with the voice mail to listen to the message.

TE14

Voice mail message deposit. The Analog phone (Ext behind Khomp) calls another phone forwarded to the voice mail. He leaves a message. Check the interaction between the Analog phone (Ext behind Khomp) and voice mail. Listen to the message from the other phone.

TE15

Do Not Disturb. Prefix: 42 On the Analog phone (Ext behind Khomp) the Do not Disturb is activated. When calling this set, the call is not presented on the phone. On the Analog phone (Ext behind Khomp) the Do not Disturb is deactivated. When calling this set, the call is presented on the phone and can be picked up.

TE16

Wake Up. Prefix: 506 (activation) and 507 (deactivation) On the Analog phone (Ext behind Khomp) the Wake Up is activated. When the wake up time arrives, the phone rings. When the picked up, the voice guide is played. Test also with the Analog phone (Ext behind Khomp) already in conversation when the wakeup time arrives. On the Analog phone (Ext behind Khomp) the Wake Up is activated then deactivated. When the previous wake up time arrives, nothing appends on the phone set.

TE17

Leaving an automatic call back. Suffix: 5 The Analog phone (Ext behind Khomp) calls another phone already in conversation. The Analog phone (Ext behind Khomp) set uses the call back suffix to be recalled. Check the call back query is taken into account and processed.

TE18

Called by an automatic call back. Suffix: 5 The Analog phone (Ext behind Khomp) is in conversation. Another phone calls the Analog phone (Ext behind Khomp) and leaves an automatic call back. Check the call back query is taken into account and processed.

TE19

KHOMP GATEWAY local features. Repeat steps 1, 3, 4, 5 and 15 but this time use the KHOMP GATEWAY local features possibilities.



8.2.6 Voice Mail


Voice Mail notification, consultation and password modification must be checked. MWI (Message Waiting Indication) has to be checked. Voice mail service is enabled on SIP sets For these tests, DTMF sending (RFC 2833) has to be validated in order to use Voice Mail menu


Test Case Id

Test Case N/A OK NOK Comment

VO1

Password modification With SIP set 3 call the Voice Mail and follow the Voice guide in order to modify the default password.

When modification is accepted hang-up.

Recall the voice mail and try to log with a wrong password. Check the rejection.

Recall the voice mail and try to log with the right password. Check the service access.

VO2

Message display activation, MWI (1): With SIP set-2 call the Voice Mail. Follow the instructions in order to send a voice message in SIP set -3 boxes.

Check that the MWI on SIP set-3 is activated.

Not supported.

VO3

Message consultation With SIP set -3 call the Voice Mail. Follow the instructions in order to listen your voice message leaved during the previous test. Check that your can listen it and delete.

Check that MWI display is disabled on SIP set-3 after message cancellation.

VO4

SIP call to a OXE user forwarded to Voice Mail Forward the IP Touch IPset-1 to Voice Mail by dialing *61 prefix + <Voice Mail number>.

With SIP set 3 call IPset-1 and check that you are immediately forwarded to Voice Mail. Check that you can leave a message

On IPset-1 disable Voice Mail forwarding with *60 prefix.

VO5

OXE set call to a SIP user forwarded to Voice Mail Forward the SIP set -3 to Voice Mail by dialing *61 prefix + <Voice Mail number>.

With IP Touch IPset-1 call SIP SET-3 and check that you are immediately forwarded to Voice Mail. Check that you can leave a message

On SIP SET-3 disable Voice Mail forwarding with *60 prefix.



8.3 Khomp used as SIP proxy (in case of IP network failure)


There is a failure in the IP network and the Khomp is used as a SIP proxy to handle the calls between analog extensions connected to Khomp gateway


Test Case Id

Test Case N/A OK NOK Comment

NF1

The Khomp is configured to use G711Alaw, G723 and G729 (in this priority order). Check that for a call from the Analog phone (Ext behind Khomp) 1 to the another SIP phone2 is successful Check that for a call from the SIP phone1 to SIP phone, the negotiated codec is G711 Alaw

NF2

The Khomp is configured to use μlaw. Check that for a call from the Analog phone (Ext behind Khomp) 1 to the another SIP phone2 is successful Check that for a call from the Analog phone (Ext behind Khomp) to the IPTouch, the negotiated codec is G711 μlaw

NF3

The Khomp is configured to use G729. Check that for a call from the Analog phone (Ext behind Khomp) 1 to the another SIP phone2 is successful Check that for a call from the SIP phone1 to the Analog phone (Ext behind Khomp) 2 , the negotiated codec is G729



9 Appendix A : AAPP member’s Application description

Low density gateway with up to 60 E1/T1, GSM 2G or 3G, FXO or FXS

Channels, and 60 SIP SBC calls with transcoding.

The KMG 400 MS MS is a low density E1/T1 media gateway developed for applications in the corporate market, for use by carriers and service providers seeking to integrate TDM and NGN networks or small-scale call centers, combining efficiency and high availability.

Its modular architecture allows for 1 or 2 E1 links inside the cabinet and it has an option for up to 2 additional external telephony modules for E1/T1, GSM 2G or 3G, FXO and/or FXS calls, with a maximum of 60 simultaneous calls.

Ideal for small call centers and VoIP carriers needing a low cost, easy-to-implement upgrade.



10 Appendix B: Configuration requirements of the AAPP member’s application

Accessing the Web Interface

KMG has a web interface for configuration, diagnostics, and management of the gateway. Below is

the information regarding the network, user, and default access password. To access the web

interface when the gateway is configured with the factory settings, you need to set up the computer

with the IP address range and subnet mask shown below. You can use any web browser of your

choice.

IP Address: 10.10.10.150

Subnet Mask: 255.0.0.0

User: admin

Password: khomp

Network

For network configurations, access the Settings → System → Network menu.

The displayed table allows for the configuration of each network interface. The scope column

displays options that can limit the network traffic. The options displayed in this field depend on the

features available in your KMG.

The gateway needs to be restarted after you apply changes to the network configuration. You can

restart the gateway using the displayed button or through the Management → Restart gateway

menu.

Configure static IP address

1. In the column "Configuration mode", select the "Static" option;

2. Inform the new IP address and the subnet mask. If there is a network gateway,

inform it as well.

3. Click on the Save button. Finally, click on the Apply button;

4. Restart the gateway;

5. The KMG and the computer used to access it must be on the same network range

so that the web interface can be accessed.

Configure the DHCP server

1. In the "Configuration mode" column, select "Dynamic (DHCP)";


3. Restart the gateway;

4. The KMG and the computer used to access it must be on the same network range

so that the web interface can be accessed.

Add a SIP NAP

To configure a NAP, access the Settings → Routing → NAPs menu.



The NAP (Network Access Point) is an entry and/or exit point for calls. All points must be registered

on the KMG so they can be used for call routing.

Add a NAP

1. Click on the "New NAP" button;

2. Type a name, preferably one that facilitates identification for routing purposes;

3. Select the NAP type. The types displayed are in accordance with the telephony

interfaces available on the KMG. They can be:

● SIP: for SIP trunks. For example: IP PBX, dialers and VoIP carriers.

● TRUNK: for E1/T1 trunks, if there is an E1/T1 interface. Telephony

carriers and PBX systems would apply to this type.

● GSM: for GSM telephony interface, if there is a GSM interface.

● FXS: for FXS interfaces, if there is an FXS interface.

● FXO: for FXO telephony interfaces, if there is an FXO interface.

4. Enter the information required for the selected NAP. Refer to the NAP section of the

KMG MS line manual for more information. The manual is available in our

Document area;

5. Click on the Save button. Finally, click on the Apply button.

This NAP will be available for use in call routing.

Example of the creation of a SIP NAP

1. Click on the New NAP button;

2. Provide a name for the NAP;

3. In the "Type" field, select the SIP option;

4. In the "Domain" field, provide the SIP server address;

5. In the "Domain port" field, inform the server SIP port;

6. In the "SIP protocol network interface", select the network interface that will

transport this protocol;

7. In the "RTP protocol network interface", select the network interface that will

transport this protocol;


If it is necessary to register in the SIP server, enable the "Registration" option and fill out the

required fields in this panel.

Routes

To configure a route, access the Settings → Routing → Routes menu.

Routes are responsible for connecting the calls from one NAP to the other. They are necessary to

allow calls to travel through the KGM. It is possible to include a filter for the dialed number, as well

as for the source number, i.e., the person dialing. This way you can create lower cost routes, or

forward the call to a specific destination, for example.

Adding a new route

https://devserver/kdevwiki/Manual_KMG_MS#NAPs



To create a route without using filters by dialed number and without changing the incoming or

outgoing number:

1. Click on the "New Route" button;

2. Provide a name for the route;

3. Provide the priority that this route will have over other similar routes. 0 indicates

maximum priority. 99 indicates minimum priority.

4. Select the source NAP;

5. Select the destination NAP;


Using filters and changing the incoming and outgoing numbers

KMG allows for applying filters to the routes. This allows for the creation of routes for specific cases,

such as a lower cost route, for example. Moreover, it is possible to change the dialed number or the

number that originated the call. There are two ways to create filters:

● Prefix: checks if the beginning of the number corresponds to what was entered on this

field. For example: 0489 - a call to the number 048999554400 would use this route.

● Regular expression: KMG uses regular expressions to define A and B number filters,

as well as to change incoming and outgoing numbers. Regular expressions follow the

Extended POSIX standard. For more information, use the complete reference, available

at http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html. For

example: for the previous example, the following expression would be used ^0489[0-

9]{8}$.

Filter fields

B Number: filter that corresponds to the number dialed by the incoming call, i.e. number to which

the call is being made.

A Number: filter that corresponds to the source number, provided by the outgoing call, i.e., number

from the person calling.

Changing the incoming and outgoing numbers

Change B number: changes the number dialed before sending to the destination NAP. It is

possible to include the telephone carrier code before the dialed number, for example.

Change A number: changes the source number, i.e., the number that originated the call.

Add route with filter for the destination number

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html



You can create a route in which calls to mobile phones are forwarded to the GSM carrier, or forward

long distance calls to a carrier that has the best plan for this case, for example. To create a route

including a filter for the dialed number:

1. Click on the "New Route" button;

2. Provide a name for the route;

3. Provide the priority that this route will have over other similar routes. 0 indicates

maximum priority. 99 indicates minimum priority.

4. Select the source NAP;

5. Provide the desired filter in the "B Number" filter;

6. Select the destination NAP.


Example of route for an outgoing number to a local landline

NAME: LOCAL_LANDLINE

PRIORITY: 0 → Maximum priority for this route

SOURCE NAP: SIP_DIALER → SIP-type NAP that has been previously registered

B NUMBER: ^48[0-9]{8}$ → Accepts numbers with the prefix 48 + 8 digits

A NUMBER: → Blank (does not distinguish by A number)

DESTINATION NAP: CARRIER_01 → TRUNK-type NAP that has been previously

registered

CHANGING B NUMBER: /^48([0-9]{8})$/$1/ → Removes the prefix and dials only the last 8 digits

CHANGING A NUMBER: → Blank (does not change A number)

Example of route for outgoing number to a local mobile number with a change in the dialed number

NAME: LOCAL_MOBILE

PRIORITY: 0 → Maximum priority for this route

SOURCE NAP: SIP_DIALER → SIP-type NAP that has been previously registered

B NUMBER: ^9[0-9]{8}$ → Only accepts numbers with the prefix 9 + 8 digits

A NUMBER: → Blank (does not distinguish by A number)

DESTINATION NAP: GSM_CARRIER_1 → GSM-type NAP that has been previously

registered

CHANGING B NUMBER: /^48([0-9]{8})$/$1/ → Removes the prefix and dials only the last 8 digits

CHANGING A NUMBER: → Blank (does not change A number)



11 Appendix C: Alcatel-Lucent Enterprise Communication Platform: configuration requirements

Here the configuration details are explained to understand the test environment better Section 1: Topology and the call flow Section 2: Configurations done at OXE end Section 3: Analog phone (Ext behind Khomp) configuration

Section 1: Topology and Call flow

General Info:

1. Main Office OXE has PSTN access (ISDN BRI)- TG 900. 2. 4 SIP phones are configured with OXE IP address as SIP server and KMG 400 MS

gateway as SIP proxy.

Call Flow

a) When the IP link is up and OXE is reachable, all the SIP extensions will get registered in OXE.

b) The gateway device just forwards the SIP register requests from the SIP phones to OXE.

c) When the LINK is down, the KMG start acting as the SIP server and all the SIP phones in the remote office are rescued and all the phones can communicate locally.



Section 2: Configurations done at 8770 end

Apart from the parameters shown here the rest are not modified (default values are used). 1. SIP Trunk Group

In our Example TG 100 is created as SIP TG with remote network as 10. OXETrunk Group

Trunk group screenshot 2



2. SIP Gateway OXESIPSIP Gateway

3. SIP Proxy OXESIPSIP Proxy



4. Configuring SIP extn OXE OXEUsers

6. IP domain configuration OXEIPIP Domain



12 Appendix D: AAPP member’s escalation process

Escalation procedure:

Get in touch with us via:

We support English, Spanish and Portuguese

Or via email [email protected].

We open a ticket and it will be handled accordingly. We have support L1, L2 and L3.




13 Appendix E: AAPP program

13.1 Alcatel-Lucent Application Partner Program (AAPP)

The Application Partner Program is designed to support companies that develop communication applications for the enterprise market, based on Alcatel-Lucent Enterprise's product family. The program provides tools and support for developing, verifying and promoting compliant third-party applications that complement Alcatel-Lucent Enterprise's product family. ALE International facilitates market access for compliant applications. The Alcatel-Lucent Application Partner Program (AAPP) has two main objectives:

Provide easy interfacing for Alcatel-Lucent Enterprise communication products: Alcatel-Lucent Enterprise's communication products for the enterprise market include infrastructure elements, platforms and software suites. To ensure easy integration, the AAPP provides a full array of standards-based application programming interfaces and fully-documented proprietary interfaces. Together, these enable third-party applications to benefit fully from the potential of Alcatel-Lucent Enterprise products.

Test and verify a comprehensive range of third-party applications: to ensure proper inter-working, ALE International tests and verifies selected third-party applications that complement its portfolio. Successful candidates, which are labelled Alcatel-Lucent Enterprise Compliant Application, come from every area of voice and data communications.

The Alcatel-Lucent Application Partner Program covers a wide array of third-party applications/products designed for voice-centric and data-centric networks in the enterprise market, including terminals, communication applications, mobility, management, security, etc.



Web site The Application Partner Portal is a website dedicated to the AAPP program and where the InterWorking Reports can be consulted. Its access is free at https://www.al-enterprise.com/en/partners/aapp

13.2 Enterprise.Alcatel-Lucent.com

You can access the Alcatel-Lucent Enterprise website at this URL: https://www.al-enterprise.com


https://www.al-enterprise.com/



14 Appendix F: AAPP Escalation process

14.1 Introduction

The purpose of this appendix is to define the escalation process to be applied by the ALE International Business Partners when facing a problem with the solution certified in this document. The principle is that ALE International Technical Support will be subject to the existence of a valid InterWorking Report within the limits defined in the chapter “Limits of the Technical support”. In case technical support is granted, ALE International and the Application Partner, are engaged as following:

(*) The Application Partner Business Partner can be a Third-Party company or the ALE International Business Partner itself



14.2 Escalation in case of a valid Inter-Working Report

The InterWorking Report describes the test cases which have been performed, the conditions of the testing and the observed limitations. This defines the scope of what has been certified. If the issue is in the scope of the IWR, both parties, ALE International and the Application Partner, are engaged: Case 1: the responsibility can be established 100% on ALE International side.

In that case, the problem must be escalated by the ALE Business Partner to the ALE International Support Center using the standard process: open a ticket (eService Request –eSR)

Case 2: the responsibility can be established 100% on Application Partner side.

In that case, the problem must be escalated directly to the Application Partner by opening a ticket through the Partner Hotline. In general, the process to be applied for the Application Partner is described in the IWR.

Case 3: the responsibility can not be established.

In that case the following process applies:

The Application Partner shall be contacted first by the Business Partner (responsible for the application, see figure in previous page) for an analysis of the problem.

The ALE International Business Partner will escalate the problem to the ALE

International Support Center only if the Application Partner has demonstrated with traces a problem on the ALE International side or if the Application Partner (not the Business Partner) needs the involvement of ALE International

In that case, the ALE International Business Partner must provide the reference of the Case Number on the Application Partner side. The Application Partner must provide to ALE International the results of its investigations, traces, etc, related to this Case Number.

ALE International reserves the right to close the case opened on his side if the investigations made on the Application Partner side are insufficient or do not exist.

Note: Known problems or remarks mentioned in the IWR will not be taken into account. For any issue reported by a Business Partner outside the scope of the IWR, ALE International offers the “On Demand Diagnostic” service where ALE International will provide 8 hours assistance against payment . IMPORTANT NOTE 1: The possibility to configure the Alcatel-Lucent Enterprise PBX with ACTIS quotation tool in order to interwork with an external application is not the guarantee of the availability and the support of the solution. The reference remains the existence of a valid InterWorking Report. Please check the availability of the Inter-Working Report on the AAPP (URL: https://www.al-enterprise.com/en/partners/aapp) or Enterprise Business Portal (Url: Enterprise Business Portal) web sites. IMPORTANT NOTE 2: Involvement of the ALE International Business Partner is mandatory, the access to the Alcatel-Lucent Enterprise platform (remote access, login/password) being the Business Partner responsibility.



https://businessportal.alcatel-lucent.com/alugesdp/faces/gesdp/products/Listing.jspx?DOCTYPE=Technical_Documentation/Interworking_Reports&RESULTSBYPAGE=25&BOXES=partner,product&OPENFOLDER=doctype.Interworking_Reports&_afPfm=2



14.3 Escalation in all other cases

For non-certified AAPP applications, no valid InterWorking Report is available and the integrator is expected to troubleshoot the issue. If the ALE Business Partner finds out the reported issue is maybe due to one of the Alcatel-Lucent Enterprise solutions, the ALE Business Partner opens a ticket with ALE International Support and shares all trouble shooting information and conclusions that shows a need for ALE International to analyze. Access to technical support requires a valid ALE maintenance contract and the most recent maintenance software revision deployed on site. The resolution of those non-AAPP solutions cases is based on best effort and there is no commitment to fix or enhance the licensed Alcatel-Lucent Enterprise software. For information, for non-certified AAPP applications and if the ALE Business Partner is not able to find out the issues, ALE International offers an “On Demand Diagnostic” service where assistance will be provided for a fee.



14.4 Technical support access The ALE International Support Center is open 24 hours a day; 7 days a week:

e-Support from the Application Partner Web site (if registered Alcatel-Lucent Application

Partner): https://www.al-enterprise.com/en/partners/aapp

e-Support from the ALE International Business Partners Web site (if registered Alcatel-Lucent

Enterprise Business Partners): https://businessportal2.alcatel-lucent.com click under “Contact

us” the eService Request link

e-mail: [email protected]

Fax number: +33(0)3 69 20 85 85

Telephone numbers:

ALE International Business Partners Support Center for countries:

For other countries: English answer: + 1 650 385 2193 French answer: + 1 650 385 2196 German answer: + 1 650 385 2197 Spanish answer: + 1 650 385 2198

END OF DOCUMENT

Country Supported language Toll free number

France

French

+800-00200100

Belgium

Luxembourg

Germany

German Austria

Switzerland

United Kingdom

English

Italy

Australia

Denmark

Ireland

Netherlands

South Africa

Norway

Poland

Sweden

Czech Republic

Estonia

Finland

Greece

Slovakia

Portugal

Spain Spanish


https://businessportal2.alcatel-lucent.com/


Partner: Khomp Application type: Media Gateway KMG series · The KMG 400 MS MS is a low density...

Documents

Transcript of Partner: Khomp Application type: Media Gateway KMG series · The KMG 400 MS MS is a low density...