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 1.2

Objective ...............................................................................................................7 Interoperability Test Laboratory Environment ...................................................7 1.2.1 1.2.2 1.2.3 1.2.4

1.3 1.4

Contact Information .............................................................................................9 Test Summary.......................................................................................................9 1.4.1 1.4.2 1.4.3

1.5 1.6

2

AudioCodes’ Components ......................................................................................................7 Third Party Components .........................................................................................................7 Laboratory Topology...............................................................................................................8 Configuration ..........................................................................................................................9

Summary of Results & Open Issues .......................................................................................9 AudioCodes’ Visual Intercept (VI) Records...........................................................................10 Avaya Bug Records ..............................................................................................................10

Recommendations & Conclusions....................................................................11 Conventions........................................................................................................11

Test Case List....................................................................................................13 2.1

Basic Calls ..........................................................................................................13 2.1.1 2.1.2 2.1.3 2.1.4 2.1.5

2.2

RTP Features – Codecs and DTMF....................................................................18 2.2.1 2.2.2

2.3

SIP Call Hold ........................................................................................................................21 Call Transfer .........................................................................................................................22 Call Waiting...........................................................................................................................24

Fax Calls .............................................................................................................25 2.4.1 2.4.2

2.5

RTP Features – Codecs .......................................................................................................18 RTP Features – DTMF .........................................................................................................19

Supplementary Services ....................................................................................21 2.3.1 2.3.2 2.3.3

2.4

Inbound Basic to Third party phone 1 Calls ..........................................................................13 Inbound Basic to Third Party Phone 2 Calls .........................................................................14 Inbound Basic to PBX Phone................................................................................................15 Inbound Basic M2K to Third Party Calls ...............................................................................16 Basic Call – Caller ID............................................................................................................17

Transparent Mode ................................................................................................................25 Fax T.38................................................................................................................................26

SIP Features........................................................................................................26 2.5.1 2.5.2 2.5.3

SIP Features - Registration and Authentication ....................................................................27 SIP Features - PRACK and Early Media...............................................................................28 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 Tip:

Date Printed: May-16-2006

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 crossreference, 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 [email protected].

Privacy Information Information contained in this document is confidential and may not be disclosed without prior written agreement from an AudioCodes signatory.

AudioCodes Confidential

5

May 2006

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.

AudioCodes Interoperability Laboratory

6

Document #: LTRT-82601

SIP Interoperability Test Plan - Results

1

1. Introducing AudioCodes’ ITP

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. 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.

Note:

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 1 2

1.2.2

IP Address

MP-114 FXS Mediant 2000

149.49.140.240 149.49.140.200

Final Version Tested V.4.8A.014.006 V.4.8A.014.006

Third Party Components Table 1-2: Third Party Components Company & Product

1 2 3

Avaya Comunication Manager S8300 Avaya SIP Proxy Avaya Media Gateway G350

AudioCodes Confidential

IP Address

Final Version Tested

149.49.140.179

CM - R013x.00.0.340.3

149.49.140.210 149.49.140.176

SES - SES03.1-03.1.018.0

7

May 2006

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

AudioCodes Interoperability Laboratory

8

Document #: LTRT-82601

SIP Interoperability Test Plan - Results

1. Introducing AudioCodes’ ITP

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


1.3

Refer to Appendix A – AudioCodes’ ini File and Appendix B - Configuration File for Third Party Devices on page 33 and 39 respectively.

Contact Information Company

1

AudioCodes

2

AudioCodes

3

Avaya

4

Avaya

1.4

Name

E-mail

Position

Interoperability Team Manager Interoperability Itzik Shnitzer [email protected] Engineer Technical Benaroya Yuval [email protected] Manager Global Technical Nir Halmut [email protected] Services Nir Zvulun

[email protected]

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

=

N/T

=

N/S

=

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. 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. 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

<79> PASS

<3> FAIL

<32> N/T or N/S

<114> Total Issues

TOTAL:

1.4.1

Summary of Results & Open Issues


Indicate which test scenarios failed.

AudioCodes Confidential

9

May 2006

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 Scenario

VI Number 37331

39256

1.4.3

New Version Numbers 4.80A.008.006

Table 5,8

2-22

