Buy or Renew
Buy or Renew
Cisco + Splunk: It’s a new day for your data. Learn more.
 
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Start a conversation
832
Views
0
Helpful
15
Replies

Primary loop

ivan aguilar
Level 1
Level 1

‎01-09-2012 03:42 AM - edited ‎03-16-2019 08:53 AM

Hi,

I have a PRI wich every day at differents times has a loop, when i check how many ports are available with "show voice call summary" i see all channel free for example, i wail a few seconds, repet the commands and almost all channel are occupated, I wait a second and are still all occupated, refresh and all free, etc.

Its looks like a loop because there is not a problem of number of channel ocupatted by users, any idea or commans to see if it is really a loop problem with this PRI??

Thanks.

Labels:
0 Helpful
15 Replies 15

paolo bevilacqua
Hall of Fame
Hall of Fame

‎01-09-2012 03:53 AM

You may have some phone that has call-forward to it's own PSTN number. That would cause the tromboning effect.

One way to find it is to take an ISDN trace to see the involved numbers.

0 Helpful

ivan aguilar
Level 1
Level 1
In response to paolo bevilacqua

‎01-10-2012 01:49 AM

Thanks, I will do tody a debug isdn q931 and check if could be a forward all or something else in the called numbers.

regards.

0 Helpful

Gordon Ross
Level 9
Level 9

‎01-09-2012 05:46 AM

If you look at the underlying serial interface, that will tell you if there really is a loop or not.

GTG

Please rate all helpful posts.
0 Helpful

ivan aguilar
Level 1
Level 1
In response to Gordon Ross

‎01-10-2012 01:50 AM

Hi Gordon,

I dont understand at all what you mean with "underlying serial interface", please could you explain it better?

Thanks and regards!

0 Helpful

Gordon Ross
Level 9
Level 9
In response to ivan aguilar

‎01-10-2012 02:09 AM 

I dont understand at all what you mean with "underlying serial interface", please could you explain it better?

PRI ISDN interfaces are made up of multiple layers in Cisco IOS.

At the top, you have, say, voice-port. This will usually be where you're handling voice traffic.

Below that you'll have a Controller. This speaks the ISDN protocol.

At the bottom, you'll have a serial interface. This does the work of sending/receiving the low-level data. PRI ISDN is based on a 2Mb/s serial connection (Or 1.5Mb/s)

Some snippets from an MGCP gateway of mine:

controller E1 0/1/0

pri-group timeslots 1-31 service mgcp

!

interface Serial0/1/0:15

no ip address

encapsulation hdlc

isdn switch-type primary-qsig

isdn incoming-voice voice

isdn bind-l3 ccm-manager

no cdp enable

!

voice-port 0/1/0:15

echo-cancel coverage 64

cptone GB

!

(Just bear in mind, that when a gateway is configured in MGCP mode, most of the grunt work is actually handled by CUCM not the IOS gateway)

BRI is much simplier in Cisco IOS: Just an interface of type "BRI" & a Voice-Port

So when I say look at the underlying serial interface, if you do a "sh int ser0/1/0:15" (For my gateway, at least) you'll get the traditional IOS Serial data dump:

Serial0/1/0:15 is up, line protocol is up (spoofing)

  Hardware is DSX1

  MTU 1500 bytes, BW 64 Kbit/sec, DLY 20000 usec,

     reliability 255/255, txload 1/255, rxload 1/255

  Encapsulation HDLC, crc 16, loopback not set

  Keepalive set (10 sec)

  Last input 00:00:07, output 00:00:07, output hang never

  Last clearing of "show interface" counters never

  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0

  Queueing strategy: weighted fair

  Output queue: 0/1000/64/0 (size/max total/threshold/drops)

     Conversations  0/1/256 (active/max active/max total)

     Reserved Conversations 0/0 (allocated/max allocated)

     Available Bandwidth 48 kilobits/sec

  5 minute input rate 0 bits/sec, 0 packets/sec

  5 minute output rate 0 bits/sec, 0 packets/sec

     2119962 packets input, 8480583 bytes, 0 no buffer

     Received 0 broadcasts, 111 runts, 0 giants, 0 throttles

     1487 input errors, 1487 CRC, 0 frame, 0 overrun, 0 ignored, 16 abort

     2121385 packets output, 8486472 bytes, 0 underruns

     0 output errors, 0 collisions, 2 interface resets

     0 unknown protocol drops

     0 output buffer failures, 0 output buffers swapped out

     1 carrier transitions

