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

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.

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
think they will consider the session terminated when the burst is
completed.

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.


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