[asterisk-dev] RTP trunking - 58% savings on media bandwidth?

[Tim Panton]

On 18 Dec 2008, at 09:13, John Todd wrote:

> [While I should be doing many, many other things this late evening
> I'll spend some time and write about improvements that will only be
> useful to a few people to the tune of tens of thousands of dollars.  I
> probably should be doing something else, but I have a hard time
> letting go of a concept once it gets in my head, so putting it down in
> a -dev posting for sad review years from now is really what I need to
> do.]
>
>   This started on the thread about cRTP, but that quickly turned to a
> dead end since cRTP seems to be link or interface specific and has
> nothing to do really with RTP at endpoints.  So I mulled it over a
> bit, and came up with my idea for a multiplexed RTP (or what I'm now
> calling "trunked RTP", or "TRTP", to be more consistent with IAX2
> trunking concepts which this is based upon) .  The numbers I
> calculated far below are interesting, especially with lower-rate
> codecs - it looks like one can get slightly less than twice the amount
> of channels into the same bandwidth by getting rid of IP overhead by
> multiplexing RTP sessions into a single UDP packet stream.  The
> details are not excruciating, and I think the use of existing concepts
> and code makes this probably fairly do-able.  Any reasonably-sized
> carrier that does international traffic on high-price links might find
> this useful - it provides some of the IAX2 trunking benefits without
> having to shift over entirely to IAX2, and maybe it would be quickly
> implementable by other SIP/RTP stacks that wanted to see decreases in
> bandwidth usage between high-traffic nodes.
>
-----details omitted----

One of the disadvantages of this in IAX2 is that the audio streams are
no-longer 'free running'. Generally asterisk doesn't mess with the  
timing of a
bridged call, so if the transmitter is running fast then asterisk  
faithfully resends
these packets at that speed, and the receiver gets to re-sample/re- 
sync as
needed. In a IAX trunked situation (and in meetme) Asterisk takes over  
the
timing of the outgoing packets and has to do some re-sync (it doesn't  
resample).

In a world where most calls have a PSTN component (with perfect  
clocking)
this isn't a problem, but as we move to a pure VoIP world, this is  
going to get
harder and harder to cope with.

Imagine you have a batch of softphones calling each other, each basing  
their timing
on their local (and cheap) audio hardware. You could easily get a 5%  
difference
between the fastest and slowest senders. (I wonder what skype does?)

I'd guess to do this we need a resampler built in to the mechanism, or  
an explicit
're-sync' frame.

T.