Remarks This was related for many test scenarios – only after this was solved was the test continued.

tests 4.80A.015.004

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 Scenario

New third Party Version

Remarks

Section 2.3.3 (Call Waiting scenarios)

AudioCodes Interoperability Laboratory

10

Document #: LTRT-82601

SIP Interoperability Test Plan - Results

1.5

1. Introducing AudioCodes’ ITP

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

4

Third Party Phone 2

5

PBX Phone

6

Third Party Server

AudioCodes Confidential

Avaya SIP IP Phone User Avaya H.323 IP Phone User CM analog phone user connected to analog card in the CM Avaya SIP Proxy

11

May 2006

Avaya

©

Reader’s Notes

AudioCodes Interoperability Laboratory

12

Document #: LTRT-82601

SIP Interoperability Test Plan - Results

2

Test Case List

2.1

Basic Calls

2. Test Case List

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

1

AC to third party phone 1, AC1 disconnects after answer

1. Third party phone 1 is alerted Pass 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

2

AC to third party phone 1, AC1 disconnects before answer

1. Third party phone 1 is alerted Pass 2. AC1 receives audible ring back 3. The call is released when AC1 is on hooked 4. Third party phone 1 stops ringing

3

AC1 to third party phone 1, third party phone 1 disconnects after answer

1. Third party phone 1 is alerted 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 the third party phone 1 is on-hooked

Pass

4

Third party phone 1 to AC1, third party phone 1 disconnects after answer

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

Pass

5

Third party phone 1 to AC1, third party phone 1 disconnects before answer

1. AC1 is alerted 2. Third party phone 1 receives audible ring back 3. The call is released when the third party phone 1 is on-hooked 4. AC1 stops ringing

Pass

AudioCodes Confidential

13

Result

Remarks

May 2006

Avaya

#

Description

Expected Results

6

Third party phone 1 to AC1, AC1 disconnects after answer

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

7

AC1 to busy third party phone 1

1. AC receives a busy tone Pass 2. The call is released when AC1 is on-hooked

8

Third party phone 1 to busy AC1

1. Third party phone 1 receives a busy tone 2. The call is released when the third party phone 1 is on-hooked

2.1.2

Result

©

Remarks

Pass

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

#

Description

Expected Results

1

AC to third party phone 2, AC1 disconnects after answer

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

2

AC to third party phone 2, AC1 disconnects before answer

Pass 1. Third party phone 2 is alerted 2. AC1 receives audible ring back 3. The call is released when AC1 is on hooked 4. Third party phone 2 stops ringing

3

AC1 to third party phone 2, third party phone 2 disconnects after answer

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

Pass

4

Third party 2 phone to AC1, third party phone 2 disconnects after answer

1. AC1 is alerted 2. Third party phone 2 receives audible ring back 3. AC1 is able to answer the call 4. Two-way voice path is established

Pass

AudioCodes Interoperability Laboratory

14

Result Remarks

Document #: LTRT-82601

SIP Interoperability Test Plan - Results

#

Description

2. Test Case List

Expected Results

Result Remarks

5. The call is released when the third party 2 phone is on-hooked 5

third party phone 2 to AC1, third party phone 2 disconnects before answer

1. AC1 is alerted 2. Third party phone 2 receives audible ring back 3. The call is released when the third party phone 2 is on-hooked 4. AC1 stops ringing

6

third party phone 2 to AC1, AC1 disconnects after answer

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

7

AC1 to busy third party phone 2

1. AC receives a busy tone Pass 2. The call is released when AC1 is on-hooked

8

Third party phone 2 to busy AC1

1. Third party phone 2 receives a busy tone 2. The call is released when the third party phone 2 is on-hooked

2.1.3

Pass

Pass

Inbound Basic to PBX Phone Table 2-3: Outbound Basic Calls to PBX Phone

#

Description

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 4. Two-way voice path is established 5. The call is released when AC1 is on-hooked

2

AC1 to PBX phone, AC1 disconnects 1. PBX phone is alerted Pass before answer 2. AC1 receives audible ring back 3. The call is released when AC1 is on-hooked 4. PBX phone stops ringing

3

AC1 to PBX phone, PBX phone disconnects after answer

AudioCodes Confidential

Expected Results

Result Remarks

1. PBX phone is alerted Pass 2. AC1 receives audible ring back 3. PBX phone is able to answer the call 4. Two-way voice path is established 5. The call is released when the 15

May 2006

Avaya

#

Description

Expected Results

©

Result Remarks

PBX phone is on-hooked 4

PBX phone to AC1, PBX phone disconnects after answer

1. AC1 is alerted Pass 2. PBX phone receives audible ring back 3. PBX phone is able to answer the call 4. Two-way voice path is established 5. The call is released when the PBX phone is on-hooked

5

PBX phone to AC1, PBX phone disconnects before answer

1. AC1 is alerted Pass 2. PBX phone receives audible ring back 3. The call is released when the PBX phone is on-hooked 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 3. AC1 is able to answer the call 4. Two-way voice path is established 5. The call is released when AC1 is on-hooked

7

AC1 to busy PBX phone

1. AC1 receives a busy tone 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. The call is released when the PBX phone is on-hooked

2.1.4

Pass

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

#

Description

Expected Results

1

AC1 through M2K to third party phone 1, AC1 disconnects after answer

1. Third party phone 1 is alerted Pass 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

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 3. The call is released when AC1 is on hooked

AudioCodes Interoperability Laboratory

16

Result Remarks

Document #: LTRT-82601

SIP Interoperability Test Plan - Results

#

Description

2. Test Case List

Expected Results

Result Remarks

4. Third party phone 1 stops ringing 3

AC1 through M2K to third party phone 2, AC1 disconnects after answer

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 3. The call is released when AC1 is on hooked 4. Third party phone 2 stops ringing

5

AC1 through M2K to PBX phone, AC1 disconnects after answer

6

AC through M2K to PBX phone, AC1 1. PBX phone is alerted Pass disconnects before answer 2. AC1 receives audible ring back 3. The call is released when AC1 is 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 phone

2.1.5

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

1. PBX phone is alerted Pass 2. AC1 receives audible ring back 3. PBX Phone is able to answer the call 4. Two-way voice path is established 5. The call is released when AC1 is on-hooked

1. AC1 receives a busy tone Pass 2. The call is released when AC1 is on-hooked

Basic Call – Caller ID Table 2-5: Basic Call – Caller ID

# Description

Expected Results

1

AC1 calls AC2, Caller ID displayed

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

AudioCodes Confidential

Caller ID of AC1 shown to AC2

Result Remarks

17

N/T

May 2006

Avaya

# Description

Expected Results

displayed

Result Remarks

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

1

AC1 to third party phone 1 with coder G.711 A-Law

Two-way voice path is established in G.711alaw Verify voice quality.

Pass

2

AC1 to third party phone 1 with coder G.711 µ-Law

Two-way voice path is established in G.711ulaw Verify voice quality.

Pass

3

AC1 to third party phone 1 with coder G.729

Two-way voice path is established in G.729 Verify voice quality.

Pass

4

AC1 to third party phone 1 with coder G.723

Two-way voice path is established in G.723. Verify voice quality.

Pass

5

AC1 to third party phone 1 with coder G.726

Two-way voice path is established in G.726. Verify voice quality

N/S

6

AC1 to third party phone 2 with coder G.711 A-Law

Two-way voice path is established in G.711alaw Verify voice quality.

Pass

AudioCodes Interoperability Laboratory

18

Result Remarks

Avaya Sip Proxy not Support G726

Document #: LTRT-82601

SIP Interoperability Test Plan - Results

2. Test Case List

#

Description

Expected Result

7

AC1 to third party phone 2 with coder G.711 µ-Law

Two-way voice path is established in G.711ulaw Verify voice quality.

Pass

8

AC1 to third party phone 2 with coder G.729

Two-way voice path is established in G.729 Verify voice quality.

Pass

9

AC1 to third party phone 2 with coder G.723

Two-way voice path is established in G.723. Verify voice quality.

Pass

10 AC1 to PBX Phone with coder G.711 A-Law

Two-way voice path is established in G.711alaw Verify voice quality.

Pass

11 AC1 to PBX Phone with coder G.711 µ-Law

Two-way voice path is established in G.711ulaw Verify voice quality.

Pass

