Subject: [AVT] Comment on draft-ietf-avt-rtp-framing-contrans-03.txt

From: Magnus Westerlund <[email-masked]>
Date: Fri, 03 Dec 2004 10:14:39 +0100

Hi,

I just glancing at the RTP framing for TCP due to ongoing SIPPING 
discussion. Thus I noticed that the protocol identifier registration 
needs to be extended. I think it would be good to register also 
"TCP/RTP/AVPF".

I know that we have discussed SAVP, but I don't think we discussed AVPF. 
To my understanding using AVPF does not require any extra considerations 
such as would be required for SAVP. What does the WG say?

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: David R Oran <[email-masked]>
Date: Fri, 3 Dec 2004 08:48:34 -0500

> needs to be extended. I think it would be good to register also 
Works for me.

> I know that we have discussed SAVP, but I don't think we discussed 
> AVPF. To my understanding using AVPF does not require any extra 
> considerations such as would be required for SAVP. What does the WG 
> say?
>
Seems reasonable. While having SAVP registered for TCP would also be 
useful, there's no reason to hold things up. I wonder though, exactly 
what considerations do you think are different for TCP/RTP/SAVP than 
UDP/RTP/SAVP? Interactions of SRTP integrity with attacks on TCP?

Dave.

> Multimedia Technologies, Ericsson Research EAB/TVA/A
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]

---

From: Stephen Casner <[email-masked]>
Date: Fri, 3 Dec 2004 08:07:17 -0800 (PST)

> needs to be extended. I think it would be good to register also

How would AVPF be used with TCP?  One of the primary applications for
AVPF with UDP is retransmission, but that is not applicable to TCP.

> such as would be required for SAVP. What does the WG say?

AVPF is about timing rules for sending RTCP.  When transmitting over
TCP, one cannot strictly control when packets are sent.

                                                        -- Steve

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 03 Dec 2004 17:18:46 +0100

Hi Steve,

> AVPF with UDP is retransmission, but that is not applicable to TCP.

There are also other feedback reports that can be included in RTCP. The 
reason I think that one should be able to indicate AVPF, is the case of 
a media relay, like the XCON focus. In that case, one participants may 
be required to join a session using TCP, for example due to NAT 
traversal. In that case the other participants will use AVPF get 
advantages of it. Thus there are cases where the usage of AVPF feedback 
and timing may be forwarded over the TCP/RTP connection.
> TCP, one cannot strictly control when packets are sent.

Assuming that you have sufficient bandwidth for sending packets 
immediately the rules are still useful in scenarios like the above one I 
  described.

Cheers

Magnus Westerlund

---

From: lazzaro <[email-masked]>
Date: Fri, 03 Dec 2004 13:01:28 -0800

> considerations such as would be required for SAVP. What does the WG 

I'm happy to add whatever the consensus is to the next revision
of the document, which I'm hoping to do before its expiration ...
so, I'll be tracking the discussion ...

---
John Lazzaro
http://www.cs.berkeley.edu/~lazzaro
lazzaro [at] cs [dot] berkeley [dot] edu
---

---

From: Stephen Casner <[email-masked]>
Date: Fri, 3 Dec 2004 16:10:56 -0800 (PST)

> and timing may be forwarded over the TCP/RTP connection.

Hmmm.  XCON is centralized conferencing.  I would think that the
TCP/RTP connection would be a separate RTP session from the ones using
AVPF.  That is, the MCU is an RTP mixer rather than an RTP translator.

> immediately the rules are still useful in scenarios like the above
> one I described.

But it may not be easy or possible for the application to tell whether
or not it has sufficient bandwidth.  I don't think this makes sense.
At least, I don't think that TCP/RTP/AVPF can be defined without
giving some thought to the problems that might arise with that
combination.  It is not a slam dunk.

                                                        -- Steve