Re: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 2 Unicast RTP session Termination

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

> >> It might be that you need to tell any using specification to declare how
> >> a unicast session is terminated. But currently this is a gapping whole
> >> in the specification.
> >
> > Actually, we clearly specified how a RAMS session is terminated or when it ends. Repeating all that text here is not needed.
> So, maybe we should simply say the spec using the Token approach needs to discuss the session termination and ending
> sessions.
> 
> No, if that requirement is put on application of this, then I am mostly
> happy.

Just to be clear: are you satisfied if we say " the spec using the Token approach needs to discuss the session termination and ending
Sessions"? If so, do you think we need a 2119 language here?

> >
> >> Based on the below comments it appears that you have decided that RTP
> >> session termination is when all external SSRCs has timed out. But, I
> >> wonder if the servers really are fine with that. If I as a client
> >> continue to send RTCP RR to a server in a RAMS scenario for the unicast
> >> session, then the server is not allowed to terminate the session? I
> >
> > In RAMS, the client will continue sending RRs if and only if the client does retransmissions in that unicast session. If that is
> the case, of course, the server is fine since the session is still active.
> >
> > If the client does not do any further retransmissions after the burst is completed, the RRs will not be sent so the session will
> end after the timeout.
> 
> But, basically you are saying that unless the client keeps the session
> alive, the server will terminate it. Which gives non symmetric behavior
> between the client and the retransmission server.

In practice, in an IPTV system, this is how it works to the best of my knowledge: The client once it completes a retransmission does not BYE the unicast ret session right after the ret packets were received. It will send the periodic RR/XR reports, if a new NACK is sent, the server is ready to go. When the client switches to another channel, it will BYE that unicast session so the session will end for both sides. Yet, some clients may stop sending reports, so the SSRC will time out on the server side.
 
...
> >> Once more my summary of this topic is: This is not defined nor obvious
> >> as this is an issue that has not existed prior to using RTP/RTCP for
> >> creating new RTP sessions.
> >
> > The difference is in creating the RTP session not ending it. Just because a session is dynamically created via RTCP does not
> mean that it must have a different termination method from the regularly established RTP sessions (3550). Once a session is
> up, it is up - no difference from any other regular RTP session. Following the KISS principle here makes sense IMO.
> 
> Well, you have above described a system for retransmissions where there
> is a difference between the client and the server. And where there is
> cases for when the session is considered terminated. That is not the
> same as saying that it isn't terminated. I haven't argued that they must
> be an explicit message. Only that the rules are made clear.
> 
> I am not certain that the restransmission case is well described here.
> And this document is the generalized form of when the unicasat session
> is created. I think describing this general case of termiantion has its
> point. And with the general case I mean:
> 
> If the client stops sending RTCP regularly and the client SSRC times out
> from the unicast RTP session, the server is allowed to terminate/close
> the session. New message for creating it is needed. If the client sends

Agreed.

> BYE in the unicast session, the session can also be considered
> terminated (Needs Token verification or there is a DOS angle).

Also agreed. More on this in an upcoming mail.
 
-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]
> ----------------------------------------------------------------------