rapport d'audit avencall 8 janvier 2014 - asterisk...document date 11/01/2014 département rd...

DOCUMENT Date 11/01/2014

Département RD Rapport d'Audit Avencall

Référence WA14-P03-DOC049

Classification EXT Version A

Ce document est la propriété de la société WAVETEL et ne peut être reproduit sans son autorisation 11/01/2014 1/28 WAVETEL - SARL au capital de 80 000 € - RCS Lorient 443 937 719 00021 - Tél. : +33(0)2 97 35 36 12 www.wavetel.fr [email protected]

Rapport d'Audit

AvenCall

8 Janvier 2014






Rapport d'Audit Avencall Liste de diffusion

Société

Destinataires

(A)ction, (I)nformation,

(Ar)chivage

Support de diffusion

WAVETEL Nicolas BOHELAY (I)

Documentaliste (Ar)

Fichier pdf

AVENCALL Etienne ALLOVON (I)

Jérémie BOISSET (I)

Fichier pdf

Gestion des évolutions

Identification du document Description évolutions

WA14-P03-DOC049 A 11/01/2014 Document initial (28 pages)

Signatures

Rédacteur Approbateur

Hubert CHARTIN

Le 11 Janvier 2014

Signature :

Nicolas BOHELAY

Le 11 Janvier 2014

Signature :

Classification

Niveau Document Interne (EXT)

Enregistrement

Archivé Le :

Tampon société :






Table des Matières

1. Introduction ........................................................................................................................ 4 2. Generalities ......................................................................................................................... 5

2.1. Objectives .................................................................................................................... 5 2.2. Acteurs ......................................................................................................................... 5

3. Audit Introduction .............................................................................................................. 5 3.1. Test Bench and Tools : ................................................................................................ 5

3.1.1. Material : .............................................................................................................. 5

3.1.2. Software: .............................................................................................................. 6 3.2. Environement Description ........................................................................................... 6

4. Test Plan ............................................................................................................................. 7 5. Preliminary Remarks .......................................................................................................... 7 6. Connection Tests : .............................................................................................................. 9

6.1. XIVO facing TNR6G Layer 1 Required Layer 2 Leave Down .................................. 9 6.1.1. Point to Multi point configuration ........................................................................ 9

6.1.2. Point to point configuration ................................................................................ 11 6.2. XIVO facing TNR6G Layer 1 Ignore Layer 2 Leave Down ..................................... 13

6.2.1. Point to Multi point configuration ...................................................................... 13 6.2.2. Point to point configuration ................................................................................ 15

6.3. XIVO facing TNR6G Layer 1 Ignore Layer 2 Keep Up ........................................... 19 6.3.1. Point to Multi point configuration ...................................................................... 19

6.3.2. Point to point configuration ................................................................................ 22 6.4. XIVO facing TNR6G Layer 1 Required Layer 2 Keep Up ....................................... 23

6.4.1. Point to Multi point configuration ...................................................................... 23 6.4.2. Point to point configuration ................................................................................ 24

7. Conclusions ...................................................................................................................... 26






1. Introduction

Avencall has developped an IPPBX called XIVO. This PBX is integrating a Digium ISDN

board with 4 BRI interfaces (S0/T0).

Recently Avencall encountered some troubles at customer’s sites to make the solution

effective facing Orange network. When the problem occurs the XIVO is connected through the

Digium ISDN board to the Orange NT1s.

As a first analysis it seems that the problem is mainly due to the layer 1 management that

occurs on the french BRI. The Layer 1 is not permanent and when the Layer 1 is down it seems

very difficult for the system to place outgoing calls.

As there is no layer 1 establishment the XIVO system is out of service during a period that can

last several minutes for outgoing and incoming calls.

Wavetel is a french company specialised in Test equipment for access and core networks

(ISDN, XDSL, Fiber, LAN, WAN, 4G/LTE). Wavetel has developped a full range of IDSN

protocol analysers and BERT tester and has a deep expertise and know how in that matter.

Wavetel has a branch of audit and consulting activity and has been missioned by XIVO to try

to troubleshoot the problem of Layer 1 establishment.

For this first collaboration between Wavetel and Avencall, the scope of the technical audit is

