Subject: [MMUSIC] Duplication semantics drafts

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 10 Oct 2011 11:17:20 -0700

I revised the two drafts per the feedback in Quebec.

If there are further comments, we would like to hear about them. As of now, there are no open issues from our standpoint except possibly defining a new RTCP XR report, which can be done later. Thus, we would like these two drafts to be considered and adopted by the MMUSIC wg.

https://datatracker.ietf.org/doc/draft-begen-mmusic-redundancy-grouping/
https://datatracker.ietf.org/doc/draft-begen-mmusic-temporal-interleaving/ 

CC'ing AVT(core) since the topic is relevant but please post your comments to mmusic where the drafts belong to.

-acbegen

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 11 Oct 2011 11:41:38 +0200

On 2011-10-10 20:17, Ali C. Begen (abegen) wrote:
> If there are further comments, we would like to hear about them. As
> of now, there are no open issues from our standpoint except possibly
> defining a new RTCP XR report, which can be done later. Thus, we
> would like these two drafts to be considered and adopted by the
> MMUSIC wg.
> 
> CC'ing AVT(core) since the topic is relevant but please post your
> comments to mmusic where the drafts belong to.
> 

Hi,

(as individual)

I have looked at the redundancy-grouping draft and still think it fails
as RTP specifications for how duplication should be done in RTP, either
using SSRC multiplexing with two different SSRCs in the same RTP session
or for the alternative how having two different RTP sessions. This first
appears to be sufficiently specified, where my only comment is the
dependency on signalling to determine that this grouping is in place. I
do propose that an RTP/RTCP based complement is derived. I would
personally suggest that my own proposal for a new SDES item SRCNAME is
used but that should clearly be discussed.

For the case where multiple RTP sessions are used, it is still not clear
how a receiver determine which SSRC in each RTP session that are
related. And I would like to point out that CNAME is not sufficient.

I still think we should consider splitting this into one AVTCORE
document discussing the RTP aspects of duplication, and another MMUSIC
document defining the grouping semantics.

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: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 11 Oct 2011 03:46:24 -0700

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Tuesday, October 11, 2011 5:42 AM
> To: Ali C. Begen (abegen)
> Cc: mmusic (E-mail); [email-masked]
> Subject: Re: [AVTCORE] Duplication semantics drafts
> 

Right, the ssrc muxing case is straightforward and easy to implement. Everything works fine without the need for defining new stuff except the grouping semantics. I am not sure why you think there is a problem in the signaling.

If duplication will be done across sessions (your second case), then it gets complicated. And as I understand your claim is regular CNAME falls short to define this relation. Is that correct? And your proposal is SRCNAME, right?
 
> document defining the grouping semantics.

This sounds like a good plan to me.
-acbegen

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 11 Oct 2011 14:31:01 +0200

On 2011-10-11 12:46, Ali C. Begen (abegen) wrote:
>> (as Individual)

> Right, the ssrc muxing case is straightforward and easy to implement.
> Everything works fine without the need for defining new stuff except
> the grouping semantics. I am not sure why you think there is a problem
>  in the signaling.

Yes, it works as long as the application can accept to rely on the
signalling protocol. However, if one would like to to this in session
where one has a dynamic set of participants and it is large enough that
it isn't feasible to updated the signalling for each new participant
that joins the session and is a potential sender. Then it would be good
to have something that works on the RTP/RTCP level.

> 
> If duplication will be done across sessions (your second case), then
it gets complicated. And as I understand your claim is regular CNAME
falls short to define this relation. Is that correct? And your proposal
is SRCNAME, right?

Yes, the show case when CNAME falls short is for any case where an
end-point will have multiple media flows in the same session. So in this
case you have 2 SSRC in one session carrying the source (original)
stream and 2 SSRCs in the second carrying the duplicated data. As the
two source SSRC come from the same synchronization context they do carry
the same CNAME. Thus a receiver will have two sets of SSRCs that both
carry the same CNAME. Thus that can't be used to bind the correct set of
SSRCs together. Using the sequence numbers are prone to errors and can
easily fail. I don't like overriding the SSRC randomization and require
the duplicated streams to have the same SSRC as the original. It also
creates separate solutions for the two cases.

I therefore prefer to see a solution that can handle both cases and
targeted at this particular problem.

There will be a dedicated version of the SRCNAME draft submitted before
the deadline.

> This sounds like a good plan to me.

Good

Magnus Westerlund