Audiocodes Mediant800 V6 4 SAS OmniPCXEnterpriseR10 1 IWR

Alcatel-Lucent Application Partner Program
Inter-Working Report
Partner: AUDIOCODES
Application type: Media Gateway
Application name: Mediant 800 (with SAS)
Alcatel-Lucent Platform: OmniPCX Enterprise™
The product and version listed have been tested with the Alcatel-Lucent Communication Server and the version
specified hereinafter. The tests concern only the inter-working between the Application Partner product and the
Alcatel-Lucent Communication platforms. The inter-working report is valid until the Application Partner issues a new
version of such product (incorporating new features or functionality), or until Alcatel-Lucent issues a new version of
such Alcatel-Lucent product (incorporating new features or functionality), whichever first occurs.
ALCATEL-LUCENT MAKES NO REPRESENTATIONS, WARRANTIES OR CONDITIONS WITH RESPECT TO THE

APPLICATION PARTNER PRODUCT. WITHOUT LIMITING THE GENERALITY OF THE FOREGOING, ALCATEL-
LUCENT HEREBY EXPRESSLY DISCLAIMS ANY AND ALL REPRESENTATIONS, WARRANTIES OR CONDITIONS
OF ANY NATURE WHATSOEVER AS TO THE APPLICATION PARTNER PRODUCT INCLUDING WITHOUT
LIMITATION THE IMPLIED WARRANTIES OF MERCHANTABILITY, NON INFRINGEMENT OR FITNESS FOR A
PARTICULAR PURPOSE AND ALCATEL-LUCENT FURTHER SHALL HAVE NO LIABILITY TO APPLICATION
PARTNER OR ANY OTHER PARTY ARISING FROM OR RELATED IN ANY MANNER TO THIS CERTIFICATE.
Alcatel-Lucent Application Partner Program – Inter-working Report

Copyright © 2011 Alcatel-Lucent, All rights reserved Edition 1 - page 1/98
Tests identification
Date of the tests May 17, 2012
Alcatel-Lucent’s representative Sebastien EHRHARD

Partner’s representative Eran Battat
Alcatel-Lucent Communication OmniPCX Enterprise

Platform
Alcatel-Lucent compatibility release R10.1 J2.501.11.c
Partner’s application version 6.40A.037.009
Author(s): Denis Lienhart

Reviewer(s):
Historic
Edition 1: creation of the document – 17-05-2012
Test results
Passed Refused Postponed
Passed with restrictions
Refer to the section 4 for a summary of the test results.

Company Contact Information
Contact name: Eran Battat

Title: Field Application Engineer
Address 1: 54, route des Sartrouville

Address 2:
City: LE PECQ
State:
Zip: 78230
Country: France
Country code:
Phone: +972 3 9764288

Fax: +972 3 9764040
Web address: http://www.audiocodes.com

E-mail: eran.battat@audiocodes.com

TABLE OF CONTENTS
1 INTRODUCTION .................................................................................................................................................... 6
2 APPLICATION INFORMATION ........................................................................................................................... 7

2.1 BRIEF APPLICATION DESCRIPTION: ................................................................................................................. 7
2.2 SEAMLESS INTERFACE WITH LEGACY ENTERPRISE NETWORKS ................................................................... 7
2.3 SAS - STAND ALONE SURVIVABILITY FOR SERVICE CONTINUITY ................................................................. 7
3 TESTS ENVIRONMENT ....................................................................................................................................... 8
3.1 ARCHITECTURE ................................................................................................................................................ 8
3.2 NETWORK CONFIGURATION ........................................................................................................................... 11
3.3 HARDWARE CONFIGURATION ........................................................................................................................ 12
3.4 SOFTWARE CONFIGURATION .......................................................................................................................... 12
4 SUMMARY OF TEST RESULTS ....................................................................................................................... 13
4.1 SUMMARY OF MAIN FUNCTIONS SUPPORTED ................................................................................................. 13
4.2 SUMMARY OF PROBLEMS................................................................................................................................ 15
4.3 SUMMARY OF LIMITATIONS ........................................................................................................................... 15
4.4 NOTES, REMARKS ........................................................................................................................................... 16
5 TEST SCENARIOS .............................................................................................................................................. 17
5.1 TEST PROCEDURE ........................................................................................................................................... 17
5.2 RESULT TEMPLATE ......................................................................................................................................... 18
6 TESTING ............................................................................................................................................................... 19
6.1 IP LINK BETWEEN HEADQUARTERS AND REMOTE OFFICE LOSS / RECOVER ................................................ 19
6.1.1 Switch ...................................................................................................................................................... 19
6.2 MEDIANT 800 USED AS ANALOG / SIP GATEWAY........................................................................................ 21
6.2.1 Analog equipment initialization, SIP registration and authentication .................................................... 21
6.2.2 Audio codec negotiation .......................................................................................................................... 22
6.2.3 Defense .................................................................................................................................................... 23
6.2.4 Basic calls................................................................................................................................................ 25
6.2.5 Telephonic features ................................................................................................................................. 27
6.2.6 Fax ........................................................................................................................................................... 33
6.2.7 Emergency calls....................................................................................................................................... 35
6.3 MEDIANT 800 USED AS SIP PROXY (IN CASE OF IP NETWORK FAILURE)................................................... 38
6.3.1 SIP registration and authentication ........................................................................................................ 38
6.3.2 Audio codec negotiation .......................................................................................................................... 39
6.3.3 Defense .................................................................................................................................................... 41
6.3.4 Basic calls................................................................................................................................................ 43
6.3.5 Telephonic features ................................................................................................................................. 45
6.4 ROBUSTNESS ................................................................................................................................................... 52
6.4.1 Test Objectives......................................................................................................................................... 52
6.4.2 Test Results .............................................................................................................................................. 52
7 APPENDIX A: PARTNER APPLICATION DESCRIPTION .......................................................................... 53
SECTION 1: CONFIGURATIONS DONE AT MEDIANT 800- GUI BASED .................................................................... 53
8 APPENDIX B: PARTNER APPLICATION: CONFIGURATION REQUIREMENTS ................................ 54
SECTION 2 : CONFIGURATIONS DONE AT MEDIAN 800- INI................................................................................... 67
9 APPENDIX C: ALCATEL-LUCENT PLATFORM: CONFIGURATION REQUIREMENTS ................... 75
SECTION 1: TOPOLOGY AND CALL FLOW.................................................................................................................. 75

SECTION 2 : CONFIGURATIONS DONE AT OXE END .................................................................................................. 77
10 APPENDIX D: PARTNER ESCALATION PROCESS ................................................................................. 92
11 APPENDIX E: AAPP PROGRAM .................................................................................................................. 93

11.1 ALCATEL-LUCENT APPLICATION PARTNER PROGRAM (AAPP) ........................................................................ 93
11.2 ALCATEL-LUCENT.COM.................................................................................................................................... 93
12 APPENDIX F: AAPP ESCALATION PROCESS .......................................................................................... 94
12.1 INTRODUCTION ................................................................................................................................................. 94
12.2 ESCALATION IN CASE OF CERTIFIED APPLICATION/PRODUCTS ........................................................................... 95
12.3 ESCALATION IN CASE OF NON-CERTIFIED APPLICATION/PRODUCT ..................................................................... 96
12.4 TECHNICAL SUPPORT ACCESS........................................................................................................................... 97

1 Introduction
The goal of these tests is to qualify an external application as an Alliance & Application Partner Program
solution for the Alcatel-Lucent Communication Platform.
The scope of the tests is the interoperability of the application with the Alcatel-Lucent Communication
Platform. It covers a basic or complex inter-working to ensure that services requested by the application and
provided by the Communication Platform (and/or conversely) are properly completed. These tests do not
verify the functional achievement of the application as well as they do not cover load capacity checks, race
conditions and generally speaking any real customer's site conditions.

2 Application information
Telephone Adapter / VoIP Gateway for Analog

Application type:
equipments
Application commercial name: Mediant 800
Application version: 6.40A.037.009
Interface type: SIP
2.1 Brief application description:

The Mediant 800 Multi-Service Business Gateway (MSBG) is a networking device that combines
multiple service functions such as a Media Gateway, Session Border Controller (SBC), Data Router
and Firewall, LAN switch, WAN access, Stand Alone Survivability (SAS) and an integrated general-
purpose server. The device is designed as a secured Voice-over-IP (VoIP) and data platform.
Enhanced media gateway security features include SRTP for media, TLS for SIP control.
2.2 Seamless Interface with Legacy Enterprise Networks

The enhanced hardware and software capabilities of the Mediant 800 provide easy installation and
continuous maintenance of voice quality. If the measured voice quality falls beneath a preconfigured
threshold, or if the path to a destination is disconnected, the Mediant 800 assures voice connectivity
by falling back to the PSTN. In the event of network problems, calls can be routed back to the PSTN
without requiring routing modifications in the PBX
2.3 SAS - Stand Alone Survivability for Service Continuity

Customers, who connect to centralized IP Centrex services, as well as branch offices of enterprises,
using a centralized IP-PBX server, may face a survivability challenge. Stand Alone Survivability
(SAS), supported in the Mediant 800, uses SIP B2BUA (Back to Back User Agent) functionality.
In our case, when the IP link is broken between the headquarters OXE and the branch office, the
branch office IPTouch switch to SIP and register to the Mediant 800 allowing them to be able to
make and receive calls (inside the branch office and also with the external world thanks to the
Mediant 800 PSTN connection).
Only the Mediant 800 hardware is tested in this document but the behavior should be the same with
all the Mediant family.

3 Tests environment
3.1 Architecture
Figure 1: Tests environment

Normal Mode
Figure 2 : Normal Mode WAN Link UP
SAS Mode
Figure 3: IPTouch SIP survivability WAN link Down

There are two modes:
• Normal behavior (OXE LINK IS UP)
The Mediant 800 is used as an analog / SIP gateway for the remote office analog phones and fax
machines. These equipments are seen as SIP end points by the OXE Call Server.
All the calls use the IP network and are handled by the OXE. The PSTN network is not used by the
Mediant 800 except for emergency outgoing calls.
• In case of IP network failure,(SAS mode)

The Mediant 800 is used as a SIP proxy. The IPTouch have lost the connection to the OXE Call
Servers and register to the Mediant 800 in SIP mode. Calls are handled by the Mediant 800. In this
case, calls between the remote office and the headquarters use the PSTN network. Remote office
users (analog phones and fax machines, IPTouch) can make (receive) calls to (from) other remote
office users and also to (from) external PSTN users thanks to the Mediant 800 PSTN BRI
connectivity.

3.2 Network configuration
Headqaurters:(Main Office)
• OmniPCX Enterprise (common hardware) with two CPU in spatial redundancy
o IP address: 10.1.8.1 (first CPU role address) and 10.10.10.50 (second CPU role address)
o SIP Domain name: node1slash.etesting.com
o Attendant: Directory Number 31900
o 4645 Voice mail: Directory Number 31300, hosted on first OXE CPU
o IPTouch phone: Directory Number 33015,33018
o UA phone: Directory Number 33000
o OXE - PSTN (ISDN T0 access): +91-44-45046242, Prefix: 66
o Analog fax: directory number 33001
o IP domain 6: IP address range 10.200.48.72 to 10.200.48.73.
o IP domain 7: IP address 10.200.48.71 & 10.200.48.78.
o Emergency number 911
Remote office:
• Mediant 800
o IP address: 10.200.48.73
o Analog phones: Directory Numbers 65010 - FXS port 1, 65011 - FXS port 2, 65012 - FXS
port 3
o IPTouch phones: Directory Numbers 33015 (IP address 10.200.48.78)
o Fax: Directory Number 65013 - FXS port 4
o M800 - PSTN (ISDN T0 access): +91-44-42180292 (to analog phone 65010 or IPTouch
33015 depending on the test)
o Emergency number 911

3.3 Hardware configuration
• Alcatel OmniPCX Enterprise :
o Common hardware : CallServer, MediaGateway, MIX board (ISDN, Digital, Analog), Digital
and Analog sets and 4068 IPTouch Extended Edition
• Application platform: Mediant 800(4 FXS, 4 FXO and 4 BRI ports) tests are detailed in this document
but all the Mediant 800 family should have the same behaviour.
3.4 Software configuration
• Alcatel Communication Platform: OmniPCX Enterprise (R10.1 - j2.501.11.c-fr-c80s1)

• Application Platform: Mediant 800 6.40A.037.009

4 Summary of test results
4.1 Summary of main functions supported
Features Status Comments
6.1 IP link between headquarters and remote office loss /

OK
recover
6.2 MEDIANT 800 used as Analog / SIP gateway
6.2.1 Analog equipment initialization, SIP registration and

OK
authentication
6.2.2 Audio codec negotiation OK
6.2.3 Defence (call server switch over and reboot) OK
6.2.4 Basic calls OK
6.2.5 Telephonic features
Forward on busy / No Answer is not

Forward OK But working for an analog phone from
PSTN User
Hold and broker call OK
Only transfer during ringing is

Transfer OK
possible
Feature not available on the Analog

Conference NA
phone
Voice mail OK
Do not disturb OK
Wake up OK
Call back OK
6.2.6 Fax OK

6.3 MEDIANT 800 used as SIP proxy (in case of IP network failure)
IP Touch SIP authentication is not

supported by the Audiocodes
6.3.1 SIP registration and authentication OK
equipment
6.3.2 Audio codec negotiation OK
6.3.3 Defence (Audiocodes equipment and IPTouch

OK
reboot)
0 Basic calls OK
Forward OK Not working for PSTN calls
Broker call From the IPTouch (OXE

Extn) to analog extns behind Mediant
Hold and broker call OK But 800 is OK, But hold tone is not played
on the analog phone when IP Touch
makes it on hold.
For blind transfer, IPTouch key has to

Transfer OK be used (hook on does not work).
Feature not available on the analog

Conference NA
phone
Voice mail OK
Do not disturb OK
6.3.6 Emergency Calls OK
6.4.2 Robustness OK

4.2 Summary of problems
None
4.3 Summary of limitations

Mediant 800 used as analog / SIP gateway (link between headquarters and remote office is up
and running))
The Dial tone is available only for sometime in the analog ports of M800.
The disconnect tone is not heard on the analog phones.
Call Forward Busy feature activated at Analog extension behind Mediant 800 is NOT working during
an incoming call from PSTN User. Refer the SR 1-136417571 for more details.
Conference feature is not available on the analog phone.
The call back from an analog phone to IP Touch fails (analog phone picks up but the conversation is
not established during the call back). Refer the SR 1-136440645 for more details.
Mediant 800 used as SIP proxy (IP network failure between headquarters and remote office)
Consultative transfer feature is not available on the analog phone.
IP Touch SIP authentication feature is not available in the Audiocodes equipment
Conference feature is not available on the analog phone

Call Forward Busy feature activated at Analog extension is not processed by Audiocodes during an
incoming call from PSTN User. Refer the SR 1-136417575 for more details.
No disconnect tone and on hold tone on analog phone in the remote office, phone located in the
headquarters and PSTN user when put on hold by a remote office phone. Refer the SR 1-
136440641 for more details.

4.4 Notes, remarks
• Only the Mediant 800 hardware has been tested. Behavior should be the same with all the Mediant
family having similar interfaces.
• When using OXE prefix to set a forward, Do not disturb, wake-up, there is no indication on the
remote office analog sets. Only tones are heard during programmation. There is also no indication
when an OXE forward is set,
• Even if some telephonic features may be activated using Audiocodes phone local possibilities
(forward, do not disturb), it is mandatory to use the OmniPCX Enterprise features (prefix and suffix).
• When in analog / SIP gateway mode (network link between headquarters and remote office up and
running), it is possible to use the Audiocodes Mediant BRI connection to the public network as a
proximity outgoing public network trunk for the remote office users (IPTouch, analog phones). In this
case, remote office phone calls using the public network prefix are routed by the OXE to the SIP
trunk to the Audiocodes Mediant 800 BRI trunk and not to the headquarters public network trunk.
The OXE configuration is exactly the same as for the emergency calls except that the ARS prefix
has to be changed from 911 to 9 (if 9 is the public network access prefix).

5 Test Scenarios
5.1 Test procedure
Step Action Result Comment
Step: a test may comprise multiple steps depending on its complexity. Each step has to be completed
successfully in order to conform to the test. Step 0 when present represents the initial state for all the
following steps.
Action: describes which action to realize in order to set-up the conditions of the test.
Result: describes the result of the test from an external point of view. If it is positive, it describes which
application's trigger was checked. If it is negative, it describes as precisely as possible the problem. If the
step within this test is not applicable to this application: NA. This has to be filled in only if the test is checked
as mandatory in the applicability box. In that case, the column comment must indicate the reason of the non-
applicability (e.g.: service not supported). NT means not tested.
Comment: this column has to be filled in when a problem occurs during the test. It must contain a high level
evaluation of the localization of the responsibility: Alcatel-Lucent or the Partner.
it is not intended during this test session to debug and fix problems.

5.2 Result template
The results table must be formatted as indicated in the example below:
1 . action 1 OK
The application waits for

2 . action 2 OK PBX timer or phone set
hangs up
3 . action 3 OK
Relevant only if the CTI

4 . action 4 interface is a direct CSTA
link
No indication, no error
5 . action 5 NOK
message
… …

6 Testing
6.1 IP link between headquarters and remote office loss / recover
These tests check the switch between the two modes (IP link between headquarters and remote office active and inactive).
6.1.1 Switch
6.1.1.1 Test objectives
Phone behaviors are checked when the headquarters to remote office IP link goes down and up.
6.1.1.2 Test procedure
IP link is down
Check the remote office IPTouch restart and register (in SIP mode) to the MEDIANT 800.
Check they can receive and make calls from/to
a PSTN user,
1 OK
an analog phone (located behind the MEDIANT 800),
Another IPTouch located in the remote office.
Check the analog phone located behind the MEDIANT 800 can receive and make from/to a PSTN
user.

IP link is up
Check the remote office IPTouch restart and register (in proprietary mode) to the headquarters
2 OXE. OK
Check they can receive and make calls from/to
a headquarters phone,
an analog phone (located behind the MEDIANT 800).

6.2 MEDIANT 800 used as analog / SIP gateway
This is the normal mode. The IP network is up and used for the calls between the remote office and the headquarters. The MEDIANT 800 acts as an analog / SIP
gateway.
6.2.1 Analog equipment initialization, SIP registration and authentication
These tests check that the equipments (analog phones and fax machines) are able to register to the OXE with and without SIP authentication. The MEDIANT 800
SIP configuration possibilities are also tested especialy for the OXE Call Server redundancy support (alternate proxy’s, DNS).
Analog phone set registration to OXE using alternate proxy
1 The MEDIANT 800 is configured to use proxy server’s address. The main and alternate proxy OK
addresses are the OXE CPU address.
Tests are performed when first Call Server is active and then when second Call Server is active.
Analog phone set registration to OXE using DNS
2 The MEDIANT 800 is configured to use a domain name as registrar / proxy server address. The OK
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.
Analog phone set registration to OXE using SIP digest authentication

3 OK
SIP digest authentication is activated on OXE and phone side (MEDIANT 800).
Check also that outgoing call is authenticated.

