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

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

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

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