Re: [AVTCORE] Mandatory nature of RTCP

["Elwell, John" <[e-mail]>]

Thanks, Magnus and Albrecht, for your responses to my questions, and thanks, Paul, for these supplementary questions of relevance. Answers to these from RTP experts would be appreciated. I suspect the answers depend on the RTP role the SIPREC Session Recording Client takes, in mediating RTP between the Communication Session being recorded and the Recording Session from the Session Recording Client to the Session Recording Server.

In addition, we anticipate having a short I-D in the coming weeks on RTP considerations for SIPREC, and we will socialize that on the AVTCORE list to try to get the engagement of RTP experts.

John


> -----Original Message-----
> From: Paul Kyzivat [mailto:[e-mail]] 
> Sent: 09 May 2011 14:15
> To: Magnus Westerlund
> Cc: Schwarz, Albrecht (Albrecht); Elwell, John; [e-mail]
> Subject: Re: [AVTCORE] Mandatory nature of RTCP
> 
> Magnus,
> 
> IMO the first question in this area that comes up for siprec is:
> 
> 1) must we be able to record the RTP of a call when that RTP
>     doesn't have RTCP?
> 
>     I think the answer is clearly yes.
>     There seems to be enough wiggle room in 3550 that we can't
>     argue that the call is invalid and we don't need to record it.
>     (And in general we should try to record calls even if they
>     *are* invalid.)
> 
> The next question that comes up is:
> 
> 2) when recording a call with a media stream that doesn't have
>     RTCP, must the siprec SRC synthesize RTCP in order that it will be
>     available to the receiver? Or can we leave it to the siprec SRS
>     to deal with it?
> 
> I think we need AVTxxx input into siprec on such issues.
> Decisions on these things can potentially have significant 
> architectural 
> impact on the way recording is done.
> 
> 	Thanks,
> 	Paul
> 
> On 5/9/2011 8:29 AM, Magnus Westerlund wrote:
> > On 2011-05-09 13:20, Schwarz, Albrecht (Albrecht) wrote:
> >> RTCP is NOT MANDATORY according RFC 3550.
> >> I fail to see any normative statement, too.
> >> I could also imagine RTP use cases which do not need at all RTCP.
> >
> > I think I agree that RTCP is not mandated directly. 
> However, in reality
> > it is required. Only in a few very limited usages can one 
> skip to use RTCP.
> >
> > If one uses UDP as underlying transport then RTCP is needed 
> to fulfill
> > the congestion control requirements in RFC 3550 and the profiles
> > (RFC3551). Both has a SHOULD requirement and that SHOULD 
> exist to allow
> > cases where you have dedicated resource.
> >
> > Then we have all the binding information that RTCP 
> provides, like time
> > synchronization (RTCP SR), which to be synchronized (SDES 
> CNAME). Some
> > single media applications can live without this, but any 
> multi-media do
> > need some of this.
> >
> > There is a reason why RTP doesn't contain so much hard 
> requirements. RTP
> > is a toolbox and applications are suppsed to pick the 
> pieces it needs.
> > And general RTCP is needed in most cases. So I would 
> recommend any one
> > deciding on RTP/RTCP should start with describing what application
> > requirements they have. Then pick the RTP parts.
> >
> > But I will guess that SIPREC is likely to need RTCP. But 
> please do your
> > analysis of what you need.
> >
> > 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]
> > 
> ----------------------------------------------------------------------
> >
> >
>