Subject: [MMUSIC] Simulcast draft review needed

From: Flemming Andreasen <[email-masked]>
Date: Thu, 22 Sep 2016 19:44:48 -0400

Thank you to all that reviewed the -rid draft so far.

Please note that we also have the simulcast draft

      https://www.ietf.org/id/draft-ietf-mmusic-sdp-simulcast-05.txt

to go along with this, and we really need some reviews of that one too. 
If you have some time to review it, please do so and send your comments 
to the list (incl. "looks good").

Thanks

-- Flemming

---

From: Ron Even <[email-masked]>
Date: Fri, 23 Sep 2016 07:43:33 +0300

Hi,
I sent my review to the list and had no feedback.
Roni

On Thursday, September 22, 2016, Flemming Andreasen <[email-masked]>
wrote:

> to go along with this, and we really need some reviews of that one too. If
> you have some time to review it, please do so and send your comments to the
> list (incl. "looks good").
>
> Thanks
>
> -- Flemming
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Bo Burman <[email-masked]>
Date: Fri, 23 Sep 2016 14:59:02 +0000

Hi Roni,

You did indeed send such review, thank you. My apologies, but that somehow fell off my radar until now.

I include your comments from July 24:

> This solution is partial since it does not support all simulcast use

> cases. The document in section 6.4 talk about declarative usage and point to

> section 8 about limitation of supporting this case. In section 8 the

> document says that the solution does not support multiple multicast groups

> and as such claiming support for declarative usage is very limited or does

> not exist.

So, you suggest that there is no point even mentioning declarative usage? If that helps, I have no problem to remove any mentioning of declarative usage.

> The question is why does the document support the simulcast attribute only

> on the media level and does not define usage for the session level to allow

> multiple multicast groups each as a separate RTP session.

This was an early design choice, which in my view is mainly related to two things:

1)      RFC 7656 states that an m= block in SDP (an m= line and all lines up to but not including the next m= line, or the end of the SDP) generally corresponds to a (single) media source

2)      the definition of simulcast to mean sending differently encoded representations of a media source (thus restricted to a single m= block)

So, the reason is simply that use of multicast groups does not fit well with the above. No immediate need for use of simulcast with multicast was expressed, so the design decision was to basically leave it out of scope for this draft. We could probably make that even more clear.

I believe it should be possible to define multicast usage of simulcast as a separate document (updating draft-ietf-mmusic-sdp-simulcast) at some later point in time. It seems very straightforward to build a simulcast for multicast on explicitly allowing a=simulcast on session level in SDP. Such update document would have to relax the guideline to restrict a media source to an m= block, probably with a clear motivation and explanation that this is specific for multicast (and other RTP usages where use of multiple different transports is the foremost concern). Without thinking this through entirely, I also believe it would be necessary to make an additional restriction to keep the simulcast stream-identifying RID values unique across the SDP (instead of being localized to an m= line), but it would probably be sufficient to make it work. That RID uniqueness requirement should hardly be any problem to meet in practice, since the possible RID value space is much larger than e.g. RTP payload types.

Cheers,
Bo (as individual)

From: mmusic [mailto:[email-masked]] On Behalf Of Ron Even
Sent: den 23 september 2016 06:44
To: Flemming Andreasen <[email-masked]>
Cc: mmusic <[email-masked]>
Subject: Re: [MMUSIC] Simulcast draft review needed

Hi,

On Thursday, September 22, 2016, Flemming Andreasen <[email-masked]<mailto:[email-masked]>> wrote:
Thank you to all that reviewed the -rid draft so far.

to go along with this, and we really need some reviews of that one too. If you have some time to review it, please do so and send your comments to the list (incl. "looks good").

Thanks

-- Flemming

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Ron Even <[email-masked]>
Date: Sat, 24 Sep 2016 09:06:07 +0300

Hi Bo,
My suggestion is that multicast is very important case for simulcast usage
and it must be supported, in the initial document. My reading of the
current text was that the dicument provide limited support for multicast
and that is wrong approach
Roni