And it's near the top that, if there's a loopback detected, you see it mentioned.

GTG

Please rate all helpful posts.
0 Helpful

ivan aguilar
Level 1
Level 1
In response to Gordon Ross

‎01-10-2012 04:01 AM

Hi Gordon,

First af all, thanks for your reply, this is my interface serial 0/0/0:15

ILL05254#sh int serial 0/0/0:15

Serial0/0/0:15 is up, line protocol is up (spoofing)

  Hardware is DSX1

  MTU 1500 bytes, BW 64 Kbit/sec, DLY 20000 usec,

     reliability 255/255, txload 1/255, rxload 1/255

  Encapsulation HDLC, crc 16, loopback not set

  Keepalive set (10 sec)

  Last input 00:00:00, output 00:00:00, output hang never

  Last clearing of "show interface" counters never

  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0

  Queueing strategy: weighted fair

  Output queue: 0/1000/64/0 (size/max total/threshold/drops)

     Conversations  0/1/256 (active/max active/max total)

     Reserved Conversations 0/0 (allocated/max allocated)

     Available Bandwidth 48 kilobits/sec

  5 minute input rate 0 bits/sec, 0 packets/sec

  5 minute output rate 0 bits/sec, 0 packets/sec

     1008190 packets input, 12270627 bytes, 0 no buffer

     Received 0 broadcasts (0 IP multicasts)

     39 runts, 8 giants, 0 throttles

     714 input errors, 706 CRC, 0 frame, 0 overrun, 0 ignored, 1 abort

     1079123 packets output, 11493562 bytes, 0 underruns

     0 output errors, 0 collisions, 3 interface resets

     0 unknown protocol drops

     0 output buffer failures, 0 output buffers swapped out

     21 carrier transitions

And the configuration of my MGCP Gw is:

controller E1 0/0/0

pri-group timeslots 1-31 service mgcp

!

interface Serial0/0/0:15

no ip address

encapsulation hdlc

isdn switch-type primary-qsig

isdn incoming-voice voice

isdn bind-l3 ccm-manager

no cdp enable

!

voice-port 0/0/0:15

cptone ES

bearer-cap Speech

busyout monitor GigabitEthernet0/0

It seems like yours, just change "busyout monitor ..." and cptone , but the rest is simillar, but making a debug i can see even all the time something like this which i dont know what does it means:

       Codeset 4 IE 0x31  i = 0x81

Jan 10 11:29:36.655: ISDN Se0/0/0:15 Q931: TX -> CALL_PROC pd = 8  callref = 0xB105

        Channel ID i = 0xA98391

                Exclusive, Channel 17

Jan 10 11:29:38.171: ISDN Se0/0/0:15 Q931: TX -> PROGRESS pd = 8  callref = 0xB105

        Facility i = 0x9FAA06800100820100A1080201010201018400

        Progress Ind i = 0x8181 - Call not end-to-end ISDN, may have in-band info

Jan 10 11:29:38.219: ISDN Se0/0/0:15 Q931: RX <- PROGRESS pd = 8  callref = 0xB131

        Facility i = 0x9FAA06800100820100A1080201010201018400

        Progress Ind i = 0x8181 - Call not end-to-end ISDN, may have in-band info

Jan 10 11:29:38.219: ISDN Se0/0/0:15 Q931: TX -> PROGRESS pd = 8  callref = 0xB104

        Facility i = 0x9FAA06800100820100A1080201010201018400

        Progress Ind i = 0x8181 - Call not end-to-end ISDN, may have in-band info

Jan 10 11:29:38.267: ISDN Se0/0/0:15 Q931: RX <- PROGRESS pd = 8  callref = 0xB130

        Facility i = 0x9FAA06800100820100A1080201010201018400

        Progress Ind i = 0x8181 - Call not end-to-end ISDN, may have in-band info

