Subject: [MMUSIC] Summary of issues to be discussed in MMUSIC WG

From: Magnus Westerlund <[email-masked]>
Date: Wed, 15 Nov 2017 16:33:32 +0800

WG,

This email is to summarize the issues that has been noted the last 
couple of week related to Simulcast (draft-ietf-mmusic-sdp-simulcast-10) 
and RID (draft-ietf-mmusic-rid-12). These issues and suggested 
resolution will be discussed tomorrow in the MMUSIC WG session. Jonathan 
Lennox, Mo Zanaty and I have discussed this issue off-line here in 
Singapore, and gotten input from Adam Roach and Bo Burman.

1. Flemming found this issue in his review for the write-up. Current 
Simulcast draft says:

In those cases, such "related" formats MUST NOT be defined as having 
their own rid-id listed explicitly in the attribute parameters, since 
they are not strictly simulcast streams of the media source, but rather 
a specific way of generating the RTP stream of a single simulcast stream 
with varying RTP payload type.

Flemming noted this as problematic. We agree that this is problematic, 
and all formats that may be used to fulfil the restriction needs to be 
listed in the PT parameter in the RID attribute. Thus the above text 
should be removed from simulcast. We also noticed that the text in 
MMUSIC RID on this topic could be clearer. Thus, we also suggest that 
MMUSIC RID is updated in Section 4:

OLD: The optional "pt=<fmt-list>" lists one or more PT values that can 
be used in the associated RTP Stream. If the "a=rid" attribute contains 
no "pt", then any of the PT values specified in the corresponding "m=" 
line may be used.

NEW: The optional "pt=<fmt-list>" lists one or more PT values that can 
be used in the associated RTP Stream. If 'pt=<fmt-list>' is present, 
then the RTP sender MUST NOT send any unlisted payload type in the 
associated RTP Stream. If the "a=rid" attribute contains no "pt", then 
any of the PT values specified in the corresponding "m=" line may be used.

2. This issue is closely related to 1, and was found in discussion of 1. 
So when using formats like RED that will use one payload type for itself 
and have one or more payload types that are encapsulated, there are a 
real difference between only including the RED payload type and 
including both the RED payload type and the encapsulated payload types. 
The first would mean only RED payloads will be sent, but can contain 
these encapsulated payloads as indicated by the RED payload types a=fmtp 
line. For the second, one can send either RED or the encapsulated codecs 
stand alone.

The above may not be that clear, even if with the issue 1 text changes 
it should be clearer. Therefore we propose that an example is added for 
RED after Issue 1 text to avoid and confusion on this in the future. We 
have not yet written that text proposal.

3.  This issue is another that was noted in the discussion. Section 4 of 
MMUSIC RID states:

Implementations that use the "a=rid" parameter in SDP and that make use 
of redundancy RTP streams [RFC7656], e.g. RTP RTX [RFC4588] or   FEC 
[RFC5109] [I-D.ietf-payload-flexible-fec-scheme], for any of the source 
RTP streams that have "a=rid" lines remaining after applying the rules 
in Section 6 and its subsections, MUST support and use 
RepairedRtpStreamId SDES item described in [I-D.ietf-avtext-rid] for 
those redundancy RTP streams.

The issue with this text is that it mandates USE of RepairedRtpStreamId. 
However, if draft-ietf-payload-flexible-fec-scheme is used, it can 
perform FEC operations across packets from multiple SSRCs. 
RepairedStreamID can only point to a single RID. Thus, 
RepairedRtpStreamId can't be used in some cases. Nor is it actually 
needed, as the Flex FEC does the reference to the source packets 
internally in each repair packet. Therefore, we propose to change the 
text in MMUSIC RID to allow exceptions:

Implementations that use the "a=rid" parameter in SDP and that make use 
of redundancy RTP streams [RFC7656], e.g. RTP RTX [RFC4588] or FEC 
[RFC5109], for any of the source RTP streams that have "a=rid" lines 
remaining after applying the rules in Section 6 and its subsections, 
MUST support and use RepairedRtpStreamId SDES item described in 
[I-D.ietf-avtext-rid] for those redundancy RTP streams when applicable. 
Use is not applicable for redundancy formats that directly associate RTP 
streams using SSRCs within RTP, an example of such a mechanism is 
[I-D.ietf-payload-flexible-fec-scheme] or other cases that 
RepairedRtpSteamId can't support.

4.  Another issue related to redundancy streams is that if one has 
dynamic mapping of RID to SSRCs, i.e. a given RID may be fulfilled by 
different SSRCs at different times. The change of SSRC for a RID value 
may create an issue for any redundancy stream with correct association. 
This is due to the indirection that is created by the chain RepairStream 
(SSRC-R) has RepairedStreamId=A that points to RID=A that is bound first 
to SSRC-A, but then changed to SSRC-B. Thus, at the time of change of 
the SSRC, it is possible that the wrong source flow is referenced. Due 
to racing update of references. This type of issue can't arise in 
redundancy solutions that directly reference its source RTP packet(s) 
using SSRC and sequence number.

Proposal is that MMUSIC RID needs to note this issue and be clear that 
redundancy mechanism that directly indicate the SSRC and sequence of the 
source packets will avoid this issue. The text has not yet been written.

5. The Simulcast draft authors has noted that the examples in simulcast 
have some short comings in using RID restrictions, and show examples 
with redundancy and related streams. The authors intend to propose some 
additional examples to better cover the space of possibilities. There 
are already more complex examples in draft-ietf-rtcweb-sdp, maybe 
possible to borrow from there and focus them on simulcast.

6. Jonathan Lennox asked about the below paragraph in Section 5.1 of 
simulcast:

It is possible to use source-specific signaling [RFC5576] with 
"a=simulcast", but it is only in certain cases possible to learn from 
that signaling which SSRC will belong to a particular simulcast stream.

So, in general a=SSRC and a=rid are independent from each other. If the 
a=ssrc actually include a=fmtp line with a PT that is in a RID lilne it 
would be possible to link them currently. However, the only RTP Payload 
format that has source specific parameters are H.265. Our conclusion is 
that this text is not really necessary in Simulcast, thus we propose to 
remove it.

There is a question if this properties need any mention in MMUSIC RID or 
can be ignored?

7. In our offline discussion we also noted there are a feature parity 
difference when it comes to possibility to perform binding information 
to SSRCs in SDP Signalling. So the MID in an media description is bound 
to the SSRC due the presence of the a=SSRC attribute within the MID 
labelled. However, the corresponding possibility is not defined for RID. 
So, it is not strictly need as the RTP header extension and RTCP SDES 
item for RID ensures that we have a working solution. The short coming 
is the possibility to do early binding of RID to SSRC in cases where RID 
will be statically bound to the SSRC. Note that RID in a=ssrc is not 
sufficient as a general solution, as it can't handle the dynamic RID 
mapping cases as well as the signalling race condition that exist when 
Answers include new SSRCs. So defining how RID is included in a=ssrc is 
an optimization for a sub-set of the possible usages.

As we understand it adding this would mean a new section in MMUSIC RID 
defining a new source specific parameter for RID, how its relate to any 
inband updates of RID, and a IANA section entry to add it to the 
registry. So this is likely in total 1 page of text. Or as an 
alternative way to implement would be to have this in its own document. 
But, then the support of this feature needs to be specified separately 
or be truly optional.

Thus, we really like to discuss this. The people discussing it so far 
has been very split about this.

That was all the issues, so please consider them and we will go through 

and discuss them tomorrow in MMUSIC WG session at 13:30 here in Singapore.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Media Technologies, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------