6.2.2 Audio codec negotiation
These tests check that the MEDIANT 800 is using the configured audio parameters (codec, framing, VAD).
The MEDIANT 800 and OXE negotiate the appropriate codec during a basic call between a UA phone and an analog phone behind the MEDIANT 800. Same test
also between an IP Phone and the analog phone.
The MEDIANT 800 is configured to offer G711Alaw, G723 and G729 (in this priority order). The
1 OXE is configured to use G711Alaw. OK
Check that for an incoming and outgoing call, the negotiated codec is G711 Alaw
2 OXE is configured to use G723. OK
Check that for an incoming and outgoing call, the negotiated codec is G723
3 OXE is configured to use G729. OK
Check that for an incoming and outgoing call, the negotiated codec is G729
The MEDIANT 800 is configured to offer G711Alaw. The OXE is configured to use G711Alaw.
4 OK
Check that for an incoming and outgoing call, the negotiated codec is G711 Alaw
The MEDIANT 800 is configured to offer G723. The OXE is configured to use G723.
5 OK
Check that for an incoming and outgoing call, the negotiated codec is G723.

The MEDIANT 800 is configured to offer G729. The OXE is configured to use G729.
6 OK
Check that for an incoming and outgoing call, the negotiated codec is G729.
Only Steps 1 and 4 have been

7 Repeat previous 6 tests by changing Alaw to µlaw OK
performed
Codec selection. The MEDIANT 800 and OXE do not have any common codec.
8 For example, the MEDIANT 800 is configured to offer G723 and the OXE to use only G729 (use of OK
IP domains).
Check that for an incoming and outgoing call is properly rejected.
6.2.3 Defense
These tests check the MEDIANT 800 defenses against perturbations and OXE Call Servers switch over.
OXE Call Server CPU switch over while the analog phones behind the MEDIANT 800 are in idle.
1 OK
Check the behavior after a switch from the OXE main to standby CPU.
The analog phone must be able to make and receive a call after the switch over.

OXE Call Server CPU switch over while the analog phones behind the MEDIANT 800 are in
Conversation remains active.
conversation with an IPTouch.
When the analog phone hooks on, the
2 Check the behavior after a switch from the OXE main to standby CPU. OK
MEDIANT 800 sends the BYE to the
The call is still active. The phone can make and receive a second call and switch from one to
Main CPU.
another.
After on hook, the analog phone must be able to make and receive a call after the switch over.
OXE Call Server reboot while the analog phones behind the MEDIANT 800 are in idle.
3 Check the phone behavior when the OXE Call Server reboots (without standby CPU). OK
The call is released.
As soon as the Call Server is running again, the analog phone is able to make and receive a call.
OXE Call Server reboot while the analog phones behind the MEDIANT 800 are in conversation with
an IPTouch.
Check the behavior when the OXE Call Server reboots (without standby CPU).
4 The call is released. OK
As soon as the Call Server is running again, the analog phone is able to make and receive a call.
Check also the behavior when in communication with another analog set behind the MEDIANT 800
(call remains established).
After OXE Call Server Switchover try to make new call from the analog phone and check the analog
5 OK
phone is able to make hold the call with IP Touch

6.2.4 Basic calls
These tests check the analog phone located behind the MEDIANT 800 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 located behind the MEDIANT 800.
For example, an outgoing call to an IPTouch means a call made by this analog phone to the an IPTouch located in the remote office or headquarters.
Call from and to a SIP phone.
The analog phone calls a SIP phone.

1 OK
The analog phone is called by a SIP phone.
In both cases, check the display and audio during all steps (dialing, ring back tone, conversation,
release).
Call from and to an IPTouch.

2 OK
Repeat 1 with an IPTouch.
Call from and to an UA phone.

3 OK
Repeat 1 with an UA phone.
Call from and to an analog phone.

4 OK
Repeat 1 with an analog phone located in the headquarters.
Repeat 1 with an analog phone located in the remote office behind the MEDIANT 800.

Incoming call released by the caller during ringing.

5 OK
The caller releases the incoming call to the analog phone before the callee takes the call.
Outgoing call released by the caller during ringing.

6 OK
The caller releases the outgoing call from the analog phone before the callee takes the call.
Incoming call rejected by the callee during ringing.

7 NA
phone.
The callee rejects the incoming call to the analog phone during ringing.
Outgoing call rejected by the callee during ringing.

8 NA Feature not available on the IPTouch.
The callee rejects the outgoing call from the analog phone during ringing.
Call released by the analog phone.

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

10 OK
The other phone releases the call after a conversation period.
Incoming call presentation while already in conversation.

11 OK
The analog phone is already in conversation and receives a new incoming call. Check the display
(new call presentation) and audio (new call signalization).
Call from and to an external number (T0/T2)

12 OK
Call is properly established.

Call from and to an attendant

