[cisco-voip] "The Call Cannot Completed as Dialed"

Jason Burns burns.jason at gmail.com
Wed May 6 08:00:12 EDT 2009


There are several defects where directory numbers become uncallable because
of leftover intercepts in digit analysis.

Since you're running 5.0.4 I wouldn't spend too much time on this before
restarting the CallManager service on all nodes

If you know the configuration is correct, and you've double checked CSS and
Partitions, you're probably just running into one of several bugs.

If you can't restart CCM right away, then you should be able to workaround
the problem by assigning the destination phone a new DN.

2009/5/6 Anthony Kouloglou <akoul at dataways.gr>

>  Well Tim,
> i am the only one administrating the CUCM so i guess nothing has changed.
> By the way, i decided a reboot of the cluster late at night (pub and sub)
> and it is working now!
> The version is 5.0.4 which is, as far as i know, not the best software
> ever. :-(
> I think i will try and upgrade to 5.1.3f which seems to be much more
> stable.
> Thanks a lot for the info
>
>
> Best Regards
> Anthony
>
> Tim Smith wrote:
>
> Yes Dialled Number Analyser = DNA. You originally asked for debugging steps
> to take. DNA is a good one to start with. It does more than check calling
> rights. Its worth checking out for yourself.
>
> I suppose it is relatively simple, in a small setup. But it can be more
> complicated than that with line / device CSS's applied, translation
> patterns, route patterns etc. It depends on the complexity of the system and
> how well it has been set up.
>
> If it's been working for 1 year.. have you or someone else made any
> changes? This is going to be a good place to start.
> You didnt mention your version. Did you rename a partition or something?
>
> Are your DN's in the same partition? Can you call the other way?
>
> IPVMS is the service that runs the Annunciator. Annunciator is the feature
> that plays the message to the user saying the call cannot be completed as
> dialled. I dont think this would ever kick in for a codec mismatch. Codec
> mismatch would end up with the call just dropping after the other party
> picked up.. and usually callers then hear fast busy.
>
> Is this only affecting 2 x specific phones?
>
> Cheers,
>
> Tim.
>
> On Wed, May 6, 2009 at 3:45 PM, Anthony Kouloglou <akoul at dataways.gr>wrote:
>
>>  You are talking about Dialed Network Analyzer?
>> Does this check anything else than calling rights? (such as Calling search
>> space and partitions?)
>> Can it check if it is ok to call due to codecs that are not supported?
>> Otherwise, a call between two DNs that exist on the same CUCM is a very
>> easy operation to check!
>> No Route Lists, no Line Groups, no Translation Patterns.
>> Check parition of DN of phone B.
>> Check if CSS of DN A includes this partition.
>> That's all!!
>> I guess, there is nothing else to check.
>>
>> Besides, if i got "Insufficient BW" i would know that it has something to
>> do with the location BW.
>> But not this case again1
>>
>> Thanks,
>> Anthony
>>
>> Tim Smith wrote:
>>
>> Have you tried DNA to check CCM thinks the call should actually be
>> allowed?
>>
>>  It's always a good first step if you get a message like that. It will
>> give you a good picture of what is supposed to be happening.
>>
>> If you havent used it before, maybe it is not installed / activated.
>> You didnt mention your version. For 4.x you install on your pub from
>> plugin page. If 5.x and above you just need to ensure DNA is activated from
>> ccmservice page.
>>
>> Cheers,
>>
>> Tim
>>
>>  On Wed, May 6, 2009 at 5:11 AM, Anthony Kouloglou <akoul at dataways.gr>wrote:
>>
>>> I am getting this message when: phone A calls phone B and vice versa
>>> (suddenly today after 1 year that it has been working!!)
>>>
>>> phone A in the hub location
>>> phone B in a location with 500kbps BW to hub
>>>
>>> Phone A can access the web page of B and ping it.
>>> B is normally registered to the same publisher CUCM!!
>>> B is behind a router that does not do NAT or firewalling.
>>>
>>> Why is this prompt playing?
>>> I resunched the location BW but i guess that is not the issue.
>>> What debugging could show  me what is wrong?
>>>
>>> Thanks and Kind Regards
>>> Anthony
>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>>
>>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20090506/09b0567f/attachment.html>


More information about the cisco-voip mailing list