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

[Colin Perkins <[e-mail]>]

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.

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

>> In this case it would be best if the token generation for service one is set so that the token will not last beyond the service it intends to service.
> 
> Indeed. Added this.
> 
>> There is also a security perspective, if one expect clients to be of a non all ways on kind, then a particular IP address may first used by host A and later by host B. Thus potentially allowing A to DoS host B unless the token is short lived. But I think I brought this up otherwise.
> 
> Indeed and I think we covered this sufficiently.
> 
> Thanks.
> -acbegen
> 
>> Cheers
>> 
>> Magnus Westerlund
>> 
>> ----------------------------------------------------------------------
>> Multimedia Technologies, Ericsson Research EAB/TVM
>> ----------------------------------------------------------------------
>> Ericsson AB                | Phone  [phone]
>> Färögatan 6                | Mobile [phone]
>> SE-164 80 Stockholm, Sweden| mailto: [e-mail]
>> ----------------------------------------------------------------------
> _______________________________________________
> Audio/Video Transport Working Group
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt



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