13 OK
Incoming external call (T0/T2 for example) to an attendant phone set which transfers the call to the
analog phone. Transfer is done while the analog phone is ringing but also after this one has picked
14 up the call (using the attendant soft key or going on hook). OK
Outgoing call from a analog phone to an attendant with transfers to an external call (T0/T2 for
example.
15 OK
Dialing break
16 OK
The analog phone 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.
These tests check the analog phone (located behind the MEDIANT 800) behavior during OXE telephonic feature use like forward, on hold, transfer, voice mail
interactions, conference.
Tests are also done using the MEDIANT 800 local feature possibilities.
For example, setting an immediate forward for calls to the analog phone.

Immediate forward to another phone. Prefix: 51

1 OK
The analog phone is forwarded to another phone. Call the analog phone and check that the call is
presented on the third phone and can be taken by this one.
Call to a phone, which is forwarded to another phone.

2 OK
The analog phone calls a phone forwarded to a third phone. The third phone takes the call and the
conversation is established.
Forward on no answer to another phone. Prefix: 53
The analog phone is forwarded on no answer to another phone. Call the analog phone and check
3 OK
that the call is presented on analog 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.
Call from IPTouch and Analog

Extensions are forwarded properly.
Forward on busy to another phone. Prefix: 52
Call from PSTN user is not forwarded to
4 The analog phone is forwarded on busy to another phone. While the analog phone is already in OK But
the specified extension.
conversation, call the analog phone 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.
Refer the SR 1-136417571 for more
details.

Forward on busy / no answer to another phone. Prefix: 54
The analog phone is forwarded on busy / no answer to another phone.
While the analog is already in conversation, call the analog phone and check that the call is
5 presented. Do not take the call and wait for the call to be presented on the third phone. Take the OK
call on the third phone.
Call the analog phone and check that the call is presented on analog 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.
Analog phone puts call on-hold.
6 The analog phone is in conversation with another phone. This conversation is put on-hold. Check OK
the display and on-hold music on this phone. Check also the display and audio signalization on the
analog phone. Check the conversation can be retrieved.
Analog phone is put on-hold.
7 The analog phone is in conversation with another phone. The other phone puts this conversation OK
on-hold. Check the display and on-hold music on the analog phone. Check the conversation can be
retrieved.
Broker call.
8 The analog phone has two active conversations and switches from one to another. Check the OK
display and on-hold music on the phones. Check also the display and audio signalization on the
analog phone.

Transfer in conversation.
9 The analog phone has two active conversations and transfers the first to the second. Check the NA
phone.
new conversation between the two other phones is successful and also the analog phone display
(signalization of the transfer and back to idle state).
Transfer during ringing.
The analog phone has one active conversation and another one in ringing step. Before the second Tested with hook flash in analog
10 OK
callee takes the call, the analog phone transfers its first call to this second callee. Check the new phones.
conversation between the two other phones is successful and also the analog phone display
(signalization of the transfer and back to idle state).
Conference.
11 NA
The analog phone has two active conversations and initiates a conference. Check the new phone.
conversation between the three parties is successful (audio and signalization).
Voice mail message signalization.
12 Call the analog phone and leave a message to its voice mail (for example by forwarding the analog OK
phone to the voice mail). Check that the message is indicated on the analog phone (led, display
and/or feedback tone).
Voice mail message listening.

13 OK
The analog phone has a voice mail message (see above). Press the voice mail key and interacts
with the voice mail to listen to the message.

Voice mail message deposit.
14 The analog phone calls another phone forwarded to the voice mail. He leaves a message. Check OK
the interaction between the analog phone and voice mail. Listen to the message from the other
phone.
Do Not Disturb. Prefix: 42
On the analog phone the Do not Disturb is activated. When calling this set, the call is not presented
15 on the phone. OK
On the analog phone the Do not Disturb is deactivated. When calling this set, the call is presented
on the phone and can be picked up.
Wake Up. Prefix: 506 (activation) and 507 (deactivation)
On the analog phone the Wake Up is activated. When the wake up time arrives, the phone rings.
When the picked up, the voice guide is played.
16 OK
Test also with the analog phone already in conversation when the wakeup time arrives.
On the analog phone the Wake Up is activated then deactivated. When the previous wake up time
arrives, nothing appends on the phone set.
Leaving an automatic call back. Suffix: 5 Call back booked from analog phone has
issue. The conversation is not establishing
after alerts.
17 The analog phone calls another phone already in conversation. The analog phone set uses the call OK But
back suffix to be recalled. Refer the SR 1-136440645 for more
Check the call back query is taken into account and processed. details

Called by an automatic call back. Suffix: 5
18 The analog phone is in conversation. Another phone calls the analog phone and leaves an OK
automatic call back.
Check the call back query is taken into account and processed.
MEDIANT 800 local features. For the Do not disturb, M800 sends SIP
19 OK 603 Decline.
Repeat steps 1, 3, 4, 5 and 15 but this time use the MEDIANT 800 local features possibilities.

6.2.6 Fax
These tests check the analog fax machine (located behind the MEDIANT 800) behavior during fax transmission to and from another fax machine (located in the
headquarters and in the remote office).
Fax sending to another fax machine located in the headquarters
1 The analog fax machine located behind the MEDIANT 800 sends a fax to another fax machine OK Tested for a single page fax.
located in the headquarters. Tests are performed with various contents: simple fax, complex fax
(including images), multi pages fax
Fax receiving from another fax machine located in the headquarters
2 The analog fax machine located behind the MEDIANT 800 receives a fax from another fax machine OK Tested for a single page fax.
located in the headquarters. Tests are performed with various contents: simple fax, complex fax
Fax sending to a PSTN fax machine
3 The analog fax machine located behind the MEDIANT 800 sends a fax to a fax machine located in OK Tested for a single page fax.
the PSTN network. Tests are performed with various contents: simple fax, complex fax (including
images), multi pages fax

Fax receiving from a PSTN fax machine
4 The analog fax machine located behind the MEDIANT 800 receives a fax from a fax machine OK Tested for a single page fax.
located in the PSTN network. Tests are performed with various contents: simple fax, complex fax

6.2.7 Emergency calls
These tests check the emergency calls issued by a phone located in the remote office (analog phone or IPTouch) uses the PSTN connection of the remote office to
reach the public network.
In order for the emergency service to be able to localize the caller, the call has to be issued using the PSTN public network access at the closest of the caller. Thus,
it is the Mediant 800 PSTN access which is used when the caller is a phone located in the remote office.
Moreover, the caller number (sent to the emergency service) is also the remote office public network number (and not the headquarters one).

1. User dials 911 and it is forwarded to OXE for processing (as the Link is up)
2. OXE processes 911 (91 is the ARS prefix and 1 stripped off and Mobile number is added instead). OXE then sends a new INVITE request to SIP
external gateway – as managed in command dialling table (for this mobile number)
3. Mediant 800 processes this request and makes a call to Mobile number – requested by the INVITE message using the ISDN BRI line connected to it.

Analog phone connected behind the Mediant 800 calls the emergency service
Check the call is issued using the Mediant 800 PSTN access after having been routed through the
1 OK
OXE first.
Check the caller number is the remote office one (and not the headquarters one).
IPTouch located in the remote office calls the emergency service

Check the call is issued using the Mediant 800 PSTN access after having been routed through the
2 OK
OXE first.
Check the caller number is the remote office one (and not the headquarters one).

6.3 MEDIANT 800 used as SIP proxy (in case of IP network failure)
There is a failure in the IP network and the MEDIANT 800 is used as a SIP proxy to handle the remote office IPTouch which have switched to SIP mode. Calls
between the headquarters and the remote office use the PSTN network.
6.3.1 SIP registration and authentication
These tests check that the phones are able to register to the MEDIANT 800 with and without SIP authentication.
IPTouch in SIP mode set registration to the MEDIANT 800

Registration details are shown in the
1 OK SAS/SBC Registered Users under
The IP link between the Headquarters and the remote office is cut. The phone restarts and switches
Status & diagnostics tab in M800
to SIP mode to register to the MEDIANT 800
IPTouch in SIP mode registration to the MEDIANT 800 using SIP digest authentication
2 NA
Same as 1 but with SIP digest authentication.

6.3.2 Audio codec negotiation
These tests verify that the IPTouch phone and MEDIANT 800 are negotiating the appropriate audio codecs for calls between the IPTouch and an analog phone
located behind the MEDIANT 800.
The phone is configured to offer G711Alaw, G711 µlaw, G723 and G729 (phone default behavior
which can not be changed).
1 The MEDIANT 800 is configured to use G711Alaw, G723 and G729 (in this priority order). OK
Check that for a call from the IPTouch to the analog phone, the negotiated codec is G711 Alaw
Check that for a call from the analog phone to the IPTouch, the negotiated codec is G711 Alaw
The MEDIANT 800 is configured to use G711Alaw.
2 OK
Check that for a call from the IPTouch to the analog phone, the negotiated codec is G711 Alaw
Check that for a call from the analog phone to the IPTouch, the negotiated codec is G711 Alaw
The MEDIANT 800 is configured to use G723.
sub3 OK
Check that for a call from the IPTouch to the analog phone, the negotiated codec is G723
Check that for a call from the analog phone to the IPTouch, the negotiated codec is G723

The MEDIANT 800 is configured to use G729.
4 OK
The MEDIANT 800 is configured to use G729 and G723 (in this priority order).
5 OK
6 Repeat steps 1 and 2 with µlaw for the MEDIANT 800 configuration. OK
No common codecs.
The phone is configured to offer G711Alaw, G723 and G729.

The MEDIANT 800 is configured to NOT use G711Alaw, G723 and G729 (use only G726 for
7 OK
example).
Check the behavior for a call from the IPTouch to the analog phone and for a call from the analog
phone to the IPTouch.

6.3.3 Defense
These tests check the IPTouch phone and MEDIANT 800 behaviors against perturbations such as phone and MEDIANT 800 reboot.
MEDIANT 800 reboot while IPTouch phone in SIP mode phone in idle.
1 OK
Check the phone behavior when the MEDIANT 800 reboots.
As soon as the MEDIANT 800 is running again, the phone is able to make and receive a call.
MEDIANT 800 reboot while IPTouch phone in SIP mode phone in conversation.
Check the phone behavior while in conversation when the MEDIANT 800 reboots.
The call should be properly released and, as soon as the MEDIANT 800 is running again, the phone
2 OK
is able to make and receive a call.
Check for calls with an analog phone located behind the MEDIANT 800, an IPTouch located in the
remote office (also in SIP mode), a PSTN user.
IPTouch reboots while idle.

3 OK
Check that the phone registers again to the MEDIANT 800 and is able to make and receive a call.

IPTouch reboots while in conversation.
Check the phone and MEDIANT 800 behaviors while the IPTouch is in conversation and reboots
The call should be properly released and, as soon as the IPTouch is registered again, the phone is
4 OK
able to make and receive a call.
Check for calls with an analog phone located behind the MEDIANT 800, an IPTouch located in the
remote office (also in SIP mode), a PSTN user.

6.3.4 Basic calls
These tests check the IPTouch phone and MEDIANT 800 behaviors during basic calls such as IPTouch to analog phone, IPTouch to IPTouch, IPTouch to
headquarters (thanks to the PSTN network), ...
1 Remote office IPTouch to and from remote office IPTouch OK
2 Remote office IPTouch to and from remote office analog phone (behind MEDIANT 800) OK
3 Remote office IPTouch to and from remote office SIP phone OK
Remote office IPTouch to and from headquarters phone (using PSTN network)
4 OK
Check with several headquarter phones: IPTouch, analog, digital, SIP.
Remote office analog phone and fax machine (behind MEDIANT 800) to and from headquarters
phone / fax machine (using PSTN network)
5 OK
Check with several headquarter phones: IPTouch, analog, digital, SIP.
Remote office IPTouch to and from PSTN user (headquarter OXE PSTN user or external PSTN
6 OK
user)
Remote office analog phone and fax machine (behind MEDIANT 800) to and from PSTN external
7 OK
user

Call release
IPTouch call from and to another IPTouch both located in the remote office.
IPTouch call from and to an analog phone (behind the MEDIANT 800) both located in the remote There is no disconnect tone available on
8 OK
office. the analog side.
Call is released by the called phone.

Call is released by the caller.
Call release
IPTouch located in the remote office call from and to an IPTouch located in the headquarters (using
PSTN network).
9 Analog phone (behind the MEDIANT 800) located in the remote office call from and to an IPTouch OK
located in the headquarters (using PSTN network).
Call is released by the called phone.

Call is released by the caller.
10 Repeat steps 8 and 9 but this time the call is released by the caller while the called phone is ringing. OK
Call rejection during ringing
Incoming call to an IPTouch located in the remote office. The IPTouch rejects the call.
11 OK
Check when the call comes from another IPTouch located in the remote office, from an analog
phone (behind MEDIANT 800) located in the remote office, from an IPTouch located in the
headquarters (using PSTN network), from a PSTN user.
Dialing break
12 OK
The IPTouch 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.

These tests check the IPTouch phone and MEDIANT 800 behaviors during telephonic feature use like forward, hold, transfer, conference, do not disturb, voice mail
interactions. Programmations are done on the phone itself (IPTouch) or the MEDIANT 800 (analog phones).
IPTouch located in the remote office is forwarded (immediate forward)
Check for several forward destinations:
IPTouch located in the remote office,

analog phone located in the remote office behind the MEDIANT 800,
phone located in the headquarters (using PSTN network),
1 OK
and for several callers:

PSTN user
Immediate call forward is OK. For this

test “SIP Re-routing mode” parameter is
Same as 1 but this time with an analog phone located in the remote office behind the MEDIANT
2 OK set Send to Proxy in Proxy &
800.
Registration page of MG800.

For the IPTouch, only the immediate

forward is possible.
When we call from Analog phone to IP

Touch, CLI is displayed twice in the
IPTouch.
Repeat steps 1 and 2 but this time for forward on busy, forward on no answer, forward on busy / no
3 NOK
answer.
Call forwarding on BUSY is not working
– when comes through BRI (from PSTN
User)
Refer the SR 1-136417575 for more

details.
IPTouch located in the remote office puts remote on hold
Check for several remotes:

Beep tone is heard when the call is
4 OK
IPTouch located in the remote office, placed on HOLD
PSTN user.
For an analog phone, phone located in

the headquarters and PSTN user there
5 OK is no on hold feedback tone played. The
800.
IPTouch does not send any on hold
feedback tone.

1) IP touch calls Analog and tries

broker call with another Analog
Phone =>OK .For this test
“Disconnect on Broken
Connection” parameter is set to
NO in Advanced Parameters
page of MG800.
IPTouch located in the remote office makes broker calls between two communications 2) When IP Touch makes the
analog phones on hold, hold
Check for several remotes: tone (beep tone) is not heard in
the analog phones even after
IPTouch located in the remote office, the “Hold format” parameter is
analog phone located in the remote office behind the MEDIANT 800, set to 0.0.0.0 in Supplementary
6 OK But
phone located in the headquarters (using PSTN network), Services page of MG800.
PSTN user.
Check that the IPTouch can go from one conversation to another. Refer the SR 1-136440641 for more
details.
Check also when the second call is an incoming or outgoing call.

broker call with another IP
TOUCH=> OK

broker call with PSTN =>OK

1) Analog set calls another

Analog and tries broker call with
another Analog =>OK
7 OK
800.
2) Analog set calls another
Analog and tries broker call with
PSTN user =>OK
IP Touch located in the remote office transfers its call

