| draft-ietf-mmusic-data-channel-sdpneg-14.txt | draft-ietf-mmusic-data-channel-sdpneg-15.txt | |||
|---|---|---|---|---|
| MMUSIC K. Drage | MMUSIC K. Drage | |||
| Internet-Draft Unaffiliated | Internet-Draft Unaffiliated | |||
| Intended status: Standards Track M. Makaraju | Intended status: Standards Track M. Makaraju | |||
| Expires: June 6, 2018 Nokia | Expires: June 7, 2018 Nokia | |||
| J. Stoetzer-Bradler | J. Stoetzer-Bradler | |||
| R. Ejzak | R. Ejzak | |||
| J. Marcon | J. Marcon | |||
| Unaffiliated | Unaffiliated | |||
| R. Even, Ed. | R. Even, Ed. | |||
| Huawei | Huawei | |||
| December 3, 2017 | December 4, 2017 | |||
| SDP-based Data Channel Negotiation | SDP-based Data Channel Negotiation | |||
| draft-ietf-mmusic-data-channel-sdpneg-14 | draft-ietf-mmusic-data-channel-sdpneg-15 | |||
| Abstract | Abstract | |||
| The Real-Time Communication in WEB-browsers (RTCWeb) working group is | The Real-Time Communication in WEB-browsers (RTCWeb) working group is | |||
| charged to provide protocols to support direct interactive rich | charged to provide protocols to support direct interactive rich | |||
| communications using audio, video, and data between two peers' web- | communications using audio, video, and data between two peers' web- | |||
| browsers. For the support of data communication, the RTCWeb working | browsers. For the support of data communication, the RTCWeb working | |||
| group has in particular defined the concept of bi-directional data | group has in particular defined the concept of bi-directional data | |||
| channels over SCTP (Stream Control Transmission Protocol), where each | channels over SCTP (Stream Control Transmission Protocol), where each | |||
| data channel might be used to transport other protocols, called | data channel might be used to transport other protocols, called | |||
| skipping to change at page 2, line 7 ¶ | skipping to change at page 2, line 7 ¶ | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on June 6, 2018. | This Internet-Draft will expire on June 7, 2018. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2017 IETF Trust and the persons identified as the | Copyright (c) 2017 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
| (https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
| publication of this document. Please review these documents | publication of this document. Please review these documents | |||
| skipping to change at page 2, line 51 ¶ | skipping to change at page 2, line 51 ¶ | |||
| 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 | |||
| 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 | |||
| 8.1. Subprotocol Identifiers . . . . . . . . . . . . . . . . . 21 | 8.1. Subprotocol Identifiers . . . . . . . . . . . . . . . . . 21 | |||
| 8.2. New SDP Attributes . . . . . . . . . . . . . . . . . . . 21 | 8.2. New SDP Attributes . . . . . . . . . . . . . . . . . . . 21 | |||
| 8.2.1. dcmap . . . . . . . . . . . . . . . . . . . . . . . . 21 | 8.2.1. dcmap . . . . . . . . . . . . . . . . . . . . . . . . 21 | |||
| 8.2.2. dcsa . . . . . . . . . . . . . . . . . . . . . . . . 22 | 8.2.2. dcsa . . . . . . . . . . . . . . . . . . . . . . . . 22 | |||
| 8.3. New Usage Level . . . . . . . . . . . . . . . . . . . . . 22 | 8.3. New Usage Level . . . . . . . . . . . . . . . . . . . . . 22 | |||
| 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 | 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 | |||
| 10. CHANGE LOG . . . . . . . . . . . . . . . . . . . . . . . . . 23 | 10. CHANGE LOG . . . . . . . . . . . . . . . . . . . . . . . . . 23 | |||
| 10.1. Changes against 'draft-ietf-mmusic-data-channel- | 10.1. Changes against 'draft-ietf-mmusic-data-channel- | |||
| sdpneg-12' . . . . . . . . . . . . . . . . . . . . . . . 23 | sdpneg-14' . . . . . . . . . . . . . . . . . . . . . . . 23 | |||
| 10.2. Changes against 'draft-ietf-mmusic-data-channel- | 10.2. Changes against 'draft-ietf-mmusic-data-channel- | |||
| sdpneg-11' . . . . . . . . . . . . . . . . . . . . . . . 23 | sdpneg-12' . . . . . . . . . . . . . . . . . . . . . . . 23 | |||
| 10.3. Changes against 'draft-ietf-mmusic-data-channel- | 10.3. Changes against 'draft-ietf-mmusic-data-channel- | |||
| sdpneg-10' . . . . . . . . . . . . . . . . . . . . . . . 23 | sdpneg-11' . . . . . . . . . . . . . . . . . . . . . . . 23 | |||
| 10.4. Changes against 'draft-ietf-mmusic-data-channel- | 10.4. Changes against 'draft-ietf-mmusic-data-channel- | |||
| sdpneg-09' . . . . . . . . . . . . . . . . . . . . . . . 23 | sdpneg-10' . . . . . . . . . . . . . . . . . . . . . . . 24 | |||
| 10.5. Changes against 'draft-ietf-mmusic-data-channel- | 10.5. Changes against 'draft-ietf-mmusic-data-channel- | |||
| sdpneg-08' . . . . . . . . . . . . . . . . . . . . . . . 24 | sdpneg-09' . . . . . . . . . . . . . . . . . . . . . . . 24 | |||
| 10.6. Changes against 'draft-ietf-mmusic-data-channel- | 10.6. Changes against 'draft-ietf-mmusic-data-channel- | |||
| sdpneg-07' . . . . . . . . . . . . . . . . . . . . . . . 25 | sdpneg-08' . . . . . . . . . . . . . . . . . . . . . . . 25 | |||
| 10.7. Changes against 'draft-ietf-mmusic-data-channel- | 10.7. Changes against 'draft-ietf-mmusic-data-channel- | |||
| sdpneg-06' . . . . . . . . . . . . . . . . . . . . . . . 25 | sdpneg-07' . . . . . . . . . . . . . . . . . . . . . . . 25 | |||
| 10.8. Changes against 'draft-ietf-mmusic-data-channel- | 10.8. Changes against 'draft-ietf-mmusic-data-channel- | |||
| sdpneg-05' . . . . . . . . . . . . . . . . . . . . . . . 25 | sdpneg-06' . . . . . . . . . . . . . . . . . . . . . . . 25 | |||
| 10.9. Changes against 'draft-ietf-mmusic-data-channel- | 10.9. Changes against 'draft-ietf-mmusic-data-channel- | |||
| sdpneg-04' . . . . . . . . . . . . . . . . . . . . . . . 26 | sdpneg-05' . . . . . . . . . . . . . . . . . . . . . . . 25 | |||
| 10.10. Changes against 'draft-ietf-mmusic-data-channel- | 10.10. Changes against 'draft-ietf-mmusic-data-channel- | |||
| sdpneg-03' . . . . . . . . . . . . . . . . . . . . . . . 27 | sdpneg-04' . . . . . . . . . . . . . . . . . . . . . . . 26 | |||
| 10.11. Changes against 'draft-ietf-mmusic-data-channel- | 10.11. Changes against 'draft-ietf-mmusic-data-channel- | |||
| sdpneg-02' . . . . . . . . . . . . . . . . . . . . . . . 28 | sdpneg-03' . . . . . . . . . . . . . . . . . . . . . . . 27 | |||
| 10.12. Changes against 'draft-ietf-mmusic-data-channel- | 10.12. Changes against 'draft-ietf-mmusic-data-channel- | |||
| sdpneg-01' . . . . . . . . . . . . . . . . . . . . . . . 29 | sdpneg-02' . . . . . . . . . . . . . . . . . . . . . . . 28 | |||
| 10.13. Changes against 'draft-ietf-mmusic-data-channel- | 10.13. Changes against 'draft-ietf-mmusic-data-channel- | |||
| sdpneg-01' . . . . . . . . . . . . . . . . . . . . . . . 29 | ||||
| 10.14. Changes against 'draft-ietf-mmusic-data-channel- | ||||
| sdpneg-00' . . . . . . . . . . . . . . . . . . . . . . . 31 | sdpneg-00' . . . . . . . . . . . . . . . . . . . . . . . 31 | |||
| 10.14. Changes against 'draft-ejzak-mmusic-data-channel- | 10.15. Changes against 'draft-ejzak-mmusic-data-channel- | |||
| sdpneg-02' . . . . . . . . . . . . . . . . . . . . . . . 34 | sdpneg-02' . . . . . . . . . . . . . . . . . . . . . . . 34 | |||
| 10.15. Changes against '-01' . . . . . . . . . . . . . . . . . 35 | 10.16. Changes against '-01' . . . . . . . . . . . . . . . . . 35 | |||
| 10.16. Changes against '-00' . . . . . . . . . . . . . . . . . 35 | 10.17. Changes against '-00' . . . . . . . . . . . . . . . . . 35 | |||
| 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 | |||
| 11.1. Normative References . . . . . . . . . . . . . . . . . . 36 | 11.1. Normative References . . . . . . . . . . . . . . . . . . 36 | |||
| 11.2. Informative References . . . . . . . . . . . . . . . . . 37 | 11.2. Informative References . . . . . . . . . . . . . . . . . 37 | |||
| Appendix A. Generic Data Channel Negotiation Aspects When Not | Appendix A. Generic Data Channel Negotiation Aspects When Not | |||
| Using DCEP . . . . . . . . . . . . . . . . . . . . . 37 | Using DCEP . . . . . . . . . . . . . . . . . . . . . 37 | |||
| A.1. Stream Identifier Numbering . . . . . . . . . . . . . . . 38 | A.1. Stream Identifier Numbering . . . . . . . . . . . . . . . 38 | |||
| A.2. Generic Data Channel Negotiation Not Using DCEP . . . . . 39 | A.2. Generic Data Channel Negotiation Not Using DCEP . . . . . 39 | |||
| A.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . 39 | A.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . 39 | |||
| A.2.2. Opening a Data Channel . . . . . . . . . . . . . . . 39 | A.2.2. Opening a Data Channel . . . . . . . . . . . . . . . 39 | |||
| A.2.3. Closing a Data Channel . . . . . . . . . . . . . . . 40 | A.2.3. Closing a Data Channel . . . . . . . . . . . . . . . 40 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 | |||
| skipping to change at page 18, line 36 ¶ | skipping to change at page 18, line 36 ¶ | |||
| SDP offer: | SDP offer: | |||
| m=application 10001 UDP/DTLS/SCTP webrtc-datachannel | m=application 10001 UDP/DTLS/SCTP webrtc-datachannel | |||
| c=IN IP4 192.0.2.1 | c=IN IP4 192.0.2.1 | |||
| a=max-message-size:100000 | a=max-message-size:100000 | |||
| a=sctp-port:5000 | a=sctp-port:5000 | |||
| a=setup:actpass | a=setup:actpass | |||
| a=fingerprint:SHA-1 \ | a=fingerprint:SHA-1 \ | |||
| 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB | 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB | |||
| a=dtls-id:4a7565 | a=tls-id:abc3de65cddef001be82 | |||
| a=dcmap:0 subprotocol="BFCP";label="BFCP" | a=dcmap:0 subprotocol="BFCP";label="BFCP" | |||
| SDP answer: | SDP answer: | |||
| m=application 10002 UDP/DTLS/SCTP webrtc-datachannel | m=application 10002 UDP/DTLS/SCTP webrtc-datachannel | |||
| c=IN IP4 192.0.2.2 | c=IN IP4 192.0.2.2 | |||
| a=max-message-size:100000 | a=max-message-size:100000 | |||
| a=sctp-port:5002 | a=sctp-port:5002 | |||
| a=setup:passive | a=setup:passive | |||
| a=fingerprint:SHA-1 \ | a=fingerprint:SHA-1 \ | |||
| 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA | 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA | |||
| a=dtls-id:532d42 | a=tls-id:dcb3ae65cddef0532d42 | |||
| Figure 1: Example 1 | Figure 1: Example 1 | |||
| In the above example the SDP answerer rejected the data channel with | In the above example the SDP answerer rejected the data channel with | |||
| stream id 0 either for explicit reasons or because it does not | stream id 0 either for explicit reasons or because it does not | |||
| understand the "a=dcmap:" attribute. As a result the offerer will | understand the "a=dcmap:" attribute. As a result the offerer will | |||
| close the data channel created with the SDP offer/answer negotiation | close the data channel created with the SDP offer/answer negotiation | |||
| option. The SCTP association will still be setup over DTLS. At this | option. The SCTP association will still be setup over DTLS. At this | |||
| point the offerer or the answerer may use DCEP negotiation to open | point the offerer or the answerer may use DCEP negotiation to open | |||
| data channels. | data channels. | |||
| SDP offer: | SDP offer: | |||
| m=application 10001 UDP/DTLS/SCTP webrtc-datachannel | m=application 10001 UDP/DTLS/SCTP webrtc-datachannel | |||
| c=IN IP4 192.0.2.1 | c=IN IP4 192.0.2.1 | |||
| a=max-message-size:100000 | a=max-message-size:100000 | |||
| a=sctp-port:5000 | a=sctp-port:5000 | |||
| a=setup:actpass | a=setup:actpass | |||
| a=fingerprint:SHA-1 \ | a=fingerprint:SHA-1 \ | |||
| 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB | 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB | |||
| a=dtls-id:4a7565 | a=tls-id:abc3de65cddef001be82 | |||
| a=dcmap:0 subprotocol="BFCP";label="BFCP" | a=dcmap:0 subprotocol="BFCP";label="BFCP" | |||
| a=dcmap:2 subprotocol="MSRP";label="MSRP" | a=dcmap:2 subprotocol="MSRP";label="MSRP" | |||
| a=dcsa:2 accept-types:message/cpim text/plain | a=dcsa:2 accept-types:message/cpim text/plain | |||
| a=dcsa:2 path:msrp://alice.example.com:10001/2s93i93idj;dc | a=dcsa:2 path:msrp://alice.example.com:10001/2s93i93idj;dc | |||
| SDP answer: | SDP answer: | |||
| m=application 10002 UDP/DTLS/SCTP webrtc-datachannel | m=application 10002 UDP/DTLS/SCTP webrtc-datachannel | |||
| c=IN IP4 192.0.2.2 | c=IN IP4 192.0.2.2 | |||
| a=max-message-size:100000 | a=max-message-size:100000 | |||
| a=sctp-port:5002 | a=sctp-port:5002 | |||
| a=setup:passive | a=setup:passive | |||
| a=fingerprint:SHA-1 \ | a=fingerprint:SHA-1 \ | |||
| 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA | 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA | |||
| a=dtls-id:532d42 | a=tls-id:dcb3ae65cddef0532d42 | |||
| a=dcmap:2 subprotocol="MSRP";label="MSRP" | a=dcmap:2 subprotocol="MSRP";label="MSRP" | |||
| a=dcsa:2 accept-types:message/cpim text/plain | a=dcsa:2 accept-types:message/cpim text/plain | |||
| a=dcsa:2 path:msrp://bob.example.com:10002/si438dsaodes;dc | a=dcsa:2 path:msrp://bob.example.com:10002/si438dsaodes;dc | |||
| Figure 2: Example 2 | Figure 2: Example 2 | |||
| In the above example the SDP offer contains data channels for BFCP | In the above example the SDP offer contains data channels for BFCP | |||
| (Binary Floor Control Protocol) and MSRP subprotocols. The SDP | (Binary Floor Control Protocol) and MSRP subprotocols. The SDP | |||
| answer rejected BFCP and accepted MSRP. So, the offerer closes the | answer rejected BFCP and accepted MSRP. So, the offerer closes the | |||
| data channel for BFCP and both offerer and answerer may start using | data channel for BFCP and both offerer and answerer may start using | |||
| skipping to change at page 20, line 14 ¶ | skipping to change at page 20, line 14 ¶ | |||
| Subsequent SDP offer: | Subsequent SDP offer: | |||
| m=application 10001 UDP/DTLS/SCTP webrtc-datachannel | m=application 10001 UDP/DTLS/SCTP webrtc-datachannel | |||
| c=IN IP4 192.0.2.1 | c=IN IP4 192.0.2.1 | |||
| a=max-message-size:100000 | a=max-message-size:100000 | |||
| a=sctp-port:5000 | a=sctp-port:5000 | |||
| a=setup:actpass | a=setup:actpass | |||
| a=fingerprint:SHA-1 \ | a=fingerprint:SHA-1 \ | |||
| 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB | 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB | |||
| a=dtls-id:4a7565 | a=tls-id:abc3de65cddef001be82 | |||
| a=dcmap:4 subprotocol="MSRP";label="MSRP" | a=dcmap:4 subprotocol="MSRP";label="MSRP" | |||
| a=dcsa:4 accept-types:message/cpim text/plain | a=dcsa:4 accept-types:message/cpim text/plain | |||
| a=dcsa:4 path:msrp://alice.example.com:10001/2s93i93idj;dc | a=dcsa:4 path:msrp://alice.example.com:10001/2s93i93idj;dc | |||
| Subsequent SDP answer: | Subsequent SDP answer: | |||
| m=application 10002 UDP/DTLS/SCTP webrtc-datachannel | m=application 10002 UDP/DTLS/SCTP webrtc-datachannel | |||
| c=IN IP4 192.0.2.2 | c=IN IP4 192.0.2.2 | |||
| a=max-message-size:100000 | a=max-message-size:100000 | |||
| a=sctp-port:5002 | a=sctp-port:5002 | |||
| a=setup:passive | a=setup:passive | |||
| a=fingerprint:SHA-1 \ | a=fingerprint:SHA-1 \ | |||
| 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA | 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA | |||
| a=dtls-id:532d42 | a=tls-id:dcb3ae65cddef0532d42 | |||
| a=dcmap:4 subprotocol="MSRP";label="MSRP" | a=dcmap:4 subprotocol="MSRP";label="MSRP" | |||
| a=dcsa:4 accept-types:message/cpim text/plain | a=dcsa:4 accept-types:message/cpim text/plain | |||
| a=dcsa:4 path:msrp://bob.example.com:10002/si438dsaodes;dc | a=dcsa:4 path:msrp://bob.example.com:10002/si438dsaodes;dc | |||
| Figure 3: Example 3 | Figure 3: Example 3 | |||
| The above example is a continuation of the example in Figure 2. The | The above example is a continuation of the example in Figure 2. The | |||
| SDP offerer now removes the MSRP data channel with stream id 2, but | SDP offerer now removes the MSRP data channel with stream id 2, but | |||
| opens a new MSRP data channel with stream id 4. The answerer accepts | opens a new MSRP data channel with stream id 4. The answerer accepts | |||
| the entire offer. As a result the offerer closes the earlier | the entire offer. As a result the offerer closes the earlier | |||
| skipping to change at page 23, line 25 ¶ | skipping to change at page 23, line 25 ¶ | |||
| The authors wish to acknowledge the borrowing of ideas from other | The authors wish to acknowledge the borrowing of ideas from other | |||
| internet drafts by Salvatore Loreto, Gonzalo Camarillo, Peter Dunkley | internet drafts by Salvatore Loreto, Gonzalo Camarillo, Peter Dunkley | |||
| and Gavin Llewellyn, and to thank Flemming Andreasen, Roni Even, | and Gavin Llewellyn, and to thank Flemming Andreasen, Roni Even, | |||
| Christian Groves, Gunnar Hellstrom, Christer Holmberg, Paul Kyzivat, | Christian Groves, Gunnar Hellstrom, Christer Holmberg, Paul Kyzivat, | |||
| Jonathan Lennox, Uwe Rauschenbach and Roman Shpount for their | Jonathan Lennox, Uwe Rauschenbach and Roman Shpount for their | |||
| invaluable comments. | invaluable comments. | |||
| 10. CHANGE LOG | 10. CHANGE LOG | |||
| 10.1. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-12' | 10.1. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-14' | |||
| o Change "dtls-id" to "tls-id" and assign 20 octet long values | ||||
| o Remove of RFC4566bis draft from list of normative references. | ||||
| 10.2. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-12' | ||||
| o Modification of Keith's address information. | o Modification of Keith's address information. | |||
| 10.2. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-11' | 10.3. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-11' | |||
| o dcmap-stream-id syntax change to limit size to 5 digits. | o dcmap-stream-id syntax change to limit size to 5 digits. | |||
| o Add missing 'x' prefix to quoted-visible syntax. | o Add missing 'x' prefix to quoted-visible syntax. | |||
| o Align SDP offerer and answerer handling when both max-retr and | o Align SDP offerer and answerer handling when both max-retr and | |||
| max-time are present. | max-time are present. | |||
| o Use of TEST-NET-1 ip addresses in examples. | o Use of TEST-NET-1 ip addresses in examples. | |||
| o Add missing a=dtls-id in one example. | o Add missing a=dtls-id in one example. | |||
| 10.3. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-10' | 10.4. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-10' | |||
| o Removal of the "a=connection" attribute lines from all SDP | o Removal of the "a=connection" attribute lines from all SDP | |||
| examples. | examples. | |||
| 10.4. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-09' | 10.5. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-09' | |||
| o In the introduction: | o In the introduction: | |||
| * Replacement of the sentence "The RTCWeb working group has | * Replacement of the sentence "The RTCWeb working group has | |||
| defined the concept of bi-directional data channels running on | defined the concept of bi-directional data channels running on | |||
| top of SCTP/DTLS (SCTP over the Datagram Transport Layer | top of SCTP/DTLS (SCTP over the Datagram Transport Layer | |||
| Security protocol)" with "The RTCWeb working group has defined | Security protocol)" with "The RTCWeb working group has defined | |||
| the concept of bi-directional data channels running on top of | the concept of bi-directional data channels running on top of | |||
| the Stream Control Transmission Protocol (SCTP)". | the Stream Control Transmission Protocol (SCTP)". | |||
| skipping to change at page 24, line 42 ¶ | skipping to change at page 25, line 5 ¶ | |||
| o In the text after the second SDP answer in section Section 6 | o In the text after the second SDP answer in section Section 6 | |||
| replacement of "... (after SCTP/DTLS association is setup)" with | replacement of "... (after SCTP/DTLS association is setup)" with | |||
| "... (after the SCTP association is set up)". | "... (after the SCTP association is set up)". | |||
| o Addition of [I-D.ietf-mmusic-dtls-sdp] to the list of informative | o Addition of [I-D.ietf-mmusic-dtls-sdp] to the list of informative | |||
| references. | references. | |||
| o Addition of "a=dtls-id" attribute lines to the SDP offer/answer | o Addition of "a=dtls-id" attribute lines to the SDP offer/answer | |||
| examples in Section 6. | examples in Section 6. | |||
| 10.5. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-08' | 10.6. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-08' | |||
| o Addition of definition of "data channel subprotocol" to Section 3 | o Addition of definition of "data channel subprotocol" to Section 3 | |||
| as proposed on the MMUSIC list, https://www.ietf.org/mail- | as proposed on the MMUSIC list, https://www.ietf.org/mail- | |||
| archive/web/mmusic/current/msg15827.html. | archive/web/mmusic/current/msg15827.html. | |||
| o Addition of [I-D.ietf-mmusic-rfc4566bis] to list of normative | o Addition of RFC4566bis draft to list of normative references. | |||
| references. | ||||
| o Updates of tables in Section 8.2.1 and Section 8.2.2 as per | o Updates of tables in Section 8.2.1 and Section 8.2.2 as per | |||
| section 8.2.4 of [I-D.ietf-mmusic-rfc4566bis]. | section 8.2.4 of RFC4566bis draft. | |||
| o Addition of new Section 8.3. | o Addition of new Section 8.3. | |||
| 10.6. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-07' | 10.7. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-07' | |||
| o Addition of two new paragraphs to Section 5.1.2.1 regarding | o Addition of two new paragraphs to Section 5.1.2.1 regarding | |||
| subprotocol attribute relationship with transport protocol. | subprotocol attribute relationship with transport protocol. | |||
| o Addition of a note to Section 8.1 regarding subprotocols | o Addition of a note to Section 8.1 regarding subprotocols | |||
| simultaneously defined for data channel and Websocket usage. | simultaneously defined for data channel and Websocket usage. | |||
| o Addition of two further SDP offer/answer considerations to | o Addition of two further SDP offer/answer considerations to | |||
| Section 5.2.5 regarding unknown subprotocol attributes and known | Section 5.2.5 regarding unknown subprotocol attributes and known | |||
| subprotocol attributes with unknown data channel transport related | subprotocol attributes with unknown data channel transport related | |||
| semantic. | semantic. | |||
| 10.7. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-06' | 10.8. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-06' | |||
| o Changes addressing Christian Groves's WGLC review comments raised | o Changes addressing Christian Groves's WGLC review comments raised | |||
| in http://www.ietf.org/mail-archive/web/mmusic/current/ | in http://www.ietf.org/mail-archive/web/mmusic/current/ | |||
| msg15357.html and http://www.ietf.org/mail- | msg15357.html and http://www.ietf.org/mail- | |||
| archive/web/mmusic/current/msg15359.html. | archive/web/mmusic/current/msg15359.html. | |||
| 10.8. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-05' | 10.9. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-05' | |||
| o In IANA registration Section 8.2.1 and Section 8.2.2 replacement | o In IANA registration Section 8.2.1 and Section 8.2.2 replacement | |||
| of contact name and e-mail address with "MMUSIC Chairs" and | of contact name and e-mail address with "MMUSIC Chairs" and | |||
| "mmusic-chairs@ietf.org". | "mmusic-chairs@ietf.org". | |||
| o In Section 5.1.2.1 replacement of "Thus in the example above, the | o In Section 5.1.2.1 replacement of "Thus in the example above, the | |||
| original attribute line "a=accept- types:text/plain" is | original attribute line "a=accept- types:text/plain" is | |||
| represented by the attribute line "a=dcsa:2 accept-types:text/ | represented by the attribute line "a=dcsa:2 accept-types:text/ | |||
| plain", which specifies that this instance of MSRP being | plain", which specifies that this instance of MSRP being | |||
| transported on the SCTP association using the data channel with | transported on the SCTP association using the data channel with | |||
| skipping to change at page 26, line 16 ¶ | skipping to change at page 26, line 28 ¶ | |||
| o Move of the last but one paragraph of Section 5.1.2.1 starting | o Move of the last but one paragraph of Section 5.1.2.1 starting | |||
| with "The same syntax applies to ..." right in front of the formal | with "The same syntax applies to ..." right in front of the formal | |||
| syntax definition of the "dcsa" attribute. | syntax definition of the "dcsa" attribute. | |||
| o Modifications of the text in Section 5.1.1.2 and Section 5.1.2.2 | o Modifications of the text in Section 5.1.1.2 and Section 5.1.2.2 | |||
| in order not to explicitly restrict usage of the "a=dcmap:" and | in order not to explicitly restrict usage of the "a=dcmap:" and | |||
| "a=dcsa:" attributes to "m" lines with proto values "UDP/DTLS/ | "a=dcsa:" attributes to "m" lines with proto values "UDP/DTLS/ | |||
| SCTP" or "TCP/DTLS/SCTP". | SCTP" or "TCP/DTLS/SCTP". | |||
| 10.9. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-04' | 10.10. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-04' | |||
| o In Section 5.1.1.5 the first (and only) paragraph was "The | o In Section 5.1.1.5 the first (and only) paragraph was "The | |||
| 'subprotocol' parameter indicates which protocol the client | 'subprotocol' parameter indicates which protocol the client | |||
| expects to exchange via the channel. 'Subprotocol' is an optional | expects to exchange via the channel. 'Subprotocol' is an optional | |||
| parameter. If the 'subprotocol' parameter is not present, then | parameter. If the 'subprotocol' parameter is not present, then | |||
| its value defaults to the empty string." Replacement of this | its value defaults to the empty string." Replacement of this | |||
| paragraph with following two paragraphs: | paragraph with following two paragraphs: | |||
| * The 'subprotocol' parameter indicates which protocol the client | * The 'subprotocol' parameter indicates which protocol the client | |||
| expects to exchange via the channel. This parameter maps to | expects to exchange via the channel. This parameter maps to | |||
| skipping to change at page 27, line 10 ¶ | skipping to change at page 27, line 20 ¶ | |||
| o Addition of new Section 5.1.1.2 describing the mux category of the | o Addition of new Section 5.1.1.2 describing the mux category of the | |||
| dcmap SDP attribute. This section and the new "a=dcsa:" attribute | dcmap SDP attribute. This section and the new "a=dcsa:" attribute | |||
| related mux category section are similar to the "Mux Category" | related mux category section are similar to the "Mux Category" | |||
| sections of the "a=sctp-port:" and "a=max-message-size:" | sections of the "a=sctp-port:" and "a=max-message-size:" | |||
| attributes in [I-D.ietf-mmusic-sctp-sdp]. | attributes in [I-D.ietf-mmusic-sctp-sdp]. | |||
| o Addition of new Section 5.1.2.2 describing the mux category of the | o Addition of new Section 5.1.2.2 describing the mux category of the | |||
| dcsa SDP attribute. | dcsa SDP attribute. | |||
| 10.10. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-03' | 10.11. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-03' | |||
| o In Section 1 replacement of "RTCWeb leaves it open for other | o In Section 1 replacement of "RTCWeb leaves it open for other | |||
| applications to use data channels and its in-band DCEP or out-of- | applications to use data channels and its in-band DCEP or out-of- | |||
| band non-DCEP protocols for creating them" with "... to use data | band non-DCEP protocols for creating them" with "... to use data | |||
| channels and its in-band DCEP or other in-band or out-of-band | channels and its in-band DCEP or other in-band or out-of-band | |||
| protocols for creating them". Additionally replacement of "In | protocols for creating them". Additionally replacement of "In | |||
| particular, the SDP offer generated by the application includes no | particular, the SDP offer generated by the application includes no | |||
| channel-specific information" with "... generated by the RTCweb | channel-specific information" with "... generated by the RTCweb | |||
| data channel stack includes no channel-specific information". | data channel stack includes no channel-specific information". | |||
| skipping to change at page 28, line 20 ¶ | skipping to change at page 28, line 30 ¶ | |||
| o In Section 5.2.1 replacement of "However, an SDP offer/answer | o In Section 5.2.1 replacement of "However, an SDP offer/answer | |||
| exchange MUST NOT be initiated if the associated SCTP stream is | exchange MUST NOT be initiated if the associated SCTP stream is | |||
| already negotiated via DCEP" with "However, an SCTP stream MUST | already negotiated via DCEP" with "However, an SCTP stream MUST | |||
| NOT be referenced in a dcmap or dcsa attribute of an SDP offer/ | NOT be referenced in a dcmap or dcsa attribute of an SDP offer/ | |||
| answer exchange if the associated SCTP stream has already been | answer exchange if the associated SCTP stream has already been | |||
| negotiated via DCEP". | negotiated via DCEP". | |||
| o In the examples in Section 6 addition of the previously missing | o In the examples in Section 6 addition of the previously missing | |||
| colons to the "a=sctp-port" attribute lines. | colons to the "a=sctp-port" attribute lines. | |||
| 10.11. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-02' | 10.12. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-02' | |||
| o Move of reference draft-ietf-rtcweb-jsep from the list of | o Move of reference draft-ietf-rtcweb-jsep from the list of | |||
| normative references to the list of informative references. | normative references to the list of informative references. | |||
| Remover in -07 since not referenced | Remover in -07 since not referenced | |||
| o Addition of [IANA-SDP-Parameters] to the list of informative | o Addition of [IANA-SDP-Parameters] to the list of informative | |||
| references and addition of following two sentences to the first | references and addition of following two sentences to the first | |||
| paragraph after the ABNF definition: "Note however that not all | paragraph after the ABNF definition: "Note however that not all | |||
| SDP attributes are suitable as "a=dcsa:" parameter. | SDP attributes are suitable as "a=dcsa:" parameter. | |||
| [IANA-SDP-Parameters] contains the lists of IANA registered | [IANA-SDP-Parameters] contains the lists of IANA registered | |||
| skipping to change at page 29, line 21 ¶ | skipping to change at page 29, line 35 ¶ | |||
| a=dcmap". | a=dcmap". | |||
| o Move of reference [WebRtcAPI] from list of normative references to | o Move of reference [WebRtcAPI] from list of normative references to | |||
| list of informative references. | list of informative references. | |||
| o Removal of almost all text parts, which discussed JavaScript or | o Removal of almost all text parts, which discussed JavaScript or | |||
| other API specific aspects. Such API specific aspects were mainly | other API specific aspects. Such API specific aspects were mainly | |||
| discussed in sub-sections of Section 5 and Section 5 of draft- | discussed in sub-sections of Section 5 and Section 5 of draft- | |||
| ietf-mmusic-data-channel-sdpneg-02. | ietf-mmusic-data-channel-sdpneg-02. | |||
| 10.12. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-01' | 10.13. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-01' | |||
| o New Section 4 regarding applicability to SDP offer/answer only. | o New Section 4 regarding applicability to SDP offer/answer only. | |||
| o Addition of new Section 8.1 "Subprotocol identifiers" as | o Addition of new Section 8.1 "Subprotocol identifiers" as | |||
| subsection of the "IANA Considerations" related Section 8. Also | subsection of the "IANA Considerations" related Section 8. Also | |||
| removal of the temporary note "To be completed. As [I-D.ietf- | removal of the temporary note "To be completed. As [I-D.ietf- | |||
| rtcweb-data-protocol] this document should refer to IANA's | rtcweb-data-protocol] this document should refer to IANA's | |||
| WebSocket Subprotocol Name Registry defined in [RFC6455]" | WebSocket Subprotocol Name Registry defined in [RFC6455]" | |||
| o In Section 5.2.2: | o In Section 5.2.2: | |||
| skipping to change at page 31, line 29 ¶ | skipping to change at page 31, line 42 ¶ | |||
| * In the last but one paragraph replacement of "must" with "The | * In the last but one paragraph replacement of "must" with "The | |||
| application MUST also close...". | application MUST also close...". | |||
| o In Section 5.1.2 addition of following note after the formal | o In Section 5.1.2 addition of following note after the formal | |||
| definition of the 'a=dcsa' attribute: "Note that the above | definition of the 'a=dcsa' attribute: "Note that the above | |||
| reference to RFC 4566 defines were the attribute definition can be | reference to RFC 4566 defines were the attribute definition can be | |||
| found; it does not provide any limitation on support of attributes | found; it does not provide any limitation on support of attributes | |||
| defined in other documents in accordance with this attribute | defined in other documents in accordance with this attribute | |||
| definition." | definition." | |||
| 10.13. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-00' | 10.14. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-00' | |||
| o In Section 3 "WebRTC data channel" was defined as "A bidirectional | o In Section 3 "WebRTC data channel" was defined as "A bidirectional | |||
| channel consisting of paired SCTP outbound and inbound streams." | channel consisting of paired SCTP outbound and inbound streams." | |||
| Replacement of this definition with "Data channel: A WebRTC data | Replacement of this definition with "Data channel: A WebRTC data | |||
| channel as specified in [I-D.ietf-rtcweb-data-channel]", and | channel as specified in [I-D.ietf-rtcweb-data-channel]", and | |||
| consistent usage of "data channel" in the remainder of the | consistent usage of "data channel" in the remainder of the | |||
| document including the document's headline." | document including the document's headline." | |||
| o In Section 5 removal of following note: 'OPEN ISSUE: The syntax in | o In Section 5 removal of following note: 'OPEN ISSUE: The syntax in | |||
| [I-D.ietf-mmusic-sctp-sdp] may change as that document progresses. | [I-D.ietf-mmusic-sctp-sdp] may change as that document progresses. | |||
| skipping to change at page 34, line 14 ¶ | skipping to change at page 34, line 27 ¶ | |||
| to handle cases where a successful SDP answer is not received, in | to handle cases where a successful SDP answer is not received, in | |||
| which case the state of the session SHOULD be kept per the last | which case the state of the session SHOULD be kept per the last | |||
| successful SDP offer/answer." | successful SDP offer/answer." | |||
| o Although dedicated to "a=dcmap" and "a=dcsa" SDP syntax aspects | o Although dedicated to "a=dcmap" and "a=dcsa" SDP syntax aspects | |||
| Section 5.1.1 contained already procedural descriptions related to | Section 5.1.1 contained already procedural descriptions related to | |||
| data channel reliability negotiation. Creation of new | data channel reliability negotiation. Creation of new | |||
| Section 5.2.2 and moval of reliability negotiation related text to | Section 5.2.2 and moval of reliability negotiation related text to | |||
| this new section. | this new section. | |||
| 10.14. Changes against 'draft-ejzak-mmusic-data-channel-sdpneg-02' | 10.15. Changes against 'draft-ejzak-mmusic-data-channel-sdpneg-02' | |||
| o Removal of note "[ACTION ITEM]" from section "subprotocol | o Removal of note "[ACTION ITEM]" from section "subprotocol | |||
| parameter". As [I-D.ietf-rtcweb-data-protocol] this document | parameter". As [I-D.ietf-rtcweb-data-protocol] this document | |||
| should refer to IANA's WebSocket Subprotocol Name Registry defined | should refer to IANA's WebSocket Subprotocol Name Registry defined | |||
| in [RFC6455] | in [RFC6455] | |||
| o In whole document, replacement of "unreliable" with "partially | o In whole document, replacement of "unreliable" with "partially | |||
| reliable", which is used in [I-D.ietf-rtcweb-data-channel] and in | reliable", which is used in [I-D.ietf-rtcweb-data-channel] and in | |||
| [I-D.ietf-rtcweb-data-protocol] in most places. | [I-D.ietf-rtcweb-data-protocol] in most places. | |||
| skipping to change at page 35, line 16 ¶ | skipping to change at page 35, line 30 ¶ | |||
| o In the "Examples" section, in the first two SDP offer examples in | o In the "Examples" section, in the first two SDP offer examples in | |||
| the a=dcmap attribute lines 'label="BGCP"' was replaced with | the a=dcmap attribute lines 'label="BGCP"' was replaced with | |||
| 'label="BFCP"'. | 'label="BFCP"'. | |||
| o In all examples, the "m" line proto value "DTLS/SCTP" was replaced | o In all examples, the "m" line proto value "DTLS/SCTP" was replaced | |||
| with "UDP/DTLS/SCTP" and the "a=fmtp" attribute lines were | with "UDP/DTLS/SCTP" and the "a=fmtp" attribute lines were | |||
| replaced with "a=max-message-size" attribute lines, as per draft- | replaced with "a=max-message-size" attribute lines, as per draft- | |||
| ietf-mmusic-sctp-sdp-12. | ietf-mmusic-sctp-sdp-12. | |||
| 10.15. Changes against '-01' | 10.16. Changes against '-01' | |||
| o Formal syntax for dcmap and dcsa attribute lines. | o Formal syntax for dcmap and dcsa attribute lines. | |||
| o Making subprotocol as an optional parameter in dcmap. | o Making subprotocol as an optional parameter in dcmap. | |||
| o Specifying disallowed parameter combinations for max-time and max- | o Specifying disallowed parameter combinations for max-time and max- | |||
| retr. | retr. | |||
| o Clarifications on WebRTC data channel close procedures. | o Clarifications on WebRTC data channel close procedures. | |||
| 10.16. Changes against '-00' | 10.17. Changes against '-00' | |||
| o Revisions to identify difference between internal and external | o Revisions to identify difference between internal and external | |||
| negotiation and their usage. | negotiation and their usage. | |||
| o Introduction of more generic terminology, e.g. "application" | o Introduction of more generic terminology, e.g. "application" | |||
| instead of "browser". | instead of "browser". | |||
| o Clarification of how "max-retr and max-time affect the usage of | o Clarification of how "max-retr and max-time affect the usage of | |||
| unreliable and reliable WebRTC data channels. | unreliable and reliable WebRTC data channels. | |||
| o Updates of examples to take into account the SDP syntax changes | o Updates of examples to take into account the SDP syntax changes | |||
| introduced with draft-ietf-mmusic-sctp-sdp-07. | introduced with draft-ietf-mmusic-sctp-sdp-07. | |||
| o Removal of the SCTP port number from the a=dcmap and a=dcsa | o Removal of the SCTP port number from the a=dcmap and a=dcsa | |||
| attributes as this is now contained in the a=sctp-port attribute, | attributes as this is now contained in the a=sctp-port attribute, | |||
| and as draft-ietf-mmusic-sctp-sdp-07 supports only one SCTP | and as draft-ietf-mmusic-sctp-sdp-07 supports only one SCTP | |||
| association on top of the DTLS connection. | association on top of the DTLS connection. | |||
| 11. References | 11. References | |||
| 11.1. Normative References | ||||
| [I-D.ietf-mmusic-rfc4566bis] | 11.1. Normative References | |||
| Handley, M., Perkins, C., and A. Begen, "SDP: Session | ||||
| Description Protocol", draft-ietf-mmusic-rfc4566bis-24 | ||||
| (work in progress), October 2017. | ||||
| [I-D.ietf-mmusic-sctp-sdp] | [I-D.ietf-mmusic-sctp-sdp] | |||
| Holmberg, C., Shpount, R., Loreto, S., and G. Camarillo, | Holmberg, C., Shpount, R., Loreto, S., and G. Camarillo, | |||
| "Session Description Protocol (SDP) Offer/Answer | "Session Description Protocol (SDP) Offer/Answer | |||
| Procedures For Stream Control Transmission Protocol (SCTP) | Procedures For Stream Control Transmission Protocol (SCTP) | |||
| over Datagram Transport Layer Security (DTLS) Transport.", | over Datagram Transport Layer Security (DTLS) Transport.", | |||
| draft-ietf-mmusic-sctp-sdp-26 (work in progress), April | draft-ietf-mmusic-sctp-sdp-26 (work in progress), April | |||
| 2017. | 2017. | |||
| [I-D.ietf-mmusic-sdp-mux-attributes] | [I-D.ietf-mmusic-sdp-mux-attributes] | |||
| skipping to change at page 38, line 15 ¶ | skipping to change at page 38, line 15 ¶ | |||
| offer/answer protocol. | offer/answer protocol. | |||
| In any case, the SDP offer generated by the application is per | In any case, the SDP offer generated by the application is per | |||
| [I-D.ietf-mmusic-sctp-sdp]. In brief, it contains one "m" line for | [I-D.ietf-mmusic-sctp-sdp]. In brief, it contains one "m" line for | |||
| the SCTP association on top of which data channels will run: | the SCTP association on top of which data channels will run: | |||
| m=application 54111 UDP/DTLS/SCTP webrtc-datachannel | m=application 54111 UDP/DTLS/SCTP webrtc-datachannel | |||
| c=IN IP4 192.0.2.1 | c=IN IP4 192.0.2.1 | |||
| a=max-message-size:100000 | a=max-message-size:100000 | |||
| a=sctp-port:5000 | a=sctp-port:5000 | |||
| a=dtls-id:abcdef1234567 | a=tls-id:abc3de65cddef001be82 | |||
| a=setup:actpass | a=setup:actpass | |||
| a=fingerprint:SHA-1 \ | a=fingerprint:SHA-1 \ | |||
| 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB | 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB | |||
| Note: A WebRTC application will only use "m" line format "webrtc- | Note: A WebRTC application will only use "m" line format "webrtc- | |||
| datachannel", and will not use other formats in the "m" line for | datachannel", and will not use other formats in the "m" line for | |||
| other protocols such as t38. [I-D.ietf-mmusic-sctp-sdp] supports | other protocols such as t38. [I-D.ietf-mmusic-sctp-sdp] supports | |||
| only one SCTP association to be established on top of a DTLS | only one SCTP association to be established on top of a DTLS | |||
| association. | association. | |||
| End of changes. 46 change blocks. | ||||
| 51 lines changed or deleted | 54 lines changed or added | |||
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||