as following :

Provision of the Wavetel Labs in Larmor-Plage in order to try the trouble that Avencall is

facing at customer site including :

Technical Assistance to set up the test system,

Provision of ISDN BRI analysers at U and S0/T0 interfaces,

Data analysis assistane performed by our IDSN expert

The scope of this document is to summarise the tests that have been performed at the Wavetel

labs during one day and to provide some clues to find a solution to understand how the Digium

board behaves facing the Orange NT1.






2. Generalities

2.1. Objectives

The main objective of this first test session that took place the 8 of January was to try to

reproduce at the lab the XIVO troubles and then to perform some deep protocol analysis.

2.2. Acteurs

The project leader delegated by XIVO to perform thoses tests is Frédéric Tarrieras

The project leader at Wavetel conducting the Audit at Wavetel is Hubert CHARTIN

Nicolas BOHELAY, Wavetel technical manager, is also providing some assistance et technical

analysis.

3. Audit Introduction

The tests took place at Larmor-Plage the 8th of January. The analysis was performed in real

time with the assistance of Frédéric. It was quite easy to reproduce the troubles that XIVO is

encoutering at customer site.

3.1. Test Bench and Tools :

In order to be able to reproduce the trouble it was mandatory to have the same configuration at

the lab that the one at customer. To do so thanks to its connnection with ELCON, the main NT1

provider for Orange, Wavetel was able to provide the NT1 6G that seems to be involved

inXIVO/Digium behavior. Then in order to be able to trace and to analyse the ISDN BRI interface,

the WAVETEL U and S analysers were available and installer between the Digium board and the

Orange ISDN LT.

3.1.1. Material :

The ACTRIS S0 is a powerful ISDN

protocol analyser that is able to fully decode

the D-Channel ISDN signalling at the

U/S0/T0 BRI interfaces according to the

European standards

(EDSS1/Q.931/Q.921/VN2 to VN7, QSIG

….).

The ARGUS 125 is a BERT tester for ISDN

BRI and PRI. It is a reference product used

worldwide by Telcos to qualify ISDN

accesses.

The ARGUS will be used in TE mode in

order to understand and to diagnose the

Layer 1 activation trouble.






3.1.2. Software:

3.1.2.1. ACTW eXpert protocol analysis software :

Le logiciel ACTW eXpert permet d'effectuer un décodage

exhaustif niveaux 1, 2 et 3 de la majorité des protocoles en

vigueur EDSS1, VN7, QSIG avec différentes fonctions d'analyse

et de recherche de défauts. La fonction tickets de

communications apporte une synthèse de l'ensemble des

communications qui ont eu lieu sur un ou plusieurs accès RNIS.

Un entête d'analyse statistique permet de détecter

automatiquement les causes éventuelles d'échec des appels et

l'occupation des canaux B de l'installation.

3.2. Environement Description

Xivo was setup in the following configuration :

- One 4 BRI Digium Board

- Two IP Phones

The XIVO was connected to one or two ISDN accesses.

The ISDN accesses were provided by Orange and it was possible to exchange the NT1 in order

to perform some tests with different manufacturers.

The main NT1 available were :

TNR2G / ELCON (NT1 ab)