For this test “Disconnect on Broken
Connection” parameter is set to NO
8 OK in Advanced Parameters page of
MG800.
PSTN user.
Check for consultative and blind transfers.
Same as 8 but this time with an analog phone located in the remote office behind the MEDIANT Feature not available on the analog
9 NA
800. phone.
IPTouch located in the remote office makes a 3 parties conference

10 OK
phone located in the headquarters,
PSTN user.

Same as 10 but this time with an analog phone located in the remote office behind the MEDIANT Feature not available on the analog
11 NA
800. phone.
IPTouch located in the remote office has activated do not disturb feature
Check for several callers:

12 NA Feature not available on the IPTouch.
phone located in the headquarters,
PSTN user.
M800 sends SIP 603 Decline.

When a phone located in the
13 OK headquarters or a
800.
PSTN user calls, the call is set up
(blank) and then immediately released
Voice mail message deposit.
The IPTouch located in the remote office calls another phone forwarded to the voice mail. He
leaves a message. Check the interaction between the phone and voice mail. Listen to the message
from the other phone.
14 OK

PSTN user.
15 OK
800.

6.3.5.3 Emergency Calls
These tests check the emergency calls issued by a phone located in the remote office (analog phone or IPTouch) use the PSTN connection of the remote office to
reach the public network. In order for the emergency service to be able to localize the caller, the call has to be issued using the PSTN public network access at the
closest of the caller. Here, as the link with the headquarters is cut, it is the Mediant 800 PSTN access which is used when the caller is a phone located in the
remote office. Moreover, the caller number (sent to the emergency service) is also the remote office public network number.
1. Set from Remote office dials 911 (SAS is active)

2. Since the SAS is active, M800 handles this call and as per the configuration, the call is established using its ISDN BRI Line.

Analog phone connected behind the Mediant 800 calls the emergency service
1 Check the call is issued using the Mediant 800 PSTN access. OK
Check the caller number is the remote office one (and not the heaquarters one).
IPTouch located in the remote office calls the emergency service

2 Check the call is issued using the Mediant 800 PSTN access. OK
Check the caller number is the remote office one (and not the heaquarters one).

6.4 Robustness
6.4.1 Test Objectives
These tests verify the robustness of the network during the switchover from main to standby in spatial redundancy, SIP device reboot scenarios
6.4.2 Test Results
1 Spatial redundancy, using “Alternate Proxy method”: Switchover to standby call server OK
2 Spatial redundancy, using “DNS method”: Switchover to standby call server. OK
SIP device reboot.

3 OK
Check that calls are possible as soon as device has come back to service.
4 Temporary Link down with the PBX NT
Primary link is down. Call is made from analog FXS to IPTouch in SAS mode. During Conversation
5 OK
Primary link is up and call should not cut. When goes on hook it should go to NOE mode.

7 Appendix A: Partner Application Description
Here the configuration of M800 is provided in both GUI and INI formats
Section 1: Configurations done at MEDIANT 800- GUI based
Note:
Apart from those parameters that are highlighted/shown here, all other parameters remains at default values.
1. Accessing web Interface of Mediant 800
Detailed procedure is available in the user guide. Mediant 800 user guide can be downloaded from the
Audiocodes website.

8 Appendix B: Partner Application: Configuration
Requirements
2. Network Configurations
3. IP routing table entries

4. BRI configuration

5. SIP general Parameters

6. Proxy & Registration

7. Proxy set table

8. IP group table

9. In Authentication Page
This page is where we configure the authentication, when SIP digest is set at OXE
10. Codec configuration

11. Keypad – Prefix configuration
All these feature codes (51, 53 etc) needs to be managed in accordance with OXE for example
The Do Not Disturb prefix in OXE is 42.
So the same prefix is managed in M800 also.

12. SAS configuration
13. DIGIT Manipulation – Outgoing management during SAS
Note: This section Manipulation table>Dest Number>IP to Tel, is used to manage the calls when SAS mode is
Active, During SAS all the outgoing is performed on the BRI lines only other than the locally registered users.
With this configuration, we say that any digit starting from 3 – will be stripped and replaced with the ISDN BRI
number of OXE, so that it lands at OXE extn,
For example
a) Set 33000 is UA set in Main office
b) The DDI number of 33000 is 45046242
c) The LINK is down and SAS is active
d) FXS set 65010 makes a call to Main office, it dials 33000
e) Now Since SAS is active, this table will be referred by M800, as configured in it, any digit starting
with 3 all 5 digits will be stripped and it will be replaced by the DDI number of Main office set 33000
which is 45046242 and forwarded on the ISDN BRI port.
14. DIGIT Manipulation – Incoming BRI Management

This is where we configure the destination number – where the incoming calls on BRI should.
15. Trunk Group (FXS and BRI configurations)
Here we configure the FXS directory numbers and Associate them with a trunk group.
FXS sets – TG1 and ISDN BRI lines TG 4.

16. IP to Trunk group routing – Incoming digits management – when LINK is up
This is where we specify how the digits in the Invite message needs to be routed
For ex, we get two types of digits
1st type the Invite will have number 65010 – this need to be landed at FXS port
2nd type the Invite will have the number (mobile) starting from 9 (9840387222)
As per the configuration shown above,

- if the received digit is 6xxxx then it is routed to TG 1 (FXS pool)
- If the received digit is 9xxx then it is routed to TG 4 (BRI pool)
17. DNS configuration

18. SRV configuration
19. TDM (LAW) settings
This needs to be configured in line with that of OXE settings, In OXE we have A law, so the same Law is
maintained here as well.

Section 2 : Configurations done at MEDIAN 800- INI
Note that the network parameters (IP address, network mask and gateway) of the Audiocodes device have to
be configured first (see Audiocodes installation manual).
;**************
;** Ini File **
;**************
;Board: Mediant 800 - MSBG

;Serial Number: 3641313
;Slot Number: 1
;Software Version: 6.40A.037.009
;DSP Software Version: 5014AE3_R_LD => 640.19
;Board IP Address: 10.200.48.73
;Board Subnet Mask: 255.255.255.0
;Board Default Gateway: 10.200.48.254
;Ram size: 512M Flash size: 64M
;Num of DSP Cores: 1 Num DSP Channels: 17
;Profile: NONE
;Key features:;Board Type: Mediant 800 - MSBG ;IP Media: VXML ;Channel Type: RTP DspCh=20 ;Security: IPSEC MediaEncryption
StrongEncryption EncryptControlProtocol ;Coders: G723 G729 GSM-FR G727 ;E1Trunks=0 ;T1Trunks=0 ;PSTN Protocols: ISDN IUA=30 CAS
;DATA features: Routing FireWall&VPN WAN Advanced-Routing ;DSP Voice features: IpmDetector ;Control Protocols: MGCP MEGACO SIP
SASurvivability MSFT ;Default features:;Coders: G711 G726;
;------- Mediant-800 HW components-------

;
; Slot # : Module type : # of ports
;----------------------------------------------
; 1 : BRI :4
; 2 : FXS :4
; 3 : FXO :4
;----------------------------------------------
[SYSTEM Params]
SyslogServerIP = 10.200.48.72
ENABLEPARAMETERSMONITORING = 1
ActivityListToLog = 'pvc', 'afl', 'dr', 'fb', 'swu', 'ard', 'naa', 'spc', 'll'
PM_VEDSPUtil = '1,78,87,15'
[BSP Params]
PCMLawSelect = 3
[Analog Params]
PolarityReversalType = 1
MinFlashHookTime = 100

[ControlProtocols Params]
AdminStateLockControl = 0
[MGCP Params]
[MEGACO Params]
EP_Num_0 = 0
EP_Num_1 = 1
EP_Num_2 = 1
EP_Num_3 = 0
EP_Num_4 = 0
[PSTN Params]
TraceLevel_0 = 2
TraceLevel_1 = 0
TraceLevel_2 = 0
TraceLevel_3 = 0
ProtocolType_0 = 50
ProtocolType_1 = 0
ProtocolType_2 = 0
ProtocolType_3 = 0
[SS7 Params]
[Voice Engine Params]
FaxTransportMode = 1
V22ModemTransportType = 0
CNGDetectorMode = 0
RFC2833TxPayloadType = 101
V34FAXTRANSPORTTYPE = 0
[WEB Params]
LogoWidth = '145'
HTTPSCipherString = 'RC4:EXP'
[SIP Params]
ISPROXYUSED = 1
ISREGISTERNEEDED = 1
AUTHENTICATIONMODE = 3
PLAYRBTONE2TEL = 1
ROUTEMODEIP2TEL = 16

CHANNELSELECTMODE = 0
ENABLERPIHEADER = 1
PROXYNAME = 'node1slash.etesting.com'
REGISTRARIP = 'node1slash.etesting.com'
SIPGATEWAYNAME = 'node1slash.etesting.com'
ALWAYSSENDTOPROXY = 1
KEYCFUNCOND = '51'
KEYCFDEACT = '41'
KEYCFNOANSWER = '53'
KEYCFBUSYORNOANSWER = '54'
KEYCFBUSY = '52'
KEYBLINDTRANSFER = '1'
DISCONNECTONBROKENCONNECTION = 0
XFERPREFIX = '2'
ENABLEMWISUBSCRIPTION = 1
MWISERVERIP = 'node1slash.etesting.com'
MWIANALOGLAMP = 1
MWIDISPLAY = 1
ENABLEMWI = 1
PREFERROUTETABLE = 1
ISFAXUSED = 1
KEYCFDONOTDISTURB = '42'
REGISTRARNAME = 'node1slash.etesting.com'
ISDNTRANSFERCAPABILITY_0 = 1
ISDNTRANSFERCAPABILITY_1 = -1
PLAYRBTONE2TRUNK_0 = 1
PLAYRBTONE2TRUNK_1 = -1
ENABLEHISTORYINFO = 1
ENABLE3WAYCONFERENCE = 1
CONFERENCECODE = '3'
ENABLEGRUU = 1
TRUNKPSTNALERTTIMEOUT_0 = 500
TRUNKPSTNALERTTIMEOUT_1 = -1
REGISTRATIONTIMETHRESHOLD = 1
ENABLESAS = 1
REGISTERONINVITEFAILURE = 1
REDUNDANTROUTINGMODE = 2
REGISTRARTRANSPORTTYPE = 0
MWISERVERTRANSPORTTYPE = 0
BCHANNELNEGOTIATIONFORTRUNK_0 = 2
BCHANNELNEGOTIATIONFORTRUNK_1 = -1
SIPREROUTINGMODE = 1
SASBINDINGMODE = 1
SASSURVIVABILITYMODE = 1

