Re: [AVT] draft-ietf-avt-ports-for-ucast-mcast-rtp-04: Review Comments [csp]

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

> -----Original Message-----
> From: Colin Perkins [mailto:[e-mail]]
> Sent: Thursday, December 02, 2010 4:23 PM
> To: Ali C. Begen (abegen)
> Cc: Magnus Westerlund; IETF AVT WG
> Subject: Re: [AVT] draft-ietf-avt-ports-for-ucast-mcast-rtp-04: Review Comments [csp]
> 
> Most of my comments have been covered in the discussion. Just some minor points inline.
> 
> Colin
> 
> 
> On 2 Dec 2010, at 17:47, Ali C. Begen (abegen) wrote:
> >>>> - Reusing a unicast session for different multimedia session, which I think implies having them share the FTap.
> >>>
> >>> This is not a problematic case, either.
> >>
> >> I am not agreeing fully. There need to be some consideration here for it. Because you need to know which session the
> incomming UDP data relates to. For example if one has an ongoing RAMS burst for one channel and then sends a NACK
> request or another RAMS request and request to use the same unicast session it is not obvious that the data is distinguishable
> from one channel to the other. Thus clearly consideration should be done here. like alternating between two different unicast
> sessions with RAMS requests to avoid overlap.
> >
> > Such considerations are discussed in the RAMS draft. If the (feedback) port on the server is shared among multiple RTP
> sessions, then the client has to know the SSRC of the media stream(s) it wants to acquire. If SSRCs are not available in the
> SDP, that port cannot be shared.
> >
> > I don't think that discussion belongs in here.
> 
> I suspect this can happen with services other than RAMS, so the general issue should be highlighted.

Probably yes. Correct if I am wrong but this does not relate to the Token AFAICT. Here we are discussing the PT port which is used to acquire a Token from, whereas the concern Magnus has raised is related to sharing the feedback target port among multiple RTP sessions (which is the a=rtcp line in the multicast session).

Maybe, this belongs to 5760?
 
> >>>> - Reuse over time of the port for different services. (which is the one I think Colin was going after).
> >>>
> >>> OK, this is interesting. Lets discuss it. Remember that the PT port (server side) is advertised in the SDP at media or
> session level.
> >>>
> >>> If advertised at the media level, PT is the port where the clients (who plan to start that particular unicast session with the
> server) send their token request message. This is illustrated in the SDP example in the draft.
> >>>
> >>> If advertised at the session level, PT will be the port for obtaining a Token for any unicast session that is run between the
> server(s) and clients. Recall that existence of the 'portmapping-req' attribute indicates that a Token is required for all unicast
> sessions. Note that different unicast session may have different server addresses, the attribute above only indicates the
> common port for them.
> >>
> >> Yes, I agree that all the tools are available for getting things to work. However, there needs text to point out when a client
> should use new local ports to create new unicast sessions to a server. This
> >
> > The local port management is a client issue. The client follows the conventional rules of using the same port for different
> RTP sessions. If there is a risk that the traffic will still leak, it has naturally to use a different local port.
> >
> >> becomes more or less important dependent on how much co-locating is
> >> happening on the server side when it comes to the RTCP feedback port.
> >> Preferably none.
> >
> > Server ports are declarative and it does not matter what the client does on its own side.
> >
> >> I also feel that you are missing the issue with time. If a service exist for 2 hours on friday between 18-20. Then another
> service is started at 21.00 on friday and happens to reuse the port numbers, but is actually another service instance. Then the
> token from service one may or may not still be valid depending if service 1 and 2 share token generator and key or not.
> >
> > It is simple. If it is a new service and the server wants the client to get a new token, it will reject the current one. Or, the
> server could have issued the token in such a way that it would  expire by 6pm.
> 
> Sure, but the draft needs to say this.

-05 (not uploaded yet) has this text.

Thanks, acbegen.