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: 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.
 
> This has previously been discussed in my review comments for 08 version
> but we didn't conclude on the discussion due to me being unable to
> respond then.
> 
> To follow up on one thing. Yes, if we had an architectural and usage
> requirements document for unicast sessions created in relation to
> multicast then that document would make sense to discuss this issue. As
> I see it now, that will not be created. This is the usage independent
> component so I think it makes sense to discuss it here, even if not
> perfectly fit. But I like to point out that creation and some other
> treatment things are discussed. So lets include how it is terminated.

I disagree. It is up to the unicast session how long it lasts or when it ends. E.g., if it is a retransmission session, it could be used for one rtx and then may never get used, eventually it will time out. Or, the client keeps asking for rtx and it will stay open. It has nothing to do with the token or port mapping.
 
> The reason i think it is important to discuss is that the end-points
> need to know when the other side will consider it terminated and create
> a new session in its eyes rather than continue using the current one.

Server does not need to know anything other than usual RTP rules. When the session times out, it is done. 

> Also, the other signaling mechanisms do have some way of terminating.
> SIP Dialog termination kills the media RTP sessions, they can also
> become terminated in SDP by re-invites. RTSP has its Teardown method.
> SAP relies on SDP t= attribute to tell when the session is valid.
> 
> But for this solution it is unclear. That becomes a bit more problematic
> as this is a protocol that is intended for highly dynamic cases, like
> RAMS. So I would really like to know what the criteria are. Otherwise we
> can have clients sending RTCP to a server for a session it considers
> closed. It also become a point of resource handling. One should clean up
> what one create.
> 
> I am fine making this timeout based, like 5 regular report interval (or
> TRR-int) without RTP activity. But I think we need to consider what it
> means if one peer sends BYE. Can you time out earlier then?

If there is a BYE in the unicast, of course, it will end without waiting for the 5xinterval timeout duration. I don't see why we need to say something about this on top of what is already in the text.

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