12 AC1 to PBX Phone with coder G.729

Two-way voice path is established in G.729 Verify voice quality.

Pass

13 AC1 to PBX Phone with coder G.723

Two-way voice path is established in G.723. Verify voice quality.

Pass

2.2.2

Result Remarks

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

#

Description

Expected Result

1

DTMF transport from AC1 to third party phone 1 (RFC 2833)

DTMF pass-through RFC 2833 RTP telephone event Verify precise DTMF detection, including fast digit dialing DTMF pass-through RFC 2833 RTP telephone event Verify precise DTMF detection, including fast digit dialing

Pass

1. AC1 declares its capability for an RFC 2833 RTP telephone event. 2. AC2 replies without an RTP telephone event 3. DTMF passes in-band transport DTMF passes through an RFC 2833 RTP telephone event Verify DTMF digit quality, including fast digit dialing

N/T

DTMF transport from AC1 to third party phone 2 (RFC 2833)

2

DTMF transport from AC1 supporting RFC 2833. AC2 doesn’t support RFC 2833

3

DTMF transport from AC1 to PBX phone (RFC 2833)

AudioCodes Confidential

19

Result

Remarks

Pass

Pass

May 2006

Avaya

#

Description

Expected Result

4

DTMF transport from PBX phone to AC1 (RFC 2833)

DTMF passes through an RFC 2833 RTP telephone event Verify DTMF digit quality, including fast digit dialing

Pass

5

DTMF transport from third party phone DTMF passes through an RFC 1 to AC1 (RFC 2833) 2833 RTP telephone event Verify DTMF digit quality, including fast digit dialing DTMF transport from third party phone DTMF passes through an RFC 2 to AC1 phone (RFC 2833) 2833 RTP telephone event Verify DTMF digit quality, including fast digit dialing

Pass

6

Result

Pass

7

AC1 to AC2, in-band DTMF (G.711) and vice versa*

DTMF passes transport

in-band

G.711

N/T

8

AC1 to PBX phone, in-band DTMF (G.711) and vice versa

DTMF passes transport

in-band

G.711

Pass

9

third party phone to AC1, in-band DTMF (G.711) and vice versa

DTMF passes transport

in-band

G.711

Pass

AudioCodes Interoperability Laboratory

20

©

Remarks

This test scenario is applicable only if RTP isn’t sent peer to peer. This test scenario is applicable only if RTP isn’t sent peer to peer. This test scenario is applicable only if RTP isn’t sent peer to peer.

Document #: LTRT-82601

SIP Interoperability Test Plan - Results

2.3

2. Test Case List

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. 2.

By sending a Re-INVITE with the IP address 0.0.0.0 or ‘a=sendonly’ in the SDP. 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)

#

Description

Expected Results

1

AC1 to third party phone 1, AC1 holds call and reconnects

2

AC1 to third party phone 2, AC1 holds call and reconnects

3

AC1 to PBX Phone, AC1 holds call and reconnects

Pass 1. Establish a call and a two-way 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 4. AC1 presses hook flash and reconnects to the third party phone 1 with a two-way voice path 5. The call is released when AC1 is on-hooked 1. Establish a call and a two-way Pass voice path between AC1 and the third party phone 2 2. AC1 presses hook flash and receives a dial tone 3. Third party phone 2 receives MOH, if available 4. AC1 presses hook flash and reconnects to the third party phone 2 with a two-way voice path 5. The call is released when AC1 is on-hooked 1. Establish a call and a two-way Pass voice path between AC1 and the PBX phone 2. AC1 presses hook flash and receives a dial tone 3. PBX phone receives MOH, if

AudioCodes Confidential

21

Result

Remarks

May 2006

Avaya #

Description

Expected Results

Result

©

Remarks

available 4. AC1 presses hook flash and reconnects to the PBX phone with a two-way voice path 5. The call is released when AC1 is 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

#

Description

Expected Results

1

AC1 to PBX Phone, AC1 unattended transfer PBX phone to third party phone 1

1. AC1 and PBX phone converse Pass 2. AC1 presses flash and receives 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 transfer to AC3 AC1 – G.711, G.729 AC2 - G.711, G.729 AC3 – G.729

1. AC1 and AC2 converse in G.711 N/T 2. AC2 presses flash and receives a dial tone 3. AC1 receives an MOH, if 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 unattended transfer to third party phone 2

Pass 1. AC1 and third party phone 1 converse 2. AC1 presses flash and receives a dial tone 3. Third party phone 1 receives an MOH, if available 4. AC1 calls third party phone 2, AC1 receives ring back. third party phone 2 is alerted. 5. AC1 on-hooks 6. Third party phone 2 continues to

AudioCodes Interoperability Laboratory

22

Result Remarks

Document #: LTRT-82601

SIP Interoperability Test Plan - Results #

Description

2. Test Case List Expected Results

Result Remarks

be alerted 7. Third party phone 2 off-hooks and converses with third party phone 1 4

AC1 to third party phone 2, AC1 unattended transfer to third party phone 1

1. AC1 and third party phone 2 Pass converse 2. AC1 presses flash and receives a dial tone 3. Third party phone 2 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 to be alerted 7. Third party phone 1 off-hooks and converses with third party phone 2

5

AC1 to PBX Phone, AC1 attended transfer to third party phone 1

1. AC1 and PBX Phone converse Pass 2. AC1 presses flash and receives 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. 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 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. 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 attended transfer to third party phone 2

AudioCodes Confidential

1. AC1 and the third party phone 1 Pass converse 2. AC1 presses flash and receives a dial tone 23

May 2006

Avaya #

Description

Expected Results

©

Result Remarks

3. Third party phone 1 receives an MOH, if available 4. AC1 calls third party phone 2, AC1 receives ring back. third party phone 2 is alerted. 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 8

2.3.3

AC1 to third party phone 2, AC1 attended transfer to third party phone 1

1. AC1 and third party phone 2 Pass converse 2. AC1 presses flash and receives a dial tone 3. Third party phone 2 receives an MOH, if available 4. AC1 calls third party phone 1, AC1 receives ring back. third party phone 1 is alerted. 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

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

#

Description

1

AC1 in call with third party phone 2, 1. AC1 and third party phone 2 PBX Phone calls AC1 and converse disconnect 2. PBX Phone calls AC1, PBX Phone receives call waiting ring back tone and AC1 has Call Waiting Indication (CWI) 3. PBX Phone on-hooks 4. AC1 and third party phone 2 continue to converse and CWI is stopped

Fail

2

AC1 in call with AC2, AC3 calls AC1, AC1 holds AC2 and answers

N/T

AudioCodes Interoperability Laboratory

Expected Results

Result Remarks

1. AC1 and AC2 converse 2. AC3 calls AC1, AC3 receives a 24

When PBX Phone call the second call to AC1, AC1 reply with “182 Queued” then the Sip Proxy send “Cancel” request

Document #: LTRT-82601

SIP Interoperability Test Plan - Results

2. Test Case List

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 6. AC1 and AC2 converse

3

AC1 in call with AC2, PBX phone calls AC1, AC1 holds AC2 and answers PBX phone and back to AC2

1. AC1 and AC2 converse 2. PBX phone calls AC1, PBX phone receives a call waiting ring back tone and AC1 has a CWI 3. AC1 presses flash, AC2 has an MOH if available 4. AC1 and the PBX phone converse 5. AC1 presses flash, PBX phone has MOH if available 6. AC1 and AC2 converse

N/T

4

AC1 in call with AC2, third party phone calls AC1, AC1 holds AC2 and answers third party phone and back to AC2

1. AC1 and AC2 converse 2. Third party phone calls AC1, third party phone receives a call waiting ring back tone and AC1 has a CWI 3. AC1 presses flash, AC2 has an MOH if available 4. AC1 and third party phone converse 5. AC1 presses flash, third party phone has an MOH if available 6. AC1 and AC2 converse

N/T

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

#

Description

Expected Results

1

AC1 to PBX phone, Fax, G.711

The fax is sent successfully

2

PBX phone to AC1, Fax, G.711

3

4

Result Remarks Pass

The fax is sent successfully Pass 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. 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.

AudioCodes Confidential

25

May 2006

Avaya

# 5

6

7

2.4.2

Description

Expected Results

©

Result Remarks

