Professional Documents
Culture Documents
Audiocodes Mediant800-V6.4-SAS OmniPCXEnterpriseR10.1 IWR
Audiocodes Mediant800-V6.4-SAS OmniPCXEnterpriseR10.1 IWR
Audiocodes Mediant800-V6.4-SAS OmniPCXEnterpriseR10.1 IWR
Inter-Working Report
Partner: AUDIOCODES
Application type: Media Gateway
Application name: Mediant 800 (with SAS)
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, ALCATELLUCENT 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.
Tests identification
Date of the tests
Alcatel-Lucents representative
Partners representative
Sebastien EHRHARD
Eran Battat
Alcatel-Lucent Communication
Platform
Alcatel-Lucent compatibility release
Partners application version
OmniPCX Enterprise
Author(s):
Reviewer(s):
R10.1 J2.501.11.c
6.40A.037.009
Denis Lienhart
Historic
Edition 1: creation of the document 17-05-2012
Test results
Passed
Refused
Postponed
Contact name:
Title:
Eran Battat
Field Application Engineer
Address 1:
Address 2:
City:
State:
Zip:
Country:
Country code:
Phone:
Fax:
+972 3 9764288
+972 3 9764040
Web address:
E-mail:
http://www.audiocodes.com
eran.battat@audiocodes.com
LE PECQ
78230
France
TABLE OF CONTENTS
INTRODUCTION .................................................................................................................................................... 6
ARCHITECTURE ................................................................................................................................................ 8
NETWORK CONFIGURATION ........................................................................................................................... 11
HARDWARE CONFIGURATION ........................................................................................................................ 12
SOFTWARE CONFIGURATION .......................................................................................................................... 12
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
11
12
12.1
12.2
12.3
12.4
INTRODUCTION ................................................................................................................................................. 94
ESCALATION IN CASE OF CERTIFIED APPLICATION/PRODUCTS ........................................................................... 95
ESCALATION IN CASE OF NON-CERTIFIED APPLICATION/PRODUCT ..................................................................... 96
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
Application type:
Mediant 800
Application version:
6.40A.037.009
Interface type:
SIP
3 Tests environment
3.1 Architecture
Normal Mode
SAS Mode
IP address: 10.1.8.1 (first CPU role address) and 10.10.10.50 (second CPU role address)
SIP Domain name: node1slash.etesting.com
Attendant: Directory Number 31900
4645 Voice mail: Directory Number 31300, hosted on first OXE CPU
IPTouch phone: Directory Number 33015,33018
UA phone: Directory Number 33000
OXE - PSTN (ISDN T0 access): +91-44-45046242, Prefix: 66
Analog fax: directory number 33001
IP domain 6: IP address range 10.200.48.72 to 10.200.48.73.
IP domain 7: IP address 10.200.48.71 & 10.200.48.78.
Emergency number 911
Remote office:
Mediant 800
o
o
o
o
o
o
IP address: 10.200.48.73
Analog phones: Directory Numbers 65010 - FXS port 1, 65011 - FXS port 2, 65012 - FXS
port 3
IPTouch phones: Directory Numbers 33015 (IP address 10.200.48.78)
Fax: Directory Number 65013 - FXS port 4
M800 - PSTN (ISDN T0 access): +91-44-42180292 (to analog phone 65010 or IPTouch
33015 depending on the test)
Emergency number 911
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.
Status
Comments
OK
OK
OK
OK
OK
Forward
OK But
OK
Transfer
OK
Conference
NA
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)
OK
OK
OK
0 Basic calls
OK
OK
OK But
Transfer
OK
Conference
NA
Voice mail
OK
Do not disturb
OK
OK
6.4.2 Robustness
OK
The Dial tone is available only for sometime in the analog ports of M800.
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.
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)
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 1136440641 for more details.
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 nonapplicability (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.
Action
Result
. action 1
OK
. action 2
OK
. action 3
OK
. action 4
. action 5
Comment
No indication, no error
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
Step
Action
Result
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,
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.
OK
Comment
Step
Action
Result
IP link is up
Check the remote office IPTouch restart and register (in proprietary mode) to the headquarters
OXE.
Check they can receive and make calls from/to
a headquarters phone,
an analog phone (located behind the MEDIANT 800).
OK
Comment
6.2.1
6.2.1.1
Test objectives
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 proxys, DNS).
6.2.1.2
Step
Test procedure
Action
Result
The MEDIANT 800 is configured to use proxy servers 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.
OK
The MEDIANT 800 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.
OK
SIP digest authentication is activated on OXE and phone side (MEDIANT 800).
Check also that outgoing call is authenticated.
OK
Comment
6.2.2
6.2.2.1
Test objectives
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.
6.2.2.2
Test procedure
Step
Action
Result
The MEDIANT 800 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
OK
The MEDIANT 800 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
OK
The MEDIANT 800 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
OK
The MEDIANT 800 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
OK
The MEDIANT 800 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.
OK
Comment
Step
Action
Result
The MEDIANT 800 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.
OK
OK
Comment
Codec selection. The MEDIANT 800 and OXE do not have any common codec.
For example, the MEDIANT 800 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.
6.2.3
OK
Defense
6.2.3.1
Test objectives
These tests check the MEDIANT 800 defenses against perturbations and OXE Call Servers switch over.
6.2.3.2
Step
Test procedure
Action
Result
OXE Call Server CPU switch over while the analog phones behind the MEDIANT 800 are in idle.
1
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.
OK
Comment
Step
Action
Result
OXE Call Server CPU switch over while the analog phones behind the MEDIANT 800 are in
conversation with an IPTouch.
2
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 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).
The call is released.
As soon as the Call Server is running again, the analog phone is able to make and receive a call.
OK
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).
The call is released.
As soon as the Call Server is running again, the analog phone is able to make and receive a call.
OK
Check also the behavior when in communication with another analog set behind the MEDIANT 800
(call remains established).
5
After OXE Call Server Switchover try to make new call from the analog phone and check the analog
phone is able to make hold the call with IP Touch
Comment
OK
6.2.4
Basic calls
6.2.4.1
Test objectives
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.
6.2.4.2
Test procedure
Step
Action
Result
OK
2
Repeat 1 with an IPTouch.
Call from and to an UA phone.
OK
3
Repeat 1 with an UA phone.
Call from and to an analog phone.
4
OK
Comment
Step
Action
Result
Comment
5
The caller releases the incoming call to the analog phone before the callee takes the call.
Outgoing call released by the caller during ringing.
OK
6
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
NA
The callee rejects the incoming call to the analog phone during ringing.
Outgoing call rejected by the callee during ringing.
8
The callee rejects the outgoing call from the analog phone during ringing.
Call released by the analog phone.
OK
9
The analog phone releases the call after a conversation period.
Call released by the other phone.
OK
10
The other phone releases the call after a conversation period.
Incoming call presentation while already in conversation.
11
The analog phone is already in conversation and receives a new incoming call. Check the display
(new call presentation) and audio (new call signalization).
OK
12
Call is properly established.
Step
Action
Result
Comment
13
Call is properly established.
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
up the call (using the attendant soft key or going on hook).
14
OK
15
OK
6.2.5
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.
OK
Telephonic features
6.2.5.1
Test objectives
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.
6.2.5.2
Test procedure
Step
Action
Result
Comment
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.
OK
The analog phone calls a phone forwarded to a third phone. The third phone takes the call and the
conversation is established.
OK
The analog phone is forwarded on no answer to another 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.
OK
Step
Action
Result
While the analog is already in 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.
OK
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
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.
OK
The analog phone is in conversation with another phone. The other phone puts this conversation
on-hold. Check the display and on-hold music on the analog phone. Check the conversation can be
retrieved.
OK
Broker call.
8
The analog phone 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
analog phone.
OK
Comment
Step
Action
Result
Comment
The analog phone 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 display
(signalization of the transfer and back to idle state).
NA
OK
NA
Transfer in conversation.
9
The analog phone has one active conversation and another one in ringing step. Before the second
callee takes the call, the analog phone transfers its first call to this second callee. Check the new
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
The analog phone has two active conversations and initiates a conference. Check the new
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
phone to the voice mail). Check that the message is indicated on the analog phone (led, display
and/or feedback tone).
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.
OK
Step
Action
Result
The analog phone calls another phone forwarded to the voice mail. He leaves a message. Check
the interaction between the analog phone and voice mail. Listen to the message from the other
phone.
OK
Comment
15
On the analog phone the Do not Disturb is activated. When calling this set, the call is not presented
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)
16
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.
Test also with the analog phone already in conversation when the wakeup time arrives.
OK
On the analog phone the Wake Up is activated then deactivated. When the previous wake up time
arrives, nothing appends on the phone set.
Call back booked from analog phone has
issue. The conversation is not establishing
after alerts.
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
Step
Action
Result
The analog phone is in conversation. Another phone calls the analog phone and leaves an
automatic call back.
Check the call back query is taken into account and processed.
OK
Comment
19
Repeat steps 1, 3, 4, 5 and 15 but this time use the MEDIANT 800 local features possibilities.
6.2.6
Fax
6.2.6.1
Test objectives
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).
6.2.6.2
Test procedure
Step
Action
Result
Comment
The analog fax machine located behind the MEDIANT 800 sends a fax to another fax machine
located in the headquarters. Tests are performed with various contents: simple fax, complex fax
(including images), multi pages fax
OK
OK
OK
The analog fax machine located behind the MEDIANT 800 receives a fax from another fax machine
located in the headquarters. Tests are performed with various contents: simple fax, complex fax
(including images), multi pages fax
Fax sending to a PSTN fax machine
The analog fax machine located behind the MEDIANT 800 sends a fax to a fax machine located in
the PSTN network. Tests are performed with various contents: simple fax, complex fax (including
images), multi pages fax
Step
Action
Result
The analog fax machine located behind the MEDIANT 800 receives a fax from a fax machine
located in the PSTN network. Tests are performed with various contents: simple fax, complex fax
(including images), multi pages fax
OK
Comment
6.2.7
Emergency calls
6.2.7.1
Test objectives
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.
6.2.7.2
Step
Test procedure
Action
Result
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
OXE first.
Check the caller number is the remote office one (and not the headquarters one).
OK
OK
Comment
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
6.3.1.1
Test objectives
These tests check that the phones are able to register to the MEDIANT 800 with and without SIP authentication.
6.3.1.2
Test procedure
Step
Action
Result
The IP link between the Headquarters and the remote office is cut. The phone restarts and switches
to SIP mode to register to the MEDIANT 800
OK
IPTouch in SIP mode registration to the MEDIANT 800 using SIP digest authentication
NA
2
Same as 1 but with SIP digest authentication.
Comment
Registration details are shown in the
SAS/SBC Registered Users under
Status & diagnostics tab in M800
6.3.2
6.3.2.1
Test objectives
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.
6.3.2.2
Step
Test procedure
Action
Result
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 phone is configured to offer G711Alaw, G711 law, G723 and G729 (phone default behavior
which can not be changed).
The MEDIANT 800 is configured to use G711Alaw.
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
sub3
The phone is configured to offer G711Alaw, G711 law, G723 and G729 (phone default behavior
which can not be changed).
The MEDIANT 800 is configured to use G723.
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
OK
Comment
Step
Action
Result
The phone is configured to offer G711Alaw, G711 law, G723 and G729 (phone default behavior
which can not be changed).
The MEDIANT 800 is configured to use G729.
OK
Check that for a call from the IPTouch to the analog phone, the negotiated codec is G729
Check that for a call from the analog phone to the IPTouch, the negotiated codec is G729
The phone is configured to offer G711Alaw, G711 law, G723 and G729 (phone default behavior
which can not be changed).
The MEDIANT 800 is configured to use G729 and G723 (in this priority order).
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 G729
6
Repeat steps 1 and 2 with law for the MEDIANT 800 configuration.
OK
No common codecs.
OK
Comment
6.3.3
Defense
6.3.3.1
Test objectives
These tests check the IPTouch phone and MEDIANT 800 behaviors against perturbations such as phone and MEDIANT 800 reboot.
6.3.3.2
Test procedure
Step
Action
Result
MEDIANT 800 reboot while IPTouch phone in SIP mode phone in idle.
1
OK
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
is able to make and receive a call.
OK
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.
OK
3
Check that the phone registers again to the MEDIANT 800 and is able to make and receive a call.
Comment
Step
Action
Result
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
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.
OK
Comment
6.3.4
Basic calls
6.3.4.1
Test objectives
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), ...
6.3.4.2
Step
Test procedure
Action
Result
OK
Remote office IPTouch to and from remote office analog phone (behind MEDIANT 800)
OK
OK
Remote office IPTouch to and from headquarters phone (using PSTN network)
OK
4
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)
OK
Remote office IPTouch to and from PSTN user (headquarter OXE PSTN user or external PSTN
user)
OK
Remote office analog phone and fax machine (behind MEDIANT 800) to and from PSTN external
user
OK
Comment
Step
Action
Result
Comment
OK
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
office.
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).
Analog phone (behind the MEDIANT 800) located in the remote office call from and to an IPTouch
located in the headquarters (using PSTN network).
OK
Repeat steps 8 and 9 but this time the call is released by the caller while the called phone is ringing.
OK
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
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.
OK
6.3.5
Telephonic features
6.3.5.1
Test objectives
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).
6.3.5.2
Test procedure
Step
Action
Result
Comment
OK
Same as 1 but this time with an analog phone located in the remote office behind the MEDIANT
800.
OK
Step
Action
Result
Comment
For the IPTouch, only the immediate
forward is possible.
Repeat steps 1 and 2 but this time for forward on busy, forward on no answer, forward on busy / no
answer.
Same as 4 but this time with an analog phone located in the remote office behind the MEDIANT
800.
OK
OK
Step
Action
Result
Comment
OK But
Step
Action
Result
Comment
1) Analog set calls another
Analog and tries broker call with
another Analog =>OK
Same as 6 but this time with an analog phone located in the remote office behind the MEDIANT
800.
OK
2)
OK
Same as 8 but this time with an analog phone located in the remote office behind the MEDIANT
800.
NA
OK
Step
Action
Result
Comment
11
Same as 10 but this time with an analog phone located in the remote office behind the MEDIANT
800.
NA
NA
OK
IPTouch located in the remote office has activated do not disturb feature
Check for several callers:
12
13
Same as 12 but this time with an analog phone located in the remote office behind the MEDIANT
800.
14
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.
OK
Same as 14 but this time with an analog phone located in the remote office behind the MEDIANT
800.
OK
6.3.5.3
Emergency Calls
6.3.5.4
Test objectives
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.
6.3.5.5
Step
Test procedure
Action
Result Comment
Analog phone connected behind the Mediant 800 calls the emergency service
Check the call is issued using the Mediant 800 PSTN access.
Check the caller number is the remote office one (and not the heaquarters one).
OK
OK
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
Step
Action
Result Comment
Spatial redundancy, using Alternate Proxy method: Switchover to standby call server
OK
OK
OK
NT
Primary link is down. Call is made from analog FXS to IPTouch in SAS mode. During Conversation
Primary link is up and call should not cut. When goes on hook it should go to NOE mode.
OK
Detailed procedure is available in the user guide. Mediant 800 user guide can be downloaded from the
Audiocodes website.
4. BRI configuration
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
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.
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
Alcatel-Lucent Application Partner Program Inter-working Report
Copyright 2011 Alcatel-Lucent, All rights reserved
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.
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
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.
;**************
;** 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]
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
ISDNTRANSFERCAPABILITY_2 = -1
ISDNTRANSFERCAPABILITY_3 = -1
PLAYRBTONE2TRUNK_0 = 1
PLAYRBTONE2TRUNK_1 = -1
PLAYRBTONE2TRUNK_2 = -1
PLAYRBTONE2TRUNK_3 = -1
ENABLEHISTORYINFO = 1
ENABLE3WAYCONFERENCE = 1
CONFERENCECODE = '3'
ENABLEGRUU = 1
TRUNKPSTNALERTTIMEOUT_0 = 500
TRUNKPSTNALERTTIMEOUT_1 = -1
TRUNKPSTNALERTTIMEOUT_2 = -1
TRUNKPSTNALERTTIMEOUT_3 = -1
REGISTRATIONTIMETHRESHOLD = 1
ENABLESAS = 1
REGISTERONINVITEFAILURE = 1
REDUNDANTROUTINGMODE = 2
REGISTRARTRANSPORTTYPE = 0
MWISERVERTRANSPORTTYPE = 0
BCHANNELNEGOTIATIONFORTRUNK_0 = 2
BCHANNELNEGOTIATIONFORTRUNK_1 = -1
BCHANNELNEGOTIATIONFORTRUNK_2 = -1
BCHANNELNEGOTIATIONFORTRUNK_3 = -1
SIPREROUTINGMODE = 1
SASBINDINGMODE = 1
SASSURVIVABILITYMODE = 1
RemoveCallingNameForTrunk_0 = 0
RemoveCallingNameForTrunk_1 = -1
RemoveCallingNameForTrunk_2 = -1
RemoveCallingNameForTrunk_3 = -1
3WayConfNoneAllocateablePorts = 0
SetTel2IpRedirectReason = 13
SetIp2TelRedirectReason = 13
SetIp2TelRedirectScreeningInd = 3
SASINBOUNDMANIPULATIONMODE = 1
[SCTP Params]
[IPsec 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 1 = 0, 2, 2;
CallWaitingPerPort 2 = 0, 2, 3;
[ \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,
[ 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;
[ 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 ]
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 M800s
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 800s 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)
2. SIP Gateway
3. SIP Proxy
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 M800s 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
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)
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 800s ISDN BRI DDI number of the
set 33015.
5. To activate the call forward in out of service condition, we enable this parameter
b) In entity 6, discriminator selector, mapping is done between logical and real discriminator like this
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.
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
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..
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/
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
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.
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).
Supported language
France
Belgium
French
Luxembourg
Germany
Austria
German
Switzerland
United Kingdom
Italy
Australia
Denmark
Ireland
Netherlands
+800-00200100
South Africa
Norway
Poland
English
Sweden
Czech Republic
Estonia
Finland
Greece
Slovakia
Portugal
Spain
Spanish
English answer:
French answer:
German answer:
Spanish answer:
END OF DOCUMENT