Re: Layer 2 BRI Problems

victorgarciaternero · ‎01-25-2008

Hi, I have configured a VIC2-2BRI-NT/TE in a 2801 Voice Gateway (IOS 12.4(11)T4) placed in Lisboa (the operator is TELEPAC), and I can't make inbound/outbound calls. The interface config is:

interface BRI0/2/0

no ip address

isdn switch-type basic-net3

isdn overlap-receiving

isdn point-to-point-setup

isdn incoming-voice voice

!

The 'sh isdn status' command:

Global ISDN Switchtype = basic-net3

ISDN BRI0/2/0 interface

dsl 4, interface ISDN Switchtype = basic-net3

Layer 1 Status:

ACTIVE

Layer 2 Status:

TEI = 66, Ces = 1, SAPI = 0, State = TEI_ASSIGNED

Layer 3 Status:

0 Active Layer 3 Call(s)

Active dsl 4 CCBs = 0

The Free Channel Mask: 0x80000003

And the 'debug isdn q921':

*Jan 25 13:29:40.480: BRI0/2/0 : Unexpected indication (4) in f3 code

*Jan 25 13:29:40.484: ISDN BR0/2/0 Q921: L2_EstablishDataLink: sending SABME

*Jan 25 13:29:40.484: ISDN BR0/2/0 Q921: User TX -> SABMEp sapi=0 tei=66

*Jan 25 13:29:40.496: ISDN BR0/2/0 Q921: User RX <- DMf sapi=0 tei=66

*Jan 25 13:29:45.380: ISDN BR0/2/0 Q921: User RX <- SABMEp sapi=0 tei=0

*Jan 25 13:29:46.380: ISDN BR0/2/0 Q921: User RX <- SABMEp sapi=0 tei=0

*Jan 25 13:29:47.380: ISDN BR0/2/0 Q921: User RX <- SABMEp sapi=0 tei=0

*Jan 25 13:29:48.376: ISDN BR0/2/0 Q921: User RX <- SABMEp sapi=0 tei=0

*Jan 25 13:29:49.388: ISDN BR0/2/0 Q921: User RX <- IDCKRQ ri=0 ai=0

*Jan 25 13:29:50.384: ISDN BR0/2/0 Q921: User RX <- IDCKRQ ri=0 ai=0

*Jan 25 13:30:01.376: ISDN BR0/2/0 Q921: User RX <- SABMEp sapi=0 tei=0

*Jan 25 13:30:02.384: ISDN BR0/2/0 Q921: User RX <- SABMEp sapi=0 tei=0

*Jan 25 13:30:03.380: ISDN BR0/2/0 Q921: User RX <- SABMEp sapi=0 tei=0

*Jan 25 13:30:04.384: ISDN BR0/2/0 Q921: User RX <- SABMEp sapi=0 tei=0

*Jan 25 13:30:05.388: ISDN BR0/2/0 Q921: User RX <- IDCKRQ ri=0 ai=0

*Jan 25 13:30:06.388: ISDN BR0/2/0 Q921: User RX <- IDCKRQ ri=0 ai=0

*Jan 25 13:30:17.380: ISDN BR0/2/0 Q921: User RX <- SABMEp sapi=0 tei=0

*Jan 25 13:30:18.384: ISDN BR0/2/0 Q921: User RX <- SABMEp sapi=0 tei=0

*Jan 25 13:30:19.384: ISDN BR0/2/0 Q921: User RX <- SABMEp sapi=0 tei=0

*Jan 25 13:30:20.384: ISDN BR0/2/0 Q921: User RX <- SABMEp sapi=0 tei=0

*Jan 25 13:30:21.388: ISDN BR0/2/0 Q921: User RX <- IDCKRQ ri=0 ai=0

*Jan 25 13:30:22.392: ISDN BR0/2/0 Q921: User RX <- IDCKRQ ri=0 ai=0

I have not idea to solve this issue. Has anybody any idea?

Thanks.

Regards.

paolo bevilacqua · ‎01-25-2008

Hi, likely you have multiple lines under same number, or DID ?

Anyway, try under int bri: shutdown, isdn static-tei 0, no shutdown.

Hope this helps, please rate post if it does!

victorgarciaternero · ‎01-25-2008

Hi, I don't know the lines features of de BRI. How can it influence in the configuration?

I have made the change in the interface (isdn static-tei 0), and now the layer 2 shows multiple_frame_established:

