CME cannot answer inbound callwaiting on BRI

Unanswered Question
Aug 27th, 2009

Here's the problem. first call comes in on first line 9481180 and works just fine. then second call comes in on 9481180 and I hear a call waiting tone on the 7970. I see the ANI on the screen pop and the distant end hears ringing. I press the answer key and the first call is placed on hold and I hear about a half second of a busy tone on my end then the call disappears from the 7970. calling party hears continued ringing.

q931 shows

"Requested circuit/channel not available"

I've tried adding secondary LDNs to the spids so that both spids have both numbers. I've tried it without spids, the "cisco recommended" way.

I'm thinking it's a simply configuration issue that I'm blind to so any assistance would be great!

thanks in advance.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
neharris Thu, 08/27/2009 - 17:54

Here's the config, I tried to remove all the unrelated meat

!

version 12.4

network-clock-participate slot 1

no network-clock-participate wic 0

!

ip dhcp excluded-address 192.168.1.1

!

isdn switch-type basic-ni

voice-card 1

dsp services dspfarm

!

voice rtp send-recv

!

voice service pots

!

voice service voip

allow-connections h323 to h323

fax protocol t38 ls-redundancy 0 hs-redundancy 0 fallback cisco

h323

!

voice register global

max-dn 72

max-pool 24

!

call-history-mib max-size 500

!

interface BRI1/0

description SBC ISDN BRI 9239481180-2

no ip address

isdn switch-type basic-ni

isdn point-to-point-setup

isdn spid1 92594811800101 9481180

isdn spid2 92594811810101 9481181

isdn incoming-voice voice

isdn send-alerting

isdn sending-complete

!

voice-port 1/1/0

description BRI Card: NM slot 1, port 0 (in use)

!

dial-peer cor custom

name P-RES-RS

name P-LOC-RS

name P-LD-RS

name P-INTL-RS

name P-UNRES-RS

!

dial-peer cor list CSS-RES-RS

member P-RES-RS

!

dial-peer cor list CSS-LOC-RS

member P-RES-RS

member P-LOC-RS

!

dial-peer cor list CSS-LD-RS

member P-RES-RS

member P-LOC-RS

member P-LD-RS

!

dial-peer cor list CSS-INTL-RS

member P-RES-RS

member P-LOC-RS

member P-LD-RS

member P-INTL-RS

!

dial-peer cor list CSS-UNRES-RS

member P-RES-RS

member P-LOC-RS

member P-LD-RS

member P-INTL-RS

member P-UNRES-RS

!

!

dial-peer voice 555001 pots

corlist outgoing CSS-LOC-RS

description Pattern=9[2-9]XXXXXX LOCAL 7-DIGIT

destination-pattern 9[2-9]......

port 1/1/0

forward-digits 7

!

dial-peer voice 555002 pots

corlist outgoing CSS-LD-RS

description Pattern=91[2-9]XX[2-9]XXXXXX LONG DISTANCE

destination-pattern 9[1][2-9]..[2-9]......

port 1/1/0

forward-digits 11

!

dial-peer voice 555003 pots

corlist outgoing CSS-INTL-RS

description Pattern=9011! INTERNATIONAL

destination-pattern 9[0][1][1]T

port 1/1/0

prefix 011

!

dial-peer voice 555004 pots

corlist outgoing CSS-LOC-RS

description Pattern=918XX[2-9]XXXXXX TOLL FREE

destination-pattern 9[1][8]..[2-9]......

port 1/1/0

forward-digits 11

!

dial-peer voice 2 pots

description **BRI pots inbound calls**

incoming called-number .

direct-inward-dial

port 1/1/0

!

no dial-peer outbound status-check pots

!

telephony-service

sdspfarm units 4

sdspfarm transcode sessions 2

load 7960-7940 P00308000400

load ATA ATA030100SCCP040211A

load 7961 P00303020214

load 7971 term71.default

max-ephones 20

max-dn 40