Jan 10 11:29:38.267: ISDN Se0/0/0:15 Q931: TX -> PROGRESS pd = 8  callref = 0xB103

        Facility i = 0x9FAA06800100820100A1080201010201018400

        Progress Ind i = 0x8181 - Call not end-to-end ISDN, may have in-band info

Jan 10 11:29:38.315: ISDN Se0/0/0:15 Q931: RX <- PROGRESS pd = 8  callref = 0xB12F

        Facility i = 0x9FAA06800100820100A1080201010201018400

        Progress Ind i = 0x8181 - Call not end-to-end ISDN, may have in-band info

Jan 10 11:29:38.315: ISDN Se0/0/0:15 Q931: TX -> PROGRESS pd = 8  callref = 0xB102

        Facility i = 0x9FAA06800100820100A1080201010201018400

        Progress Ind i = 0x8181 - Call not end-to-end ISDN, may have in-band info

Jan 10 11:29:38.363: ISDN Se0/0/0:15 Q931: RX <- PROGRESS pd = 8  callref = 0xB12E

        Facility i = 0x9FAA06800100820100A1080201010201018400

        Progress Ind i = 0x8181 - Call not end-to-end ISDN, may have in-band info

Jan 10 11:29:38.367: ISDN Se0/0/0:15 Q931: TX -> PROGRESS pd = 8  callref = 0xB101

        Facility i = 0x9FAA06800100820100A1080201010201018400

        Progress Ind i = 0x8181 - Call not end-to-end ISDN, may have in-band info

Jan 10 11:29:38.415: ISDN Se0/0/0:15 Q931: RX <- PROGRESS pd = 8  callref = 0xB12D

        Facility i = 0x9FAA06800100820100A1080201010201018400

        Progress Ind i = 0x8181 - Call not end-to-end ISDN, may have in-band info

Jan 10 11:29:38.419: ISDN Se0/0/0:15 Q931: TX -> PROGRESS pd = 8  callref = 0xB100

        Facility i = 0x9FAA06800100820100A1080201010201018400

        Progress Ind i = 0x8181 - Call not end-to-end ISDN, may have in-band info

Jan 10 11:29:38.463: ISDN Se0/0/0:15 Q931: RX <- PROGRESS pd = 8  callref = 0xB12C

        Facility i = 0x9FAA06800100820100A1080201010201018400

        Progress Ind i = 0x8181 - Call not end-to-end ISDN, may have in-band info

Jan 10 11:29:38.467: ISDN Se0/0/0:15 Q931: TX -> PROGRESS pd = 8  callref = 0xB0FF

        Facility i = 0x9FAA06800100820100A1080201010201018400

        Progress Ind i = 0x8181 - Call not end-to-end ISDN, may have in-band info

Jan 10 11:29:38.511: ISDN Se0/0/0:15 Q931: RX <- PROGRESS pd = 8  callref = 0xB12B

        Facility i = 0x9FAA06800100820100A1080201010201018400

        Progress Ind i = 0x8181 - Call not end-to-end ISDN, may have in-band info

Jan 10 11:29:38.515: ISDN Se0/0/0:15 Q931: TX -> PROGRESS pd = 8  callref = 0xB0FE

        Facility i = 0x9FAA06800100820100A1080201010201018400

        Progress Ind i = 0x8181 - Call not end-to-end ISDN, may have in-band info

Jan 10 11:29:38.559: ISDN Se0/0/0:15 Q931: RX <- PROGRESS pd = 8  callref = 0xB12A

        Facility i = 0x9FAA06800100820100A1080201010201018400

        Progress Ind i = 0x8181 - Call not end-to-end ISDN, may have in-band info        Codeset 4 IE 0x31  i = 0x81
Jan 10 11:29:36.655: ISDN Se0/0/0:15 Q931: TX -> CALL_PROC pd = 8  callref = 0xB105
        Channel ID i = 0xA98391
                Exclusive, Channel 17
Jan 10 11:29:38.171: ISDN Se0/0/0:15 Q931: TX -> PROGRESS pd = 8  callref = 0xB105
        Facility i = 0x9FAA06800100820100A1080201010201018400
        Progress Ind i = 0x8181 - Call not end-to-end ISDN, may have in-band info
Jan 10 11:29:38.219: ISDN Se0/0/0:15 Q931: RX <- PROGRESS pd = 8  callref = 0xB131
        Facility i = 0x9FAA06800100820100A1080201010201018400
        Progress Ind i = 0x8181 - Call not end-to-end ISDN, may have in-band info
Jan 10 11:29:38.219: ISDN Se0/0/0:15 Q931: TX -> PROGRESS pd = 8  callref = 0xB104
        Facility i = 0x9FAA06800100820100A1080201010201018400
        Progress Ind i = 0x8181 - Call not end-to-end ISDN, may have in-band info
Jan 10 11:29:38.267: ISDN Se0/0/0:15 Q931: RX <- PROGRESS pd = 8  callref = 0xB130
        Facility i = 0x9FAA06800100820100A1080201010201018400
        Progress Ind i = 0x8181 - Call not end-to-end ISDN, may have in-band info
Jan 10 11:29:38.267: ISDN Se0/0/0:15 Q931: TX -> PROGRESS pd = 8  callref = 0xB103
        Facility i = 0x9FAA06800100820100A1080201010201018400
        Progress Ind i = 0x8181 - Call not end-to-end ISDN, may have in-band info
Jan 10 11:29:38.315: ISDN Se0/0/0:15 Q931: RX <- PROGRESS pd = 8  callref = 0xB12F
        Facility i = 0x9FAA06800100820100A1080201010201018400
        Progress Ind i = 0x8181 - Call not end-to-end ISDN, may have in-band info
Jan 10 11:29:38.315: ISDN Se0/0/0:15 Q931: TX -> PROGRESS pd = 8  callref = 0xB102
        Facility i = 0x9FAA06800100820100A1080201010201018400
        Progress Ind i = 0x8181 - Call not end-to-end ISDN, may have in-band info
Jan 10 11:29:38.363: ISDN Se0/0/0:15 Q931: RX <- PROGRESS pd = 8  callref = 0xB12E
        Facility i = 0x9FAA06800100820100A1080201010201018400
        Progress Ind i = 0x8181 - Call not end-to-end ISDN, may have in-band info
Jan 10 11:29:38.367: ISDN Se0/0/0:15 Q931: TX -> PROGRESS pd = 8  callref = 0xB101
        Facility i = 0x9FAA06800100820100A1080201010201018400
        Progress Ind i = 0x8181 - Call not end-to-end ISDN, may have in-band info
Jan 10 11:29:38.415: ISDN Se0/0/0:15 Q931: RX <- PROGRESS pd = 8  callref = 0xB12D
        Facility i = 0x9FAA06800100820100A1080201010201018400
        Progress Ind i = 0x8181 - Call not end-to-end ISDN, may have in-band info
Jan 10 11:29:38.419: ISDN Se0/0/0:15 Q931: TX -> PROGRESS pd = 8  callref = 0xB100
        Facility i = 0x9FAA06800100820100A1080201010201018400
        Progress Ind i = 0x8181 - Call not end-to-end ISDN, may have in-band info
Jan 10 11:29:38.463: ISDN Se0/0/0:15 Q931: RX <- PROGRESS pd = 8  callref = 0xB12C
        Facility i = 0x9FAA06800100820100A1080201010201018400
        Progress Ind i = 0x8181 - Call not end-to-end ISDN, may have in-band info
Jan 10 11:29:38.467: ISDN Se0/0/0:15 Q931: TX -> PROGRESS pd = 8  callref = 0xB0FF
        Facility i = 0x9FAA06800100820100A1080201010201018400
        Progress Ind i = 0x8181 - Call not end-to-end ISDN, may have in-band info
Jan 10 11:29:38.511: ISDN Se0/0/0:15 Q931: RX <- PROGRESS pd = 8  callref = 0xB12B
        Facility i = 0x9FAA06800100820100A1080201010201018400
        Progress Ind i = 0x8181 - Call not end-to-end ISDN, may have in-band info
Jan 10 11:29:38.515: ISDN Se0/0/0:15 Q931: TX -> PROGRESS pd = 8  callref = 0xB0FE
        Facility i = 0x9FAA06800100820100A1080201010201018400
        Progress Ind i = 0x8181 - Call not end-to-end ISDN, may have in-band info
