[cisco-voip] Speed up skinny?

Mon Aug 3 17:35:41 EDT 2009

Sounds like H323 is your protocol then. J

SCCP will require 1-1.5 x <RTT latency> to setup a full audio stream.
CUCM will send the device an OpenLogicalChannel, the device will process
it and respond with an OpenLogicalChannelAck, and then CUCM processes
the Ack and generates a StartMediaTransmission to send to the other
party (in the case of two SCCP phones).

So if you have a 600ms RTT from site A to siteB, then you have to wait
for the OLC to make it there (~300ms), then wait for the Ack to be
returned (~300ms), then CUCM has to send the SMT to the other party
(time here depends on where this other device is located and whether or
not it is going to experience any delay in transit); hence 1-1.5 x <RTT
latency>.

So in your case, using SCCP, you are looking at roughly 1+ seconds after
off-hook to get full two-way audio. There is not "faststart" SCCP that I
am aware of.

-Chris

From: cisco-voip-bounces at puck.nether.net
[mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Keith Klevenski
Sent: Monday, August 03, 2009 5:19 PM
To: Wes Sisk (wsisk)
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] Speed up skinny?

Wes,

Thanks for the reply.  Running CM 7.02.  I'm quite sure its RTT as we're
talking 600-800ms with 100 byte packets although the link speeds are
128/256kbps so we're not breaking any speed records here.  ;)  If I
change the SCCP gateway to H323 and configure the usual dial-peers the
delay is gone.  Convert back to SCCP and it's back.  

I don't see any way around it based on the round trip requirement you
mentioned.  Thanks for the confirmation.  

-Keith

From: Wes Sisk [mailto:wsisk at cisco.com] 
Sent: Monday, August 03, 2009 3:39 PM
To: Keith Klevenski
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] Speed up skinny?

What CM version are you on?

Only recent optimization available is Advanced CM service parameter
"Bundle Outbound SCCP Messages Timer" to enable bundling of SCCP
messages. More messages per packet = fewer ACKs = fewer round trips.
Much further back there was an effort to streamline the number of
messages required to setup SCCP call.

SCCP capabilities are exchanged at device registration so it does not
suffer the same issue as h.323 where capabilities must exchange during
every call setup.  There is no MSD equivalent.  SCCP overall is a much
lighter protocol at the point of call signaling.  The only round trip
requirement in SCCP is OpenReceiveChannel/OpenReceiveChannelAck with
remote IP:Port.  StartMediaTransmission is required and cannot be sent
until IP:Port is received from far end device.  Unfortunately this
exchange is required with no way to bypass this round trip for SCCP.

One area we commonly see issues is shared lines at remote sites.  This
is covered in SRND:
http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/6x/netstruc.html
#wp1045582

Is it really RTT or is it possibly link speed that is causing the issue?

/Wes

On Monday, August 03, 2009 4:11:50 PM , Keith Klevenski
<KKlevenski at cstcorp.net> <mailto:KKlevenski at cstcorp.net>  wrote:

Is there any mechanism to 'speed up' skinny call setup like faststart in
h323?  Satellite provider migrated to skinny gateways (SCCP controlled
FXS ports) from h323 gateways.  All analog phones.  It was noticed that
inbound PSTN calls (through h323 gateway) were losing the first second
or so of the call when the called party picked up.  This made sense to
me as the skinny gateway must tell CM the phone has gone offhook then CM
tells the gateway to tell the phone to stop ringing and send media
stream to the PSTN gateway.  This is over a 600-700ms satellite link so
the delay would be reasonable.  The rest of the call is perfect.  If the
same skinny gateway is changed to h323 the delay is not present since
h323 gets the IP address where to send the stream during call setup if
I'm not mistaken so the delay isn't present, but neither are the
features of skinny controlled fxs ports...

To me this is all reasonable and makes perfect sense.  The question the
customer has is if there is any mechanism to speed up the skinny
signaling.  I wouldn't think so based on the master/slave nature of the
skinny protocol.  I've configured voice call send-alert, voice rtp
send-recv, progress_ind setup enable 3, and all that, but nothing helps
and I can understand why.

Can anyone confirm if there is a way to speed up skinny call setup over
high latency links?  Running CM 7.0, SCCP controlled FXS.

Thanks!

-Keith 

________________________________

_______________________________________________
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/20090803/917d0d22/attachment.html>