On Friday, September 23, 2016, Bo Burman <[email-masked]> wrote:

> So, you suggest that there is no point even mentioning declarative usage?
> If that helps, I have no problem to remove any mentioning of declarative
> usage.
>
>
>
> 1)      RFC 7656 states that an m= block in SDP (an m= line and all lines
> up to but not including the next m= line, or the end of the SDP) generally
> corresponds to a (single) media source
>
> 2)      the definition of simulcast to mean sending differently encoded
> representations of a media source (thus restricted to a single m= block)
>
>
>
> So, the reason is simply that use of multicast groups does not fit well
> with the above. No immediate need for use of simulcast with multicast was
> expressed, so the design decision was to basically leave it out of scope
> for this draft. We could probably make that even more clear.
>
>
>
> I believe it should be possible to define multicast usage of simulcast as
> a separate document (updating draft-ietf-mmusic-sdp-simulcast) at some
> later point in time. It seems very straightforward to build a simulcast for
> multicast on explicitly allowing a=simulcast on session level in SDP. Such
> update document would have to relax the guideline to restrict a media
> source to an m= block, probably with a clear motivation and explanation
> that this is specific for multicast (and other RTP usages where use of
> multiple different transports is the foremost concern). Without thinking
> this through entirely, I also believe it would be necessary to make an
> additional restriction to keep the simulcast stream-identifying RID values
> unique across the SDP (instead of being localized to an m= line), but it
> would probably be sufficient to make it work. That RID uniqueness
> requirement should hardly be any problem to meet in practice, since the
> possible RID value space is much larger than e.g. RTP payload types.
>
>
>
> Cheers,
>
> Bo (as individual)
>
>
>
> *From:* mmusic [mailto:[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>] *On Behalf Of *Ron
> Even
> *Sent:* den 23 september 2016 06:44
> *To:* Flemming Andreasen <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
> *Cc:* mmusic <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
> *Subject:* Re: [MMUSIC] Simulcast draft review needed
>
>
>
> Hi,
>
> On Thursday, September 22, 2016, Flemming Andreasen <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 26 Sep 2016 09:00:52 +0200

Den 2016-09-24 kl. 08:06, skrev Ron Even:
> Hi Bo,
> My suggestion is that multicast is very important case for simulcast
> usage and it must be supported, in the initial document. My reading of
> the current text was that the dicument provide limited support for
> multicast and that is wrong approach
> Roni

Roni,

I would have been fine with including multicast support and declarative 
usages, if we known there was actually an interest in multicast earlier. 
Then we could have ensured that we had a solution in place for it. 
However, that has not been expressed and the individual version that was 
adopted as WG item 
(https://www.ietf.org/archive/id/draft-burman-mmusic-sdp-simulcast-00.txt) 
says:

    Multicast:  Multiple RTP sessions will be required to enable
       combining simulcast with multicast.  Different simulcast versions
       have to be separated to different multicast groups to allow a
       multicast receiver to pick the version it wants, rather than
       receive all of them.  In this case, the only reasonable
       implementation is to use different RTP sessions for each multicast
       group so that reporting and other RTCP functions operate as
       intended.  The proposed solution can be extended to support this
       functionality with an optional mid: prefix before the RTP payload
       types of a simulcast version, to describe simulcast across
       multiple media descriptions.

Note the "extended to support this functionality".

Thus, this was adopted as a work item multicast support was a future 
extension. The general declarative usage will need to be removed from 
the simulcast draft in the next version due to that RID is missing that 
support. The removal of declarative usage was discussed twice I think as 
a result of my feedback on RID. The end result was that as I didn't have 
the time to propose text, and Adam didn't feel he had the expertise it 
didn't get written up.

The only way forward with simulcast in multicast and declarative use is 
to start working on extension specifications for both the RID and 
simulcast documents. There is no way we can shoehorn it in at this stage.

Cheers

Magnus

>
> On Friday, September 23, 2016, Bo Burman <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi Roni,____
>
>     __ __
>
>     You did indeed send such review, thank you. My apologies, but that
>     somehow fell off my radar until now.____
>
>     __ __
>
>     I include your comments from July 24:____
>
>     __ __
>
>     > This solution is partial since it does not support all simulcast use____
>
>     > cases. The document in section 6.4 talk about declarative usage and point to____
>
>     > section 8 about limitation of supporting this case. In section 8 the____
>
>     > document says that the solution does not support multiple multicast groups____
>
>     > and as such claiming support for declarative usage is very limited or does____
>
>     > not exist.____
>
>     __ __
>
>     So, you suggest that there is no point even mentioning declarative
>     usage? If that helps, I have no problem to remove any mentioning of
>     declarative usage.____
>
>     __ __
>
>     > The question is why does the document support the simulcast attribute only____
>
>     > on the media level and does not define usage for the session level to allow____
>
>     > multiple multicast groups each as a separate RTP session.____
>
>     __ __
>
>     This was an early design choice, which in my view is mainly related
>     to two things:____
>
>     __1)      __RFC 7656 states that an m= block in SDP (an m= line and
>     all lines up to but not including the next m= line, or the end of
>     the SDP) generally corresponds to a (single) media source____
>
>     __2)      __the definition of simulcast to mean sending differently
>     encoded representations of a media source (thus restricted to a
>     single m= block)____
>
>     __ __
>
>     So, the reason is simply that use of multicast groups does not fit
>     well with the above. No immediate need for use of simulcast with
>     multicast was expressed, so the design decision was to basically
>     leave it out of scope for this draft. We could probably make that
>     even more clear.____
>
>     __ __
>
>     I believe it should be possible to define multicast usage of
>     simulcast as a separate document (updating
>     draft-ietf-mmusic-sdp-simulcast) at some later point in time. It
>     seems very straightforward to build a simulcast for multicast on
>     explicitly allowing a=simulcast on session level in SDP. Such update
>     document would have to relax the guideline to restrict a media
>     source to an m= block, probably with a clear motivation and
>     explanation that this is specific for multicast (and other RTP
>     usages where use of multiple different transports is the foremost
>     concern). Without thinking this through entirely, I also believe it
>     would be necessary to make an additional restriction to keep the
>     simulcast stream-identifying RID values unique across the SDP
>     (instead of being localized to an m= line), but it would probably be
>     sufficient to make it work. That RID uniqueness requirement should
>     hardly be any problem to meet in practice, since the possible RID
>     value space is much larger than e.g. RTP payload types.____
>
>     __ __
>
>     Cheers,____
>
>     Bo (as individual)____
>
>     __ __
>
>     *From:*mmusic [mailto:[email-masked]
>     <javascript:_e(%7B%7D,'cvml',[email-masked]');>] *On
>     Behalf Of *Ron Even
>     *Subject:* Re: [MMUSIC] Simulcast draft review needed____
>
>     __ __
>
>     Hi,____
>
>     I sent my review to the list and had no feedback.____
>
>     Roni
>
>     <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:____
>
>         <https://www.ietf.org/id/draft-ietf-mmusic-sdp-simulcast-05.txt>
>
>         to go along with this, and we really need some reviews of that
>         one too. If you have some time to review it, please do so and
>         send your comments to the list (incl. "looks good").
>
>         Thanks
>
>         -- Flemming
>
>
>         <https://www.ietf.org/mailman/listinfo/mmusic>____
>

-- 

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Ron Even <[email-masked]>
Date: Mon, 26 Sep 2016 12:25:29 +0300

Hi,
I am sorry for noticing at this stage but in my view this is something that
we need to look at now since we need to be sure that this solution can
support the multicast declarative case or we will end up with a different
simulcast solution for multicast, which is not a good direction. Support
for multicast is something that is defintly required
Roni

On Monday, September 26, 2016, Magnus Westerlund <
[email-masked]> wrote:

> Then we could have ensured that we had a solution in place for it. However,
> that has not been expressed and the individual version that was adopted as
> WG item (https://www.ietf.org/archive/id/draft-burman-mmusic-sdp-sim
> ulcast-00.txt) says:
>
> extension. The general declarative usage will need to be removed from the
> simulcast draft in the next version due to that RID is missing that
> support. The removal of declarative usage was discussed twice I think as a
> result of my feedback on RID. The end result was that as I didn't have the
> time to propose text, and Adam didn't feel he had the expertise it didn't
> get written up.
>
> The only way forward with simulcast in multicast and declarative use is to
> start working on extension specifications for both the RID and simulcast
> documents. There is no way we can shoehorn it in at this stage.
>
> Cheers
>
> Magnus
>
>

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 26 Sep 2016 11:34:28 +0200

Hi Roni,

I can understand your view, but I don't see that I as document editor 
are performing this change unless the chairs declare that there are at 
least rough consensus to include it. My view is that we need to finish 
simulcast for WebRTC. Taking on a task that is going to delay the work a 
year or so is not viable in my opinion.

So about the different solution. Yes, that is actually likely, but not 
easily addressable. In fact the underlying issue here is the underlying 
assumption that an m= line is a media source for SDP O/A. That is not 
the classical multicast interpretation. And it is clear that for 
multicast one actually have to tackle this discrepancy.

 From my perspective the multicast usage of SDP is something that is 
lagging significantly when it comes to features that has been defined 
for O/A unicast. There are a lot of clarifications and decisions that 
needs to be made. I don't see that we can do any better than to open up 
a WG item to clarify multicast and declarative usages in SDP and then 
build an simulcast extension.

The big question is if there exist sufficient interest in the WG to 
tackle this.

Cheers

Magnus

Den 2016-09-26 kl. 11:25, skrev Ron Even:
> Hi,
> I am sorry for noticing at this stage but in my view this is something
> that we need to look at now since we need to be sure that this solution
> can support the multicast declarative case or we will end up with a
> different simulcast solution for multicast, which is not a good
> direction. Support for multicast is something that is defintly required
> Roni
>
> On Monday, September 26, 2016, Magnus Westerlund
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>     I would have been fine with including multicast support and
>     declarative usages, if we known there was actually an interest in
>     multicast earlier. Then we could have ensured that we had a solution
>     in place for it. However, that has not been expressed and the
>     individual version that was adopted as WG item
>     (https://www.ietf.org/archive/id/draft-burman-mmusic-sdp-simulcast-00.txt
>     <https://www.ietf.org/archive/id/draft-burman-mmusic-sdp-simulcast-00.txt>)
>     says:
>
>     extension. The general declarative usage will need to be removed
>     from the simulcast draft in the next version due to that RID is
>     missing that support. The removal of declarative usage was discussed
>     twice I think as a result of my feedback on RID. The end result was
>     that as I didn't have the time to propose text, and Adam didn't feel
>     he had the expertise it didn't get written up.
>
>     The only way forward with simulcast in multicast and declarative use
>     is to start working on extension specifications for both the RID and
>         <https://www.ietf.org/id/draft-ietf-mmusic-sdp-simulcast-05.txt
>         <https://www.ietf.org/id/draft-ietf-mmusic-sdp-simulcast-05.txt>>
>
>         <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>         <https://www.ietf.org/mailman/listinfo/mmusic>
>                 <https://www.ietf.org/mailman/listinfo/mmusic
>         <https://www.ietf.org/mailman/listinfo/mmusic>>____
>
>
>
>     --
>
>     Magnus Westerlund
>

-- 

Magnus Westerlund

---

From: Ron Even <[email-masked]>
Date: Mon, 26 Sep 2016 17:28:48 +0300

Hi Magnus,
I am not sure why you see this as a big issue. For multicast the RTP
multiplexing is by the 5-tupple IP address so it is much simpler to
identify. This requires that the simulcast attribute will be also on the
session level. The rest is just text to explain that in this case each
configuration is in a separate m-line

On Monday, September 26, 2016, Magnus Westerlund <
[email-masked]> wrote:

> Hi Roni,
>
> I can understand your view, but I don't see that I as document editor are
> performing this change unless the chairs declare that there are at least
> rough consensus to include it. My view is that we need to finish simulcast
> for WebRTC. Taking on a task that is going to delay the work a year or so
> is not viable in my opinion.
>
> assumption that an m= line is a media source for SDP O/A. That is not the
> classical multicast interpretation. And it is clear that for multicast one
> actually have to tackle this discrepancy.
>
> lagging significantly when it comes to features that has been defined for
> O/A unicast. There are a lot of clarifications and decisions that needs to
> be made. I don't see that we can do any better than to open up a WG item to
> clarify multicast and declarative usages in SDP and then build an simulcast
> extension.
>
> The big question is if there exist sufficient interest in the WG to tackle
> this.
>
> Cheers
>
> Magnus
>
>> wrote:____

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 26 Sep 2016 14:47:44 -0400

Greetings MMUSIC

I'd like to hear from more people on this topic before we decide one way 
or the other.

I will note that multicast was removed in the -03 version almost a year 
ago (as noted in the change log). Similarly, Adam Roach asked a related 
question on the -rid draft about 6 months ago, which didn't generate any 
interest in further work either (see 
https://mailarchive.ietf.org/arch/msg/mmusic/kEsBZLBW5exDK25bMvB3YHofm8o).

Thanks

-- Flemming (as MMUSIC co-chair)

On 9/26/16 5:34 AM, Magnus Westerlund wrote:
> simulcast for WebRTC. Taking on a task that is going to delay the work 
> a year or so is not viable in my opinion.
>
> easily addressable. In fact the underlying issue here is the 
> underlying assumption that an m= line is a media source for SDP O/A. 
> That is not the classical multicast interpretation. And it is clear 
> that for multicast one actually have to tackle this discrepancy.
>
> needs to be made. I don't see that we can do any better than to open 
> up a WG item to clarify multicast and declarative usages in SDP and 
> then build an simulcast extension.
>

---

From: Roman Shpount <[email-masked]>
Date: Mon, 26 Sep 2016 15:04:43 -0400

On Mon, Sep 26, 2016 at 2:47 PM, Flemming Andreasen <[email-masked]>
wrote:

> interest in further work either (see https://mailarchive.ietf.org/a
> rch/msg/mmusic/kEsBZLBW5exDK25bMvB3YHofm8o).
>

I would be strongly against spending any time on multicast at this point.
If multicast is needed, it should be addressed in a separate document. From
what I have seen, covering multicast and declarative SDP usage at the same
time as O/A procedures creates nothing but confusion.

Regards,
_____________
Roman Shpount

---

From: Ron Even <[email-masked]>
Date: Tue, 27 Sep 2016 01:32:22 +0300

Hi,
As far as I understand there is no need for rid for the multicast case
where each so,upcast stream is in a separate rtp session. The image
attribute is used to describe the simulcast configuration.
So I am not sure why we have a problem here except for the issue with
having each simulcast stream in a different m-line which even though they
are from the same source.
Now if this document will only address conversional application usage it
should be clear from the title since it is not a full simulcast support.
BTW: in my view the multicast simulcast is the more relevant usage for
simulcast. I believe that for conversional application scalable video make
more sense for the encoder side.

Roni

---

From: Ron Even <[email-masked]>
Date: Tue, 27 Sep 2016 01:38:17 +0300

Hi,
I am sorry but can you explain what you mean by creating confusion?
Roni Even

On Monday, September 26, 2016, Roman Shpount <[email-masked]> wrote:

> On Mon, Sep 26, 2016 at 2:47 PM, Flemming Andreasen <[email-masked]

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 27 Sep 2016 09:55:36 +0200

> configuration is in a separate m-line

So, what about multi source cases, one RTP session and multicast group 
per source and format? Or one per format and multiple sources in each 
multicast group. And also what you seem to propose is that we depart 
from RIDs and IDs and instead use MIDs? Is that the only option.

I am not saying that this is highly complex but it is not something that 
you throw together during a coffe break and everyone agrees with it.

Yes, another document has its overhead, but it has its advantages. And I 
think one will be authors that are interested in the issue. I might be 
interested from a technology perspective, this is not a task that fits 
into my current priorities.

Roni, if it is easy as you claim, please write it up so that we have a 
text proposal.

Cheers

Magnus Westerlund

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Tue, 27 Sep 2016 09:13:09 +0000

Hi,

I think it does have some requirements to support multicast in simulcast. There might be some simulcast in multicast scenarios, i.e., multicast ABR, out there. We should not ignore that. 

But It also makes sense to me that the current scope of this draft explicitly indicates that it only considers unicast case and multicast could be in the future consideration. 

BR,
Rachel

-----邮件原件-----
发件人: mmusic [mailto:[email-masked]] 代表 Flemming Andreasen
发送时间: 2016年9月27日 2:48
收件人: Magnus Westerlund; Ron Even
抄送: [email-masked]; mmusic
主题: [MMUSIC] Multicast support in simulcast ? [Re: Simulcast draft review needed]

Greetings MMUSIC

I'd like to hear from more people on this topic before we decide one way or the other.

I will note that multicast was removed in the -03 version almost a year ago (as noted in the change log). Similarly, Adam Roach asked a related question on the -rid draft about 6 months ago, which didn't generate any interest in further work either (see https://mailarchive.ietf.org/arch/msg/mmusic/kEsBZLBW5exDK25bMvB3YHofm8o).

Thanks

On 9/26/16 5:34 AM, Magnus Westerlund wrote:
>> I am sorry for noticing at this stage but in my view this is 
>> something that we need to look at now since we need to be sure that 
>> this solution can support the multicast declarative case or we will 
>> end up with a different simulcast solution for multicast, which is 
>> not a good direction. Support for multicast is something that is 
>> defintly required Roni
>>

---

From: Ron Even <[email-masked]>
Date: Tue, 27 Sep 2016 15:57:23 +0300

Hi Magnus,
You are right what I was pointing out is that the rid based approach is
relevant for the single M-line approach or MRST case. I have no problem
with a separate documen but it should be clear in the document that
multicast usage is a valid use case for declarative SDP and since it was
not addressed in this document it may require a different attribute.

I would like to see text in the document, maybe in the introduction
section, like
"This solution addresses the offer/answer case and may not support the
declarative multicast case used in streaming applications. Since the
declarative SDP support was not analyzed by this solution it may require a
different approach which will not be an extension to the offer/answer
solution e.g. requiring a different SDP attribute"

Roni

On Tuesday, September 27, 2016, Magnus Westerlund <
[email-masked]> wrote:

> So, what about multi source cases, one RTP session and multicast group per
> source and format? Or one per format and multiple sources in each multicast
> group. And also what you seem to propose is that we depart from RIDs and
> IDs and instead use MIDs? Is that the only option.
>
> interested from a technology perspective, this is not a task that fits into
> my current priorities.
>

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 27 Sep 2016 15:59:14 +0200

Den 2016-09-27 kl. 14:57, skrev Ron Even:
> declarative SDP support was not analyzed by this solution it may require
> a different approach which will not be an extension to the offer/answer

Yes, I have no issue with clarifying the scoping of our simulcast 
document in the introduction.

/Magnus

> Roni
>
> On Tuesday, September 27, 2016, Magnus Westerlund
>     So, what about multi source cases, one RTP session and multicast
>     group per source and format? Or one per format and multiple sources
>     in each multicast group. And also what you seem to propose is that
>     we depart from RIDs and IDs and instead use MIDs? Is that the only
>     option.
>
>     I am not saying that this is highly complex but it is not something
>     that you throw together during a coffe break and everyone agrees
>     with it.
>
>     Yes, another document has its overhead, but it has its advantages.
>     And I think one will be authors that are interested in the issue. I
>     might be interested from a technology perspective, this is not a
>     task that fits into my current priorities.
>
>     Roni, if it is easy as you claim, please write it up so that we have
>     a text proposal.
>
>     Cheers
>
>     Magnus Westerlund
>

-- 

Magnus Westerlund

---

From: Adam Roach <[email-masked]>
Date: Tue, 27 Sep 2016 13:36:36 -0500

On 9/26/16 1:47 PM, Flemming Andreasen wrote:
> I will note that multicast was removed in the -03 version almost a 
> year ago (as noted in the change log). Similarly, Adam Roach asked a 
> related question on the -rid draft about 6 months ago, which didn't 
> generate any interest in further work either (see 

To be clear, the apathy ran deeper than that.

Initially, the RID document didn't cover declarative use cases. Someone 
asked whether it should, and I threw in a relatively small section that 
I thought would cover the situation. The message Flemming cited above 
received zero comments. Later, Magnus noted that declarative use would 
take nontrivially more work than the current text. At the meeting in 
Berlin, we raised the question about whether anyone was willing to do 
that extra work. The only comment, aside from overwhelming silence, was 
Magnus indicating that he didn't have sufficient interest in multicast 
use of RIDs to author any text.

I think it's manifestly clear that the MMUSIC working group currently 
lacks the energy and motivation to work on RID/simulcast for multicast 
scenarios. Making the unicast specification of these features wait for 
someone to care enough about multicast to do any real work is 
effectively a death sentence -- the publication of a simulcast mechanism 
will become contingent on a day that may well never arrive.

So, to be crystal clear: I do not support any changes in the RID or 
simulcast documents regarding multicast, except possibly to make it more 
obvious that multicast is out of scope.

/a

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Tue, 27 Sep 2016 19:01:10 +0000

I do not think we should expand the scope of the current simulcast or rid specs to include multicast. If there is enough interest in multicast (which has not been the case each time folks have asked), a more wholistic effort is needed as there are more fundamental gaps before addressing simulcast, and the simulcast draft is certainly not the right place for those more fundamental issues. 

Mo

On Sep 26, 2016, at 2:47 PM, Flemming Andreasen (fandreas) <[email-masked]> wrote:

Greetings MMUSIC

Thanks

> I can understand your view, but I don't see that I as document editor are performing this change unless the chairs declare that there are at least rough consensus to include it. My view is that we need to finish simulcast for WebRTC. Taking on a task that is going to delay the work a year or so is not viable in my opinion.
> 
> So about the different solution. Yes, that is actually likely, but not easily addressable. In fact the underlying issue here is the underlying assumption that an m= line is a media source for SDP O/A. That is not the classical multicast interpretation. And it is clear that for multicast one actually have to tackle this discrepancy.
> 
> From my perspective the multicast usage of SDP is something that is lagging significantly when it comes to features that has been defined for O/A unicast. There are a lot of clarifications and decisions that needs to be made. I don't see that we can do any better than to open up a WG item to clarify multicast and declarative usages in SDP and then build an simulcast extension.
> 
> The big question is if there exist sufficient interest in the WG to tackle this.
> 
> Cheers
> 
> Magnus
>

---

From: Roman Shpount <[email-masked]>
Date: Tue, 27 Sep 2016 15:02:45 -0400

Roni,

>From what I've seen most of the people working or implementing these
specifications do not care about multicast. Because of this, multicast
sections do not get sufficiently reviewed or discussed, which decreases the
overall quality of the resulting document. At the end, the multicast
sections end up being fairly unclear or confusing. I think the better
strategy to keep declarative SDP, multicast related topics in the separate
document who is written and reviewed by people who sufficiently care about
multicast use cases to create something usable.

Regards,
_____________
Roman Shpount

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 28 Sep 2016 08:08:26 +0100

> On Sep 27, 2016, at 2:59 PM, Magnus Westerlund <[email-masked]> wrote:
> 
>> 
> Yes, I have no issue with clarifying the scoping of our simulcast document in the introduction.
> 
> /Magnus

works for me