CCME over SATCOM link

rochesterjcw · ‎01-12-2008

Can I run 7941 or 7911 phones over a SATCOM link to a 2811 equipped with the Secure Voice package (CCME)? Latency will be around 240 mS in each direction.

paolo bevilacqua · ‎01-13-2008

Yes. I have setups like that and quality is surprisingly good. For now, I would recommend using g.711 if possible at all. Then in the future, with the newer phones, you will be able to use iLBC codec for a lower bandwidth usage.

Hope this helps, please rate post if it does!

pcameron · ‎01-13-2008

The delay will give users the impression they are talking on a two way radio ('over!') , so as long as their expectations are set it should work. If you have multiple remote sites they delay is going to be compounded.

Some other suggestions -

If this is CME , use a local router running CME at each side and that way you can link the sites via VOIP dial peers configured for G729. You can reduce bandwidth by changing the byte size of the codec as well , this will make larger packets , but send less packets, so you save by reducing the IP./UDP/RTP overhead.

dial-peer voice 1 voip

destination-pattern 1234

session target ipv4:1.1.1.1

dtmf-relay h245-alphanumeric

codec g729r8 bytes 40 <--- will reduce B/W per call from 25Kbps to 16Kbps

2) If possible, enable RTP header compression on each side of the link.

3) Another option with a centralised CME is to use G729 dsp transcoding on remote ephones. You need DSP resources dedicated for this function . Here is a sample config (if you use it, you would need to change MAC addresses etc ...) -

!

sccp local GigabitEthernet0/0

sccp ccm 172.19.150.56 identifier 1

sccp

!

sccp ccm group 1

associate ccm 1 priority 1

associate profile 1 register MTP0013c49a0cd0

keepalive retries 5

!

dspfarm profile 1 transcode

codec g711ulaw

codec g711alaw

codec g729ar8

codec g729abr8

codec gsmfr

codec g729r8

maximum sessions 90

no shutdown

associate application SCCP

!

telephony-service

load 7960-7940 P00307020300

max-ephones 10

max-dn 20

ip source-address 172.19.150.56 port 2000

system message Lab Test CCME 4.1

sdspfarm units 1

sdspfarm transcode sessions 128

sdspfarm tag 1 MTP0013c49a0cd0

voicemail 7800

max-conferences 24 gain -6

call-forward pattern .T

moh music-on-hold.au

multicast moh 239.1.1.1 port 2000

web admin system name admin password cisco

transfer-system full-consult

transfer-pattern .T

secondary-dialtone 9

after-hours block pattern 1 9911 7-24

create cnf-files version-stamp Jan 01 2002 00:00:00

!

ephone-dn 2

number 6002

call-forward busy 7800

call-forward noan 7800 timeout 10

!

ephone-dn 5 dual-line

number 6005

call-forward busy 7800

call-forward noan 7800 timeout 10

!

ephone 5

device-security-mode none

username "Zaphod Beeblebrox"

mac-address 0011.5C0E.571B

paging-dn 99 unicast <--- Paging should be set to unicast if multicast-routing is not enabled on WAN:

codec g729r8 dspfarm-assist <---- this will force G729 as the codec to the phone

mtp <--- this will invoke an MTP/transcoder for the connection to the other phones

type 7970

button 1:5 2:2

4) If this is Call Manager, consider using regions to set the codec to G729, or use local transcoding resources to utilise G729 on the WAN and G711 on the LAN.

rochesterjcw · ‎01-13-2008

This is all good information and I will try this next time I get the link.

I have gotten as far as having the console display the initial registration messages for the phone, but these are followed two seconds later by an message indicating that the phone unregistered abnormally. Wireshark data of bad registrations on a SATCOM link compared to good registrations on a local link show that in the SATCOM link case, the router drops the control connection to the phone about half way through the SKINNY dialog. The only difference I can see between the good and the bad case is the 240 mS one way latency in the bad case.

Is there any timer or other time-based requirement that I am not meeting using a simple CME configuration and Default xml files?

pcameron · ‎01-13-2008

The sccp needs to loose 3 keepalives before it unregisters - in this case it doesn't sound like a KA issue as you never get to the full registration state.

My guess is this is due to a TCP establishment problem.

The wireshark should show the standard TCP 3 way handshake - you need to check which side then drops the TCP session.

I did a search through our database and found some references to a problem on earlier PIX firewalls with skinny fixup and high latency links - do you have a firewall in the data path ? Bug ID is CSCsh26607 and is fixed in latest 7.2 and 8.0 PIX code.

paolo bevilacqua · ‎01-14-2008

Hello,

not sure why the low rating to my post that gives factual and real information. If you have problems in making the registration work, you can try is to run the phones as SIP to avoid any TCP problem.

Aaron Dhiman · ‎01-14-2008

I manage a large network with VoIP over satellite. Surprisingly, the quality is good with G.729. Here are some recommendations:

1. If your VSAT link is low bandwidth, make sure to use Header Compression, as well as Fragmentation/Interleaving. Pcameron's recommendation to increase packet size is an alternate to Header Compression if you can't do it (no MLPP).

2. Definitely configure LLQ on both ends of the link.

3. If you have some links which exhibit high jitter, you could run into excessive Silence Insertion, b/c there are limitations on the jitter buffers on some router platforms (I have exerienced them on the 7206). Be sure to monitor the silence insertion during your testing. I do this with "sh call active voice brief" and pay attention to these stats:

pl:17930/1930ms lost:97/2/0 delay:70/70/70ms