Many people have run VoIP over a satellite link. The inherent delay of the satellite transmission cannot be eliminated, regardless if you are using VoIP over the link, or doing traditional TDM voice. However the delay should not be noticeably worse with VoIP. It might be recommended depending on the link bandwidth to increase the sample size of the codec.
Voice over a sattelite link will give you delay in terms of conversation due to propagation delay of approx 500ms. The quality of the voice itself however can be quite good because the delay is usually constant so jitter buffer values don't need to adjust much dynamically. The main effect of sattelite delay is that when the speaker stops talking he will encounter delay hearing the listener respond. People usually adjust to this delay within 30 seconds of conversation (the human mind is very adaptive).
here's an addition to this. i have also tried to implement exactly what you are trying to do many a times. the problem which i face every time is that the quality of voice degrades as soon as the link chokes (which is frequently the case especially in satellite links which are costly and hence limited bandwidth say 64 kbps or so). As soon as the data comes and links starts hitting its peak, the voice quality degrades, it gets suppressed. it is a perennial problem which i am facing for the last 3-4 months but so far have not found any solution. I am using RSVP, MLPP, LLQ, RTP header compression and a smaller mtu size of 300 bytes. Still no improvement. Changed all codecs one by one, no improvement. under normal loads, voice quality over satellite is slightly poorer than the toll quality, delay is higher (600 ms) but not a problem as humans would adjust to it shortly and there is no way out of it.
Can someone suggest me how to overcome this problem (how to increase the sample size of codec ?)
well here are some QoS mechanisms that I think you should not use, and couple that you should.
cRTP is a must if your b/w is small.
You should also use LFI as well as LLQ.
But a major problem that I'm sensing you're having is once the data traffic hits the pipe.
Here are two things that you must implement:
WRED and CAC (Call admission control)
Use WRED to avoid congestion (that would be applicable for your data traffic only - TCP/IP) and
CAC to limit number of voice calls that are send vie the link. Do the math by adding the number of voice channels x codec (ex. 4 x 11.2kbps for G.729a) = 44.8kbps, and leave the rest for data. But in the mean time use CAC to limit number of calls to 4. In this case the 5th user will get a busy signal, where your other 4 users will have a good quality.
Also, when configuring LLQ use the priority command for the priority class. By using this you don't need to use RSVP, as the command : priority 45 (where 45 stands for 45kbps), will guarantee the b/w for those four calls.
I did some VoIP over satellite, we used 4 3660 routers, connecting in to siemens pbx's, and belive this or not but the qualty was better than a toll call to the parts of south america where the remote sites were located.
I used g729ar8, and applied some traffic shaping and standard QoS.
The only problem we had in the beginning was that the interface to the satellite modem was a 10meg Ethernet port, the problem was we only had a 512k satellite pipe, and the was no way to apply any traffic shaping or QoS to a Ethernet port less than 10 meg. The satellite vender had to replace all of the modems so we could have a serial port.
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
[toc:faq]CUCM Database Replication is an area in which Cisco customers
and partners have asked for more in-depth training in being able to
properly assess a replication problem and potentially resolve an issue
without involving TAC. This document discusse...