Subject: Re: [AVT] Working group last call: draft-ietf-avt-rtp-framing-contrans-04.txt

From: Magnus Westerlund <[email-masked]>
Date: Wed, 05 Jan 2005 16:35:30 +0100

Hi,

[AVT chair hat off]

I have reviewed the draft and has the following comments.

1. I am concerned that the draft is written in a bit to AVP centric. I 
know that the draft only registers, and apparently there is not enough 
consensus and interest to define any other profile for the moment. 
However the format and its basic signalling properties would be the same 
independent of the profile in use.

2. Section 2, second paragraph: I think the last sentence could benefit 
a informative reference to RTP section A.1 for checks that can be used 
to verify correct alignment.

New text: In lieu of a frame
marker, receivers SHOULD monitor the RTP and RTCP header fields whose
values are predictable (for example, the RTP version number), see also 
section A.1 of RFC 3550 [ ].

3. Section 3, the first Undefined property:
      "The framing method is commonly used for sending a single
       RTP or RTCP stream over a connection.  However, Section
       2 does not define this common use as normative, so that
       (for example) a memo that defines an RTP SSRC multiplexing
       protocol may use the framing method."

The expected property must be that any contrans supports usage of 
multiple SSRCs. The behavior to expect needs to be the same for RTP over 
UDP and RTP over TCP. What comes in on the TCP connection, can be the 
same as what can come in over UDP port in unicast mode from a single 
source. The difference between TCP and UDP is really only that you can't 
receive from multiple sources to the same port as I understand the 
signalling.

I would like to rephrase and move the paragraph. It should define the 
expected properties in this case for clarity.

4. Section 4. I think the signaling section should clearly define that 
the basic procedure for establishing the TCP connection that the RTP 
framing is sent over is using COMEDIA. This should be in the first 
paragraph.

For example a sentence like:
The transport of RTP/AVP over TCP when signaled using SDP and the 
offer/answer method [RFC3264] SHALL establish its TCP connection as 
defined by comedia [xx]. The RTP/AVP over TCP is identified in SDP using 
the "proto" identifier "TCP/RTP/AVP".

For this SDP "proto" identifier the fmt list ...

I would also like to point out that due to comedia it doesn't seem that 
this framing method can be used in any non Offer/Answer usage. Or have I 
missed something in the comedia draft?

5. Section 4, second last paragraph:
"The RTP stream MUST have an unbroken sequence number order.  RTCP 
stream packets MUST appear as defined in [2], with no lost or re-ordered
packets.  IETF standards-track documents MAY loosen these restrictions
on packet loss and packet ordering."

This paragraph is in contradiction with a statement in section 3. I also 
think that it is wrong to make this requirement on the packets entering 
the TCP connection.

6. What is meant with the following sentence in section 4:
"The out-of-band semantics for the connection MUST comply with [3]." I 
don't think it is clear what is meant with out-of-band semantics.

7. Section 4. Does this section also need to define the usage of the 
"a=rtcp" SDP attribute under this profile. Because I think there are 
advantages of being able to define another TCP port for RTCP than the 
RTP port + 1.

8. Section 4, which method are used to indicate the non-presence of RTCP 
when using this transport?

9. Section 8. The Length field consideration. I think one can be a bit 
more direct in the recommendation. I would like to add this following 
sentence to the end of the paragraph:
"Thus, a implementation needs to handle packets of any length from the 
NULL packet (Length=0) to max length 64K packet (Length=0xFFFF).

10. The lack of recommendations on how to register more identifiers for 
other profiles and what they would need to consider.

I am sorry that I can't provide more text proposals. I am also sorry for 
these late comments, these should have been raised before.

Cheers

Magnus

Colin Perkins wrote:
> This is to announce a working group last call on the method for Framing  
> RTP and RTCP Packets over Connection-Oriented Transport:
> 
> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-framing- 
> contrans-04.txt
> 
> Please send any final comments on this draft to the <[email-masked]>  
> mailing list by 5th January 2005. If no substantive technical issues  
> are raised by that time, we will submit the draft for publication as a  
> Proposed Standard RFC.
> 
> Colin
> 
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/avt
> 

-- 

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: Colin Perkins <[email-masked]>
Date: Thu, 6 Jan 2005 09:49:50 +0000

On 13 Dec 2004, at 16:47, Colin Perkins wrote:
> This is to announce a working group last call on the method for  
> Framing RTP and RTCP Packets over Connection-Oriented Transport:
>

This working group last call period ended yesterday. Magnus raised a  
number of technical issues. Accordingly, the draft will not be advanced  
until they have been addressed.

Colin