[cisco-voip] QS: TFTP Server and Phone Loads

Mon Sep 15 09:27:13 EDT 2008

I mean packet routing.   In order to get 2-way audio CUCM has to  
receive and send the RTP parameters (IP address, port, and codec)  
from each party and send them on to the other party.   After that  
it's all routing in the network as RTP is just another UDP data flow.

-Ryan

On Sep 12, 2008, at 10:51 PM, Syed Khalid Ali wrote:

Thanks for the reply and explanation.

Regarding the one-way audio, what do you mean by routing issue. It is  
call routing or packet network routing? I have other branches running  
and there are no issues at all but the media is either DSL, DXX or  
WiMAX and the delay is around 100-250 ms.

Note: I am runnning Call Manager 4.2(3) with IPCC Express 4.0(4)

Thanks
Khalid
CC: cisco-voip at puck.nether.net; thsglobal at gmail.com
From: rratliff at cisco.com
Subject: Re: [cisco-voip] QS: TFTP Server and Phone Loads
Date: Fri, 12 Sep 2008 14:02:43 -0400
To: khalid_khursheed at hotmail.com

Are your phones having to upgrade the phone firmware?

The zip file alone for the 7911 version 8.3.5 is about 4Mb.  If my  
quick and dirty math is correct at 512 bytes per packet it will take  
about 8000 packets to download that 4Mb of phone load files, per  
phone.  At 800ms per packet (assuming that's RTT so best-case) that's  
a very, very long time to upgrade phone loads.

I'd highly encourage you to get either a local TFTP server for phone  
loads (recent CUCM versions allow you to set a load server at the  
phone level) or set those phones to use whatever load they are  
currently on so they can skip the upgrading part.

One-way audio is going to be a routing issue, the transport won't  
change that fact.

-Ryan

On Sep 12, 2008, at 12:41 PM, Syed Khalid Ali wrote:

Hi,

I have 7911G IP Phones. We have up to 4 to 5 phones at each site. I  
have tested it via ping command from call manager to ip phones. The  
delay with 32 bytes packet is around 650 to 675 ms. For 200 to 300  
bytes packet the delay goes around 800+ms delay. The link capacity is  
256k/256k. I did not measure the packet loss throughly, however, I  
did check show ip interface output and did not find any packet loss  
or CRC errors.

I have waited  register ofor around 1 hour just tone phone. Hell only  
one of the phone was able to register with CallManager. Also what  
about Peer Firmware Sharing with 7911 series?

Also for 3-4 phones, it will be very difficult to justify the cost  
for CME at remote site to administration.

One more thing, the problem of ONE-WAY Audio is also there!

Waiting for your response.

Regards,
Khalid

From: rratliff at cisco.com
Subject: Re: [cisco-voip] QS: TFTP Server and Phone Loads
Date: Fri, 12 Sep 2008 10:21:05 -0400
To: khalid_khursheed at hotmail.com

For phone loads it depends on he phone model and version.  The  
7940/60 loads are pretty small, the 3rd-gen phone loads can get  
pretty big.  Over a high latency link you will see some very long  
times to upgrade 3rd gen phones as TFTP only transmits a small amount  
of data (512 bytes IIRC) and each packet has to be acked before the  
next is sent.

For registration the VSAT won't be too bad.  Delay itself won't even  
make voice quality too bad as long as the jitter is low.  Somebody  
who has actually used it may have more specific information though.

-Ryan

On Sep 12, 2008, at 2:29 AM, Syed Khalid Ali wrote:

All,

How TFTP server provides phone load to ip phones. I mean what is the  
minimum number of BYTES tftp server sends to IP Phones.

Another things is that we have some branches in location VSAT is the  
only possible solution. Will ip phones be able to register with call  
manager.

Using CCM 4.2(3).

Regards,
Khalid

Get news, entertainment and everything you care about at Live.com.  
Check it out!
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Get news, entertainment and everything you care about at Live.com.  
Check it out!

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