ip source-address 192.168.1.1 port 2000

cnf-file location flash:

cnf-file perphone

time-zone 5

time-format 24

date-format dd-mm-yy

max-conferences 1 gain -6

moh music-on-hold.au

transfer-system full-consult

secondary-dialtone 9

create cnf-files version-stamp 7960 Aug 17 2009 00:25:24

!

ephone-dn 1 dual-line

number 9481180

label 9481180

!

ephone-dn 2

number 9481181

label 9481181

!

ephone 1

device-security-mode none

description ETHERNET PHONE 7970G

mac-address 0000.0000.0000

type 7970

auto-line 1

button 1:1 2:2

!

ephone 2

device-security-mode none

description ETHERNET PHONE 7971GE

mac-address 0000.0000.0000

type 7971

auto-line 1

button 1:1 2:2

!

ephone 3

device-security-mode none

description IP COMMUNICATOR

mac-address 0000.0000.0000

username "cupc" password 1717

type CIPC

button 1:1 2:2

!

ephone 4

device-security-mode none

description ETHERNET PHONE 7940G

mac-address 0000.0000.0000

type 7940

no auto-line

button 1:1 2:2

!

ephone 10

device-security-mode none

description ANALOG TELEPHONE ADAPTER ata186 port 1

mac-address 0000.0000.0000

type ata

button 1:1

!

ephone 11

device-security-mode none

description ANALOG TELEPHONE ADAPTER ata186 port 2

mac-address 0000.0000.0000

type ata

button 1:2

!

Paolo Bevilacqua Fri, 08/28/2009 - 01:59

It is not a simple configuration, some telco do not provisdion the circuit correctly so that the second call is given directly on the 2nd B-channel, rather they try to use one single B-channel and give call-waiting, the router cannot handle this configuration, either you fixt this at telco level either I don't think anything can be done on the router.

neharris Fri, 08/28/2009 - 08:05

So you're saying that I should be seeing the "Call waiting tone" on B1 instead of B2?

here's the Q931:

First call already in progress on B1

Second call is presented with as call waiting with inband tone and screen pop with ANI

Aug 28 07:03:19.014: ISDN BR1/0 Q931: RX <- SETUP pd = 8 callref = 0x11

Bearer Capability i = 0x8090A2

Standard = CCITT

Transfer Capability = Speech

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0x88

Exclusive, No B-channel

Signal i = 0x07 - Call waiting tone on

Called Party Number i = 0xC1, '9481180'

Plan:ISDN, Type:Subscriber(local)

Locking Shift to Codeset 5

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

Aug 28 07:03:19.074: ISDN BR1/0 Q931: TX -> CALL_PROC pd = 8 callref = 0x91

Channel ID i = 0x8A

Exclusive, B2

Aug 28 07:03:19.114: ISDN BR1/0 Q931: TX -> ALERTING pd = 8 callref = 0x91

Channel ID i = 0x8A

Exclusive, B2

When I try to answer the waiting call:

Aug 28 07:03:34.274: ISDN BR1/0 Q931: TX -> CONNECT pd = 8 callref = 0x91

Channel ID i = 0x8A

Exclusive, B2

Aug 28 07:03:34.342: ISDN BR1/0 Q931: RX <- RELEASE pd = 8 callref = 0x11

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'

Aug 28 07:03:34.354: ISDN BR1/0 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x91

Aug 28 07:03:34.386: ISDN BR1/0 Q931: RX <- INFORMATION pd = 8 callref = 0xDD

Locking Shift to Codeset 5

Codeset 5 IE 0x2A i = 0x808001038308, '948-1180', 0x8001098909, 'Connected', 0x80010B8001, '('

Paolo Bevilacqua Fri, 08/28/2009 - 08:59

Yes, as you can see telco fails to connect 2nd call on B2:

Aug 28 07:03:34.342: ISDN BR1/0 Q931: RX <- RELEASE pd = 8 callref = 0x11

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'