Global ISDN Switchtype = basic-net3

ISDN BRI0/2/0 interface

dsl 4, interface ISDN Switchtype = basic-net3

Layer 1 Status:

ACTIVE

Layer 2 Status:

TEI = 0, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED

Layer 3 Status:

0 Active Layer 3 Call(s)

Active dsl 4 CCBs = 0

The Free Channel Mask: 0x80000003

But when I do a call I can hear a very noisely voice (I think it is an autoattendand console, but I can not understand anything). This is the output of the 'debug isdn q931' command:

*Jan 25 22:46:09.697: ISDN BR0/2/0 Q931: Applying typeplan for sw-type 0x1 is 0x

0 0x0, Calling num 3017

*Jan 25 22:46:09.701: ISDN BR0/2/0 Q931: Applying typeplan for sw-type 0x1 is 0x

0 0x0, Called num 217805000

*Jan 25 22:46:09.701: ISDN BR0/2/0 Q931: TX -> SETUP pd = 8 callref = 0x0C

Bearer Capability i = 0x8090A3

Standard = CCITT

Transfer Capability = Speech

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0x81

Preferred, B1

Calling Party Number i = 0x0081, '3017'

Plan:Unknown, Type:Unknown

Called Party Number i = 0x80, '217805000'

Plan:Unknown, Type:Unknown

*Jan 25 22:46:09.917: ISDN BR0/2/0 Q931: RX <- SETUP_ACK pd = 8 callref = 0x8C

Channel ID i = 0x89

Exclusive, B1

*Jan 25 22:46:09.977: ISDN BR0/2/0 Q931: RX <- CALL_PROC pd = 8 callref = 0x8C

Display i = 'CHAMADA EM PROGRESSO'

*Jan 25 22:46:10.505: ISDN BR0/2/0 Q931: RX <- ALERTING pd = 8 callref = 0x8C

Progress Ind i = 0x8488 - In-band info or appropriate now available

Display i = 'A CHAMAR'

*Jan 25 22:46:10.581: ISDN BR0/2/0 Q931: RX <- CONNECT pd = 8 callref = 0x8C

Display i = 'IMPULSOS = 2'

Date/Time i = 0x0801191630

Date (yr-mm-dd) = 08-01-25

Time (hr:mnt:sec) = 22:48:76

Connected Number i = 0x0083, '217805000'

*Jan 25 22:46:10.585: %ISDN-6-CONNECT: Interface BRI0/2/0:1 is now connected to

N/A N/A

*Jan 25 22:46:10.585: ISDN BR0/2/0 Q931: TX -> CONNECT_ACK pd = 8 callref = 0x0

C

*Jan 25 22:46:10.613: ISDN BR0/2/0 Q931: RX <- FACILITY pd = 8 callref = 0x8C

Facility i = 0x91A1130202906E020122300AA1053003020102820100

Protocol Profile = Remote Operations Protocol

0xA1130202906E020122300AA1053003020102820100

Component = Invoke component

Invoke Id = 36974

Operation = AOCDChargingUnit

*Jan 25 22:46:15.577: ISDN BR0/2/0 Q931: RX <- INFORMATION pd = 8 callref = 0x8

C

Display i = 'IMPULSOS = 2'

*Jan 25 22:46:35.317: %ISDN-6-DISCONNECT: Interface BRI0/2/0:1 disconnected fro

m unknown , call lasted 24 seconds

*Jan 25 22:46:35.317: ISDN BR0/2/0 Q931: TX -> DISCONNECT pd = 8 callref = 0x0C

Cause i = 0x8090 - Normal call clearing

*Jan 25 22:46:35.465: ISDN BR0/2/0 Q931: RX <- RELEASE pd = 8 callref = 0x8C

Facility i = 0x91A1130202906F020122300AA1053003020102820101

Protocol Profile = Remote Operations Protocol

0xA1130202906F020122300AA1053003020102820101

Component = Invoke component

Invoke Id = 36975

Operation = AOCDChargingUnit

Display i = 'IMPULSOS = 2'

*Jan 25 22:46:35.469: ISDN BR0/2/0 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x

0C

When the call is connected, the telnet window to the router stops working, and when the call is finished it works again. How can I solve that?

Regards.

paolo bevilacqua · ‎01-25-2008

Hi,

under bri interface:

compand-type a-law

The stopping terminal is too strange. Suggest you upgrade to 12.4(11)XJ that works fine.

