E1 problem

[Julio Saldivar]

Dear, I have the problem when making a call to the PSTN, I get a busy tone, this is the log:

Jan 13 12:53:02 1.1.6.240 5704072: 553122: Jan 13 14:53:07.487: ISDN Se0/3/0:15 Q931: TX -> SETUP pd = 8  callref = 0x182C

Jan 13 12:53:02 1.1.6.240 5704073: ^ISending Complete

Jan 13 12:53:02 1.1.6.240 5704074: ^IBearer Capability i = 0x8090A3

Jan 13 12:53:02 1.1.6.240 5704075: ^I^IStandard = CCITT

Jan 13 12:53:02 1.1.6.240 5704076: ^I^ITransfer Capability = Speech 

Jan 13 12:53:02 1.1.6.240 5704077: ^I^ITransfer Mode = Circuit

Jan 13 12:53:02 1.1.6.240 5704078: ^I^ITransfer Rate = 64 kbit/s

Jan 13 12:53:02 1.1.6.240 5704079: ^IChannel ID i = 0xA98381

Jan 13 12:53:02 1.1.6.240 5704080: ^I^IExclusive, Channel 1

Jan 13 12:53:02 1.1.6.240 5704081: ^IProgress Ind i = 0x8183 - Origination address is non-ISDN

Jan 13 12:53:03 1.1.6.240 5704082: 

Jan 13 12:53:03 1.1.6.240 5704083: ^ICalling Party Number i = 0x0180, '333'

Jan 13 12:53:03 1.1.6.240 5704084: ^I^IPlan:ISDN, Type:Unknown

Jan 13 12:53:03 1.1.6.240 5704085: ^ICalled Party Number i = 0x81, '9860327'

Jan 13 12:53:03 1.1.6.240 5704086: ^I^IPlan:ISDN, Type:Unknown

Jan 13 12:53:03 1.1.6.240 5704087: 553123: Jan 13 14:53:07.543: ISDN  Se0/3/0:15 Q931: RX <- CALL_PROC pd = 8  callref = 0x982C

Jan 13 12:53:03 1.1.6.240 5704088: ^IChannel ID i = 0xA98381

Jan 13 12:53:03 1.1.6.240 5704089: ^I^IExclusive, Channel 1

Jan 13 12:53:03 1.1.6.240 5704090: 553124: Jan 13 14:53:08.187: ISDN  Se0/3/0:15 Q931: RX <- DISCONNECT pd = 8  callref = 0x982C  
Jan 13 12:53:03 1.1.6.240 5704091: ^ICause i = 0x82A200000000 - No circuit/channel available

How about you? Problems of the telco?

[danielwiebe]

Is this a full E1?  ie 1 to 31 time slots? If not have you programmed that into the uc500 so it doesn't try to send calls out non working time slots?

[Julio Saldivar]

is fractional E1, the configuration is:

controller E1 0/3/0

framing NO-CRC4

pri-group timeslots 1-16

process-max-time 50

Can it be problem of UC500? or the PSTN?

[Daniele Giordano]

Can you post also the config of your Serial interface? And the output of command "show controller e1" too?

Is ther the command "isdn negotiate-bchan" ?

Try to add it.

Is the calling number "333" forwarded to the provider right?

Some providers uses "Calling Number White List" technics to block unauthorized calls.

Regards.

[Julio Saldivar]

estimated, the problems are some times, but not overloading the UC500, which can happen when there is only one or two calls.

UC520#sh controllers e1

E1 0/3/0 is up.

  Applique type is Channelized E1 - balanced

  No alarms detected.

  alarm-trigger is not set

  Version info Firmware: 20090408, FPGA: 13, spm_count = 0

  Framing is NO-CRC4, Line Code is HDB3, Clock Source is Line.

  Data in current interval (389 seconds elapsed):

     0 Line Code Violations, 0 Path Code Violations

     0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins

     0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs

  Total Data (last 24 hours)

     0 Line Code Violations, 0 Path Code Violations,

     0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins,

     0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs

[Julio Saldivar]

are random problems

[paolo bevilacqua]

Whne this happens in addition to debug isdn q931, can you take "show isdn status"

Also please include "show run int s0/3/0:16£. That is because you're sending out the call on channel 1, but it should 15.

[Julio Saldivar]

not think it's estimated that, on another call that occupies the same channel and the call occurs.  to me it gives the impression that the PSTN problem.  Could it be congestion in the PSTN?

