Problem with incoming ISDN calls on PRI E1

Unanswered Question
Feb 5th, 2009

Hi,

I've got here a strange problem with a customer where at the moment 2 persons can't dial in to any phone extension. All other people can dial in without any problem.

What I see on the gateway is the following:

037221: Feb 3 13:04:04.402 GMT: ISDN Se0/0/0:15 Q931: RX <- SETUP pd = 8 callref = 0x438E

Bearer Capability i = 0x8090A3

Standard = CCITT

Transfer Capability = Speech

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0xA98394

Exclusive, Channel 20

Calling Party Number i = 0x2181, '2819520800'

Plan:ISDN, Type:National

Called Party Number i = 0xC1, '818'

Plan:ISDN, Type:Subscriber(local)

High Layer Compat i = 0x9181

037222: Feb 3 13:04:04.410 GMT: ISDN Se0/0/0:15 Q931: TX -> SETUP_ACK pd = 8 callref = 0xC38E

Channel ID i = 0xA98394

Exclusive, Channel 20

037223: Feb 3 13:04:04.418 GMT: ISDN Se0/0/0:15 Q931: TX -> DISCONNECT pd = 8 callref = 0xC38E

Cause i = 0x8090 - Normal call clearing

037224: Feb 3 13:04:04.466 GMT: ISDN Se0/0/0:15 Q931: RX <- RELEASE pd = 8 callref = 0x438E

037225: Feb 3 13:04:04.470 GMT: ISDN Se0/0/0:15 Q931: TX -> RELEASE_COMP pd = 8 callref = 0xC38E

The Number he is dialing is either 0281 818 157 or 818 157 from the same local region.

See relevant config as attachment.

5 seconds for overlap receiving should be enough and i can see other calls successfully get connected with overlap receiving:

039791: Feb 3 15:18:17.636 GMT: ISDN Se0/0/0:15 Q931: TX -> RELEASE_COMP pd = 8 callref = 0xC44E

039792: Feb 3 15:18:28.164 GMT: ISDN Se0/0/0:15 Q931: RX <- SETUP pd = 8 callref = 0x444F

Bearer Capability i = 0x9090A3

Standard = CCITT

Transfer Capability = 3.1kHz Audio

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0xA9839B

Exclusive, Channel 27

Calling Party Number i = 0x2180, '3039735264'

Plan:ISDN, Type:National

Calling Party Number i = 0x2183, '30397350'

Plan:ISDN, Type:National

Called Party Number i = 0xC1, '8181'

Plan:ISDN, Type:Subscriber(local)

039793: Feb 3 15:18:28.168 GMT: ISDN Se0/0/0:15 Q931: TX -> SETUP_ACK pd = 8 callref = 0xC44F

Channel ID i = 0xA9839B

Exclusive, Channel 27

039794: Feb 3 15:18:28.620 GMT: ISDN Se0/0/0:15 Q931: RX <- INFORMATION pd = 8 callref = 0x444F

Called Party Number i = 0xC1, '5'

Plan:ISDN, Type:Subscriber(local)

039795: Feb 3 15:18:28.880 GMT: ISDN Se0/0/0:15 Q931: RX <- INFORMATION pd = 8 callref = 0x444F

Called Party Number i = 0xC1, '7'

Plan:ISDN, Type:Subscriber(local)

039796: Feb 3 15:18:29.300 GMT: ISDN Se0/0/0:15 Q931: TX -> CALL_PROC pd = 8 callref = 0xC44F

039797: Feb 3 15:18:29.308 GMT: ISDN Se0/0/0:15 Q931: TX -> ALERTING pd = 8 callref = 0xC44F

Also, they say that they first dial the number and than they push a dial button, so this indicates that the other end is sending complete.

Also see a CCAPI Debug as attachment.

For some reason the called number is not complete. what can be done to solve this issue?

cheers,

Bernhard

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Nicholas Matthews Thu, 02/05/2009 - 06:25

Hi Bernhard,

You are correct - 5 seconds should be enough for overlap receiving.

If we're not getting the digits in time - we're just not getting the digits in time.

Have you spoken with your provider about this?

-nick

Ayodeji Okanlawon Thu, 02/05/2009 - 06:38

Hi,

what is simply happening is that your telco is sending 4 digits. This is fairly common.I believe your best option is to work around this 4 digits. Since your extension numbers are 3 digits numbers, you can easily strip off the extra 1 digit.. You can adjust your xlation rule to look like this...

voice translation-rule 2

rule 1 /^8180/ /199/

rule 2 /^8/ //

!

Bernardo34 Thu, 02/05/2009 - 06:50

The one with 4 digits was successfully connected. The first debug was sending 3 digits without the DDI and this one is not connecting:

Bearer Capability i = 0x8090A3

Standard = CCITT

Transfer Capability = Speech

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0xA98394

Exclusive, Channel 20

Calling Party Number i = 0x2181, '2819520800'

Plan:ISDN, Type:National

Called Party Number i = 0xC1, '818'

Plan:ISDN, Type:Subscriber(local)

High Layer Compat i = 0x9181

There is simply the DDI missing. Also they say that they where able to dial in before the cisco gateway has been installed, so asking the provider might not help, but i will try...

Paolo Bevilacqua Thu, 02/05/2009 - 08:37

Hi, can you add

network-clock-participate wic 0

network-clock-select 1 e1 0/0/0

A bit unlikely because q921 should take care of that, but might have slips and not getting all the messages.

Bernardo34 Fri, 02/06/2009 - 00:41

This is already been configured. I haven't add this to my config fragment i've posted here... sry

I've spoken with the telco provider and they say everything is fine. My next try would be to get them calling another cisco gateway and see if there is the same problem. If they can't dial in to any cisco gateway then the problem is not with the telco i would guess...

Bernardo34 Fri, 02/06/2009 - 00:48

ok. to which version? I am using c2800nm-spservicesk9-mz.124-15.T8 at the moment.

Bernardo34 Fri, 02/06/2009 - 05:45

I got them now to call two other cisco gateways. One with the same version and one with version 12.4.15T5. For all these gateways there is no problem at all... The config of the dial peers is nearly the same and they are all PRI's aswell.

So the problem must be with the telco?

One more thing... i don't think this might be a reason, but it is worth mentioninig. The Telco's PRI had no RJ45 port attached. Instead of i had to wire manually 4 wires (Pins 1+2 and Pins 4+5)to the S2M Bus. I would guess that if my cabling was wrong, then there wouldn't be a Multiple_Frame_Established status at ISDN status and we would have more users complaining about that problem. An if there would be a slack joint then we would have intermediant connection who work and something not, but only just these 2 persons (we know off) got never a connection...

The only difference i can see between the gateways is the hardware. The one that has these problems is a 2851 and the other gateways are 2811 and 2821...

I don't think that a IOS Upgrade will help, but i'll try that.

cheers,

Bernhard

Paolo Bevilacqua Fri, 02/06/2009 - 06:07

Hi, of course cabling doesn't matter unless you have errors. Like you have noticed, cisco GWs behaves correctly since many years all over the world.

As Nick said, if router is not getting the digits, it's not getting them, so it's for telco to investigate.

Actions

This Discussion