Help with CME in a high latency (SATCOM) environment

Jan 10, 2008 3 Replies
J

I'm having trouble getting a Cisco 7911 or 7941 phone to stay registered in a CME environment where the link latency is on the order of 250 mS each direction. The phones will appear to have registered as indicated by messages at the router console, but within 2 seconds, an unregistered abnormally message is seen. The message flow as seen by Wireshark looks the same as a normal registration up until the router closes the control connection on port 2000. This sequence repeats over and over again as long as the phone is powered.



Can anyone provide some insight on what might be going on and what I can try to sort this out? I could swear I was told that CME would work over SATCOM links. What have I gotten wrong?



Thanks in advance for clues, insights, and solutions.



John in Rochester


Vote
Twitter Facebook LinkedIn
M

I think there is a Cisco DDTS that indicates that for any latency over

240 ms that you need to have a local TFTP server to download the phone firmware
Vote
Twitter Facebook LinkedIn
J

On Jan 10, 4:52=A0pm, Merv wrote:

Here's the Wireshark trace:

No. Time Source Destination Protocol Info 41 43.851564 192.168.135.151 192.168.130.1 TFTP Read Request, File: CTLSEP001E7A25B6C8.tlv, Transfer type: octet 42 43.853648 192.168.130.1 192.168.135.151 TFTP Error Code, Code: File not found, Message: No such file 44 44.391688 192.168.135.151 192.168.130.1 TFTP Read Request, File: SEP001E7A25B6C8.cnf.xml, Transfer type: octet 45 44.393693 192.168.130.1 192.168.135.151 TFTP Error Code, Code: File not found, Message: No such file 46 44.796587 192.168.135.151 192.168.130.1 TFTP Read Request, File: XMLDefault.cnf.xml, Transfer type: octet 47 44.799582 192.168.130.1 192.168.135.151 TFTP Data Packet, Block: 1 48 45.201354 192.168.135.151 192.168.130.1 TFTP Acknowledgement, Block: 1 49 45.202976 192.168.130.1 192.168.135.151 TFTP Data Packet, Block: 2 50 45.606495 192.168.135.151 192.168.130.1 TFTP Acknowledgement, Block: 2 51 45.607616 192.168.130.1 192.168.135.151 TFTP Data Packet, Block: 3 (last) 52 46.011445 192.168.135.151 192.168.130.1 TFTP Acknowledgement, Block: 3 56 46.701342 192.168.135.151 192.168.130.1 TCP 52053 > tdbm [SYN] Seq=3D0 Len=3D0 MSS=3D1400 57 46.702777 192.168.130.1 192.168.135.151 TCP tdbm > 52053 [SYN, ACK] Seq=3D0 Ack=3D1 Win=3D4128 Len=3D0 MSS=3D53=

6 59 47.095500 192.168.135.151 192.168.130.1 TCP 52053 > tdbm [ACK] Seq=3D1 Ack=3D1 Win=3D8192 Len=3D0 60 47.095506 192.168.135.151 192.168.130.1 SKINNY AlarmMessage 61 47.095807 192.168.135.151 192.168.130.1 SKINNY AlarmMessage 63 47.230405 192.168.135.151 192.168.130.1 SKINNY RegisterMessage 64 47.293941 192.168.130.1 192.168.135.151 TCP tdbm > 52053 [ACK] Seq=3D1 Ack=3D273 Win=3D3856 Len=3D0 65 47.372566 192.168.130.1 192.168.135.151 SKINNY RegisterAckMessage 66 47.372780 192.168.130.1 192.168.135.151 SKINNY CapabilitiesReqMessage 67 47.771395 192.168.135.151 192.168.130.1 SKINNY IpPortMessage 68 47.771586 192.168.135.151 192.168.130.1 SKINNY ButtonTemplateReqMessage 69 47.771588 192.168.135.151 192.168.130.1 SKINNY SoftKeyTemplateReqMessage 70 47.771793 192.168.135.151 192.168.130.1 SKINNY SoftKeySetReqMessage 71 47.771795 192.168.135.151 192.168.130.1 SKINNY ConfigStatReqMessage 72 47.772209 192.168.135.151 192.168.130.1 SKINNY CapabilitiesResMessage 73 47.772211 192.168.135.151 192.168.130.1 SKINNY HeadsetStatusMessage 76 47.875883 192.168.130.1 192.168.135.151 TCP [TCP segment of a reassembled PDU] 82 48.310389 192.168.135.151 192.168.130.1 TCP 52053 > tdbm [ACK] Seq=3D513 Ack=3D538 Win=3D8192 Len=3D0 83 48.378127 192.168.130.1 192.168.135.151 SKINNY SoftKeyTemplateResMessage 84 48.379981 192.168.130.1 192.168.135.151 TCP [TCP segment of a reassembled PDU] 85 48.380194 192.168.130.1 192.168.135.151 SKINNY SoftKeySetResMessage 87 48.630168 192.168.130.1 192.168.135.151 TCP tdbm > 52053 [FIN, PSH, ACK] Seq=3D1501 Ack=3D513 Win=3D3616 Len=3D= 0 88 48.850357 192.168.135.151 192.168.130.1 TCP 52053 > tdbm [ACK] Seq=3D513 Ack=3D1501 Win=3D8192 Len=3D0 89 49.120218 192.168.135.151 192.168.130.1 TCP 52053 > tdbm [FIN, ACK] Seq=3D513 Ack=3D1502 Win=3D8192 Len=3D0 90 49.120926 192.168.130.1 192.168.135.151 TCP tdbm > 52053 [ACK] Seq=3D1502 Ack=3D514 Win=3D3616 Len=3D0

