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

OK, let's not describe a specific method, and the following text:

A specification using the Token-based authentication described in this document is REQUIRED to discuss the methods and rules for terminating/ending the unicast session.

I propose to add the text above to the 5th parag. of section 3 as follows:

   Upon successful validation and once the unicast session is
   established, all the RTP and RTCP rules specified in [RFC3550] and
   other relevant specifications also apply in this session until it is
   terminated.  >>>


-acbegen

> -----Original Message-----
> From: Magnus Westerlund [mailto:[e-mail]]
> Sent: Wednesday, January 19, 2011 9:21 AM
> To: Ali C. Begen (abegen)
> Cc: IETF AVT WG; [e-mail]
> Subject: Re: WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 2 Unicast RTP session Termination
> 
> Ali C. Begen (abegen) skrev 2011-01-18 14:10:
> >>>> 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?
> >
> 
> I have a preference for it, so that it is clear that it can't be skipped.
> 
> >>>
> >>>> 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.
> 
> Yes, I agree that is the reasonable usage in that scenario. But, I don't
> know if everyone will see it in the same light when implementing. Thus
> resulting in interoperability issues.
> 
> That is why I do wonder if we shouldn't describe this reasonble base
> case, and say that applications may modify or specify additional methods
> of termination.
> 
> 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]
> ----------------------------------------------------------------------