Re: [AVTCORE] Mandatory nature of RTCP

[Paul Kyzivat <[e-mail]>]

On 5/10/2011 5:01 AM, Magnus Westerlund wrote:
> On 2011-05-09 15:15, Paul Kyzivat wrote:
>> 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.)
>
> Agree that you will need to be able to record it.
>
>> 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?
>
> 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.

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

> 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.
>
>> 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.
>>
>
> We should do our best to provide feedback on such questions.
>
> 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]
> ----------------------------------------------------------------------
>
>