TNR6G / ELCON (NT1 6G

TNR G / Sagem

The ACTRIS S0 was connected in high impedande at the S0 interface.

The ACTRIS U was only usefull on a few test to check the behavior of the U interface and to

control if there were some difference between te signalling at the U and S interfaces.






4. Test Plan

We will test the connection of the XIVO PABX to different types of NT1. The main idea is

first to be able to reproduce the customer trouble.

Then for each test sequence we will connect the ISDN BRI tester to the same NT1 to check if

there is also some difficulties in order to know of the trouble is issued from the Terminal

Equipment (XIVO or ARGUS) or from the NT1.

During each test campaign we will analyse carefully from one side the log of the XIVO

system and from the other side the ISDN signalling.

5. Preliminary Remarks

XIVO and Digium Configuration :

According to the layer 1 troubles we have to take care of the Digium Board configuration :

File /etc/dahdi/system.conf :

Port creation and inilisation as following :

Span = 1,1,0,ccs,ami

Ccs : channel common signalling. It is correct.

Ami : U interface code (Alternate Mark Inversion)

Synchro : it is not clear ; the XIVO has to act as a TE mode so in that case the XIVO through

the Digium board is slave relating to the clock that is provided by the NT1.

® Remark1 : The ami code is a three states line code that is no more used in France for

years. The U interace code is 2B1Q. Anyway it should not impact a connection at the S0/T0

interface






File /etc/asterisk/dahdi-channels.conf and chan-dahdi.conf:

Customer Premises Equipment configuration :

Parameter Possible values

Signalling CPE bri_cpe (Point to Point ) or

bri_cpe_ptmp (Point to Multi-Point)

® Remark2 : The XIVO is configured most of the time in Point to Multipoint with a

dynamic TEI management.

We are quite surprised as the XIVO is in a typical point to point configuration. The XIVO is

the only Termincal equipment (CPE) connected on the S-Bus.

This should imply a point to point configuration with a TEI assigned in manual mode and

equal to 0.This is typically the PBX configuration that is used mostly to interconnect PBX

to the ISDN network.

Layer 1 and Layer 2 behavior :

Parameter Possible values

Layer 1 presence Required or Ignore

Layer2-persistence Keep_up / Leave-down

® Remark3 : The Layer 1 is not permanent at the S0/T0 interface. This means that when

there is no layer 1 active, the CPE (ie Digium board) will have to activate the layer 1 and

then the layer 2 to achieve an outgoin call. This is under the responsability of the CPE.

The firmware can ignore the Layer 1 value anyway you need a Layer 1 activated to be able

to setup the layer 2 and then to place a call.

The standard is the I.430. The layer 1 is activated on request to save energy.






Layer 1 activation (TE/NT1)

6. Connection Tests :

Different tests are performed towards several NT1. It appears clearly that time to time the

XIVO system is locked and unable to place some simple calls. If we place the Argus tester in

the same configuration it works perfectly.

However it seems difficult to make a simple diagnose so we decide to focus on the TNR6G

from ELCOM that seems to imply troubles on the field.

We will run different tests with the different valued of Layer 1, Layer 2 and PP/PMP

configuration. Then we will place outgoing and incoming calls

6.1. XIVO facing TNR6G Layer 1 Required Layer 2 Leave Down

6.1.1. Point to Multi point configuration

Outgoing Call

03 :07 pm

The XIVO is not able to establish the Layer 1 nor the Layer 2.

The XIVO does not answer to the TEI Check Request from the Network

The Layer 1 is not stable

After some testing the U interface is getting down






Incoming Call

03 :03 PM

Analysis :

The incoming call conforms to the standard

with a TEI 127 as the layer 2 is not still

assigned.

The CPE request a TEI and get 105

assigned.

The layer 2 is then established (SABME/UA)

Anomaly Report 1

(L1R,L2LD,PMP)

The XIVO rejects the call in PMP with a

cause value 44 (circuit not avaible). This is

not standard and nor understandable. This

cause is a network cause and then no channel

are assigned on the S-Bus

Relating frames :






6.1.2. Point to point configuration

Outgoing Call

03 :19 pm

The XIVO is configured in point to point.

Nothing is happening on the S Bus when we try to establish a call.

There is no layer 1 activation.

The analyser is able to detect the presence of the PS1 (Power supply 1 in

fanthom mode).

If we perform the same test with the ARGUS there is no trouble to establish

a call.

Anomaly

Report 2

(L1R,L2LD,P

P)

The XIVO is not activating the layer 1 at the S0 interface. The logs are not

consistant as the system is stating layer 1 and layer 2 activation but nothing

is happening on the S bus.






Outgoing Call

03 :21 pm

The XIVO is configured in point to point.

The networks is delivering a standard incoming call with a regular SETUP

The XIVO is establishing the Layer 2 (SABME/UA : TEI 0)

The XIVO rejects again the incoming call with a cause value 44

The XIVO does not answer to the TEI Check Request from the network

Anomaly

Report 3

(L1R,L2LD,P

P)

The XIVO rejects the call in PP with a cause value 44 (circuit not avaible).

This is not standard and nor understandable. This cause is a network cause

and then no channel are assigned on the S-Bus

Anomaly

Report 4

The XIVO when configured in PP mode TEI = 0 does not answer to the TEI

check request with Ai value (127) from the network.

No answer to the TEI Check Request






6.2. XIVO facing TNR6G Layer 1 Ignore Layer 2 Leave Down


Outgoing

Calls

And Incoming

Calls

03 :21 pm

First Initialisation is quite long.

Then The XIVO is able to place several successful outgoing calls

Call Trace Summary (CDR)

Outgoing Call trace – with TEI assignment

0178:L: 08/01/14 15:46:52:70 N->U :INFO 4 U->N :INFO 0

0179:L: 08/01/14 15:46:52:72 N->U :INFO 0 U->N :INFO 0

0180:L: 08/01/14 15:46:52:77 N->U :INFO 0 U->N :INFO 1

0181:L: 08/01/14 15:46:52:84 N->U :INFO 2 U->N :INFO 1

0182:L: 08/01/14 15:46:52:84 N->U :INFO 2 U->N :INFO 3

0183:L: 08/01/14 15:46:52:89 N->U :INFO 4 U->N :INFO 3

0184:N: 08/01/14 15:46:55:91 63 127 1 UI 0 ... ... 15 00000 ID check requ. 127

0185:N: 08/01/14 15:46:56:94 63 127 1 UI 0 ... ... 15 00000 ID check requ. 127

0186:U: 08/01/14 15:46:57:78 63 127 0 UI 0 ... ... 15 27655 ID request 127

0187:N: 08/01/14 15:46:57:80 63 127 1 UI 0 ... ... 15 27655 ID assigned 106

0188:U: 08/01/14 15:46:57:81 00 106 0 SABME 1 ... ...

0189:N: 08/01/14 15:46:57:82 00 106 0 UA 1 ... ...

0190:U: 08/01/14 15:46:57:85 00 106 0 I 0 000 000 08 1 01 0 SETUP

BEARER CAPABILITY (04) 03 80 90 A3

coding standard: CCITT

information : speech

transfer mode : circuit mode

transfer rate : 64 kbit/s

layer 1 protoc.: Recommendation G.711 A-law

CHANNEL IDENTIFIC. (18) 01 81

int id present : interface implicitly identified

interface type : basic interface






prefer./exclus.: preferred

Channel identif: not D-channel

info chan sel. : B1 channel

CALLING PARTY NUMB (6C) 0B 21 80 32 39 37 38 33 37 35 33 30

type of number : national number

numbering plan : ISDN/telephony numbering plan (E.164)

presentat. ind : presentation allowed

screening ind. : user-provided, not screened

number digits : 297837530

CALLED PARTY NUMB. (70) 0B 80 30 36 34 37 38 38 32 31 30 38

type of number : unknown

numbering plan : unknown


SENDING COMPLETE (A1)

0191:N: 08/01/14 15:46:57:86 00 106 0 RR 0 ... 001

0192:N: 08/01/14 15:46:57:96 63 127 1 UI 0 ... ... 15 00000 ID check requ. 127

0193:U: 08/01/14 15:46:57:97 63 127 0 UI 0 ... ... 15 62771 ID check resp. 106

0194:N: 08/01/14 15:46:58:27 00 106 1 I 0 000 001 08 1 01 1 CALL PROCEEDING




prefer./exclus.: exclusive



0195:U: 08/01/14 15:46:58:27 00 106 1 RR 0 ... 001

0196:N: 08/01/14 15:46:59:59 00 106 1 I 0 001 001 08 1 01 1 ALERTING

0197:U: 08/01/14 15:46:59:60 00 106 1 RR 0 ... 002

0198:U: 08/01/14 15:47:09:50 00 106 0 I 0 001 002 08 1 01 0 DISCONNECT

CAUSE (08) 02 81 90


location : private network serving the local user

cause : Normal call clearing #16

0199:N: 08/01/14 15:47:09:51 00 106 0 RR 0 ... 002

0200:N: 08/01/14 15:47:09:71 00 106 1 I 0 002 002 08 1 01 1 RELEASE

0201:U: 08/01/14 15:47:09:72 00 106 1 RR 0 ... 003

0202:U: 08/01/14 15:47:09:73 00 106 0 I 0 002 003 08 1 01 0 RELEASE COMPLETE

CAUSE (08) 02 81 90




0203:N: 08/01/14 15:47:09:74 00 106 0 RR 0 ... 003

0204:N: 08/01/14 15:47:11:84 00 106 1 DISC 1 ... ...

0205:U: 08/01/14 15:47:11:85 00 106 1 UA 1 ... ...







Layer 2 establishment The layer two establishment conforms to the

standard with TEI = 0.

Despites the layer 2 is established the XIVO

board does not answer to the TEI check

request.

Cf Anomaly Report 4

Outgoing Calls All the outgoing calls are rejected with a

cause value 21 (Call rejected from the

Network).

If we perform the test with the same Layer 2

configuration, the call is accepted.

The main difference seems to come from the

fact that the Argus is answering to the

Identity check from the network.






Outgoing Call full trace

0005:U: 08/01/14 15:28:39:91 00 000 0 SABME 1 ... ...

0006:N: 08/01/14 15:28:39:92 00 000 0 UA 1 ... ...

0007:N: 08/01/14 15:28:42:72 63 127 1 UI 0 ... ... 15 00000 ID check requ. 127

0008:N: 08/01/14 15:28:43:74 63 127 1 UI 0 ... ... 15 00000 ID check requ. 127

0009:N: 08/01/14 15:28:49:91 00 000 1 RR 1 ... 000

0010:U: 08/01/14 15:28:49:91 00 000 1 RR 1 ... 000

0011:U: 08/01/14 15:28:59:91 00 000 0 RR 1 ... 000

0012:N: 08/01/14 15:28:59:92 00 000 0 RR 1 ... 000

0013:N: 08/01/14 15:29:03:96 63 127 1 UI 0 ... ... 15 00000 ID check requ. 127

0014:N: 08/01/14 15:29:04:98 63 127 1 UI 0 ... ... 15 00000 ID check requ. 127

0015:U: 08/01/14 15:29:09:93 00 000 0 RR 1 ... 000

0016:N: 08/01/14 15:29:09:94 00 000 1 RR 1 ... 000

0017:N: 08/01/14 15:29:09:94 00 000 0 RR 1 ... 000

0018:U: 08/01/14 15:29:09:94 00 000 1 RR 1 ... 000

0019:U: 08/01/14 15:29:11:69 00 000 0 I 0 000 000 08 1 01 0 SETUP










prefer./exclus.: preferred









CALLED PARTY NUMB. (70) 05 80 33 30 30 30





0020:N: 08/01/14 15:29:11:71 00 000 0 RR 0 ... 001

0021:N: 08/01/14 15:29:11:81 00 000 1 I 0 000 001 08 1 01 1 RELEASE COMPLETE

CAUSE (08) 02 87 95


location : international network

cause : Call rejected #21

0022:U: 08/01/14 15:29:11:82 00 000 1 RR 0 ... 001

0023:N: 08/01/14 15:29:13:81 00 000 1 DISC 1 ... ...






Anomaly

Report 5

In PP mode, L1 Ignore L2 leave_down all the outgoing calls are rejected by

the network (21). Then the trace in the log file of the XIVO is not consistant

(awaiting TEI when you are in PP mode)

Incoming Calls The incoming calls are sucessfull with a

complete Layer 2 establishment

0083:U: 08/01/14 15:39:25:67 00 000 0 SABME 1 ... ...

0084:N: 08/01/14 15:39:25:68 00 000 0 UA 1 ... ...

0085:N: 08/01/14 15:39:27:11 63 127 1 UI 0 ... ... 15 00000 ID check requ. 127

0086:N: 08/01/14 15:39:28:14 63 127 1 UI 0 ... ... 15 00000 ID check requ. 127

0087:N: 08/01/14 15:39:28:35 00 127 1 UI 0 ... ... 08 1 0C 0 SETUP
























screening ind. : network provided






0088:U: 08/01/14 15:39:28:36 00 000 0 I 0 000 000 08 1 0C 1 CALL PROCEEDING







0089:N: 08/01/14 15:39:28:37 00 000 0 RR 0 ... 001

0090:U: 08/01/14 15:39:28:86 00 000 0 I 0 001 000 08 1 0C 1 ALERTING

PROGRESS INDICATOR (1E) 02 81 88








description : In band information or app. pattern now available

0091:N: 08/01/14 15:39:28:87 00 000 0 RR 0 ... 002

0092:U: 08/01/14 15:39:31:40 00 000 0 I 0 002 000 08 1 0C 1 CONNECT










description : Destination address is non ISDN

CONNECTED NUMBER (4C) 06 00 80 31 30 30 31






0093:N: 08/01/14 15:39:31:41 00 000 0 RR 0 ... 003

0094:N: 08/01/14 15:39:31:70 00 000 1 I 0 000 003 08 1 0C 0 CONNECT ACK

0095:U: 08/01/14 15:39:31:71 00 000 1 RR 0 ... 001

0096:U: 08/01/14 15:39:37:38 00 000 0 I 0 003 001 08 1 0C 1 DISCONNECT

CAUSE (08) 02 81 90




0097:N: 08/01/14 15:39:37:39 00 000 0 RR 0 ... 004

0098:N: 08/01/14 15:39:37:67 00 000 1 I 0 001 004 08 1 0C 0 RELEASE

0099:U: 08/01/14 15:39:37:68 00 000 1 RR 0 ... 002

0100:U: 08/01/14 15:39:37:69 00 000 0 I 0 004 002 08 1 0C 1 RELEASE COMPLETE

CAUSE (08) 02 81 90




0101:N: 08/01/14 15:39:37:70 00 000 0 RR 0 ... 005

0102:N: 08/01/14 15:39:39:78 00 000 1 DISC 1 ... ...

0103:U: 08/01/14 15:39:39:79 00 000 1 UA 1 ... ...






6.3. XIVO facing TNR6G Layer 1 Ignore Layer 2 Keep Up


Outgoing Calls Primitive TEI Management in the XIVO log

file but nothing is happening on the S0

interface.

Difficulties to set up outgoing calls from

scratch.

Outgoing call procedure is using two SETUP

and has some difficulties to manage Call

Context

Outgoing calls are finished with a Release complete message with a cause stating Invalid Call

reference value coming from the User (XIVO).






The Call Proceeding is answering to the first SETUP messages (Cref : 07). It is refused by the

XIVO. This may be a problem of timer.

Anomaly

Report 6

In case of multiple outgoing calls with a delayed network response the

XIVO (through dahdi) is not managing properly the Call Ref and rejects

some calls.

Incoming Calls Seems to be OK.

If you perform an outgoing call just after an

incoming it works then.

N: 08/01/14 16:14:00:52 U,Normal call clearing #16 B1

16:13:49:97 647882108 7530 0012

speech

16:13:57:29 3 sec

****************************************************************************

N: 0:00 00 127 1 UI 0 ... ... 08 1 12 0 SETUP






Two

SETUP

with Call

Ref : 07

Two

SETUP

with Call

Ref : 08
























screening ind. : network provided






U: 2:51 00 108 0 I 0 004 000 08 1 12 1 CALL PROCEEDING







U: 2:53 00 108 0 I 0 005 000 08 1 12 1 ALERTING




description : In band information or app. pattern now available

U: 7:32 00 108 0 I 0 007 002 08 1 12 1 CONNECT










description : Destination address is non ISDN

CONNECTED NUMBER (4C) 06 00 80 31 30 30 31











N: 7:65 00 108 1 I 0 002 008 08 1 12 0 CONNECT ACK

U: 10:25 00 108 0 I 0 008 003 08 1 12 1 DISCONNECT

CAUSE (08) 02 81 90




N: 10:54 00 108 1 I 0 003 009 08 1 12 0 RELEASE

U: 10:55 00 108 0 I 0 009 004 08 1 12 1 RELEASE COMPLETE

CAUSE (08) 02 81 90









request.

Cf Anomaly Report 4

Outgoing Calls Unsuccessfull.

When we try to setup outgoing calls there is

no activity in the S0 bus. No Layer 1

activation and no layer 2 either.

After an incoming call it is possible to place

an outgoing call. the outgoing calls is one

more time rejected with a cause value 21

(Call rejected from the Network).

This can be linked to the non answering to

TEI management.

Incominng Calls Successfull.






6.4. XIVO facing TNR6G Layer 1 Required Layer 2 Keep Up


Layer 2 establishment Conforms to the standard


There is no signalling for outgoing calls.

Nothing happens when we off hook the IP

Phones.

After one incoming call it is again possible to

place outgoing calls.

0146:L: 08/01/14 16:45:33:79 N->U :INFO 4 U->N :INFO 0

0147:L: 08/01/14 16:45:33:80 N->U :INFO 0 U->N :INFO 0

0148:L: 08/01/14 16:45:33:84 PS1 DISCONNECTION

0149:L: 08/01/14 16:45:33:84 N->U :INFO 0 U->N :INFO 1

0150:L: 08/01/14 16:47:19:59 PS1 CONNECTION

0151:L: 08/01/14 16:48:19:54 N->U :INFO 2 U->N :INFO 1

0152:L: 08/01/14 16:48:19:54 N->U :INFO 2 U->N :INFO 3

Incoming Calls According to the trace there is an incoming

call from the network.

The channel selected by the network is the

B1 channel.

The XIVO answer is a release with no

channel available. But there is no other active

calls.

The XIVO log is again not consistent.

Anomaly

Report 7

In point to multipoint configuration PMP Mode the XIVO sometimes rejects

calls with a « no circuit available » cause value that is not consistant.











request.

Cf Anomaly Report 4


The outgoing calls is one more time rejected

with a cause value 21 (Call rejected from the






Network).

This can be linked to the non answering to

TEI management.

The layer 1 is not stable.

After incoming call it is again possible to

place outgoing calls

Incominng Calls Successfull.






7. Conclusions

The test performed facing the TNR-6G are providing the following anomaly reports

synthesis :

Anomaly Report 1

(L1R,L2MD,PMP)

The XIVO rejects the call in PMP with a cause value 44 (circuit not

avaible). This is not standard and nor understandable. This cause is a

network cause and then no channel are assigned on the S-Bus

Anomaly Report 2

(L1R,L2LD,PP)

The XIVO is not activating the layer 1 at the S0 interface. The logs are

not consistant as the system is stating layer 1 and layer 2 activation but

nothing is happening on the S bus.

Anomaly Report 3

(L1R,L2LD,PP)

The XIVO rejects the call in PP with a cause value 44 (circuit not

avaible). This is not standard and nor understandable. This cause is a

network cause and then no channel are assigned on the S-Bus

Anomaly Report 4

The XIVO when configured in PP mode TEI = 0 does not answer to the

TEI check request with Ai value (127) from the network.

Anomaly Report 5 In PP mode, L1 Ignore L2 leave_down all the outgoing calls are

rejected by the network (21). Then the trace in the log file of the XIVO

is not consistant (awaiting TEI when you are in PP mode)

Anomaly Report 6 In case of multiple outgoing calls with a delayed network response the

XIVO (through dahdi) is not managing properly the Call Ref and

rejects some calls.

Anomaly Report 7 In point to multipoint configuration PMP Mode the XIVO sometimes

rejects calls with a « no circuit available » cause value that is not

consistant.

As a summary we can notice the following points :

Point to point mode (TEI 0) :

The system does not work properly in Point to Point mode,

The layer 1 is not stable,

The system is not providing any answer to the TEI check

Following this the outgoing calls on a TEI = 0 are unsuccessful with a release

cause 21 (call rejected)

The system is often not able to activate the Layer 1 and the S Bus and in that

case the logfile is not correct in comparison to the IDSN analyser traces






Point to Multi point mode :

During the tests we encoutered some troubles with the Call references and with

the circuit assignment management from the TE side.

The PMP mode seems to be more stable despite it is not the logical

configuration for a PBX acting as NT2 in the standard.






As a general remark the difference between the TNR6G from Elcon and the

others NT1 is that one is self powered from the network. It may happen that the

Digium board is perturbing the Layer 1 caracteristics of the NT1 (power

consumption or bad impedance)

rapport d'audit avencall 8 janvier 2014 - asterisk...document date 11/01/2014 département rd...

Documents