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@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.