Subject: [AVTCORE] Mandatory nature of RTCP

From: "Elwell, John" <[email-masked]>
Date: Mon, 9 May 2011 12:34:16 +0200

I am sure I have heard many times experts say that RTCP is a mandatory part of RTP. However, some people looking into RTP as part of work in the SIPREC WG have failed to find convincing normative statements in RFC 3550. Any pointers would be appreciated.

Thanks,

John

---

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Mon, 9 May 2011 13:20:14 +0200

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

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Elwell, John
> Sent: Montag, 9. Mai 2011 12:34
> To: [email-masked]
> Cc: Paul Kyzivat (pkyzivat)
> Subject: [AVTCORE] Mandatory nature of RTCP
> 
> I am sure I have heard many times experts say that RTCP is a 
> mandatory part of RTP. However, some people looking into RTP 
> as part of work in the SIPREC WG have failed to find 
> convincing normative statements in RFC 3550. Any pointers 
> would be appreciated.
> 
> Thanks,
> 
> John
> 
>  
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 9 May 2011 14:29:29 +0200

> 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  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Mon, 9 May 2011 14:40:02 +0200

Fully agree to that view, Magnus!

We may also consider the scenarios of "unidirectional RTP sessions", e.g., just an RTP media flow from RTP endsystem A to RTP endsystem B, but not vice versa.
There might be then an associated RTCP control flow, - a bidirectional RTCP or again a unidirectional RTCP flow (e.g. just from B to A, but not vice versa).
Etc

> From: Magnus Westerlund [mailto:[email-masked]] 
> Sent: Montag, 9. Mai 2011 14:29
> To: Schwarz, Albrecht (Albrecht)
> Cc: Elwell, John; [email-masked]; Paul Kyzivat (pkyzivat)
> Subject: Re: [AVTCORE] Mandatory nature of 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
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 09 May 2011 09:15:17 -0400

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

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 10 May 2011 08:10:52 +0200

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

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 09 May 2011 14:15
> To: Magnus Westerlund
> Cc: Schwarz, Albrecht (Albrecht); Elwell, John; [email-masked]
> to fulfill
> requirements. RTP
> recommend any one

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 10 May 2011 11:01:56 +0200

>     (And in general we should try to record calls even if they

Agree that you will need to be able to record it.

>     available to the receiver? Or can we leave it to the siprec SRS

Looking at the architecture pictures in Section 3.1 in
http://tools.ietf.org/html/draft-ietf-siprec-architecture-02

I get the impression that the RTP session between the SRC and the SRS
appears to be a separate RTP session from the one that is being
recorded. In those case I think it is important that the SRC monitors
the media flow to the SRS to ensure that it is being delivered
successfully and with sufficient quality without causing any persistent
congestion.

Thus I think a requirement on using RTCP between the SRC and SRS appears
necessary.

In that context you will have to answer the question what to do if the
SRC sees persistent congestion on the path to the SRS. Can it do some
media manipulation to reduce bit-rate, for example by repacketizing
audion into multiple frames per packet to reduce packet overhead. At the
minimal it may have to stop sending the recording stream if there are
insufficient resources.

> impact on the way recording is done.

We should do our best to provide feedback on such questions.

Cheers

Magnus Westerlund

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 12 May 2011 08:22:07 -0400

> Thus I think a requirement on using RTCP between the SRC and SRS appears

This will need to be discussed/investigated further.
We are discussing multiple models for how the SRC manages the RTP.
For some of them the above may be feasible, and for others, not.

There are others in siprec with a much better handle on the RTP side of 
things than I have. We need to arrange the right level of interaction 
among the right people.

	Thanks,
	Paul