[Asterisk-Users] IAX2 trunk mode over satellite

[John Todd]

Today has been the day for satellite questions, apparently, so I'll 
proxy one out to the rest of the community...  I asked this 
tangentially a month or two ago, but I'll put it in a more blunt way:

If you have IAX2 trunking mode experience over satellite, please let 
us know your experiences with that protocol/transport combination.

I've got several people asking about IAX2 and trunk mode over 
satellite.  I have not experimented with IAX2 over satellite (though 
I have used IAX1 over satellite) and I'm wondering if anyone has 
direct experiences with IAX2's jitter buffer control over such 
long-latency connections.

I've had SIP working very well over satellite (despite what some 
people have found to the contrary on this list) and other than the 
lag there have been no issues that have come up on a 
reasonably-managed satellite segment.  However, the IP overhead 
really starts to cost significant amounts of pennies when you add it 
up on multiple SIP RTP sessions over the same link.  Plus, packet 
contention and buffering may (_may_) be an issue when pushing 
multiple simultaneous streams out the same transponder.

It would seem to me that IAX2 in trunk mode would be optimal for 
people on very expensive satellite bandwidth, as a G.729 9.6kbps 
channel starts to actually look like 9.6kbps instead of 24kbps. 
However, I have had mixed success with IAX2 in certain circumstances. 
Before I start to ask for favors and get satellite time for testing, 
I'd like to see if anyone else has performed this experiment.  If 
you'd wish to remain anonymous, please mail me directly and I'll 
appropriately trim identity information and re-distribute, or 
re-write as appropriate.

Other hints I have heard/used on VoIP over satellite:
   - use small transmit cell (packet) sizes on your satellite gear
   - turn off error correction (why use it for VoIP?)
   - turn off compression (G.729 is already compressed; you ARE using 
G.729, right?)
   - ensure minimal latency on the terrestrial portions of the call
   - tell your users to suck it up and deal with the half-second lag

JT