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

[Roni Even <[e-mail]>]

Hi Ali,
Inline
Roni

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Ali C. Begen (abegen)
> Sent: Monday, December 13, 2010 4:22 PM
> To: Roni Even; [e-mail]
> Subject: Re: [AVT] I-D Action:draft-ietf-avt-ports-for-ucast-mcast-rtp-
> 08.txt - my review
> 
> 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.


Currently it looks like there is inconsistency between the text in the
introduction and section 7.1 specifying offer answer. Once the offer answer
is resolved, the text in section 1 should follow the decision. 
> 


> > 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?

The text is section 4 talk about when to send a new port mapping request, I
think that this is what RFC 6051 talk about, see section 2.1.2

> 
> > 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.


It does not say it currently

> 
> >    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.
> 

This is related to offer answer case, where currently I did not see any text
that prevents it from being used in a regular unicast call.

> >
> > 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.

So what will the server send as a failure in the case when there was no
token and he expected one?

> 
> > 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.

So does it mean that the session level address is applicable only to the
unicast lock, or do we need to say that in this case you take the address
from the unicast block and not the multicast block which will be the typical
behavior for a session level attribute. 
> 
> > 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.
> 
But the first part of the sentence says that only uncast addresses are
allowed.

> > 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?

If we support general offer answer than it should work also for AVP.


> 
> >    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.
> 
> 
> >
> >
> > Roni Even as individual
> _______________________________________________
> Audio/Video Transport Working Group
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt