CME with BRI cannot answer second inbound voice call

Unanswered Question
Jan 29th, 2009

Dear CME Sensei(s), I have a 2621xm with a couple IP phones, and an ATA with a single BRI. problem is that after one call is already connected, regardless of whether its to a cisco phone, CIPC or the ATA the next inbound call to the BRI cannot be answered. caller hears the ringing continue and I hear a fast busy. I can however use the second call path for outbound calls and/or conf just fine.

I'll attach a sho tech.

I've been unable to get this working now for a ~long~ time.

Any suggestions will be tried immediately, thanks in advance for your efforts.


ps ignore the IP stuff (policy map work in progress among other things) just working on voice here

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 2 (1 ratings)
Paolo Bevilacqua Fri, 01/30/2009 - 03:44

Hi, can you take a "debug isdn q931" and "debug dialpeer" with term mon when the 2nd call fails.

neharris Fri, 01/30/2009 - 09:52

ok I've placed an outbound call from 2541232 to cellphone voicemail at 3238569 and left it pinned up. then started "debug isdn q931" and "debug voip dialpeer all" and tried to call 2541231 from 3238569. caller heard continued ringing and called party hears phone ring and fast busy on answer.

debug attached.

Thanks in advance,


Paolo Bevilacqua Fri, 01/30/2009 - 10:02

Hi, this something about the way the BRI is configured. The network is telling you that a second call is coming as call waiting:

Codeset 5 IE 0x2A i = 0x808001039E05, 'From ', 0x8B0C, '925 323-8569', 0x800101890F, 'Call is waiting', 0x8001048001, '('

But does not specifies a B chan. However, router takes the call on the B2:

Jan 30 10:37:58.124: ISDN BR1/0 Q931: TX -> CONNECT pd = 8 callref = 0xD3

Channel ID i = 0x8A

Exclusive, B2

At this point the switch does not accept the channel and disconnects

Jan 30 10:37:58.208: ISDN BR1/0 Q931: RX <- RELEASE pd = 8 callref = 0x53

Cause i = 0x82AC - Requested circuit/channel not available

Signal i = 0x4F - Alerting off

Locking Shift to Codeset 5

Codeset 5 IE 0x2A i = 0x808001, 'P'

Now, assuming it's not the "exclusive" bit in Bchan by the router, it seem to me telco should re-configure the line so that a second call for the same number is presented as a completely new call with an assigned Bchan.

You would have no problems then.

neharris Fri, 01/30/2009 - 10:12

This BRI works perfectly on a Nautica200 router as configured. Also worked perfectly on a Combinet (Cisco766) I may need to call out differently to get the debug to present things in the way you're looking for but either line will present call waiting if the second call comes in on the spid already in use. but the calls fail the same either way with the exception of the cisco phone presenting an inband tone or a ringing second DN.

I'll try to get a debug later that shows the call without a call waiting flag.

since the BRI works on other CPE I have to assume my configuration is in error though.



Paolo Bevilacqua Fri, 01/30/2009 - 10:21

Yes, what I mean is need for a different spid profile (call appearance per number, etc)on telco side. The various options and codes can be very confusing due to the way BRI is delivered in USA. I remember one guy complaining that he never managed to have a group of BRIs to work as intended and common in Europe.

Anyway, try isdn negotiate-bchan. If it is what makes the switch unhappy, it's easy to find out.

neharris Fri, 01/30/2009 - 18:15

where do I enter the B-channel negotiation command on a BRI?

neharris Sat, 01/31/2009 - 09:07

The command does not appear in the BRI interface so I expected that you're going to share a hidden object where I enter it.  I understand B channel negotiation as a feature available for DS1 PRI services to allow CPE call control and do not have experience with it in the BRI realm domestically or internationally.  just as SPIDs aren't on PRIs, I thought B chan neg wasn't on BRIs.

You're telling me to try enabling B-channel negotiation on a BRI and I'm willing to try this out.  How do I enable that please.



ps all ISDN commands are not entered at the interface object.  like ISDN switch type (don't remember the exact command off the top of my head) for example.

Paolo Bevilacqua Sat, 01/31/2009 - 09:53

Hi, no hidden secret, in fact negotiate bchan is not available for BRI but I fogot that.

Can you try isdn switchtype basic-ni ? That will use keypad IE and preferred channel any to place calls.

And yes you can enter it under interface, as the global command is there for historical reasons, as prevented for example, to define both bri and pri switchtypes in the same box.



neharris Sat, 01/31/2009 - 20:41

As I'm sure you're aware there are many hidden (undocumented/unpublished) objects and commands, I figured you knew something about the BRI in this case.

It might help you help me if you take a look at the existing configuration.  That is already the case.



neharris Sun, 02/01/2009 - 07:33

not sure what you mean.  switch type ni is ALREADY IN THE CONFIG & I cannot use B channel negotiation...was there something you suggested?


Paolo Bevilacqua Sun, 02/01/2009 - 10:40

Basically I was suggesting that by changing switch type, router doesn't use exclusive channel and that is enough to make CO happy. Sorry I didn't looked at the config as I tend to skip large attachments.

Channel selection logic is tied to the switchtype used, so perhaps -5ess would work if -ni doesn't.


neharris Mon, 08/17/2009 - 14:32

SOLUTION: The problem, believe it or not, turned out to be that the 7 digit phone numbers for each of the BRI bearers was missing from the spid configuration lines in the BRI interface configuration.

isdn spid1 41541512340101 xxxxxxx

the x's should contain the 7 digit phone number for a BRI and are oddly optional when configuring the interface.

I am surprised I missed it but even more surprised that no one else caught it.

Case closed.


This Discussion