Avaya CM Sip Itp

AudioCodes Mediant 2000,
MP-114 & Avaya© CM,

SIP Proxy Test Results
May 2006 Document #: LTRT-82601

SIP Interoperability Test Plan - Results Contents
Table of Contents
1 Introducing AudioCodes’ ITP .............................................................................7
1.1 Objective ...............................................................................................................7
1.2 Interoperability Test Laboratory Environment ...................................................7
1.2.1 AudioCodes’ Components ......................................................................................................7
1.2.2 Third Party Components .........................................................................................................7
1.2.3 Laboratory Topology...............................................................................................................8
1.2.4 Configuration ..........................................................................................................................9
1.3 Contact Information .............................................................................................9
1.4 Test Summary.......................................................................................................9
1.4.1 Summary of Results & Open Issues .......................................................................................9
1.4.2 AudioCodes’ Visual Intercept (VI) Records...........................................................................10
1.4.3 Avaya Bug Records ..............................................................................................................10
1.5 Recommendations & Conclusions....................................................................11
1.6 Conventions........................................................................................................11
2 Test Case List....................................................................................................13
2.1 Basic Calls ..........................................................................................................13
2.1.1 Inbound Basic to Third party phone 1 Calls ..........................................................................13
2.1.2 Inbound Basic to Third Party Phone 2 Calls .........................................................................14
2.1.3 Inbound Basic to PBX Phone................................................................................................15
2.1.4 Inbound Basic M2K to Third Party Calls ...............................................................................16
2.1.5 Basic Call – Caller ID............................................................................................................17
2.2 RTP Features – Codecs and DTMF....................................................................18
2.2.1 RTP Features – Codecs .......................................................................................................18
2.2.2 RTP Features – DTMF .........................................................................................................19
2.3 Supplementary Services ....................................................................................21
2.3.1 SIP Call Hold ........................................................................................................................21
2.3.2 Call Transfer .........................................................................................................................22
2.3.3 Call Waiting...........................................................................................................................24
2.4 Fax Calls .............................................................................................................25
2.4.1 Transparent Mode ................................................................................................................25
2.4.2 Fax T.38................................................................................................................................26
2.5 SIP Features........................................................................................................26
2.5.1 SIP Features - Registration and Authentication ....................................................................27
2.5.2 SIP Features - PRACK and Early Media...............................................................................28
2.5.3 Connection Mode Features...................................................................................................30
Appendix A – AudioCodes’ ini File ........................................................................33

Appendix B - Configuration File for Third Party Devices.....................................39
AudioCodes Confidential 3 May 2006

©
Avaya CM
List of Tables
Table 1-1: AudioCodes' Components.......................................................................................................7
Table 1-2: Third Party Components .........................................................................................................7
Table 1-3: Test Summary .........................................................................................................................9
Table 1-4: Visual Intercept (VI) Records ................................................................................................10
Table 1-5: Bug Records of Avaya ..........................................................................................................10
Table 1-6: Conventions ..........................................................................................................................11
Table 2-1: Inbound Basic to Third party phone 1 Calls ..........................................................................13
Table 2-2: Inbound Basic to Third Party Phone 2 Calls .........................................................................14
Table 2-3: Outbound Basic Calls to PBX Phone ....................................................................................15
Table 2-4: Inbound Basic M2K to Third Party Calls ...............................................................................16
Table 2-5: Basic Call – Caller ID ............................................................................................................17
Table 2-6: Codecs ..................................................................................................................................18
Table 2-7: DTMF ....................................................................................................................................19
Table 2-8: Call Hold – re-INVITE (SIP) ..................................................................................................21
Table 2-9: Call Transfer..........................................................................................................................22
Table 2-10: Call Waiting .........................................................................................................................24
Table 2-11: Transparent Mode ...............................................................................................................25
Table 2-12: Fax T.38 ..............................................................................................................................26
Table 2-13: Registration and Authentication ..........................................................................................27
Table 2-14: SIP Features - PRACK and Early Media ............................................................................28
Table 2-15: Connection Modes ..............................................................................................................30
List of Figures
Figure 1-1: Layout of the Interoperability Test Environment with Avaya Equipment ...............................8
Figure B-1: Configuring AudioCodes Products in Avaya SIP Proxy. .....................................................39
AudioCodes Interoperability Laboratory 4 Document #: LTRT-82601

SIP Interoperability Test Plan - Results Notices
Notice
This Interoperability Test Plan (ITP) presents the scenarios according to which
AudioCodes’ products are tested to determine the degree to which they’re interoperable
©
with the Avaya Communication Manager. Information contained in this document is
believed to be accurate and reliable at the time of printing. However, due to ongoing
product improvements and revisions, AudioCodes cannot guarantee accuracy of printed
material after the Date Published nor can it accept responsibility for errors or omissions.
Updates to this document and other documents can be viewed by registered Technical
Support customers at www.audiocodes.com under Support / Product Documentation.
© Copyright 2006 AudioCodes Ltd. All rights reserved.
This document is subject to change without notice.
Refer to the current release notes that may be included with your documentation or hardware
delivery.
Date Published: May-10-2006 Date Printed: May-16-2006
Tip: When viewing this manual on CD, Web site or on any other electronic
copy, all cross-references are hyperlinked. Click on the page or section
numbers (shown in blue) to reach the individual cross-referenced item
directly. To return to the point from where you accessed the cross-
reference, press Alt + ←.
Trademarks
AC logo, Ardito, AudioCoded, AudioCodes, AudioCodes logo, IPmedia, Mediant,
MediaPack, MP-MLQ, NetCoder, Stretto, TrunkPack, VoicePacketizer and VoIPerfect, are
trademarks or registered trademarks of AudioCodes Limited.
All other products or trademarks are property of their respective owners.
WEEE EU Directive
Pursuant to the WEEE EU Directive, electronic and electrical waste must not be disposed
of with unsorted waste. Please contact your local recycling authority for disposal of this
product.
Customer Support
Customer technical support and service are provided by AudioCodes’ Distributors,
Partners, and Resellers from whom the product was purchased. For Customer support for
products purchased directly from AudioCodes, contact support@audiocodes.com.
Privacy Information
Information contained in this document is confidential and may not be

disclosed without prior written agreement from an AudioCodes signatory.

©
Avaya
Interoperability Tests in General

AudioCodes’ media gateways and VoIP products have been tested and are continuously
being tested to achieve interoperability capability in a wide range of VoIP environments.
AudioCodes’ media gateways have been tested and are continuously being tested for
interoperability with the following generic VoIP environment components:
Softswitches
Call Agents
Call Managers
Proxies
Gatekeepers
IP PBXs
Standard PBXs
Soft Phones
VoIP Phones
VoIP Application Servers
Voice Mail
Unified Messaging
Media Servers/IVR (Interactive Voice Response)
Local exchange simulators
MCUs (Multipoint Conferencing Units)
MTAs (Multimedia Terminal Adaptors)
CMTSs (Cable Modem Termination Systems)
LE (Local Exchange) switches (V5.2)
Firewalls and NATs
Full details pertaining to the specific telephony companies’ products with which
AudioCodes’ Media Gateways have been proven to interoperate, and to what degree of
interoperability, are presented in the AudioCodes Interoperability List, LTRT-10000.
ITP Target Audience

The ITP is targeted at the following groups:
1. AudioCodes’ Interoperability Laboratory Engineers
2. Customers and potential customers (OEMs, carriers, enterprise, inter alia) seeking
information on how AudioCodes determines the interoperability level of its equipment.
3. AudioCodes’ sales managers, presales personnel, marketing managers, technical
support staff, product managers and R&D.
4. Parties seeking procedures to perform interoperability testing on AudioCodes’
products with their products.

SIP Interoperability Test Plan - Results 1. Introducing AudioCodes’ ITP
1 Introducing AudioCodes’ ITP

AudioCodes’ Interoperability Test Plan (ITP) lists and details which tests are conducted on
what capabilities and features (to systematically determine the interoperability level of the
©
Avaya Communication Manager (CM) tested in a SIP environment.
All subsections are to be completed as comprehensively as possible.
Note: The ITP is open, modular and flexible, depending on the requirements of
the specific interoperability project. Some test scenarios can be waived, for
example, when testing for basic-level interoperability. Conversely, testers
can invent and add additional test scenarios, depending on network
conditions/requirements and third party features/capabilities.
1.1 Objective
In this subsection, the primary objective of this interoperability test is described.
The MP-114 FXS MediaPack gateway and Mediant 2000 digital gateway Version 4.8
tested in SIP with Avaya Communication Manager (CM) and SIP proxy.
1.2 Interoperability Test Laboratory Environment

In this subsection, in Table 1-1 and Table 1-2 all the devices comprising the interoperability
test laboratory environment are described.
1.2.1 AudioCodes’ Components

Table 1-1: AudioCodes' Components
Product IP Address Final Version Tested

1 MP-114 FXS 149.49.140.240 V.4.8A.014.006
2 Mediant 2000 149.49.140.200 V.4.8A.014.006
1.2.2 Third Party Components

Table 1-2: Third Party Components
Company & Product IP Address Final Version Tested

1 Avaya Comunication Manager 149.49.140.179 CM - R013x.00.0.340.3
S8300
2 Avaya SIP Proxy 149.49.140.210 SES - SES03.1-03.1.018.0
3 Avaya Media Gateway G350 149.49.140.176

©
Avaya
1.2.3 Laboratory Topology

Figure 1-1 shows the layout of the interoperability test environment.
Figure 1-1: Layout of the Interoperability Test Environment with Avaya Equipment
(Refer to Figure 1-1)
Describe (in words) the layout of the test environment shown in Figure 1-1, including
configured IP addresses and phone numbers of the components.
Avaya Communication Manager (CM) is an integrated solution that can run on a

variety of media servers, on a distributed network of media gateways and on a
wide range of analog, digital, and IP-based communication devices.
The CM includes the Media Server (S8300), Gatekeeper, Media
Gateway (G350), analog and digital cards, etc.
AudioCodes’ MP-114 MediaPack (149.49.140.240) registered to Avaya SIP proxy
(149.49.140.210) and makes calls to one of three different phone types:
1. Avaya SIP IP Phone – extension 3000.
2. Avaya H.323 IP Phone - extension 1000, connected to the CM via an H.323 trunk
3. Analog Phone – extension 1005, connected to the CM via an analog card
All call signaling was managed by the SIP Proxy and the CM, connected with a SIP
trunk between them

All RTP (voice) streams go through the media gateway (149.49.140.176).

AudioCodes’ Mediant 2000 (149.49.140.200) registered to Avaya SIP Proxy. Mediant
2000 has loop back in its E1 trunks. The MP-114 routes its calls to the Mediant 2000
which redirects them to the Avaya SIP Proxy.
1.2.4 Configuration
Refer to Appendix A – AudioCodes’ ini File and Appendix B - Configuration File for
Third Party Devices on page 33 and 39 respectively.
1.3 Contact Information

Company Name E-mail Position
Interoperability
1 AudioCodes Nir Zvulun Nir.Zvulun@audiocodes.com
Team Manager
Interoperability
2 AudioCodes Itzik Shnitzer Itzik.Shnitzer@audiocodes.com
Engineer
Technical
3 Avaya Benaroya Yuval benaroya@avaya.com
Manager
Global Technical
4 Avaya Nir Halmut nhalmut@avaya.com
Services
1.4 Test Summary

When you’ve completed the test session, complete Table 1-3. This table and all scenario
tables are headed by these columns:
FAILED = The tested feature is supported by all parties’ devices and the
appropriate configuration was performed, but the test failed due to
(for example) proprietary implementation of the feature by the third
party.
N/T = Not Tested. The feature is supported by all parties’ devices
according to product specifications, but the scenario was not run due
to (for example) scope constraints, etc.
N/S = Not Supported. The feature presently isn’t supported by one of the
parties’ devices, but future support is possible.
Table 1-3: Test Summary

Section PASSED FAILED N/T or N/S Issues #
(1) Basic Calls 35 0 6 41
(2)Codec and DTMF 20 0 3 23
(3) Supplementary services 9 1 5 15
(4) Fax calls 2 0 10 12
(6) SIP Features 13 2 8 23
TOTAL: <79> <3> <32> <114>
PASS FAIL N/T or N/S Total Issues
1.4.1 Summary of Results & Open Issues

Indicate which test scenarios failed.

©
Avaya
1. Call Waiting scenarios failed.

Example scenario: AC1 in call with third party phone 2, PBX phone calls AC1 and
disconnects.
When the PBX phone calls the second call to AC1, AC1 replies with ‘182 Queued’
then the SIP proxy sends a ‘Cancel’ request. (Avaya SIP proxy failure).
List any unusual or unwanted behavior.

When Avaya sends a SIP message and inserts an extra empty line at the end of
the SDP, AudioCodes does not accept it. This problem was fixed by AudioCodes’
R&D (see the correct new version in Table 1-4 below (VI records)).
When working with TCP transport type, the first call after registration failed; the call
after the first call passed.
AudioCodes’ R&D fix this issue; see the correct new version in Table 1-4 below (VI
records).
1.4.2 AudioCodes’ Visual Intercept (VI) Records

This subsection is targeted specifically at AudioCodes’ R&D (Research & Development)
and QA (Quality Assurance) divisions. In Table 1-4, list the VI records that were opened
during the interoperability session and which describe errors (and unusual or unwanted
behaviors) that require R&D fixes and a new version.
Table 1-4: Visual Intercept (VI) Records

Related Test
VI Number New Version Numbers Remarks
Scenario
37331 4.80A.008.006 This was related for many
test scenarios – only after
this was solved was the test
continued.
39256 Table 2-22 tests 4.80A.015.004
5,8
1.4.3 Avaya Bug Records

In Table 1-6, list the third party bug records that were opened during the interoperability
session and which describe errors (and unusual or unwanted behaviors) that require third
party R&D fixes and a new version.
Table 1-5: Bug Records of Avaya

Related Test
New third Party Version Remarks
Scenario
Section 2.3.3 (Call
Waiting scenarios)

1.5 Recommendations & Conclusions

Briefly summarize the test results.
Most of the test was passed successfully (except the call waiting scenarios).
It is recommended to fix the call waiting problem (the responsibility of Avaya) and to
complete the full interoperability test cases.
The Avaya SIP proxy is not supported in the G.726 coder and in fax T.38
Write down your general impressions of the third party devices.

AudioCodes’ SIP Media Gateways and Avaya SIP solutions were successfully
deployed together. It was straightforward to configure AudioCodes’ products in
Avaya SIP proxy. There was no special configuration in the implementation with
AudioCodes’ products.
1.6 Conventions
Complete the column ‘Refers to’ in Table 1-6. If your interoperability test requires it, add
more conventions (for example, Third Party Phone 2) and define what they refer to.
Table 1-6: Conventions
Convention Refers to
1 AC1 MP-114 User
2 M2K Mediant 2000
3 Third Party Phone 1 Avaya SIP IP Phone User
4 Third Party Phone 2 Avaya H.323 IP Phone User
5 CM analog phone user connected to analog
PBX Phone
card in the CM
6 Third Party Server Avaya SIP Proxy

©
Avaya
Reader’s Notes

SIP Interoperability Test Plan - Results 2. Test Case List
2 Test Case List

2.1 Basic Calls
The purpose of this section is to verify that basic calls can be originated and terminated by
AudioCodes’ devices. This section includes tests for inbound and outbound origination,
termination, call failure scenarios, stability, and Caller ID. The tests can be conducted with
any coder that the tester chooses. The calls can be direct (peer to peer) or, in the case of a
third party server, should be routed through it.
2.1.1 Inbound Basic to Third party phone 1 Calls

Table 2-1: Inbound Basic to Third party phone 1 Calls
# Description Expected Results Result Remarks

1 AC to third party phone 1, AC1 1. Third party phone 1 is alerted Pass
disconnects after answer 2. AC1 receives audible ring back
3. Third party phone 1 is able to
answer the call
4. Two-way voice path is
established
5. The call is released when AC1 is
on-hooked
disconnects before answer 2. AC1 receives audible ring back
on hooked
4. Third party phone 1 stops ringing
3 AC1 to third party phone 1, third 1. Third party phone 1 is alerted Pass
party phone 1 disconnects after 2. AC1 receives audible ring back
answer
answer the call
established
5. The call is released when the
third party phone 1 is on-hooked
4 Third party phone 1 to AC1, third 1. AC1 is alerted Pass
party phone 1 disconnects after 2. Third party phone 1 receives
answer audible ring back
3. AC1 is able to answer the call
established
5 Third party phone 1 to AC1, third 1. AC1 is alerted Pass
party phone 1 disconnects before 2. Third party phone 1 receives
4. AC1 stops ringing

©
Avaya

6 Third party phone 1 to AC1, AC1 1. AC1 is alerted Pass
disconnects after answer 2. Third party phone 1 receives
audible ring back
established
on-hooked
7 AC1 to busy third party phone 1 1. AC receives a busy tone Pass
on-hooked
8 Third party phone 1 to busy AC1 1. Third party phone 1 receives a Pass
busy tone
2.1.2 Inbound Basic to Third Party Phone 2 Calls

Table 2-2: Inbound Basic to Third Party Phone 2 Calls

answer the call
established
on-hooked
on hooked
3 AC1 to third party phone 2, third 1. Third party phone 2 is alerted Pass
party phone 2 disconnects after 2. AC1 receives audible ring back
answer
answer the call
established
4 Third party 2 phone to AC1, third 1. AC1 is alerted Pass
party phone 2 disconnects after 2. Third party phone 2 receives
established


third party 2 phone is on-hooked
5 third party phone 2 to AC1, third 1. AC1 is alerted Pass
party phone 2 disconnects before 2. Third party phone 2 receives
4. AC1 stops ringing
6 third party phone 2 to AC1, AC1 1. AC1 is alerted Pass
disconnects after answer 2. Third party phone 2 receives
audible ring back
established
on-hooked
7 AC1 to busy third party phone 2 1. AC receives a busy tone Pass
on-hooked
8 Third party phone 2 to busy AC1 1. Third party phone 2 receives a Pass
busy tone
2.1.3 Inbound Basic to PBX Phone

Table 2-3: Outbound Basic Calls to PBX Phone

1 AC1 to PBX phone, AC1 disconnects 1. PBX phone is alerted Pass
after answer 2. AC1 receives audible ring back
3. PBX phone is able to answer the
call
established
on-hooked
2 AC1 to PBX phone, AC1 disconnects 1. PBX phone is alerted Pass
before answer 2. AC1 receives audible ring back
on-hooked
4. PBX phone stops ringing
3 AC1 to PBX phone, PBX phone 1. PBX phone is alerted Pass
call
established

©
Avaya

PBX phone is on-hooked
4 PBX phone to AC1, PBX phone 1. AC1 is alerted Pass
disconnects after answer 2. PBX phone receives audible ring
back
call
established
5 PBX phone to AC1, PBX phone 1. AC1 is alerted Pass
disconnects before answer 2. PBX phone receives audible ring
back
4. AC1 phone stops ringing
6 PBX phone to AC1, AC1 disconnects 1. AC1 is alerted Pass
after answer 2. PBX phone receives audible ring
back
established
on-hooked
7 AC1 to busy PBX phone 1. AC1 receives a busy tone Pass
2. The call is released when AC is
on-hooked
8 PBX phone to busy AC1 1. PBX phone receives a busy tone Pass
2.1.4 Inbound Basic M2K to Third Party Calls

Table 2-4: Inbound Basic M2K to Third Party Calls

1 AC1 through M2K to third party 1. Third party phone 1 is alerted Pass
phone 1, AC1 disconnects after 2. AC1 receives audible ring back
answer
answer the call
established
on-hooked
2 AC through M2K to third party phone 1. Third party phone 1 is alerted Pass
1, AC1 disconnects before answer 2. AC1 receives audible ring back
on hooked


3 AC1 through M2K to third party 1. Third party phone 2 is alerted Pass
phone 2, AC1 disconnects after 2. AC1 receives audible ring back
answer
answer the call
established
on-hooked
4 AC through M2K to third party phone 1. Third party phone 2 is alerted Pass
2, AC1 disconnects before answer 2. AC1 receives audible ring back
on hooked
5 AC1 through M2K to PBX phone, 1. PBX phone is alerted Pass
AC1 disconnects after answer 2. AC1 receives audible ring back
3. PBX Phone is able to answer the
call
established
on-hooked
6 AC through M2K to PBX phone, AC1 1. PBX phone is alerted Pass
on hooked
4. PBX phone stops ringing
7 AC1 through M2K to busy third party 1. AC1 receives a busy tone Pass
phone 1 2. The call is released when AC1 is
on-hooked
8 AC1 through M2K to busy third party 1. AC1 receives a busy tone Pass
phone 2 2. The call is released when AC1 is
on-hooked
9 AC1 through M2K to busy PBX 1. AC1 receives a busy tone Pass
phone 2. The call is released when AC1 is
on-hooked
2.1.5 Basic Call – Caller ID

Table 2-5: Basic Call – Caller ID

1 AC1 calls AC2, Caller ID displayed Caller ID of AC1 shown to AC2 N/T
2 PBX phone calls AC1, Caller ID Caller ID of PBX phone shown to N/T
displayed AC1
3 third party phone 1 calls AC1, Caller Caller ID of third party phone 1 N/T
ID displayed shown to AC1
4 AC1 call third party phone 1, Caller ID Caller ID of AC1 shown to third Pass

©
Avaya

displayed party 1 phone
5 AC1 call third party phone 2, Caller ID Caller ID of AC1 shown to third Pass
displayed party phone 2
6 Caller ID restricted: AC1 calls AC2, Note: This configuration should be N/T
Caller ID not displayed performed in AudioCodes’ device
Caller ID of AC1 not shown to AC2
7 Caller ID restricted: AC1 calls third Note: This configuration should be N/T
party phone, Caller ID not displayed performed in AudioCodes’ device
Caller ID of AC1 not shown to third
party phone
8 Caller ID restricted: third party phone Note: This configuration should be N/T
calls AC1, Caller ID not displayed performed in third party phone
device
Caller ID of third party phone not
shown to AC1
2.2 RTP Features – Codecs and DTMF

This section tests the capability of the system to perform codec negotiation and to establish
two-way voice pass with various codecs. The section also tests the system’s capability of
sending in-band and out-of-band DTMF or to negotiate from RFC 2833 to in-band DTMF, if
the remote device does not support out-of-band DTMF. In each test, configure
AudioCodes’ device with the relevant codec or DTMF type according the test case.
2.2.1 RTP Features – Codecs

This section exemplifies test scenarios in which AC1 calls AC2. Perform the same test
scenarios using a PBX phone and a third party phone instead of AC2.
Table 2-6: Codecs

# Description Expected Result Result Remarks
1 AC1 to third party phone 1 with coder Two-way voice path is established Pass
G.711 A-Law in G.711alaw
Verify voice quality.
G.711 µ-Law in G.711ulaw
G.729 in G.729
G.723 in G.723.
5 AC1 to third party phone 1 with coder Two-way voice path is established N/S Avaya Sip
G.726 in G.726. Proxy not
Verify voice quality Support
G726
G.711 A-Law in G.711alaw


G.711 µ-Law in G.711ulaw
G.729 in G.729
G.723 in G.723.
10 AC1 to PBX Phone with coder G.711 Two-way voice path is established Pass
A-Law in G.711alaw
µ-Law in G.711ulaw
in G.729
in G.723.
2.2.2 RTP Features – DTMF

Perform each test scenario in Table 2-7 twice:
1. After AC1 establishes the call
2. After AC1 receives the call
Table 2-7: DTMF

1 DTMF transport from AC1 to third DTMF pass-through RFC 2833 Pass
party phone 1 (RFC 2833) RTP telephone event
Verify precise DTMF detection,
including fast digit dialing
DTMF transport from AC1 to third DTMF pass-through RFC 2833 Pass
party phone 2 (RFC 2833) RTP telephone event
Verify precise DTMF detection,
including fast digit dialing
2 DTMF transport from AC1 supporting 1. AC1 declares its capability for an N/T
RFC 2833. AC2 doesn’t support RFC 2833 RTP telephone event.
RFC 2833 2. AC2 replies without an RTP
telephone event
3. DTMF passes in-band transport
3 DTMF transport from AC1 to PBX DTMF passes through an RFC Pass
phone (RFC 2833) 2833 RTP telephone event
Verify DTMF digit quality, including
fast digit dialing

©
Avaya

4 DTMF transport from PBX phone to DTMF passes through an RFC Pass
AC1 (RFC 2833) 2833 RTP telephone event
fast digit dialing
5 DTMF transport from third party phone DTMF passes through an RFC Pass
1 to AC1 (RFC 2833) 2833 RTP telephone event
fast digit dialing
6 DTMF transport from third party phone DTMF passes through an RFC Pass This test
2 to AC1 phone (RFC 2833) 2833 RTP telephone event scenario is
Verify DTMF digit quality, including applicable
fast digit dialing only if
RTP isn’t
sent peer
to peer.
7 AC1 to AC2, in-band DTMF (G.711) DTMF passes in-band G.711 N/T This test
and vice versa* transport scenario is
applicable
only if
RTP isn’t
sent peer
to peer.
8 AC1 to PBX phone, in-band DTMF DTMF passes in-band G.711 Pass This test
(G.711) and vice versa transport scenario is
applicable
only if
RTP isn’t
sent peer
to peer.
9 third party phone to AC1, in-band DTMF passes in-band G.711 Pass
DTMF (G.711) and vice versa transport

2.3 Supplementary Services

This section tests the capability of the AudioCodes device to perform and manage
supplementary services like Hold, Transfer, Forward and Waiting calls.
In this section, enable each service’s corresponding parameter either from the Web
Interface or via the ini file.
2.3.1 SIP Call Hold

The Hold is performed by pressing the hook flash. Two methods to hold a call can be
performed using AudioCodes’ SIP gateways:
1. By sending a Re-INVITE with the IP address 0.0.0.0 or ‘a=sendonly’ in the SDP.

2. By sending an INFO message and the third party server is responsible for holding the
call.
This section tests the capability of the system to hold the call using these two methods.
2.3.1.1 SIP Call Hold using Re-Invite

Configure the gateway for call hold – enabled
Table 2-8: Call Hold – re-INVITE (SIP)

1 AC1 to third party phone 1, AC1 1. Establish a call and a two-way Pass
holds call and reconnects voice path between AC1 and the
third party phone 1
2. AC1 presses hook flash and
receives a dial tone
3. Third party phone 1 receives
MOH, if available
reconnects to the third party
phone 1 with a two-way voice
path
on-hooked
2 AC1 to third party phone 2, AC1 1. Establish a call and a two-way Pass
holds call and reconnects voice path between AC1 and the
third party phone 2
3. Third party phone 2 receives
MOH, if available
reconnects to the third party
phone 2 with a two-way voice
path
on-hooked
3 AC1 to PBX Phone, AC1 holds call 1. Establish a call and a two-way Pass
and reconnects voice path between AC1 and the
PBX phone
3. PBX phone receives MOH, if

©
Avaya

available
reconnects to the PBX phone
with a two-way voice path
on-hooked
2.3.2 Call Transfer

This section tests the capability of transferring a call to another user. The transfer can be
attended or unattended. Configure the gateway to enable call transfer and enable call hold.
In this section, users should hold the call in one of the options mentioned above.
Thereafter, call transfer should be activated and tested.
Table 2-9: Call Transfer

1 AC1 to PBX Phone, AC1 1. AC1 and PBX phone converse Pass
unattended transfer PBX phone to 2. AC1 presses flash and receives
third party phone 1 a dial tone
3. PBX phone receives an MOH, if
available
4. AC1 calls third party phone 1,
AC1 receives ring back. third party
phone 1 is alerted
5. AC1 on-hooks
6. Third party phone 1 continues
being alerted
7. Third party off-hooks and
converses with PBX phone
2 AC1 to AC2, AC2 unattended 1. AC1 and AC2 converse in G.711 N/T
transfer to AC3 2. AC2 presses flash and receives
AC1 – G.711, G.729 a dial tone
AC2 - G.711, G.729 3. AC1 receives an MOH, if
AC3 – G.729 available
4. AC2 calls AC3, AC2 receives
ring back. AC3 is alerted.
5. AC2 on-hooks
6. AC3 continues being alerted
7. AC3 off-hooks and converses
with AC1 in G.729
3 AC1 to third party phone 1, AC1 1. AC1 and third party phone 1 Pass
unattended transfer to third party converse
phone 2 2. AC1 presses flash and receives
a dial tone
3. Third party phone 1 receives an
MOH, if available
AC1 receives ring back. third
party phone 2 is alerted.
5. AC1 on-hooks
6. Third party phone 2 continues to


be alerted
7. Third party phone 2 off-hooks
and converses with third party
phone 1
unattended transfer to third party converse
a dial tone
MOH, if available
5. AC1 on-hooks
6. Third party phone 1 continues to
be alerted
7. Third party phone 1 off-hooks
and converses with third party
phone 2
5 AC1 to PBX Phone, AC1 attended 1. AC1 and PBX Phone converse Pass
transfer to third party phone 1 2. AC1 presses flash and receives
a dial tone
3. PBX Phone receives an MOH, if
available
party phone 1 is alerted
5. Third party phone 1 answers
6. AC1 and third party phone 1
converse
7. AC1 on-hooks
8. PBX Phone converses with third
party phone 1
6 AC1 to AC2, AC2 attended transfer 1. AC1 and AC2 converse on N/T
to AC3 G.711
AC1 – G.711, G.729 2. AC2 presses flash and receives
AC2 - G.711, G.729 a dial tone
AC3 – G.729 3. AC1 receives an MOH, if
available
4. AC2 calls AC3, AC2 receives
ring back. AC3 is alerted.
5. AC3 answers.
6. AC2 and AC3 converse on
G.729
7. AC2 on-hooks.
8. AC1 converses with AC3 on
G.729
7 AC1 to third party phone 1, AC1 1. AC1 and the third party phone 1 Pass
attended transfer to third party converse
a dial tone

©
Avaya

MOH, if available
5. Third party phone 2 answers,
AC1 and third party phone 2
converse
6. AC1 on-hooks
7. third party phone 2 converses
with the third party phone 1
attended transfer to third party converse
a dial tone
MOH, if available
5. Third party phone 1 answers,
AC1 and third party phone 1
converse
6. AC1 on-hooks
7. Third party phone 1 converses
with third party phone 2 phone
2.3.3 Call Waiting

The Call Waiting feature enables gateways to accept an additional (second) call on busy
endpoints. This section tests the capability of accepting an additional (second) call,
answering or ignoring this waiting call, and the capability of playing the call waiting
indicator. Configure the gateway to enable call waiting.
Table 2-10: Call Waiting

1 AC1 in call with third party phone 2, 1. AC1 and third party phone 2 Fail When
PBX Phone calls AC1 and converse PBX
disconnect 2. PBX Phone calls AC1, PBX Phone call
Phone receives call waiting ring the
back tone and AC1 has Call second
Waiting Indication (CWI) call to
AC1, AC1
3. PBX Phone on-hooks
reply with
4. AC1 and third party phone 2 “182
continue to converse and CWI Queued”
is stopped then the
Sip Proxy
send
“Cancel”
request
2 AC1 in call with AC2, AC3 calls 1. AC1 and AC2 converse N/T
AC1, AC1 holds AC2 and answers 2. AC3 calls AC1, AC3 receives a

AC3 and back to AC2 call waiting ring back tone and
AC1 has a CWI
3. AC1 presses flash, AC2 has
MOH if available
4. AC1 and AC3 converse
5. AC1 presses flash, AC3 has an
MOH if available
3 AC1 in call with AC2, PBX phone 1. AC1 and AC2 converse N/T
calls AC1, AC1 holds AC2 and 2. PBX phone calls AC1, PBX
answers PBX phone and back to phone receives a call waiting ring
AC2 back tone and AC1 has a CWI
MOH if available
4. AC1 and the PBX phone
converse
5. AC1 presses flash, PBX phone
has MOH if available
4 AC1 in call with AC2, third party 1. AC1 and AC2 converse N/T
phone calls AC1, AC1 holds AC2 2. Third party phone calls AC1,
and answers third party phone and third party phone receives a call
back to AC2 waiting ring back tone and AC1
has a CWI
MOH if available
4. AC1 and third party phone
converse
5. AC1 presses flash, third party
phone has an MOH if available
2.4 Fax Calls

This section tests the fax capabilities of the system.
2.4.1 Transparent Mode

Configure the gateway for Fax Signaling Method - Transparent Mode.
Table 2-11: Transparent Mode

1 AC1 to PBX phone, Fax, G.711 The fax is sent successfully Pass
2 PBX phone to AC1, Fax, G.711 The fax is sent successfully Pass
3 AC1 to AC2, Fax, fallback to G.711 1. Configure both AC1 & AC2 for N/T
G.723 voice coder and also for
fax fallback to G.711.
2. The fax is sent successfully.
4 AC1 to PBX phone, Fax, fallback to 1. Configure both AC1 & the PBX N/T
G.711 phone for G.723 voice coder and
also for fax fallback to G.711.

©
Avaya

5 PBX phone to AC1, Fax, fallback to 1. Configure both AC1 & the PBX N/T
G.711 phone for G.723 voice coder and
also for fax fallback to G.711.
6 AC1 to third party phone, Fax, 1. Configure both AC1 & the third N/T
fallback to G.711 party phone for G.723 voice
coder and also for fax fallback to
G.711.
7 third party phone to AC1, Fax, 1. Configure both AC1 & the third N/T
fallback to G.711 party phone for the G.723 voice
coder and also for fax fallback to
G.711.
2.4.2 Fax T.38

Configure the gateway for Fax Signaling Method – T.38 relay. These tests should be
conducted using Fax Generation 2 and, if required, Fax Generation 3 (V.34) as well.
Table 2-12: Fax T.38

1 AC1 to AC2, Fax T.38 T.38 is negotiated N/T
The fax is sent successfully.
2 AC1 to PBX phone, Fax T.38 T.38 is negotiated N/S T.38 Not
The fax is sent successfully. supported
by Avaya
SIP Proxy
3 PBX phone to AC1, Fax T.38 T.38 is negotiated N/S T.38 Not
The fax is sent successfully. supported
by Avaya
SIP Proxy
4 AC1 to third party phone, Fax T.38 T.38 is negotiated N/T
5 third party phone to AC1, Fax T.38 T.38 is negotiated N/T
2.5 SIP Features

This section verifies gateway registration and authentication capabilities. The tests in this
section apply only to SIP devices that register their location to a third party server.
This section also covers testing SIP features such as early media, PRACK, SIP out-of-
band DTMF transmission using SIP INFO and Notify commands, and testing SIP
connection modes (UDP, TCP and TLS).
Apart from the list below, each of the test scenarios defined above (basic call, DTMF, Fax,
Coder, etc.) should also be tested if a SIP Proxy is utilized in the interoperability
environment.
Configure the gateway to use SIP Proxy and enabled registration.

2.5.1 SIP Features - Registration and Authentication

Table 2-13: Registration and Authentication

1 AC Registration without 1. AC sends a SIP REGISTER Pass
Authentication. message to the third party server
2. A successful response is sent to
AC.
2 AC Authenticated on Registration 1. AC sends a SIP REGISTER Pass
message to the third party server.
2. The third party server prompts AC
for authentication (returns SIP
401).
3. AC resends the SIP REGISTER
message with authentication
parameters.
AC.
3 M2K Authenticated on Registration 1. M2K sends a SIP REGISTER Pass
2. The third party server prompts
M2K for authentication (returns
SIP 401).
3. M2K resends the SIP REGISTER
parameters.
M2K.
4 AC Re-Registration (Registration 1. Define the Registration Time of N/T
Time in gateway more than the AudioCodes device as more
Registration Time in third party than the Registration Time that is
server) defined in the third party server.
2. Verify that the AC device re-
registers in the third party server
every period of time defined by
the third party server and
expressed in the 200OK response
for REGISTER messages.
5 AC Re-Registration (Registration 1. Define the Registration Time of N/T
Time in gateway less than the AudioCodes device as less
Registration Time in third party than the Registration Time that
server) is defined in the third party server.
2. Verify that the AC device re-
registers in the third party server
every period of time defined by
the third party server and
expressed in the 200OK response
for REGISTER messages.
6 AC Authenticated on re-INVITE 1. AC sends a SIP INVITE message Pass
to the third party server.
2. The third party server prompts AC
for authentication (returns SIP

©
Avaya

407).
3. AC resends the SIP INVITE
parameters.
AC.
7 M2K Authenticated on re-INVITE 1. M2K sends a SIP INVITE Pass
2. The third party server prompts
M2K for authentication (returns
SIP 407).
3. M2K resends the SIP INVITE
parameters.
M2K.
2.5.2 SIP Features - PRACK and Early Media

Table 2-14: SIP Features - PRACK and Early Media

1 AC1 to third party with PRACK 1. Configure the gateway for PRACK Pass
request mode enabled
2. Establish a call from AC1 to third
party
3. Verify that a PRACK request is
sent by the AC1 gateway and
a 200 OK response from the
server.
2 AC1 to AC2 with Early media. 1. Enable early media in the N/T
gateways
2. Establish a call from AC1 to AC2
3. Verify that AC2 sends a 183
Session Progress response with
SDP (instead of 180 Ringing),
following the media stream to be
set up prior to the answering of
the call.
4. Verify that the call was established
correctly
3 AC1 to PBX phone with Early media. 1. Enable early media in the gateway Pass
2. Establish a call from AC1 to the
PBX phone
3. Verify that the PBX phone
sends a 183 Session Progress
response with SDP (instead of
180 Ringing), following the media
stream to be set up prior to the
answering of the call.


correctly
4 AC1 to third party phone 1 with Early 1. Enable early media in the gateway Pass
media. 2. Establish a call from AC1 to the
third party phone 1
3. Verify that the third party phone 1
sends a 183 Session Progress
response with SDP (instead of
180 Ringing), following the media
stream to be set up prior to the
answering of the call.
correctly
5 AC1 to third party phone 2 with Early 1. Enable early media in the gateway Pass
media. 2. Establish a call from AC1 to the
third party phone 2
3. Verify that the third party phone 2
sends a 183 Session
Progress response with SDP
(instead of 180 Ringing),
the call.
correctly
5 PBX phone to AC1 with Early media. 1. Enable early media in the gateway Pass
2. Establish a call from the PBX
phone to AC1
the call.
4. Verify that the call was
established correctly
6 third party phone 1 to AC1 with Early 1. Enable early media in the gateway Pass
media. 2. Establish a call from the third party
phone 1phone to AC1
the call.
correctly

©
Avaya
2.5.3 Connection Mode Features

SIP defines several methods for connection modes:
1. Over a UDP channel
2. Over a TCP channel
3. Over a TLS channel
Following are suggested test scenarios. Apart from the list below, each of the test
scenarios defined above (basic call, DTMF, Fax, Coder, etc.) should be tested in each
required connection mode.
Table 2-15: Connection Modes

1 AC1 to AC2 using UDP connection 1. Enable UDP connection on both N/T
AC devices.
3. Verify that the call was
established correctly
2 AC1 to AC2 using TCP connection 1. Enable TCP connection on both N/T
AC devices.
3. Verify that the call was correctly
established in a TCP connection
3 AC1 to AC2 using TLS connection 1. Enable TLS connection on both N/T
AC devices.
established in a TLS connection
4 AC1 to PBX phone using UDP 1. Enable UDP connection on both Pass
connection AC1 device and PBX.
PBX phone
established in a UDP connection
5 AC1 to PBX phone using TCP 1. Enable TCP connection on both Fail Please
connection AC1 device and the PBX phone. see
2. Establish a call from AC1 to the unusual
PBX phone or
3. Verify that the call was correctly unwanted
established in a TCP connection behaviors
in
paragraph
1.4.1
6 AC1 to PBX phone using TLS 1. Enable TLS connection on both N/T
connection the AC1 device and the PBX
phone.
PBX phone
established in a TLS connection
7 AC1 to third party phone using UDP 1. Enable UDP connection on both Pass
connection the AC1 device and the third party
phone.


third party phone
established in a UDP connection
8 AC1 to third party phone using TCP 1. Enable TCP connection on both Fail Please
connection the AC1 device and the third party see
phone. unusual
2. Establish a call from AC1 to the or
third party phone unwanted
behaviors
in
established in a TCP connection
paragraph
1.4.1
9 AC1 to third party phone using TLS 1. Enable TLS connection on both N/T
connection the AC1 device and the third party
phone.
third party phone
established in a TLS connection.

©
Avaya
Reader’s Notes

SIP Interoperability Test Plan - Results Appendix A – AudioCodes’ ini File
Appendix A – AudioCodes’ ini File

Copy and paste under this appendix the contents of AudioCodes’ ini files. Additionally,
discuss any special configuration issues.
MP-114 – Configuration File
;**************
;** Ini File **
;**************
;Board: MP-114 FXS

;Serial Number: 389341
;Slot Number: 1
;Software Version: 4.80A.014.006
;Board IP Address: 149.49.140.240
;Board Subnet Mask: 255.255.255.0
;Board Default Gateway: 149.49.140.1
;Ram size: 32M Flash size: 8M
;Num DSPs: 1 Num DSP channels: 4
;Profile: NONE
;------------------------------
[SYSTEM Params]
SyslogServerIP = 149.49.140.245
EnableSyslog = 1
[BSP Params]
PCMLawSelect = 3
RoutingTableHopsCountColumn = 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0
[ATM Params]
[Analog Params]
FXSLoopCharacteristicsFilename = 'MP11x10-1-fxs.dat'
CallProgressTonesFilename = 'usa_tones_11.dat'
[ControlProtocols Params]
[MGCP Params]

©
Avaya
[MEGACO Params]
EP_Num_0 = 0
EP_Num_1 = 1
EP_Num_2 = 0
EP_Num_3 = 0
EP_Num_4 = 0
[SS7 Params]
[Voice Engine Params]
IdlePCMPattern = 85
RFC2833PayloadType = 127
[WEB Params]
LogoWidth = '339'
[SIP Params]
LOCALSIPPORT = 5060
PLAYRBTONE2IP = 0
REGISTRATIONTIME = 3600
SIPT1RTX = 500
SIPT2RTX = 4000
ISPROXYUSED = 1
ISREGISTERNEEDED = 1
SIPDESTINATIONPORT = 5060
PLAYRBTONE2TEL = 2
DETFAXONANSWERTONE = 0
CHANNELSELECTMODE = 0
GWDEBUGLEVEL = 5
ENABLERPIHEADER = 0
ENABLEEARLYMEDIA = 1
ISUSERPHONE = 1
SIPSESSIONEXPIRES = 0
PROXYNAME = '149.49.140.210'
SIPGATEWAYNAME = '149.49.140.210'
PRACKMODE = 0
ALTROUTINGTEL2IPMODE = 0
SIPMAXRTX = 7
ASSERTEDIDMODE = 0
ISUSERPHONEINFROM = 0
ADDTON2RPI = 1
USESOURCENUMBERASDISPLAYNAME = 0

MINSE = 90
IPALERTTIMEOUT = 180
ISFAXUSED = 0
SIPTRANSPORTTYPE = 0
TCPLOCALSIPPORT = 5060
TLSLOCALSIPPORT = 6061
ENABLESIPS = 0
USERAGENTDISPLAYINFO = ''
SESSIONEXPIRESMETHOD = 0
USEDISPLAYNAMEASSOURCENUMBER = 0
USESIPTGRP = 0
SIPSUBJECT = ''
CODERNAME = g711Alaw64k,20,$$,$$,0
CODERNAME = g711Ulaw64k,20,$$,$$,0
CODERNAME = g729,20,$$,$$,0
CALLERDISPLAYINFO0 = 3000,0
TRUNKGROUP = 1-1,3006,0
PROXYIP = 149.49.140.210
AUTHENTICATION_0 = 3006,123456
TXDTMFOPTION = 4
[VXML Params]
[IPsec Params]
[Audio Staging Params]
[PSTN-SDH Params]
Mediant 2000 – Configuration File
;**************
;** Ini File **
;**************
;Board: TrunkPack 1610

;Serial Number: 284560
;Slot Number: 1
;Software Version: 4.80A.014.006
;Board IP Address: 149.49.140.200
;Board Subnet Mask: 255.255.255.0
;Board Default Gateway: 149.49.140.1
;Ram size: 64M Flash size: 8M
;Num DSPs: 12 Num DSP channels: 60

©
Avaya
;Profile: NONE
;Key features:;Max SW Ver: 5.0;Board Type: TrunkPack 1610;SS7 Links: MTP2=2 MTP3=2
M2UA=2 M3UA=1 ;Security: IPSEC MediaEncryption StrongEncryption
EncryptControlProtocol ;Coders: G723 G729 G728 NETCODER GSM-FR GSM-EFR AMR
EVRC-QCELP G727 ;Control Protocols: MGCP MEGACO H323 SIP
;E1Trunks=2;T1Trunks=2;Channel Type: RTP DspCh=60;PSTN Protocols: IUA=1 ;IP Media:
VXML ;Default features:;Coders: G711 G726;
;------------------------------
[SYSTEM Params]
SyslogServerIP = 149.49.140.245
EnableSyslog = 1
[BSP Params]
PCMLawSelect = 1
LocalOAMIPAddress = 149.49.140.243
RoutingTableHopsCountColumn = 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0
[ATM Params]
[Analog Params]
[ControlProtocols Params]
[MGCP Params]
[MEGACO Params]
EP_Num_0 = 0
EP_Num_1 = 1
EP_Num_2 = 0
EP_Num_3 = 0
EP_Num_4 = 0
[PSTN Params]
ProtocolType = 1
ClockMaster = 1
TerminationSide_0 = 1
TerminationSide_1 = 0
FramingMethod = c

LineCode = 2
[SS7 Params]
[Voice Engine Params]
IdlePCMPattern = 85
[WEB Params]
LogoWidth = '339'
[SIP Params]
LOCALSIPPORT = 5060
PLAYRBTONE2IP = 0
SIPT1RTX = 500
SIPT2RTX = 4000
ISPROXYUSED = 1
ISREGISTERNEEDED = 1
SIPDESTINATIONPORT = 5060
PLAYRBTONE2TEL = 2
DETFAXONANSWERTONE = 0
CHANNELSELECTMODE = 1
GWDEBUGLEVEL = 5
ENABLERPIHEADER = 0
ENABLEEARLYMEDIA = 0
ISUSERPHONE = 1
SIPSESSIONEXPIRES = 0
PROXYNAME = '149.49.140.210'
SIPGATEWAYNAME = '149.49.140.210'
USERNAME = '3006'
PASSWORD = '123456'
PRACKMODE = 1
ALTROUTINGTEL2IPMODE = 0
SIPMAXRTX = 7
ASSERTEDIDMODE = 0
ISUSERPHONEINFROM = 0
ADDTON2RPI = 1
USESOURCENUMBERASDISPLAYNAME = 0
MINSE = 90
IPALERTTIMEOUT = 180
ISFAXUSED = 0
SIPTRANSPORTTYPE = 0
TCPLOCALSIPPORT = 5060
SIP183BEHAVIOUR = 0

©
Avaya
PLAYBUSYTONE2ISDN = 0
TLSLOCALSIPPORT = 5061
ENABLESIPS = 0
USERAGENTDISPLAYINFO = ''
SESSIONEXPIRESMETHOD = 0
USEDISPLAYNAMEASSOURCENUMBER = 0
PLAYRBTONE2TRUNK_0 = -1
PLAYRBTONE2TRUNK_1 = 0
USESIPTGRP = 0
SIPSUBJECT = ''
CODERNAME = g711Alaw64k,20,0,$$,0
CODERNAME = g711Ulaw64k,20,0,$$,0
CODERNAME = g729,20,0,$$,0
TRUNKGROUP = 0-0/1-31,4000,0
TRUNKGROUP = 1-1/1-31,5000,0
PROXYIP = 149.49.140.210
[SCTP Params]
[VXML Params]
[IPsec Params]
[Audio Staging Params]
[PSTN-SDH Param

SIP Interoperability Test Plan - Results Appendix B - Configuration File for Third Party Devices
Appendix B - Configuration File for Third

Party Devices
There should be one Media Server Extension assigned for each AudioCodes product and
controlled by the CM Media Server.
Figure B-1: Configuring AudioCodes Products in Avaya SIP Proxy.

Avaya CM SIP Interoperability Test Plan - Results
Document #: LTRT-82601 May 2006
www.audiocodes.com

Avaya CM Sip Itp

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Avaya CM Sip Itp

Transféré par

Droits d'auteur :

Formats disponibles

AudioCodes Mediant 2000,

MP-114 & Avaya© CM,

May 2006 Document #: LTRT-82601

Appendix A – AudioCodes’ ini File ........................................................................33

AudioCodes Confidential 3 May 2006

AudioCodes Interoperability Laboratory 4 Document #: LTRT-82601

Information contained in this document is confidential and may not be

AudioCodes Confidential 5 May 2006

Interoperability Tests in General

ITP Target Audience

AudioCodes Interoperability Laboratory 6 Document #: LTRT-82601

1 Introducing AudioCodes’ ITP

1.2 Interoperability Test Laboratory Environment

1.2.1 AudioCodes’ Components

Product IP Address Final Version Tested

1.2.2 Third Party Components

Company & Product IP Address Final Version Tested

AudioCodes Confidential 7 May 2006

1.2.3 Laboratory Topology

(Refer to Figure 1-1)

Avaya Communication Manager (CM) is an integrated solution that can run on a

AudioCodes Interoperability Laboratory 8 Document #: LTRT-82601

All RTP (voice) streams go through the media gateway (149.49.140.176).

1.3 Contact Information

1.4 Test Summary

Table 1-3: Test Summary

1.4.1 Summary of Results & Open Issues

AudioCodes Confidential 9 May 2006

1. Call Waiting scenarios failed.

List any unusual or unwanted behavior.

1.4.2 AudioCodes’ Visual Intercept (VI) Records

Table 1-4: Visual Intercept (VI) Records

1.4.3 Avaya Bug Records

Table 1-5: Bug Records of Avaya

AudioCodes Interoperability Laboratory 10 Document #: LTRT-82601

1.5 Recommendations & Conclusions

Write down your general impressions of the third party devices.

Table 1-6: Conventions

AudioCodes Confidential 11 May 2006

AudioCodes Interoperability Laboratory 12 Document #: LTRT-82601

2 Test Case List

2.1.1 Inbound Basic to Third party phone 1 Calls

# Description Expected Results Result Remarks

AudioCodes Confidential 13 May 2006

# Description Expected Results Result Remarks

2.1.2 Inbound Basic to Third Party Phone 2 Calls

# Description Expected Results Result Remarks

AudioCodes Interoperability Laboratory 14 Document #: LTRT-82601

# Description Expected Results Result Remarks

2.1.3 Inbound Basic to PBX Phone

# Description Expected Results Result Remarks

AudioCodes Confidential 15 May 2006

# Description Expected Results Result Remarks

2.1.4 Inbound Basic M2K to Third Party Calls

# Description Expected Results Result Remarks

AudioCodes Interoperability Laboratory 16 Document #: LTRT-82601

# Description Expected Results Result Remarks

2.1.5 Basic Call – Caller ID

# Description Expected Results Result Remarks

AudioCodes Confidential 17 May 2006

# Description Expected Results Result Remarks

2.2 RTP Features – Codecs and DTMF

2.2.1 RTP Features – Codecs