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-17 14:23:
> 
> 
>> -----Original Message-----
>> From: Magnus Westerlund [mailto:[e-mail]]
>> Sent: Monday, January 17, 2011 5:54 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-14 19:33:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Magnus Westerlund [mailto:[e-mail]]
>>>> Sent: Friday, January 14, 2011 5:34 PM
>>>> To: IETF AVT WG; [e-mail]
>>>> Subject: WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 2 Unicast RTP session Termination
>>>>
>>>> Hi,
>>>>
>>>> The second issue is getting back to the unicast RTP session termination.
>>>>
>>>> Having re-read this document it is very clear on when an Unicast RTP
>>>> session is created. Section 3.2, bullet 4 makes this clear. However,
>>>> there is no discussion on what the criterias are for when the session
>>>> can be considered terminated.
>>>
>>> Of course, this draft is about how to achieve port mapping and establish/control a unicast session. For termination, the
>> 3550 rules apply as usual. It is because it is the unicast session that is the important here. This draft cannot say anything at all
>> how the sessions established by using this draft should be terminated.
>>
>> The issue, I have is that you say RFC 3550 rules. I don't see how RFC
>> 3550 applies to RTP session termination. Because that happening through
>> external mechanism. RFC 3550 discusses when to consider an SSRC timed
>> out. But that is not the same as terminating the session.
> 
> As a good citizen, the client can send a BYE to end the unicast session. It is not just when SSRC times out.
Sure, but it is the criteria that is the question.

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

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

> 
>> think they will consider the session terminated when the burst is
>> completed.
> 
> Not necessarily. RAMS server is not just a burst server,  it is a retransmission server, too.



>  
>> For NACK I think one can take two approaches. One more aggressive, but
>> both appear to work.
>>
>> A. Lazy, server and client consider the session terminated when the far
>> side SSRC times out completely. This will not happen as long as both
>> end-points sees each other RTCP RR even if no data traffic is present.
>>
>> B. More aggressive: The RTP session is timed out when no RTP data
>> traffic has been sent in the RTP session for 2 or 5 regular RTCP
>> reporting intervals.
>>
>> 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
BYE in the unicast session, the session can also be considered
terminated (Needs Token verification or there is a DOS angle).

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