[cisco-voip] Slow to connect calls

Oddiraju, Kiran @ London SMC Kiran.Oddiraju at cbre.com
Fri Jun 26 06:28:33 EDT 2009


It could be a long post dial delay (pdd) issue too, while you work on
your CCM SDI/SDL traces, try logging a call with your provider saying
you have pdd issues.

 

Kiran

 

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 20:09
To: Cristobal Priego; Wes Sisk
Cc: cisco-voip
Subject: Re: [cisco-voip] Slow to connect calls

 

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.


CB Richard Ellis Limited, Registered Office: St Martin's Court, 
10 Paternoster Row, London, EC4M 7HP, registered in England and Wales No. 3536032. 
Regulated by the RICS and an appointed representative of CB Richard Ellis 
Indirect Investment Services Limited which is authorised and regulated by the Financial Services Authority.

This communication is from CB Richard Ellis Limited or one of its 
associated/subsidiary companies. This communication contains information 
which is confidential and may be privileged. If you are not the intended recipient, 
please contact the sender immediately. Any use of its contents is strictly prohibited 
and you must not copy, send or disclose it, or rely on its contents in any way whatsoever. 
Reasonable care has been taken to ensure that this communication 
(and any attachments or hyperlinks contained within it) is free from computer viruses. 
No responsibility is accepted by CB Richard Ellis Limited or its associated/subsidiary 
companies and the recipient should carry out any appropriate virus checks.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20090626/1aeeb63c/attachment.html>


More information about the cisco-voip mailing list