Re: [AVT] FW: New Version Notification for draft-ietf-avt-ports-for-ucast-mcast-rtp-10

Hi Ali,

On 3 Jan 2011, at 16:24, Ali C. Begen (abegen) wrote:
> Hi Colin,
> 
>> -----Original Message-----
>> From: Colin Perkins [mailto:csp@csperkins.org]
>> Sent: Monday, January 03, 2011 9:22 AM
>> To: Ali C. Begen (abegen)
>> Cc: avt@ietf.org
>> Subject: Re: [AVT] FW: New Version Notification for draft-ietf-avt-ports-for-ucast-mcast-rtp-10
>> 
>> Ali,
>> 
>> On 21 Dec 2010, at 07:10, Ali C. Begen (abegen) wrote:
>>> This revision includes the changes we agreed on in the last week's call and after the feedback on the list. It also addresses
>> Glen's comments, makes some clarifications here and there.
>> 
>> 
>> This is looking good. Some minor comments only:
>> 
>> - Section 3:  “Therefore, the server will need the client to also include the Token along with the RTCP messages that are
>> different from the RTCP message that triggerred the unicast session establishment.” - I don’t understand what this means.
>> Can you clarify in the draft?
> 
> Certain messages don’t establish a unicast session but control it, and they can be required to be bundled with a token as well as described in 4.3.1.

Sure, I understand that. But the text in the draft is unclear, and needs updating.

>> - Section 4.1: “Here, the SSRC value is not necessarily linked to the one used by the client in the multicast session.” - what do
>> you mean by “not necessarily” here? They’re either part of the same RTP session, in which case the client should use the
>> same SSRC; or they’re not, in which case the client should choose its SSRC randomly.
> 
> When requesting a Token, the SSRC used or chosen by the client does not matter. Think about a client requesting a token during booting. It can use that token with any ssm session later on. We could say "Here the SSRC value can be chosen randomly by the client since the Port Mapping Request message is not necessarily linked to a specific multicast session."
> 
> Is this better?

Not really, since it's just as vague. Saying the SSRC "can" be chosen randomly doesn't help: either it is chosen randomly, or it isn't. Which is it?

>> - Section 4.2: The addition of the packet types element is good. However, for clarify, it would be useful to include a packet
>> diagram showing the format of such an element with enough entries to fill more than one 32 bit block and require padding
>> to the next.
> 
> OK, I will give it a shot.
> 
>> - Figure 6: “PT of request” - the RTCP packet that causes this respond to be generated might not be a request to the server.
>> This field might be clearer called “Failed PT”?
> 
> Sounds good.
> 
>> I didn't look at the SDP sections, sorry.
> 
> Thanks anyway.
> -acbegen
> 
>> --
>> Colin Perkins
>> http://csperkins.org/
>> 
>> 
> 
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt

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