Using Simulcast in Session Description Protocol (SDP) and RTP Sessions
draft-ietf-mmusic-sdp-simulcast-14
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2020-05-22
|
14 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2020-04-09
|
14 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2020-03-16
|
14 | (System) | RFC Editor state changed to RFC-EDITOR from REF |
2019-08-19
|
14 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'Overtaken by Events' |
2019-08-19
|
14 | Gunter Van de Velde | Assignment of request for Last Call review by OPSDIR to Fred Baker was marked no-response |
2019-08-16
|
14 | (System) | RFC Editor state changed to REF from EDIT |
2019-08-16
|
14 | (System) | RFC Editor state changed to EDIT from MISSREF |
2019-08-15
|
14 | (System) | RFC Editor state changed to MISSREF from EDIT |
2019-08-15
|
14 | (System) | RFC Editor state changed to EDIT from MISSREF |
2019-03-05
|
14 | Bo Burman | New version available: draft-ietf-mmusic-sdp-simulcast-14.txt |
2019-03-05
|
14 | (System) | New version approved |
2019-03-05
|
14 | (System) | Request for posting confirmation emailed to previous authors: Bo Burman , Mo Zanaty , Suhas Nandakumar , Magnus Westerlund |
2019-03-05
|
14 | Bo Burman | Uploaded new revision |
2018-07-19
|
13 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'No Response' |
2018-07-11
|
13 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2018-07-11
|
13 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2018-07-11
|
13 | (System) | RFC Editor state changed to MISSREF |
2018-07-11
|
13 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2018-07-11
|
13 | (System) | Announcement was received by RFC Editor |
2018-07-10
|
13 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2018-07-10
|
13 | (System) | IANA Action state changed to In Progress |
2018-07-10
|
13 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2018-07-10
|
13 | Cindy Morgan | IESG has approved the document |
2018-07-10
|
13 | Cindy Morgan | Closed "Approve" ballot |
2018-07-10
|
13 | Ben Campbell | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2018-07-10
|
13 | Ben Campbell | Ballot approval text was generated |
2018-07-10
|
13 | Wesley Eddy | Closed request for Last Call review by TSVART with state 'Overtaken by Events' |
2018-07-06
|
13 | Adam Roach | [Ballot comment] Recusing, as I am a contributor to this document. Thanks for addressing my earlier discuss and comments! |
2018-07-06
|
13 | Adam Roach | [Ballot Position Update] Position for Adam Roach has been changed to Recuse from Discuss |
2018-06-27
|
13 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2018-06-27
|
13 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2018-06-27
|
13 | Bo Burman | New version available: draft-ietf-mmusic-sdp-simulcast-13.txt |
2018-06-27
|
13 | (System) | New version approved |
2018-06-27
|
13 | (System) | Request for posting confirmation emailed to previous authors: Bo Burman , Mo Zanaty , Suhas Nandakumar , Magnus Westerlund |
2018-06-27
|
13 | Bo Burman | Uploaded new revision |
2018-06-21
|
12 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2018-06-21
|
12 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2018-06-20
|
12 | Ignas Bagdonas | [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas |
2018-06-20
|
12 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2018-06-20
|
12 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2018-06-19
|
12 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2018-06-19
|
12 | Adam Roach | [Ballot discuss] Thanks to everyone who put in the hard work to make this document happen. I have found a blocking issue that I believe … [Ballot discuss] Thanks to everyone who put in the hard work to make this document happen. I have found a blocking issue that I believe should be easy to address; but (due to the potential impact on interoperability) document publication does need to be blocked pending resolution of this issue. The problem is that the SDP examples in this document are not consistent with the syntax and semantics defined in draft-ietf-mmusic and draft-ietf-avtext-rid, as described below. --------------------------------------------------------------------------- §4, Figure 1: > a=rid:1 send pt=97 max-width=1280;max-height=720 > a=rid:2 send pt=98 max-width=320;max-height=180 > a=rid:3 send pt=99 max-width=320;max-height=180 > a=rid:4 recv pt=97 The final syntax for RID ended up with PT being treated the same as other parameters, and therefore requiring a semicolon delimiter between it and stream restrictions. So this example should read: a=rid:1 send pt=97;max-width=1280;max-height=720 a=rid:2 send pt=98;max-width=320;max-height=180 a=rid:3 send pt=99;max-width=320;max-height=180 a=rid:4 recv pt=97 --------------------------------------------------------------------------- §4, Figure 1: > a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:RtpStreamId Although the SDES item is called "RtpStreamId," the URN registered for its identification is urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id -- see section 4.3 of draft-ietf-avtext-rid. This example should read: a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id --------------------------------------------------------------------------- The preceding two comments regarding SDP syntax also apply to Figure 2, Figure 5, Figure 6, Figure 7, and Figure 8. --------------------------------------------------------------------------- Figure 8 (which is missing a figure label): > a=rid:5 send pt=99,102;max-br=64000 > a=rid:6 send pt=100,97,101,102 The selection of "5" and "6" for these RIDs goes against the advice in section 3.3 of draft-ietf-avtext-rid; and, even worse, may give the incorrect impression that RID space is shared between media sections. Please adjust them to be 1 and 2 instead of 5 and 6. Also, if LPC is intended to be used with the first RID (as is suggested by the text above the example), then your "pt" value needs to be "pt=99,102,98" -- otherwise, the RID will prevent the use of PT 98. Remember: RID defines *restrictions*. If you say "pt" and then don't list a PT in it, then that missing PT is strictly forbidden from appearing with that RID. There is a similar problem with the video section, which needs to read as follows to match the explanatory text: a=rid:1 send pt=103,105,107;max-width=1280;max-height=720;max-fps=30 a=rid:2 send pt=104,106,107;max-width=1280;max-height=720;max-fps=30 a=rid:3 send pt=103,105,107;max-width=640;max-height=360;max-br=300000 a=rid:4 send pt=104,106,107;max-width=640;max-height=360;max-br=300000 |
2018-06-19
|
12 | Adam Roach | Ballot discuss text updated for Adam Roach |
2018-06-19
|
12 | Adam Roach | [Ballot discuss] Thanks to everyone who put in the hard work to make this document happen. I have found a blocking issue that I believe … [Ballot discuss] Thanks to everyone who put in the hard work to make this document happen. I have found a blocking issue that I believe should be easy to address; but (due to the potential impact on interoperability) document publication does need to be blocked pending resolution of this issue. The problem is that the SDP examples in this document are not consistent with the syntax and semantics defined in draft-ietf-mmusic and draft-ietf-avtext-rid, as described below. --------------------------------------------------------------------------- §4, Figure 1: > a=rid:1 send pt=97 max-width=1280;max-height=720 > a=rid:2 send pt=98 max-width=320;max-height=180 > a=rid:3 send pt=99 max-width=320;max-height=180 > a=rid:4 recv pt=97 The final syntax for RID ended up with PT being treated the same as other parameters, and therefore requiring a semicolon delimiter between it and stream restrictions. So this example should read: a=rid:1 send pt=97;max-width=1280;max-height=720 a=rid:2 send pt=98;max-width=320;max-height=180 a=rid:3 send pt=99;max-width=320;max-height=180 a=rid:4 recv pt=97 --------------------------------------------------------------------------- §4, Figure 1: > a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:RtpStreamId Although the SDES item is called "RtpStreamId," the URN registered for its identification is urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id -- see section 4.3 of draft-ietf-avtext-rid. This example should read: a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id --------------------------------------------------------------------------- The preceding two comments regarding SDP syntax also apply to Figure 2, Figure 5, Figure 6, Figure 7, and Figure 8. --------------------------------------------------------------------------- Figure 8 (which is missing a figure label): > a=rid:5 send pt=99,102;max-br=64000 > a=rid:6 send pt=100,97,101,102 The selection of "5" and "6" for these RIDs goes against the advice in section 3.3 of draft-ietf-avtext-rid; and, even worse, may give the incorrect impression that RID space is shared between media sections. Please adjust them to be 1 and 2 instead of 5 and 6. Also, if LPC is intended to be used with the first RID (as is suggested by the text above the example), then your "pt" value needs to be "pt=99,102,98" -- otherwise, the RID will prevent the use of PT 98. Remember: RID defines *restrictions*. If you say "pt" and then don't list a PT in it, then that missing PT is strictly forbidden from appearing with with that RID. There is a similar problem with the video section, which needs to read as follows to match the explanatory text: a=rid:1 send pt=103,105,107;max-width=1280;max-height=720;max-fps=30 a=rid:2 send pt=104,106,107;max-width=1280;max-height=720;max-fps=30 a=rid:3 send pt=103,105,107;max-width=640;max-height=360;max-br=300000 a=rid:4 send pt=104,106,107;max-width=640;max-height=360;max-br=300000 |
2018-06-19
|
12 | Adam Roach | Ballot discuss text updated for Adam Roach |
2018-06-19
|
12 | Adam Roach | [Ballot discuss] Thanks to everyone who put in the hard work to make this document happen. I have found a blocking issue that I believe … [Ballot discuss] Thanks to everyone who put in the hard work to make this document happen. I have found a blocking issue that I believe should be easy to address; but (due to the potential impact on interoperability) document publication does need to be blocked pending resolution of this issue. The problem is that the SDP examples in this document are not consistent with the syntax and semantics defined in draft-ietf-mmusic and draft-ietf-avtext-rid, as described below. --------------------------------------------------------------------------- §4, Figure 1: > a=rid:1 send pt=97 max-width=1280;max-height=720 > a=rid:2 send pt=98 max-width=320;max-height=180 > a=rid:3 send pt=99 max-width=320;max-height=180 > a=rid:4 recv pt=97 The final syntax for RID ended up with PT being treated the same as other parameters, and therefore requiring a semicolon delimiter between it and stream restrictions. So this example should read: a=rid:1 send pt=97;max-width=1280;max-height=720 a=rid:2 send pt=98;max-width=320;max-height=180 a=rid:3 send pt=99;max-width=320;max-height=180 a=rid:4 recv pt=97 --------------------------------------------------------------------------- §4, Figure 1: > a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:RtpStreamId Although the SDES item is called "RtpStreamId," the URN registered for its identification is urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id -- see section 4.3 of draft-ietf-avtext-rid. This example should read: a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id --------------------------------------------------------------------------- The preceding two comments regarding SDP syntax also apply to Figure 2, Figure 5, Figure 6, Figure 7, and Figure 8. --------------------------------------------------------------------------- Figure 8 (which is missing a figure label): > a=rid:5 send pt=99,102;max-br=64000 > a=rid:6 send pt=100,97,101,102 The selection of "5" and "6" for these RIDs goes against the advice in section 3.3 of draft-ietf-avtext-rid; and, even worse, may give the incorrect impression that RID space is shared between media sections. Please adjust them to be 1 and 2 instead of 5 and 6. Also, if LPC is inteded to be used with the first RID (as is suggested by the text above the example), then your "pt" value needs to be "pt=99,102,98" -- otherwise, the RID will prevent the use of PT 98. Remember: RID defines *restrictions*. If you say "pt" and then don't list a PT in it, then that missing PT is strictly forbidden from appearing with with that RID. There is a similar problem with the video section, which needs to read as follows to match the explanatory text: a=rid:1 send pt=103,105,107;max-width=1280;max-height=720;max-fps=30 a=rid:2 send pt=104,106,107;max-width=1280;max-height=720;max-fps=30 a=rid:3 send pt=103,105,107;max-width=640;max-height=360;max-br=300000 a=rid:4 send pt=104,106,107;max-width=640;max-height=360;max-br=300000 |
2018-06-19
|
12 | Adam Roach | Ballot discuss text updated for Adam Roach |
2018-06-19
|
12 | Adam Roach | [Ballot discuss] Thanks to everyone who put in the hard work to make this document happen. I have found a blocking issue that I believe … [Ballot discuss] Thanks to everyone who put in the hard work to make this document happen. I have found a blocking issue that I believe should be easy to address; but (due to the potential impact on interoperability) document publication does need to be blocked pending resolution of this issue. The problem is that the SDP examples in this document are not consistent with the syntax and semantics defined in draft-ietf-mmusic and draft-ietf-avtext-rid, as described below. --------------------------------------------------------------------------- §4, Figure 1: > a=rid:1 send pt=97 max-width=1280;max-height=720 > a=rid:2 send pt=98 max-width=320;max-height=180 > a=rid:3 send pt=99 max-width=320;max-height=180 > a=rid:4 recv pt=97 The final syntax for RID ended up with PT being treated the same as other parameters, and therefore requiring a semicolon delimiter between it and stream restrictions. So this example should read: a=rid:1 send pt=97;max-width=1280;max-height=720 a=rid:2 send pt=98;max-width=320;max-height=180 a=rid:3 send pt=99;max-width=320;max-height=180 a=rid:4 recv pt=97 --------------------------------------------------------------------------- §4, Figure 1: > a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:RtpStreamId Although the SDES item is called "RtpStreamId," the URN registered for its identification is urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id -- see section 4.3 of draft-ietf-avtext-rid. This example should read: a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id --------------------------------------------------------------------------- The preceding two comments regarding SDP syntax also apply to Figure 2, Figure 5, Figure 6, Figure 7, Figure 8 --------------------------------------------------------------------------- Figure 8 (which is missing a figure label): > a=rid:5 send pt=99,102;max-br=64000 > a=rid:6 send pt=100,97,101,102 The selection of "5" and "6" for these RIDs goes against the advice in section 3.3 of draft-ietf-avtext-rid; and, even worse, may give the incorrect impression that RID space is shared between media sections. Please adjust them to be 1 and 2 instead of 5 and 6. Also, if LPC is inteded to be used with the first RID (as is suggested by the text above the example), then your "pt" value needs to be "pt=99,102,98" -- otherwise, the RID will prevent the use of PT 98. Remember: RID defines *restrictions*. If you say "pt" and then don't list a PT in it, then that missing PT is strictly forbidden from appearing with with that RID. There is a similar problem with the video section, which needs to read as follows to match the explanatory text: a=rid:1 send pt=103,105,107;max-width=1280;max-height=720;max-fps=30 a=rid:2 send pt=104,106,107;max-width=1280;max-height=720;max-fps=30 a=rid:3 send pt=103,105,107;max-width=640;max-height=360;max-br=300000 a=rid:4 send pt=104,106,107;max-width=640;max-height=360;max-br=300000 |
2018-06-19
|
12 | Adam Roach | [Ballot comment] I will be recusing myself from a ballot position once the preceding issues have been resolved, as I am a contributor to this … [Ballot comment] I will be recusing myself from a ballot position once the preceding issues have been resolved, as I am a contributor to this document. I found some minor issues and a number of editorial nits that warrant correction prior to publication. --------------------------------------------------------------------------- §1: > Usage of multicast or broadcast transport is out of scope and left > for future extension. "...future extensions." --------------------------------------------------------------------------- §1: > This document describes a few scenarios that motivates the use of "...that motivate the use..." --------------------------------------------------------------------------- §3: > There are two principle approaches for an RTP Mixer to provide this "...two principal approaches..." --------------------------------------------------------------------------- §5.1: > sc-send = "send" SP sc-str-list > sc-recv = "recv" SP sc-str-list While it's a bit muddled in the base SDP spec, it appears that the general convention here is to make SDP strings case-sensitive. I believe this document wants to cite RFC 7405, and adjust these two lines to read: sc-send = %s"send" SP sc-str-list sc-recv = %s"recv" SP sc-str-list --------------------------------------------------------------------------- §5.2: > there is currently no mechanism for align the choice between > alternative rid-ids between different simulcast streams. "...mechanism to align..." --------------------------------------------------------------------------- Figure 7: > m=video 49602 RTP/AVPF 96 104 > a=mid:zen > a=rtpmap:96 VP8/90000 > a=fmtp:96 max-fs=3600; max-fr=30 > a=rtpmap:104 rtx/90000 > a=fmtp:104 apt=96;rtx-time=200 > a=rid:1 send pt=96;max-fs=921600;max-fps=30 > a=rid:2 send pt=96;max-fs=614400;max-fps=15 > a=rid:3 send pt=96;max-fs=230400;max-fps=30 > a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid > a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:RtpStreamId > a=rtcp-fb:* ccm pause nowait > a=simulcast:send 1;~2;~3 While this isn't technically invalid (modulo the extmap lines), it's saying something a bit odd. Namely, it's offering to use RTX if the answerer doesn't understand RID, but forbidding the use of RTX if they do. You probably meant something more like: a=rid:1 send pt=96,104;max-fs=921600;max-fps=30 a=rid:2 send pt=96,104;max-fs=614400;max-fps=15 a=rid:3 send pt=96,104;max-fs=230400;max-fps=30 Or, really, since that's all the PTs that are defined for this media section, just leave it out altogether: a=rid:1 send max-fs=921600;max-fps=30 a=rid:2 send max-fs=614400;max-fps=15 a=rid:3 send max-fs=230400;max-fps=30 Either way is valid and sensible -- the second might be a better example, since it demonstrates the use of simulcast without payload-restricted RID lines. You don't want to give the erroneous impression that "pt" is required on the RID line for simulcast to work. |
2018-06-19
|
12 | Adam Roach | [Ballot Position Update] New position, Discuss, has been recorded for Adam Roach |
2018-06-19
|
12 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2018-06-19
|
12 | Benjamin Kaduk | [Ballot comment] I have some questions, probably just due to confusion on my part, as well as some nit-leve comments. Section 3 There are … [Ballot comment] I have some questions, probably just due to confusion on my part, as well as some nit-leve comments. Section 3 There are two principle approaches for an RTP Mixer to provide this adapted view of the communication session to each receiving participant: I think this is more a case for "principal" than "principle", as it's talking about the primary or main options. Section 3.1 Expand QoE at first usage only (the fourth usage also has an expansion). Section 5.1 [...] Since pause capability specified via the "a=rtcp-fb" attribute and rid-id specified by "a=rid" can refer to common payload types, it is unfeasible to pause streams with rid- id where any of the related RTP payload type(s) do not have pause capability. My brain is having trouble reading this last sentence; maybe it's trying to say there's a singular/plural disagreement between "capability" and "payload types", but I think the second clause may also be giving my brain trouble. Am I parsing things properly as this noting that some ("common"/"widely used") payload types do not support pausing, and that trying to use SDP syntax to pause streams using that payload type is not going to work well? Section 5.2 All RTP payload types related to such initially paused simulcast stream MUST be listed in the SDP as pause/resume capable as specified by [RFC7728], e.g. by using the "*" wildcard format for "a=rtcp-fb". nit: I think "streams" plural is needed to be consistent with "payload types" plural. If the endpoint sending the SDP includes an "recv" direction simulcast stream that is initially paused, then the remote RTP sender receiving the SDP SHOULD put its RTP stream in a unsolicited locally paused state. However, this does not apply if there are other RTP stream receivers that do not mark the simulcast stream as initially paused. I'm not sure if I'm parsing this properly (probably due to ignorance on my part). Are the "other RTP stream receivers" other SDP participants that are for some reason (multicast?) using the same descriptions, or is this covering the case of things like dependent streams where something else in the whole negotiated session requires that stream? I'm not entirely sure what concrete information/recommendation/action I'm supposed to take from Section 6.2.2. Maybe I just haven't had enough tea yet today. |
2018-06-19
|
12 | Benjamin Kaduk | [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk |
2018-06-18
|
12 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2018-06-18
|
12 | Eric Rescorla | [Ballot comment] Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D4629 It might be nice if you explained some of the basic concepts for how to use … [Ballot comment] Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D4629 It might be nice if you explained some of the basic concepts for how to use this with offer/answer in the introduction. I found the explanation kind of confusing until I got there. COMMENTS S 3.2. > It is also common that a currently active speaker participant is > shown in larger size or higher quality than other participants (the > sampling or bitrate aspects of Section 3.1). Not sending the active > speaker media back to itself means there is some other participant's > media that instead has to receive special handling towards the active > speaker; typically the previous active speaker. This way, the This isn't strictly true. You could *show* yourself big. S 4. > With this SDP answer, the answerer indicates in the "recv" part that > it wants to receive the two simulcast RTP streams. It has removed an > alternative that it doesn't support (rid-id 3). The send part > confirms to the offerer that it will receive one stream for this > media source according to rid-id 4. The corresponding, more complete > example SDP answer media description could look like: Do these need to be reversed in order in the answer? S 6.2.1. > The mixer may communicate the identity of the originating media > source to the receiver by including the CSRC field with the > originating media source's SSRC value. Note that due to the > possibility that the RTP mixer switches between simulcast versions of > the media source, the CSRC value may change, even if the media source > is kept the same. How does this interact with PERC? |
2018-06-18
|
12 | Eric Rescorla | [Ballot Position Update] New position, No Objection, has been recorded for Eric Rescorla |
2018-06-18
|
12 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2018-06-18
|
12 | Mirja Kühlewind | [Ballot comment] Two smallish comments/questions: 1) Maybe section 3 could/should also mention that sending multiple stream simultaneously from the source to a mixer has also … [Ballot comment] Two smallish comments/questions: 1) Maybe section 3 could/should also mention that sending multiple stream simultaneously from the source to a mixer has also the disadvantage of consuming more network resources..? 2) The intro says: "The media transport topologies considered are point to point RTP sessions as well as centralized multi-party RTP sessions..." but then only middlebox scenarios are discussed and I actually cannot really imagine where a point-to-point scenario makes sense. Could you clarify…? |
2018-06-18
|
12 | Mirja Kühlewind | Ballot comment text updated for Mirja Kühlewind |
2018-06-18
|
12 | Mirja Kühlewind | [Ballot comment] Two smallish comments/questions: 1) Maybe section 3 could/should also mention that sending multiple stream simultaneously from the source to a mixer has also … [Ballot comment] Two smallish comments/questions: 1) Maybe section 3 could/should also mention that sending multiple stream simultaneously from the source to a mixer has also the disadvantage of consuming more network resources..? 2) The intro says: "The media transport topologies considered are point to point RTP sessions as well as centralized multi-party RTP sessions..." but then only middlebox scenarios are discussed and I actually cannot really imagine where a point-to-point scenario make sense. Could you clarify this…? |
2018-06-18
|
12 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2018-06-17
|
12 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
2018-05-24
|
12 | Amy Vezza | Telechat date has been changed to 2018-06-21 from 2018-06-07 |
2018-05-22
|
12 | Amy Vezza | Placed on agenda for telechat - 2018-06-07 |
2018-05-21
|
12 | Ben Campbell | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2018-05-21
|
12 | Ben Campbell | Ballot has been issued |
2018-05-21
|
12 | Ben Campbell | [Ballot Position Update] New position, Yes, has been recorded for Ben Campbell |
2018-05-21
|
12 | Ben Campbell | Created "Approve" ballot |
2018-05-21
|
12 | Ben Campbell | Ballot approval text was generated |
2018-05-07
|
12 | Sabrina Tanamal | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2018-04-24
|
12 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2018-04-23
|
12 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2018-04-23
|
12 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-mmusic-sdp-simulcast-12. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-mmusic-sdp-simulcast-12. If any part of this review is inaccurate, please let us know. The IANA Services Operator understands that, upon approval of this document, there is a single action which we must complete. In the att-field (media level only) registry on the Session Description Protocol (SDP) Parameters registry page located at: https://www.iana.org/assignments/sdp-parameters/ a single, new registration will be made as follows: Type: att-field (media level only) SDP Name: simulcast MUX Category: NORMAL Reference: [ RFC-to-be ] As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC. The IANA Services Operator understands that this is the only action required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2018-04-21
|
12 | Matthew Miller | Request for Last Call review by GENART Completed: Ready. Reviewer: Matthew Miller. Sent review to list. |
2018-04-19
|
12 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Sandra Murphy |
2018-04-19
|
12 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Sandra Murphy |
2018-04-16
|
12 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Fred Baker |
2018-04-16
|
12 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Fred Baker |
2018-04-16
|
12 | Gunter Van de Velde | Assignment of request for Last Call review by OPSDIR to Stefan Winter was rejected |
2018-04-15
|
12 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Stefan Winter |
2018-04-15
|
12 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Stefan Winter |
2018-04-12
|
12 | Jean Mahoney | Request for Last Call review by GENART is assigned to Matthew Miller |
2018-04-12
|
12 | Jean Mahoney | Request for Last Call review by GENART is assigned to Matthew Miller |
2018-04-11
|
12 | Magnus Westerlund | Request for Last Call review by TSVART is assigned to Wesley Eddy |
2018-04-11
|
12 | Magnus Westerlund | Request for Last Call review by TSVART is assigned to Wesley Eddy |
2018-04-10
|
12 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2018-04-10
|
12 | Cindy Morgan | The following Last Call announcement was sent out (ends 2018-04-24): From: The IESG To: IETF-Announce CC: fandreas@cisco.com, ben@nostrum.com, mmusic-chairs@ietf.org, mmusic@ietf.org, draft-ietf-mmusic-sdp-simulcast@ietf.org … The following Last Call announcement was sent out (ends 2018-04-24): From: The IESG To: IETF-Announce CC: fandreas@cisco.com, ben@nostrum.com, mmusic-chairs@ietf.org, mmusic@ietf.org, draft-ietf-mmusic-sdp-simulcast@ietf.org Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Using Simulcast in SDP and RTP Sessions) to Proposed Standard The IESG has received a request from the Multiparty Multimedia Session Control WG (mmusic) to consider the following document: - 'Using Simulcast in SDP and RTP Sessions' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-04-24. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract In some application scenarios it may be desirable to send multiple differently encoded versions of the same media source in different RTP streams. This is called simulcast. This document describes how to accomplish simulcast in RTP and how to signal it in SDP. The described solution uses an RTP/RTCP identification method to identify RTP streams belonging to the same media source, and makes an extension to SDP to relate those RTP streams as being different simulcast formats of that media source. The SDP extension consists of a new media level SDP attribute that expresses capability to send and/or receive simulcast RTP streams. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-simulcast/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-simulcast/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2536/ |
2018-04-10
|
12 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2018-04-10
|
12 | Ben Campbell | Last call was requested |
2018-04-10
|
12 | Ben Campbell | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2018-04-10
|
12 | Ben Campbell | Last call announcement was generated |
2018-04-10
|
12 | Ben Campbell | Ballot writeup was changed |
2018-04-10
|
12 | Ben Campbell | Ballot approval text was generated |
2018-04-10
|
12 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2018-04-10
|
12 | Magnus Westerlund | New version available: draft-ietf-mmusic-sdp-simulcast-12.txt |
2018-04-10
|
12 | (System) | New version approved |
2018-04-10
|
12 | (System) | Request for posting confirmation emailed to previous authors: Bo Burman , Mo Zanaty , Suhas Nandakumar , Magnus Westerlund |
2018-04-10
|
12 | Magnus Westerlund | Uploaded new revision |
2018-04-09
|
11 | Ben Campbell | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2018-03-29
|
11 | Ben Campbell | This is my AD Evaluation of draft-ietf-mmusic-sdp-simulcast-11.Thanks for all the work on this; overall it’s in good shape. I do, however, have some comments. I’d … This is my AD Evaluation of draft-ietf-mmusic-sdp-simulcast-11.Thanks for all the work on this; overall it’s in good shape. I do, however, have some comments. I’d like to address my substantive comments and significatn editorial comments prior to IETF LC. --------------------------------- Substantive: §5.2, paragraph 12: — " RTP duplication [RFC7104 ] procedures SHOULD be considered instead of simulcast” “considered” seems weak for a normative statement. Should this say “SHOULD use”? — " Note that this does not eliminate use of simulcast as an RTP duplication mechanism, since it is possible to define multiple different rid-id that are effectively equivalent.” Didn’t the first part of the paragraph say (or at least imply) that you SHOULD NOT do that? §7: Is there anything to say about congestion? (I don’t know that there is; I just want to make sure people thought about it.) §9: Is there any reason not to make the registration contact “The IESG (iesg@ietf.org)” ? Appendix A: Are the requirements met by this document? If so, is there value to the reader to keep the requirements in the document? Significant Editorial: §2.2: Please use the boilerplate from RFC 8174—there are at least several lower case “should”s in the document. §3, 2nd bullet: “… and does not require RTP Mixer (full) access to media content.” That’s a potentially strong advantage. Should there be a reciprocal “disadvantage” for the transcoding case? §4, 4th paragraph: “ Each simulcast RTP stream identifier (rid-id) is separated by a semicolon (";"). When rid-ids are separated by a comma (","), they describe alternative representations for that particular simulcast RTP stream.” That text is confusing, it says instances of rid-id are separated by semicolons, then says “when separated by commas”. I think you mean that a semicolon separates rids for different streams, and a comma separates multiple rids for the same stream? §4, last paragraph: This paragraph seems like it belongs earlier in the section. §5.2: — First paragraph: "The meaning of the attribute on SDP session level is undefined, MUST NOT be used by implementations of this specification and MUST be ignored if received on session level.” Convoluted sentence. I suggest something to the effect of: “The use of this attribute at the session level is undefined. Implementations of this specification MUST NOT use it at the session level and MUST ignore it if received at the session level.” — same paragraph: “ Extensions to this specification MAY define such session level usage.” That “MAY" seems more a statement of fact than permission. I suggest stating it without the normative keyword. — 6th paragraph: "In this case, it is not possible to align what alternative rid-id that are used across different simulcast streams, like requiring all simulcast streams to use rid-id alternatives referring to the same codec format.” I don’t understand the sentence. — 10th paragraph: The first sentence is hard to parse. §5.3.2, paragraph 3: “The answerer MUST be prepared to receive any of the receive direction rid-id alternatives, and MAY send any of the send direction alternatives that are kept in the answer.” I think from reading further that you intend “that are kept in the answer” to restrict both the alternatives one must be ready to receive and may choose to send. But the comma before “and MAY” makes it seem like it only restricts the alternatives the answerer can choose to send. Editorial and Nits: §1, last paragraph: Unclear antecedent for “it”. (The document is motivated?) §3.1, Codec: “… (such as SDP MIME type) …”: Should that be SDP payload MIME type? (We aren’t talking about application/sdp, are we) - Bitrate: s/amount/number §3.3: I want to say s/ “ preferences to “ / “ preferences for”, but that seems wrong with “apply preferences”. So now I think there’s something awkward about the phrase “apply preference to the characteristics”. Does this mean the same as “state preferences for the characteristics”? §4, 5th paragraph (starting with “The RID mechanism, as defined…”: It would make things easier to understand if you moved this paragraph before most of the discussion that talks about rids. — 8th paragraph: "interpreted on a high level” s/on/at §5.2: — paragraph 9: Missing “the” before send. “part” seems like the wrong word choice, but I’m not sure what was intended, maybe “peer”? (Same for paragraph 10). — Paragraph 10: Please expand “ TMMBR/TMMBN” §6.1, 2nd paragraph: s/“may not”/“might not" |
2018-03-29
|
11 | Ben Campbell | Changed consensus to Yes from Unknown |
2018-03-29
|
11 | Ben Campbell | IESG state changed to AD Evaluation from Publication Requested |
2018-03-06
|
11 | Flemming Andreasen | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard. The title page shows the intended status as Standards Track, which is appropriate in liue of the general applicability of simulcast and the extension made to SDP. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. In some application scenarios it may be desirable to send multiple differently encoded versions of the same media source in different RTP streams. This is called simulcast. This document describes how to accomplish simulcast in RTP and how to signal it in SDP. The described solution uses an RTP/RTCP identification method to identify RTP streams belonging to the same media source, and makes an extension to SDP to relate those RTP streams as being different simulcast formats of that media source. The SDP extension consists of a new media level SDP attribute that expresses capability to send and/or receive simulcast RTP streams. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Nothing in particular. There has been a few different simulcast proposals in the past, however once this proposal was made and adopted by the WG, progress and consensus has been smooth. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? The document is part of the RTCWeb suite of specifications. There is currently one known partial implementation of the specification. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Flemming Andreasen is the Document Shepherd. Ben Campbell is the Responsible Area Director. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. I have reviewed -10 of the document in detail, which resulted in a few changes. I have also reviewed the current -11 version of the document. The document is ready to progress but needs one minor change in Section 3.1 (which can be handled in the next version of the document, but no later than Auth48): The reference to "SDP MIME type" should be changed to "encoding name". (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concerns. The document has generally seen good discussion and review in the WG. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. N/A (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No such concerns (except the change to Section 3.1. noted above). (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Each author has confirmed. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. An IPR disclosure has been filed. The WG was alerted to the disclore early on (March 20, 2015) and was asked for any concerns related to it. None were raised then or subsequently. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is solid consensus in the WG. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) N/A (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. No significant nits. There are a couple of mechanical warnings that will be rectified as part of the publication process. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. N/A (13) Have all references within this document been identified as either normative or informative? Yes (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? There are several references to other Internet Drafts, however all of those drafts have been submitted for Publication Request and are progressing (or are simply in MISSREF state) (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. N/A (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. N/A (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). The IANA considerations have been reviewed and are consistent with the body of the document. A single SDP extension is defined. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. N/A (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. ABNF has been verified with Bill Fenner's ABNF parser. |
2018-03-06
|
11 | Flemming Andreasen | Responsible AD changed to Ben Campbell |
2018-03-06
|
11 | Flemming Andreasen | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2018-03-06
|
11 | Flemming Andreasen | IESG state changed to Publication Requested |
2018-03-06
|
11 | Flemming Andreasen | IESG process started in state Publication Requested |
2018-03-06
|
11 | Flemming Andreasen | Tag Revised I-D Needed - Issue raised by WGLC cleared. |
2018-03-06
|
11 | Flemming Andreasen | Changed document writeup |
2017-12-20
|
11 | Bo Burman | New version available: draft-ietf-mmusic-sdp-simulcast-11.txt |
2017-12-20
|
11 | (System) | New version approved |
2017-12-20
|
11 | (System) | Request for posting confirmation emailed to previous authors: Bo Burman , Mo Zanaty , Suhas Nandakumar , Magnus Westerlund |
2017-12-20
|
11 | Bo Burman | Uploaded new revision |
2017-11-02
|
10 | Flemming Andreasen | IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document |
2017-07-20
|
10 | Bo Burman | New version available: draft-ietf-mmusic-sdp-simulcast-10.txt |
2017-07-20
|
10 | (System) | New version approved |
2017-07-20
|
10 | (System) | Request for posting confirmation emailed to previous authors: Bo Burman , Mo Zanaty , Suhas Nandakumar , Magnus Westerlund |
2017-07-20
|
10 | Bo Burman | Uploaded new revision |
2017-07-03
|
09 | Bo Burman | New version available: draft-ietf-mmusic-sdp-simulcast-09.txt |
2017-07-03
|
09 | (System) | New version approved |
2017-07-03
|
09 | (System) | Request for posting confirmation emailed to previous authors: Bo Burman , Mo Zanaty , Suhas Nandakumar , Magnus Westerlund |
2017-07-03
|
09 | Bo Burman | Uploaded new revision |
2017-06-16
|
08 | Flemming Andreasen | Tag Revised I-D Needed - Issue raised by WGLC set. |
2017-06-16
|
08 | Flemming Andreasen | IETF WG state changed to WG Document from In WG Last Call |
2017-03-13
|
08 | Bo Burman | New version available: draft-ietf-mmusic-sdp-simulcast-08.txt |
2017-03-13
|
08 | (System) | New version approved |
2017-03-13
|
08 | (System) | Request for posting confirmation emailed to previous authors: Bo Burman , Mo Zanaty , Suhas Nandakumar , Magnus Westerlund |
2017-03-13
|
08 | Bo Burman | Uploaded new revision |
2017-01-31
|
07 | Magnus Westerlund | New version available: draft-ietf-mmusic-sdp-simulcast-07.txt |
2017-01-31
|
07 | (System) | New version approved |
2017-01-31
|
07 | (System) | Request for posting confirmation emailed to previous authors: "Suhas Nandakumar" , "Bo Burman" , "Mo Zanaty" , "Magnus Westerlund" |
2017-01-31
|
07 | Magnus Westerlund | Uploaded new revision |
2016-10-31
|
06 | Bo Burman | New version available: draft-ietf-mmusic-sdp-simulcast-06.txt |
2016-10-31
|
06 | (System) | New version approved |
2016-10-31
|
05 | (System) | Request for posting confirmation emailed to previous authors: "Suhas Nandakumar" , "Bo Burman" , "Mo Zanaty" , "Magnus Westerlund" |
2016-10-31
|
05 | Bo Burman | Uploaded new revision |
2016-07-07
|
05 | Flemming Andreasen | IETF WG state changed to In WG Last Call from WG Document |
2016-06-28
|
05 | Bo Burman | New version available: draft-ietf-mmusic-sdp-simulcast-05.txt |
2016-02-03
|
04 | Bo Burman | New version available: draft-ietf-mmusic-sdp-simulcast-04.txt |
2015-10-19
|
03 | Magnus Westerlund | New version available: draft-ietf-mmusic-sdp-simulcast-03.txt |
2015-10-16
|
02 | Flemming Andreasen | Intended Status changed to Proposed Standard from None |
2015-10-14
|
02 | (System) | Notify list changed from "Flemming Andreasen" to (None) |
2015-10-06
|
02 | Bo Burman | New version available: draft-ietf-mmusic-sdp-simulcast-02.txt |
2015-07-21
|
01 | Bo Burman | New version available: draft-ietf-mmusic-sdp-simulcast-01.txt |
2015-02-09
|
Naveen Khan | Posted related IPR disclosure: Microsoft Technology Licensing, LLC.'s Statement about IPR related to draft-ietf-mmusic-sdp-simulcast | |
2015-02-06
|
00 | Ari Keränen | Notification list changed to "Flemming Andreasen" <fandreas@cisco.com> |
2015-02-06
|
00 | Ari Keränen | Document shepherd changed to Flemming Andreasen |
2015-01-22
|
00 | Ari Keränen | This document now replaces draft-burman-mmusic-sdp-simulcast instead of None |
2015-01-20
|
00 | Bo Burman | New version available: draft-ietf-mmusic-sdp-simulcast-00.txt |