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

[Stanisław Pitucha]

2008/12/18 John Todd <jtodd at digium.com>:
>   I'm hoping that just embedding the whole RTP header for each stream
> would be sufficiently descriptive so that after unpacking the receiver
> would be able to determine what session was being described - isn't
> that the purpose of the SSRC?  Or would there need to be a new marker
> on a per-payload basis?  Does UDP port number factor into what session
> is receiving the stream, or is SSRC the "canonical" data?

RTP endpoint is identified basically only by the ip/port combination
afaik. SSRC may change even between early media and the 'proper' call.
Also SSRC is not communicated to the other endpoint before the first
packet, so when 2 calls start at the same time, you would get first
packets multiplexed and you don't know which one belongs where.
Way to overcome that problem - use both normal RTP and multiplexed one
- just enforce markers on every change in the stream and send the
packets with markers to RTP, then all the rest to TRTP. But imagine
what happens if you drop that first packet - you get a one way audio
for no real reason.
Also when you're calculating the cost, there's also increased cost of
processing the packets - some people already need to unpack the
stream, so it's not a big difference for them, but those who do the
simple packet forwarding (was it packet2packet, or something like
that?) will get a lot more work to do...

Stan