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

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

...
> > 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?
> 
> I think it belongs in the port mapping draft. Because without it what we
> are discussing here is not really possible. The port mapping allows one
> to do late binding between a receiver local port and a specific feedback
> target address that relates to a specific SSM session. If there is some
> overloading ongoing for the FT Adress plus port then re-using the
> receivers local port creates an issue of separation. This would not
> likely happen if one had to pre-establish the unicast sessions. It
> becomes the receivers choice to re-use a specific local port, and that
> is really what the discussion here is about.

OK, not about the server side - which I wanted to convey.
 
> From my point of view a receiver really should use different local ports
> when submitting RTCP requests related to different SSM sessions. That
> way you avoid the whole mess, even if there is some overloading happening.

Yes, clearly a client cannot keep using the same local (receive) port for different unicast (retransmission, RAMS, etc.) sessions since the unless the source packets are distinct in their media source SSRCs, there could be leakage when switching from one session to another. OTOH, the client does not necessarily need a totally different port for every session, either.

I guess what implementations will do is that they will select N local ports when the system boots up and will rotate the port as they switch from one session to another. N should be chosen such that the probability of still receiving RTP/RTCP packets from an old session is almost zero when the client starts using the same port for a new session. N is application and usage dependent. For typical IPTV applications, a value of 10 or even 5 should be sufficient to satisfy the requirement above.

Is something along the lines above what you were looking for?

Cheers, acbegen.