Subject: [MMUSIC] RE: [dccp] Using DCCP for VoIP

From: [email-masked]
Date: Thu, 17 Jul 2003 10:37:47 +0200

All,

IMHO this issue is related to my question in the other mail about managing audio AND video at the same time:

probably DCCP should have a way to handle "collectively" a bunch of streams, be it audio plus video or  two-way audio!

regards,

Philippe Gentric
Software Architect
Philips MP4Net
[email-masked]
http://www.platform4.philips.com

                                                                                                                                       
                                                   To:   "'Reiner Ludwig'" <[email-masked]>                                
                                                    [email-masked]                                                                      
                                                   cc:   (bcc: Philippe Gentric/MP4-SUR/CE/PHILIPS)                                    
                                                   Subject:    RE: [dccp] Using DCCP for VoIP                                          
               "Phelan, Tom"                                                                                                           
               <[email-masked]>              Classification:                                                                     
                                                                                                                                       
               Sent by:                                                                                                                
               [email-masked]                                                                                                     
                                                                                                                                       
               17/07/2003 09:17                                                                                                        

Hi Reiner,

I guess I missed this when you sent it on tsvwg, thanks for resending.  To
me it seems to say that the thought of using TRFC for two-way telephony is
fundamentally broken, so DCCP isn't usable for that until there's a new
CCID.

Tom P.

> -----Original Message-----
> From: Reiner Ludwig [mailto:[email-masked]]
> Sent: Wednesday, July 16, 2003 3:06 AM
> To: [email-masked]
> Subject: RE: [dccp] Using DCCP for VoIP
>
>
> I'm forwarding this mail since I believe it relates to the currrent
> discussion about DCCP for VoIP. I had sent this mail to the
> tsvwg mailing
> list a few weeks ago ...
>
> ///einer
>
>
> >X-Sender: [email-masked]
> >X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
> >Date: Fri, 04 Apr 2003 10:52:58 +0200
> >To: [email-masked]
> >From: Reiner Ludwig <[email-masked]>
> >Subject: Re: [Tsvwg] redundant data - A TFRC Example
> >Sender: [email-masked]
> >X-BeenThere: [email-masked]
> >X-Mailman-Version: 2.0.12
> >List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
> >         <mailto:[email-masked]?subject=unsubscribe>
> >List-Id: Transport Area Working Group <tsvwg.ietf.org>
> >List-Post: <mailto:[email-masked]>
> >List-Help: <mailto:[email-masked]?subject=help>
> >List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
> >         <mailto:[email-masked]?subject=subscribe>
> >
> >I'd like to add an example for people to think about ...
> >
> >If you try to run VoIP over TFRC, you'll most likely be
> disappointed by
> >the quality. The reason is that when A talks, then (usually)
> B is silent,
> >and vice versa. I.e., a talkspurt A>B is followed by a
> talkspurt B>A is
> >followed by a talkspurt A>B, ....
> >
> >While B is silent and if the talkspurt from A is long enough
> then B's TFRC
> >send rate will decay to zero (or at least often enough below
> the required
> >coder rate). Andrei Gurtov did this experiment and told me
> how 'broken'
> >such a voice conversation becomes.
> >
> >The "easy fix" is for B to send dummy data (or even
> potentially useful
> >data like pictures, ads, calendar sync data, etc.) for the
> sole purpose of
> >maintain the TFRC rate above the required coder rate. B
> would be a good
> >Internet citizen in the sense that it is always TCP
> friendly. Still, B is
> >sending data it does't have to send necessarily.
> >
> >Should the IETF set up rules that would limit the sending of such
> >potentially useless data? Do we have hope that such rules
> would be obeyed
> >by application and protocol designers?
> >
> >I could imagine VoIP application designers that would let
> themselves be
> >convinced to move away from uncontrolled UDP to RTP/DCCP,
> but probably not
> >much further. I.e., their view could be: "We ensure that our
> flows behave
> >TCP friendly, but what we do with the available bandwidth is
> our business."
> >
> >I'm not saying that I agree to that, but I would understand
> that view.
> >
> >///Reiner
> >
> >_______________________________________________
> >tsvwg mailing list
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/tsvwg
>
>
> _______________________________________________
> dccp IETF mailing list: [email-masked]
> list info:  https://www1.ietf.org/mailman/listinfo/dccp
> wg charter: http://www.ietf.org/html.charters/dccp-charter.html
>

_______________________________________________
dccp IETF mailing list: [email-masked]
list info:  https://www1.ietf.org/mailman/listinfo/dccp
wg charter: http://www.ietf.org/html.charters/dccp-charter.html

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Eddie Kohler <[email-masked]>
Date: Thu, 24 Jul 2003 13:21:19 -0700

Hi all,

On this issue:

> IMHO this issue is related to my question in the other mail about
> managing audio AND video at the same time: probably DCCP should have a
> way to handle "collectively" a bunch of streams, be it audio plus video
> or two-way audio!

Our thought was that, given DCCP's unreliability, it is trivial to layer
multiple streams on top. The first byte of packet data could indicate
stream number to the application. This works as long as both streams want
to share the same congestion control state + CC mechanism -- is this the
case?

Eddie