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 > <vraguku...@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. _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
