Re: [rtcweb] Review of draft-perkins-rtcweb-usage-03 (Re: Fwd: New Version Notification for draft-perkins-rtcweb-rtp-usage-03.txt)

[Colin Perkins <[e-mail]>]

Harald,

On 29 Aug 2011, at 14:33, Harald Alvestrand wrote:
> Colin, I really like this version!
> 
> There might want to be a placeholder about multiplexing, saying "we will return to this issue after more discussion". Otherwise, it seems to me we're setting up the expectation that this will be handled entirely in some other document - I think the end product of the WG needs to discuss it, and it seems logical that some aspect of it should go here.

Yes, I'll add this.

> Some detailed comments:
> 
> - In Figure 2, section 1.1, I think you're making the assumption that multi-unicast topologies will use a single shared RTP session (SSRC number space) for all the links. This is not obvious; it's possible to build this topology on point-to-point RTP sessions too.

It's possible, but not necessarily desirable. Building this using a single RTP session (with a shared SSRC space) makes debugging a lot easier, since you can do third-party debugging (e.g., you can see from the RTCP that Alice can hear Bob talking, but you can't, so you know there's a problem somewhere, and can alert the user). It also enables various other features, such as third-party retransmissions. 

> - In section 3, you make the point that improper signalling of bandwidth can cause failure to interoperate (because of differing RTCP timings). Is there a (possibly theoretical) problem with interoperation between RTP/AVP and RTP/AVPF too, or have we verified that the AVPF profile always sends enough RTCP packets that AVP-conformant endpoints don't time out?

I'm not aware of any problems here. They were designed to interoperate.

> - In section 6, I would recommend removing the point about scenarios with mixers using point-to-point RTP sessions are "not well utilizing the mechanisms of RTP" - I think people's engineering tradeoffs should be respected.
> I'm fine with leaving in the comment about protocol violations (although I'd like to be more specific about what they are - protocols shouldn't be violated; if people "have" to do that, there's something wrong with the protocol).

The referenced sections of RFC 5117 list specific technical problems with these approaches. I agree that the wording could be improved, but I think that the recommendation is generally appropriate.

> - In the list of other extensions, section 6.2, you say that two extensions are "not recommended" - is this a recommendation against (like NOT RECOMMENDED would be), or simply a declaration that their use or non-use is of no concern?

My feeling is there's no clear benefit for RTCWeb from implementing these other extensions. The wording is perhaps a little strong, and could be weakened.

> - there are some sections with garbled grammar (the last paragraph of section 7.2, before 7.2.1, is particularly irksome to the eye), but I assume that this will be reviewed in later versions; the meaning comes through.


Yeah, I'll review it and try to improve things in a coming version.

-- 
Colin Perkins
http://csperkins.org/