Re: [AVT] I-D Action:draft-ietf-avt-ports-for-ucast-mcast-rtp-08.txt - my review

["Ali C. Begen (abegen)" <[e-mail]>]

Hi Roni,

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Roni Even
> Sent: Monday, December 13, 2010 8:11 AM
> To: [e-mail]
> Subject: Re: [AVT] I-D Action:draft-ietf-avt-ports-for-ucast-mcast-rtp-08.txt - my review
> 
> Hi,
> I read this version of the draft and read all the email exchange from the
> last weeks.
> I will provide my view and not address a specific issue.
> I am doing it as an individual
> 
> 
> 1. The introduction section just before figure 1 has the following sentence
> "This solution allows receivers to choose their desired UDP ports for RTP
> and RTCP in every unicast session when they are running RTP applications
> using both unicast and multicast services, and offer/answer exchange is not
> available.". My view and I agree with Tom on this one is that this is the
> only use case. I am not sure why the Magnus added the need for offer answer
> since if there is an offer answer exchange the answer can provide the
> unicast address and port for receiving the unicast stream. For example if
> you take the example in figure 7, the unicast m-line in the answer with
> mid=2 will provide the transport address for the unicast retransmission. I
> am wondering if the motivation is to have "yet another ICE"

I will let Magnus answer this, however, I think his main motivation was unless we do it here properly, it could be done improperly in the future somewhere else. 
 
> 2. A nit in section 3.1 second paragraph second sentence add "token" so it
> will say "When a token request" .

OK.
 
> 3. Section 4 defines Token verification failure message. Maybe it should be
> mentioned in section 3 that discuss the new messages.

I will look into it.
 
> 4. In section 4 third paragraph you use RFC 4585 for discussion the RTCP
> message scheduling, why not reference RFC 6051

6051 does not make changes on the receiver behavior that we care about here. Does it?
 
> 5. Section 4.3 says " Currently, the following RTCP messages are REQUIRED
> to be accompanied by a Token Verification Request message:". I have some
> questions here"
> 
>    5.1 Is this true all the time or only if a token is used.

Of course, the 'portmapping-req' attribute has to exists. Ow, it means the server does not support it anyway.

>    5.2 I understand that it is always required for RAMS but not always for
> NACK, BYE and CCM. Some text is needed to explain when to send it.

Unless it is purely unicast app (which is not something we consider), yes, these messages require Tokens because they need to be authorized.
 
> 
> 6. A nit in section 6 second paragraph "The server first applies the its own
> procedure". Delete the "the".

Ok.
 
> 7. In section 6 you do not mention the case when the server expected a token
> and did not get one.

If there is no token, there is nothing to validate. 
 
> 8. In section 7.1 the draft suggests that the portmapping-req attribute can
> be a media or session level. So if used at the session level does it relate
> also to the multicast session when used in a grouping of a unicast and
> multicast retransmission definition. That will be inconsistent if the
> attribute provides only a port for a multicast session there is a problem
> according to next section (see my next comment).  So either it MUST have the
> optional address parameter if specified at the session level or only allow
> it at the media level. I think that this attribute is relevant only for the
> unicast session and the text should say that if used at the session level
> MUST have the address parameter.

I would be ok to define it at media level only. But, in the last meeting or the one earlier, we kinda agreed to have it at session level, too.

I don't see why not specifying an address at session level would be a problem. If the address does not exist, you get it from the c line (in the respective unicast block.
 
> 9. In section 7.1 " In the optional address value, only unicast addresses
> are allowed; multicast addresses SHOULD NOT be used ...". I see this as
> contradiction between the two parts of the sentence and I am not sure why
> not say "multicast address MUST NOT be used".

If somebody wants to use it, they can use it if and only if they are aware of the potential problems and solutions for them.
 
> 10. In section 7.2 I have some questions on the following requirements:
> 
>    o  The RTP/AVPF profile  [RFC4585] - the current text with offer answer
> which in my view is very open can allow it to work with AVT profile.

So, should we remove 4585 from requirements?
 
>    o  The RTCP extensions for SSM sessions with unicast feedback  [RFC5760]
> - The introduction says that it is relevant also for any source multicast,
> so why is this required.

Right, I guess we can remove this, too.
 
>    o  The 'multicast-rtcp'  attribute [I-D.ietf-avt-rtcp-port-for-ssm] - can
> you explain why?

This could be removed, too, although it is much better to be explicit about the RTCP port rather than being implicit.
  
> 11. In section 7.3 maybe rephrase the sentence "Since there is no address
> indiciated in this line, the client needs to retrieve  the Token from the
> address specified in the "c" line."  to  " Since there is no address
> indicated in this line, the client needs to send the token request to the
> address specified in the "c" line."
> 
> There is also a typo in "indiciated"

Sure. Thanks.
-acbegen
 
> 
> 
> Roni Even as individual