18 May
2010
18 May
'10
7:10 p.m.
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.
18 May
18 May
7:26 p.m.
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(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.
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
8 p.m.
New subject: Robust header compression (RFC 3095) with Kamailio +rtpproxy
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.
11:04 p.m.
New subject: Robust header compression (RFC 3095) with Kamailio +rtpproxy
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(a)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(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.
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
5110
days inactive
5110
days old
3 comments
4 participants
participants (4)
-
Alex Balashov -
Jeff Brower -
Ovidiu Sas -
Vikram Ragukumar