[cisco-voip] Slow to connect calls

Thu Jun 25 14:29:16 EDT 2009

Unfortunately that is not quite the whole picture.  DNA does not 
gracefully identify and handle all overlap conditions which can cause 
delayed routing.

Overlap dial plan is most likely.  However, there are other signaling 
issues such as long round trip time that can caused delayed call 
routing.  Another cause is hunting through endpoints in a routelist or 
routegroup which are partially responsive.

CCM SDI and SDL traces from the involved CM servers is the best way to 
identify what is introducing the delay.  If you are uncomfortable 
reviewing those open a TAC case and attach them.  Include on the case:
traces
calling party number
called party number
approximate time of call based on phone time.
phone time offset from the server

/Wes

On Thursday, June 25, 2009 2:16:09 PM, Jeff Ruttman 
<ruttmanj at carewisc.org> wrote:
> Thanks Cristobal, Ian.
>  
> There doesn't appear to be a dial plan problem.  See below.
>  
> I'm open to changing protocol to H.323, but I wouldn't know how to do 
> that exactly at the moment.  And anyway as I mentioned we have an 
> H.323 GW for each of the sites that use Trunks and POTS.  They've 
> always had a status of "unknown" and if you view their config, the 
> registration is unknown.  2 of the 4 have a device name/IP address 
> that is the same as the routers at those sites, and the other 2 have a 
> device name/IP address that is the same as the IP on the FXO and FXS 
> CCM configs on the MGCP GWs for these sites.  They are otherwise 
> configured the same.
>  
> Are these H.323 GWs just ornamental??  Are they doing anything?  
> Certainly the MGCP GWs are....
>  
> I'll keep plugging away.  Little by little I'll catch on.
>  
> Thanks
> jeff
>  
> # *Results Summary*
>
>     * *Calling Party Information*
>           o *Calling Party* = 5801
>           o *Partition* =
>           o *Device CSS* =
>           o *Line CSS* = MO1Phones
>           o *AAR Group Name* =
>           o *AAR CSS* =
>     * *Dialed Digits* = 92977902
>     * *Match Result* = RouteThisPattern
>     * *Matched Pattern Information*
>           o *Pattern* = 9.[2-9]XXXXXX
>           o *Partition* = MO1Routes
>           o *Time Schedule* =
>     * *Called Party Number* = 92977902
>     * *Time Zone* = Central Standard/Daylight Time
>     * *End Device* = MO1-RL-Local
>     * *Call Classification* = OffNet
>     * *InterDigit Timeout* = NO
>     * *Device Override* = Disabled
>     * *Outside Dial Tone* = NO
>
>
> ------------------------------------------------------------------------
> *From:* Cristobal Priego [mailto:cristobalpriego at gmail.com]
> *Sent:* Thursday, June 25, 2009 11:28 AM
> *To:* Ian MacKinnon
> *Cc:* Jeff Ruttman; cisco-voip
> *Subject:* Re: [cisco-voip] Slow to connect calls
>
> Sounds like Ian is right. you can have a dial plan problem
> do you have a centralized deployment? if you do, you need to be very 
> careful with the delay of MGCP, because this is a Master-Slave 
> protocol. MGCP has a dependency of callmanager, so before you can 
> place a call, the gw needs to talk to the CUCM to know what to do. if 
> that's the case I'd say the best option for you is to change your 
> protocol to H.323.
>
>
> Cris
>
> 2009/6/25 Ian MacKinnon <Ian.Mackinnon at lumison.net 
> <mailto:Ian.Mackinnon at lumison.net>>
>
>     Hi Jeff,
>
>     That sounds like a dial plan problem ie it is waiting for another
>     digit, and then timing out.
>
>      
>
>     Can you dial the number before hitting dial on the phone so it is
>     all present as opposed to lifting the handset and dialling each
>     digit in turn?
>
>      
>
>     *From:* cisco-voip-bounces at puck.nether.net
>     <mailto:cisco-voip-bounces at puck.nether.net>
>     [mailto:cisco-voip-bounces at puck.nether.net
>     <mailto:cisco-voip-bounces at puck.nether.net>] *On Behalf Of *Jeff
>     Ruttman
>     *Sent:* 25 June 2009 14:47
>     *To:* cisco-voip
>     *Subject:* [cisco-voip] Slow to connect calls
>
>      
>
>     Greetings,
>
>      
>
>     Some of our sites have DID trunk ports and POTS lines, and we have
>     MGCP controlled GWs with FXS and FXO configured.  We also have for
>     these sites H.323 GWs--which frankly I'm not sure why or what they do.
>
>      
>
>     Anyway, at one of those sites, it takes a count of 15 or more for
>     an outgoing call to connect.  I know some delay is expected with
>     that setup, but that's quite a bit longer than at our comparable
>     sites.
>
>      
>
>     Is that length of delay still within expectations?  Or is there
>     something perhaps I can do to speed that up?
>
>      
>
>     Thanks
>
>     jeff
>
>      
>
>     CONFIDENTIALITY NOTICE: The information contained in this email
>     including attachments is intended for the specific delivery to and
>     use by the individual(s) to whom it is addressed, and includes
>     information which should be considered as private and
>     confidential. Any review, retransmission, dissemination, or taking
>     of any action in reliance upon this information by anyone other
>     than the intended recipient is prohibited. If you have received
>     this message in error, please reply to the sender immediately and
>     delete the original message and any copy of it from your computer
>     system. Thank you.
>
>
>     ------------------------------------------------------------------------
>     --
>
>     This email and any files transmitted with it are confidential and
>     intended
>     solely for the use of the individual or entity to whom they are
>     addressed.
>     If you have received this email in error please notify the sender. Any
>     offers or quotation of service are subject to formal specification.
>     Errors and omissions excepted. Please note that any views or opinions
>     presented in this email are solely those of the author and do not
>     necessarily represent those of Lumison.
>     Finally, the recipient should check this email and any attachments
>     for the
>     presence of viruses. Lumison accept no liability for any
>     damage caused by any virus transmitted by this email.
>
>     _______________________________________________
>     cisco-voip mailing list
>     cisco-voip at puck.nether.net <mailto:cisco-voip at puck.nether.net>
>     https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
>  
> CONFIDENTIALITY NOTICE: The information contained in this email 
> including attachments is intended for the specific delivery to and use 
> by the individual(s) to whom it is addressed, and includes information 
> which should be considered as private and confidential. Any review, 
> retransmission, dissemination, or taking of any action in reliance 
> upon this information by anyone other than the intended recipient is 
> prohibited. If you have received this message in error, please reply 
> to the sender immediately and delete the original message and any copy 
> of it from your computer system. Thank you.
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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/20090625/4043c605/attachment.html>