Look at packet number 87. This is the first place an unsuccessful registration differs. Note that the router (192.168.130.1) is dropping the control connection ~240 mS after sending a SoftKeySetResMessage. Also note that the ACK does come, but after 470 mS.

Is there a way to make the router more tolerant of high latency links???

Vote
Twitter Facebook LinkedIn
T

No there isn't. This isn't a router issue, but a VoIP issue. VoIP does not like high latency links and anything greater than 250ms will affect voice quality so SEVERELY that it isn't usable. You really want latency less than

150ms as even at that level it is noticeable to callers.

"JohnInRochester" wrote in message news: snipped-for-privacy@c4g2000hsg.googlegroups.com... On Jan 10, 4:52 pm, Merv wrote:

Here's the Wireshark trace:

No. Time Source Destination Protocol Info 41 43.851564 192.168.135.151 192.168.130.1 TFTP Read Request, File: CTLSEP001E7A25B6C8.tlv, Transfer type: octet 42 43.853648 192.168.130.1 192.168.135.151 TFTP Error Code, Code: File not found, Message: No such file 44 44.391688 192.168.135.151 192.168.130.1 TFTP Read Request, File: SEP001E7A25B6C8.cnf.xml, Transfer type: octet 45 44.393693 192.168.130.1 192.168.135.151 TFTP Error Code, Code: File not found, Message: No such file 46 44.796587 192.168.135.151 192.168.130.1 TFTP Read Request, File: XMLDefault.cnf.xml, Transfer type: octet 47 44.799582 192.168.130.1 192.168.135.151 TFTP Data Packet, Block: 1 48 45.201354 192.168.135.151 192.168.130.1 TFTP Acknowledgement, Block: 1 49 45.202976 192.168.130.1 192.168.135.151 TFTP Data Packet, Block: 2 50 45.606495 192.168.135.151 192.168.130.1 TFTP Acknowledgement, Block: 2 51 45.607616 192.168.130.1 192.168.135.151 TFTP Data Packet, Block: 3 (last) 52 46.011445 192.168.135.151 192.168.130.1 TFTP Acknowledgement, Block: 3 56 46.701342 192.168.135.151 192.168.130.1 TCP 52053 > tdbm [SYN] Seq=0 Len=0 MSS=1400 57 46.702777 192.168.130.1 192.168.135.151 TCP tdbm > 52053 [SYN, ACK] Seq=0 Ack=1 Win=4128 Len=0 MSS=536 59 47.095500 192.168.135.151 192.168.130.1 TCP 52053 > tdbm [ACK] Seq=1 Ack=1 Win=8192 Len=0 60 47.095506 192.168.135.151 192.168.130.1 SKINNY AlarmMessage 61 47.095807 192.168.135.151 192.168.130.1 SKINNY AlarmMessage 63 47.230405 192.168.135.151 192.168.130.1 SKINNY RegisterMessage 64 47.293941 192.168.130.1 192.168.135.151 TCP tdbm > 52053 [ACK] Seq=1 Ack=273 Win=3856 Len=0 65 47.372566 192.168.130.1 192.168.135.151 SKINNY RegisterAckMessage 66 47.372780 192.168.130.1 192.168.135.151 SKINNY CapabilitiesReqMessage 67 47.771395 192.168.135.151 192.168.130.1 SKINNY IpPortMessage 68 47.771586 192.168.135.151 192.168.130.1 SKINNY ButtonTemplateReqMessage 69 47.771588 192.168.135.151 192.168.130.1 SKINNY SoftKeyTemplateReqMessage 70 47.771793 192.168.135.151 192.168.130.1 SKINNY SoftKeySetReqMessage 71 47.771795 192.168.135.151 192.168.130.1 SKINNY ConfigStatReqMessage 72 47.772209 192.168.135.151 192.168.130.1 SKINNY CapabilitiesResMessage 73 47.772211 192.168.135.151 192.168.130.1 SKINNY HeadsetStatusMessage 76 47.875883 192.168.130.1 192.168.135.151 TCP [TCP segment of a reassembled PDU] 82 48.310389 192.168.135.151 192.168.130.1 TCP 52053 > tdbm [ACK] Seq=513 Ack=538 Win=8192 Len=0 83 48.378127 192.168.130.1 192.168.135.151 SKINNY SoftKeyTemplateResMessage 84 48.379981 192.168.130.1 192.168.135.151 TCP [TCP segment of a reassembled PDU] 85 48.380194 192.168.130.1 192.168.135.151 SKINNY SoftKeySetResMessage 87 48.630168 192.168.130.1 192.168.135.151 TCP tdbm > 52053 [FIN, PSH, ACK] Seq=1501 Ack=513 Win=3616 Len=0 88 48.850357 192.168.135.151 192.168.130.1 TCP 52053 > tdbm [ACK] Seq=513 Ack=1501 Win=8192 Len=0 89 49.120218 192.168.135.151 192.168.130.1 TCP 52053 > tdbm [FIN, ACK] Seq=513 Ack=1502 Win=8192 Len=0 90 49.120926 192.168.130.1 192.168.135.151 TCP tdbm > 52053 [ACK] Seq=1502 Ack=514 Win=3616 Len=0

Look at packet number 87. This is the first place an unsuccessful registration differs. Note that the router (192.168.130.1) is dropping the control connection ~240 mS after sending a SoftKeySetResMessage. Also note that the ACK does come, but after 470 mS.

Is there a way to make the router more tolerant of high latency links???

Vote
Twitter Facebook LinkedIn

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required