[cisco-voip] Slow to connect calls
Jeff Ruttman
ruttmanj at carewisc.org
Thu Jun 25 15:08:54 EDT 2009
Nice! Thanks everyone. I'll pursue it. My first look at traces...real
phone guy arcana :)
jeff
________________________________
From: Cristobal Priego [mailto:cristobalpriego at gmail.com]
Sent: Thursday, June 25, 2009 1:52 PM
To: Wes Sisk
Cc: Jeff Ruttman; Ian MacKinnon; cisco-voip
Subject: Re: [cisco-voip] Slow to connect calls
Jeff,
I'd do what Wes is saying, however I will check the traces myself before
I send those to TAC.
Trace the call look for the StationOpenReceiveChannel output, this
contains the media Payload and bit rate check the timestamp of this
message, then look for this message StationOpenReceiveChannelAck and
then look for StartMediaTransmission, this message commands the phone
to start streaming RTPs, this includes UDP port, IP of remote endpoint,
packet size and codec. check the timestamps and if the delay between
those messages is greater than 40ms or 200ms I don't remember hopefully
someone knows the roundtrip delay for MGCP. then the problem is MGCP and
you may want to consider H.323.
I have an entire call flow from a few tests calls I made and got all the
messages that are involved
Call Processing Behavior
P->CM: OffHookMessage
CM->P: StationCallState: OffHook (1)
CM->P: StationDisplayPromptStatus: update the display
CM->P: StationSelectSoftKeys: loads the appropiate soft key set,
depending on the call state
CM->P: StationActivateCallPlane: contains the specified line appearance
of the DN being called
CM->P: StationStartTone: InsideDialTone, commands the phone to play
dialtone
P->CM: KeyPadButton: keypad button was pressed. *= 0xe; #=0xf
CM->P: StationStopTone: msg sent when a tone needs to be stopped (i.e.
DialTone)
CM->P2: StationCallState: State of the call: OffHook=1, OnHook=2,
RingOut=3, RingIn=4, Connected=5
Busy=6, Congestion=7, Hold=8, CallWaiting=9,
CallTransfer=10, CallPark=11, Proceed=12
CallRemoteMultiline=13, InvalidNumber=14
CM->P: StationStartTone: (outsidedialtone=34)
P->CM: keyPadButton:
CM->P: StationStopTone
CM->P2: StationCallInfo: msg has the called party DN/Name and Calling
party DN/Name
CM->P2: StationSetRinger: sets the ringer to the specified ringing
mode: StationRingOff: stops ringer from Ringing, StationInsideRinging:
indicates OnNetCall,
StationOutsideRing: indicates OffNetCall,
StationFeatureRing: used by third-party apps to invoke special features
CM->P2: StationDisplayNotify: this msg causes the phone to discard msg
txt from StationOutputDispalyText and play the text contained in
StationDisplayNotify
CM->P2: StationDisplayPromptStatus
CM->P2: StationSelectSoftKeys
CM->P: StationCallState: proceed=12
CM->P: StationCallInfo
CM->P: StationStartTone: alerting Tone, ringback tone
CM->P: StationCallState: ringout=3
CM->P: StationSelectSoftKeys
CM->P: StationDisplayPromptStatus
P2->CM: OffHookMessage
CM->P2: StationClearNotify: msg sent to the phone to clear the
information sent in the StationDisplayNotify msg
CM->P2: StationSetRinger: RingerOff
CM->P2: StationCallState
CM->P2: StationActivateCallPlane
CM->P: StationStopTone
CM->P: StationCallState
CM->P: StationCallInfo
CM->P: StationSelectSoftkeys
CM->P: StationDisplayPromptStatus
CM->P: StationOpenReceiveChannel: contains the media Payload and bit
rate, asks the phone if it is ready to receive RTP Stream
CM->P2: StationOpenReceiveChannel
P->CM: StationOpenReceiveChannelAck
P2->CM: StationOpenReceiveChannelAck
CM->P2: StartMediaTransmission: commands the phone to start streaming
RTP. Includes: UDP port , IP of remote endpoint, packet size, Codec
CM->P: StartMediaTransmission
P2->CM: OnHookMessage
CM->P2: StationConnectionStatisticsReq: requests connectionstatistics
from the ip phone
P2->CM: StationSetSpeakerMode: turns the speakerphone on/off
CM->P2: StationClearStatus:
CM->P2: StationCallState: 2=onhook
CM->P2: StationSelectSoftkeys
CM->P2: StationDisplayPromptStatus
CM->P2: StationActivateCallPlane
P2->CM: StationConnectionStatisticsRes
CM->P2: StationDefineTimeDate
CM->P2: StationStopTone
CM->P: StationCloseReceiveChannel: commands the phone to stop
processing RTP messages sent to it
CM->P: StationStopMediaTransmission: tells the phone to stop streaming
RTP packets
CM->P2: StationCloseReceiveChannel
CM->P2: StationStopMediaTransmission
CM is The communications Manager
P is phone 1 the phone that is placing the call
P2 is the phone that will receive the call
hopefully this will help you out
Cris
2009/6/25 Wes Sisk <wsisk at cisco.com>
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> <mailto: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
* Calling Party = 5801
* Partition =
* Device CSS =
* Line CSS = MO1Phones
* AAR Group Name =
* AAR CSS =
* Dialed Digits = 92977902
* Match Result = RouteThisPattern
* Matched Pattern Information
* Pattern = 9.[2-9]XXXXXX
* Partition = MO1Routes
* 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>
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] 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
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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20090625/40cc4317/attachment.html>
More information about the cisco-voip
mailing list