Jan 10 11:29:38.559: ISDN Se0/0/0:15 Q931: RX <- PROGRESS pd = 8  callref = 0xB12A
        Facility i = 0x9FAA06800100820100A1080201010201018400
        Progress Ind i = 0x8181 - Call not end-to-end ISDN, may have in-band info

And triying to make a call with the CSS of that Gw to a mobile, every 5 test, 4 fails.

Any idea? seems configuration is ok, but traces are stranges.

Thanks in advance.

0 Helpful

acampbell
VIP Alumni
VIP Alumni
In response to ivan aguilar

‎01-10-2012 04:29 AM

Hi,

What does this PRI link connect to.

Is it the public PSTN or a private PBX etc ?

You have selected ISDN witch-type prim-qsig

Are you sure that in Spain you should be using prim-net5

Regards

Alex

Regards, Alex. Please rate useful posts.
0 Helpful

ivan aguilar
Level 1
Level 1
In response to acampbell

‎01-10-2012 06:06 AM

Hi Acampbell,

Thanks for your reply, here you are your answers in black:

What does this PRI link connect to.  I dont know, phisically is not in my site

Is it the public PSTN or a private PBX etc ? public PSTN

You have selected ISDN witch-type prim-qsig

Are you sure that in Spain you should be using prim-net5 , yes is net5

We have 10 Gw more and this is the only wich fails.

Thanks.

0 Helpful

paolo bevilacqua
Hall of Fame
Hall of Fame
In response to ivan aguilar

‎01-10-2012 06:35 AM

You should avoid MGCP.

With H.323 or SIP, you would have a more robust solution, more features, and easier troubleshooting.

0 Helpful

ivan aguilar
Level 1
Level 1
In response to paolo bevilacqua

‎01-10-2012 06:47 AM

Hi Paolo,

H.323 is worst because all is managed by the own gateway, not CUCM, and It could not be a solution because all gateways are in MGCP.

regards.

0 Helpful

paolo bevilacqua
Hall of Fame
Hall of Fame
In response to ivan aguilar

‎01-10-2012 06:57 AM

It is actually better because the gateway manages things better, as you can see by the weird problem you're facing..

You can have a mix of H.323 and MGCP GWs if you want.

0 Helpful

acampbell
VIP Alumni
VIP Alumni
In response to paolo bevilacqua

‎01-10-2012 07:06 AM

Hi,

If you are sure that it should be PRIM-NET5 then make the following changes

!

interface Serial0/0/0:15
shut
no ip address
encapsulation hdlc
no isdn switch-type primary-qsig
isdn switch-type primary-net5
isdn incoming-voice voice
isdn bind-l3 ccm-manager
no cdp enable
no shut
!


You will also need to correct the switch type on the MGCP gateway end point on CUCM

to PRI EURO

Save and reset.


HTH
Alex

Regards, Alex. Please rate useful posts.
0 Helpful

Gordon Ross
Level 9
Level 9
In response to acampbell

‎01-10-2012 07:09 AM 

acampbell wrote:
You will also need to correct the switch type on the MGCP gateway end point on CUCM
to PRI EURO
Save and reset.

Actually, you only need to do that in CCMAdmin. It will push the new config down to the gateway automatically (after a suitable "Save/Apply Config"). That's the reason for MGCP ;-)

GTG

Please rate all helpful posts.
0 Helpful

Gordon Ross
Level 9
Level 9
In response to paolo bevilacqua

‎01-10-2012 07:06 AM 

Paolo Bevilacqua wrote:
It is actually better because the gateway manages things better, as you can see by the weird problem you're facing..

Hmm, I'd probably disagree. MGCP does have limitations (Unable to filter on calling DN, unable to see interface activity on the gateway) but on the whole it's fine. And it certainly doesn't prevent you fault finding ISDN problems, as all the debug isdn commands still work.

Anyway, getting back to the original poster's problem....

As you have plently other gateways with the same config working, my gut feel is that it could be a fault with the PSTN switch at the other end. Log a call with your PSTN provider and see what they say. Nine times out of ten, when it's a wierd problem list this, it's the PSTN's fault.

GTG

Please rate all helpful posts.
0 Helpful
Customers Also Viewed These Support Documents