Jan 19 08:58:53 1.1.6.240 5734527: 568168: Jan 19 10:59:00.052: ISDN Se0/3/0:15 Q931: TX -> SETUP pd = 8  callref = 0x1A11

Jan 19 08:58:54 1.1.6.240 5734528: ^ISending Complete

Jan 19 08:58:54 1.1.6.240 5734529: ^IBearer Capability i = 0x8090A3

Jan 19 08:58:54 1.1.6.240 5734530: ^I^IStandard = CCITT

Jan 19 08:58:54 1.1.6.240 5734531: ^I^ITransfer Capability = Speech 

Jan 19 08:58:54 1.1.6.240 5734532: ^I^ITransfer Mode = Circuit

Jan 19 08:58:54 1.1.6.240 5734533: ^I^ITransfer Rate = 64 kbit/s

Jan 19 08:58:54 1.1.6.240 5734534: ^IChannel ID i = 0xA98381

Jan 19 08:58:54 1.1.6.240 5734535: ^I^IExclusive, Channel 1

Jan 19 08:58:54 1.1.6.240 5734536: ^IProgress Ind i = 0x8183 - Origination address is non-ISDN

Jan 19 08:58:54 1.1.6.240 5734537: 

Jan 19 08:58:54 1.1.6.240 5734538: ^ICalling Party Number i = 0x0180, '333'

Jan 19 08:58:54 1.1.6.240 5734539: ^I^IPlan:ISDN, Type:Unknown

Jan 19 08:58:54 1.1.6.240 5734540: ^ICalled Party Number i = 0x81, '6233373'

Jan 19 08:58:54 1.1.6.240 5734541: ^I^IPlan:ISDN, Type:Unknown

Jan 19 08:58:54 1.1.6.240 5734542: 568169: Jan 19 10:59:00.120: ISDN Se0/3/0:15 Q931: RX <- CALL_PROC pd = 8  callref = 0x9A11

Jan 19 08:58:54 1.1.6.240 5734543: ^IChannel ID i = 0xA98381

Jan 19 08:58:54 1.1.6.240 5734544: ^I^IExclusive, Channel 1

Jan 19 08:58:54 1.1.6.240 5734545: 568170: Jan 19 10:59:00.780: ISDN Se0/3/0:15 Q931: RX <- ALERTING pd = 8  callref = 0x9A11

Jan 19 08:58:55 1.1.6.240 5734546: ^IProgress Ind i = 0x8282 - Destination address is non-ISDN 

Jan 19 08:58:55 1.1.6.240 5734547: ^IProgress Ind i = 0x8288 - In-band info or appropriate now available

Jan 19 08:58:55 1.1.6.240 5734548: 568171: Jan 19 10:59:01.384: ISDN Se0/3/0:15 Q931: RX <- CONNECT pd = 8  callref = 0x9A11

Jan 19 08:58:55 1.1.6.240 5734549: ^IProgress Ind i = 0x8282 - Destination address is non-ISDN 

Jan 19 08:58:55 1.1.6.240 5734550: ^IDate/Time i = 0x0C0113083A36

Jan 19 08:58:55 1.1.6.240 5734551: ^I^IDate (dd-mm-yr)   = 12-01-19

Jan 19 08:58:55 1.1.6.240 5734552: ^I^ITime (hr:mnt:sec) = 08:58:54

Jan 19 08:58:55 1.1.6.240 5734553: 568172: Jan 19 10:59:01.384: %ISDN-6-CONNECT: Interface Serial0/3/0:0 is now connected to 6233373 N/A

Jan 19 08:58:55 1.1.6.240 5734554: 568173: Jan 19 10:59:01.384: ISDN Se0/3/0:15 Q931: TX -> CONNECT_ACK pd = 8  callref = 0x1A11

[paolo bevilacqua]

Please take the steps indicated above first.

[David Trad]

HI Julio,

Can you please elaborate a little further on the following:

• Was this system configured using CCA or CLI? This will determine which direction to head with changes and modifications
• Is the issue more pertinent when making the first attempt you get busy tone (Cause 34) and then immediatly after make another attempt and it then proceeds to dial out?
• Is your outbound dial-string (Dial-Peer configuration) in-line with how the carrier expects the numbers to be presented?
• If created using CLI does the configuration have the right clock timers appropriately set?
• What country are you in?

That will be a good start to work of, debugging a PRI circuit will only yield you so much information, you may need to get nitty and gritty and debug your dial-peers, timers, Voice CCAPI etc..etc..

But what needs to be done is determined on how the system was originally configured and some answers to the questions above.

Lastly have you logged a support case yet with SBSC?

Cheers,

David.