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

[Magnus Westerlund <[e-mail]>]

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