01-29-2009 10:51 PM - edited 03-15-2019 03:52 PM
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.
->N
ps ignore the IP stuff (policy map work in progress among other things) just working on voice here
01-30-2009 03:44 AM
Hi, can you take a "debug isdn q931" and "debug dialpeer" with term mon when the 2nd call fails.
01-30-2009 09:52 AM
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,
->N
01-30-2009 10:02 AM
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.
01-30-2009 10:12 AM
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.
thanks,
->N
01-30-2009 10:21 AM
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.
01-30-2009 06:15 PM
where do I enter the B-channel negotiation command on a BRI?
01-31-2009 08:23 AM
Like all ISDN commands, under interface.
01-31-2009 09:07 AM
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.
thanks,
->N
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.
01-31-2009 09:53 AM
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.
01-31-2009 08:41 PM
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.
Thanks,
->N
02-01-2009 03:29 AM
No worries. Check if the recommended change helps.
02-01-2009 07:33 AM
not sure what you mean. switch type ni is ALREADY IN THE CONFIG & I cannot use B channel negotiation...was there something you suggested?
->N
02-01-2009 10:40 AM
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.
08-17-2009 02:32 PM
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.
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: