Subject: Re: [siprec] [AVTCORE] Request to review a SIPREC draft related toRTP

From: Magnus Westerlund <[email-masked]>
Date: Tue, 2 Aug 2011 17:55:34 +0200

Hi,

Some reply. I will be unable to follow up on any additional comments for
a while as I will be away on vacation.

On 2011-07-28 18:26, Charles Eckel (eckelcu) wrote:
> Hi Magnus,
> 
> Thank you for reviewing and for your comments. Please see inline.
> 
> 
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Magnus Westerlund 
>> Sent: Thursday, July 28, 2011 9:00 AM To: Roni Even Cc:
>> [email-masked] Subject: Re: [siprec] [AVTCORE] Request to review a
>> SIPREC draft related toRTP
>> 
>> Hi,
>> 
>> Here are my review comments:
>> 
>> In general the document is pretty straight forward and
>> understandable. And make for me reasonable recommendations. As can
>> be seen by the comments I think Section 4 is where the most
>> improvements can be made.
>> 
>> 
>> 1. In Section 4.1: The following sentence exist: More
>> specifically, the SRC cannot multiple RTP streams with different
>> SSRCs into a single RTP stream multiplexed by SSRC and/or CSRC.
>> 
>> If I guess that there should be "put multiple RTP streams" I would 
>> really wonder over the "cannot". If the Streams are from the same 
>> call/multimedia session and from the corresponding RTP session
>> between the UAs being recorded, I don't see why you couldn't put
>> all the streams into the same RTP session. They are related, from
>> the same context, and should also have unique SSRCs thus allowing
>> the recording "translator" to create copies and forward them to the
>> SRS. As long as each original stream has its own SSRC (assuming
>> that the actual media isn't mixed in the SRC).
> 
> I am not sure what I was trying to say here. Fixing the grammar is
> easy, but as you point out, doing so results in a false statement. I
> think it is best to remove this sentence completely.

Yes, until you know what you want to say.

> 
>> 
>> 2. Section 4.1: RTCP Receiver Reports generated by the SRS need to
>> be forwarded to the relevant UA.
>> 
>> If the goal is that the UAs shall know of the SRS then this is the 
>> correct approach. If not, then the SRC can in fact suppress the
>> SRS's RTCP messages.
> 
> Okay, but what would you suggest an SRC does it forwards packets from
> UA1 to SRS and UA2, and reports from the SRS indicates loss of
> packets while reports from a UA-B do not.

I was trying to understand what requirements you really have. Yes having
the SRC being a relaying RTP translator is simple and for adaptation and
feedback to work it clearly need to forward the RTCP messages.

After having thought about it I think you are right, that one of the
defining things for using translator setup will be that RTCP for the SRS
will be seen by the UAs. Even if doing media transcoding, the RTCP shall
be forwarded, although in translated form.

If you want another behavior you need to pick a different RTP behavior,
either a mixer (Section 4.2) or separate the RTP session (Section 4.3).

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