Outbound calls from 79xx don't work, calls from CUPC/CIPC work (Requested circuit/channel not available)

[Isaac Romero]

Hi,

We have a CUCM 7.1 and a 2821 with 2PRI connected to the PSTN.

When calling outbound from an IP Phone 79xx (7911, 7945, etc) to the PSTN we got the following error:

Dec 14 10:18:26.249: ISDN Se0/0/0:15 Q931: TX -> DISCONNECT pd = 8  callref = 0x070D
        Cause i = 0x80AC - Requested circuit/channel not available

When calling from a Softphone (CUPC or CIPC) the call works fine. Also when using "csim start" in the gateway it does work fine.

We tried to change the IP address of a 79xx into the Data Vlan as the Softphones, but the problem remains the same.

Does anyone faced a similar problem? Or do you know how to solve it?

I attach the configs and the debug traces.

Thanks.

Regards,

Isaac Romero

Unitronics

[paolo bevilacqua]

One thing you might want to check,  in your setup message your called number is reporting only 9 digits.

The OP is not the US, as can be evinced by the E1 interface numbering.

[Isaac Romero]

Hi Ryan, in Spain local and mobile numbers are only 9 digits. Also I tried it with international calls and I got the same error (it works with CIPC/CUPC but not with 79xx phones).

[ryan]

I have a hard time believing that this is actually a problem with the phone type itself.  It seems much more likely that it is a problem with either the rtp stream as others have suggested (perhaps even a codec issue).  Or a problem with the actual call setup itself and dial plan. 

One thing you might want to check ( i have only seen one instance of this ever happening) is whether or not your PSTN provider is filtering outbound calls based on calling number.

Ryan

[maharris · Accepted solution]

We have run into problems like this lately, go into the Enterprise Parameters and turn off 'advertize g722), and then make sure that you have a voip peer in the gateway that includes the codec that you want to use, and put an 'incoming called number . (dot)" under that peer, to force calls coming into the router to match that peer.

Mary Beth

[Isaac Romero]

Hi Mary Beth,

I have applied both the changes you suggested (disabling g722 advertising and including "incoming called number ." into a voip dial-peer) and now it is working fine!

I really don't know how this can only affect just to IP phones 79xx and not to CIPC/CUPC.... could please provide me some more information?

It's just to understand the problem, and to avoid it again in the future... anyway, thanks a lot!

Regards,

Isaac.

[asandborgh]

Isaac,

Glad to hear that fixed it.

Just out of curiousity, what version of CIPC are you running (this likely impacted the situation)?

Thanks,

Art

[Isaac Romero]

Hi Art,

CIPC version is 2.1.3.0 and CUPC version is 7.0(2.13496).

I am pretty sure that what solved this was including the "incoming called-numer ." command into a voip dial-peer, because I didn't restart the phones after disabling the g722 advertisement.

I am trying to understand why this was happening only with the 79xx phones, as they should use the same dial-peers that the softphone... I would really appreciate if you could give more information about this, so I could explain it to the customer and also take it into account in the future.

Thanks for your help.

Regards,

Isaac.

[asandborgh]

Isaac,

CIPC did not support G.722 until version 7  so it was not coming up in the negotiation (I'm not sure about CUPC - if it can handle G.722).  I'm willing to bet that during the codec negotiation CCM was advertising and selecting G.722 for the IP phones and the gateway could not handle it.  By turning off advertisements of 722 and making sure a DP was matched with a legitimate codec they could then agree.

If anyone else have a better explanation, please share - I'm just making an eduacted guess.....

I've had issues with G.722 before but had not seen this one - good to know!

Cheers,

Art

[maharris]

Your guess is a good one, when we ran into it, I saw the bad codec requested in the debug voip ccapi inout output.  It is easy to get thrown off by what looks like a PRI problem, too - because of the requested circuit/channel error - Cisco has a special language, I guess - and that G722 has been nothing but trouble, I don't know why they have it on by default!  I am glad that worked!

Mary Beth

[maharris]

We have found that you really want to force your incoming calls to a voip peer that has all of the characteristics that you require, like no vad, dtmf

relay, codecs, etc - we always try to use the incoming called number . to do that, since the list of decision making points for dial peers gets weird, and you  can have strange problems if you are matching the wrong one for some obscure reason, or worse, matching dial peer 0, which is extremely limited.

Mary Beth

[Isaac Romero]

Hi Ryan,

I also though on this, and tried to change the calling number but it didn't make any changes. I tried to change it on the route pattern, on the gateway options setting it to external phone number mask, to default, to restricted, but the problems persists. Also I tried to share the same DN both on the CIPC and on the 7945 so the partition/css is the same, and it only works with the softphone.

Thanks.

[paolo bevilacqua]

It is not a numbers problem.

It is a codec/gw configuration problem as explained above.

[asandborgh]

Isaac,

I think Mary Beth has probably pointed you in the correct direction - try her fix first when you have a chance.

Mary - kudos - five points to you!

Art

[iptuser55]

I know this was a while ago but I also had the same type of problem today - "Channel request not available" on the debugs . Every device uses the same CSS and the same H323 GW however if you dial using a 7937 phone you fail,  dial using a 7942 it works. Replicated in my office using a 7962 works,  used a 7937 failed- Nothing to do with the network as my office is remote from where the original issue is- Reassigned another CSS to route it out on a different GW - MGCP it works, changed it back to the CSS so to route via H323 - fails. By adding the incoming called-number .  to a specific test DP it works- I did no other changes. We also had a incoming called-number . DP as below so that should solved the problem before getting to the normal 9T dial-peers for routing

dial-peer voice 1 pots
incoming called-number .
direct-inward-dial

Did anyone get any answers

thanks

[iptuser55]

Further testing was that if I only added the "incoming called number .  " to an outgoing POTS DP  - the call the rung ok - previously it would cut

off as before answering however now on answer it disconnects. By adding

Dial-peer voice z voip

incoming caled-number .

codec g711alaw

Everything worked. In our System we did not advertise G722 either

It works but why??