2. The fax is sent successfully. 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. 2. The fax is sent successfully. AC1 to third party phone, Fax, N/T 1. Configure both AC1 & the third fallback to G.711 party phone for G.723 voice coder and also for fax fallback to G.711. 2. The fax is sent successfully. third party phone to AC1, Fax, N/T 1. Configure both AC1 & the third fallback to G.711 party phone for the G.723 voice coder and also for fax fallback to G.711. 2. The fax is sent successfully.

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

#

Description

Expected Results

1

AC1 to AC2, Fax T.38

T.38 is negotiated The fax is sent successfully.

N/T

2

AC1 to PBX phone, Fax T.38

T.38 is negotiated The fax is sent successfully.

3

PBX phone to AC1, Fax T.38

T.38 is negotiated The fax is sent successfully.

4

AC1 to third party phone, Fax T.38

T.38 is negotiated The fax is sent successfully.

N/S T.38 Not supported by Avaya SIP Proxy N/S T.38 Not supported by Avaya SIP Proxy N/T

5

third party phone to AC1, Fax T.38

T.38 is negotiated The fax is sent successfully.

2.5

Result Remarks

N/T

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-ofband 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.

AudioCodes Interoperability Laboratory

26

Document #: LTRT-82601

SIP Interoperability Test Plan - Results

2.5.1

2. Test Case List

SIP Features - Registration and Authentication Table 2-13: Registration and Authentication

#

Description

Expected Results

1

AC Registration without Authentication.

1. AC sends a SIP REGISTER message to the third party server 2. A successful response is sent to AC.

Pass

2

AC Authenticated on Registration

1. AC sends a SIP REGISTER 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. 4. A successful response is sent to AC.

Pass

3

M2K Authenticated on Registration

1. M2K sends a SIP REGISTER message to the third party server. 2. The third party server prompts M2K for authentication (returns SIP 401). 3. M2K resends the SIP REGISTER message with authentication parameters. 4. A successful response is sent to M2K.

Pass

4

AC Re-Registration (Registration Time in gateway more than Registration Time in third party server)

1. Define the Registration Time of the AudioCodes device as more than the Registration Time that is defined in the third party server. 2. Verify that the AC device reregisters in the third party server every period of time defined by the third party server and expressed in the 200OK response for REGISTER messages.

N/T

5

AC Re-Registration (Registration Time in gateway less than Registration Time in third party server)

1. Define the Registration Time of the AudioCodes device as less than the Registration Time that is defined in the third party server. 2. Verify that the AC device reregisters in the third party server every period of time defined by the third party server and expressed in the 200OK response for REGISTER messages.

N/T

6

AC Authenticated on re-INVITE

1. AC sends a SIP INVITE message to the third party server. 2. The third party server prompts AC for authentication (returns SIP

Pass

AudioCodes Confidential

27

Result Remarks

May 2006

Avaya

#

Description

Expected Results

©

Result Remarks

407). 3. AC resends the SIP INVITE message with authentication parameters. 4. A successful response is sent to AC. 7

2.5.2

M2K Authenticated on re-INVITE

1. M2K sends a SIP INVITE message to the third party server. 2. The third party server prompts M2K for authentication (returns SIP 407). 3. M2K resends the SIP INVITE message with authentication parameters. 4. A successful response is sent to M2K.

Pass

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

# 1

Description AC1 to third party with PRACK request

Expected Results

Result Remarks 1. Configure the gateway for PRACK Pass 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.

3

AC1 to PBX phone with Early media. 1. Enable early media in the gateway 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. 4. Verify that the call was established

AudioCodes Interoperability Laboratory

1. Enable early media in the 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

28

N/T

Pass

Document #: LTRT-82601

SIP Interoperability Test Plan - Results

#

Description

2. Test Case List Expected Results

Result Remarks

correctly 4

AC1 to third party phone 1 with Early 1. Enable early media in the gateway 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. 4. Verify that the call was established correctly

Pass

5

AC1 to third party phone 2 with Early 1. Enable early media in the gateway 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), following the media stream to be set up prior to the answering of the call. 4. Verify that the call was established correctly

Pass

5

PBX phone to AC1 with Early media. 1. Enable early media in the gateway 2. Establish a call from the PBX phone to AC1 3. Verify that AC1 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

