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.
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.
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.
-- Alex Balashov - Principal Evariste Systems LLC 1170 Peachtree Street 12th Floor, Suite 1200 Atlanta, GA 30309 Tel: +1-678-954-0670 Fax: +1-404-961-1892
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.
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
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.
Without RoHC, the only 'cheap' way to save on bandwidth is to increase the packetization time, which leads to delays. Also, if a packet is dropped, a big chunk of media is lost. With RoHC, packetization time doesn't really matter. Choosing a low value for packetization (10-20ms) reduce the latency a lot and if a packet is discarded, the effect is negligible.
RoHC makes a lot of sense in scenarios where bandwidth is expesive (wireless transmissions). It can save a lot of bandwidth and it can improve the voice quality (low delay by choosing a low value for packetization and better tolerance for packet loss).
Regards, Ovidiu Sas
On Tue, May 18, 2010 at 4:00 PM, Jeff Brower jbrower@signalogic.com wrote:
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.
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
-
Alex Balashov -
Jeff Brower -
Ovidiu Sas -
Vikram Ragukumar