neharris Fri, 08/28/2009 - 08:56

I've been on with ISDN switched support at AT&T for a couple hours now doing various testing and they're saying that the Cisco is not correctly formatting it's call waiting response message on the D-channel. The 5ESS config'd as NI is sending the call waiting without a channel assignment and instead of the Cisco using call waiting it's placing the first call on hold locally (leaving it up connected to the 5E) and is asking for the second call on to be delivered on B2.

Can anyone comment on this? Can Cisco equipment actually use the call waiting feature as it was designed on a single bearer or can it only handle one call per bearer? If everything is as it appears this sounds like a bug

Paolo Bevilacqua Fri, 08/28/2009 - 09:07

Hi, they're are correct to a certain point, Cisco does not supports call waiting and it can handle only one call per bearer, it is asking the switch to do so but gets a refusal.

I've seen this situation already in various US telcos with BRI, sometimewas resolved by setting on the switch the proper "capability package" see:

http://www.cisco.com/en/US/docs/routers/access/800/801/software/configuration/guide/provisio.html

unfortunately the details are never 100% clear because these are CO things not really divulged to the public.

neharris Fri, 08/28/2009 - 09:23

Thanks for the link but that's for the 700/800's which if I'm not wrong are the old Combinet devices. Not IOS based and very different.

If I have the 5ESS increase the calls per bearer and then the second call to the first number WILL come in on B2 but this is NOT call waiting.

So what you're saying is that Cisco does not support call waiting, It just accepts the call waiting message and asks for the call on another bearer???

Is that what you're saying?

Thanks,

Paolo Bevilacqua Fri, 08/28/2009 - 09:27

The 800 were true IOS routers and the ISDN logic did not change in this aspect.

Yes the router does not does support call waiting (hold and resume), it specifies the call to be completed on the free bearer, that fails.

neharris Fri, 08/28/2009 - 11:10

I see you all over the forum. Are you paid to answer questions? just curious.

So FYI here is the best solution for anyone with CME and a BRI hanging off of a 5ESS:

how to provision the 5ESS for a BRI with CME

1) disable call waiting

2) set additional call offering to off

3) set CSV (ckt switchefd voice) to 2 for each bearer

4) set total calls to 2

this will produce the following:

-Allows 2 inbound calls on each number if dual-line DNs are configured.

-prevents total of more than 2 inbound calls for the BRI sending a busy tone to caller on 3rd attempt either number (will not see a D-chan msg)

-allows 2 outbound calls on each number

unfortunately cisco does not appear to support call waiting. It receives the call waiting message and instead of allowing the switch to retract the first call and then send the second down the same bearer, it asks the switch to present the call waiting call on another bearer, which is unsupported by the 5ESS (without creating other problems)

I wish Cisco supported call waiting. If they did a BRI on a 5ESS could support up to 16 inbound calls (8 on each spid), DMS100 still only does 2 per bearer

Problem closed.

Paolo Bevilacqua Fri, 08/28/2009 - 12:16

No I'm not paid. I just answer where I know.

The reason why cisco doesn't support call waiting on BRI or FXO, is that CM/CME are not residential products. Business customers want one circuit per call.

neharris Fri, 08/28/2009 - 19:23

I recently deployed a 27 site mgcp CCM4.2 cluster and one of the sites, in Yuma, AZ was small enough that a PRI was a bad idea. the only other option (supporting multiple DIDs) from Qwest was inbound trunks over h323. Which meant that unless we backhauled calls to another site to gateway out, we had to use POTS for local outbound. 2 BRI's on a 5ESS & call waiting abilities with up to 16 DIDs would've been great solution & less than half the cost and likely less problems. Obviously Cisco would have to support the 5ESS feature sets for multi switched voice calls, call waiting and additional call offering.

I'm suggesting that it's hard to say whether of not business customers would want it or not. Since it's not available there's no statistical opportunity :)

thanks for your comments!

cheers

Actions

This Discussion