18 May
2010
18 May
'10
11 p.m.
Alex-
It is not supported by rtpproxy. But you could run
all that traffic
inside a high-compression IP-in-IP UDP tunnel, though there would be
an overhead penalty there too.
We've already extended rtpproxy for transcoding and encryption, we're thinking to
continue with that approach for
header compression.
Doesn't seem to me like this stuff really saves a
lot of bandwidth,
especially in a way that has meaningful network oversubscription
returns. You might be better off just using a low-bandwidth codec
than worrying about all this.
Yes we're wondering also. The main customer concern seems to be physically slow
networks rather than
oversubscription. I.e. geographical regions and/or equipment where voice channels are
well under 50 kbps. But you
make a good point, and we're trying to evaluate this carefully.
It does seem valuable if we can get down (and stay down) to a few bytes for all headers
instead of 40. Also it seems
a lot of work has gone in the area over the last few years. For example, initial RFCs
were sensitive to packet loss,
later revisions have improved this.
-Jeff
On May 18, 2010, at 3:10 PM, Vikram Ragukumar
<vragukumar(a)signalogic.com> wrote:
> Hello,
>
> We are looking into bandwidth conservation by implementing RTP/UDP/
> IP header compression.
>
> Has anybody implemented ROHC or another header compression scheme in
> combination with kamailio + rtpproxy ? Could you please point us to
> online documentation or other useful resources ?
>
> Thanks and Regards,
> Vikram.