Pass

6

third party phone 1 to AC1 with Early 1. Enable early media in the gateway media. 2. Establish a call from the third party phone 1phone to AC1 3. Verify that AC1 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

Pass

AudioCodes Confidential

29

May 2006

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

#

Description

Expected Results

1

AC1 to AC2 using UDP connection

1. Enable UDP connection on both AC devices. 2. Establish a call from AC1 to AC2 3. Verify that the call was established correctly

N/T

2

AC1 to AC2 using TCP connection

1. Enable TCP connection on both AC devices. 2. Establish a call from AC1 to AC2 3. Verify that the call was correctly established in a TCP connection

N/T

3

AC1 to AC2 using TLS connection

1. Enable TLS connection on both AC devices. 2. Establish a call from AC1 to AC2 3. Verify that the call was correctly established in a TLS connection

N/T

4

AC1 to PBX phone using UDP connection

1. Enable UDP connection on both AC1 device and PBX. 2. Establish a call from AC1 to the PBX phone 3. Verify that the call was correctly established in a UDP connection

Pass

5

AC1 to PBX phone using TCP connection

1. Enable TCP connection on both AC1 device and the PBX phone. 2. Establish a call from AC1 to the PBX phone 3. Verify that the call was correctly established in a TCP connection

Fail

6

AC1 to PBX phone using TLS connection

1. Enable TLS connection on both the AC1 device and the PBX phone. 2. Establish a call from AC1 to the PBX phone 3. Verify that the call was correctly established in a TLS connection

N/T

7

AC1 to third party phone using UDP 1. Enable UDP connection on both connection the AC1 device and the third party phone. 2. Establish a call from AC1 to the

AudioCodes Interoperability Laboratory

30

Result Remarks

Please see unusual or unwanted behaviors in paragraph 1.4.1

Pass

Document #: LTRT-82601

SIP Interoperability Test Plan - Results

#

Description

2. Test Case List

Expected Results

Result Remarks

third party phone 3. Verify that the call was correctly established in a UDP connection 8

AC1 to third party phone using TCP 1. Enable TCP connection on both connection the AC1 device and the third party phone. 2. Establish a call from AC1 to the third party phone 3. Verify that the call was correctly established in a TCP connection

Fail

9

AC1 to third party phone using TLS connection

N/T

AudioCodes Confidential

1. Enable TLS connection on both the AC1 device and the third party phone. 2. Establish a call from AC1 to the third party phone 3. Verify that the call was correctly established in a TLS connection.

31

Please see unusual or unwanted behaviors in paragraph 1.4.1

May 2006

Avaya

©

Reader’s Notes

AudioCodes Interoperability Laboratory

32

Document #: LTRT-82601

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]

AudioCodes Confidential

33

May 2006

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

AudioCodes Interoperability Laboratory

34

Document #: LTRT-82601

SIP Interoperability Test Plan - Results

Appendix A – AudioCodes’ ini File

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 AudioCodes Confidential

35

May 2006

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 AudioCodes Interoperability Laboratory

36

Document #: LTRT-82601

SIP Interoperability Test Plan - Results

Appendix A – AudioCodes’ ini File

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

AudioCodes Confidential

37

May 2006

Avaya

©

PLAYBUSYTONE2ISDN = 0 TLSLOCALSIPPORT = 5061 ENABLESIPS = 0 USERAGENTDISPLAYINFO = '' SESSIONEXPIRESMETHOD = 0 USEDISPLAYNAMEASSOURCENUMBER = 0 PLAYRBTONE2TRUNK_0 = -1 PLAYRBTONE2TRUNK_1 = 0 PLAYRBTONE2TRUNK_2 = -1 PLAYRBTONE2TRUNK_3 = -1 PLAYRBTONE2TRUNK_4 = -1 PLAYRBTONE2TRUNK_5 = -1 PLAYRBTONE2TRUNK_6 = -1 PLAYRBTONE2TRUNK_7 = -1 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

AudioCodes Interoperability Laboratory

38

Document #: LTRT-82601

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.

AudioCodes Confidential

39

May 2006

Avaya CM SIP Interoperability Test Plan - Results

Document #: LTRT-82601

May 2006

www.audiocodes.com