RemoveCallingNameForTrunk_0 = 0
RemoveCallingNameForTrunk_1 = -1
3WayConfNoneAllocateablePorts = 0
SetTel2IpRedirectReason = 13
SetIp2TelRedirectReason = 13
SetIp2TelRedirectScreeningInd = 3
SASINBOUNDMANIPULATIONMODE = 1
[SCTP Params]
[IPsec Params]
[Audio Staging Params]
[SNMP Params]
[ TrunkGroup ]
FORMAT TrunkGroup_Index = TrunkGroup_TrunkGroupNum, TrunkGroup_FirstTrunkId, TrunkGroup_FirstBChannel,

TrunkGroup_LastBChannel, TrunkGroup_FirstPhoneNumber, TrunkGroup_ProfileId, TrunkGroup_LastTrunkId, TrunkGroup_Module;
TrunkGroup 0 = 1, 255, 1, 1, 65010, 0, 255, 2;
TrunkGroup 1 = 1, 255, 2, 2, 65011, 0, 255, 2;
TrunkGroup 2 = 1, 255, 3, 3, 65012, 0, 255, 2;
TrunkGroup 3 = 1, 255, 4, 4, 65013, 0, 255, 2;
TrunkGroup 4 = 4, 0, 1, 1, 45046242, 1, 0, 1;
TrunkGroup 5 = 4, 1, 1, 1, 45046243, 1, 1, 1;
[ \TrunkGroup ]
[ NumberMapIp2Tel ]
FORMAT NumberMapIp2Tel_Index = NumberMapIp2Tel_DestinationPrefix, NumberMapIp2Tel_SourcePrefix,

NumberMapIp2Tel_SourceAddress, NumberMapIp2Tel_NumberType, NumberMapIp2Tel_NumberPlan, NumberMapIp2Tel_RemoveFromLeft,
NumberMapIp2Tel_RemoveFromRight, NumberMapIp2Tel_LeaveFromRight, NumberMapIp2Tel_Prefix2Add, NumberMapIp2Tel_Suffix2Add,
NumberMapIp2Tel_IsPresentationRestricted, NumberMapIp2Tel_SrcTrunkGroupID, NumberMapIp2Tel_SrcIPGroupID;
NumberMapIp2Tel 1 = 911, *, *, 4, 9, 3, 0, 255, 9840244932, 0, 255, -1, -1;
[ \NumberMapIp2Tel ]
[ NumberMapTel2Ip ]
FORMAT NumberMapTel2Ip_Index = NumberMapTel2Ip_DestinationPrefix, NumberMapTel2Ip_SourcePrefix,

NumberMapTel2Ip_SourceAddress, NumberMapTel2Ip_NumberType, NumberMapTel2Ip_NumberPlan, NumberMapTel2Ip_RemoveFromLeft,
NumberMapTel2Ip_RemoveFromRight, NumberMapTel2Ip_LeaveFromRight, NumberMapTel2Ip_Prefix2Add, NumberMapTel2Ip_Suffix2Add,
NumberMapTel2Ip_IsPresentationRestricted, NumberMapTel2Ip_SrcTrunkGroupID, NumberMapTel2Ip_SrcIPGroupID;
NumberMapTel2Ip 1 = *, *, *, 255, 255, 8, 0, 255, 65011, , 255, 4, -1;

[ \NumberMapTel2Ip ]
[ PstnPrefix ]
FORMAT PstnPrefix_Index = PstnPrefix_DestPrefix, PstnPrefix_TrunkGroupId, PstnPrefix_SourcePrefix, PstnPrefix_SourceAddress,

PstnPrefix_ProfileId, PstnPrefix_SrcIPGroupID, PstnPrefix_DestHostPrefix, PstnPrefix_SrcHostPrefix, PstnPrefix_SrcSRDID,
PstnPrefix_TrunkId;
PstnPrefix 0 = 4*, 4, *, *, 0, -1, *, *, , -1;
PstnPrefix 1 = 6*, 1, *, *, 0, -1, *, *, , -1;
PstnPrefix 2 = 3*, 4, *, *, 0, -1, *, *, , -1;
PstnPrefix 3 = 9*, 4, *, *, 0, -1, *, *, , -1;
[ \PstnPrefix ]
[ Srv2Ip ]
FORMAT Srv2Ip_Index = Srv2Ip_InternalDomain, Srv2Ip_TransportType, Srv2Ip_Dns1, Srv2Ip_Priority1, Srv2Ip_Weight1, Srv2Ip_Port1,

Srv2Ip_Dns2, Srv2Ip_Priority2, Srv2Ip_Weight2, Srv2Ip_Port2, Srv2Ip_Dns3, Srv2Ip_Priority3, Srv2Ip_Weight3, Srv2Ip_Port3;
Srv2Ip 0 = etesting.com, 0, node1slash.etesting.com, 1, 1, 53, , 0, 0, 0, , 0, 0, 0;
[ \Srv2Ip ]
[ Dns2Ip ]
FORMAT Dns2Ip_Index = Dns2Ip_DomainName, Dns2Ip_FirstIpAddress, Dns2Ip_SecondIpAddress, Dns2Ip_ThirdIpAddress,

Dns2Ip_FourthIpAddress;
Dns2Ip 0 = node1slash.etesting.com, 10.1.8.1, 10.10.10.50, 0.0.0.0, 0.0.0.0;
[ \Dns2Ip ]
[ ProxyIp ]
FORMAT ProxyIp_Index = ProxyIp_IpAddress, ProxyIp_TransportType, ProxyIp_ProxySetId;

ProxyIp 0 = node1slash.etesting.com, 0, 0;
ProxyIp 1 = 10.200.48.73:5080, 0, 0;
[ \ProxyIp ]
[ TrunkGroupSettings ]
FORMAT TrunkGroupSettings_Index = TrunkGroupSettings_TrunkGroupId, TrunkGroupSettings_ChannelSelectMode,

TrunkGroupSettings_RegistrationMode, TrunkGroupSettings_GatewayName, TrunkGroupSettings_ContactUser,
TrunkGroupSettings_ServingIPGroup, TrunkGroupSettings_MWIInterrogationType;
TrunkGroupSettings 0 = 1, 0, 0, node1slash.etesting.com, , 1, 255;
TrunkGroupSettings 1 = 4, 1, 4, , , -1, 255;
[ \TrunkGroupSettings ]

[ CallWaitingPerPort ]
FORMAT CallWaitingPerPort_Index = CallWaitingPerPort_IsEnabled, CallWaitingPerPort_Module, CallWaitingPerPort_Port;

CallWaitingPerPort 0 = 0, 2, 1;
[ \CallWaitingPerPort ]
[ ProxySet ]
FORMAT ProxySet_Index = ProxySet_EnableProxyKeepAlive, ProxySet_ProxyKeepAliveTime, ProxySet_ProxyLoadBalancingMethod,

ProxySet_IsProxyHotSwap, ProxySet_SRD, ProxySet_ClassificationInput, ProxySet_ProxyRedundancyMode;
ProxySet 0 = 2, 60, 0, 1, 0, 0, -1;
[ \ProxySet ]
[ IPGroup ]
FORMAT IPGroup_Index = IPGroup_Type, IPGroup_Description, IPGroup_ProxySetId, IPGroup_SIPGroupName, IPGroup_ContactUser,

IPGroup_EnableSurvivability, IPGroup_ServingIPGroup, IPGroup_SipReRoutingMode, IPGroup_AlwaysUseRouteTable,
IPGroup_RoutingMode, IPGroup_SRD, IPGroup_MediaRealm, IPGroup_ClassifyByProxySet, IPGroup_ProfileId,
IPGroup_MaxNumOfRegUsers, IPGroup_InboundManSet, IPGroup_OutboundManSet, IPGroup_RegistrationMode,
IPGroup_AuthenticationMode, IPGroup_MethodList, IPGroup_EnableSBCClientForking, IPGroup_ContactName;
IPGroup 1 = 0, SERVER, 0, , , 0, -1, 0, 1, -1, 0, , 1, 0, -1, -1, -1, 0, 0, , 0, ;
[ \IPGroup ]
[ Account ]
FORMAT Account_Index = Account_ServedTrunkGroup, Account_ServedIPGroup, Account_ServingIPGroup, Account_Username,

Account_Password, Account_HostName, Account_Register, Account_ContactUser, Account_ApplicationType;
Account 1 = 1, -1, 1, 65010, *, node1slash.etesting.com, 1, 65010, 0;
[ \Account ]
[ SASRegistrationManipulation ]
FORMAT SASRegistrationManipulation_Index = SASRegistrationManipulation_RemoveFromRight,

SASRegistrationManipulation_LeaveFromRight;
SASRegistrationManipulation 0 = 0, 0;
[ \SASRegistrationManipulation ]
[ IP2IPRouting ]
FORMAT IP2IPRouting_Index = IP2IPRouting_SrcIPGroupID, IP2IPRouting_SrcUsernamePrefix, IP2IPRouting_SrcHost,

IP2IPRouting_DestUsernamePrefix, IP2IPRouting_DestHost, IP2IPRouting_RequestType, IP2IPRouting_MessageCondition,

