cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1174
Views
5
Helpful
17
Replies

ISDN BRI won't rollover

mleboeuf
Level 1
Level 1

Hi,

I have a 2851 with 2 VIC2-2BRI-NT/TE. I configured trunk groups to rollover between the 4 voice ports for outbound calls. Everything works fine with all the ports connected (I can place and receive many calls at the same time). Then I disconnected all of the ports except the BRI0/0/1 and when I try to place a call, I get a fast busy. The router seems always to try the first port (BRI0/0/0) as that log says (and there's nothing connected in that port):

Dec 5 22:20:26.627: %LINK-3-UPDOWN: Interface BRI0/0/0, changed state to up

Dec 5 22:20:34.631: %LINK-3-UPDOWN: Interface BRI0/0/0, changed state to down

Here's the config:

!

trunk group BRI

hunt-scheme sequential both up

!

!

!

interface BRI0/0/0

no ip address

isdn switch-type basic-net3

isdn twait-disable

isdn point-to-point-setup

isdn incoming-voice voice

isdn static-tei 0

trunk-group BRI

!

interface BRI0/0/1

no ip address

isdn switch-type basic-net3

isdn twait-disable

isdn point-to-point-setup

isdn incoming-voice voice

isdn static-tei 0

trunk-group BRI

!

interface BRI0/1/0

no ip address

isdn switch-type basic-net3

isdn twait-disable

isdn point-to-point-setup

isdn incoming-voice voice

isdn static-tei 0

trunk-group BRI

!

interface BRI0/1/1

no ip address

isdn switch-type basic-net3

isdn twait-disable

isdn point-to-point-setup

isdn incoming-voice voice

isdn static-tei 0

trunk-group BRI

!

!

dial-peer voice 800 pots

trunkgroup BRI

destination-pattern 0T

!

Thanks!!

17 Replies 17

allan.thomas
Level 8
Level 8

As you are using the sequential hunt-scheme have you tried using preferences? By default Sequential trunk-group will use the interface with the highest preference is selected.

Try assigning or configuring your interfaces starting BRI0/1/1 with 'trunk-group BRI 1' and then BRI0/1/0 with 'trunk-group BRI 2' and so. This should then force BRI0/1/1 interface to be selected first.

Hope this helps.

Regards

Allan.

Thanks for your reply. I tried what you suggest and the BRI0/1/1 could be selected first. But what I'm looking for, is to have a rollover in case of failure. That's the reason why I do this test. I tried other hunt schemes but when a port that is not connected is selected first, the router won't go to the next one... Any ideas??

Hi,

under "trunk group XXX", please try "max-retry 2".

Hope this helps, please rate post if it does!

Thanks for your reply. No it doesn't work either. And now the router starts with the Bri0/1/0... Do you think this is a bug? Thanks again!

Hi,

actually I think that failure to try another line in a trunk group made of BRIs, is a definite bug. I have the same issue in my installations, and the workaround is to remove the BRI from the trunk-group.

However, I didn't tried the "max-retry" config with "hunt-scheme round-robin". Have you ?

Hi, yes I have tried all hunt schemes... Same result. Your workaround seems to be the only thing to do since the router have the same behavior if I shutdown the BRI ports that are not connected.

Thanks for your help!!

You are welcome. Unfortunately it can take a lot of time and effort to convince Cisco that it is a bug, so I didn't pursued the issue any further.

Who has the will to do that and is successful, that would be an accomplishment benefiting everyone.

MARTIN STREULE
Spotlight
Spotlight

add the following to you config:

trunk group BRI

max-retry 3 ! you have 4 ports

voice-class cause-code 1

voice class cause 1

no-circuit

no-channel

temp

If this does not work, do a "debug voice ccapi inout" and you'll see somewhere (tons of text) the cause code.

In the voice-class cause you can use the "?/help" and look if you find the matching code.

Worked for me, but is not really good documented... :-)

Good luck,

Martin

Good info, will try as I got a chance.

Just another point to be aware of:

If you have outgoing translations on the ports or the trunk, they will go wrong.

The translation will be done even if call cannot be placed and the next port/trunk translation will be done again.

Example:

--DialPeer---Trunk---Port (out of order)

---Port (ok)

translation on peer: ok

translation on trunk/port: will translate twice :-)

-> If you want to use trunk, use outgoing translations in dial-peer only if you need redundancy.

This is sad, but this is IOS...

I got a case open on that - but this seems to be a case of "works as designed".

/Martin

Hi Martin,

good info again, thanks. Typical case of cisco short sighting in design and testing.

Next thing you will discover, is that what was not a bug when you reported it, it becomes one when reported by a large and important customer with an order at stake, or if it is mentioned in an highly visible venue, like ietf meeting, etc.

Hi,

try without the hunt function.

nterface BRI0/0/0

no ip address

isdn switch-type basic-net3

isdn twait-disable

isdn point-to-point-setup

isdn incoming-voice voice

isdn static-tei 0

!

interface BRI0/0/1

no ip address

isdn switch-type basic-net3

isdn twait-disable

isdn point-to-point-setup

isdn incoming-voice voice

isdn static-tei 0

!

interface BRI0/1/0

no ip address

isdn switch-type basic-net3

isdn twait-disable

isdn point-to-point-setup

isdn incoming-voice voice

isdn static-tei 0

!

interface BRI0/1/1

no ip address

isdn switch-type basic-net3

isdn twait-disable

isdn point-to-point-setup

isdn incoming-voice voice

isdn static-tei 0

Greets,

Norbert

Great one - worked like a charm.. Gave you a "high five" for that one..

Thanks a lot!

Cheers

/David

Coming into the thread a little late ... but perhaps you would all like to know what is happening here.

If you unplug the BRI ports and run 'debug voip ccapi inout', the clearing code will actually be 1 - unallocated/unassigned number.

This happens because the voice port status is reflected on the actual dial peer. If you do a 'sh dial peer voice status', you will see the POTS dial peers are in the down state.

If a call comes into the router from the VOIP leg, the dial peers that are in the down state will be ignored , so no match will be made on the destination pattern of the first dial peer that the router hunts through and as a result, IOS sends a clear code of unallocated /unassigned number. At the VOIP processing layer, a decision is made that there is no point retrying the call since the number does not exist. So IOS clears the call down and nothing more happens.

There is a simple fix ... Add the command 'no dial-peer outbound status-check pots' . This command tells the software to ignore the physical status of the voice port. The voice call on this dial peer still fails, but it will return cause value 34 - no circuit/channel available. When this gets passed back to the voice processing software , it then retries the call and will hunt through the all the dial peers.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: