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

OK, this looks good. It maybe needs some 2119 adjustment, though: e.g., if something we say here is already specified in 3550 with a 2119 keyword, I think we better repeat them without a 2119 keyword but do point to 3550.

-acbegen

> -----Original Message-----
> From: Magnus Westerlund [mailto:[e-mail]]
> Sent: Wednesday, January 19, 2011 10: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-19 16:22:
> > OK, let's not describe a specific method, and the following text:
> >
> > A specification using the Token-based authentication described in this document is REQUIRED to discuss the methods and
> rules for terminating/ending the unicast session.
> >
> > I propose to add the text above to the 5th parag. of section 3 as follows:
> >
> >    Upon successful validation and once the unicast session is
> >    established, all the RTP and RTCP rules specified in [RFC3550] and
> >    other relevant specifications also apply in this session until it is
> >    terminated.  >>>
> >
> 
> Well based on this, I wouldn't come to the conclusion that one can stop
> sending RTCP as server at all unless there has been some explicit
> signalling for termination. this is Probably fine for the general
> introduction. And it do leave the question of termination wide open.
> 
> So, I don't see other than that you have to discuss the termination in
> the draft.
> 
> "The Unicast RTP session created using the port mapping method can be
> explicitly terminated by procedures specified by the using application
> or extension. Any unicast RTP session created using this method may be
> terminated by a timeout procedure. If either client or Retransmission
> Server has not seen any RTCP from any SSRC used by a peer for 5 regular
> transmission intervals, the client or server SHOULD consider the RTP
> session as terminated, and in that case not send any RTP or RTCP traffic
> in the future. The client will have to establish a new unicast session
> if required.
> 
> If no procedure for explicit termination exist, the client MAY stop
> sending RTCP to the Retransmission Server to accomplish session
> termination. The Server SHALL NOT stop sending RTCP until the unicast
> RTP session is terminated. If Token Verification is signaled to be
> allowed also on in the unicast RTP session, i.e. the RTCP messages sent
> from c2 to P4, the client SHOULD prefer to terminate by sending RTCP BYE
> on all SSRCs it has used in this unicast RTP session."
> 
> I think this works fine, and is way better than having no specification
> at all.
> 
> 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]
> ----------------------------------------------------------------------