Re: [MMUSIC] [AVTCORE] Comments on draft-begen-mmusic-redundancy-grouping-01

[Magnus Westerlund <[e-mail]>]

On 2011-07-25 10:07, Ali C. Begen (abegen) wrote:

> Ok, lets discuss it. My current proposal is to use different SSRCs.
PTs turn out to be different since I designate these streams in the same
m line. Unless I am mistakes, you cannot put two different streams with
the same PT in a single m line. Remember, we do not use PT to demux the
RTP streams, we use SSRC for that purpose.

No, that is wrong. The PT is completely unrelated to to which SSRC that
use them. The set of configured PTs can be used by any of the sources
that transmit in the direction for which they are configured. I do
include the direction because of the O/A aspects of having different
configurations for receving in different directions.


>> If SSRC A has a duplciation in SSRC C and SSRC B has a duplication
>> in SSRC D and both A and B comes from the same end-point and have a
>> common synchronization context, then all of A-D needs to have the
>> same CNAME.
> 
> Well, above implies that all streams are coming from the same source
> and yes, they will end up having the same CNAME since you required A
> will be synched with B. But, still I think this is workable without
> any additional mechanism. A and C would be in the same m line and B
> and D would be in the same (but separate from the first) m line. That
> would give me what I want.

I am not agreeing that you would put A and B in different sessions. This
doesn't make sense if you actually like to provide two related media
streams of the same type, for example two cameras covering different
parts of a telepresence room, or two different camera angels in a movie.

What you are suggesting seems to be a hack to just get around the issue
that if you have streams that are some form of alternatives of the
actual same original source then you need to identify, like the SRCNAME
proposal.


> 
>> And I get the impression that you are using a payload type based 
>> association scheme here. And I think that is a bad idea. For
>> example it can't support particular many streams. It also looks
>> semantically wrong, as if Stream A uses PT 96, then SSRC C should
>> use PT 96 also for the corresponding packet duplicates. And if A
>> switches from one PT to another the other stream needs to follow.
> 
> No, I am not suggesting to use PT for demuxing. I use SSRC for that
> purpose. As I asked above, if I can use the same PT for multiple
> streams in the same m line, then I will. But I don’t think I can.
> 

Yes, understand this is a different type of missunderstanding of RTP.


>> 
>> Ok, but you will need to make clear on how one should set the RTCP
>> SR timestamp NTP mapping to be clear. And what that implies for the
>> RTCP jitter calculation.
> 
> The fact that you are using delayed duplication or spatial diversity
> means that you will likely introduce some jitter into your stream
> unless the node merging the streams smooths out that jitter in the
> first place. There is not nothing special for the ultimate endpoint
> for preparing the reports, it just does  what it is supposed to do.
> In most systems, the ultimate RTP receivers might not be even aware
> of the fact that they are receiving a stream merged from two
> identical streams. That is a design feature.
> 

When you talk about jitter here, you are talking about small transport
level jitter, rather than jitter on the level of frame intervals.

Sure, if you have a translator that merge these, then you clearly should
be hidden to the end-point behind translator.

>>>> 7. Thus I think the signalling aspects of this is the minor
>>>> part. Although there clearly are some aspects of this needing
>>>> discussion. For example clearer offer/answer rules for handling
>>>> these.
>>> 
>>> We have some text around O/A stuff. But frankly, I don’t see any
>>> use case where duplication will be used in a unicast application.
>>> I mean if redundancy is needed, one should use FEC instead for
>>> unicast transport. Duplication is a nice use case for multicast
>>> transport where the bw overhead is easier to justify and the
>>> implementation is easier. And one would naturally implement this
>>> spec in networks where he already knows that the network elements
>>> support this spec. So, maybe we should remove the whole O/A text
>>> anyway and write that this will only be used declaratively.
>> 
>> Then, I think we should slap an application statement to the
>> beginning of the draft to ensure that it may only be used in
>> multicast. For
> 
> Wfm.
> 
>> example b=TIAS was only intended to used in declarative SDPs, but
>> it has become common in O/A, but it doesn't have clear rules.
>> 
>> So I think it imporant that one don't assume to much. Yes, it might
>> not be the best idea for unicast, but that is not going to prevent
>> it from being used.
> 
> If one really uses this for unicast, let them deal with all the
> potential O/A problems that might surface. It is more like they will
> deserve it :)
> 

:-)

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