As an appreciation to those providing answers, please rate posts using the scrollbox below!

victorgarciaternero · ‎01-26-2008

Hi, this is the configuration of the voice-port:

voice-port 0/2/0

compand-type a-law

connection plar 1500

The compand-type is the first thing I thought, but in u-law the call is refused, so it may be another problem.

victorgarciaternero · ‎01-26-2008

Hi, here you have the network scheme:

ADSLoISDN--|Transparent Bridge|---(fa0/1)|2801|

BRI_____|_____________________________|(VIC2-2BRI-NT/TE)

I thing that the call proceed ok, but the quality is very poor, we can hear a metalic non understable voice. We are making the call with an IP Communicator located in another site (in Spain), and accesing through a VPN tunnel to the ADSLoISDN. We have performed a ping test, and when the call is connected the data rate thorugh the ADSLoISDN line almost stops. When we finish the call the data rate is restored:

Respuesta desde X.X.X.X: bytes=32 tiempo=114ms TTL=241

Respuesta desde X.X.X.X: bytes=32 tiempo=120ms TTL=241

Respuesta desde X.X.X.X: bytes=32 tiempo=113ms TTL=241

Respuesta desde X.X.X.X: bytes=32 tiempo=118ms TTL=241

Respuesta desde X.X.X.X: bytes=32 tiempo=203ms TTL=241

Respuesta desde X.X.X.X: bytes=32 tiempo=1097ms TTL=241

Tiempo de espera agotado para esta solicitud.

Respuesta desde X.X.X.X: bytes=32 tiempo=773ms TTL=241

Respuesta desde X.X.X.X: bytes=32 tiempo=116ms TTL=241

Respuesta desde X.X.X.X: bytes=32 tiempo=120ms TTL=241

Respuesta desde X.X.X.X: bytes=32 tiempo=113ms TTL=241

Respuesta desde X.X.X.X: bytes=32 tiempo=118ms TTL=241

Is it possible that when we make a phone call through the isdn there is no enough bandwidth for data traffic in the ADSLoISDN line?

Thanks in advanced.

Regards.

paolo bevilacqua · ‎01-27-2008

Hi, with the call active in g711, the bandwidth taken is like 90 kbps, possibly the connection is not fast enough in the upstream direction, it's dropping packets and the sound is poor. It would be much better if you get an HWIC-ADSLI so you can montir what's going one on the DSL, do some QoS, etc.

Now, when you press ? twice on the IP communicator there is a screen that tells you how many packtes are being late or lost.

Try configuring g729 under the IPCP ephone, that will reduce the bandwidth, but be aware, with even few packets lost the quality becomes bad.

victorgarciaternero · ‎01-27-2008

Hi, the codec used is G729 (because the call is across a WAN link). About the HWIC-ADSLI, we already have a HWIC-ADSL because the customer told us that the ADSL line was over POTS, but Telepac has installed the ADSL over ISDN, so the faster solution was to put a Linksys ADSLoISDN router as a transparent bridge between the the telco and the 2801 router. When Telepac install the ADSLoPOTS we will conect the HWIC-ADSL to the ADSL line.

These are the call statitics during a call:

Rcvr Codec: G729

Sender Codec: G729

TamaÃ±o del destinatario: 20 ms

TamaÃ±o del remitente: 20 ms

Rcvr Packets: 861

Sender Packets: 2324

Avg Jitter: 55

Max Jitter: 1716

Rcvr Discarded: 0

Rcvr Lost Packets: 1371

Viewing these statistics and the ping test I think that when I make a voice call the ADSLoISDN interface data rate reduces severely. Can I do anything to solve this problem or maybe it is a problem that the telco (Telepac) must resolve?

Tanks. Regards.

paolo bevilacqua · ‎01-27-2008

Hi,

I understand you are doing a VPN internationally, so is not said, but still possobile, that the packet loss is occurring at the DSL provider, you need to find where packets are lost. For sure somewhere there must be a problem, as a single g.729 call can't work.

victorgarciaternero · ‎01-28-2008

Hi, we are doing a VPN internationally (Spain, Portugal, Bulgary..) through DSL lines, and we have had problems only in Lisboa. But today the problem has solved automatically. I suppose the telco has changed something in its switches and routers configuration, so now everything is ok.

Thanks very much.

Best regards.

paolo bevilacqua · ‎01-28-2008

No hay porque', mucha suerte!