IP2IPRouting_DestType, IP2IPRouting_DestIPGroupID, IP2IPRouting_DestSRDID, IP2IPRouting_DestAddress, IP2IPRouting_DestPort,
IP2IPRouting_DestTransportType, IP2IPRouting_AltRouteOptions, IP2IPRouting_CostGroup;
IP2IPRouting 1 = 1, *, *, 33033, *, 6, , 1, 4, , , 0, 0, 2, ;
[ \IP2IPRouting ]
[ CodersGroup0 ]
FORMAT CodersGroup0_Index = CodersGroup0_Name, CodersGroup0_pTime, CodersGroup0_rate, CodersGroup0_PayloadType,

CodersGroup0_Sce;
CodersGroup0 0 = g711Alaw64k, 20, 0, -1, 0;
CodersGroup0 1 = g711Ulaw64k, 20, 0, -1, 0;
CodersGroup0 2 = g7231, 30, 0, -1, 0;
CodersGroup0 3 = g729, 20, 0, -1, 0;
[ \CodersGroup0 ]
[ CodersGroup1 ]
FORMAT CodersGroup1_Index = CodersGroup1_Name, CodersGroup1_pTime, CodersGroup1_rate, CodersGroup1_PayloadType,

CodersGroup1_Sce;
CodersGroup1 0 = g711Alaw64k, 20, 0, -1, 0;
CodersGroup1 1 = g711Ulaw64k, 20, 0, -1, 0;
CodersGroup1 2 = g7231, 30, 0, -1, 0;
CodersGroup1 3 = g729, 20, 0, -1, 0;
[ \CodersGroup1 ]
[ RoutingRuleGroups ]
FORMAT RoutingRuleGroups_Index = RoutingRuleGroups_LCREnable, RoutingRuleGroups_LCRAverageCallLength,

RoutingRuleGroups_LCRDefaultCost;
RoutingRuleGroups 0 = 0, 0, 1;
[ \RoutingRuleGroups ]
[ InterfaceTable ]
FORMAT InterfaceTable_Index = InterfaceTable_ApplicationTypes, InterfaceTable_InterfaceMode, InterfaceTable_IPAddress,

InterfaceTable_PrefixLength, InterfaceTable_Gateway, InterfaceTable_VlanID, InterfaceTable_InterfaceName,
InterfaceTable_PrimaryDNSServerIPAddress, InterfaceTable_SecondaryDNSServerIPAddress, InterfaceTable_UnderlyingInterface;
InterfaceTable 0 = 6, 10, 10.200.48.73, 24, 10.200.48.254, 1, Voice, 10.1.8.1, 10.10.10.50, ;
[ \InterfaceTable ]
[ StaticRouteTable ]
FORMAT StaticRouteTable_Index = StaticRouteTable_InterfaceName, StaticRouteTable_Destination, StaticRouteTable_PrefixLength,

StaticRouteTable_Gateway, StaticRouteTable_Description;

StaticRouteTable 0 = Voice, 10.1.8.1, 32, 10.200.48.254, ;
StaticRouteTable 1 = Voice, 10.10.10.50, 32, 10.200.48.254, ;
[ \StaticRouteTable ]
[ DspTemplates ]
;
; *** TABLE DspTemplates ***
; This table contains hidden elements and will not be exposed.
; This table exists on board and will be saved during restarts.
;
[ \DspTemplates ]
[ POETable ]
FORMAT POETable_Index = POETable_PortEnable, POETable_PortPower;

POETable 0 = 1, 15400;
POETable 1 = 1, 15400;
POETable 2 = 1, 15400;
POETable 3 = 1, 15400;
POETable 4 = 1, 15400;
POETable 5 = 1, 15400;
POETable 6 = 1, 15400;
POETable 7 = 1, 15400;
POETable 8 = 1, 15400;
POETable 9 = 1, 15400;
POETable 10 = 1, 15400;
POETable 11 = 1, 15400;
[ \POETable ]

9 Appendix C: Alcatel-Lucent 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 1: Topology and Call flow
General Info:
1. Main Office OXE has PSTN access (ISDN BRI)- TG 40.

2. 3 Analog Phones and 1 Analog fax machine has been connected to FXS port of M800
3. These 3 Analog Phones are configured as “SIP EXTENSION” and FAX machine (65013) has been
configured as SIP DEVICE – in OXE
Call Flow
a) When the IP link is up and OXE is reachable, all the FXS extensions will get registered in OXE.
b) When the IP link is up, M800 forwards all the digits that are dialed from any FXS set to the OXE,
and OXE sees it as the digits dialed from a registered SIP set and processes it accordingly as per
the OXE configuration.
c) In OXE, In Domain Management, for Domain 6 , we manage the SIP server IP address as M800’s
Ip address, This information gets written in to the IP touch extended editions phone flash memory
when it boots and comes in-service. So that when the TFTP1 and TFTP2 servers are not
reachable, it activates the SIP protocol and tries to contact the SIP server as per its domain entry
and gets registered with it.
d) When the LINK is down, the M800 start acting as the SIP server and all the FXS ports and the IP
phones that belong to the domain 6, will get registered in to M800 in SIP mode.
e) In this condition (SAS mode), the digits dialed from FXS sets or the IP phone (SIP mode) are
managed by Median 800.
f) When the Link is up, all the calls made from FXS sets are made Via OXE, but only for the
emergency call (911), the outgoing call to 911 is made using the ISDN BRI line of M800 and not
that of OXE,

g) We achieve this, using the ARS, Digit manipulation, and external SIP gateway configuration. (It is
explained under the emergency call section)
h) When the Link is Up, Even the call made from One FXS (65010) to another FXS set (65011) will
have to go through OXE only.
i) From the User perspective, they will dial the same number when the link is up or down. For
example :
1. Emergency call :
- When the link is UP: The FXS user will dial 911, and this call happens using the ISDN
BRI line of M800, so that the 911 Department is called using the Remote office line
and they can reach the correct location.
2. Emergency call :
- When the Link is DOWN : The FXS user still dial 911, then we manage the M800 in
such a way that it is forwarded to 911 using Mediant 800’s BRI line
3. Normal call from OXE to FXS :
- When the Link is UP: User 33000 (UA set of OXE) will dial 65010 to reach the FXS
set 65010.
4. Normal Call from OXE to FXS:
- When the LINK is DOWN : OXE knows that the called set is out of service and then
as per the out of service overflow management , ->it lands at a virtual extn>which is
forwarded to the PSTN DDI number of Remote office FXS or IP touch (SIP mode) set
-> and it takes the ISDN line of Main office and lands through the ISDN line of Remote
office on the required FXS ot IP touch set
j) While the FXS sets behind Mediant 800 registers in OXE as SIP extensions, the MEDIANT800
also registers in OXE as “SIP EXTERNAL GATEWAY”
k) OXE sees the FXS sets as SIP Sets and M800 as SIP External Gateway.
l) SAS mode is triggered in Mediant 800, when it is not able to reach the both OXE (main and
Standby)

Section 2 : Configurations done at OXE end
Note:
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.

2. SIP Gateway

3. SIP Proxy
4. Configuring M800 as SIP external Gateway
Note:10.200.48.73 is the IP address of Mediant 800. Once the configurations are done correctly at M800 end
also, then we can see that the external SIP gateway is in service
with this command sipextgw –g 0

5. Configuring M800’s FXS port Analog extns as SIP extn & SIP device in OXE
Note: All remote office sets are maintained in Domain 6 and entity 6 for easy configuration purposes.

FXS port, which is connected to FAX machine alone is configured as SIP device.

6. IP domain configuration

Validate this after performing the domain configuration (ctrl+v)
7. IP domain configuration continued…
All the IP sets of remote office is maintained in Domain 6, the ranges (low and high) are configured
accordingly..
1. Remote Office IP touch phones configuration..

9. Remote Office IP touch phones configuration..SIP survi info on IP domain 6
domstat option 3 will give you the below result (>domstat )
10. Overflow configuration for reaching the FXS through BRI when the LINK is down
Thanks to this configuration, It makes it possible to call FXS or IP touch set of remote office with the same
number in both link up and link down conditions…
1. Set 33015 is IP touch EE located in remote office

2. We have configured one virtual set as its associated set (67015)
3. 67015 is a Analog virtual set

4. This set has been configured for Immediate forwarding in mgr>user>dynamic state user
66 is the Trunk Access prefix and 42180292 is Remote office Mediant 800’s ISDN BRI DDI number of the
set 33015.
5. To activate the call forward in out of service condition, we enable this parameter
In the telephone feature cos of the remote office sets.
11. Emergency call Configuration
What we need is, when the FXS sets or remote office IP touch sets dial 911, this call needs to be managed in
OXE such a way that, the outgoing call to 911 emergency service is made using the remote office ISDN BRI
line.

1. User dials 911
2. OXE processes 911 (91 is the ARS prefix and 1 stripped off and Mobile number is added instead).
OXE then sends a new INVITE request to SIP external gateway – as managed in command dialing
table (for this mobile number)
3. Mediant 800 processes this request and makes a call to Mobile number – requested by the INVITE
message using the ISDN BRI line connected to it.
a) 91 is configured as ARS Prefix
b) In entity 6, discriminator selector, mapping is done between logical and real discriminator like this

c) In mgr>translator>ext num plan>discriminator selcector>
d) In second level
Now we have mapped it to ARS table 60, so when the user from entity 6(remote office) dials 911, it will be
connected to ARS route number 60.

e) ARS route list 60 and associated time based management

Here we are removing digit 1, and adding the mobile number and we are further re-directing it to refer the
command dialing table number 60
f) Command dialing table entry (60)
We say I – Insert the digits and route it on SIP Gateway 0, this how OXE sends a INVITE with the mobile
number configured in ARS route 60 to Mediant 800 .
To ensure that for such 911, calls the CLI of remote office is sent, we manage like this
TG 40 is used for ISDN BRI TG of OXE

NPD for TG 40 is 46

NPD 46 has reference to IP domain
IP domain is 6 and in domain 6 we have the source number as M800 ISDN BRI no

Note:
When we make the call from OXE to the external mobile number, and if there is a delay is getting the 180
ringing message, then OXE tends to cut the call with a cancel message, because of this, the caller gets a
missed call on this mobile, please do the below configuration to increase the waiting time..
With this OXE end configurations are complete.

10 Appendix D: Partner escalation process
In case you would need technical assistance, please contact the reseller/distributor where you purchased your
AudioCodes products. They have been trained on the products to give you 1st and 2nd levels of support. They
are in plus in direct relation with 3rd level AudioCodes support in case an escalation would be needed.

11 Appendix E: AAPP program
11.1 Alcatel-Lucent Application Partner Program (AAPP)
Complete e-business solutions at your disposal
The Application Partner Program is designed to support companies that develop communication applications
for the enterprise market, based on Alcatel-Lucent's Omni product family.
The program provides tools and support for developing, verifying and promoting compliant third-party
applications that complement Alcatel-Lucent's Omni-based products. Alcatel-Lucent facilitates market access
for compliant applications.
The Alcatel-Lucent Application Partner Program (AAPP) has two main objectives:
• Provide easy interfacing for Alcatel-Lucent communication products:
Alcatel-Lucent'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
products.
• Test and verify a comprehensive range of third-party applications:

to ensure proper inter-working, Alcatel-Lucent tests and verifies selected third-party applications that
complement its portfolio. Successful candidates, which are labelled Alcatel-Lucent Compliant
Application, come from every area of voice and data communications.
The Allcatel-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, …
Web site
If registered Application Partner, you can access the AAPP website at this URL:
http://applicationpartner.alcatel-lucent.com
11.2 Alcatel-Lucent.com
You can access the Alcatel-Lucent website at this URL: http://www.Alcatel-Lucent.com/

12 Appendix F: AAPP Escalation process
12.1 Introduction
The purpose of this appendix is to define the split of responsibilities and the escalation process to be applied by
the Alcatel-Lucent Business Partners when facing a problem with a solution involving an Alcatel-Lucent platform
and a Third-Party application with or without a valid Alcatel-Lucent Inter-Working Report.
If a problem occurs on an installation involving Alcatel-Lucent platforms and a certified product or application,
both parties, Alcatel-Lucent and the Application Partner, are engaged as follows:
(*) The Application Partner Business Partner can be a Third-Party company or the Alcatel-Lucent Business
Partner itself

12.2 Escalation in case of certified application/products
The Alcatel-Lucent support will be limited to applications with a valid Inter-Working Report (IWR). Known
problems or remarks mentioned in the IWR will not be taken into account.
A valid IWR means an official IWR exists which is posted on the Alcatel-Lucent Enterprise Business Portal and
mentions the same release/version of the software of both parties as those of the current customer installation
(Or an official agreement between Alcatel-Lucent and the Third-Party exists to support the customer installation if
the release/version doesn’t match those mentioned in the latest IWR ).
If there is an interworking issue, both parties, Alcatel-Lucent and the Application Partner, are engaged:
Case 1: the responsibility can be established 100% on Alcatel-Lucent side.

In that case, the problem must be escalated by the ALU Business Partner to the Alcatel-Lucent 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 Alcatel-Lucent Business Partner will escalate the problem to the Alcatel-Lucent Support Center
only if the Application Partner has demonstrated with traces a problem on the Alcatel-Lucent side or
if the Application Partner (not the Business Partner) needs the involvement of Alcatel-Lucent.
In that case, the Alcatel-Lucent Business Partner must provide the reference of the Case Number on the
Application Partner side. The Application Partner must provide to Alcatel-Lucent the results of its
investigations, traces, etc, related to this Case Number.
Alcatel-Lucent reserves the right to close the case opened on his side if the investigations made on the
Application Partner side are insufficient or do no exist.
IMPORTANT NOTE 1: The possibility to configure the Alcatel-Lucent PBX with ACTIS quotation tool in order to
interwork with an external application is not a guarantee of the availability of the solution. Please check the
availability of the Inter-Working Report on the AAPP (Url: https://private.applicationpartner.alcatel-lucent.com) or
Enterprise Business Portal (Url: Enterprise Business Portal) web sites.
IMPORTANT NOTE 2: Involvement of the Alcatel-Lucent Business Partner is mandatory, the access to the
Alcatel-Lucent platform (remote access, login/password) being the Business Partner responsibility.

12.3 Escalation in case of non-certified application/product
If an Alcatel-Lucent Business Partner escalates an issue where a 3rd party application is involved and the
following conditions apply:
1. no IWR exist (not available on the Enterprise Business Portal for Business Partners or on the Alcatel-
Lucent Application Partner web site) ,
2. Or the 3rd party company is referenced as AAPP participant but with no existing IWR,
3. Or the existing IWR is available but the release/version of the both parties (Alcatel-Lucent and 3rd-party)
are not the same than those currently deployed at the customer site (see exception in Note 2).
In this case, the only responsibility of the Alcatel-Lucent Technical Support is to verify that the Alcatel-Lucent
platform is correctly installed and configured for a standard use and that the Alcatel-Lucent equipments perform
as expected. If that’s the case, Alcatel-Lucent will be forced to close the case.
If the Alcatel-Lucent Business Partner, the customer or the 3rd party company need additional and specific
involvement from Alcatel-Lucent, there are two options:
Either request a quote for specific investigation and diagnosis (with no agreement to fix the issue),
Or the AAPP program process is followed to officially certify the 3rd party application/product.
For both options, just send the request to the AAPP team (by opening an e-SR).
IMPORTANT NOTE 1: Even if the 3rd party company is able to demonstrate the issue is on the Alcatel-Lucent
side, there is no obligation from Alcatel-Lucent to fix it (there is no official IWR established between the two
parties).
IMPORTANT NOTE 2: For case 3, Alcatel-Lucent and the Third-Party company may decide to provide a
document specifying the possible extension of the IWR by mentioning the list of releases/versions officially
supported. (Another way is to update an existing IWR with new release/version compatibility).

12.4 Technical Support access
The Alcatel-Lucent 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):
http://applicationpartner.alcatel-lucent.com
• e-Support from the Alcatel-Lucent Business Partners Web site (if registered Alcatel-Lucent Business
Partners): https://businessportal.alcatel-lucent.com click under “Let us help you” the eService Request
link
• e-mail: Ebg_Global_Supportcenter@alcatel-lucent.com
• Fax number: +33(0)3 69 20 85 85
• Telephone numbers:
Alcatel-Lucent Business Partners Support Center for countries:
Country Supported language Toll free number

France
Belgium French
Luxembourg
Germany
Austria German
Switzerland
United Kingdom
Italy
Australia
Denmark
Ireland
Netherlands +800-00200100
South Africa
Norway
English
Poland
Sweden
Czech Republic
Estonia
Finland
Greece
Slovakia
Portugal
Spain Spanish
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


Audiocodes Mediant800 V6 4 SAS OmniPCXEnterpriseR10 1 IWR

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Audiocodes Mediant800 V6 4 SAS OmniPCXEnterpriseR10 1 IWR

Uploaded by

Copyright:

Available Formats

Alcatel-Lucent Application Partner Program

ALCATEL-LUCENT MAKES NO REPRESENTATIONS, WARRANTIES OR CONDITIONS WITH RESPECT TO THE

Alcatel-Lucent Application Partner Program – Inter-working Report

Date of the tests May 17, 2012

Alcatel-Lucent’s representative Sebastien EHRHARD

Alcatel-Lucent Communication OmniPCX Enterprise

Author(s): Denis Lienhart

Edition 1: creation of the document – 17-05-2012

Passed with restrictions

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

Alcatel-Lucent Application Partner Program – Inter-working Report

Contact name: Eran Battat

Address 1: 54, route des Sartrouville

Phone: +972 3 9764288

Web address: http://www.audiocodes.com

Alcatel-Lucent Application Partner Program – Inter-working Report

2 APPLICATION INFORMATION ........................................................................................................................... 7

Alcatel-Lucent Application Partner Program – Inter-working Report

11 APPENDIX E: AAPP PROGRAM .................................................................................................................. 93

Alcatel-Lucent Application Partner Program – Inter-working Report

Alcatel-Lucent Application Partner Program – Inter-working Report

Telephone Adapter / VoIP Gateway for Analog

Application commercial name: Mediant 800

Application version: 6.40A.037.009

Interface type: SIP

2.1 Brief application description:

2.2 Seamless Interface with Legacy Enterprise Networks

2.3 SAS - Stand Alone Survivability for Service Continuity

Alcatel-Lucent Application Partner Program – Inter-working Report

Figure 1: Tests environment

Alcatel-Lucent Application Partner Program – Inter-working Report

Figure 2 : Normal Mode WAN Link UP

Figure 3: IPTouch SIP survivability WAN link Down

Alcatel-Lucent Application Partner Program – Inter-working Report

• Normal behavior (OXE LINK IS UP)

• In case of IP network failure,(SAS mode)

Alcatel-Lucent Application Partner Program – Inter-working Report

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

Alcatel-Lucent Application Partner Program – Inter-working Report

• Alcatel OmniPCX Enterprise :

3.4 Software configuration

• Alcatel Communication Platform: OmniPCX Enterprise (R10.1 - j2.501.11.c-fr-c80s1)

Alcatel-Lucent Application Partner Program – Inter-working Report

4.1 Summary of main functions supported

Features Status Comments

6.1 IP link between headquarters and remote office loss /

6.2 MEDIANT 800 used as Analog / SIP gateway

6.2.1 Analog equipment initialization, SIP registration and

6.2.2 Audio codec negotiation OK

6.2.3 Defence (call server switch over and reboot) OK

6.2.4 Basic calls OK

6.2.5 Telephonic features

Forward on busy / No Answer is not

Hold and broker call OK

Only transfer during ringing is

Feature not available on the Analog

Alcatel-Lucent Application Partner Program – Inter-working Report

IP Touch SIP authentication is not

6.3.2 Audio codec negotiation OK

6.3.3 Defence (Audiocodes equipment and IPTouch

6.3.5 Telephonic features

Forward OK Not working for PSTN calls

Broker call From the IPTouch (OXE