├── .gitignore ├── README.md ├── markdown ├── draft-ietf-ice-pac-03.md ├── draft-ietf-ice-trickle-21.md ├── draft-ietf-mmusic-ice-sip-sdp-39.md ├── draft-ietf-mmusic-msid-17.md ├── draft-ietf-mmusic-mux-exclusive-12.md ├── draft-ietf-mmusic-sdp-bundle-negotiation-54.md ├── draft-ietf-mmusic-sdp-mux-attributes-17.md ├── draft-ietf-rtcweb-data-channel-13.md ├── draft-ietf-rtcweb-ip-handling-12.md ├── draft-ietf-rtcweb-jsep-26.md ├── draft-ietf-rtcweb-mdns-ice-candidates-04.md ├── draft-ietf-rtcweb-overview-19.md ├── draft-ietf-rtcweb-rtp-usage-26.md ├── draft-ietf-rtcweb-sdp-11.md ├── draft-ietf-rtcweb-security-12.md ├── draft-ietf-rtcweb-transports-17.md ├── draft-roach-mmusic-unified-plan-00.md ├── draft-thatcher-ice-renomination-01.md ├── draft-uberti-rtcweb-turn-rest-00.md ├── rfc3264.md ├── rfc3605.md ├── rfc4145.md ├── rfc4556.md ├── rfc5389.md ├── rfc5506.md ├── rfc5576.md ├── rfc5761.md ├── rfc5763.md ├── rfc5764.md ├── rfc5888.md ├── rfc6347.md ├── rfc7064.md ├── rfc7478.md ├── rfc7675.md ├── rfc7742.md ├── rfc7874.md ├── rfc7983.md ├── rfc8122.md ├── rfc8421.md └── rfc8445.md ├── script ├── check-updates.js ├── init-markdown.js └── init-summary.js └── summary ├── draft-ietf-ice-pac-03.md ├── draft-ietf-ice-trickle-21.md ├── draft-ietf-mmusic-ice-sip-sdp-39.md ├── draft-ietf-mmusic-msid-17.md ├── draft-ietf-mmusic-mux-exclusive-12.md ├── draft-ietf-mmusic-sdp-bundle-negotiation-54.md ├── draft-ietf-mmusic-sdp-mux-attributes-17.md ├── draft-ietf-rtcweb-data-channel-13.md ├── draft-ietf-rtcweb-ip-handling-12.md ├── draft-ietf-rtcweb-jsep-26.md ├── draft-ietf-rtcweb-mdns-ice-candidates-04.md ├── draft-ietf-rtcweb-overview-19.md ├── draft-ietf-rtcweb-rtp-usage-26.md ├── draft-ietf-rtcweb-sdp-11.md ├── draft-ietf-rtcweb-security-12.md ├── draft-ietf-rtcweb-transports-17.md ├── draft-roach-mmusic-unified-plan-00.md ├── draft-thatcher-ice-renomination-01.md ├── draft-uberti-rtcweb-turn-rest-00.md ├── rfc3264.md ├── rfc3605.md ├── rfc4145.md ├── rfc4556.md ├── rfc5389.md ├── rfc5506.md ├── rfc5576.md ├── rfc5761.md ├── rfc5763.md ├── rfc5764.md ├── rfc5888.md ├── rfc6347.md ├── rfc7064.md ├── rfc7478.md ├── rfc7675.md ├── rfc7742.md ├── rfc7874.md ├── rfc7983.md ├── rfc8122.md ├── rfc8421.md └── rfc8445.md /.gitignore: -------------------------------------------------------------------------------- 1 | # Logs 2 | logs 3 | *.log 4 | npm-debug.log* 5 | yarn-debug.log* 6 | yarn-error.log* 7 | 8 | # Runtime data 9 | pids 10 | *.pid 11 | *.seed 12 | *.pid.lock 13 | 14 | # Directory for instrumented libs generated by jscoverage/JSCover 15 | lib-cov 16 | 17 | # Coverage directory used by tools like istanbul 18 | coverage 19 | 20 | # nyc test coverage 21 | .nyc_output 22 | 23 | # Grunt intermediate storage (http://gruntjs.com/creating-plugins#storing-task-files) 24 | .grunt 25 | 26 | # Bower dependency directory (https://bower.io/) 27 | bower_components 28 | 29 | # node-waf configuration 30 | .lock-wscript 31 | 32 | # Compiled binary addons (https://nodejs.org/api/addons.html) 33 | build/Release 34 | 35 | # Dependency directories 36 | node_modules/ 37 | jspm_packages/ 38 | 39 | # TypeScript v1 declaration files 40 | typings/ 41 | 42 | # Optional npm cache directory 43 | .npm 44 | 45 | # Optional eslint cache 46 | .eslintcache 47 | 48 | # Optional REPL history 49 | .node_repl_history 50 | 51 | # Output of 'npm pack' 52 | *.tgz 53 | 54 | # Yarn Integrity file 55 | .yarn-integrity 56 | 57 | # dotenv environment variables file 58 | .env 59 | 60 | # next.js build output 61 | .next 62 | -------------------------------------------------------------------------------- /markdown/draft-ietf-ice-pac-03.md: -------------------------------------------------------------------------------- 1 | > Read [original](https://tools.ietf.org/html/draft-ietf-ice-pac-03) / [summary](../summary/draft-ietf-ice-pac-03.md) 2 | 3 | --- 4 | 5 | # ICE Patiently Awaiting Connectivity 6 | 7 | ## 1. Introduction 8 | 9 | [RFC8445] describes a protocol, Interactive Connectivity Establishment (ICE), for Network Address Translator (NAT) traversal for UDP-based communication. 10 | 11 | When using ICE, endpoints will typically exchange ICE candidates, form a list of candidate pairs, and then test each candidate pair to see if connectivity can be established. If the test for a given pair fails, it is marked accordingly, and if all pairs have failed, the overall ICE process typically is considered to have failed. 12 | 13 | During the process of connectivity checks, additional candidates may be created as a result of successful inbound checks from the remote peer. Such candidates are referred to as peer-reflexive candidates, and once discovered, will be used to form new candidate pairs which will be tested like any other. However, there is an inherent race condition here; if, before learning about any peer-reflexive candidates, an endpoint runs out of candidate pairs to check, either because it has none, or it considers them all to have failed, it will prematurely declare failure and terminate ICE processing. This race condition can occur in many common situations. 14 | 15 | This specification updates [RFC8445], by simply requiring that an ICE agent wait a minimum amount of time before declaring ICE failure, even if there are no candidate pairs to check, or if all candidate pairs have failed. This delay provides enough time for the discovery of peer-reflexive candidates, which may eventually lead to ICE processing completing successfully. 16 | 17 | ## 2. Conventions 18 | 19 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 20 | 21 | ## 3. Relevant Scenarios 22 | 23 | As noted above, the core problem this specification attempts to address is the situation where even after local gathering and remote candidate signaling has completed, the ICE agent immediately ends up with no valid pairs and no candidate pairs left to check, resulting in a premature ICE failure. This failure is premature because not enough time has elapsed to allow for discovery of peer-reflexive candidates from inbound connectivity checks; if discovered, these candidates are very likely to result in a valid pair. 24 | 25 | In most ICE scenarios, the lengthy timeouts for connectivity check transactions, typically tens of seconds, will prevent this problem from occurring. However, there are certain specific cases where this problem will frequently occur. 26 | 27 | ### 3.1. No Candidates From Peer 28 | 29 | It is entirely legal for an ICE agent to provide zero candidates of its own. If the agent somehow knows that the remote endpoint is directly reachable, gathering local candidates is unnecessary and will only cause delays; the peer agent can discover the appropriate local candidate via connectivity checks. 30 | 31 | However, following the procedures from [RFC8445] strictly will result in immediate ICE failure, since the checklist at the peer agent will be empty. 32 | 33 | ### 3.2. All Candidates Discarded 34 | 35 | Even if the ICE agent provides candidates, they may be discarded by the peer agent if it does not know what to do with them. For example, candidates may use an address family that the peer agent does not support, (e.g., a host candidate with an IPv6 address in a NAT64 scenario), or may not be usable for some other reason. 36 | 37 | In these scenarios, when the candidates are discarded, the checklist at the peer agent will once again be empty, leading to immediate ICE failure. 38 | 39 | ### 3.3. Immediate Candidate Pair Failure 40 | 41 | Section 7.2.5.2 of [RFC8445] describes several situations in which a candidate pair will be considered to have failed, well before the connectivity check transaction timeout. 42 | 43 | As a result, even if the ICE agent provides usable candidates, the pairs created by the peer agent may fail immediately when checked, e.g., a check to a non-routable address that receives an immediate ICMP error. 44 | 45 | In this situation, the checklist at the peer agent may contain only failed pairs, resulting in immediate ICE failure. 46 | 47 | ## 4. Update to RFC 8445 48 | 49 | In order to avoid the problem raised by this document, the ICE agent needs to wait enough time to allow peer-reflexive candidates to be discovered. Accordingly, when a full ICE implementation begins its ICE processing, as described in [RFC8445], Section 6.1, it MUST set a timer, henceforth known as the PAC timer, to ensure ICE will run for a minimum amount of time before determining failure. 50 | 51 | Specifically, the ICE agent will start its timer once it believes ICE connectivity checks are starting. This occurs when the agent has sent the values needed to perform connectivity checks (e.g., the Username Fragment and Password denoted in [RFC8445], Section 5.3) and has received some indication that the remote side is ready to start connectivity checks, typically via receipt of the values mentioned above. Note that the agent will start the timer even if it has not sent or received any ICE candidates. 52 | 53 | The RECOMMENDED duration for the timer is equal to the agent's connectivity check transaction timeout, including all retransmissions. This timeout value is chosen to roughly coincide with the maximum possible duration of ICE connectivity checks from the remote peer, which, if successful, could create peer-reflexive candidates. Because the ICE agent doesn't know the exact number of candidate pairs and pacing interval in use by the remote side, this timeout value is simply a guess, albeit an educated one. Regardless, for this particular problem, the desired benefits will be realized as long as the agent waits some reasonable amount of time, and, as usual, the application is in the best position to determine what is reasonable for its scenario. 54 | 55 | While the timer is running, the ICE agent MUST NOT set the state of a checklist to Failed, even if the checklist has no pairs left to check. As a result, the ICE agent will not remove any data streams or set the state of the ICE session to Failed as long as the timer is running. 56 | 57 | When the timer eventually elapses, the ICE agent MUST resume typical ICE processing, including setting any checklists containing only Failed pairs to the Failed state, as usual, and handling any consequences as indicated in [RFC8445], Section 8.1.2. Naturally, if there are no such checklists, no action is necessary. 58 | 59 | One consequence of this behavior is that in cases where ICE should fail, e.g., where both sides provide candidates with unsupported address families, ICE will no longer fail immediately, and only fail when the PAC timer expires. However, because most ICE scenarios require an extended period of time to determine failure, the fact that some specific scenarios no longer fail fast should have minimal application impact, if any. 60 | 61 | Note also that the PAC timer is potentially relevant to the ICE nomination procedure described in [RFC8445], Section 8.1.1. That specification does not define a minimum duration for ICE processing prior to nomination of a candidate pair, but in order to select the best candidate pair, ICE needs to run for enough time in order to allow peer-reflexive candidates to be discovered and checked, as noted above. Accordingly, the controlling ICE agent SHOULD wait a sufficient amount of time before nominating candidate pairs, and it MAY use the PAC timer to do so. As always, the controlling ICE agent retains full discretion, and MAY decide, based on its own criteria, to nominate pairs prior to the timer elapsing. 62 | 63 | ## 5. Update to RFC XXXX 64 | 65 | [RFC EDITOR NOTE: Please replace RFC XXXX with the RFC number of draft-ietf-ice-trickle once it has been published.] 66 | 67 | Trickle ICE [I-D.ietf-ice-trickle] considers a similar problem, namely whether an ICE agent should allow a checklist to enter the Failed state if more candidates might still be provided by the remote peer. The solution, specified in [I-D.ietf-ice-trickle], Section 8, is to wait until an end-of-candidates indication has been received before determining ICE failure. 68 | 69 | However, for the same reasons described above, the ICE agent may discover peer-reflexive candidates after it has received the end-of-candidates indication, and so the solution proposed by this document MUST still be used even when the ICE agent is using Trickle ICE. 70 | 71 | Note also that sending an end-of-candidates indication is only a SHOULD-strength requirement, which means that ICE agents will need to implement an backup mechanism to decide when all candidates have been received, typically a timer. Accordingly, ICE agents MAY use the PAC timer to also serve as an end-of-candidates fallback. 72 | 73 | ## 6. Security Considerations 74 | 75 | The security considerations for ICE are defined in [RFC8445]. This specification only recommends that ICE agents wait for a certain time of period before they declare ICE failure, and does not introduce new security considerations. 76 | 77 | ## 7. IANA considerations 78 | 79 | This specification makes no requests to IANA. 80 | -------------------------------------------------------------------------------- /markdown/draft-thatcher-ice-renomination-01.md: -------------------------------------------------------------------------------- 1 | > Read [original](https://tools.ietf.org/html/draft-thatcher-ice-renomination-01) / [summary](../summary/draft-thatcher-ice-renomination-01.md) 2 | 3 | --- 4 | 5 | # ICE Renomination: Dynamically selecting ICE candidate pairs 6 | 7 | ## 1. Introduction 8 | 9 | ICE agents are either controlling or controlled. The controlling ICE agent can unilaterally select a given candidate pair at any time. But it cannot control what candidate pair the controlled ICE agent selects once the controlling ICE agent has nominated a candidate pair (with passive nomination) or nominated many candidate pairs (with aggressive nomination), with the exception that it may nominate a higher priority candidate pair with aggressive nomination. This greatly limits the controlling side's options. 10 | 11 | For example, if an ICE agent selects and nominates a candidate pair over a cellular network, and then later connects to a Wi-Fi network and trickles ICE candidates for the Wi-Fi network, it may wish to select and nominate a candidate pair using Wi-Fi. If soon thereafter the Wi-Fi network disconnects and the ICE agent wishes to select and nominate the cellular candidate pair again, it would be unable to do with either passive or aggressive nomination. 12 | 13 | ## 2. Terminology 14 | 15 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 16 | 17 | ## 3. Renomination 18 | 19 | We define a new ICE option called "renomination". When renomination is signaled, aggressive nomination is disabled, and the controlled side follows a rule of "last nomination wins". This allows the controlling side to send nominations for new candidate pairs at any time. The controlling side SHOULD send the new nomination until the STUN packet is acked to ensure that the renomination was received. 20 | 21 | If one side signals "renomination" and the other does not understand it, then according to the rules of ICE, aggressive nomination is disabled and passive nomination is used, and the controlling side MUST NOT send more than one nomination. 22 | 23 | ## 4. "Nomination" attribute 24 | 25 | To deal with out-of-order delivery of nominations, we define a new STUN attribute: "nomination" which includes a 24-bit integer in the 3 least significant bytes of the attribute. 26 | 27 | The controlling side MAY include such an attribute when renominating. The controlled side MUST select the nomination with the largest value contained in the "nomination" attribute. Any value included takes precedence over the lack of a value. 28 | 29 | ## 5. IANA Considerations 30 | 31 | This specification requests no actions from IANA. 32 | 33 | ## 6. Security Considerations 34 | 35 | TODO 36 | -------------------------------------------------------------------------------- /markdown/draft-uberti-rtcweb-turn-rest-00.md: -------------------------------------------------------------------------------- 1 | > Read [original](https://tools.ietf.org/html/draft-uberti-rtcweb-turn-rest-00) / [summary](../summary/draft-uberti-rtcweb-turn-rest-00.md) 2 | 3 | --- 4 | 5 | # A REST API For Access To TURN Services 6 | 7 | ## 1. Introduction 8 | 9 | TURN [RFC5766] is a protocol that is often used to improve the connectivity of P2P applications. By providing a cloud-based relay service, TURN ensures that a connection can be established even when one or both sides is incapable of a direct P2P connection. However, as a relay service, it imposes a nontrivial cost on the service provider. Therefore, access to a TURN service is almost always access-controlled. 10 | 11 | TURN provides a mechanism to control access via "long-term" username/ password credentials that are provided as part of the TURN protocol. It is expected that these credentials will be kept secret; if the credentials are discovered, the TURN server could be used by unauthorized users or applications. However, in web applications, ensuring this secrecy is typically impossible. 12 | 13 | To address this problem, this document proposes an API that can be used to retrieve ephemeral TURN credentials from a web service. For simplicity, the design has been kept intentionally stateless; to use this mechanism, the only interaction needed between the web service and the TURN service is to share a secret key. 14 | 15 | ## 2. HTTP Interactions 16 | 17 | To retrieve a new set of credentials, the client makes a HTTP POST request, specifying TURN as the service to allocate credentials for, and optionally specifying a user id parameter. The purpose of the user id parameter is to simplify debugging on the TURN server, as well as provide the ability to control the number of credentials handed out for a specific user, if desired. The TURN credentials and their lifetime are returned as JSON, along with URIs that indicate how to connect to the server using the TURN protocol. To avoid the need for state passing between the web service and TURN server, the returned credentials consist of a TURN username that encodes all the necessary state (expiry time and application user id), and a TURN password that is a digest of this state, signed with the shared secret key. Since the returned credentials are ephemeral, they will eventually expire. This does not affect existing TURN allocations, as they are tied to a specific 5-tuple, but requests to allocate new TURN ports will fail after the expiry time. This is significant in the case of an ICE restart, where the client will need to allocate a new set of candidates, including TURN candidates. To get a new set of ephemeral credentials, the client can simply re-issue the original HTTP request with the same parameters, which will return the new credentials in its JSON response. To prevent unauthorized use, the HTTP requests can be ACLed by various means, e.g. IP address (if coming from a server), Origin header, User-Agent header, login cookie, API key, etc. 18 | 19 | ### 2.1. Request 20 | 21 | The request includes the following parameters, specified in the URL: 22 | 23 | * service: specifies the desired service (turn) 24 | 25 | * username: an optional user id to be associated with the credentials 26 | 27 | * key: if an API key is used for authentication, the API key 28 | 29 | 30 | ``` 31 | Example: 32 | 33 | POST /?service=turn&username=fred 34 | ``` 35 | 36 | ### 2.2. Response 37 | 38 | The response is returned with content-type "application/json", and consists of a JSON object with the following parameters: 39 | 40 | * username: the TURN username to use, which is a colon-delimited combination of the expiration timestamp and the username parameter from the request (if specified). The timestamp is intended to be opaque to the web application, so its format is arbitrary, but for simplicity, use of UNIX timestamps is recommended. 41 | 42 | * password: the TURN password to use; this value is computed from the a secret key shared with the TURN server and the returned username value, by performing base64(hmac(secret key, returned username)). HMAC-SHA1 is one HMAC algorithm that can be used, but any algorithm that incorporates a shared secret is acceptable, as long as both the web server and TURN server use the same algorithm and secret. 43 | 44 | * ttl: the duration for which the username and password are valid, in seconds. A value of one day (86400 seconds) is recommended. 45 | 46 | * uris: an array of TURN URIs, in the form specified in [I-D.petithuguenin-behave-turn-uris]. This is used to indicate the different addresses and/or protocols that can be used to reach the TURN server. 47 | 48 | 49 | ``` 50 | Example: 51 | 52 | { 53 | "username" : "12334939:fred", 54 | "password" : "adfsaflsjflds", 55 | "ttl" : 86400, 56 | "uris" : [ 57 | "turn:1.2.3.4:9991?transport=udp", 58 | "turn:1.2.3.4:9992?transport=tcp", 59 | "turns:1.2.3.4:443?transport=tcp" 60 | ] 61 | } 62 | ``` 63 | 64 | ## 3. WebRTC Interactions 65 | 66 | The returned JSON is parsed and supplied when creating a WebRTC RTCPeerConnection, to tell it how to access the TURN server. 67 | 68 | 69 | ``` 70 | Example: 71 | 72 | var iceServer = { 73 | "username": response.username, 74 | "credential": response.password, 75 | "uris": response.uris 76 | }; 77 | var config = {"iceServers": [iceServer]}; 78 | var pc = new RTCPeerConnection(config); 79 | ``` 80 | 81 | When the credentials are updated (e.g. because they are about to expire), a new RTCConfiguration with the updated credentials can be supplied to the existing RTCPeerConnection via the updateIce method. This update must not affect existing TURN allocations, because TURN requires that the username stay constant for an allocation, but the new credentials will be used for any new allocations. 82 | 83 | [TODO: make sure this behavior is specified in the W3C API spec] 84 | 85 | ## 4. TURN Interactions 86 | 87 | ### 4.1. Client 88 | 89 | WebRTC's TURN request uses the supplied "username" value for its USERNAME attribute, and the "password" value for the input to the MESSAGE-INTEGRITY hash. 90 | 91 | ### 4.2. Server 92 | 93 | When processing ALLOCATE requests, the TURN server will split the USERNAME attribute into its timestamp and user id components, and verify that the timestamp, which indicates when the credentials expire, has not yet been reached. If this verification fails, it SHOULD reject the request with a 401 (Unauthorized) error. 94 | 95 | If desired, the TURN server can optionally verify that the parsed user id value corresponds to a currently valid user of an external service (e.g. is currently logged in to the web app that is making use of TURN). This requires proprietary communication between the TURN server and external service on each ALLOCATE request, so this usage is not recommended for typical applications. If this external verification fails, it SHOULD reject the request with a 401 (Unauthorized) error. 96 | 97 | For non-ALLOCATE requests, the TURN server merely verifies that the USERNAME matches the USERNAME that was used in the ALLOCATE (since it must remain constant). 98 | 99 | As in RFC 5766, the TURN server MUST verify the MESSAGE-INTEGRITY using the password associated with the supplied USERNAME. For the usage outlined in this document, the password will always be constructed using the supplied username and the shared secret as indicated in the "HTTP Interactions" section above. 100 | 101 | ## 5. Implementation Notes 102 | 103 | ### 5.1. Revocation 104 | 105 | In the system as described here, revoking specific credentials is not possible. The assumption is that TURN services are of low enough value that waiting for the timeout to expire is a valid approach for dealing with possibly-compromised credentials. 106 | 107 | In extreme abuse cases, TURN server blacklists of timestamp+username values can be supplied by an administrator to stop abuse of specific credential sets. 108 | 109 | ### 5.2. Key Rotation 110 | 111 | As indicated in [RFC2104], periodic rotation of the shared secret to protect against key compromise is RECOMMENDED. To facilitate the rollover, the TURN server SHOULD be able to validate incoming MESSAGE-INTEGRITY tokens based on at least 2 shared secrets at any time. 112 | 113 | ## 6. Security Considerations 114 | 115 | Because the USERNAME values in a TURN ALLOCATE request are typically visible to eavesdroppers, inclusion of an externally identifying user id, such as a login name, may allow a passive attacker to determine the identities of the parties in a conversation. To prevent this problem, use of opaque user id values is recommended. 116 | 117 | ## 7. IANA Considerations 118 | 119 | None. 120 | -------------------------------------------------------------------------------- /markdown/rfc3605.md: -------------------------------------------------------------------------------- 1 | > Read [original](https://tools.ietf.org/html/rfc3605) / [summary](../summary/rfc3605.md) 2 | 3 | --- 4 | 5 | # RTCP attribute in SDP 6 | 7 | ## 1. Introduction 8 | 9 | The session invitation protocol (SIP, [RFC3261]) is often used to establish multi-media sessions on the Internet. There are often cases today in which one or both ends of the connection are hidden behind a network address translation device [RFC2766]. In this case, the SDP text must document the IP addresses and UDP ports as they appear on the "public Internet" side of the NAT. In this memo, we will suppose that the host located behind a NAT has a way to obtain these numbers. A possible way to learn these numbers is briefly outlined in section 3, however, just learning the numbers is not enough. 10 | 11 | The SIP messages use the encoding defined in SDP [RFC2327] to describe the IP addresses and TCP or UDP ports used by the various media. Audio and video are typically sent using RTP [RFC3550], which requires two UDP ports, one for the media and one for the control protocol (RTCP). SDP carries only one port number per media, and states that "other ports used by the media application (such as the RTCP port) should be derived algorithmically from the base media port." RTCP port numbers were necessarily derived from the base media port in older versions of RTP (such as [RFC1889]), but now that this restriction has been lifted, there is a need to specify RTCP ports explicitly in SDP. Note, however, that implementations of RTP adhering to the earlier [RFC1889] specification may not be able to make use of the SDP attributes specified in this document. 12 | 13 | When the NAT device performs port mapping, there is no guarantee that the mappings of two separate ports reflects the sequencing and the parity of the original port numbers; in fact, when the NAT manages a pool of IP addresses, it is even possible that the RTP and the RTCP ports may be mapped to different addresses. In order to successfully establish connections despite the misordering of the port numbers and the possible parity switches caused by the NAT, we propose to use a specific SDP attribute to document the RTCP port and optionally the RTCP address. 14 | 15 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 16 | 17 | ## 2. Description of the Solution 18 | 19 | The main part of our solution is the declaration of an SDP attribute for documenting the port used by RTCP. 20 | 21 | ### 2.1. The RTCP Attribute 22 | 23 | The RTCP attribute is used to document the RTCP port used for media stream, when that port is not the next higher (odd) port number following the RTP port described in the media line. The RTCP attribute is a "value" attribute, and follows the general syntax specified page 18 of [RFC2327]: "a=:". For the RTCP attribute: 24 | 25 | * the name is the ascii string "rtcp" (lower case), 26 | 27 | * the value is the RTCP port number and optional address. 28 | 29 | The formal description of the attribute is defined by the following ABNF [RFC2234] syntax: 30 | 31 | 32 | ``` 33 | rtcp-attribute = "a=rtcp:" port [nettype space addrtype space 34 | connection-address] CRLF 35 | ``` 36 | 37 | In this description, the "port", "nettype", "addrtype" and "connection-address" tokens are defined as specified in "Appendix A: SDP Grammar" of [RFC2327]. 38 | 39 | Example encodings could be: 40 | 41 | 42 | ``` 43 | m=audio 49170 RTP/AVP 0 44 | a=rtcp:53020 45 | 46 | m=audio 49170 RTP/AVP 0 47 | a=rtcp:53020 IN IP4 126.16.64.4 48 | 49 | m=audio 49170 RTP/AVP 0 50 | a=rtcp:53020 IN IP6 2001:2345:6789:ABCD:EF01:2345:6789:ABCD 51 | ``` 52 | 53 | The RTCP attribute MAY be used as a media level attribute; it MUST NOT be used as a session level attribute. Though the examples below relate to a method that will return only unicast addresses, both unicast and multicast values are valid. 54 | 55 | ## 3. Discussion of the Solution 56 | 57 | The implementation of the solution is fairly straightforward. The questions that have been most often asked regarding this solution are whether this is useful, i.e., whether a host can actually discover port numbers in an unmodified NAT, whether it is sufficient, i.e., whether or not there is a need to document more than one ancillary port per media type, and whether why should not change the media definition instead of adding a new attribute. 58 | 59 | ### 3.1. How do we Discover Port Numbers? 60 | 61 | The proposed solution is only useful if the host can discover the "translated port numbers", i.e., the value of the ports as they appear on the "external side" of the NAT. One possibility is to ask the cooperation of a well connected third party that will act as a server according to STUN [RFC3489]. We thus obtain a four step process: 62 | 63 | 1 - The host allocates two UDP ports numbers for an RTP/RTCP pair, 64 | 65 | 2 - The host sends a UDP message from each port to the STUN server, 66 | 67 | 3 - The STUN server reads the source address and port of the packet, and copies them in the text of a reply, 68 | 69 | 4 - The host parses the reply according to the STUN protocol and learns the external address and port corresponding to each of the two UDP ports. 70 | 71 | This algorithm supposes that the NAT will use the same translation for packets sent to the third party and to the "SDP peer" with which the host wants to establish a connection. There is no guarantee that all NAT boxes deployed on the Internet have this characteristic. Implementers are referred to the STUN specification [RFC3489] for an extensive discussion of the various types of NAT. 72 | 73 | ### 3.2. Do we need to Support Multiple Ports? 74 | 75 | Most media streams are transmitted using a single pair of RTP and RTCP ports. It is possible, however, to transmit a single media over several RTP flows, for example using hierarchical encoding. In this case, SDP will encode the port number used by RTP on the first flow, and the number of flows, as in: 76 | 77 | 78 | ``` 79 | m=video 49170/2 RTP/AVP 31 80 | ``` 81 | 82 | In this example, the media is sent over 2 consecutive pairs of ports, corresponding respectively to RTP for the first flow (even number, 49170), RTCP for the first flow (odd number, 49171), RTP for the second flow (even number, 49172), and RTCP for the second flow (odd number, 49173). 83 | 84 | In theory, it would be possible to modify SDP and document the many ports corresponding to the separate encoding layers. However, layered encoding is not much used in practice, and when used is mostly used in conjunction with multicast transmission. The translation issues documented in this memo apply uniquely to unicast transmission, and thus there is no short term need for the support of multiple port descriptions. It is more convenient and more robust to focus on the simple case in which a media is sent over exactly one RTP/RTCP stream. 85 | 86 | ### 3.3. Why not Expand the Media Definition? 87 | 88 | The RTP ports are documented in the media description line, and it would seem convenient to document the RTCP port at the same place, rather than create an RTCP attribute. We considered this design alternative and rejected it for two reasons: adding an extra port number and an option address in the media description would be awkward, and more importantly it would create problems with existing applications, which would have to reject the entire media description if they did not understand the extension. On the contrary, adding an attribute has a well defined failure mode: implementations that don't understand the "a=rtcp" attribute will simply ignore it; they will fail to send RTCP packets to the specified address, but they will at least be able to receive the media in the RTP packets. 89 | 90 | ## 4. UNSAF Considerations 91 | 92 | The RTCP attribute in SDP is used to enable establishment of RTP/RTCP flows through NAT. This mechanism can be used in conjunction with an address discovery mechanism such as STUN [RFC3489]. STUN is a short term fix to the NAT traversal problem, which requires thus consideration of the general issues linked to "Unilateral self-address fixing" [RFC3424]. 93 | 94 | The RTCP attribute addresses a very specific problem, the documentation of port numbers as they appear after address translation by a port-mapping NAT. The RTCP attribute SHOULD NOT be used for other applications. 95 | 96 | We expect that, with time, one of two exit strategies can be developed. The IETF may develop an explicit "middlebox control" protocol that will enable applications to obtain a pair of port numbers appropriate for RTP and RTCP. Another possibility is the deployment of IPv6, which will enable use of "end to end" addressing and guarantee that the two hosts will be able to use appropriate ports. In both cases, there will be no need for documenting a "non standard" RTCP port with the RTCP attribute. 97 | 98 | ## 5. Security Considerations 99 | 100 | This SDP extension is not believed to introduce any significant security risk to multi-media applications. One could conceive that a malevolent third party would use the extension to redirect the RTCP fraction of an RTP exchange, but this requires intercepting and rewriting the signaling packet carrying the SDP text; if an interceptor can do that, many more attacks are available, including a wholesale change of the addresses and port numbers at which the media will be sent. 101 | 102 | In order to avoid attacks of this sort, when SDP is used in a signaling packet where it is of the form application/sdp, end-to-end integrity using S/MIME [RFC3369] is the technical method to be implemented and applied. This is compatible with SIP [RFC3261]. 103 | 104 | ## 6. IANA Considerations 105 | 106 | This document defines a new SDP parameter, the attribute field "rtcp", which per [RFC2327] has been registered by IANA. This attribute field is designed for use at media level only. 107 | -------------------------------------------------------------------------------- /markdown/rfc7064.md: -------------------------------------------------------------------------------- 1 | > Read [original](https://tools.ietf.org/html/rfc7064) / [summary](../summary/rfc7064.md) 2 | 3 | --- 4 | 5 | # URI Scheme for the Session Traversal Utilities for NAT (STUN) Protocol 6 | 7 | ## 1. Introduction 8 | 9 | This document specifies the syntax and semantics of the Uniform Resource Identifier (URI) scheme for the Session Traversal Utilities for NAT (STUN) protocol. 10 | 11 | STUN is a protocol that serves as a tool for other protocols in dealing with Network Address Translator (NAT) traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT, to perform connectivity checks between two endpoints, and as a keepalive protocol to maintain NAT bindings. RFC 5389 [RFC5389] defines the specifics of the STUN protocol. 12 | 13 | The "stun" and "stuns" URI schemes are used to designate a stand-alone STUN server or any Internet host performing the operations of a STUN server in the context of STUN usages (Section 14 of RFC 5389 [RFC5389]). With the advent of standards such as WebRTC [WEBRTC], we anticipate a plethora of endpoints and web applications to be able to identify and communicate with such a STUN server to carry out the STUN protocol. This implies that endpoints and/or applications must be provisioned with the appropriate configuration to identify the STUN server. Having an inconsistent syntax adds ambiguity and can result in non-interoperable solutions and implementation limitations. The "stun" and "stuns" URI schemes help alleviate most of these issues by providing a consistent way to describe, configure, and exchange the information identifying a STUN server. 14 | 15 | ## 2. Terminology 16 | 17 | The key words "MUST", "MUST NOT", "REQUIRED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] when they appear in ALL CAPS. When these words are not in ALL CAPS (such as "should" or "Should"), they have their usual English meanings and are not to be interpreted as RFC 2119 key words. 18 | 19 | ## 3. Definition of the "stun" or "stuns" URI 20 | 21 | ### 3.1. URI Scheme Syntax 22 | 23 | "stun" and "stuns" URIs have the following formal ABNF syntax [RFC5234]: 24 | 25 | 26 | ``` 27 | stunURI = scheme ":" host [ ":" port ] 28 | scheme = "stun" / "stuns" 29 | ``` 30 | 31 | and are specified in [RFC3986]. While these two ABNF productions are defined in [RFC3986] as components of the generic hierarchical URI, this does not imply that the "stun" and "stuns" URI schemes are hierarchical URIs. Developers MUST NOT use a generic hierarchical URI parser to parse a "stun" or "stuns" URI. 32 | 33 | ### 3.2. URI Scheme Semantics 34 | 35 | The "stun" and "stuns" URI schemes are used to designate a stand-alone STUN server or any Internet host performing the operations of a STUN server in the context of STUN usages (Section 14 of RFC 5389 [RFC5389]). The STUN protocol supports sending messages over UDP, TCP, or TLS-over-TCP. The "stuns" URI scheme MUST be used when STUN is run over TLS-over-TCP (or in the future DTLS-over-UDP), and the "stun" scheme MUST be used otherwise. 36 | 37 | The required part of the "stun" URI denotes the STUN server host. 38 | 39 | For the optional DNS discovery procedure mentioned in Section 9 of RFC 5389, the "stun" URI scheme implies UDP as the transport protocol for SRV lookup, and the "stuns" URI scheme indicates TCP as the transport protocol. 40 | 41 | As specified in [RFC5389], the part, if present, denotes the port on which the STUN server is awaiting connection requests. If it is absent, the default port is 3478 for both UDP and TCP. The default port for STUN over TLS is 5349 as per Section 9 of [RFC5389]. 42 | 43 | ## 4. Security Considerations 44 | 45 | The "stun" and "stuns" URI schemes do not introduce any specific security issues beyond the security considerations discussed in [RFC3986]. These URI schemes are intended for use in specific environments that involve NAT traversal. Users of the scheme need to carefully consider the security properties of the context in which they are using them. 46 | 47 | Although a "stun" or "stuns" URI does not itself include the username or password that will be used to authenticate the STUN client, in certain environments, such as WebRTC, the username and password will almost certainly be provisioned remotely by an external agent at the same time as a "stuns" URI is sent to that client. Thus, in such situations, if the username and password were received in the clear, there would be little or no benefit to using a "stuns" URI. For this reason, a STUN client MUST ensure that the username, password, "stuns" URI, and any other security-relevant parameters are received with equivalent security before using the "stuns" URI. Receiving those parameters over another TLS session can provide the appropriate level of security if both TLS sessions are similarly parameterized, e.g., with commensurate strength ciphersuites. 48 | 49 | ## 5. IANA Considerations 50 | 51 | This section contains the registration information for the "stun" and "stuns" URI schemes (in accordance with [RFC4395]). Note that these URI schemes are intended for use in very specific NAT traversal environments and should not be used otherwise on the open Web or Internet. 52 | 53 | ### 5.1. "stun" URI Registration 54 | 55 | URI scheme name: stun 56 | 57 | Status: permanent 58 | 59 | URI scheme syntax: See Section 3.1 60 | 61 | URI scheme semantics: See Section 3.2 62 | 63 | Encoding considerations: There are no encoding considerations beyond those in [RFC3986]. 64 | 65 | Applications/protocols that use this URI scheme name: 66 | 67 | The "stun" URI scheme is intended to be used by applications with a need to identify a STUN server to be used for NAT traversal. 68 | 69 | Interoperability considerations: N/A 70 | 71 | Security considerations: See Section 4 72 | 73 | Contact: Suhas Nandakumar 74 | 75 | Author/Change controller: The IESG 76 | 77 | References: RFC 7064 78 | 79 | ### 5.2. "stuns" URI Registration 80 | 81 | URI scheme name: stuns 82 | 83 | Status: permanent 84 | 85 | URI scheme syntax: See Section 3.1 86 | 87 | URI scheme semantics: See Section 3.2 88 | 89 | Encoding considerations: There are no encoding considerations beyond those in [RFC3986]. 90 | 91 | Applications/protocols that use this URI scheme name: 92 | 93 | The "stuns" URI scheme is intended to be used by applications with a need to identify a STUN server to be used for NAT traversal over a secure connection. 94 | 95 | Interoperability considerations: N/A 96 | 97 | Security considerations: See Section 4 98 | 99 | Contact: Suhas Nandakumar 100 | 101 | Author/Change controller: The IESG 102 | 103 | References: RFC 7064 -------------------------------------------------------------------------------- /markdown/rfc7675.md: -------------------------------------------------------------------------------- 1 | > Read [original](https://tools.ietf.org/html/rfc7675) / [summary](../summary/rfc7675.md) 2 | 3 | --- 4 | 5 | # Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness 6 | 7 | ## 1. Introduction 8 | 9 | To prevent attacks on peers, endpoints have to ensure the remote peer is willing to receive traffic. Verification of peer consent before sending traffic is necessary in deployments like WebRTC to ensure that a malicious JavaScript cannot use the browser as a platform for launching attacks. This is performed both when the session is first established to the remote peer using Interactive Connectivity Establishment (ICE) [RFC5245] connectivity checks, and periodically for the duration of the session using the procedures defined in this document. 10 | 11 | When a session is first established, ICE implementations obtain an initial consent to send by performing STUN connectivity checks. This document describes a new STUN usage with exchange of request and response messages that verifies the remote peer's ongoing consent to receive traffic. This consent expires after a period of time and needs to be continually renewed, which ensures that consent can be terminated. 12 | 13 | This document defines what it takes to obtain, maintain, and lose consent to send. Consent to send applies to a single 5-tuple. How applications react to changes in consent is not described in this document. The consent mechanism does not update the ICE procedures defined in [RFC5245]. 14 | 15 | Consent is obtained only by full ICE implementations. An ICE-lite agent (as defined in Section 2.7 of [RFC5245]) does not generate connectivity checks or run the ICE state machine. Hence, an ICE-lite agent does not generate consent checks and will only respond to any checks that it receives. No changes are required to ICE-lite implementations in order to respond to consent checks, as they are processed as normal ICE connectivity checks. 16 | 17 | ## 2. Applicability 18 | 19 | This document defines what it takes to obtain, maintain, and lose consent to send using ICE. Sections 4.4 and 5.3 of [WebRTC-SA] further explain the value of obtaining and maintaining consent. 20 | 21 | Other applications that have similar security requirements to verify peer consent before sending non-ICE packets can use the consent mechanism described in this document. The mechanism of how applications are made aware of consent expiration is outside the scope of the document. 22 | 23 | ## 3. Terminology 24 | 25 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 26 | 27 | Consent: The mechanism of obtaining permission from the remote endpoint to send non-ICE traffic to a remote transport address. Consent is obtained using ICE. Note that this is an application-level consent; no human intervention is involved. 28 | 29 | Consent Freshness: Maintaining and renewing consent over time. 30 | 31 | Transport Address: The remote peer's IP address and UDP or TCP port number. 32 | 33 | ## 4. Design Considerations 34 | 35 | Although ICE requires periodic keepalive traffic to keep NAT bindings alive (see Section 10 of [RFC5245] and also [RFC6263]), those keepalives are sent as STUN Indications that are send-and-forget, and do not evoke a response. A response is necessary for consent to continue sending traffic. Thus, we need a request/response mechanism for consent freshness. ICE can be used for that mechanism because ICE implementations are already required to continue listening for ICE messages, as described in Section 10 of [RFC5245]. STUN binding requests sent for consent freshness also serve the keepalive purpose (i.e., to keep NAT bindings alive). Because of that, dedicated keepalives (e.g., STUN Binding Indications) are not sent on candidate pairs where consent requests are sent, in accordance with Section 20.2.3 of [RFC5245]. 36 | 37 | When Secure Real-time Transport Protocol (SRTP) is used, the following considerations are applicable. SRTP is encrypted and authenticated with symmetric keys; that is, both sender and receiver know the keys. With two party sessions, receipt of an authenticated packet from the single remote party is a strong assurance the packet came from that party. However, when a session involves more than two parties, all of whom know each other's keys, any of those parties could have sent (or spoofed) the packet. Such shared key distributions are possible with some Multimedia Internet KEYing (MIKEY) [RFC3830] modes, Security Descriptions [RFC4568], and Encrypted Key Transport (EKT) [EKT]. Thus, in such shared keying distributions, receipt of an authenticated SRTP packet is not sufficient to verify consent. 38 | 39 | The mechanism proposed in the document is an optional extension to the ICE protocol; it can be deployed at one end of the two-party communication session without impact on the other party. 40 | 41 | ## 5. Solution 42 | 43 | Initial consent to send traffic is obtained using ICE [RFC5245]. An endpoint gains consent to send on a candidate pair when the pair enters the Succeeded ICE state. This document establishes a 30-second expiry time on consent. 30 seconds was chosen to balance the need to minimize the time taken to respond to a loss of consent with the desire to reduce the occurrence of spurious failures. 44 | 45 | ICE does not identify when consent to send traffic ends. This document describes two ways in which consent to send ends: expiration of consent and immediate revocation of consent, which are discussed in the following sections. 46 | 47 | ### 5.1. Expiration of Consent 48 | 49 | A full ICE implementation obtains consent to send using ICE. After ICE concludes on a particular candidate pair and whenever the endpoint sends application data on that pair consent is maintained following the procedure described in this document. 50 | 51 | An endpoint MUST NOT send data other than the messages used to establish consent unless the receiving endpoint has consented to receive data. Connectivity checks that are paced as described in Section 16 of [RFC5245], and responses to connectivity checks are permitted. That is, no application data (e.g., RTP or Datagram Transport Layer Security (DTLS)), can be sent until consent is obtained. 52 | 53 | Explicit consent to send is obtained and maintained by sending a STUN binding request to the remote peer's transport address and receiving a matching, authenticated, non-error STUN binding response from the remote peer's transport address. These STUN binding requests and responses are authenticated using the same short-term credentials as the initial ICE exchange. 54 | 55 | Note: Although TCP has its own consent mechanism (TCP acknowledgements), consent is necessary over a TCP connection because it could be translated to a UDP connection (e.g., [RFC6062]). 56 | 57 | Consent expires after 30 seconds. That is, if a valid STUN binding response has not been received from the remote peer's transport address in 30 seconds, the endpoint MUST cease transmission on that 5-tuple. STUN consent responses received after consent expiry do not re-establish consent and may be discarded or cause an ICMP error. 58 | 59 | To prevent expiry of consent, a STUN binding request can be sent periodically. To prevent synchronization of consent checks, each interval MUST be randomized from between 0.8 and 1.2 times the basic period. Implementations SHOULD set a default interval of 5 seconds, resulting in a period between checks of 4 to 6 seconds. Implementations MUST NOT set the period between checks to less than 4 seconds. This timer is independent of the consent expiry timeout. 60 | 61 | Each STUN binding request for consent MUST use a new STUN transaction identifier, as described in Section 6 of [RFC5389]. Each STUN binding request for consent is transmitted once only. A sender therefore cannot assume that it will receive a response for every consent request, and a response might be for a previous request (rather than for the most recently sent request). 62 | 63 | An endpoint SHOULD await a binding response for each request it sends for a time based on the estimated round-trip time (RTT) (see Section 7.2.1 of [RFC5389]) with an allowance for variation in network delay. The RTT value can be updated as described in [RFC5389]. All outstanding STUN consent transactions for a candidate pair MUST be discarded when consent expires. 64 | 65 | To meet the security needs of consent, an untrusted application (e.g., JavaScript or signaling servers) MUST NOT be able to obtain or control the STUN transaction identifier, because that enables spoofing of STUN responses, falsifying consent. 66 | 67 | To prevent attacks on the peer during ICE restart, an endpoint that continues to send traffic on the previously validated candidate pair during ICE restart MUST continue to perform consent freshness on that candidate pair as described earlier. 68 | 69 | While TCP affords some protection from off-path attackers ([RFC5961], [RFC4953]), there is still a risk an attacker could cause a TCP sender to send forever by spoofing ACKs. To prevent such an attack, consent checks MUST be performed over all transport connections, including TCP. In this way, an off-path attacker spoofing TCP segments cannot cause a TCP sender to send once the consent timer expires (30 seconds). 70 | 71 | An endpoint does not need to maintain consent if it does not send application data. However, an endpoint MUST regain consent before it resumes sending application data. In the absence of any packets, any bindings in middleboxes for the flow might expire. Furthermore, having one peer unable to send is detrimental to many protocols. Absent better information about the network, if an endpoint needs to ensure its NAT or firewall mappings do not expire, this can be done using keepalive or other techniques (see Section 10 of [RFC5245] and see [RFC6263]). 72 | 73 | After consent is lost, the same ICE credentials MUST NOT be used on the affected 5-tuple again. That means that a new session, or an ICE restart, is needed to obtain consent to send on the affected candidate pair. 74 | 75 | ### 5.2. Immediate Revocation of Consent 76 | 77 | In some cases, it is useful to signal that consent is terminated rather than relying on a timeout. 78 | 79 | Consent for sending application data is immediately revoked by receipt of an authenticated message that closes the connection (e.g., a Transport Layer Security (TLS) fatal alert) or receipt of a valid and authenticated STUN response with error code Forbidden (403). Note however that consent revocation messages can be lost on the network, so an endpoint could resend these messages, or wait for consent to expire. 80 | 81 | Receipt of an unauthenticated message that closes a connection (e.g., TCP FIN) does not indicate revocation of consent. Thus, an endpoint receiving an unauthenticated end-of-session message SHOULD continue sending media (over connectionless transport) or attempt to re-establish the connection (over connection-oriented transport) until consent expires or it receives an authenticated message revoking consent. 82 | 83 | Note that an authenticated Secure Real-time Transport Control Protocol (SRTCP) BYE does not terminate consent; it only indicates the associated SRTP source has quit. 84 | 85 | ## 6. DiffServ Treatment for Consent 86 | 87 | It is RECOMMENDED that STUN consent checks use the same Diffserv Codepoint markings as the ICE connectivity checks described in Section 7.1.2.4 of [RFC5245] for a given 5-tuple. 88 | 89 | Note: It is possible that different Diffserv Codepoints are used by different media over the same transport address [WebRTC-QoS]. Such a case is outside the scope of this document. 90 | 91 | ## 7. DTLS Applicability 92 | 93 | The DTLS applicability is identical to what is described in Section 4.2 of [RFC7350]. 94 | 95 | ## 8. Security Considerations 96 | 97 | This document describes a security mechanism, details of which are mentioned in Sections 4.1 and 4.2 of [RFC7350]. Consent requires 96 bits transaction ID defined in Section 6 of [RFC5389] to be uniformly and randomly chosen from the interval 0 .. 2**96-1, and be cryptographically strong. This is good enough security against an off-path attacker replaying old STUN consent responses. Consent Verification to avoid attacks using a browser as an attack platform against machines is discussed in Sections 3.3 and 4.2 of [WebRTC-SEC]. 98 | 99 | The security considerations discussed in [RFC5245] should also be taken into account. -------------------------------------------------------------------------------- /markdown/rfc7742.md: -------------------------------------------------------------------------------- 1 | > Read [original](https://tools.ietf.org/html/rfc7742) / [summary](../summary/rfc7742.md) 2 | 3 | --- 4 | 5 | # WebRTC Video Processing and Codec Requirements 6 | 7 | ## 1. Introduction 8 | 9 | One of the major functions of WebRTC endpoints is the ability to send and receive interactive video. The video might come from a camera, a screen recording, a stored file, or some other source. This specification provides the requirements and considerations for WebRTC applications to send and receive video across a network. It specifies the video processing that is required as well as video codecs and their parameters. 10 | 11 | Note that this document only discusses those issues dealing with video-codec handling. Issues that are related to transport of media streams across the network are specified in [WebRTC-RTP-USAGE]. 12 | 13 | ## 2. Terminology 14 | 15 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 16 | 17 | The following definitions are used in this document: 18 | 19 | * A WebRTC browser (also called a WebRTC User Agent or WebRTC UA) is something that conforms to both the protocol specification and the Javascript API (see [RTCWEB-OVERVIEW]). 20 | 21 | * A WebRTC non-browser is something that conforms to the protocol specification, but it does not claim to implement the Javascript API. This can also be called a "WebRTC device" or "WebRTC native application". 22 | 23 | * A WebRTC endpoint is either a WebRTC browser or a WebRTC non-browser. It conforms to the protocol specification. 24 | 25 | * A WebRTC-compatible endpoint is an endpoint that is able to successfully communicate with a WebRTC endpoint but may fail to meet some requirements of a WebRTC endpoint. This may limit where in the network such an endpoint can be attached, or it may limit the security guarantees that it offers to others. It is not constrained by this specification; when it is mentioned at all, it is to note the implications on WebRTC-compatible endpoints of the requirements placed on WebRTC endpoints. 26 | 27 | These definitions are also found in [RTCWEB-OVERVIEW] and that document should be consulted for additional information. 28 | 29 | ## 3. Pre- and Post-Processing 30 | 31 | This section provides guidance on pre- and post-processing of video streams. 32 | 33 | Unless specified otherwise by the Session Description Protocol (SDP) or codec, the color space SHOULD be sRGB [SRGB]. For clarity, this is the color space indicated by codepoint 1 from "ColourPrimaries" as defined in [IEC23001-8]. 34 | 35 | Unless specified otherwise by the SDP or codec, the video scan pattern for video codecs is Y'CbCr 4:2:0. 36 | 37 | ### 3.1. Camera-Source Video 38 | 39 | This document imposes no normative requirements on camera capture; however, implementors are encouraged to take advantage of the following features, if feasible for their platform: 40 | 41 | * Automatic focus, if applicable for the camera in use 42 | 43 | * Automatic white balance 44 | 45 | * Automatic light-level control 46 | 47 | * Dynamic frame rate for video capture based on actual encoding in use (e.g., if encoding at 15 fps due to bandwidth constraints, low light conditions, or application settings, the camera will ideally capture at 15 fps rather than a higher rate). 48 | 49 | ### 3.2. Screen-Source Video 50 | 51 | If the video source is some portion of a computer screen (e.g., desktop or application sharing), then the considerations in this section also apply. 52 | 53 | Because screen-sourced video can change resolution (due to, e.g., window resizing and similar operations), WebRTC-video recipients MUST be prepared to handle midstream resolution changes in a way that preserves their utility. Precise handling (e.g., resizing the element a video is rendered in versus scaling down the received stream; decisions around letter/pillarboxing) is left to the discretion of the application. 54 | 55 | Note that the default video-scan format (Y'CbCr 4:2:0) is known to be less than optimal for the representation of screen content produced by most systems in use at the time of this document's writing, which generally use RGB with at least 24 bits per sample. In the future, it may be advisable to use video codecs optimized for screen content for the representation of this type of content. 56 | 57 | Additionally, attention is drawn to the requirements in Section 5.2 of [WebRTC-SEC-ARCH] and the considerations in Section 4.1.1. of [WebRTC-SEC]. 58 | 59 | ## 4. Stream Orientation 60 | 61 | In some circumstances -- and notably those involving mobile devices -- the orientation of the camera may not match the orientation used by the encoder. Of more importance, the orientation may change over the course of a call, requiring the receiver to change the orientation in which it renders the stream. 62 | 63 | While the sender may elect to simply change the pre-encoding orientation of frames, this may not be practical or efficient (in particular, in cases where the interface to the camera returns pre-compressed video frames). Note that the potential for this behavior adds another set of circumstances under which the resolution of a screen might change in the middle of a video stream, in addition to those mentioned in Section 3.2. 64 | 65 | To accommodate these circumstances, WebRTC implementations that can generate media in orientations other than the default MUST support generating the R0 and R1 bits of the Coordination of Video Orientation (CVO) mechanism described in Section 7.4.5 of [TS26.114] and MUST send them for all orientations when the peer indicates support for the mechanism. They MAY support sending the other bits in the CVO extension, including the higher-resolution rotation bits. All implementations SHOULD support interpretation of the R0 and R1 bits and MAY support the other CVO bits. 66 | 67 | Further, some codecs support in-band signaling of orientation (for example, the SEI "Display Orientation" messages in H.264 and H.265 [H265]). If CVO has been negotiated, then the sender MUST NOT make use of such codec-specific mechanisms. However, when support for CVO is not signaled in the SDP, then such implementations MAY make use of the codec-specific mechanisms instead. 68 | 69 | ## 5. Mandatory-to-Implement Video Codec 70 | 71 | For the definitions of "WebRTC browser", "WebRTC non-browser", and "WebRTC-compatible endpoint" as they are used in this section, please refer to Section 2. 72 | 73 | WebRTC Browsers MUST implement the VP8 video codec as described in [RFC6386] and H.264 Constrained Baseline as described in [H264]. 74 | 75 | WebRTC Non-Browsers that support transmitting and/or receiving video MUST implement the VP8 video codec as described in [RFC6386] and H.264 Constrained Baseline as described in [H264]. 76 | 77 | NOTE: To promote the use of non-royalty-bearing video codecs, participants in the RTCWEB working group, and any successor working groups in the IETF, intend to monitor the evolving licensing landscape as it pertains to the two mandatory-to-implement codecs. If compelling evidence arises that one of the codecs is available for use on a royalty-free basis, the working group plans to revisit the question of which codecs are required for Non-Browsers, with the intention being that the royalty-free codec will remain mandatory to implement and the other will become optional. 78 | 79 | These provisions apply to WebRTC Non-Browsers only. There is no plan to revisit the codecs required for WebRTC Browsers. 80 | 81 | "WebRTC-compatible endpoints" are free to implement any video codecs they see fit. This follows logically from the definition of "WebRTC-compatible endpoint". It is, of course, advisable to implement at least one of the video codecs that is mandated for WebRTC browsers, and implementors are encouraged to do so. 82 | 83 | ## 6. Codec-Specific Considerations 84 | 85 | SDP allows for codec-independent indication of preferred video resolutions using the mechanism described in [RFC6236]. WebRTC endpoints MAY send an "a=imageattr" attribute to indicate the maximum resolution they wish to receive. Senders SHOULD interpret and honor this attribute by limiting the encoded resolution to the indicated maximum size, as the receiver may not be capable of handling higher resolutions. 86 | 87 | Additionally, codecs may include codec-specific means of signaling maximum receiver abilities with regard to resolution, frame rate, and bitrate. 88 | 89 | Unless otherwise signaled in SDP, recipients of video streams MUST be able to decode video at a rate of at least 20 fps at a resolution of at least 320 pixels by 240 pixels. These values are selected based on the recommendations in [HSUP1]. 90 | 91 | Encoders are encouraged to support encoding media with at least the same resolution and frame rates cited above. 92 | 93 | ### 6.1. VP8 94 | 95 | For the VP8 codec, defined in [RFC6386], endpoints MUST support the payload formats defined in [RFC7741]. 96 | 97 | In addition to the [RFC6236] mechanism, VP8 encoders MUST limit the streams they send to conform to the values indicated by receivers in the corresponding max-fr and max-fs SDP attributes. 98 | 99 | Unless otherwise signaled, implementations that use VP8 MUST encode and decode pixels with an implied 1:1 (square) aspect ratio. 100 | 101 | ### 6.2. H.264 102 | 103 | For the [H264] codec, endpoints MUST support the payload formats defined in [RFC6184]. In addition, they MUST support Constrained Baseline Profile Level 1.2 and SHOULD support H.264 Constrained High Profile Level 1.3. 104 | 105 | Implementations of the H.264 codec have utilized a wide variety of optional parameters. To improve interoperability, the following parameter settings are specified: 106 | 107 | packetization-mode: Packetization-mode 1 MUST be supported. Other modes MAY be negotiated and used. 108 | 109 | profile-level-id: Implementations MUST include this parameter within SDP and MUST interpret it when receiving it. 110 | 111 | max-mbps, max-smbps, max-fs, max-cpb, max-dpb, and max-br: 112 | 113 | These parameters allow the implementation to specify that they can support certain features of H.264 at higher rates and values than those signaled by their level (set with profile-level-id). Implementations MAY include these parameters in their SDP, but they SHOULD interpret them when receiving them, allowing them to send the highest quality of video possible. 114 | 115 | sprop-parameter-sets: H.264 allows sequence and picture information to be sent both in-band and out-of-band. WebRTC implementations MUST signal this information in-band. This means that WebRTC implementations MUST NOT include this parameter in the SDP they generate. 116 | 117 | H.264 codecs MAY send and MUST support proper interpretation of Supplemental Enhancement Information (SEI) "filler payload" and "full frame freeze" messages. The "full frame freeze" messages are used in video-switching MCUs, to ensure a stable decoded displayed picture while switching among various input streams. 118 | 119 | When the use of the video orientation (CVO) RTP header extension is not signaled as part of the SDP, H.264 implementations MAY send and SHOULD support proper interpretation of Display Orientation SEI messages. 120 | 121 | Implementations MAY send and act upon "User data registered by Rec. ITU-T T.35" and "User data unregistered" messages. Even if they do not act on them, implementations MUST be prepared to receive such messages without any ill effects. 122 | 123 | Unless otherwise signaled, implementations that use H.264 MUST encode and decode pixels with an implied 1:1 (square) aspect ratio. 124 | 125 | ## 7. Security Considerations 126 | 127 | This specification does not introduce any new mechanisms or security concerns beyond what is in the other documents it references. In WebRTC, video is protected using Datagram Transport Layer Security (DTLS) / Secure Real-time Transport Protocol (SRTP). A complete discussion of the security considerations can be found in [WebRTC-SEC] and [WebRTC-SEC-ARCH]. Implementors should consider whether the use of variable bitrate video codecs are appropriate for their application, keeping in mind that the degree of inter-frame change (and, by inference, the amount of motion in the frame) may be deduced by an eavesdropper based on the video stream's bitrate. 128 | 129 | Implementors making use of H.264 are also advised to take careful note of the "Security Considerations" section of [RFC6184], paying special regard to the normative requirement pertaining to SEI messages. 130 | -------------------------------------------------------------------------------- /markdown/rfc7874.md: -------------------------------------------------------------------------------- 1 | > Read [original](https://tools.ietf.org/html/rfc7874) / [summary](../summary/rfc7874.md) 2 | 3 | --- 4 | 5 | # WebRTC Audio Codec and Processing Requirements 6 | 7 | ## 1. Introduction 8 | 9 | An integral part of the success and adoption of Web Real-Time Communications (WebRTC) will be the voice and video interoperability between WebRTC applications. This specification will outline the audio processing and codec requirements for WebRTC endpoints. 10 | 11 | ## 2. Terminology 12 | 13 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 14 | 15 | ## 3. Codec Requirements 16 | 17 | To ensure a baseline level of interoperability between WebRTC endpoints, a minimum set of required codecs are specified below. If other suitable audio codecs are available for the WebRTC endpoint to use, it is RECOMMENDED that they also be included in the offer in order to maximize the possibility of establishing the session without the need for audio transcoding. 18 | 19 | WebRTC endpoints are REQUIRED to implement the following audio codecs: 20 | 21 | * Opus [RFC6716] with the payload format specified in [RFC7587]. 22 | 23 | * PCMA and PCMU (as specified in ITU-T Recommendation G.711 [G.711]) with the payload format specified in Section 4.5.14 of [RFC3551]. 24 | 25 | * [RFC3389] comfort noise (CN). WebRTC endpoints MUST support [RFC3389] CN for streams encoded with G.711 or any other supported codec that does not provide its own CN. Since Opus provides its own CN mechanism, the use of [RFC3389] CN with Opus is NOT RECOMMENDED. Use of Discontinuous Transmission (DTX) / CN by senders is OPTIONAL. 26 | 27 | * the 'audio/telephone-event' media type as specified in [RFC4733]. The endpoints MAY send DTMF events at any time and SHOULD suppress in-band dual-tone multi-frequency (DTMF) tones, if any. DTMF events generated by a WebRTC endpoint MUST have a duration of no more than 8000 ms and no less than 40 ms. The recommended default duration is 100 ms for each tone. The gap between events MUST be no less than 30 ms; the recommended default gap duration is 70 ms. WebRTC endpoints are not required to do anything with tones (as specified in RFC 4733) sent to them, except gracefully drop them. There is currently no API to inform JavaScript about the received DTMF or other tones (as specified in RFC 4733). WebRTC endpoints are REQUIRED to be able to generate and consume the following events: 28 | 29 | 30 | ``` 31 | +------------+--------------------------------+-----------+ 32 | |Event Code | Event Name | Reference | 33 | +------------+--------------------------------+-----------+ 34 | | 0 | DTMF digit "0" | [RFC4733] | 35 | | 1 | DTMF digit "1" | [RFC4733] | 36 | | 2 | DTMF digit "2" | [RFC4733] | 37 | | 3 | DTMF digit "3" | [RFC4733] | 38 | | 4 | DTMF digit "4" | [RFC4733] | 39 | | 5 | DTMF digit "5" | [RFC4733] | 40 | | 6 | DTMF digit "6" | [RFC4733] | 41 | | 7 | DTMF digit "7" | [RFC4733] | 42 | | 8 | DTMF digit "8" | [RFC4733] | 43 | | 9 | DTMF digit "9" | [RFC4733] | 44 | | 10 | DTMF digit "*" | [RFC4733] | 45 | | 11 | DTMF digit "#" | [RFC4733] | 46 | | 12 | DTMF digit "A" | [RFC4733] | 47 | | 13 | DTMF digit "B" | [RFC4733] | 48 | | 14 | DTMF digit "C" | [RFC4733] | 49 | | 15 | DTMF digit "D" | [RFC4733] | 50 | +------------+--------------------------------+-----------+ 51 | ``` 52 | 53 | For all cases where the endpoint is able to process audio at a sampling rate higher than 8 kHz, it is RECOMMENDED that Opus be offered before PCMA/PCMU. For Opus, all modes MUST be supported on the decoder side. The choice of encoder-side modes is left to the implementer. Endpoints MAY use the offer/answer mechanism to signal a preference for a particular mode or ptime. 54 | 55 | For additional information on implementing codecs other than the mandatory-to-implement codecs listed above, refer to [RFC7875]. 56 | 57 | ## 4. Audio Level 58 | 59 | It is desirable to standardize the "on the wire" audio level for speech transmission to avoid users having to manually adjust the playback and to facilitate mixing in conferencing applications. It is also desirable to be consistent with ITU-T Recommendations G.169 and G.115, which recommend an active audio level of -19 dBm0. However, unlike G.169 and G.115, the audio for WebRTC is not constrained to have a passband specified by G.712 and can in fact be sampled at any sampling rate from 8 to 48 kHz and higher. For this reason, the level SHOULD be normalized by only considering frequencies above 300 Hz, regardless of the sampling rate used. The level SHOULD also be adapted to avoid clipping, either by lowering the gain to a level below -19 dBm0 or through the use of a compressor. 60 | 61 | Assuming linear 16-bit PCM with a value of +/-32767, -19 dBm0 corresponds to a root mean square (RMS) level of 2600. Only active speech should be considered in the RMS calculation. If the endpoint has control over the entire audio-capture path, as is typically the case for a regular phone, then it is RECOMMENDED that the gain be adjusted in such a way that an average speaker would have a level of 2600 (-19 dBm0) for active speech. If the endpoint does not have control over the entire audio capture, as is typically the case for a software endpoint, then the endpoint SHOULD use automatic gain control (AGC) to dynamically adjust the level to 2600 (-19 dBm0) +/-6 dB. For music- or desktop-sharing applications, the level SHOULD NOT be automatically adjusted, and the endpoint SHOULD allow the user to set the gain manually. 62 | 63 | The RECOMMENDED filter for normalizing the signal energy is a second-order Butterworth filter with a 300 Hz cutoff frequency. 64 | 65 | It is common for the audio output on some devices to be "calibrated" for playing back pre-recorded "commercial" music, which is typically around 12 dB louder than the level recommended in this section. Because of this, endpoints MAY increase the gain before playback. 66 | 67 | ## 5. Acoustic Echo Cancellation (AEC) 68 | 69 | It is plausible that the dominant near-to-medium-term WebRTC usage model will be people using the interactive audio and video capabilities to communicate with each other via web browsers running on a notebook computer that has a built-in microphone and speakers. The notebook-as-communication-device paradigm presents challenging echo cancellation problems, the specific remedy of which will not be mandated here. However, while no specific algorithm or standard will be required by WebRTC-compatible endpoints, echo cancellation will improve the user experience and should be implemented by the endpoint device. 70 | 71 | WebRTC endpoints SHOULD include an AEC or some other form of echo control. On general-purpose platforms (e.g., a PC), it is common for the analog-to-digital converter (ADC) for audio capture and the digital-to-analog converter (DAC) for audio playback to use different clocks. In these cases, such as when a webcam is used for capture and a separate soundcard is used for playback, the sampling rates are likely to differ slightly. Endpoint AECs SHOULD be robust to such conditions, unless they are shipped along with hardware that guarantees capture and playback to be sampled from the same clock. 72 | 73 | Endpoints SHOULD allow the entire AEC and/or the nonlinear processing (NLP) to be turned off for applications, such as music, that do not behave well with the spectral attenuation methods typically used in NLP. Similarly, endpoints SHOULD have the ability to detect the presence of a headset and disable echo cancellation. 74 | 75 | For some applications where the remote endpoint may not have an echo canceller, the local endpoint MAY include a far-end echo canceller, but when included, it SHOULD be disabled by default. 76 | 77 | ## 6. Legacy VoIP Interoperability 78 | 79 | The codec requirements above will ensure, at a minimum, voice interoperability capabilities between WebRTC endpoints and legacy phone systems that support G.711. 80 | 81 | ## 7. Security Considerations 82 | 83 | For security considerations regarding the codecs themselves, please refer to their specifications, including [RFC6716], [RFC7587], [RFC3551], [RFC3389], and [RFC4733]. Likewise, consult the RTP base specification for RTP-based security considerations. WebRTC security is further discussed in [WebRTC-SEC], [WebRTC-SEC-ARCH], and [WebRTC-RTP-USAGE]. 84 | 85 | Using the guidelines in [RFC6562], implementers should consider whether the use of variable bitrate is appropriate for their application. Encryption and authentication issues are beyond the scope of this document. 86 | -------------------------------------------------------------------------------- /script/check-updates.js: -------------------------------------------------------------------------------- 1 | const { exec } = require('child_process'); 2 | const { readdir } = require('fs'); 3 | 4 | (async function() { 5 | const currentDrafts = await readCurrentDrafts().catch(console.error); 6 | const nextDraftUrls = currentDrafts.map(({ id, ver }) => { 7 | const nextVer = String(ver + 1).padStart(2, '0'); 8 | return `https://tools.ietf.org/html/${id}-${nextVer}`; 9 | }); 10 | 11 | const numOfDratfs = nextDraftUrls.length; 12 | console.log(`checking new version for ${numOfDratfs} drafts...`); 13 | console.log(''); 14 | 15 | const found = []; 16 | await Promise.all(nextDraftUrls.map(url => { 17 | console.log('fetch', url); 18 | return fetchStatusCode(url).then(statusCode => { 19 | if (statusCode === 200) { 20 | found.push(url); 21 | } 22 | }); 23 | })).catch(console.error); 24 | 25 | console.log(''); 26 | if (found.length === 0) { 27 | console.log('All drafts are still fresh! ;D'); 28 | return; 29 | } 30 | 31 | console.log(`${found.length} updated drafts were found!`); 32 | for (const url of found) { 33 | console.log(url); 34 | } 35 | }()); 36 | 37 | 38 | function readCurrentDrafts() { 39 | return new Promise((resolve, reject) => { 40 | readdir('./markdown', (err, items) => { 41 | if (err) { 42 | reject(err); 43 | } 44 | 45 | const drafts = items.filter(fName => fName.startsWith('draft')) 46 | .map(fName => { 47 | const [id] = fName.split('.md'); 48 | const frags = id.split('-'); 49 | const ver = frags.pop(); 50 | return { id: frags.join('-'), ver: parseInt(ver) }; 51 | }); 52 | 53 | resolve(drafts); 54 | }); 55 | }); 56 | } 57 | 58 | function fetchStatusCode(url) { 59 | return new Promise((resolve, reject) => { 60 | exec([ 61 | 'curl', 62 | '-s', 63 | url, 64 | '-o /dev/null', 65 | '-w \'%{http_code}\'', 66 | ].join(' '), (err, stdout, stderr) => { 67 | if (err || stderr) { 68 | reject(err || stderr); 69 | } 70 | resolve(parseInt(stdout.toString())); 71 | }); 72 | }); 73 | } 74 | -------------------------------------------------------------------------------- /script/init-markdown.js: -------------------------------------------------------------------------------- 1 | const fs = require('fs'); 2 | const { execFile } = require('child_process'); 3 | 4 | const [,, name] = process.argv; 5 | 6 | const md = ` 7 | > Read [original](https://tools.ietf.org/html/${name}) / [summary](../summary/${name}.md) 8 | 9 | --- 10 | 11 | # Xxx 12 | `.trim(); 13 | 14 | fs.writeFileSync(`./markdown/${name}.md`, md); 15 | console.log(`./markdown/${name}.md`, 'created.'); 16 | execFile('open', [`./markdown/${name}.md`]); 17 | -------------------------------------------------------------------------------- /script/init-summary.js: -------------------------------------------------------------------------------- 1 | const fs = require('fs'); 2 | const { execFile } = require('child_process'); 3 | 4 | const [,, targetPath] = process.argv; 5 | const fname = targetPath.split('/').pop(); 6 | const [name] = fname.split('.'); 7 | 8 | const md = fs.readFileSync(`./markdown/${fname}`, { encoding: 'utf8' }); 9 | 10 | const toc = []; 11 | for (const line of md.split('\n')) { 12 | if (line.startsWith('#')) { 13 | toc.push(line); 14 | } 15 | } 16 | 17 | const summary = ` 18 | > Read [original](https://tools.ietf.org/html/${name}) / [markdown](../markdown/${fname}) 19 | 20 | --- 21 | 22 | ${toc.join('\n\n')} 23 | `.trim(); 24 | 25 | fs.writeFileSync(`./summary/${fname}`, summary); 26 | console.log(`./summary/${fname}`, 'created.'); 27 | execFile('open', [`./summary/${fname}`]); 28 | -------------------------------------------------------------------------------- /summary/draft-ietf-ice-pac-03.md: -------------------------------------------------------------------------------- 1 | > Read [original](https://tools.ietf.org/html/draft-ietf-ice-pac-03) / [markdown](../markdown/draft-ietf-ice-pac-03.md) 2 | 3 | --- 4 | 5 | # ICE Patiently Awaiting Connectivity 6 | 7 | ## 1. Introduction 8 | 9 | - ICEというプロトコルでUDPベースのやり取りを開始できる 10 | - RFC8445参照 11 | - ICEでは、エンドポイントが互いに候補を出してペアを作る 12 | - そしてそのペアで疎通を確認する 13 | - もし全て失敗したら、ICEが失敗したといえる 14 | - この疎通確認の過程で、副産物として新たな候補が見つかることがある 15 | - `prflx`な候補と呼ばれる 16 | - ただこの場合でも、候補ペアの確認を終えて全て失敗していたら、ICEは失敗となる 17 | - `prflex`の候補をリストに加える前に、全行程が終了してしまう 18 | - この文書は、これを回避したいための仕様 19 | - とはいってもICEの状態を`failed`にする前に、少し待機するだけ 20 | 21 | ## 2. Conventions 22 | 23 | - いつもの 24 | 25 | ## 3. Relevant Scenarios 26 | 27 | - ICEの失敗条件 28 | - リモート・ローカルで候補の収集が終わっていて 29 | - 有効なペアがなく、これ以上チェックすべき候補もない場合 30 | - `prflx`な候補を見つけるまでの猶予がないのが問題 31 | - だいたいのICEのユースケースなら、10秒も待てばOK 32 | 33 | ### 3.1. No Candidates From Peer 34 | 35 | - そもそも候補が0件の場合 36 | - ICEの仕様としては問題ないケース 37 | - 候補がなくとも疎通できるとわかっている場合は不要なので 38 | - ただし、RFC8445に準拠すると、即`failed`になるけど 39 | 40 | ### 3.2. All Candidates Discarded 41 | 42 | - 全ての候補が捨てられる場合 43 | - IPv6非対応なエンドポイントで、IPv6の候補が見つかったときなど 44 | - これもおなじく`failed`になる 45 | 46 | ### 3.3. Immediate Candidate Pair Failure 47 | 48 | - いくつかの状況で、ペアが`failed`扱いにされることがある 49 | - RFC8445のSection 7.2.5.2を参照 50 | - その場合もICEはうまくいかない 51 | 52 | ## 4. Update to RFC 8445 53 | 54 | - これらを踏まえて、`prflx`な候補のために待ち時間を設けたい 55 | - ICE-Fullのエンドポイントは、`PAC`タイマーをセットすることとする 56 | - タイマーはICEの疎通確認をはじめるときにスタートする 57 | - 実際にSTUNを送信・受信するタイミングではない 58 | - その準備ができたタイミング 59 | - タイマーの値のおすすめは、トランザクションのタイムアウト値と同じ 60 | - `prflx`が返ってくるなら、その時間内に返ってくるから 61 | - このタイマーが有効な間、チェックリストの状態を`failed`にしてはいけない 62 | - RFC8445では、従来通りにペアを見つけてノミネートするまでの時間に制約はなかった 63 | - ただし`prflx`がベストな経路であるならば、それを使うべきである 64 | - なのでノミネートする前に、このタイマーの間は待機するべき 65 | - ノミネートは今まで通り`CONTROLLING`なエンドポイントが行う 66 | - もしかしたら、独自の判断で、タイマーを待たずにノミネートするかもしれない 67 | 68 | ## 5. Update to RFC XXXX 69 | 70 | - そのほかの関連仕様への影響 71 | - draft-ietf-ice-trickle 72 | - `failed`に移行する前に新たな候補が提示されるかもしれない 73 | - なので`end-of-candidates`がわかるまで待機すると書かれている 74 | - TrickleICEでも、ここで触れる内容は当てはまる 75 | - `end-of-candidates`を通知することは推奨であり必須要件ではないことに注意 76 | - なのでこの通知なしに、全ての候補を受信したというタイミングを決めてる実装があるかも 77 | - この`PAC`タイマーでもって、そのタイミングを決めることもできるだろう 78 | 79 | ## 6. Security Considerations 80 | 81 | - RFC8445の内容に準ずる 82 | 83 | ## 7. IANA considerations 84 | 85 | - IANAは関係ない 86 | -------------------------------------------------------------------------------- /summary/draft-ietf-ice-trickle-21.md: -------------------------------------------------------------------------------- 1 | > Read [original](https://tools.ietf.org/html/draft-ietf-ice-trickle-21) / [markdown](../markdown/draft-ietf-ice-trickle-21.md) 2 | 3 | --- 4 | 5 | # Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol 6 | 7 | ## 1. Introduction 8 | 9 | - ICEの基本 10 | - 候補を集める 11 | - 交換する 12 | - nominatedからselectedを選ぶ 13 | - しばしばSTUNへの問い合わせやTURNの割当など時間がかかる 14 | - 非同期に行われるものではあるけど 15 | - ここではTrickleICEという手法を解説 16 | - 集めた候補をすぐに交換する 17 | - 疎通確認もすぐにやる 18 | 19 | ## 2. Terminology 20 | 21 | - いつもの 22 | 23 | ## 3. Determining Support for Trickle ICE 24 | 25 | - まずそもそもサポートしてるかどうか 26 | - サポート状況がわからない場合、Half-Trickleという手法に沿ってもよい 27 | - Section 16.で解説 28 | - 明示的にサポートしてないとわかったら、通常のICEにしなければならない 29 | - SDPにICEオプションとして`trickle`と書くことでサポートしてることを明示できる 30 | 31 | ## 4. Generating the Initial ICE Description 32 | 33 | - UIなどで指示するよりも先に、candidateを集めることもできる 34 | - Half-Trickleを明示していないなら 35 | - そして集められた候補は、最初のICEの情報（ufrag/passwordなど）と一緒に送っても良い 36 | 37 | ## 5. Handling the Initial ICE Description and Generating the Initial ICE Response 38 | 39 | - 最初のICEの情報を受け取ったら、`trickle`にオプションがあるかチェック 40 | - 明示的なサポートがわからないなら、通常のICEを開始する 41 | - レスポンス側も、事前にcandidateを集めておいてよい 42 | 43 | ## 6. Handling the Initial ICE Response 44 | 45 | - ICEの役割やその後の手順は通常と同じ 46 | 47 | ## 7. Forming Check Lists 48 | 49 | - チェックリストの作成 50 | - 優先度による並べ替えや冗長な経路の削除も同じように 51 | - 通常のICEだと、このチェックリストが必要になった時に既にcandidateはあるはず 52 | - Trickleの場合は非同期なので、初期状態は空っぽ 53 | - チェックリストの状態はRunning 54 | 55 | ## 8. Performing Connectivity Checks 56 | 57 | - 疎通確認のタイマーが発火したときに、対象となるチェックリストはRunningのもの 58 | - なのでTrickleで扱うチェックリストの状態もRunningにしておく 59 | - タイマーが動いて拾ったリストが空なら、それをスキップして次のリストを処理する 60 | - チェックリストの状態を更新で、以下に合致すると状態がFailedになる 61 | - リスト内のペアがすべてFailed or Succeeded 62 | - リストにペアがない 63 | - Trickleだとこのパターンにハマりがちなので、以下の条件を追加する 64 | - ローカルのcandidateの収集が終わっている 65 | - リモートのcandidateの収集も終わっている 66 | 67 | ## 9. Gathering and Conveying Newly Gathered Local Candidates 68 | 69 | - STUNやTURN経由の候補は、しばしば遅れて非同期で集まる 70 | - それぞれ通常のICE通りに優先度やbaseやcomponentIDを計算する 71 | - 冗長な候補の削除ももちろん行う 72 | - ただしTrickleの場合、優先度よりも新しいものを冗長と判断する 73 | - そうして見つかったものがリモートに送られる 74 | - この間にICEがリスタートしたら、その候補は無視されるべき 75 | 76 | ## 10. Pairing Newly Gathered Local Candidates 77 | 78 | - 集めた候補はペアにする 79 | - これも通常のICEと同じ 80 | - ただしここにも条件が増える 81 | - 送信するまでペアにしてはいけない 82 | - ペアにしようとしているcomponentについて、リモートのcandidateがわかっている必要がある 83 | - 冗長なペアを削除するときも、WaitingかFrozenのもののみ 84 | - リストのペアは100までなので余りを捨てる 85 | 86 | ## 11. Receiving Trickled Candidates 87 | 88 | - Trickleなcandidateは受け取り側も同じように処理する 89 | - ローカルのcandidateが用意できるまでペアにしないとか 90 | - 冗長なペアを見つけたとき、リモートがprflexならそれを削除 91 | - 削除したペアの優先度を、残す方のペアの優先度にする 92 | - リストのペアは100までなので余りを捨てる 93 | 94 | ## 12. Inserting Trickled Candidate Pairs into a Check List 95 | 96 | - リストに追加されたペアがどう処理されていくか図で説明 97 | 98 | ## 13. Generating an End-of-Candidates Indication 99 | 100 | - candidate収集の終了をどう明示するか 101 | - すべてのcandidateが集め終わったら 102 | - ICEのセッションが期限切れになったら 103 | - なんらかの方法でそれを伝える 104 | - できればcontrollingから 105 | - もちろん収集の途中でやめるのを宣言してもいい 106 | - その後はcandidateを収集してはいけない 107 | 108 | ## 14. Receiving an End-of-Candidates Indication 109 | 110 | - 終了の意志を受け取ったら 111 | - チェックリストの状態を更新しvalidペアがないならICEは失敗 112 | 113 | ## 15. Subsequent Exchanges and ICE Restarts 114 | 115 | - candidateをやりとりする過程で、ufragやpasswordの変化に気づくかも 116 | - それはICEリスタートを意味する 117 | - Trickleなセッションは、リスタート後もTrickleが有効 118 | 119 | ## 16. Half Trickle 120 | 121 | - リモートがTrickleをサポートしてるかわからない時に使う 122 | - controlling側は、Trickleではなく普通にcandidateを集めてから送る 123 | - 全てではなく一部のcandidate 124 | - そのときにTrickleをサポートしてると伝えられる 125 | - リモートはそれを見てTrickleすることができる 126 | - Halfだとしても、UXの改善になる 127 | 128 | ## 17. Preserving Candidate Order while Trickling 129 | 130 | - Trickleだとローカルとリモートでの疎通確認が必ずしも同期で行われない 131 | - だいたいのタイミング的な意味で 132 | - candidateを適切に並べ替えることで、ある程度そこをsyncできる 133 | - componentIDの小さい順に 134 | 135 | ## 18. Requirements for Using Protocols 136 | 137 | - Trickle ICEを実現するためにプロトコルに求められること 138 | - サポート状況の通知 139 | - candidateを逐次伝える仕組み 140 | - 送信順の保証など 141 | 142 | ## 19. IANA Considerations 143 | 144 | - 新しいICEオプションを追加した 145 | - `trickle` 146 | 147 | ## 20. Security Considerations 148 | 149 | - ICEでのセキュリティへの懸念を引き継ぐ 150 | -------------------------------------------------------------------------------- /summary/draft-ietf-mmusic-ice-sip-sdp-39.md: -------------------------------------------------------------------------------- 1 | > Read [original](https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-39) / [markdown](../markdown/draft-ietf-mmusic-ice-sip-sdp-39.md) 2 | 3 | --- 4 | 5 | # SDP Offer/Answer procedures for ICE 6 | 7 | ## 1. Introduction 8 | 9 | - ICEがオファー・アンサーでどう使われるかについて 10 | 11 | ## 2. Conventions 12 | 13 | - いつもの 14 | 15 | ## 3. Terminology 16 | 17 | - ICEを使わない場合のデフォルトの値について 18 | - RTPなら`c=`行のアドレスと、`m=`行のプロトコルとポート 19 | - RTCPなら`a=rtcp`属性から 20 | - それがない場合は、RTPより1大きいポート 21 | 22 | ## 4. SDP Offer/Answer Procedures 23 | 24 | - 本文なし 25 | 26 | ### 4.1. Introduction 27 | 28 | - ICEの仕様にある用語と、オファー・アンサーの仕様にある用語を対照する 29 | - RFC8445 30 | - RFC3264 31 | - ICEの処理は、候補が集まってからはじめる 32 | 33 | ### 4.2. Generic Procedures 34 | 35 | - 本文なし 36 | 37 | #### 4.2.1. Encoding 38 | 39 | - Section 5でSDPの属性の詳細に触れる 40 | 41 | ##### 4.2.1.1. Data Streams 42 | 43 | - `m=`セクションによって、どのようなデータをやり取りしたいかがわかる 44 | 45 | ##### 4.2.1.2. Candidates 46 | 47 | - `m=`セクションごとに送信経路の候補情報をつける 48 | - 経路が決まる前は、`c=`行にデフォルト候補のIPが記載される 49 | - ポートとプロトコルは、`m=`行に 50 | - 経路が決まると、その候補のIPとポートとプロトコルになる 51 | 52 | ##### 4.2.1.3. Username and Password 53 | 54 | - ICEのユーザー名は、`a=ice-ufrag`属性 55 | - ICEのパスワードは、`a=ice-pwd`属性 56 | 57 | ##### 4.2.1.4. Lite Implementations 58 | 59 | - ICE-Liteの実装は`a=ice-lite`属性をつける 60 | - ICE-Fullの実装はつけてはならない 61 | 62 | ##### 4.2.1.5. ICE Extensions 63 | 64 | - その他のICEのオプションに関しては、`a=ice-options`属性で表す 65 | - この仕様を満たす実装は、`a=ice-options:ice2`をつける 66 | - そうでない場合は、RFC5245までをサポートしているはず 67 | 68 | ##### 4.2.1.6. Inactive and Disabled Data Streams 69 | 70 | - `m=`セクションが`inactive`の場合や、帯域の指定が`0`の場合は、その他の属性を残す 71 | - しかし`m=`行のポートが`0`にされた場合は、その他の属性をつけるべきではない 72 | 73 | #### 4.2.2. RTP/RTCP Considerations 74 | 75 | - RTP/RTCPを多重化する場合は、両方に関する属性を同じ`m=`セクションに含める 76 | - 別にポートを使う場合は、`a=rtcp`属性で指定する 77 | - その場合はRTPの`ポート番号 + 1` 78 | - RTCPをそもそも使わない場合は、`b=RS:0`や`b=RR:0`をつける 79 | 80 | #### 4.2.3. Determining Role 81 | 82 | - オファー側からICEの処理を開始する 83 | - ICEの役割はICEの仕様通りに決まる 84 | - Full-Fullの場合は、オファー側が`CONTROLLING` 85 | - Full-Liteの場合は、Full側が`CONTROLLING` 86 | 87 | #### 4.2.4. STUN Considerations 88 | 89 | - SDPで経路の候補をオファー・アンサーしたら、いつSTUNのパケットが送信されてもよいように 90 | 91 | #### 4.2.5. Verifying ICE Support Procedures 92 | 93 | - SDPに`ice-pwd`と`ice-ufrag`属性があるならば、ICEをサポートしてると推測できる 94 | - 本仕様を満たすならば、同時に`ice-options:ice2`も必要 95 | - 受け取ったSDPの各ストリームごとにICEの処理をすすめる 96 | - RTPのストリームの場合、`a=candidate`には`c=`行のIPと`m=`行のポートが記載される 97 | - 特定のGWを通ると、アドレス情報が書き換えられるかもしれない 98 | - その場合は、書き換えられたアドレスを使って処理を続けてもよいし 99 | - `a=ice-mismatch`を返すかも 100 | - デフォルトのトランスポートアドレスは、`0.0.0.0:9` 101 | 102 | #### 4.2.6. SDP Example 103 | 104 | - ここまで紹介した属性がついたSDPの例 105 | 106 | ### 4.3. Initial Offer/Answer Exchange 107 | 108 | - 本文なし 109 | 110 | #### 4.3.1. Sending the Initial Offer 111 | 112 | - オファー側が初期オファーを生成するとき 113 | - `ice-ufrag`と`ice-pwd`属性が必須 114 | - ICE-Fullなら、`ice-pacing`属性も必要 115 | - 省略した場合はデフォルトの値 116 | - ICE-Liteなら不要 117 | - 初期オファーに経路情報が載らないこともある 118 | - それは`prflx`だけを使うつもりという意味 119 | 120 | #### 4.3.2. Sending the Initial Answer 121 | 122 | - 初期オファーへのアンサーを送信するとき 123 | - こちらも`ice-ufrag`と`ice-pwd`属性が必須 124 | - ICE-Fullなら、`ice-pacing`属性も必要 125 | - 省略した場合はデフォルトの値 126 | - ICE-Liteなら不要 127 | - アンサーでは、オファーと同じプロトコルで`m=`行を用意する 128 | - アンサーを送信したら、接続確認をはじめられる 129 | - ICEを使えない場合は、それにまつわる属性をつけてアンサーしてはいけない 130 | - ICEミスマッチに対する処理はSection 4.2.5 131 | 132 | #### 4.3.3. Receiving the Initial Answer 133 | 134 | - 初期オファーに対する初期アンサーを受け取ったら 135 | - 接続確認をはじめられる 136 | - ICEミスマッチに対する処理はSection 4.2.5 137 | 138 | #### 4.3.4. Concluding ICE 139 | 140 | - ICEの処理が終わって、経路が決まったら、それをSDPと照らし合わせる 141 | - ローカルのICEの情報と、SDPに記載の情報 142 | - `ice2`をサポートしている場合、その経路はデフォルトの経路として以降のセッションで使われる 143 | - リスタートされるまで 144 | - サポートしていない場合は、追ってオファーを生成する 145 | - ICEのチェックリストでFailedになったものがあるなら 146 | - 該当する`m=`セクションのポート値を`0`にしてオファーを再送 147 | - draft-ietf-ice-pacをサポートすれば、`prflx`な候補を見つけられる可能性は高まる 148 | 149 | ### 4.4. Subsequent Offer/Answer Exchanges 150 | 151 | - セッション開始後のオファー・アンサーについて 152 | 153 | #### 4.4.1. Sending Subsequent Offer 154 | 155 | - 本文なし 156 | 157 | ##### 4.4.1.1. Procedures for All Implementations 158 | 159 | - 本文なし 160 | 161 | ###### 4.4.1.1.1. ICE Restart 162 | 163 | - `c=`行のIPを`0.0.0.0` OR `::`にセットすることは、ICEのリスタートを意味する 164 | - この仕組みは保留のために使ってはならず、そのためには`a=inactive`や`a=sendonly`を使う 165 | - リスタートしたら、`ice-ufrag`と`ice-pwd`を更新する 166 | 167 | ###### 4.4.1.1.2. Removing a Data Stream 168 | 169 | - `m=`行のポートを`0`にしてストリームを削除したなら、その他の属性はつけてはいけない 170 | 171 | ###### 4.4.1.1.3. Adding a Data Stream 172 | 173 | - ストリームを追加する場合 174 | - 初期オファーと同じように（通常通り） 175 | 176 | ##### 4.4.1.2. Procedures for Full Implementations 177 | 178 | - ICE-Fullの実装向けの追加の手順について 179 | 180 | ###### 4.4.1.2.1. Before Nomination 181 | 182 | - 経路確定前 183 | - 初期オファー・アンサーと同じICEの属性をつける 184 | - `prflx`の候補などは追加されるかも 185 | - デフォルトの経路は変更するかも 186 | 187 | ###### 4.4.1.2.2. After Nomination 188 | 189 | - 経路確定後 190 | - そのストリームについては確定した経路のみを含める 191 | - その他の候補は含めてはいけない 192 | - `CONTROLLING`の側は、確定している証として`a=remote-candidates`属性をつける 193 | 194 | ##### 4.4.1.3. Procedures for Lite Implementations 195 | 196 | - ICE-Liteの実装向けの追加の手順について 197 | - ICEの処理が途中の場合は、すべての経路候補をつける 198 | - Lite実装の場合は、その後のオファー・アンサーの際に、あらたな候補を追加してはいけない 199 | - そうしたい場合はリスタートが必要 200 | 201 | #### 4.4.2. Sending Subsequent Answer 202 | 203 | - オファーに`a=remote-candidates`属性がない場合は、オファー側と同じ手順（通常通り） 204 | - ただし`a=remote-candiadtes`を含めてはいけない 205 | - `CONTROLLED`側は`a=remote-candidates`つきのオファーを受け取るかもしれないし 206 | - ICEで確定した経路情報を知るかもしれない（オファー側で既にICEが完了している場合） 207 | - このケースの詳細はAppendix Bにて 208 | - 以下の組み合わせでペアを形成する 209 | - リモート: オファー側のデフォルト（`m=`行のポートと`c=`行のIP） 210 | - ローカル: `a=remote-candidates`と同じトランスポートの経路 211 | - そしてこのペアがValidリストにいるかチェックし、ない場合はLosingペアとする 212 | 213 | ##### 4.4.2.1. ICE Restart 214 | 215 | - ICEをリスタートするときは、改めて初期オファーを送る 216 | - アンサー側はそれまでと同じ経路情報を提示してもよい 217 | - `ice-ufrag`と`ice-pwd`は更新する必要がある 218 | 219 | ##### 4.4.2.2. Lite Implementation specific procedures 220 | 221 | - Lite実装の場合 222 | - 以下の組み合わせでペアを形成する 223 | - リモート: オファー側のデフォルト（`m=`行のポートと`c=`行のIP） 224 | - ローカル: `a=remote-candidates`と同じトランスポートの経路 225 | - ICEの処理を完了とする 226 | 227 | #### 4.4.3. Receiving Answer for a Subsequent Offer 228 | 229 | - 本文なし 230 | 231 | ##### 4.4.3.1. Procedures for Full Implementations 232 | 233 | - 最初のアンサーにはICEの属性があったのに、後続のアンサーでそれがなくなってた場合 234 | - B2BUA (Back-to-Back User Agent) などの場合にありえる 235 | - 基本的にこれは予期してないパターンである 236 | - リスタートの場合は、リスタートする 237 | - ストリームの削除・拒否された場合は、Validリストを空にしてSTUNの処理も止める 238 | - ストリームの追加は、通常通りの手順で 239 | - ICEが実行中の場合は、チェックリストを再度作り直すところから 240 | 241 | ###### 4.4.3.1.1. ICE Restarts 242 | 243 | - リスタートする前に、ストリームごとの確定していた経路情報を記憶しておく 244 | - リスタートが完了するまでは、その経路でデータを送受信し続ける 245 | 246 | ##### 4.4.3.2. Procedures for Lite Implementations 247 | 248 | - 新たなValidリストを作り直す 249 | - リスタートが完了するまでは、その経路でデータを送受信し続ける 250 | 251 | ## 5. Grammar 252 | 253 | - この仕様で追加される新たなSDPの属性について 254 | - `candidate` 255 | - `remote-candidates` 256 | - `ice-lite` 257 | - `ice-mismatch` 258 | - `ice-ufrag` 259 | - `ice-pwd` 260 | - `ice-pacing` 261 | - `ice-options` 262 | 263 | ### 5.1. "candidate" Attribute 264 | 265 | - `a=candidate` 266 | - メディアレベル限定 267 | - STUNの接続確認で使われる情報を含む 268 | - `port`: IPv4かIPv6かは、アドレスに含まれる`:`で判定する 269 | - IPv6をサポートしてない場合などは、そのcandidateを無視する 270 | - `transport`: 現状は`UDP`のみだが、将来的には拡張される 271 | - `foundation`: アルファベットと数字と`+`と`/`から成る1-32文字 272 | - `component-id`: 1-256の数値 273 | - `1`からはじまってインクリメントされていく 274 | - `rel-addr`/`rel-port`: `srflx`と`prflx`と`relay`のときに必要 275 | - `host`のときにはつけてはいけない 276 | - プライバシー保護などIPを開示したくない場合は、IPは`0.0.0.0` OR `::`でポートは`9`に 277 | 278 | ### 5.2. "remote-candidates" Attribute 279 | 280 | - `a=remote-candidates` 281 | - メディアレベル限定 282 | - `CONTROLLING`側のオファーにのみ記載される 283 | 284 | ### 5.3. "ice-lite" and "ice-mismatch" Attributes 285 | 286 | - `a=ice-lite` 287 | - セッションレベル限定 288 | - `a=ice-mismatch` 289 | - メディアレベル限定 290 | 291 | ### 5.4. "ice-ufrag" and "ice-pwd" Attributes 292 | 293 | - どちらも 294 | - メディアレベルかセッションレベルかどちらか 295 | - 両方に出たらメディアレベル優先 296 | - `a=ice-ufrag` 297 | - 最低でも24bitのランダムな値 298 | - = 最低でも4文字 299 | - 最長256文字だが32文字くらいまでがベター 300 | - `a=ice-pwd` 301 | - 最低でも128bitランダムな値 302 | - = 最低でも22文字 303 | 304 | ### 5.5. "ice-pacing" Attribute 305 | 306 | - `a=ice-pacing` 307 | - セッションレベル限定 308 | - 接続確認のタイマーの間隔を指定するための値 309 | - デフォルトは`50ms` 310 | 311 | ### 5.6. "ice-options" Attribute 312 | 313 | - `a=ice-options` 314 | - セッションレベル、メディアレベル 315 | - オファーにそれがある場合は、サポートしておりその機能を使いたい旨を表す 316 | 317 | ## 6. Keepalives 318 | 319 | - キープアライブはもちろん実行する 320 | - `inactive`でも`bandwidth`の指定も関係なく実行する 321 | 322 | ## 7. SIP Considerations 323 | 324 | - SIP関連のため割愛 325 | 326 | ### 7.1. Latency Guidelines 327 | 328 | - SIP関連のため割愛 329 | 330 | #### 7.1.1. Offer in INVITE 331 | 332 | - SIP関連のため割愛 333 | 334 | #### 7.1.2. Offer in Response 335 | 336 | - SIP関連のため割愛 337 | 338 | ### 7.2. SIP Option Tags and Media Feature Tags 339 | 340 | - SIP関連のため割愛 341 | 342 | ### 7.3. Interactions with Forking 343 | 344 | - SIP関連のため割愛 345 | 346 | ### 7.4. Interactions with Preconditions 347 | 348 | - SIP関連のため割愛 349 | 350 | ### 7.5. Interactions with Third Party Call Control 351 | 352 | - SIP関連のため割愛 353 | 354 | ## 8. Interactions with Application Layer Gateways and SIP 355 | 356 | - Application Layer Gateways (ALGs)との兼ね合い 357 | - NAT越えのために使われるもの 358 | - 基本的にはICEに問題はないはず 359 | - 問題があったら`a=ice-mismatch`を返すだけ 360 | - Session Border Controllers (SBCs)との兼ね合い 361 | - ICEのcandidateを削除してしまうかも 362 | - SDPに書かれたアドレスが外部のものであれば書き換えない 363 | - 内部のアドレスな場合は書き換えられる 364 | 365 | ## 9. Security Considerations 366 | 367 | - ICEに関してはRFC8445を参照 368 | - SDPのオファーアンサーに関してはRFC3264を参照 369 | 370 | ### 9.1. IP Address Privacy 371 | 372 | - アドレスとポートを公開したくないときもあるはず 373 | - その場合は、`0.0.0.0`か`::`と、ポートは`9`にする 374 | 375 | ### 9.2. Attacks on the Offer/Answer Exchanges 376 | 377 | - オファー・アンサーが攻撃者によって改ざんされるケース 378 | - TLSなどでセキュアにSDPをやり取りするように 379 | 380 | #### 9.3. The Voice Hammer Attack 381 | 382 | - 関係ないIP・ポートに対してパケットを送出させるよう仕組む攻撃 383 | - ICE特有の攻撃ではないけど 384 | - ICEの情報を受取ると、接続確認でパケットを送信するはずなので 385 | 386 | ## 10. IANA Considerations 387 | 388 | - 本文なし 389 | 390 | ### 10.1. SDP Attributes 391 | 392 | - 7つの新しいSDPの属性を定義した 393 | 394 | #### 10.1.1. candidate Attribute 395 | 396 | - `a=candidate` 397 | - メディアレベル 398 | 399 | #### 10.1.2. remote-candidates Attribute 400 | 401 | - `a=remote-candidates` 402 | - メディアレベル 403 | 404 | #### 10.1.3. ice-lite Attribute 405 | 406 | - `a=ice-lite` 407 | - セッションレベル 408 | 409 | #### 10.1.4. ice-mismatch Attribute 410 | 411 | - `a=ice-mismatch` 412 | - メディアレベル 413 | 414 | #### 10.1.5. ice-pwd Attribute 415 | 416 | - `a=ice-pwd` 417 | - セッションレベルかメディアレベル 418 | 419 | #### 10.1.6. ice-ufrag Attribute 420 | 421 | - `a=ice-ufrag` 422 | - セッションレベルかメディアレベル 423 | 424 | #### 10.1.7. ice-options Attribute 425 | 426 | - `a=ice-options` 427 | - セッションレベル 428 | 429 | #### 10.1.8. ice-pacing Attribute 430 | 431 | - `a=ice-pacing` 432 | - セッションレベル 433 | 434 | ### 10.2. Interactive Connectivity Establishment (ICE) Options Registry 435 | 436 | - `a=ice-options`の値は、20文字以下が推奨 437 | 438 | ### 10.3. Candidate Attribute Extension Subregistry Establishment 439 | 440 | - Candidate Attribute Extensionsを追加 441 | - 追加する場合はRFC8126にあるポリシーに従う 442 | 443 | ## Appendix A. Examples 444 | 445 | - SDPの例 446 | 447 | ## Appendix B. The remote-candidates Attribute 448 | 449 | - `a=remote-candidates`が存在する理由を示す例 450 | - R側がSTUNのレスポンスを受信できなかったとき 451 | - L側から確認できてることを伝えてあげる 452 | 453 | ## Appendix C. Why Is the Conflict Resolution Mechanism Needed? 454 | 455 | - お互いに`CONTROLLING` OR `CONTROLLED`だと認識してしまう場合について 456 | - シグナリングプレーンで解消できる問題ではある 457 | 458 | ## Appendix D. Why Send an Updated Offer? 459 | 460 | - オファーの更新がなぜ必要なのかについて 461 | - オファー・アンサーの結果を確信するために送ってるなら、不要ともいえる 462 | - ただし中継機など様々な要因を認識するために必須としている 463 | - WebRTCではつかってない 464 | -------------------------------------------------------------------------------- /summary/draft-ietf-mmusic-msid-17.md: -------------------------------------------------------------------------------- 1 | > Read [original](https://tools.ietf.org/html/draft-ietf-mmusic-msid-17) / [markdown](../markdown/draft-ietf-mmusic-msid-17.md) 2 | 3 | --- 4 | 5 | # WebRTC MediaStream Identification in the Session Description Protocol 6 | 7 | ## 1. Introduction 8 | 9 | - 本文なし 10 | 11 | ### 1.1. Terminology 12 | 13 | - いつもの 14 | 15 | ### 1.2. Structure Of This Document 16 | 17 | - RTPストリームにIDを振る、グルーピングするための仕様をSDPに追加する 18 | - WebRTCのための拡張である 19 | 20 | ### 1.3. Why A New Mechanism Is Needed 21 | 22 | - なぜ拡張が必要だったのか 23 | - RTPセッション中のRTPストリームは、SSRCによって一意に識別できた 24 | - そもそもRTPセッションは、トランスポートアドレスで別れているものだった 25 | - しかしWebRTCではBUNDLEすることができてしまう 26 | - SDPグルーピングについては、RFC5888 27 | - しかしそれはSDP内に閉じた話で、アプリケーションレベルでこれを知る必要が往々にしてある 28 | - そのためにこの拡張が必要 29 | 30 | ### 1.4. The WEBRTC MediaStream 31 | 32 | - WebRTCではメディアを`MediaStream`として扱い、`MediaStreamTrack`を含む 33 | - `MediaStreamTrack`は、RTPセッション中の単一のSSRCを表すもの 34 | - サイマルキャストなど、このSSRCが増えることもあるがそれはこの仕様と関係ない 35 | - そしてこれは一方通行なもの 36 | - RTPセッションでは、RTPストリームはSSRCで識別されつつ、CNAMEの情報を持ってる 37 | - しかしこのCNAMEもRTPセッションも、`MediaStream`とは対応していない 38 | - SDPにおける`m=`セクションは、それぞれが`MediaStreamTrack`と対応する 39 | - そしてBUNDLEされると、いくつかの`MediaStreamTrack`がRTPセッションとなる 40 | - そこで、どの`MediaStream`に`MediaStreamTrack`が属するかの情報が必要になる 41 | 42 | ## 2. The Msid Mechanism 43 | 44 | - `msid`属性をSDPのメディアレベルに追加する 45 | - `a=msid:{id} {appdata}` 46 | - `msid:examplefoo examplebar` 47 | - この場合は`examplefoo`というIDに、`examplebar`という値 48 | 49 | ## 3. Procedures 50 | 51 | - `msid`はどう決まるのか 52 | - `MediaStream`の`id`が、`{id}`に紐づく 53 | - `MediaStreamTrack`の`id`が、`{appdata}`に紐づく 54 | - `msid`の`{id}`が新たに増えた = 新たな`MediaStream`を受信したとわかる 55 | - `{appdata}`が新たに増えた = 新たな`MediaStreamTrack` 56 | - `{appdata}`がなく`{id}`だけ増えるパターンもある 57 | - その場合は受信側が自分で割り当てる 58 | - `{id}`が`-`の場合は、`MediaStream`がないことを表す 59 | - `MediaStreamTrack`の終了条件 60 | - `a=msid`が消えた時 61 | - すべてのSSRCでBYEパケットを受信したとき 62 | - タイムアウトしたとき 63 | - `m=`行のポートに`0`が指定されたとき 64 | 65 | ### 3.1. Handling of non-signalled tracks 66 | 67 | - `msid`を使用しない、紐付けないRTPパケットが送信されてくることもある 68 | - 既にセッションがあるときに、後から`MediaStreamTrack`を追加した場合 69 | - 再ネゴシエーションが発生して、アンサーが受領されるまでの間 70 | - = `RTCSignalingState`が`stable`でない間 71 | 72 | ### 3.2. Detailed Offer/Answer Procedures 73 | 74 | - オファー・アンサーについては別の仕様に詳細がある 75 | - RFC3264 76 | 77 | #### 3.2.1. Generating the initial offer 78 | 79 | - オファーのSDPに`a=msid`が載るまで 80 | - 送信したい`MediaStream`の数だけ定義する 81 | - `id`を`msid`の`{id}`に 82 | - 次いで、`MediaStreamTrack`の`id`を`{appdata}`に 83 | 84 | #### 3.2.2. Answerer processing of the Offer 85 | 86 | - アンサー側がどうするか 87 | - `{appdata}`でもって`MediaStreamTrack`のインスタンスを探す or 作る 88 | - `{id}`を使って`MediaStream`を探す or 作る 89 | - ユーザーに知らせる 90 | 91 | #### 3.2.3. Generating the answer 92 | 93 | - アンサーを発行するときは、オファーを発行するときと同じ 94 | - オファー側が影響を与えることはない 95 | 96 | #### 3.2.4. Offerer processing of the answer 97 | 98 | - 同上 99 | 100 | #### 3.2.5. Modifying the session 101 | 102 | - セッション中の再ネゴシエーションで注意点が1つだけある 103 | - `ended`になっていない`MediaStreamTrack`について 104 | - SDPにその`id`が`{appdata}`と同じものが存在するかチェック 105 | - 存在しなくなってたら、`ended`にしてしまう 106 | 107 | ### 3.3. Example SDP description 108 | 109 | - 2つの`MediaStream`を送る場合のSDPの例 110 | 111 | ## 4. IANA Considerations 112 | 113 | - 本文なし 114 | 115 | ### 4.1. Attribute registration in existing registries 116 | 117 | - `msid`属性をSDPの`att-field`に追加する 118 | - これはメディアレベル限定 119 | 120 | ## 5. Security Considerations 121 | 122 | - SDPを改ざんされるおそれはある 123 | - そうなるとバッファリング実装のメモリを枯渇させることができるかも 124 | - IDを生成するときも、UUIDのv3や4を使うなど推奨 125 | 126 | ## Appendix A. Design considerations, rejected alternatives 127 | 128 | - 代案について 129 | - CNAMEを使う案 130 | - CNAMEは`MediaStreamTrack`をsyncするためのもの 131 | - RTCPのSRパケットを使う案 132 | - 全ての`MediaStreamTrack`の状況を把握できない 133 | - `a=wms-semantic`という属性もあった 134 | - 2015年4月に削除された 135 | - 実際には`a=msid-semantic:WMS`から続く行 136 | - 今もChromeやFirefoxがSDPに載せてくる 137 | -------------------------------------------------------------------------------- /summary/draft-ietf-mmusic-mux-exclusive-12.md: -------------------------------------------------------------------------------- 1 | > Read [original](https://tools.ietf.org/html/draft-ietf-mmusic-mux-exclusive-12) / [markdown](../markdown/draft-ietf-mmusic-mux-exclusive-12.md) 2 | 3 | --- 4 | 5 | # Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP 6 | 7 | ## 1. Introduction 8 | 9 | - RFC5761で`a=rtcp-mux`を規定した 10 | - これによって、任意でRTP/RTCPが多重化できるようになった 11 | - 拒否もできる 12 | - WebRTCのような新しいアプリは、後方互換性が必要ない 13 | - そういう環境に限っては、多重化しないことをサポートしない旨を示すことができる 14 | - SDPのメディアレベルに`a=rtcp-mux-only`を記述する 15 | 16 | ## 2. Conventions 17 | 18 | - いつもの 19 | 20 | ## 3. SDP rtcp-mux-only Attribute 21 | 22 | - `a=rtcp-mux-only`をメディアレベルに追加 23 | - オファー側でのみ記述できる 24 | - RTPを使う場合のみ記述できる 25 | - SSRCごとの指定 = ソースレベルの指定はできない 26 | 27 | ## 4. SDP Offer/Answer Procedures 28 | 29 | - 本文なし 30 | 31 | ### 4.1. General 32 | 33 | - オファー・アンサーにおける影響について 34 | 35 | ### 4.2. Generating the Initial SDP Offer 36 | 37 | - 最初のオファーについて 38 | - `a=rtcp-mux-only`をメディアレベルに記述する 39 | - `a=rtcp-mux`もあわせて記述する 40 | 41 | ### 4.3. Generating the Answer 42 | 43 | - それに対するアンサーについて 44 | - 受け入れる場合 45 | - `a=rtcp-mux`をつけて返す 46 | - 拒否する場合 47 | - `m=`行のポートを`0`にして返す 48 | - オファー自体を拒否してもいい 49 | 50 | ### 4.4. Offerer Processing of the SDP Answer 51 | 52 | - オファー側がアンサーを処理するとき 53 | - 受け入れられた場合は今まで通りICEをはじめる 54 | - RTP/RTCPは多重化して 55 | - 拒否された場合は、おまかせ 56 | - 新たにオファーを再送するでもいいし 57 | - その際に`rtcp-mux-only`を外すとか 58 | 59 | ### 4.5. Modifying the Session 60 | 61 | - セッション確立後の再ネゴシエーションのとき 62 | - 過去に`rtcp-mux-only`で確立してるなら、引き続きそうするべき 63 | - ただし途中でやめることもできる 64 | - 基本的には一度多重化すると決めたなら、多重化し続けるべき 65 | 66 | ## 5. Update to RFC 5761 67 | 68 | - 本文なし 69 | 70 | ### 5.1. General 71 | 72 | - RFC5761からの変更点について 73 | - 多重化する場合は、RTCP用の`a=candidate`を載せない 74 | - `a=rtcp`も載せない 75 | 76 | ### 5.2. Update to 4th paragraph of section 5.1.1 77 | 78 | - 既に書かれた内容なので割愛 79 | 80 | ### 5.3. Update to 2nd paragraph of section 5.1.3 81 | 82 | - 既に書かれた内容なので割愛 83 | 84 | ## 6. ICE Considerations 85 | 86 | - 多重化することがわかってる場合 87 | - ICEのコンポーネントは1つだけになる 88 | - RTP用でコンポーネントIDは`1` 89 | - RTCPが純粋にサポートされてない場合も同じことになる 90 | - が、それで判断してはいけない 91 | - 判断はあくまで`rtcp-mux-only`でやる 92 | 93 | ## 7. Security Considerations 94 | 95 | - セキュリティに関しては特になし 96 | 97 | ## 8. IANA Considerations 98 | 99 | - SDPのメディアレベルに1つ追加する 100 | - `a=rtcp-mux-only` 101 | -------------------------------------------------------------------------------- /summary/draft-ietf-mmusic-sdp-bundle-negotiation-54.md: -------------------------------------------------------------------------------- 1 | > Read [original](https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-54) / [markdown](../markdown/draft-ietf-mmusic-sdp-bundle-negotiation-54.md) 2 | 3 | --- 4 | 5 | # Negotiating Media Multiplexing Using the SDP 6 | 7 | ## 1. Introduction 8 | 9 | - 本文なし 10 | 11 | ### 1.1. Background 12 | 13 | - SDPでオファー・アンサーしてセッションを確立する 14 | - 通常は`m=`セクションごとに異なるトランスポートを使う 15 | - これをまとめて1つのトランスポートで実現できれば、リソース効率の面で魅力的 16 | 17 | ### 1.2. BUNDLE Mechanism 18 | 19 | - まとめられる単一のトランスポートをBUNDLEトランスポートとする 20 | - メディアを送受信するアドレスとポート 21 | - SDPでBUNDLE用の属性を使う 22 | - `a=group:BUNDLE`を定義する 23 | - `m=`セクションをまとめあげる 24 | - ICEで確定する候補は1ペアだけになる 25 | - BUNDLEグループは複数あってもよい 26 | - 後方互換性があるので、BUNDLEできない場合は通常通りに別々にトランスポートを使う 27 | 28 | ### 1.3. Protocol Extensions 29 | 30 | - BUNDLEするときに使う`a=bundle-only`属性を追加する 31 | - その他のRFCへの更新は以下 32 | - 拒否するのではなく、`m=`行のポートに`0`を割り当てられるように 33 | - RFC3264 34 | - RTCPのSDES項目に`MID`を追加 35 | - RFC3550 36 | - およびそのヘッダ拡張 37 | - `MID`拡張のための例外を追加 38 | - RFC7941 39 | 40 | ## 2. Terminology 41 | 42 | - いつもの 43 | 44 | ## 3. Conventions 45 | 46 | - いつもの 47 | 48 | ## 4. Applicability Statement 49 | 50 | - この仕様に関する内容は、SDPを使ってオファー・アンサーを実施するときのみ有効 51 | 52 | ## 5. SDP Grouping Framework BUNDLE Extension 53 | 54 | - `a=group:BUNDLE`でBUNDLEする意志を表す 55 | - この属性自体は複数定義できる 56 | - ただし内包される`m=`セクションは、複数に属してはいけない 57 | - `a=group:BUNDLE foo bar` 58 | - `foo`がタグ付けされた、ベースとなる`m=`セクション 59 | - `bar`はBUNDLEされる`bundle-only`な`m=`セクション 60 | - オファー・アンサー手順の詳細はSection 7にて 61 | 62 | ## 6. SDP 'bundle-only' Attribute 63 | 64 | - `a=bundle-only`属性をメディアレベルに追加 65 | - 値はなし 66 | - アンサー側がBUNDLE非対応だった場合 67 | - 何もしなくても拒否されるように、`m=`行のポートに`0`を指定してオファーしてもよい 68 | - アンサー側がBUNDLE対応の場合は、`a=bundle-only`を見てそれを判別できる 69 | 70 | ## 7. SDP Offer/Answer Procedures 71 | 72 | - BUNDLEをやるにあたってオファー・アンサーの手順がどうなるかについて 73 | - アンサー側でもBUNDLEする意思があるときだけ成立する 74 | 75 | ### 7.1. Generic SDP Considerations 76 | 77 | - SDPがどうなるかについて 78 | 79 | #### 7.1.1. Connection Data (c=) 80 | 81 | - `c=`行について 82 | - `nettype`は`IN`になる 83 | - `addrtype`は`IP4` or `IP6`になる 84 | 85 | #### 7.1.2. Bandwidth (b=) 86 | 87 | - 特になし（今まで通り） 88 | - draft-ietf-mmusic-sdp-mux-attributes 89 | 90 | #### 7.1.3. Attributes (a=) 91 | 92 | - 他の`a=`行の属性も今まで通り 93 | - ただしBUNDLEされる`m=`セクションについての属性に以下の例外を適用する 94 | - `bundle-only`なセクションには、`IDENTICAL`と`TRANSPORT`のカテゴリーの属性はつけてはいけない 95 | - `a=rtcp`とか`a=rtcp-mux`とか 96 | - それらは、BUNDLEするベースの`m=`セクションにつけること 97 | - その後のオファーやアンサーでも、タグ付けされたベースの`m=`セクションにだけ、`IDENTICAL`と`TRANSPORT`の属性をつけてよい 98 | - それ以外のカテゴリーの属性は、今まで通りつけてよい 99 | 100 | ### 7.2. Generating the Initial SDP Offer 101 | 102 | - BUNDLEしたい最初のオファーに関して 103 | - `m=`行のアドレス、ポートに同じものを指定する 104 | - `a=group:BUNDLE`をつける 105 | - 絶対にBUNDLEしたい場合 106 | - `a=bundle-only`をつけて、ポートに`0`を指定する 107 | 108 | #### 7.2.1. Suggesting the Offerer tagged 'm=' section 109 | 110 | - BUNDLEが受け入れられると、その`m=`行に記載のアドレス、ポートでデータが送受信される 111 | - オファー側は、`bundle-only`の`m=`セクションをタグ付けしてはいけない 112 | 113 | #### 7.2.2. Example: Initial SDP Offer 114 | 115 | - BUNDLEするオファーSDPの例 116 | - `a=group:BUNDLE foo bar` 117 | - `a=mid:foo`の`m=`セクションが、「タグ付けされた」`m=`セクション 118 | - ベースとなる`m=`セクション 119 | 120 | ### 7.3. Generating the SDP Answer 121 | 122 | - アンサー側に関して 123 | - BUNDLEが指定されていた時だけ、BUNDLEを指定できる 124 | - その後の処理は基本的にオファー側と同じ 125 | - BUNDLEを拒否することもできる 126 | 127 | #### 7.3.1. Answerer Selection of tagged 'm=' sections 128 | 129 | - 以下の条件に合致するなら、同様にBUNDLEする意思を表明する 130 | - 同様にBUNDLEする意思があり 131 | - その`m=`セクションを拒否しないつもりで 132 | - その`m=`行のポートが`0`じゃないなら 133 | 134 | #### 7.3.2. Moving A Media Description Out Of A BUNDLE Group 135 | 136 | - BUNDLEしないようにしたい場合 137 | - `a=bundle-only`がついてる場合は拒否できない 138 | - オファー全体を拒否するか、オファーを再度出し直すか 139 | - それ以外は 140 | - `m=`セクションに別々のアドレス・ポートを振る 141 | - `a=group:BUNDLE`のリストに`mid`を含めない 142 | - `a=bundle-only`を使わない 143 | 144 | #### 7.3.3. Rejecting a Media Description in a BUNDLE Group 145 | 146 | - BUNDLEを拒否する場合 147 | - `m=`行のポートを`0`に 148 | - `a=group:BUNDLE`のリストに`mid`を含めない 149 | - `a=bundle-only`を使わない 150 | 151 | #### 7.3.4. Example: SDP Answer 152 | 153 | - BUNDLEを了承するSDPの例 154 | - `a=bundle-only`な`m=`セクションのポートは`0`になる 155 | 156 | ### 7.4. Offerer Processing of the SDP Answer 157 | 158 | - アンサーを受け取ったら 159 | - オファーでBUNDLEした内容から変更ないか確かめる 160 | - そもそも`a=group:BUNDLE`が残ってるか 161 | - `m=`セクションのリストがそのままか 162 | - `a=group:BUNDLE`がない場合は、通常のアンサーとして処理する 163 | 164 | ### 7.5. Modifying the Session 165 | 166 | - BUNDLEを使用してネゴシエーションした後、オファー・アンサーする場合 167 | - タグ付けする`m=`セクションを選び直しても良い 168 | - 新規にオファーを出すときと同じ 169 | - タグ付けする`m=`セクションを変更する必要があるのは 170 | - その`m=`セクションを、BUNDLEしたくなくなったとき 171 | - その`m=`セクションを、disableにしたくなったとき 172 | 173 | #### 7.5.1. Adding a Media Description to a BUNDLE group 174 | 175 | - BUNDLEに新たな`m=`セクションを追加する場合 176 | - 普通に追加してもいいし、それをタグ付けして使ってもいい 177 | 178 | #### 7.5.2. Moving a Media Description Out of a BUNDLE Group 179 | 180 | - BUNDLEから外したい場合 181 | - 外した`m=`セクションには 182 | - 新しいアドレス・ポートを振る 183 | - `a=group:BUNDLE`のリストには含めない 184 | - `a=bundle-only`をつけない 185 | 186 | #### 7.5.3. Disabling a Media Description in a BUNDLE Group 187 | 188 | - BUNDLEしていたものをdisableにしたい場合 189 | - `m=`行のポートを`0`に 190 | - `a=group:BUNDLE`のリストには含めない 191 | - `a=bundle-only`をつけない 192 | 193 | ## 8. Protocol Identification 194 | 195 | - BUNDLEされる`m=`セクションは、同じプロトコルである必要がある 196 | - そうでない場合、より上層のプロトコルは正しく処理される実装になってないといけない 197 | - ここではUDP上でSTUNとDTLSとSRTPがやり取りされる場合についてだけ解説する 198 | 199 | ### 8.1. STUN, DTLS, SRTP 200 | 201 | - STUNとDTLSとSRTPを判別する方法はある 202 | - RFC5764 203 | - この仕様をサポートしているものとする 204 | - DTLS上で流れるパケットについては、よしなに判別すること 205 | - SRTPを流れるパケットと`m=`セクションとの紐づけは、Section 9.2にて後述 206 | 207 | ## 9. RTP Considerations 208 | 209 | - 本文なし 210 | 211 | ### 9.1. Single RTP Session 212 | 213 | - 同じBUNDLEグループに属することは、同じRTPセッションに属することを意味する 214 | - RFC4961のSymmetric RTPに従う 215 | - SSRCの名前空間も同じ 216 | - `m=`行の`proto`も同一なはず 217 | - RTPのMIDヘッダ拡張は必須 218 | - すべての`m=`セクションに 219 | - `extmap`で`urn:ietf:params:rtp-hdrext:sdes:mid`をつける 220 | - SSRCは`m=`セクションをまたいで使われてはいけない 221 | 222 | #### 9.1.1. Payload Type (PT) Value Reuse 223 | 224 | - BUNDLEされる複数の`m=`セクションを表すRTP 225 | - すべて同じコーデック、パラメータである必要がある 226 | - ペイロードタイプも同じ 227 | 228 | ### 9.2. Associating RTP/RTCP Streams with the Correct SDP Media Description 229 | 230 | - 受信したRTPと、SDPの`m=`セクションをどうやって照合するか 231 | - SSRCを使う 232 | - SDPに`a=ssrc`をつける 233 | - RTPヘッダ拡張か、RTCPのSDESパケットによってパケットからSSRCを得る 234 | - それができない場合は、ペイロードタイプを頼るしかない 235 | - RTPのストリームとSDPを紐付けるために、マッピングテーブルを用意して実装する 236 | - MID, 送信用のSSRC, 受信用のSSRC 237 | - RTPを受け取っても、そのテーブルにSSRCがない場合は破棄する 238 | - RTCPパケットの扱いについて 239 | - SDES, BYE, SR, RR, XR, RTPFB, PSFB 240 | - フィードバックのそれぞれの条件による処理の違いなど 241 | 242 | ### 9.3. RTP/RTCP Multiplexing 243 | 244 | - BUNDLEを利用する場合、RTP/RTCPを多重化することも必要 245 | - `rtcp-mux-only` 246 | 247 | #### 9.3.1. SDP Offer/Answer Procedures 248 | 249 | - `rtcp-mux`と`rtcp-mux-only`をどうネゴシエーションするか 250 | - これをつける = RTPベースのメディアを使いたいはずだが、RTPベースではない`m=`セクションも存在するはず 251 | 252 | ##### 9.3.1.1. Generating the Initial SDP BUNDLE Offer 253 | 254 | - 初期オファーについて 255 | - `rtcp-mux`はつけるが、`rtcp-mux-only`をつけない場合 256 | - `a=rtcp`をつけてもよい 257 | 258 | ##### 9.3.1.2. Generating the SDP Answer 259 | 260 | - それに対するアンサーについて 261 | - `rtcp-mux`に対しては`rtcp-mux`を返す必要がある 262 | - `rtcp-mux-only`に対しては、`rtcp-mux-only`を返す 263 | - BUNDLEされた`m=`セクションには、`a=rtcp`を含めてはいけない 264 | 265 | ##### 9.3.1.3. Offerer Processing of the SDP Answer 266 | 267 | - オファー側がアンサーを受け取ったら 268 | - 適切に多重化を処理する 269 | - タグ付けされた`m=`行のポートにメディアを送信する 270 | 271 | ##### 9.3.1.4. Modifying the Session 272 | 273 | - セッション確立後に再度オファーする場合 274 | - `rtcp-mux`属性が必須 275 | 276 | ## 10. ICE Considerations 277 | 278 | - ICEとの兼ね合いについて 279 | - 基本的にはいつもどおりだが、いくつか例外がある 280 | - BUNDLEが確立されると、`m=`セクション単位ではなく、BUNDLEトランスポートに対して処理を行う 281 | - 接続チェックやキープアライブ 282 | - オファー時はBUNDLEされるかわからないので、ICEの属性は各`m=`セクションにつける 283 | - TrickleICEを使うときは、`m=`行のポートは`9`で、アドレスは`0.0.0.0` OR `::`になる 284 | 285 | ## 11. DTLS Considerations 286 | 287 | - DTLSとの兼ね合いについて 288 | - BUNDLEグループごとに1つのDTLSアソシエーションを形成する 289 | - DTLS-SRTPをサポートするなら、`use_srtp`拡張を使って`ClientHello`をする 290 | - こうしておけば、後からメディアを追加するときにもDTLSのネゴシエーションが不要 291 | 292 | ## 12. RTP Header Extensions Consideration 293 | 294 | - RTPのヘッダ拡張を使用する場合、BUNDLEされるメディアたちは同一の定義を使う 295 | 296 | ## 13. Update to RFC 3264 297 | 298 | - RFC3264をアップデート 299 | - ポートを`0`に指定した場合の意味合いが変更点 300 | 301 | ### 13.1. Original text of section 5.1 (2nd paragraph) of RFC 3264 302 | 303 | - こうでした 304 | 305 | ### 13.2. New text replacing section 5.1 (2nd paragraph) of RFC 3264 306 | 307 | - こうなった 308 | 309 | ### 13.3. Original text of section 8.4 (6th paragraph) of RFC 3264 310 | 311 | - こうでした 312 | 313 | ### 13.4. New text replacing section 8.4 (6th paragraph) of RFC 3264 314 | 315 | - こうなった 316 | 317 | ## 14. Update to RFC 5888 318 | 319 | - RFC5888をアップデート 320 | - `a=group`属性で関連付けられる`m=`行のポートを`0`に指定できるのが変更点 321 | 322 | ### 14.1. Original text of section 9.2 (3rd paragraph) of RFC 5888 323 | 324 | - 古い文書がこうでした 325 | 326 | ### 14.2. New text replacing section 9.2 (3rd paragraph) of RFC 5888 327 | 328 | - こうなった 329 | 330 | ## 15. RTP/RTCP extensions for identification-tag transport 331 | 332 | - RTCP SDESに`MID`を定義するヘッダ拡張 333 | - パケットでその`a=mid`値なのか判断するための項目 334 | - RTCP MID SDESは、定期的に送られるべき 335 | - そのインターバルはパケロス具合にもよるのでここでは規定しない 336 | - SSRCが変わっても送られる 337 | - 送られてこないことも想定する必要があって、ただちにセッションを終了するなどはしない 338 | 339 | ### 15.1. RTCP MID SDES Item 340 | 341 | - パケットフォーマットの図 342 | - 00-08bit: MID 343 | - 09-15bit: length 344 | - 16-32bit: identification-tag 345 | - `0`埋めしない 346 | 347 | ### 15.2. RTP SDES Header Extension For MID 348 | 349 | - RTP SDESヘッダ拡張 350 | - ペイロードは1-2byteのヘッダにエンコードされる 351 | - 識別タグは短いほうがよい 352 | - 1byteのヘッダの場合、1-3byteなら結果敵に32bitで収まる 353 | 354 | ## 16. IANA Considerations 355 | 356 | - 本文なし 357 | 358 | ### 16.1. New SDES item 359 | 360 | - MID SDESを追加 361 | 362 | ### 16.2. New RTP SDES Header Extension URI 363 | 364 | - RTP SDESヘッダ拡張の追加 365 | - `urn:ietf:params:rtp-hdrext:sdes:mid` 366 | 367 | ### 16.3. New SDP Attribute 368 | 369 | - SDPの`bundle-only`属性の追加 370 | 371 | ### 16.4. New SDP Group Semantics 372 | 373 | - SDPの`group`属性に`BUNDLE`値を追加 374 | 375 | ## 17. Security Considerations 376 | 377 | - BUNDLEするかしないかで変わるのは、どのアドレス・ポートをRTPが流れるかだけ 378 | - MIDは、3byte以下にするのが効率的 379 | - フィンガープリントとして使われないようにするほうが望ましい 380 | 381 | ## 18. Examples 382 | 383 | - 本文なし 384 | 385 | ### 18.1. Example: Tagged m= Section Selections 386 | 387 | - BUNDLEするSDPの例 388 | - オファーでBUNDLEが指定されている 389 | - アンサーはそれを受け入れる 390 | - タグ付けされたものを引き継ぐ 391 | - BUNDLEする`m=`セクションのポートは`0`にして、`bundle-only` 392 | 393 | ### 18.2. Example: BUNDLE Group Rejected 394 | 395 | - BUNDLEを拒否する例 396 | - アンサーで`a=group`を指定しない 397 | 398 | ### 18.3. Example: Offerer Adds a Media Description to a BUNDLE Group 399 | 400 | - 後からBUNDLEにメディアを追加する例 401 | 402 | ### 18.4. Example: Offerer Moves a Media Description Out of a BUNDLE Group 403 | 404 | - BUNDLEを解除する例 405 | 406 | ### 18.5. Example: Offerer Disables a Media Description Within a BUNDLE Group 407 | 408 | - BUNDLEから一部のメディアだけを解除する例 409 | 410 | ## Appendix A. Design Considerations 411 | 412 | - この仕様を検討する上でのポイントについて 413 | - 主には、オファーとアンサーで`m=`行に同じポートを指定できるかどうか 414 | 415 | ### A.1. UA Interoperability 416 | 417 | - Symmetric RTPに対応しないエンドポイントもある 418 | - その場合は、オファーに対して異なるポート番号でアンサーが返ってくる 419 | - ICEを使う場合は、すべての`m=`行が同じポート番号を使うかもしれない 420 | 421 | ### A.2. Usage of Port Number Value Zero 422 | 423 | - `m=`行のポートに`0`を指定するケース 424 | - 本来はそのオファーを拒否する場合に使う 425 | - 複数のポートからBUNDLEグループが構成されていたら、拒否したい場合にどうする？ 426 | - という問題がある 427 | 428 | ### A.3. B2BUA And Proxy Interoperability 429 | 430 | - B2BUAについての懸念 431 | 432 | #### A.3.1. Traffic Policing 433 | 434 | - 特定の環境では、セッションを終了させられるかも 435 | - SDPから取得したポートでメディアが送受信されない場合 436 | 437 | #### A.3.2. Bandwidth Allocation 438 | 439 | - 帯域の割当もSDPの情報で成されるかもしれない 440 | 441 | ### A.4. Candidate Gathering 442 | 443 | - ICEのcandidateは、ポートごとに必要 444 | - `m=`セクションが増えるごとに、20msほどかかる想定 445 | - これを回避するために、TrickleICEを使用する 446 | -------------------------------------------------------------------------------- /summary/draft-ietf-rtcweb-data-channel-13.md: -------------------------------------------------------------------------------- 1 | > Read [original](https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13) / [markdown](../markdown/draft-ietf-rtcweb-data-channel-13.md) 2 | 3 | --- 4 | 5 | # WebRTC Data Channels 6 | 7 | ## 1. Introduction 8 | 9 | - WebRTCにおいて送信できるメディアは映像と音声だけではない 10 | - 映像と音声はSRTPで送信される 11 | - それ以外はSCTPを使って送信される 12 | - RFC4960 13 | - DTLSでカプセル化される 14 | - RFC8261 15 | - DTLSはICE/UDPによってNATを超えて接続できる 16 | - SCTPによって、信頼性のある通信が可能（部分的に信頼性をもたせることも） 17 | - RFC3758 18 | - 複数のストリームを1つのアソシエーションに束ねる仕組み 19 | - RFC6525 20 | 21 | ## 2. Conventions 22 | 23 | - いつもの 24 | 25 | ## 3. Use Cases 26 | 27 | - ユースケースの紹介 28 | 29 | ### 3.1. Use Cases for Unreliable Data Channels 30 | 31 | - 信頼性なしモード 32 | - リアルタイムゲームにおけるオブジェクトの状態や位置の伝送 33 | - 誰かがミュートしたなど、クリティカルではないメディア通信に関するメタデータ 34 | 35 | ### 3.2. Use Cases for Reliable Data Channels 36 | 37 | - 信頼性ありモード 38 | - リアルタイムゲームにおけるクリティカルなデータの伝送 39 | - リアルタイムでなくてもよいファイル伝送 40 | - リアルタイムのテキストチャット 41 | - `RTCPeerConnection`のネゴシエーションに使うデータ 42 | - プロキシ実装のバックエンドとして 43 | 44 | ## 4. Requirements 45 | 46 | - 2つのブラウザがP2PでDataChannelを利用するときの要件 47 | - 同時に複数のチャンネルをサポートすること 48 | - SRTPを使ったメディア転送とも平行利用できる 49 | - 信頼性ありとなしの2つのモード 50 | - 輻輳制御されること 51 | - 個別でも、トランスポート全体でも 52 | - SRTPの帯域に影響を与えないこと 53 | - そのチャンネルの帯域使用における優先度が指定できる 54 | - セキュアであること 55 | - メッセージの分割ができること 56 | - DataChannelトランスポート自体は、IPアドレスを内部で参照しない 57 | - ストリームのように実質無制限のサイズの送信ができること 58 | - IPの断片化を避け、PMTUを守ること 59 | - ユーザーのアプリケーションで、プロトコルの実装ができること 60 | 61 | ## 5. SCTP over DTLS over UDP Considerations 62 | 63 | - WebRTCにおけるSCTPの重要な機能について 64 | - TCPに優しい輻輳制御 65 | - SRTP側の輻輳制御との親和性 66 | - 複数の一方向ストリーム 67 | - 順序保証、非保証のメッセージ伝送 68 | - 断片化による大きいデータの伝送 69 | - PMTU判別 70 | - 信頼性、部分的信頼性のサポート 71 | - SCTPのマルチホーミングはサポートしない 72 | - DTLSレイヤーが公開する単一のホスト上で動作 73 | - SCTPで送信されるユーザーメッセージは、PPIDが付与される 74 | - UTF8、バイナリのデータのほか、DCEP(Data Channel Establishment Protocol)を判別する 75 | - draft-ietf-rtcweb-data-protocol 76 | - これらのメッセージは、SCTP上でやりとりされるが、SCTP自体はDTLSのペイロードであることに注意 77 | - 多重化を解く時など 78 | - ICEがセッションの途中でIPアドレスを変えた場合 79 | - SCTPはそれを検知する必要がある 80 | - PMTUをリセットしたり、輻輳制御の状態をリセットする 81 | - SCTPでは1つのアソシエーションで1つの輻輳ウィンドウを管理する 82 | - その中で複数のストリームが管理される 83 | 84 | ## 6. The Usage of SCTP for Data Channels 85 | 86 | - 本文なし 87 | 88 | ### 6.1. SCTP Protocol Considerations 89 | 90 | - SCTPパケットは必ずDTLSでカプセル化すること 91 | - 複数のSCTPストリームをサポートすること 92 | - 順序保証と信頼性は、共に有効・無効化できること 93 | - 以下の拡張をサポートすること 94 | - RFC6525 95 | - RFC5061 96 | - RFC3758 97 | 98 | ### 6.2. SCTP Association Management 99 | 100 | - WebRTCでは、SDPでネゴシエーションされたときにSCTPのアソシエーションをセットアップする 101 | - ICEによって選ばれつながれたDTLSの上でセットアップ 102 | - このDTLSの接続は、SRTPのメディアの接続と共有される 103 | - 1アソシエーションで扱えるストリームの数の上限は`65535` 104 | - アソシエーションの終了方法は2つ 105 | - 送受信中のメッセージを失わないグレイスフルな方法 106 | - 片方がいきなり切断する方法 107 | - メッセージの到達をチェックし、再送があまりに増えた場合に切断する 108 | - アソシエーションが閉じると、DataChannelも閉じられる 109 | - いきなり切断された場合などは、エラーの通達などが望ましい 110 | 111 | ### 6.3. SCTP Streams 112 | 113 | - SCTPのストリームは、アソシエーション内に一方向の流れとして存在するもの 114 | - 多重化のためにシーケンス番号を保持 115 | - 順序保証されたものだけが並べ替えられる 116 | 117 | ### 6.4. Data Channel Definition 118 | 119 | - DataChannelはWebSocketのように、対応するAPIが用意される 120 | - `label`によって、チャンネルを区別できる 121 | - DataChannelはSCTPストリームのペアで、同じIDを持っている 122 | - このIDの紐付けは実装依存 123 | - そのほかの属性 124 | - 信頼性の有無（ストリームではなくメッセージの属性） 125 | - 順序保証の有無（ストリームではなくメッセージの属性） 126 | - 2byteのUIntで表される優先度 127 | - 128: below normal 128 | - 256: normal 129 | - 512: high 130 | - 1024: extra high 131 | - ラベル（オプショナル） 132 | - プロトコル（オプショナル） 133 | 134 | ### 6.5. Opening a Data Channel 135 | 136 | - DataChannelは、in-bandなネゴシエーションとout-bandなネゴシエーションで確立できる 137 | - out-bandな方法についてはここでは触れない 138 | - in-bandな方法は以下にて 139 | - draft-ietf-rtcweb-data-protocol 140 | 141 | ### 6.6. Transferring User Data on a Data Channel 142 | 143 | - 送受信されるメッセージは、そのDataChannelの設定によって伝送される 144 | - 信頼性や順序保証について 145 | - 1つのSCTPのユーザーメッセージの中には、アプリ側のメッセージも1つしか含めてはいけない 146 | - 送信するデータによって、次のPPIDを使用する 147 | - WebRTC String 148 | - WebRTC String Empty 149 | - WebRTC Binary 150 | - WebRTC Binary Empty 151 | - SCTP自体は空メッセージをサポートしていない 152 | - なのでそのためのPPIDを指定して、0byteのメッセージを送る 153 | - 不正な、無効なPPIDのメッセージを受信した場合、そのDataChannelを閉じてもよい 154 | - つまりネゴシエーションなしにPPIDを拡張できない 155 | - 特定のストリームで大きいデータを送信すると、そのアソシエーション全体に影響が出る 156 | - それを回避するための実装がある 157 | - RFC8260 158 | - これに沿わない場合は、16KB以内に制限する必要がある 159 | - それでも、メッセージサイズには制限を設けることが推奨される 160 | - draft-ietf-mmusic-sctp-sdp-26 161 | - Nagleアルゴリズムは使わないほうがよい 162 | 163 | ### 6.7. Closing a Data Channel 164 | 165 | - DataChannelを閉じるためには、外向きのSCTPストリームをリセットする 166 | - それに呼応して、リモート側もリセットする 167 | - ので、内向きのSCTPストリームがリセットされる 168 | - リセットに際しては、SSN(Stream Sequence Number)を`0`に戻す 169 | - そのストリームはまたいつか再利用されるかも 170 | - リセットする前に、全てのデータを送受信する必要がある 171 | - RFC6525 172 | 173 | ## 7. Security Considerations 174 | 175 | - 特別に懸念される事項はなし 176 | - 受信側は、送信側が巨大なメッセージを送信する可能性があることを考慮すべし 177 | 178 | ## 8. IANA Considerations 179 | 180 | - SCTPのPPIDを6ヶ使用している 181 | - うち2つはDeprecated 182 | - 51: `WebRTC String` 183 | - 53: `WebRTC Binary` 184 | - 56: `WebRTC String Empty` 185 | - 57: `WebRTC Binary Empty` 186 | -------------------------------------------------------------------------------- /summary/draft-ietf-rtcweb-ip-handling-12.md: -------------------------------------------------------------------------------- 1 | > Read [original](https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-12) / [markdown](../markdown/draft-ietf-rtcweb-ip-handling-12.md) 2 | 3 | --- 4 | 5 | # WebRTC IP Address Handling Requirements 6 | 7 | ## 1. Introduction 8 | 9 | - WebRTCはP2Pできるのがミソ 10 | - ただしP2Pのために集めたIPアドレスの扱いに注意 11 | - そのあたりについて書いた文書 12 | 13 | ## 2. Terminology 14 | 15 | - いつものやつ 16 | 17 | ## 3. Problem Statement 18 | 19 | - ICEで集めたIPの組が見える 20 | - それを見るとわかることがいくつかある 21 | - 懸念されるパターンが3つ紹介されてる 22 | - VPN使ってるけどばれちゃう 23 | - NATの向こうのプライベートなIPも 24 | - 企業FWとかProxyの向こう側のIPも 25 | 26 | ## 4. Goals 27 | 28 | - パフォーマンスとプライバシーどちらも考慮した方法論を模索したい 29 | - そのためのフレームワークを検討する 30 | 31 | ## 5. Detailed Design 32 | 33 | - 本文なし 34 | 35 | ### 5.1. Principles 36 | 37 | - 4つの原則を紹介 38 | - HTTPが流れるのと同じインターフェースを使う（＝特殊なことはしない） 39 | - できればP2Pでやる、余計な中継をしない 40 | - プライベートなローカルIPは収集しない 41 | - Proxyを介さない 42 | 43 | ### 5.2. Modes and Recommendations 44 | 45 | - パフォーマンスとプライバシーの兼ね合いで、4つのモード（落とし所）を考えた 46 | - 全収集 47 | - TURN+ローカルアドレス 48 | - TURN強制 49 | - Proxy強制 50 | - 下に行くほどキツい 51 | - 全収集する場合はもちろんユーザー確認したほうがよい 52 | 53 | ## 6. Implementation Guidance 54 | 55 | - これらをどう実装するかの話 56 | 57 | ### 6.1. Ensuring Normal Routing 58 | 59 | - ソケットを`0.0.0.0`とか`::`にする 60 | - OSに任せる 61 | - STUNもTURNも普通に動くはず 62 | 63 | ### 6.2. Determining Host Candidates 64 | 65 | - Webのホストコンポーネントからアドレスを得る 66 | - そうすればパケットをNWに送らずにアドレスを得られる 67 | 68 | ## 7. Application Guidance 69 | 70 | - TURNudp/tcpどちらでも動くようにして公開しておくべし 71 | - hostのcanidateがない場合、Mode3か4になる 72 | -------------------------------------------------------------------------------- /summary/draft-ietf-rtcweb-mdns-ice-candidates-04.md: -------------------------------------------------------------------------------- 1 | > Read [original](https://tools.ietf.org/html/draft-ietf-rtcweb-mdns-ice-candidates-04) / [markdown](../markdown/draft-ietf-rtcweb-mdns-ice-candidates-04.md) 2 | 3 | --- 4 | 5 | # Using Multicast DNS to protect privacy when exposing ICE candidates 6 | 7 | ## 1. Introduction 8 | 9 | - プライベートIPを露出させると、P2Pの成功率は上がる 10 | - しかし同時にfingerprintingの問題がある 11 | - mDNSを使うことでローカルのプライベートIPの露出を防ぐことができる 12 | - 事前にこの名前とIPを変換するだけ 13 | - ICEの手順は今までどおり 14 | - mDNS自体は、RFC6762を参照 15 | 16 | ## 2. Terminology 17 | 18 | - いつもの 19 | 20 | ## 3. Description 21 | 22 | - ICEのエージェントの挙動に沿って説明していく 23 | 24 | ### 3.1. ICE Candidate Gathering 25 | 26 | - まずは候補収集 27 | - ローカルIPをmDNSでどう扱うか 28 | 29 | #### 3.1.1. Procedure 30 | 31 | - 以下の手順に沿って処理される 32 | - 1: 収集したIPがICEのポリシーとして、公開して良いかチェック 33 | - よいなら今まで通りのICEの手順へ 34 | - 2: そのIPに対するmDNSホスト名が既に登録されているか確認 35 | - あるならそれをcandidateとして使う 36 | - 3: ホスト名を生成 37 | - `${uuid/v4}.local` 38 | - 4: ホスト名を登録 39 | - それをネットワークに周知してもよい 40 | - 5: 将来のためにキャッシュする 41 | - 6: IPアドレスを置き換えて、アプリケーション側に渡す 42 | - ホスト名の登録は事前にやっておいてもよい 43 | - 同じ結果になるなら実装方法は任意 44 | - mDNSに非対応の場合、そもそも`host`のcandidateを公開しない実装もあるかも 45 | - IPv4とIPv6では異なるホスト名になる 46 | 47 | #### 3.1.2. Implementation Guidance 48 | 49 | - 本文なし 50 | 51 | ##### 3.1.2.1. Registration 52 | 53 | - ホスト名の登録をネットワークに周知するのは非同期になる 54 | - ただしアドレス自体のアプリケーションの返答は即座にする必要がある 55 | 56 | ##### 3.1.2.2. Determining Address Privacy and Server-Reflexive Candidates 57 | 58 | - グローバルなIPについては、mDNSで保護しなくてもよい 59 | - 既にグローバルに公開されてるので 60 | - ただしIPだけ見て、それがmDNSで保護されてるかどうかは判断できない 61 | - STUNで`srflx`のアドレスを集めた時に、同じアドレスが帰ってくれば、グローバルだと判断はできる 62 | - `srflx`の`raddr`は`0.0.0.0`/`::`で、`rport`は`9`にする 63 | 64 | ##### 3.1.2.3. Special Handling for IPv6 Addresses 65 | 66 | - IPv6は特殊な特性なため、mDNSで保護しないという判断もあるかも 67 | 68 | ##### 3.1.2.4. mDNS Candidate Encoding 69 | 70 | - mDNSのホスト名は、SDPの`c=`行の`connection-address`で使われる 71 | - ただそれが唯一の候補の場合は載せてはいけない 72 | - アドレス: `0.0.0.0`/`::` + ポート: `9`を使う 73 | 74 | ### 3.2. ICE Candidate Processing 75 | 76 | - 収集したcandidateの扱いについて 77 | 78 | #### 3.2.1. Procedure 79 | 80 | - `connection-address`の値が、`.local`で終わらない場合 81 | - または`.`が複数含まれている場合 82 | - 今までどおりのICEの手順 83 | - それ以外ならmDNSのホスト名のはず 84 | - ホスト名でIPを解決して、以降は通常のICEの手順 85 | 86 | #### 3.2.2. Implementation Guidance 87 | 88 | - ホスト名を解決したときに、複数のアドレスが返ってくるかも 89 | - これはcandidateとしても無視するべき 90 | 91 | ### 3.3. Additional Privacy Considerations 92 | 93 | - ICE以外の部分でもプライベートなIPを保護する必要がある 94 | 95 | #### 3.3.1. Statistics 96 | 97 | - 統計データを残す場合も、mDNSのホスト名を使う 98 | - `prflx`なアドレスも開示してはいけない 99 | 100 | #### 3.3.2. Interactions With TURN Servers 101 | 102 | - TURNにはIPを伝える必要がある 103 | - なので自身の`relay`と、リモートの`host`はペアにしてはいけない 104 | - その逆は問題ない 105 | 106 | #### 3.3.3. Generated Name Reuse 107 | 108 | - mDNSのホスト名は、定期的にリセットされるべき 109 | - これが永続したら、IPアドレスよりも追跡がしやすい 110 | - そのウェブページの寿命と同じが望ましい 111 | 112 | #### 3.3.4. Specific Browsing Contexts 113 | 114 | - 同じデバイス上で2つのピアがP2Pすると一瞬で接続できる 115 | - 例えば3rdパーティのコンテキストから（`iframe`とか）つながれるかも 116 | - そのようなコンテキストでは、mDNSの登録をすべきではない 117 | 118 | #### 3.3.5. Network Interface Enumeration 119 | 120 | - mDNSのホスト名の数で、ネットワークインターフェースの数がわかる 121 | - それもFingerprintの側面がある 122 | - 公開するmDNSのホストの数を制限することが有効 123 | 124 | #### 3.3.6. Monitoring of Sessions 125 | 126 | - mDNSの登録・解除自体を監視される可能性もある 127 | - それによって、通信してるかどうか、頻度などがわかってしまう 128 | - これはこの仕様の範囲外 129 | 130 | ## 4. Potential Limitations 131 | 132 | - 本文なし 133 | 134 | ### 4.1. Reduced Connectivity 135 | 136 | - 同じネットワークに接続している場合、`host`のcandidate同士で接続できる 137 | - mDNSを使うと、各エンドポイントがmDNSに対応していれば問題ない 138 | - でも対応していないと、つながらなくなってしまう 139 | - あまりに広域なネットワークでもつながらない可能性はある 140 | - mDNSが失敗するとTURNを使おうとするかもしれないが、接続までの時間やコストが増える 141 | - IPv6はmDNSで保護しないようにするなどで、これは緩和できる 142 | - STUN+mDNSを使う環境での接続テストの統計を見ると次のようになった 143 | - 片側だけ有効に比べて、両側で有効な場合のICEの接続率への影響は2%ほど 144 | - STUNが必要になるケースは94%から97%に増加した 145 | - NATのヘアピンに失敗してるのが理由であろう 146 | 147 | ### 4.2. Connection Setup Latency 148 | 149 | - mDNSのホスト解決がある分、実行に時間はかかる 150 | - ホスト名を事前に登録していれば少しは軽減できる 151 | 152 | ### 4.3. Backward Compatibility 153 | 154 | - 後方互換性には影響ないはず 155 | - mDNSの名前をもらっても解決できないだけのはず 156 | - ただしそれがエラーになるなどICEが失敗するエンドポイントも稀にあった 157 | - シグナリング時に受信してないホストからの接続確認を処理できない 158 | - おそらくこの理由によって、接続率は3%減少した 159 | 160 | ## 5. Examples 161 | 162 | - 簡単な例と少し複雑な例を紹介する 163 | 164 | ### 5.1. Normal Handling 165 | 166 | - お互いにmDNSの解決ができる場合 167 | 168 | ### 5.2. Peer-reflexive Candidate From Slow Signaling 169 | 170 | - mDNSのcandidateが届く前に、STUNがきた場合 171 | - それは`prflx`のcandidateとして扱われる 172 | 173 | ### 5.3. Peer-reflexive Candidate From Slow Resolution 174 | 175 | - mDNSの解決が完了する前に、STUNがきた場合 176 | - それも`prflx`のcandidateとして扱われる 177 | 178 | ### 5.4. IPv4, IPv6, and STUN handling 179 | 180 | - IPv4とIPv6両対応のエンドポイントどうしが通信する場合 181 | 182 | ## 6. Security Considerations 183 | 184 | - 本文なし 185 | 186 | ### 6.1. mDNS Message Flooding 187 | 188 | - この仕様を満たすためには、ブラウザにmDNSの機能が必要 189 | - 登録・解決 190 | - OS側にももちろん実装されてる必要がある 191 | - この実装を悪用される恐れはある 192 | - ページを開くだけでmDNSの登録・削除を行うとか 193 | - その処理にレート制限を入れるなどして対策すべき 194 | 195 | ### 6.2. Malicious Responses to Deny Name Registration 196 | 197 | - mDNSの登録を拒まれる場合 198 | - そのcandidateは破棄されてしまう 199 | - ローカルのネットワークに悪意のあるエンドポイントがいる場合は、この仕様の範囲外 200 | 201 | ### 6.3. Unsolicited ICE Communications 202 | 203 | - ICEを悪用してトラフィック攻撃に使われるかも 204 | - mDNSホスト名が公開されていると、その標的にされる可能性がある 205 | - ホスト名のフォーマットをチェックしてmDNSの解決をしないようにするなどする 206 | 207 | ## 7. IANA Considerations 208 | 209 | - IANAには関係ない 210 | -------------------------------------------------------------------------------- /summary/draft-ietf-rtcweb-overview-19.md: -------------------------------------------------------------------------------- 1 | > Read [original](https://tools.ietf.org/html/draft-ietf-rtcweb-overview-19) / [markdown](../markdown/draft-ietf-rtcweb-overview-19.md) 2 | 3 | --- 4 | 5 | # Overview: Real Time Protocols for Browser-based Applications 6 | 7 | ## 1. Introduction 8 | 9 | - インターネットでリアルタイムになんかするのをずっとやってきた 10 | - IETFとW3Cの協力でWebRTCというものが生まれ、過去を刷新するであろう 11 | - ユースケースはRFC 7478に詳しい 12 | 13 | ## 2. Principles and Terminology 14 | 15 | - 本文なし 16 | 17 | ### 2.1. Goals of this document 18 | 19 | - この文書は、WebRTCの全容を説明するもの 20 | - この文書と引用されてる仕様を読めば、WebRTC自体の実装も可能 21 | - なので最初にコレを読んで、そこから広げていくべし 22 | 23 | ### 2.2. Relationship between API and protocol 24 | 25 | - IETFによるプロトコル仕様と、W3CのJavaScriptのAPIの両方の理解が必要 26 | - あとは用語説明が続く 27 | 28 | ### 2.3. On interoperability and innovation 29 | 30 | - 互換性は単独ではありえない概念 31 | - なので歩調あわせて実装したり仕様を検討したりしましょうね的な内容 32 | - それがインターネットですよね 33 | 34 | ## 3. Architecture and Functionality groups 35 | 36 | - ブラウザにはJSでRTC系のAPIを公開して、それを開発者が使う 37 | - MediaのパスとSignalingのパスは別で、Signalingの方法は規定しない 38 | - などなどプロトコルとしてのWebRTCのレイヤー・登場人物の紹介 39 | 40 | ## 4. Data transport 41 | 42 | - トランスポート = データの送受信 43 | - 最低限必要な実装は、`draft-ietf-rtcweb-transports`にあるもの 44 | 45 | ## 5. Data framing and securing 46 | 47 | - メディアはRTPとSRTPを使う 48 | - RTP以外にDataChannelの実装が必要 49 | - これらに関するドラフトがいくつかある 50 | 51 | ## 6. Data formats 52 | 53 | - 仕様としてはつながることが最優先で、データのフォーマットは二の次 54 | - 必須のコーデックやプロファイルは、RFC 7874とRFC 7742を参照 55 | 56 | ## 7. Connection management 57 | 58 | - SignalingにはSDPを使う 59 | - ブラウザはWebRTCのAPIとして`ietf-rtcweb-jsep`にあるものを実装する 60 | - ブラウザ以外は、ネットワークレイヤーのものだけ実装すればいい 61 | 62 | ## 8. Presentation and control 63 | 64 | - 開発者がAPIをどのように使うか 65 | - Peer Connection APIと、Media Capture APIの2つが必要 66 | 67 | ## 9. Local system support functions 68 | 69 | - エコーキャンセラーやHW的なカメラの設定などについて 70 | - RFC 7874の実装は必要 71 | 72 | ## 10. IANA Considerations 73 | 74 | - IANAには関係ない 75 | 76 | ## 11. Security Considerations 77 | 78 | - できることが増えるということは、セキュリティのリスクも増えるということ 79 | - こういうことに気をつけなさいよ 80 | -------------------------------------------------------------------------------- /summary/draft-ietf-rtcweb-sdp-11.md: -------------------------------------------------------------------------------- 1 | > Read [original](https://tools.ietf.org/html/draft-ietf-rtcweb-sdp-11) / [markdown](../markdown/draft-ietf-rtcweb-sdp-11.md) 2 | 3 | --- 4 | 5 | # Annotated Example SDP for WebRTC 6 | 7 | ## 1. Introduction 8 | 9 | - JSEPしかり、WebRTCのオファー・アンサーではSDPでそのやり取りが行われる 10 | - この文書は、あらゆるユースケースにおいてそのSDPがどうなるかを書いてる 11 | 12 | ## 2. Terminology 13 | 14 | - いつもの 15 | 16 | ## 3. SDP and the WebRTC 17 | 18 | - ここではSDPの概要を説明する 19 | - 詳細はRFC4566 20 | - SDPはWebRTCのものではなく、元から広く使われていたもの 21 | - SIP, RTSP, RTPなど 22 | - SDPの構成要素 23 | - Session Metadata 24 | - Network Description 25 | - Stream Description 26 | - Security Description 27 | - QoS, Grouping Description 28 | 29 | ## 4. Offer/Answer and the WebRTC 30 | 31 | - WebRTCでSDPはオファー・アンサーの過程で使われる 32 | - 詳細はRFC3264 33 | - 初期のオファーを発行して、その内容に対してアンサーを返す 34 | - アンサーは拒否されることもある 35 | - またセッションの途中に新たなオファーを発行することもある 36 | - そのあたりの状態はJSEPが担保してる 37 | 38 | ## 5. WebRTC Session Description Examples 39 | 40 | - だいたいのWebRTCはこんな感じ 41 | - 0本以上のメディア（動画のみ、音声のみ、両方あり） 42 | - データのセッションもあるかも 43 | - DTLS-SRTPでセキュリティを担保 44 | - ICEを使ってNATを越える 45 | - RTCPを使ったフィードバック 46 | - IPv4かIPv6、またはデュアル 47 | - 5taple単位でバンドルする 48 | - IPとポートの組、プロトコル 49 | 50 | ### 5.1. Some Conventions 51 | 52 | - 以降に続くサンプルの読み方に関する注意 53 | 54 | ### 5.2. Basic Examples 55 | 56 | - 本文なし 57 | 58 | #### 5.2.1. Audio Only Session 59 | 60 | - 音声のみのセッション 61 | 62 | #### 5.2.2. Audio/Video Session 63 | 64 | - 音声・動画のセッション 65 | - 動画の`m=`セクションが増えるだけ 66 | 67 | ##### 5.2.2.1. IPv4 audio/video session 68 | 69 | - IPv4のとき 70 | 71 | ##### 5.2.2.2. Dual Stack audio/video session 72 | 73 | - デュアルスタックのとき 74 | - `a=candidate`にIPv6のが入るだけ 75 | 76 | #### 5.2.3. Data Only Session 77 | 78 | - DataChannelのみ 79 | 80 | #### 5.2.4. Audio Call On Hold 81 | 82 | - 音声のオファーを`inactive`でアンサー 83 | - 一方通行で音声が流れる 84 | 85 | #### 5.2.5. Audio with DTMF Session 86 | 87 | - 音声とDTMFで合計2本の音声ストリーム 88 | 89 | #### 5.2.6. One Way Audio/Video Session - Document Camera 90 | 91 | - `sendonly`のオファーと`recvonly`のアンサー 92 | 93 | #### 5.2.7. Audio, Video Session with BUNDLE Support Unknown 94 | 95 | - BUNDLEがサポートされてないかもしれない環境 96 | - WebRTCではありえない 97 | 98 | #### 5.2.8. Audio, Video and Data Session 99 | 100 | - 音声・動画・データのBUNDLE 101 | 102 | #### 5.2.9. Audio, Video Session with BUNDLE Unsupported 103 | 104 | - BUNDLEがサポートされてない環境 105 | - WebRTCではありえない 106 | 107 | #### 5.2.10. Audio, Video BUNDLED, but Data (Not BUNDLED) 108 | 109 | - 音声・動画のBUNDLE 110 | - データはBUNDLEしない 111 | - WebRTCではありえない 112 | 113 | #### 5.2.11. Audio Only, Add Video to BUNDLE 114 | 115 | - 最初は音声のみ 116 | - あとから動画を送ってBUNDLEする 117 | 118 | ### 5.3. MultiResolution, RTX, FEC Examples 119 | 120 | - サイマルキャストなどマルチストリームの場合の例 121 | - RTXとかFECとか 122 | 123 | #### 5.3.1. Sendonly Simulcast Session with 2 cameras and 2 encodings per camera 124 | 125 | - 1つの音声2つの動画 126 | - 動画は解像度が2つずつ 127 | - VP8とH264 128 | - この1 + 4RTPストリームをすべてBUNDLEする 129 | 130 | #### 5.3.2. Successful SVC Video Session 131 | 132 | - H264-SVCを選んで返す例 133 | 134 | #### 5.3.3. Successful Simulcast Video Session with Retransmission 135 | 136 | - RTXで多重化する例 137 | 138 | #### 5.3.4. Successful 1-way Simulcast Session with 2 resolutions and RTX -One resolution rejected 139 | 140 | - RTXで多重化して2本送るけど1つは拒否される例 141 | 142 | #### 5.3.5. Simulcast Video Session with Forward Error Correction 143 | 144 | - FECを使う例 145 | 146 | ### 5.4. Others 147 | 148 | - それ以外のユースケース例 149 | - RTPヘッダの拡張を使うやつとか 150 | 151 | #### 5.4.1. Audio Session - Voice Activity Detection 152 | 153 | - RTPの拡張でVADする例 154 | 155 | #### 5.4.2. Audio Conference - Voice Activity Detection 156 | 157 | - 同じくRTPの拡張でVADする例（ルーム） 158 | 159 | #### 5.4.3. Successful legacy Interop Fallback with bundle-only 160 | 161 | - レガシーVoIP環境とつなげる例 162 | - 片や`bundle-only`で動画と音声をオファー 163 | - 片やそれを無視して音声のみでつながる 164 | 165 | #### 5.4.4. Legacy Interop with RTP/AVP profile 166 | 167 | - 少し古いプロファイルであるAVPを使う例 168 | - もちろんつながる 169 | 170 | ## 6. IANA Considerations 171 | 172 | - IANAは関係なし 173 | 174 | ## 7. Security Considerations 175 | 176 | - 別の仕様があるのでそれを参照 177 | - draft-ietf-rtcweb-security-arch 178 | - SDPにはプライベートな情報が含まれるので、TLSなど暗号化が使われる 179 | 180 | ## 8. Acknowledgments 181 | 182 | - 謝辞 183 | 184 | ## Appendix A. Appendix 185 | 186 | - 本文なし 187 | 188 | ### A.1. JSEP SDP Attributes Checklist 189 | 190 | - SDPの文法が正しいかを調べるためのチェックリスト 191 | 192 | #### A.1.1. Common Checklist 193 | 194 | - SDPのフォーマットについての決まりごと 195 | - `v=0`からはじまるとか 196 | - `s=-`は絶対に3行目とか 197 | 198 | #### A.1.2. RTP Media Description Checklist 199 | 200 | - RTPに関する記述のチェックリスト 201 | - JSEPでは`UDP/TLS/RTP/SAVPF`をプロトコルに指定するとか 202 | - `SAVPF`だけでなく、`S?AVPF?`をもれなくサポートせよとか 203 | - `a=group:LS`は`mid`と必ずセットにするとか 204 | 205 | #### A.1.3. DataChannel Media Description checklist 206 | 207 | - DataChannelのSDPのためのチェックリスト 208 | - タイプは`application` 209 | - `UDP/DTLS/SCTP`がプロトコル 210 | -------------------------------------------------------------------------------- /summary/draft-ietf-rtcweb-security-12.md: -------------------------------------------------------------------------------- 1 | > Read [original](https://tools.ietf.org/html/draft-ietf-rtcweb-security-12) / [markdown](../markdown/draft-ietf-rtcweb-security-12.md) 2 | 3 | --- 4 | 5 | # Security Considerations for WebRTC 6 | 7 | ## 1. Introduction 8 | 9 | - WebRTCを使った一般的なユースケースでは、Webサーバーを介してセットアップを行う 10 | - WebRTCを使うためのJavaScriptはブラウザに実装されているが、それをコールするのはサーバーから渡されるスクリプトである 11 | - 一般的なこれまでのVoIPのシステムとは異なり、新たなセキュリティリスクが伴う 12 | - もしかしたら、ページを表示しただけでどこかに通話が開始され、録画されたりするかも 13 | - DoS攻撃に利用されることもありうる 14 | 15 | ## 2. Terminology 16 | 17 | - いつもの 18 | 19 | ## 3. The Browser Threat Model 20 | 21 | - ブラウザはユーザーを保護する責務がある 22 | - もし悪意のある攻撃者に誘導されてページを閲覧したとしても、安全であることが重要 23 | - WebRTCについても同様に要件を満たす必要がある 24 | - HTMLもJSも、ブラウザのSandbox内で実行され、そのコンピュータに対しては隔離されてる 25 | - Web攻撃者とネットワーク攻撃者がいる 26 | - ネットワーク攻撃者については、RFC3552 27 | 28 | ### 3.1. Access to Local Resources 29 | 30 | - ブラウザはローカルのリソース（ファイルやカメラなど）にアクセスできる 31 | - しかしWebサーバーからはアクセスさせない 32 | - ファイルアップロードもユーザーが明示的にファイルを選択する必要がある 33 | - Flashも、カメラやマイクへのアクセスには許可が必要 34 | - なんらかの実行ファイルも、ダウンロードはできても実行はされない 35 | 36 | ### 3.2. Same-Origin Policy 37 | 38 | - ブラウザからは他のサーバーへのアクセスができる 39 | - `XHR`などで 40 | - ただしそれにもSame-Origin Policyの制約がかかる 41 | - JavaScriptの変数の参照も、オリジンをまたいでおこなうことはできない 42 | 43 | ### 3.3. Bypassing SOP: CORS, WebSockets, and consent to communicate 44 | 45 | - SOPは堅牢であるが、不便なこともある 46 | - 複数のAPIサービスのマッシュアップなど 47 | - そのために`CORS`の仕様がW3Cにはある 48 | - Cross-Origin Resource Sharing 49 | - CROSS-PROTOCOL攻撃には注意が必要 50 | 51 | ## 4. Security for WebRTC Applications 52 | 53 | - 本文なし 54 | 55 | ### 4.1. Access to Local Devices 56 | 57 | - ユーザーの同意なしに、通話を開始してはいけない 58 | - ここでいうユーザーの同意とはなにか 59 | - どのメディアを送るのか 60 | - 誰に送ろうとしているのか 61 | - ローカルデバイス利用への同意は、それが送信されることへの同意にもなり得る 62 | - HTTPSなどで暗号化された経路であっても、同意は必要 63 | - デバイスに対するプライバシー上の同意 64 | - ネットワークにトラフィックを送信することへの同意 65 | 66 | #### 4.1.1. Threats from Screen Sharing 67 | 68 | - カメラやマイクだけでなく、画面共有についても考慮が必要 69 | - カメラやマイクよりもシビアな問題 70 | - 思った以上にシェアされてしまう可能性がある 71 | - とつぜんの通知であったり、共有を止め忘れたり 72 | - SOPでそのページの内容を見ることができなかったのに、画面共有ならそれが見れてしまう 73 | - パスワードやトークンなどを写し取られてしまったらどうする 74 | 75 | #### 4.1.2. Calling Scenarios and User Expectations 76 | 77 | - 通話に関しては多様なパターンがあって、それぞれ一様に同意を得ることはできない 78 | 79 | ##### 4.1.2.1. Dedicated Calling Services 80 | 81 | - 特定のサイトで不特定多数と話すパターン 82 | - 長い期間、カメラやマイクへのアクセスを許可することになる 83 | - 通話しながらゲームができるとか 84 | - 多くの異なる人と話せる場合は、誰と話しているのかがわかる必要がある 85 | 86 | ##### 4.1.2.2. Calling the Site You're On 87 | 88 | - ショッピングサイトなどにある「担当者と話す」のパターン 89 | - こちらから話したい場合には同意をする 90 | - ただしそれはいつでも通話をよこしても良いという意味ではないはず 91 | - そのサイトがマイクやカメラを利用していることを表示するUIも必要 92 | 93 | #### 4.1.3. Origin-Based Security 94 | 95 | - 前述の通り、ブラウザのSandboxはオリジンごとである 96 | - たった1度の通話で許可したことを、未来永劫の許可と捉えられるわけにはいかない 97 | - そこをケアするためにはいくつか同意に区分が必要 98 | - 3つの区分 99 | - 個人の同意: 通話ごとに許可を 100 | - 通話相手に対する同意 101 | - 通話内容が暗号化されることについての同意 102 | - UIを出すだけでいい話ではない 103 | - ユーザーが何も考えずにOKを押すこともある 104 | - 通話相手への同意は、悪意あるサイトの場合に嘘かもしれない 105 | - 通話相手を識別するなにかがあれば 106 | - draft-ietf-rtcweb-security-arch でも言及がある 107 | 108 | #### 4.1.4. Security Properties of the Calling Page 109 | 110 | - オリジンによるセキュリティの担保は、Web攻撃者には有効 111 | - ただしWebRTCではネットワーク攻撃者についても考慮する必要がある 112 | - HTTPのページで許可をしたあとに、脆弱なネットワークで攻撃されるシナリオ 113 | - HTTPコネクションを差し替えられて、異なるサイトでも許可したことにされてしまう 114 | - 脆弱なネットワークから離れたあとも影響され続ける 115 | 116 | ### 4.2. Communications Consent Verification 117 | 118 | - Webアプリから無制限にネットワークアクセスはできない 119 | - これができてしまったら、攻撃プラットフォームに使われてしまう 120 | - トラフィック送信の同意をするためのハンドシェイク以外のトラフィックは許可なく送られてはいけない 121 | - ただし帯域の過剰仕様を防げるわけではない 122 | - WebRTCを使えば同意なしにトラフィックを送信して帯域を圧迫もできる 123 | - よって適切な輻輳制御がWebRTCプロトコルに実装されている必要がある 124 | 125 | #### 4.2.1. ICE 126 | 127 | - 同意を得るにはハンドシェイクが必要で、ICEにもその仕組みがある 128 | - 安全にハンドシェイクをするために、応答を偽造されないための仕組みが必要 129 | - 例えばICEの場合、STUNのトランザクションIDは必ずブラウザが生成する 130 | - トラフィックが流れる間ずっと、受信することを希望していることを確認する仕組みも必要 131 | - ICEの場合はそれがRFC7675 132 | 133 | #### 4.2.2. Masking 134 | 135 | - TCPが使われる場合は、WebSocketのようにマスキングが必要 136 | - DTLS上ではマスキングは不要 137 | - TURN TCPでのSRTPパケットは、WebAudioと緻密なタイミング制御によって制御できる 138 | 139 | #### 4.2.3. Backward Compatibility 140 | 141 | - ICEが使えないクライアントとの互換性 142 | - 攻撃者が偽造できないなんらかの値を含めてやりとりする必要がある 143 | - ICEを使わずにSTUNをやり取りする場合 144 | - RTCPを暗黙的に到達確認に使う場合 145 | - WebRTCはICEを使うものなので、STUNだけを使ってもユーザー名とパスワードを検証できない 146 | - RTCPを使う場合も、そもそもRTCPがサポートされてないこともあるのでダメ 147 | - 他にあるとすればICE-Liteの実装のような場合 148 | 149 | #### 4.2.4. IP Location Privacy 150 | 151 | - ICEで経路を送ると、IPアドレスがわかる 152 | - `srflx`なアドレスは地理的な情報をも含む可能性がある 153 | - TURNを使ってそういった情報を秘匿したいと思うかもしれない 154 | - VPNを介して接続していても隠しきれない可能性もある 155 | 156 | ### 4.3. Communications Security 157 | 158 | - 通信のセキュリティについて 159 | - 映像と音声について、改ざんやなりすましなどに耐性が必要 160 | - RFC5479 161 | - 攻撃の分類は2つ 162 | - 受動的な攻撃: 古い通話に対する攻撃 163 | - 能動的な攻撃: 通話中に対する攻撃 164 | 165 | #### 4.3.1. Protecting Against Retrospective Compromise 166 | 167 | - 通話後に、その内容を復元しようとする攻撃 168 | - これに対しては、トラフィックを暗号化している鍵へのアクセスが焦点になる 169 | - WebRTCでは公開鍵ベースの鍵交換が推奨で、できればPFSな仕組みであるべき 170 | - また保存された鍵へアクセスするAPIは提供してはいけない 171 | 172 | #### 4.3.2. Protecting Against During-Call Attack 173 | 174 | - 通話中を狙った攻撃について 175 | - 具体的にはMITM攻撃を防ぐのは困難である 176 | - Fingerprintの仕組みや、3rdの認証機構を用いるなどするしかない 177 | 178 | ##### 4.3.2.1. Key Continuity 179 | 180 | - `Key Continuity`について 181 | - 悪意があっても、特定の公開鍵に対して秘密鍵を生成することはできない 182 | - SSHのように対応する鍵の情報を管理しておけば、それが変わったときに気付くことができる 183 | - しかしWebRTCでは、複数のコンピュータ、ブラウザを使うことは一般的なので有用ではない 184 | - ブラウザが信頼できるUIで、誰に対する呼び出しなのかを明示する必要がある 185 | 186 | ##### 4.3.2.2. Short Authentication Strings 187 | 188 | - ZRTPで使われるSASという仕組みがある 189 | - Short Authentication String 190 | - 通話するAとBにそれぞれ決められた単語を読み上げさせて確認する 191 | - しかし音声変換システムなどでなんとかできてしまう 192 | - ブラウザもSAS交換を要求しているUIを出すことしかできない 193 | - そしてそれは無視されることもあるだろう 194 | 195 | ##### 4.3.2.3. Third Party Identity 196 | 197 | - 3rdの認証システムを使って個人を識別することもできる 198 | - 使わないよりは面倒にはなる 199 | - ただし昨今は一般的にもなりつつある 200 | - MITMに対してももちろん耐性がある 201 | 202 | ##### 4.3.2.4. Page Access to Media 203 | 204 | - WebRTCで送られるメディアは`MediaStream`というAPIで操作される 205 | - 通話をするサイトがそれを操作できる 206 | - サイトが`MediaStream`を変更していない保証を得たいかもしれない 207 | - 一般的にはユーザーはそれを気にしてはいない 208 | - これを実現するには、`MediaStream`へのアクセスを許可、取り下げる仕組みが必要 209 | 210 | #### 4.3.3. Malicious Peers 211 | 212 | - 通話相手がそもそも悪意がある場合 213 | - 通話内容を録音したり横流ししたり 214 | - 変声や顔を隠しているなど 215 | - WebRTCのようなオープンな仕組みでは関与しない 216 | 217 | ### 4.4. Privacy Considerations 218 | 219 | - 本文なし 220 | 221 | #### 4.4.1. Correlation of Anonymous Calls 222 | 223 | - 匿名性との関係について 224 | - DTLSの証明書やRTCPのCNAMEをリセットする仕組みが必要 225 | - IPアドレスも個人を特定する要素になり得る 226 | 227 | #### 4.4.2. Browser Fingerprinting 228 | 229 | - ブラウザに搭載されてるAPIの有無ですらFingerprintとして使われるかも 230 | - 機能性とリスクのバランスを取る必要がある 231 | 232 | ## 5. Security Considerations 233 | 234 | - この文書自体がセキュリティに関するものであった 235 | -------------------------------------------------------------------------------- /summary/draft-ietf-rtcweb-transports-17.md: -------------------------------------------------------------------------------- 1 | > Read [original](https://tools.ietf.org/html/draft-ietf-rtcweb-transports-17) / [markdown](../markdown/draft-ietf-rtcweb-transports-17.md) 2 | 3 | --- 4 | 5 | # Transports for WebRTC 6 | 7 | ## 1. Introduction 8 | 9 | - WebRTCはプロトコルの集合体である 10 | - データのトランスポートに関して解説する 11 | - 実装の参考にするためにも明文化していく 12 | 13 | ## 2. Requirements language 14 | 15 | - いつもの 16 | 17 | ## 3. Transport and Middlebox specification 18 | 19 | - 本文なし 20 | 21 | ### 3.1. System-provided interfaces 22 | 23 | - UDPとTCPのIPv4/IPv6サポートが必要 24 | - 自分で実装しないといけないかもしれないのが以下 25 | - TURN 26 | - STUN 27 | - ICE 28 | - TLS 29 | - DTLS 30 | 31 | ### 3.2. Ability to use IPv4 and IPv6 32 | 33 | - IPv4とIPv6のサポートは必須 34 | - 相互接続はHappy Eyeballsを参考に 35 | - ietf-mmusic-ice-dualstack-fairness 36 | 37 | ### 3.3. Usage of temporary IPv6 addresses 38 | 39 | - IPv6のアドレスはtemporaryなアドレスを優先 40 | - ただしICEは全部集めるので手動で破棄するなどしたい 41 | - プライバシーのために 42 | - temporaryなアドレスでも、deprecatedとマークされたら無視してよい 43 | 44 | ### 3.4. Middle box related functions 45 | 46 | - ICEはライトではなく完全実装が必須 47 | - STUN/TURN利用は設定できるようにする必要がある 48 | - UDPが使えない環境のために、TURN/TCPのサポートも必要 49 | - TURNではIPv6ももちろん使えるように 50 | - ICEはTCPもcandidateとして集める 51 | - STUNの`ALTERNATE-SERVER`も対応必須 52 | 53 | ### 3.5. Transport protocols implemented 54 | 55 | - メディアの送信はSRTP 56 | - DTLS-SRTPで鍵交換 57 | - データの送信はSCTP over DTLS over ICE 58 | - SCTPのDNATA拡張もサポート必須 59 | - DTLSとRTPはmultiplexする 60 | - DTLSを流れるパケットはすべてSCTP 61 | 62 | ## 4. Media Prioritization 63 | 64 | - メディアの送信をmedia flowという（データはdata flow） 65 | - flowには優先度がある 66 | - very-low, low, medium, high 67 | 68 | ### 4.1. Local prioritization 69 | 70 | - パケットが送られる前に、ローカルの優先度が設定される 71 | - 優先度に差があると輻輳制御下で2倍の転送効率の差になる 72 | - highはvery-lowの8倍 73 | - かといってストリームごとに輻輳制御をして協調せよといってるわけではない 74 | 75 | ### 4.2. Usage of Quality of Service - DSCP and Multiplexing 76 | 77 | - パケットが送られるときDSCP値がセットされるかもしれない 78 | - QoSのためになんらかの取り組みをすべき 79 | - 実装依存ではあるが、その際にDSCPを利用しないようにするかも 80 | - SCTP上は単一のDSCPコードポイント 81 | - TCPを使う場合も同じ 82 | - DSCPを使わずにQoSを担保するやり方もいろいろある 83 | -------------------------------------------------------------------------------- /summary/draft-roach-mmusic-unified-plan-00.md: -------------------------------------------------------------------------------- 1 | > Read [original](https://tools.ietf.org/html/draft-roach-mmusic-unified-plan-00) / [markdown](../markdown/draft-roach-mmusic-unified-plan-00.md) 2 | 3 | --- 4 | 5 | # A Unified Plan for Using SDP with Large Numbers of Media Flows 6 | 7 | ## 1. Introduction 8 | 9 | - 昨今のRTC技術では、たくさんのストリームをやり取りする 10 | - たとえばカンファレンス 11 | - メインのストリームに加えて、参加者全員分のサムネイルのストリーム 12 | - もしそれが複数の解像度をサポートしていたら・・？ 13 | - FECやRTXを有効にしていたら・・？ 14 | - その数はゆうに30を越えるだろう 15 | - SDPはメディアレベルにセッション情報（ポート、ICE candidate）が必要なので 16 | - ストリームが増えるとそれも増える 17 | - STUNのバインディングポートもそれだけ増えてリソースを圧迫する 18 | - そんな場合にSDPをどうするかについて述べたのがこの仕様 19 | - 方針としては、出来る限りリソースを節約するように 20 | 21 | ### 1.1. Design Goals 22 | 23 | - 需要はいろいろある 24 | - 以下のゴールを設定する 25 | 26 | #### 1.1.1. Support for a large number of arbitrary sources 27 | 28 | - 大規模なカンファレンス 29 | - それぞれの環境によって、求めるものは異なるはず 30 | - 高解像度を重視したいとか 31 | - 低解像度でいいからサムネイルが欲しいとか 32 | - スライドも見たいとか 33 | - `large`とか`thumbnail`とかカテゴリを任意に分けてそのグループごとに配信するとかもできる 34 | 35 | #### 1.1.2. Support for fine-grained receiver control of sources 36 | 37 | - 受信側が様々な要求を出してストリームを表示するためには、それを要求できる仕組みが必要 38 | - そしてその条件に対してベストエフォートで配信側が対応する 39 | - こうしたやり取りはAPIとして公開されるべき 40 | 41 | #### 1.1.3. Glareless addition and removal of sources 42 | 43 | - たくさんのストリームが追加され削除される 44 | - そのときにSDPをどう修正していくかに注意が必要 45 | - シグナリングでグレアを起こさないためにも 46 | 47 | #### 1.1.4. Interworking with other devices 48 | 49 | - 環境によっては、この仕様にあるテクニックが使えないこともあるだろう 50 | - その場合は単一の映像と音声だけなど、もっともシンプルな形で配信する 51 | 52 | #### 1.1.5. Avoidance of excessive port allocation 53 | 54 | - たくさんストリームがあるからといって、たくさんポートを使わないようにしたい 55 | - ポートの数と通信の成功率は比例しない実験結果がある 56 | - SDPのBUNDLEはここでも有効である 57 | 58 | #### 1.1.6. Simple binding of MediaStreamTrack to SDP 59 | 60 | - ストリームは`MediaStreamTrack`から成る 61 | - この`MediaStreamTrack`はSDPの中で認識できるようにする必要がある 62 | 63 | #### 1.1.7. Support for RTX, FEC, simulcast, layered coding 64 | 65 | - RTXやFECもサポートする 66 | - simulcastなども同じく 67 | - これらのテクニックを使う・使わないはユーザーが選べるべき 68 | 69 | ### 1.2. Terminology 70 | 71 | - いつもの 72 | 73 | ### 1.3. Syntax Conventions 74 | 75 | - この仕様に記載のあるSDPのサンプルの読み方 76 | - 改行は見やすさのためとか 77 | - コメントはコメントだとか 78 | 79 | ## 2. Solution Overview 80 | 81 | - 概要は次のとおり 82 | - `MediaStreamTrack`ごとに`m=`セクションを設ける 83 | - 各`m=`セクションは`a=ssrc`でRTPパケットと紐付けられる 84 | - おなじく`a=msid`をもち`MediaStream`および`MediaStreamTrack`と紐付けられる 85 | - BUNDLEをリソース節約のために使う 86 | - オファー・アンサーは`m=`行ごとに対処する 87 | - 既にアクティブなストリームへの影響を減らす 88 | - すべての`m=`行に`a=mid`を必要とする 89 | - BUNDLEされる`m=`行は、それぞれ同じ属性を含める必要がある 90 | - ここで`IDENTICAL`と書かれているもの 91 | - draft-ietf-mmusic-sdp-mux-attributes-17 92 | 93 | ## 3. Detailed Description 94 | 95 | - 本文なし 96 | 97 | ### 3.1. Bundle-Only M-Lines 98 | 99 | - 基本的にBUNDLEしていく 100 | - 最初の`m=`だけ通常通り 101 | - ほかの`m=`は、 102 | - ポートを`0`にする 103 | - `a=bundle-only`をつける 104 | - 互換性のないエンドポイントは、最初の`m=`以外を拒否するはず 105 | 106 | ### 3.2. Correlation 107 | 108 | - 以下3つの相関関係について 109 | - `m=`行 110 | - `MediaStreamTrack` 111 | - RTPのソース 112 | 113 | #### 3.2.1. Correlating RTP Sources with m-lines 114 | 115 | - 単一のトランスポートで複数のストリームを送る 116 | - SSRCを使ってそれらを識別する 117 | - `a=ssrc`をSDPに含めれば基本的にはOK 118 | - しかし3パターンの例外がある 119 | - セッション確立中に、新たなオファーを発行する場合 120 | - 既存のSSRCを変更する場合 121 | - SDPにSSRCを載せることができないレガシー環境の場合 122 | 123 | ##### 3.2.1.1. RTP Header Extension Correlation 124 | 125 | - RTPヘッダ拡張の関連付けについて 126 | - `m=`セクションごとに、`a=extmap`で定義する 127 | 128 | ##### 3.2.1.2. Payload Type Correlation 129 | 130 | - RTPヘッダ拡張をサポートしていないが、BUNDLEは対応したい相手の場合 131 | - 推奨はしないが、ペイロードタイプを利用することでも相関付けられる 132 | - 2つの動画を送る際、それぞれ同じコーデックでも、異なるペイロードタイプにする 133 | - 使えるペイロードタイプの番号についての詳細は、RFC3551とRFC5761にて 134 | 135 | #### 3.2.2. Correlating Media Stream Tracks with m-lines 136 | 137 | - `m=`セクションごとに`a=msid`をつけることで`MediaStreamTrack`を相関付ける 138 | 139 | #### 3.2.3. Correlating Media Stream Tracks with RTP Sources 140 | 141 | - `MediaStreamTrack`は、RTPソースと相関付けられる 142 | - オファーを発行する時点で`MediaStreamTrack`と`m=`行がペアになる 143 | - `m=`行とRTPソース = SSRCはSection 3.2.1.の通り 144 | 145 | ### 3.3. Handling of Simulcast, Forward Error Correction, and Retransmission Streams 146 | 147 | - サイマルキャストについて 148 | - 単一の入力ソースを異なる解像度やFPSに分けること 149 | - FECとRTXはどちらもパケロスに対する技術 150 | - ペイロードタイプとSSRC値はそれぞれで異なる 151 | - `a=ssrc-group:FID`でグルーピングされる 152 | - サイマルキャスト 153 | - `a=ssrc`行に`imageattr`属性をさらに付与する 154 | - `a=ssrc-group:SIMULCAST` 155 | 156 | ### 3.4. Glare Minimization 157 | 158 | - グレアを徹底的に回避するために 159 | - `m=`セクションを独立して変更可能にする 160 | - 部分オファーと部分アンサー 161 | - 各`m=`セクションが`a=mid`属性を持ってる必要がある 162 | - RFC5888 163 | - SDPの`type`に`partialOffer`や`partialAnswer`を定義する 164 | - `sdp`自体には、差分だけが入る 165 | - ということを構想している段階 166 | 167 | #### 3.4.1. Adding a Stream 168 | 169 | - ストリームの追加 170 | - まだ使われていない新たな`mid`を使う 171 | - 非同期で複数の部分オファーを受信したら 172 | - `mid`の小さい順に追加する 173 | - `o=`行ののバージョンをインクリメントしてアンサーを発行する 174 | 175 | #### 3.4.2. Changing a Stream 176 | 177 | - ストリームの変更 178 | - `mid`が同じものを変更する 179 | - `o=`行ののバージョンをインクリメントしてアンサーを発行する 180 | 181 | #### 3.4.3. Removing a Stream 182 | 183 | - ストリームの削除 184 | - 該当の`mid`のセクションに`a=inactive`をつける 185 | 186 | ### 3.5. Negotiation of Stream Ordinality 187 | 188 | - オファー側から、アンサー側が何本のストリームを望んでいるかはわからない 189 | - たとえばカンファレンスアプリで、8本の配信がある場合 190 | - 視聴側はとりあえず1本だけオファーを出してみて 191 | - 配信側はその1本に対してアンサーしつつ、8本のオファーも出す 192 | - それに対して改めて8本のアンサーを返す 193 | - この3wayハンドシェイクでやり取りできる 194 | - それ用のシグナリング手段で事前に解消する手もある 195 | 196 | ### 3.6. Compatibility with Legacy uses 197 | 198 | - レガシーなクライアントとの互換性について 199 | - `a=bundle-only`の扱いだけが問題 200 | - レガシーな環境はそれを無視するはず 201 | - なのでどのストリームが重要なのかを決めることが重要 202 | 203 | ## 4. Examples 204 | 205 | - ユースケース別にSDPのサンプルを載せる 206 | - またも仕様に準拠したSDPではなく読みやすさを優先してあるよ 207 | 208 | ### 4.1. Simple example with one audio and one video 209 | 210 | - 1音声1動画のSDP例 211 | - アンサー側はBUNDLEも`rtcp-mux`もサポートしていない 212 | 213 | ### 4.2. Multiple Videos 214 | 215 | - 1音声2動画のSDP例 216 | - `bundle-only`ではない 217 | 218 | ### 4.3. Many Videos 219 | 220 | - 1音声3動画のSDP例 221 | - `bundle-only`で、ペイロードタイプも重複している 222 | 223 | ### 4.4. Multiple Videos with Simulcast 224 | 225 | - 1音声2動画（解像度2つ）のSDP例 226 | - VP8とH.264を`bundle-only`で送る 227 | 228 | ### 4.5. Video with Simulcast and RTX 229 | 230 | - 1音声1動画（解像度2つ）のSDP例 231 | - RTX対応 232 | 233 | ### 4.6. Video with Simulcast and FEC 234 | 235 | - 1動画1音声（解像度2つ）のSDP例 236 | - FEC対応 237 | 238 | ### 4.7. Video with Layered Coding 239 | 240 | - 1音声1動画（解像度3つ） 241 | - RFC5583にあるやり方 242 | -------------------------------------------------------------------------------- /summary/draft-thatcher-ice-renomination-01.md: -------------------------------------------------------------------------------- 1 | > Read [original](https://tools.ietf.org/html/draft-thatcher-ice-renomination-01) / [markdown](../markdown/draft-thatcher-ice-renomination-01.md) 2 | 3 | --- 4 | 5 | # ICE Renomination: Dynamically selecting ICE candidate pairs 6 | 7 | ## 1. Introduction 8 | 9 | - ICEのAgentは`CONTROLLING`か`CONTROLLED`のどちらか 10 | - `CONTROLLING`側が常にcandidateを選ぶ 11 | - しかし`CONTROLLED`がどのペアを選択するかはわからない 12 | - 通常のノミネーションでも、アグレッシブノミネーションでも 13 | - 最初にノミネーションしたネットワークよりも、良いものが見つかることもある 14 | - Wi−Fiが使えるようになったりとか 15 | - その場合に、切り替えたくてもどうしようもない 16 | 17 | ## 2. Terminology 18 | 19 | - いつもの 20 | 21 | ## 3. Renomination 22 | 23 | - `a=ice-options:renomination`を追加する 24 | - これが解釈された場合は、いつでも新しいペアをノミネーションしてよい 25 | - アグレッシブノミネーションを無効にして、後勝ちにできる 26 | - STUNのレスポンスが返ってくるまで送信する 27 | - 解釈されない場合 28 | - アグレッシブノミネーションは無効 29 | - `CONTROLLING`側は、複数ノミネーションしてはいけない 30 | 31 | ## 4. "Nomination" attribute 32 | 33 | - 新しいSTUNの属性に`nomination`を定義 34 | - 最下位3byteに24bitの整数 35 | - `CONTROLLED`側は、この値が最大のものを常に選択する 36 | 37 | ## 5. IANA Considerations 38 | 39 | - IANAには関係ない 40 | 41 | ## 6. Security Considerations 42 | 43 | - TODO 44 | -------------------------------------------------------------------------------- /summary/draft-uberti-rtcweb-turn-rest-00.md: -------------------------------------------------------------------------------- 1 | > Read [original](https://tools.ietf.org/html/draft-uberti-rtcweb-turn-rest-00) / [markdown](../markdown/draft-uberti-rtcweb-turn-rest-00.md) 2 | 3 | --- 4 | 5 | # A REST API For Access To TURN Services 6 | 7 | ## 1. Introduction 8 | 9 | - TURNはP2Pの接続確立を上げられる仕組み 10 | - RFC5766 11 | - TURNはその仕組み上、インターネットから接続される 12 | - サーバーを管理するコストもあるので、アクセス管理はほぼ必須 13 | - TURNは`long-term`な認証を使用する 14 | - usernameとpasswordによる 15 | - これらcredentialsが漏洩する危険性と隣り合う 16 | - そのために、credentialsを期限付きにしてAPI経由で取得する方式を提案する 17 | - WebサービスとTURNは、共通の秘密鍵さえ保持してればよい 18 | 19 | ## 2. HTTP Interactions 20 | 21 | - まずPOSTリクエストでcredentialsを発行する 22 | - ユーザーIDのようなものをオプションでつけてもよい 23 | - 主にデバッグ用途ではある 24 | - ただどのユーザーIDにcredentialsをいくつ発行したかなど追える 25 | - JSON形式でレスポンスされる 26 | - TURNに送信するusernameとハッシュ化されたpasswordを返す 27 | - このレスポンスには期限がある 28 | - つまり、ICEのリスタート時などには再取得が必要 29 | 30 | ### 2.1. Request 31 | 32 | - リクエストに含むパラメータの例 33 | - 基本的に任意 34 | 35 | ### 2.2. Response 36 | 37 | - レスポンスに含むパラメータの例 38 | - `username`: TURNのusername 39 | - `:`でUNIXタイムスタンプと適当なユーザー名をつないだもの 40 | - ユーザー名の部分は任意 41 | - タイムスタンプの形式も任意だが、UNIXタイムスタンプがわかりやすい 42 | - `password`: TURNのpassword 43 | - 事前に共有された秘密鍵で計算する 44 | - `base64(hmac-sha1(secretkey, username))` 45 | - HMAC-SHA1でもいいし、なんでもいい 46 | - `ttl`: このcredentialsが有効な秒数 47 | - 任意だが、1日（86400秒）が推奨値 48 | - `uris`: TURNのURLの配列 49 | - 提供しているTURNのポート、トランスポートに応じて返す 50 | 51 | ## 3. WebRTC Interactions 52 | 53 | - JSONのレスポンスは、`RTCPeerConnection`に渡される 54 | - `RTCConfiguration`の`iceServers`として 55 | - credentialsの更新時には、それ用のメソッドを使う 56 | - `getConfiguration()` + `setConfiguration()`で`iceServers`を更新する 57 | 58 | ## 4. TURN Interactions 59 | 60 | - 本文なし 61 | 62 | ### 4.1. Client 63 | 64 | - `username`は、TURNの`USERNAME`属性にあたる 65 | - `password`は、TURNの`MESSAGE-INTEGRITY`属性 66 | 67 | ### 4.2. Server 68 | 69 | - `ALLOCATE`リクエスト時 70 | - `USERNAME`属性の値をユーザー名とタイムスタンプに分割する 71 | - そしてタイムスタンプを検証し、期限がきれているなら`401(Unauthorized)`を返す 72 | - ユーザーIDの検証は任意で行ってもよい 73 | - このときも`401(Unauthorized)`を返す 74 | - ただし外部サービスと連携することになるはずなので、TPOに応じて 75 | - それ以外のリクエスト時 76 | - `USERNAME`はそのまま`ALLOCATE`時のものと照合される 77 | - `MESSAGE-INTEGRITY`属性は、`USERNAME`とあわせて照合される 78 | - 照合用のpasswordは、ユーザー名と秘密鍵によって計算する 79 | 80 | ## 5. Implementation Notes 81 | 82 | - 本文なし 83 | 84 | ### 5.1. Revocation 85 | 86 | - このような仕組みなので、credentialsを取り消すことはできない 87 | - 期限が切れるのを待つのがコスパとして妥当であろう 88 | - 極端に不正利用される場合は、ブラックリストを用意するなど 89 | 90 | ### 5.2. Key Rotation 91 | 92 | - HMACの特性から、定期的に鍵をローテーションするのが望ましい 93 | - RFC2104 94 | - ロールオーバーのために、少なくとも2つの鍵で`MESSAGE-INTEGRITY`を検証できるようにしたい 95 | 96 | ## 6. Security Considerations 97 | 98 | - `USERNAME`属性は盗聴できる 99 | - なのでわかりやすいIDだとトラッキングされるかも 100 | 101 | ## 7. IANA Considerations 102 | 103 | - IANAとは関係ない 104 | -------------------------------------------------------------------------------- /summary/rfc3264.md: -------------------------------------------------------------------------------- 1 | > Read [original](https://tools.ietf.org/html/rfc3264) / [markdown](../markdown/rfc3264.md) 2 | 3 | --- 4 | 5 | # An Offer/Answer Model with the Session Description Protocol (SDP) 6 | 7 | ## 1 Introduction 8 | 9 | - もともとSDPはマルチキャストのために生まれた 10 | - SAP(Session Announcement Protocol)とあわせて使う 11 | - しかしユニキャストだと、参加者の環境の要件の最小公倍数が必要 12 | - オファーとアンサーに概念を分けることでこれに対応したい 13 | - そのSDPをどう伝えるか = シグナリングは規定しない 14 | 15 | ## 2 Terminology 16 | 17 | - いつもの 18 | 19 | ## 3 Definitions 20 | 21 | - 単語の定義 22 | 23 | ## 4 Protocol Operation 24 | 25 | - オファーを何らかの経路で送る 26 | - それは受け取られるかもしれないし、拒否されるかもしれない 27 | - 拒否されるとなかったことになる 28 | - 一度オファーを受け取ったら、その側はオファーを発行してはいけない 29 | - 受取も拒否もされてないなら、新しいオファーを発行してはいけない 30 | - オファーを出していながらオファーを受け取っりする状態をグレアという 31 | - こうならないようにするのもシグナリングプロトコルの債務 32 | - たとえばSIP 33 | 34 | ## 5 Generating the Initial Offer 35 | 36 | - RFC2327では`e=`行と`p=`行が必要だったが不要にする 37 | - `o=`行: セッションのID、バージョンなど 38 | - SDPとしては複数のセッションを記述できる 39 | - けどここでは単一のセッションのみに限定 40 | - `s=`行: セッションのタイトル 41 | - 特にない場合は`-` OR 空白文字`0x20`のどちらかがおすすめ 42 | - `t=`行: セッションの時間 43 | - 外部でシグナリングする場合は`0 0` 44 | - `m=`セクション: 0個以上のメディアストリーム 45 | - `m=`行からはじまる 46 | - `a=`行: 属性を表すのに使う 47 | - マルチキャストかユニキャストかによって、`m=`セクションの構成が変わる 48 | 49 | ## 5.1 Unicast Streams 50 | 51 | - ストリームはそもそも双方向の土管 52 | - 送信専用の場合は、`a=sendonly` 53 | - 受信専用の場合は、`a=recvonly` 54 | - どっちもしない場合は、`a=inactive` 55 | - デフォルトの場合は、`a=sendrecv`で省略可能 56 | - オファーに書いてあるアドレスとポートに対してRTPが送られる 57 | - RTCPは明示されない限り`そのポート + 1`に送られる 58 | - ポートが`0`の場合は、そのメディアは使わないという意味 59 | - 最初のオファーにおいては無意味な指定 60 | - ただSDPの仕様としては、アンサーで使うために説明してる 61 | - RTPならRTPのペイロードタイプが記載される 62 | - `a=rtpmap` 63 | - 複数記載することで、どれかが使えるという意味になる 64 | - セッションの途中で変えることもできる 65 | - `a=fmtp`で細かいパラメータを指定する 66 | - `m=`行のフォーマットは優先度順 67 | - `a=ptime`: パケットの間隔は`0`より大きい値 68 | - ストリームは複数あることもある 69 | - それぞれエンコーディングが違ってもよい 70 | - 複数受け取ったら、全て表示する必要がある 71 | - 表示する出口が1つの場合、何らかの形で1つにする必要がある 72 | - 送信元が同じであれば、送信前に結合されている必要がある 73 | - プリペイドのテレホンカードのアプリが典型例 74 | 75 | ## 5.2 Multicast Streams 76 | 77 | - `recvonly`か`sendonly`なストリームが含まれる場合 78 | - 誰かしらがそれを望んでいるということ 79 | 80 | ## 6 Generating the Answer 81 | 82 | - オファーとアンサーは別の参加者によって作られる 83 | - `o=`行は異なるし無関係 84 | - オファーの`m=`セクションとアンサーの`m=`セクションの数は同じである必要がある 85 | - `t=`行は一致している必要がある 86 | - なんらかの理由でオファーを拒否することもある 87 | - その場合は当然メディアを送ってはいけない 88 | - `m=`行のポートを`0`にする 89 | 90 | ## 6.1 Unicast Streams 91 | 92 | - オファーに`sendonly`とある場合は、`recvonly`か`inactive`でアンサーする 93 | - `sendrecv`がきたら、`sendonly`か`recvonly`か`sendrecv`か`inactive` 94 | - アンサーで`recvonly`を返す場合は、メディアフォーマットを1つ以上含める 95 | - もちろん追加のフォーマットを提示してもいい 96 | - `sendonly`を返す場合は、オファーにあるメディアフォーマットで 97 | - `m=`行のメディアフォーマットは、対応しているものをアンサーする 98 | - 対応していないものは省略される 99 | - そのほかはオファー時と同じ 100 | - 拒否したいストリームにはポートを`0`にする 101 | - アンサーを送ったら、その内容に備える必要がある 102 | - = メディアの受取に備えるということ 103 | 104 | ## 6.2 Multicast Streams 105 | 106 | - マルチキャストの場合 107 | - アンサーは複数の参加者の間でも一致しないといけない 108 | - サポートしてないフォーマットは、それを削除することで示す 109 | 110 | ## 7 Offerer Processing of the Answer 111 | 112 | - アンサーが届いたらメディアを送信してもよい 113 | - アンサーにあるフォーマットの最優先のもので 114 | - ただしこれはMUSTではなくSHOULD 115 | - 別のシグナリング方法でその旨が伝えられるかもしれないので 116 | 117 | ## 8 Modifying the Session 118 | 119 | - セッションの途中で新たなオファーを発行してもよい 120 | - また同じ手順でオファー・アンサーするだけ 121 | - その場合は、`o=`行にあるバージョンを `+1`する 122 | - そのほかは同じでよい 123 | - `m=`行は減らしてはいけない 124 | - 増えることはある 125 | - ただし`a=`行はなくてもよい 126 | 127 | ## 8.1 Adding a Media Stream 128 | 129 | - メディアを追加する場合 130 | - 新しい`m=`セクションを追加する 131 | - OR ポートが`0`だったセクションを使う 132 | - ここを見ることで、メディアの追加をアンサー側が知ることができる 133 | 134 | ## 8.2 Removing a Media Stream 135 | 136 | - メティアを削除する場合 137 | - ポート番号を`0`にする 138 | - その場合、`a=`行を省略してもいい 139 | - 削除したストリームに対してはもちろんメディアを送信してはいけない 140 | - これによってリソースの開放ができる 141 | 142 | ## 8.3 Modifying a Media Stream 143 | 144 | - メディアの特徴も変更できる 145 | 146 | ## 8.3.1 Modifying Address, Port or Transport 147 | 148 | - ポートの変更 149 | - `m=`行の該当部分を書き換えて送る 150 | - その他の指定は変えないほうがよい 151 | - 移行完了するまで、古いポートへの送信をやめないほうがよい 152 | - 受信側も、古いポートに溜まっているパケットを全て再生してから新しいものを 153 | - アドレスの変更も基本的にはポートと同じ 154 | - ただし回線が変わるだろう 155 | 156 | ## 8.3.2 Changing the Set of Media Formats 157 | 158 | - メディアのフォーマットセットの変更 159 | - `m=`行の該当部分を書き換えて送る 160 | - ただしRTPでは動的なペイロードタイプの番号はセッション中に変えられない 161 | - 以前存在していたフォーマットが消えたなら、それはもう使ってはいけない 162 | - 以前は使っていたとしても使ってはいけない 163 | - どうやってフォーマットの変更完了を検知するか 164 | - ポートも変更してしまう 165 | - 新しいペイロードタイプにする 166 | - タイマーを使う（1分も待てば十分） 167 | 168 | ## 8.3.3 Changing Media Types 169 | 170 | - メディアのタイプ変更（オーディオとビデオ） 171 | - `m=`行の該当部分を書き換えて送る 172 | 173 | ## 8.3.4 Changing Attributes 174 | 175 | - `a=`を変えたい場合 176 | - 上述のいずれかの方法で、メディアを送りなおす 177 | 178 | ## 8.4 Putting a Unicast Media Stream on Hold 179 | 180 | - 通話中に保留したいのようなケース 181 | - `sendrecv`だったものを`sendonly`、`inactive`にする 182 | - 新しいオファーを送るだけ 183 | - アドレスを`0.0.0.0`にする案があったが非推奨 184 | - ただし最初のオファーで送信元アドレスが確定してないがオファー発行したい場合などに使えるかも 185 | 186 | ## 9 Indicating Capabilities 187 | 188 | - オファーを発行する前に、アンサー側が受け取れるメディアフォーマットがわかると嬉しい 189 | - SIPにはそういう機能がある 190 | - そういったやりとりをSDPを使ってやってもいい 191 | - ただしSDP自体にそういう意味合いは薄い 192 | - 将来的に拡張されるかもしれない 193 | - WebRTCでは少なくともやってない 194 | 195 | ## 10 Example Offer/Answer Exchanges 196 | 197 | - オファー・アンサーのSDPの例 198 | 199 | ## 10.1 Basic Exchange 200 | 201 | - AliceとBobが1:1でオファー・アンサー 202 | 203 | ## 10.2 One of N Codec Selection 204 | 205 | - 事前にメディアフォーマットをsyncするパターン 206 | 207 | ## 11 Security Considerations 208 | 209 | - セキュリティの懸念がいくつかある 210 | - 盗聴 211 | - 通話の無効化 212 | - 不要なメディアの挿入など 213 | - オファーとアンサーは暗号化されるべき 214 | - シグナリング側でMUSTで対応する 215 | - 古いオファー・アンサーのリプレイ攻撃も要対応 216 | - 順序付けするなどして 217 | - SIPはこれらに対応している 218 | 219 | ## 12 IANA Considerations 220 | 221 | - IANAには関係なし 222 | -------------------------------------------------------------------------------- /summary/rfc3605.md: -------------------------------------------------------------------------------- 1 | > Read [original](https://tools.ietf.org/html/rfc3605) / [markdown](../markdown/rfc3605.md) 2 | 3 | --- 4 | 5 | # RTCP attribute in SDP 6 | 7 | ## 1. Introduction 8 | 9 | - SIPでSDPを交換してセッションを確立する 10 | - SDPにはIPアドレスやUDPのポートが記載される 11 | - それはだいたいRTPが前提になってる 12 | - RTPを使うならRTCPも使うことになる 13 | - そのRTCP用のIPとポートをどう決めるか 14 | - SDPでそれを指定することで確実性をもたせたい 15 | 16 | ## 2. Description of the Solution 17 | 18 | - RTCPに使われるポートを記載することで解決したい 19 | 20 | ### 2.1. The RTCP Attribute 21 | 22 | - `a=rtcp`属性 23 | - オプションで`nettype`などがつくことも 24 | - 例 25 | - `a=rtcp:53020` 26 | - `a=rtcp:53020 IN IP4 126.16.64.4` 27 | - `a=rtcp:53020 IN IP6 2001:2345:6789:ABCD:EF01:2345:6789:ABCD` 28 | - メディアレベル限定 29 | 30 | ## 3. Discussion of the Solution 31 | 32 | - この属性は有用なのかについての議論 33 | - ポートが正しいものなのか確認できるのか？ 34 | - 既存の属性で定義できないか？など 35 | 36 | ### 3.1. How do we Discover Port Numbers? 37 | 38 | - ポート番号をどのように確定するか 39 | - RTP/RTCPにそれぞれポートを割り振る 40 | - STUNサーバーにそこからメッセージを送る 41 | - レスポンスに含まれるポートを使う 42 | 43 | ### 3.2. Do we need to Support Multiple Ports? 44 | 45 | - メディアの送信に複数のポートを使っている場合 46 | - `m=video 49170/2 RTP/AVP 31` 47 | - RTP: 49170, RTCP: 49171 48 | - RTP: 49172, RTCP: 49173 49 | - ただ実情として使われていない 50 | 51 | ### 3.3. Why not Expand the Media Definition? 52 | 53 | - RTPのポートは`m=`行に記載されている 54 | - RTCPのポートもそこに書くほうがいろいろと楽では？ 55 | - 最初はそう検討していたが、冗長であるし、後方互換性が重要 56 | - この行が理解されないと、RTPまで送ることができなくなる 57 | - それは避けるべきだった 58 | - 新しい属性の場合は、理解できないならそれだけ無視すればいい 59 | 60 | ## 4. UNSAF Considerations 61 | 62 | - この属性はRFC3489のSTUNとあわせて使うことを想定 63 | - そのため、一般的な問題もある 64 | - RFC3424 65 | - その解決策が将来的に出てくるかも 66 | - RTP/RTCPのポート番号のペアを取得できる明示的なプロトコルとか 67 | - IPv6が一般的になるとか 68 | 69 | ## 5. Security Considerations 70 | 71 | - セキュリティに関する懸念は、SDPに関するものと同様 72 | 73 | ## 6. IANA Considerations 74 | 75 | - SDPの属性として`a=rtcp`を追加 76 | - メディアレベル限定 77 | -------------------------------------------------------------------------------- /summary/rfc4145.md: -------------------------------------------------------------------------------- 1 | > Read [original](https://tools.ietf.org/html/rfc4145) / [markdown](../markdown/rfc4145.md) 2 | 3 | --- 4 | 5 | # TCP-Based Media Transport in the SDP 6 | 7 | ## 1. Introduction 8 | 9 | - SDP自体はただのテキストファイル 10 | - どんなメディアを送受信したいかはプロトコルを記述することで決まる 11 | - `RTP/AVP`や`UDP`など 12 | - この仕様では`TCP`を追加する 13 | - `TCP`のセッション確立のために、`setup`と`connection`という属性を追加する 14 | 15 | ## 2. Terminology 16 | 17 | - いつもの 18 | 19 | ## 3. Protocol Identifier 20 | 21 | - `m=`行の`proto`の値に`TCP`を追加する 22 | 23 | ## 4. Setup Attribute 24 | 25 | - `a=setup`属性 26 | - 指定できる値は4つ 27 | - `active`: 接続をはじめる側 28 | - `passive`: 接続を待ち受ける側 29 | - `actpass`: その両方 30 | - `holdconn`: 接続を期待していない 31 | 32 | ### 4.1. The Setup Attribute in the Offer/Answer Model 33 | 34 | - `a=setup`は、オファー・アンサーの過程でネゴシエーションされる 35 | - オファー側の値によって、アンサー側の値は決まる 36 | - オファー側 - アンサー側 37 | - `active` - `passive` OR `holdconn` 38 | - `passive` - `active` OR `holdconn` 39 | - `actpass` - `active` OR `passive` OR `holdconn` 40 | - `holdconn` - `holdconn` 41 | - デフォルトは、オファー側が`active`でアンサー側が`passive` 42 | 43 | ## 5. The Connection Attribute 44 | 45 | - `a=connection`属性 46 | - 値は`new`か`existing` 47 | - 既に確立したセッションの途中で新しいTCP接続にしたいこともあるはず 48 | - デフォルトはどちらも`new` 49 | - WebRTCでは使ってない 50 | 51 | ### 5.1. Offerer Behaviour 52 | 53 | - オファー側の観点 54 | - 初期のオファーは`new`になる 55 | - その後、既存のTCPトランスポートを使いまわしたい場合は`existing`を指定 56 | - オファー側 - アンサー側 57 | - `new` - `new` 58 | - `existing` - `existing` OR `new` 59 | 60 | ### 5.2. Answerer Behaviour 61 | 62 | - アンサー側の観点 63 | - 先述の組み合わせの通り 64 | 65 | ## 6. Connection Management 66 | 67 | - TCPのコネクションをどう扱うか 68 | 69 | ### 6.1. Connection Establishment 70 | 71 | - メディアの送信に関わらず、速やかにTCPコネクションを開始する 72 | - つまりメディアをいつでも送信できるように 73 | 74 | ### 6.2. Connection Reestablishment 75 | 76 | - TCPコネクションが閉じられたら、`a=connection:new`で再ネゴシエーション 77 | 78 | ### 6.3. Connection Termination 79 | 80 | - 接続終了は様々な要因で起こる 81 | - 起きたらTCPコネクションも終了する 82 | 83 | ## 7. Examples 84 | 85 | - `a=setup`の使用例 86 | 87 | ### 7.1. Passive/Active 88 | 89 | - オファー側 - アンサー側 90 | - 基本の`passive` - `active` 91 | 92 | ### 7.2. Actpass/Passive 93 | 94 | - `actpass` - `passive` 95 | - ネゴシエーションしたら、オファー側から接続を開始する 96 | 97 | ### 7.3. Existing Connection Reuse 98 | 99 | - `a=connection:existing`の例 100 | 101 | ### 7.4. Existing Connection Refusal 102 | 103 | - `a=connection:existing`の例 104 | - ただし`new`でアンサーする 105 | 106 | ## 8. Other Connection-Oriented Transport Protocols 107 | 108 | - ここで定義した内容は、TCP以外のコネクション確立にも使われるかも 109 | - 将来的に 110 | - `TCP`を含むプロトコルの場合は、`TCP/XXX`のようにする 111 | - Half-closeの概念がないトランスポートもあるかも 112 | - TCPと違って 113 | - その場合は、またひと手間が必要になるかも 114 | 115 | ## 9. Security Considerations 116 | 117 | - SDPそのものへのセキュリティ事項と同じ 118 | 119 | ## 10. IANA Considerations 120 | 121 | - セッションレベルかメディアレベルに2つの属性を追加する 122 | - `a=setup` 123 | - `a=connection` 124 | - メディアレベルのプロトコルに`TCP`を追加 125 | -------------------------------------------------------------------------------- /summary/rfc4556.md: -------------------------------------------------------------------------------- 1 | > Read [original](https://tools.ietf.org/html/rfc4556) / [markdown](../markdown/rfc4556.md) 2 | 3 | --- 4 | 5 | # SDP: Session Description Protocol 6 | 7 | ## 1. Introduction 8 | 9 | - マルチメディア向けのセッション確立のためにSDPというフォーマットがある 10 | - SDPをどうやり取りするかはお任せ 11 | 12 | ## 2. Glossary of Terms 13 | 14 | - いつもの 15 | 16 | ## 3. Examples of SDP Usage 17 | 18 | - 本文なし 19 | 20 | ### 3.1. Session Initiation 21 | 22 | - SIPの場合はそれ用のメッセージではじめる 23 | - WebRTCだとオファー・アンサーモデルが採用されてる 24 | 25 | ### 3.2. Streaming Media 26 | 27 | - メディアの送信にはRTSPを使う 28 | - SDPの一部にそれ用のパラメータを記述するようになってる 29 | 30 | ### 3.3. Email and the World Wide Web 31 | 32 | - SDPはメールでも送ることができる 33 | - `application/sdp` 34 | 35 | ### 3.4. Multicast Session Announcement 36 | 37 | - 複数人を参加させたい場合 38 | - SAP(Session Announcement Protocol)というのがある 39 | - マルチキャストのグループにSDPを定期送信する 40 | 41 | ## 4. Requirements and Recommendations 42 | 43 | - SDPの目的 44 | - セッションを告知する目的 45 | - セッションに参加するために情報をやり取りする目的 46 | - SDPに記載されていること 47 | - セッションの名前、目的 48 | - 時間 49 | - 構成するメディア 50 | - そのメディアの要件 51 | - etc... 52 | 53 | ### 4.1. Media and Transport Information 54 | 55 | - メディアの要件 56 | - 種類（動画・音声） 57 | - プロトコル（RTP） 58 | - コーデック（H.264、VP8） 59 | - そのメディアがどのトランスポートアドレスに送られるか 60 | 61 | ### 4.2. Timing Information 62 | 63 | - セッションの時間を書いておける 64 | - 時間が決まってることもあれば、決まってないのもある 65 | 66 | ### 4.3. Private Sessions 67 | 68 | - SDPにプライベートなセッションを作る機能はない 69 | - 身内でSDPをやり取りすればそれがプライベート 70 | - メディアを暗号化してるキーを別でやり取りしてね 71 | 72 | ### 4.4. Obtaining Further Information about a Session 73 | 74 | - セッションの詳細を知るためのリンクを付与してもいい 75 | 76 | ### 4.5. Categorisation 77 | 78 | - セッションの告知の際にフィルターできるようにつけられる 79 | - `a=cat`行がそれ 80 | - WebRTCでは使わない 81 | 82 | ### 4.6. Internationalisation 83 | 84 | - 文字コードはUTF8が推奨 85 | 86 | ## 5. SDP Specification 87 | 88 | - 書式について 89 | - `=`の行から成る 90 | - ``は1文字 91 | - 大文字・小文字は区別される 92 | - ``は半角スペースで複数に区切られる 93 | - `=`の両側に空白はつけてはいけない 94 | - セッションレベル + 0個以上のメディアレベルのセクションから成る 95 | - 各行末はCRLFで改行する 96 | - セッションレベル 97 | - `v=`行からはじまる 98 | - メディアレベル 99 | - `m=`行からはじまる 100 | - それぞれRequiredな行とOptionalな行がある 101 | - 記述される順序にも決まりがある 102 | - セッションレベルで記述したものは、メディアレベルで上書きもできる 103 | - ただし`c`, `a`だけ 104 | 105 | ### 5.1. Protocol Version ("v=") 106 | 107 | - セッションレベルに登場 108 | - 必須 109 | - `v=0` 110 | - マイナーバージョンはない 111 | 112 | ### 5.2. Origin ("o=") 113 | 114 | - セッションレベルに登場 115 | - 必須 116 | - `o= ` 117 | - WebRTCだと 118 | - `o=- 7050844505790472601 2 IN IP4 127.0.0.1` 119 | 120 | ### 5.3. Session Name ("s=") 121 | 122 | - セッションレベルに登場 123 | - 必須 124 | - 空にしてはいけない 125 | - 特に名前ないなら` `でもいい 126 | - WebRTCだと 127 | - `s=-` 128 | 129 | ### 5.4. Session Information ("i=") 130 | 131 | - セッションレベル、メディアレベルに登場 132 | - どちらも任意 133 | 134 | ### 5.5. URI ("u=") 135 | 136 | - セッションレベルに登場 137 | - 任意 138 | 139 | ### 5.6. Email Address and Phone Number ("e=" and "p=") 140 | 141 | - セッションレベルに登場 142 | - 任意 143 | 144 | ### 5.7. Connection Data ("c=") 145 | 146 | - セッションレベル、メディアレベルに登場 147 | - セッションレベルに必須 OR 各メディアレベルに必須 148 | - WebRTCだと 149 | - `c=IN IP4 0.0.0.0` 150 | - ICEでやるので使ってない 151 | 152 | ### 5.8. Bandwidth ("b=") 153 | 154 | - セッションレベル、メディアレベルに登場 155 | - どちらも任意 156 | - `b=:` 157 | - `bwtype`は`CT`: 全体 OR `AS`: RTP 158 | 159 | ### 5.9. Timing ("t=") 160 | 161 | - セッションレベルに登場 162 | - 必須 163 | - WebRTCだと 164 | - `t=0 0` 165 | - 意味としては永続セッション 166 | 167 | ### 5.10. Repeat Times ("r=") 168 | 169 | - セッションレベルに登場 170 | - 任意 171 | 172 | ### 5.11. Time Zones ("z=") 173 | 174 | - セッションレベルに登場 175 | - 任意 176 | 177 | ### 5.12. Encryption Keys ("k=") 178 | 179 | - セッションレベル、メディアレベルに登場 180 | - どちらも任意 181 | - 使用は推奨しない 182 | 183 | ### 5.13. Attributes ("a=") 184 | 185 | - セッションレベル、メディアレベルに登場 186 | - どちらも任意 187 | - `a=` OR `a=:` 188 | 189 | ### 5.14. Media Descriptions ("m=") 190 | 191 | - メディアレベルに登場 192 | - 必須 193 | - 子情報として`i`, `c`, `b`, `k`, `a`が任意で定義できる 194 | - `m= [...]` 195 | - ``: `audio`, `video`, `text`, `application`, `message` 196 | - ``: `udp` or `RTP/AVP` or `RTP/SAVP` 197 | - ``: ``によるがRTPが使えるならそのペイロードタイプ番号が並ぶ 198 | - WebRTCだと 199 | - `m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126` 200 | - ICEでやるので使ってなくて、`9`はダミーとしての固定値 201 | 202 | ## 6. SDP Attributes 203 | 204 | - `a=`の例示 205 | - 自由に追加できるのであくまで一例 206 | - `a=rtpmap: / [/]` 207 | - `m=`行のペイロードタイプとマッピングするやつ 208 | - `a=fmtp: ` 209 | - ペイロードタイプへの追加パラメーター 210 | 211 | ## 7. Security Considerations 212 | 213 | - SIPを使うならSIPのセキュリティ事項をみてね 214 | - 信頼できないトランスポートで受け取ったSDPは各自で注意 215 | 216 | ## 8. IANA Considerations 217 | 218 | - 本文なし 219 | 220 | ### 8.1. The "application/sdp" Media Type 221 | 222 | - `application/sdp`というメディアタイプを登録する 223 | - `.sdp`ファイル 224 | 225 | ### 8.2. Registration of Parameters 226 | 227 | - 後述するパラメータを登録する 228 | 229 | #### 8.2.1. Media Types ("media") 230 | 231 | - `audio` 232 | - `video` 233 | - `application` 234 | - `text` 235 | - `message` 236 | 237 | #### 8.2.2. Transport Protocols ("proto") 238 | 239 | - `RTP/AVP` 240 | - `RTP/SAVP` 241 | - `udp` 242 | 243 | #### 8.2.3. Media Formats ("fmt") 244 | 245 | - `proto`で指定されたプロトコルで使われるメディアのタイプのこと 246 | - RTPのペイロードタイプ 247 | 248 | #### 8.2.4. Attribute Names ("att-field") 249 | 250 | - `a=xxx`の`xxx`の部分で規定したものがいくつかある 251 | - `recvonly`とか`sendonly`とか`sendrecv`とか 252 | - `rtpmap`とか`fmtp`とか 253 | 254 | #### 8.2.5. Bandwidth Specifiers ("bwtype") 255 | 256 | - 帯域を指定するやつ 257 | 258 | #### 8.2.6. Network Types ("nettype") 259 | 260 | - インターネットの場合は`IN` 261 | 262 | #### 8.2.7. Address Types ("addrtype") 263 | 264 | - `IP4`と`IP6` 265 | 266 | #### 8.2.8. Registration Procedure 267 | 268 | - RFCに追加したいものがある場合はこちら 269 | 270 | ### 8.3. Encryption Key Access Methods 271 | 272 | - `k=`行は使わないでね 273 | 274 | ## 9. SDP Grammar 275 | 276 | - SDPの構文のおさらい 277 | -------------------------------------------------------------------------------- /summary/rfc5389.md: -------------------------------------------------------------------------------- 1 | > Read [original](https://tools.ietf.org/html/rfc5389) / [markdown](../markdown/rfc5389.md) 2 | 3 | --- 4 | 5 | # Session Traversal Utilities for NAT (STUN) 6 | 7 | ## 1. Introduction 8 | 9 | - STUNはNAT越えのためのユーティリティ 10 | - ユースケースはここではなく別のRFCで規定される 11 | - その際に拡張されたりもする 12 | 13 | ## 2. Evolution from RFC 3489 14 | 15 | - 元々はRFC 3489で定義されていた 16 | - 紆余曲折あって新装改訂したのがコレ 17 | - 古いやつはClassic STUNと呼んだりも 18 | 19 | ## 3. Overview of Operation 20 | 21 | - STUNはクラサバの様態で使う 22 | - 場合によっては1つのエンドポイントが両方の役割を担うこともある 23 | - STUNメッセージというものを送りあうよ 24 | - ざっくり用途の説明だが詳細はすべて追って 25 | 26 | ## 4. Terminology 27 | 28 | - `MUST`とか`SHOULD`とか大文字用語に従って実装してね 29 | 30 | ## 5. Definitions 31 | 32 | - いわゆる用語説明 33 | 34 | ## 6. STUN Message Structure 35 | 36 | - STUNメッセージのペイロードフォーマットについて 37 | - ヘッダは20byteで固定 38 | - type / length / MagicCookie / TransactionId 39 | - MessageTypeは4つのclassと1つのmethodの組み合わせで4種 40 | - MagicCookieは`0x2112a442` 41 | 42 | ## 7. Base Protocol Procedures 43 | 44 | - メッセージの用途について 45 | 46 | ### 7.1. Forming a Request or an Indication 47 | 48 | - 結局はユースケースに依る 49 | 50 | ### 7.2. Sending the Request or Indication 51 | 52 | - STUNメッセージはUDPでもTCPで送ってもいい 53 | 54 | #### 7.2.1. Sending over UDP 55 | 56 | - UDPでやるなら自分で再送してね 57 | - 再送はRTO(RetransmissionTimeOut)値に従う 58 | - 再送するたびに+2倍していく（0, 500, 1500, 3500...） 59 | - RTOはRTTから見積もった値 60 | - `500ms`以上で設定できるようにすべき 61 | - RTOはキャッシュされるべきだが、`10min`でクリアされる 62 | - TransactionIDをチェックするために、一定期間はリクエストへの参照を持っておく 63 | 64 | #### 7.2.2. Sending over TCP or TLS-over-TCP 65 | 66 | - TCPとTLS-over-TCPの場合について 67 | - コネクションの兼ね合いについてあれこれ 68 | 69 | ### 7.3. Receiving a STUN Message 70 | 71 | - STUNメッセージを受け取ったらチェックすべきこと 72 | - 先頭2bitが0とか、MagicCookieの値とか、TransactionIdとか 73 | - `FINGERPRINT`やその他認証も必要あれば 74 | 75 | #### 7.3.1. Processing a Request 76 | 77 | - 受け取ったリクエストを検証してからレスポンスを用意する 78 | - その際は再送されたものかなどなどチェックが必要 79 | - ただステートレスにしたいと思うので、まぁよしなに 80 | 81 | ##### 7.3.1.1. Forming a Success or Error Response 82 | 83 | - レスポンスは`Success`か`Error`か2択 84 | - `Error`の場合は、`ERROR-CODE`属性が必須 85 | - `Success`の場合は、`XOR-MAPPED-ADDRESS`属性を 86 | 87 | ##### 7.3.1.2. Sending the Success or Error Response 88 | 89 | - レスポンスはリクエストのトランスポートで返す 90 | - UDPならUDP、TCPならTCP 91 | 92 | #### 7.3.2. Processing an Indication 93 | 94 | - リクエストのほかにレスポンスを期待しないインディケーションがある 95 | - WebRTCでは使ってない 96 | 97 | #### 7.3.3. Processing a Success Response 98 | 99 | - WebRTCでは使ってないので割愛 100 | 101 | #### 7.3.4. Processing an Error Response 102 | 103 | - WebRTCでは使ってないので割愛 104 | 105 | ## 8. FINGERPRINT Mechanism 106 | 107 | - そのポートをSTUN以外にも使ってる場合に、STUNのパケットをどう見分けるか 108 | - Section 6.にある固定値のフィールドを見る 109 | - 必要なら`FINGERPRINT`属性を使う 110 | 111 | ## 9. DNS Discovery of a Server 112 | 113 | - STUNサーバーをインターネットに公開するならの話 114 | - わかるドメイン名にしてねとか 115 | - デフォルトポートの話とか 116 | 117 | ## 10. Authentication and Message-Integrity Mechanisms 118 | 119 | - short-termな認証、long-termな認証が使える 120 | - それぞれユースケースによって必要なら使ってね 121 | 122 | ### 10.1. Short-Term Credential Mechanism 123 | 124 | - short-termは制限時間つきの認証 125 | - ICEでは`username`と`password`を使ってる 126 | 127 | #### 10.1.1. Forming a Request or Indication 128 | 129 | - `USERNAME`と`MESSAGE-INTEGRITY`属性を使うことが必須 130 | - `password`は露出させないように 131 | 132 | #### 10.1.2. Receiving a Request or Indication 133 | 134 | - リクエストの検証について 135 | - 必須の属性がない場合に適切に`Error`を返すべし 136 | - レスポンスは`MESSAGE-INTEGRITY`が必須で、`USERNAME`は含んではならない 137 | 138 | #### 10.1.3. Receiving a Response 139 | 140 | - 返ってきたレスポンスを検証する 141 | - `MESSAGE-INTEGRITY`の値を検証する 142 | - 違ってたらそのレスポンスは捨てる 143 | 144 | ### 10.2. Long-Term Credential Mechanism 145 | 146 | - long-termの認証 147 | - 事前に入手したであろう`username`と`password`を使う 148 | 149 | #### 10.2.1. Forming a Request 150 | 151 | - 初回のリクエストと、そのレスポンスを受け取って以降のリクエストを分けて扱う 152 | 153 | ##### 10.2.1.1. First Request 154 | 155 | - `USERNAME`, `MESSAGE-INTEGRITY`, `REALM`, `NONCE`属性を送る 156 | - 初回なので、いうなれば認証も何もない 157 | 158 | ##### 10.2.1.2. Subsequent Requests 159 | 160 | - 返ってきた`username`, `password`, `REALM`, `NONCE`をキャッシュしておく 161 | - 以降のリクエストではそれを送る 162 | 163 | #### 10.2.2. Receiving a Request 164 | 165 | - リクエストの検証について 166 | - 問題なければレスポンスを返す 167 | - `MESSAGE-INTEGRITY`は必須だが、`REALM`, `NONCE`, `USERNAME`は含まない 168 | 169 | #### 10.2.3. Receiving a Response 170 | 171 | - レスポンスの検証について 172 | - レスポンスがおかしかったらリクエストをやり直す 173 | 174 | ## 11. ALTERNATE-SERVER Mechanism 175 | 176 | - 違うSTUNサーバーに行って欲しいときに 177 | - `ALTERNATE-SERVER`属性を使う 178 | - リダイレクトループにならないためにどうするか 179 | 180 | ## 12. Backwards Compatibility with RFC 3489 181 | 182 | - Classic STUNとの後方互換性について 183 | - 詳細はSection 19. 184 | 185 | ### 12.1. Changes to Client Processing 186 | 187 | - Classic STUNなサーバーにリクエストを送りたい場合の話 188 | - UDPで属性なしで送れなど 189 | 190 | ### 12.2. Changes to Server Processing 191 | 192 | - サーバーは受け取ったリクエストを見れば、それがClassic STUNのメッセージかわかる 193 | - その場合はこうしてあげなさいという話 194 | 195 | ## 13. Basic Server Behavior 196 | 197 | - スタンドアロンなSTUNサーバーを建てるときの話 198 | - 認証は受け付けない 199 | - UDP/TCPどっちもサポートしろなど 200 | 201 | ## 14. STUN Usages 202 | 203 | - 執筆時点でのSTUNのユースケースは3つ 204 | - ICE: MMUSIC-ICE 205 | - SIP: SIP-OUTBOUND 206 | - NAT: BEHAVE-NAT 207 | - まあこの先きっと拡張されるでしょうけど 208 | 209 | ## 15. STUN Attributes 210 | 211 | - 各属性の詳細について 212 | - 基本はType/Length/Valueの3部構成 213 | - 32bit境界なのでValueはLengthで切り出す 214 | 215 | ### 15.1. MAPPED-ADDRESS 216 | 217 | - Family/Port/Address 218 | - IPv4かIPv6かで長さは変わる 219 | 220 | ### 15.2. XOR-MAPPED-ADDRESS 221 | 222 | - `MAPPED-ADDRESS`と基本的に同じ 223 | - ただPort/Addressが`XOR`で演算されてる 224 | - IPv4かIPv6かでロジックは変わる 225 | 226 | ### 15.3. USERNAME 227 | 228 | - 認証に使う 229 | - 値のみの属性 230 | 231 | ### 15.4. MESSAGE-INTEGRITY 232 | 233 | - 属性の列の最後尾につける決まり（ただし`FINGERPRINT`があるならそっちが最後尾） 234 | - HMAC-SHA1なので20byte 235 | - この属性を含まないメッセージの全体を使って計算する 236 | - ダミーの値で先に属性を追加して長さをアップデートしてから計算 237 | - 値は後で書き換え 238 | - 検証するときも注意 239 | 240 | ### 15.5. FINGERPRINT 241 | 242 | - 属性の列の最後尾につける決まり 243 | - `MESSAGE-INTEGRITY`と一緒で、先にダミーを使って計算する 244 | - `MESSAGE-INTEGRITY`の計算時はこいつの存在を考慮する必要がある 245 | - こいつを含まないメッセージの全体を使うので 246 | - `crc32(msg) XOR 0x5354554e` 247 | 248 | ### 15.6. ERROR-CODE 249 | 250 | - 3桁数字のエラーコードと説明文 251 | - Section 15.6に例文がある 252 | 253 | ### 15.8. NONCE 254 | 255 | - ただの値 256 | 257 | ### 15.7. REALM 258 | 259 | - ただの値 260 | - これがあるとlong-termの認証をすることがわかる 261 | 262 | ### 15.9. UNKNOWN-ATTRIBUTES 263 | 264 | - `Error`レスポンスで`ERROR-CODE`で`420`を返すときにつける属性 265 | - 不明な属性のTypeを返す 266 | 267 | ### 15.10. SOFTWARE 268 | 269 | - 己の名をいれる属性 270 | - 特別な用途はない 271 | 272 | ### 15.11. ALTERNATE-SERVER 273 | 274 | - `MAPPED-ADDRESS`と同じ形式 275 | 276 | ## 16. Security Considerations 277 | 278 | - セキュリティ的な観点について 279 | 280 | ### 16.1. Attacks against the Protocol 281 | 282 | - 本文なし 283 | 284 | #### 16.1.1. Outside Attacks 285 | 286 | - 改ざんは`MESSAGE-INTEGRITY`で対応できる 287 | - 辞書攻撃は強固なパスワードを用意することで対応してね 288 | 289 | #### 16.1.2. Inside Attacks 290 | 291 | - DoS攻撃は不可避 292 | - `SOFTWARE`属性でログ取るなどしてもいい 293 | 294 | ### 16.2. Attacks Affecting the Usage 295 | 296 | - STUNサーバーだけではどうしようもない攻撃もある 297 | - ソースIPの書き換えとか 298 | - なのでクライアント側での対処も必要 299 | 300 | #### 16.2.1. Attack I: Distributed DoS (DDoS) against a Target 301 | 302 | - どのリクエストにも特定のクライアントのアドレスを返すやつ 303 | - そのクライアントにアクセスが集中する 304 | 305 | #### 16.2.2. Attack II: Silencing a Client 306 | 307 | - 偽のアドレスを返す 308 | - もちろん何も返ってこないので困る 309 | 310 | #### 16.2.3. Attack III: Assuming the Identity of a Client 311 | 312 | - 自身のアドレスを返すことで、代わりにパケットを受け取る 313 | - いわゆるなりすまし 314 | 315 | #### 16.2.4. Attack IV: Eavesdropping 316 | 317 | - いわゆる盗聴 318 | - 経路が既にわかってる場合にしかできない 319 | 320 | ### 16.3. Hash Agility Plan 321 | 322 | - この仕様では暗号にHMAC-SHA1を使ってる 323 | - それが古くなったり問題があったら、新しい`MESSAGE-INTEGRITY`属性をつくるだろう 324 | 325 | ## 17. IAB Considerations 326 | 327 | - IABのUNSAFについてのご意見 328 | 329 | ## 18. IANA Considerations 330 | 331 | - IANAがSTUNのためにレジストリを用意した話 332 | 333 | ### 18.1. STUN Methods Registry 334 | 335 | - この仕様では`0x001`のBindingだけ 336 | - レンジは`0x000`から`0x7ff`まで 337 | 338 | ### 18.2. STUN Attribute Registry 339 | 340 | - 8つの必須属性と3つにオプション属性を定義した 341 | - レンジは`0x0000`から`0xffff`まで 342 | 343 | ### 18.3. STUN Error Code Registry 344 | 345 | - エラーコードは`0`から`699`まで 346 | 347 | ### 18.4. STUN UDP and TCP Port Numbers 348 | 349 | - `stun`のためのポート番号も定義した 350 | - `3478/tcp`と`3478/udp` 351 | - `stuns`のために`5349/tcp`も用意した 352 | 353 | ## 19. Changes since RFC 3489 354 | 355 | - Classic STUNとの差分 356 | -------------------------------------------------------------------------------- /summary/rfc5506.md: -------------------------------------------------------------------------------- 1 | > Read [original](https://tools.ietf.org/html/rfc5506) / [markdown](../markdown/rfc5506.md) 2 | 3 | --- 4 | 5 | # Support for Reduced-Size RTCP: Opportunities and Consequences 6 | 7 | ## 1. Introduction 8 | 9 | - RTPのRTCPは、複合パケットとして送ることになっている 10 | - SR, RRのどちから必須 + SDESなど 11 | - 重要な情報ではあるが、パケットのサイズが大きくなる問題がある 12 | - レイテンシーをとにかく重視したいケースの場合に困る 13 | - RTP/AVPFプロファイルでは、新たなフィードバック用のRTCPパケットのタイプが追加された 14 | - RFC4585 15 | - これらのフィードバックの送信は、早ければ早いほど有用 16 | - つまりこの最低限のフィードバックだけを送るようにしたい 17 | - 他のRTCPパケットを待って送信タイミングを待つよりも 18 | - そこで、Reduced-Size RTCPというものを提案する 19 | 20 | ## 2. Terminology 21 | 22 | - いつもの 23 | 24 | ## 3. Use Cases and Design Rationale 25 | 26 | - 本文なし 27 | 28 | ### 3.1. RTCP Compound Packets (Background) 29 | 30 | - 本来のRTCPについておさらい 31 | - SRパケットかRRパケット、CNAMEを含むSDESパケットを送る 32 | - どれも重要な情報を含んでいる 33 | - 定期的に送信されてこそ意味がある 34 | 35 | ### 3.2. Use Cases for Reduced-Size RTCP 36 | 37 | - Reduced-Size RTCPにするユースケースについていくつか紹介 38 | - OMA-PoCのコントロールプレーン 39 | - Codecコントロール 40 | - ビットレートの変更など 41 | - Generic NACKを使用する動画ストリームでのフィードバック 42 | - ただでさえ帯域を食うので 43 | - ステータスレポート 44 | - あえて分割して送る 45 | 46 | ### 3.3. Benefits of Reduced-Size RTCP 47 | 48 | - Reduced-Size RTCPのメリットについて 49 | - RTCPに使える帯域が限られている場合に有用 50 | - 通常より70-80bytesも小さくなる 51 | - 小さいと送信も早いし、受け取り側も解析が容易 52 | - パケットサイズが小さくなること自体より、情報量が少ないことに意味がある 53 | 54 | ### 3.4. Issues with Reduced-Size RTCP 55 | 56 | - Reduced-Size RTCPの問題について 57 | 58 | #### 3.4.1. Middle Boxes 59 | 60 | - 中継機がRTCPとして解釈できず捨ててしまうかもしれない 61 | 62 | #### 3.4.2. Packet Validation 63 | 64 | - 既存のパケットのバリデーションで落とされるかもしれない 65 | - ロジックを新しくしてもらう必要がある 66 | - 正しく解釈されなかった結果、帯域を節約できないかも 67 | 68 | #### 3.4.3. Encryption/Authentication 69 | 70 | - SRTPおよびSRTCPでも、問題なく使える 71 | 72 | #### 3.4.4. RTP and RTCP Multiplex on the Same Port 73 | 74 | - RTP/RTCPの多重化についても問題ない 75 | - そもそも多重化する際の注意点さえ踏まえていれば 76 | 77 | #### 3.4.5. Header Compression 78 | 79 | - RoHCアルゴリズムによるヘッダ圧縮 80 | - RTP/RTCPが多重化されている場合に、RTCPを判別できないかも 81 | - 将来的にRTCPが圧縮される可能性 82 | - 現状はされないことになってるけど 83 | 84 | ## 4. Use of Reduced-Size RTCP with AVPF 85 | 86 | - 特定の条件下でReduced-Size RTCPを使うのが良さそう 87 | - 通常のRTCPは、今までどおり定期的に正しく伝送されるべき 88 | - 複合パケット 89 | - その上で 90 | - フィードバックは追加のRTCPとして別途送る 91 | - プロファイルがAVPFかSAVPF、即時フィードバックモードでのみ使われるべき 92 | 93 | ### 4.1. Definition of Reduced-Size RTCP 94 | 95 | - Reduced-Size RTCPとは 96 | - 1つ以上のRTCPパケットを含む 97 | - 通常の定期送信タイミングのRTCPとしては送らない 98 | - RTP/AVPまたはRTP/SAVPプロファイルでは使われない 99 | 100 | ### 4.2. Algorithm Considerations 101 | 102 | - 本文なし 103 | 104 | #### 4.2.1. Verification of Delivery 105 | 106 | - Reduced-Size RTCPを判別するには 107 | - 正しくエンドポイント同士がこれを送受信できているかを知るには 108 | - Reduced-Size RTCPに対応していることを事前にシグナリングしておく 109 | - Reduced-Size RTCPが到着したことを自前で確認する 110 | - SR/RRを使う = これが届いている = 届いている 111 | - フィードバックRTCPパケット = Reduced-Size RTCPとして送られてくるはずなので 112 | - 判別できなかった場合は、通常のRTCPのみを解釈するように 113 | 114 | #### 4.2.2. Single vs Multiple RTCP in a Reduced-Size RTCP 115 | 116 | - 複数のRTCPを含むべきかどうか 117 | - 帯域に敏感な場合は、単一のRTCPのみを送るべき 118 | 119 | #### 4.2.3. Enforcing Compound RTCP 120 | 121 | - 定期送信されるものは通常の複合RTCPパケットであることが必要 122 | 123 | #### 4.2.4. Immediate Feedback Mode 124 | 125 | - 即時フィードバックモードでは、パケットのサイズに制限がある 126 | 127 | ## 5. Signaling 128 | 129 | - SDPに`a=rtcp-rsize`属性を追加する 130 | - これを使用することは、自身が使用可能であることも意味する 131 | - オファーに同意する場合は、アンサーでも同じように含める 132 | 133 | ## 6. Security Considerations 134 | 135 | - RTPやAVPFについてのセキュリティ要件が適用される 136 | 137 | ## 7. IANA Considerations 138 | 139 | - SDPの属性をメディアレベルに1つ追加する 140 | - `a=rtcp-rsize` 141 | -------------------------------------------------------------------------------- /summary/rfc5576.md: -------------------------------------------------------------------------------- 1 | > Read [original](https://tools.ietf.org/html/rfc5576) / [markdown](../markdown/rfc5576.md) 2 | 3 | --- 4 | 5 | # Source-Specific Media Attributes in the SDP 6 | 7 | ## 1. Introduction 8 | 9 | - SDPにはRTPなどメディアのことを記述する 10 | - 1本のRTPストリームについての記載はできるが、その中に複数ソースある場合には触れていなかった 11 | - 昨今の需要から単一のRTPセッションの中で複数のSSRCを扱うようになった 12 | - そもそもRTPはそういうものでもある 13 | - そこでSDPにそれ用の記述ができるようにしようというもの 14 | 15 | ## 2. Terminology 16 | 17 | - いつもの 18 | 19 | ## 3. Overview 20 | 21 | - RTPのセッション内で複数のソースが存在しうる 22 | - SSRC: Synchronization Source 23 | - 32bitの識別子 24 | - SDPの記述にはレベルがある 25 | - セッションレベル 26 | - メディアレベル 27 | - そこに新たなにソースレベルを追加する 28 | - SSRCによって分かれる 29 | 30 | ## 4. Media Attributes 31 | 32 | - メディアレベルに2つの属性を追加する 33 | - `a=ssrc`と`a=ssrc-group` 34 | 35 | ### 4.1. The "ssrc" Media Attribute 36 | 37 | - 記述パターン2つ 38 | - フラグ属性 `a=ssrc: ` 39 | - 値をもつ `a=ssrc: :` 40 | - この仕様では後者のパターンしか追加しない 41 | - `cname`属性が必須 42 | - 詳しくはSection 6.1. 43 | - 記述されたSSRCは、他のSDP属性から参照されたりRTPで使われるかもしれない 44 | 45 | ### 4.2. The "ssrc-group" Media Attribute 46 | 47 | - `a=ssrc-group: ...` 48 | - SSRCに紐づく各種ソースを、特定の意図でグルーピングする目的の記述 49 | - 設定されること 50 | - `FID`: Flow Identification（デフォルト） 51 | - `FEC`: Forward Error Correction 52 | - Chromeが`FID`だけ実装してる 53 | - 設定不要なものたち 54 | - `LS`: Lip Synchronization 55 | - 同じCNAMEを持つRTPソースはRTPが同期してくれるので不要 56 | - `SRF`: Single Reservation Flow 57 | - トランスポートの特性を表すだけ 58 | - `ANAT`: Alternative Network Address Types 59 | - トランスポートの特性を表すだけ 60 | - `CS`: Composite Session 61 | - RTPには当てはまらない 62 | 63 | ## 5. Usage of Identified Source Identifiers in RTP 64 | 65 | - RTPにおけるSSRCについておさらい 66 | - SSRCは異なるエンドポイントで払い出されるので衝突の可能性がある 67 | - そしてそれに備えるようRTPは規定されてる 68 | - 衝突したかどうかは、RTCPのSDESパケットでだけわかる 69 | - SDPの`a=ssrc`で見たものだけが存在すると思ってはいけない 70 | - が、見たことあるSSRCは使わないようにする必要がある 71 | - 衝突が起こった場合は、SSRCを新しくしてSDPを更新してもよい 72 | - その際は、`previous-ssrc`属性が必要 73 | - ただしSDPを再送する以前に、そもそもこのソースレベルの属性が解釈されない可能性も考慮する必要がある 74 | 75 | ## 6. Source Attributes 76 | 77 | - 属性の詳細について 78 | 79 | ### 6.1. The "cname" Source Attribute 80 | 81 | - `a=ssrc`の`cname`について 82 | - RTCPのSDESパケットのCNAMEと同じ値 83 | - 詳細はRTPの仕様を参照 84 | - RFC3550 85 | 86 | ### 6.2. The "previous-ssrc" Source Attribute 87 | 88 | - `a=ssrc`の`previous-ssrc`について 89 | - SSRCが衝突したことを示す 90 | - 新しいSSRCと、衝突していた古いSSRCを紐付ける 91 | 92 | ### 6.3. The "fmtp" Source Attribute 93 | 94 | - `a=ssrc`の`fmtp`について 95 | - `a=fmtp`と同じように、ペイロードタイプごとに 96 | 97 | ### 6.4. Other Source Attributes 98 | 99 | - 今の時点で規定してるのはこれだけ 100 | - 将来的にはまた増減するかも 101 | 102 | ## 7. Examples 103 | 104 | - SDPの例 105 | - 通常は1つの`m=`セクションに、`a=ssrc`は1つ 106 | - `cname`付き 107 | - `a=ssrc-group:FID`とかがつくと、`a=ssrc`が複数載る 108 | 109 | ## 8. Usage With the Offer/Answer Model 110 | 111 | - オファー・アンサーに与える影響 112 | - 送信側がSDPによしなに記述するだけ 113 | - 拒否するときは`m=`セクション単位なので 114 | - アンサー側はオファー側が使ってるSSRCを使わないようにしたい 115 | - 再オファーするときは、アンサー側で使ってるSSRCを使わないように 116 | 117 | ## 9. Backward Compatibility 118 | 119 | - SDPの仕様として、未知の・未対応の属性は無視できる 120 | - それに備える意味では、複数のSSRCを含めても解釈されない可能性がある 121 | - 1度に1ソースしか送らないという選択肢もある 122 | 123 | ## 10. Formal Grammar 124 | 125 | - 各属性の正式な記法について 126 | 127 | ## 11. Security Considerations 128 | 129 | - セキュリティに関してはRTPとSDPのそれに準ずる 130 | 131 | ## 12. IANA Considerations 132 | 133 | - 本文なし 134 | 135 | ### 12.1. New SDP Media-Level Attributes 136 | 137 | - SDPのメディアレベルに2つの属性を追加する 138 | - `ssrc` 139 | - `ssrc-group` 140 | - これらはソースレベルのセクションを表す 141 | 142 | ### 12.2. Registry for Source-Level Attributes 143 | 144 | - ソースレベルで使える値を追加する 145 | - `cname` 146 | - `previous-ssrc` 147 | - `fmtp` 148 | 149 | ### 12.3. Registry for Source Grouping Semantics 150 | 151 | - `ssrc-group`で指定できる値を追加する 152 | - `FID` 153 | - `FEC` 154 | -------------------------------------------------------------------------------- /summary/rfc5761.md: -------------------------------------------------------------------------------- 1 | > Read [original](https://tools.ietf.org/html/rfc5761) / [markdown](../markdown/rfc5761.md) 2 | 3 | --- 4 | 5 | # Multiplexing RTP Data and Control Packets on a Single Port 6 | 7 | ## 1. Introduction 8 | 9 | - RTPはRTCPとセットで使われる 10 | - 従来はそれぞれ異なるUDPポートが使われていた 11 | - 複数のポートを使うのは往々にしてリソースもトラフィックも増える 12 | - ファイアウォールの管理にも関係してくる 13 | - なのでできれば多重化して1つのポートで使いたい 14 | 15 | ## 2. Background 16 | 17 | - RTPの多重化はトランスポートの層でやることになっていた 18 | - シンプルだから: 別のポートなので実装も楽 19 | - 効率的だから 20 | - 第3者によるモニタリングのため: RTCPだけレポート公開とか 21 | - 単一のUDPポートによる多重化のために、RTPにも追加の実装が必要になる 22 | 23 | ## 3. Terminology 24 | 25 | - いつもの 26 | 27 | ## 4. Distinguishable RTP and RTCP Packets 28 | 29 | - RTPとRTCPを多重化すると困ること 30 | - RTCPの`PT`とRTPの`M`+`PT`の位置が被る 31 | - しかし以下の条件下では判別に使える 32 | - RTPの`PT`とRTCの`PT`が異なる値を使っている場合 33 | - RTPの`PT`+128した値がRTCPの`PT`と異なる値の場合 34 | - 既知の判別できないパターンの例 35 | - RTPの`PT`が以下の場合 36 | - `64~65`, `72~76`, `77~78`, `79`, `80` 37 | - 将来的に`PT`が追加されたら、また衝突が起きるかもしれない 38 | - なのでこれに気をつけて追加していきたい 39 | - 動的に`PT`を`96~127`の範囲で選べば問題はない 40 | 41 | ## 5. Multiplexing RTP and RTCP on a Single Port 42 | 43 | - 実際に多重化するときにどうするかについて 44 | - ユニキャストの場合、マルチキャストの場合を見ていく 45 | 46 | ### 5.1. Unicast Sessions 47 | 48 | - 多重化する場合、前もってSDPでその旨を疎通しておく 49 | - SDPにどう書けばいいか 50 | 51 | #### 5.1.1. SDP Signalling 52 | 53 | - `a=rtcp-mux`がその旨を示す 54 | - 各メディアレベル 55 | - オファー・アンサー共に 56 | - アンサーに記載がない場合は多重化してはいけない 57 | - 通常通りRTPのポート + 1 or `a=rtcp`行をみる 58 | 59 | #### 5.1.2. Interactions with SIP Forking 60 | 61 | - SIPのことなので割愛 62 | 63 | #### 5.1.3. Interactions with ICE 64 | 65 | - 多重化されない場合、ICEのコンポーネントは2つ 66 | - これも`a=rtcp-mux`行の有無で判断する 67 | - `a=rtcp`行もフォールバックのためにオファーには含める 68 | 69 | #### 5.1.4. Interactions with Header Compression 70 | 71 | - CRTPやROHCなどのヘッダ圧縮に影響を与えるかも 72 | - ヘッダ圧縮のアルゴリズムに依る 73 | - この圧縮に大きく頼ってる場合は、多重化すべきかどうか要検討 74 | 75 | ### 5.2. Any Source Multicast Sessions 76 | 77 | - Any-sourceなマルチキャストの場合は、多重化しないほうがメリットがあるはず 78 | - RTCPだけをモニタリングしたいとか 79 | 80 | ### 5.3. Source-Specific Multicast Sessions 81 | 82 | - Source-spesificなマルチキャストの場合は、RTCPの返送は別の方法を使う 83 | - 先述のヘッダ圧縮の問題に注意 84 | 85 | ## 6. Multiplexing, Bandwidth, and Quality of Service 86 | 87 | - 多重化すると、QoSの測定に影響を与えるかも 88 | - RTCPの帯域を考慮しておく必要がある 89 | - 総帯域 = RTP + RTCP 90 | - RTPの帯域は、`b=AS`または`b=TIAS`行でわかる 91 | - RTCPは、その5%と決まってるので、合計は105% 92 | - `b=RR`と`b=RS`という非標準の行によって、RTCPの帯域を知ることもできる 93 | - その場合はそれの合計を使ってもよい 94 | 95 | ## 7. Security Considerations 96 | 97 | - 特別に考慮しておくべきセキュリティリスクはない 98 | - SRTP上で多重化するなら、そっちでよしなに暗号化される 99 | 100 | ## 8. IANA Considerations 101 | 102 | - `a=rtcp-mux`という新たな属性を追加する 103 | - RTCPの`PT`を追加するときは、RTPとの衝突を避けたレンジから選ぶように 104 | -------------------------------------------------------------------------------- /summary/rfc5763.md: -------------------------------------------------------------------------------- 1 | > Read [original](https://tools.ietf.org/html/rfc5763) / [markdown](../markdown/rfc5763.md) 2 | 3 | --- 4 | 5 | # Framework for Establishing a SRTP Security Context Using DTLS 6 | 7 | ## 1. Introduction 8 | 9 | - セキュアなRTPのセッションをUDP上で、DTLS拡張を使って実現する方法について 10 | - 両方のエンドポイントが持つ鍵を交換する 11 | - 自己証明書で作ってよい 12 | - FingerprintはSDPなどでオファー・アンサーされる 13 | - SDPが持つセキュリティリスクは避けられないが、その他の要素が今まで通り使える 14 | 15 | ## 2. Overview 16 | 17 | - AliceとBobがセッションを確立しようとする 18 | - AliceからDTLSの鍵を交換しようとオファーする 19 | - SDPにFingerprintを載せる 20 | - それを使ってDTLSのハンドシェイクをする 21 | 22 | ## 3. Motivation 23 | 24 | - 以前にもこういったセキュアにしたい取り組みはあった 25 | - しかし以下の理由からこの仕様ができた 26 | - 広く普及したTLSを使いたい 27 | - メディアの送信と暗号化を分けて扱える 28 | - 鍵自体を交換しなくてよい 29 | - SSRCの衝突時にシグナリングが不要 30 | 31 | ## 4. Terminology 32 | 33 | - いつもの 34 | 35 | ## 5. Establishing a Secure Channel 36 | 37 | - DTLSのハンドシェイクで使われるCertificateは、TLSのそれと同じ 38 | - RFC4572 39 | - Certificateは、SDPに書かれたFingerprintで検証される 40 | - オファーでそれを送る 41 | - アンサー側が受け取ったらDTLSのアソシエーションを確立できる 42 | - アンサー側も同様のものをSDPで送り返す 43 | - シグナリングプレーンは、DTLSのFingerprintを伝えるだけ 44 | - あとはメディアプレーンで鍵交換と認証を行う 45 | - 実装の要件 46 | - オファー側: `a=setup:actpass`を使うこと 47 | - アンサー側: `a=setup:active`か`a=setup:passive`を使うこと 48 | - `active`が推奨 49 | - `passive`だとオファー側でアンサーの受理を待つ必要がある 50 | - いずれにせよ`active`側がClientHelloを送る 51 | - `passive`側がそれを受け取る準備をする 52 | - `a=connection`は使ってはいけない 53 | - `a=fingerprint`が必須 54 | 55 | ## 6. Miscellaneous Considerations 56 | 57 | - 本文なし 58 | 59 | ### 6.1. Anonymous Calls 60 | 61 | - 匿名コールがしたい場合 62 | - 同じエンドポイントだと悟られないよう、新たな証明書を作る必要がある 63 | 64 | ### 6.2. Early Media 65 | 66 | - Early mediaを期待するオファーが届いたら 67 | - `setup:active`ですぐにDTLSのアソシエーションを確立する 68 | 69 | ### 6.3. Forking 70 | 71 | - SIPの場合はフォーキングという概念がある 72 | - 1オファーに対してNアンサー 73 | - 特に変わった手順はなし 74 | 75 | ### 6.4. Delayed Offer Calls 76 | 77 | - SIPのINVITEの扱い 78 | - オファーではない 79 | - それを受け取った側がオファーを出す 80 | - その後はいつもどおり 81 | 82 | ### 6.5. Multiple Associations 83 | 84 | - 複数のアソシエーションを確立する場合 85 | - 複数のメディアを送るとか 86 | - WebRTCではないけど 87 | - どういう順序でさばいてもよい 88 | 89 | ### 6.6. Session Modification 90 | 91 | - セッション確立後に再ネゴシエーションする場合 92 | - DTLSアソシエーションは新規に作っても、使いまわしてもよい 93 | - `active`/`passive`の役割が変わったら、新規作成しなければならない 94 | 95 | ### 6.7. Middlebox Interaction 96 | 97 | - 中継機との兼ね合いについて 98 | 99 | #### 6.7.1. ICE Interaction 100 | 101 | - ICEとの兼ね合いについて 102 | - 複数の候補が出てくるが、DTLSハンドシェイクは1度だけになる 103 | 104 | #### 6.7.2. Latching Control without ICE 105 | 106 | - ICEが使われない場合 107 | - WebRTCではありえないので割愛 108 | 109 | ### 6.8. Rekeying 110 | 111 | - いつでもDTLSのハンドシェイクをやり直すことができる 112 | - 鍵を更新できる 113 | - 更新している間も、古い接続でメディアは流れ続ける 114 | - 新しい鍵と接続が用意できたらスイッチする 115 | 116 | ### 6.9. Conference Servers and Shared Encryptions Contexts 117 | 118 | - カンファレンスのサーバー実装の場合 119 | - 全ての参加者に対して同じ暗号化コンテキストを共有すれば、リソースは節約できる 120 | - ただし、DTLSハンドシェイクをはじめる側が不定な仕様なので、そうもいかない 121 | - コーデック処理よりも軽い処理なはずなので心配しなくていいはず 122 | 123 | ### 6.10. Media over SRTP 124 | 125 | - DTLSの上でRTP vs DTLS-SRTP 126 | - 前者はあまり最適化されていないので使いづらい 127 | - DTLS-SRTPのほうがパフォーマンス的にも利点が多い 128 | 129 | ### 6.11. Best Effort Encryption 130 | 131 | - エンドポイント同士がベストエフォートでSRTPを使おうとする 132 | - 合致しない場合はRTPを使う 133 | - これもSDPでネゴシエーションする 134 | 135 | ## 7. Example Message Flow 136 | 137 | - AliceとBobがセッション確立しようとする例 138 | - 互いに自己証明書によるCertificateがある状態から 139 | 140 | ### 7.1. Basic Message Flow with Early Media and SIP Identity 141 | 142 | - AliceからBobへINVITEのオファー、Bobがアンサーを返すパターン 143 | - BtoA: ClientHello 144 | - AtoB: ServerHello, Certificate, ServerHelloDone 145 | - BtoA: Certificate, ClientKeyExchange, CertificateVerify 146 | - その後、ChangeCipherSpec 147 | - AtoB: ChangeCipherSpec 148 | 149 | ### 7.2. Basic Message Flow with Connected Identity (RFC 4916) 150 | 151 | - SIPのIdentityを使うパターン 152 | - RFC4916 153 | - WebRTCに関係ないので割愛 154 | 155 | ### 7.3. Basic Message Flow with STUN Check for NAT Case 156 | 157 | - NATを超える場合のパターン 158 | 159 | ## 8. Security Considerations 160 | 161 | - セキュリティに関して 162 | - SDPがセキュアにやり取りされてる前提に立つ 163 | - シグナリングプレーンに一任している 164 | 165 | ### 8.1. Responder Identity 166 | 167 | - SIPのUPDATEメッセージで自身とSDPが信頼できるものだと証明する 168 | - UPDATEが送信される前でもメディアは送信されるかも 169 | - その場合はMITMされるかも 170 | - 相互にやり取りできていないことが検知できればそれに気づける 171 | 172 | ### 8.2. SIPS 173 | 174 | - SIPではなくSIPSの場合 175 | - SIPのIdentityを使うパターンよりは弱い 176 | 177 | ### 8.3. S/MIME 178 | 179 | - S/MIMEはセキュア 180 | - RFC3261 181 | 182 | ### 8.4. Continuity of Authentication 183 | 184 | - 一度でもセッションを確立できればそれは安全なチャネルである 185 | - クレデンシャルをキャッシュしておけば、あとでまた使える 186 | 187 | ### 8.5. Short Authentication String 188 | 189 | - 略してSAS 190 | - 人の声を使ってFingerprintの検証ができる 191 | - 声を偽装することは難しいから 192 | - Fingerprintは最小64bit 193 | 194 | ### 8.6. Limits of Identity Assertions 195 | 196 | - Identity Assertionsの制約 197 | - RFC4474 198 | - ドメインを根拠にシグナリングの安全を保証するときの注意 199 | - WebRTCには関係ない 200 | 201 | ### 8.7. Third-Party Certificates 202 | 203 | - そもそも認証に関しては規定していない 204 | - 3rdパーティの機構を使ってもよい 205 | 206 | ### 8.8. Perfect Forward Secrecy 207 | 208 | - 鍵を長期的に使い回す場合の懸念 209 | - 過去の通信を侵害されるかも 210 | - それを防ぐためのPFSにDTLSは対応している 211 | -------------------------------------------------------------------------------- /summary/rfc5764.md: -------------------------------------------------------------------------------- 1 | > Read [original](https://tools.ietf.org/html/rfc5764) / [markdown](../markdown/rfc5764.md) 2 | 3 | --- 4 | 5 | # DTLS Extension to Establish Keys for the SRTP 6 | 7 | ## 1. Introduction 8 | 9 | - RTP/RTCPをセキュアに使うSRTP 10 | - ただそれ自体に鍵を管理する機能はない 11 | - その役目を担うのはDTLSが適してる 12 | - この仕様では、DTLSのSRTP拡張を定義する 13 | - DTLSのハンドシェイクでSRTPのための鍵交換やパラメータを決定する 14 | - 他の部分は従来のDTLSと同じ 15 | 16 | ## 2. Conventions Used In This Document 17 | 18 | - いつもの 19 | 20 | ## 3. Overview of DTLS-SRTP Operation 21 | 22 | - DTLS-SRTPは、1:1を想定している 23 | - その間に、1つのアソシエーションを張る（TLS用語ではコネクションという） 24 | - SRTPのコンテキストは、送信で1つ、受信で1つ 25 | - 単一のUDPソースに対応する 26 | - SDPなどを使って、DTLSの役割を分担して接続する 27 | - 接続できたら、鍵情報をSRTP側に渡す 28 | - その詳細はRFC5763にて 29 | - RTPとRTCPが多重化される場合は1つのアソシエーションでよい 30 | - 複数のポートになるなら、複数のアソシエーションが必要 31 | - 単純にテレビ電話を実装した場合 32 | - 動画と音声それぞれでDTLSをつなごうとするかも 33 | - 1つが確立するのを待って、相乗りしてもよい 34 | - クライアントが使う鍵と、サーバーが使う鍵は別のもの 35 | - そのチャンネルごとの鍵を使う 36 | 37 | ## 4. DTLS Extensions for SRTP Key Establishment 38 | 39 | - 本文なし 40 | 41 | ### 4.1. The use_srtp Extension 42 | 43 | - `use_srtp`という拡張を、DTLSの`ClientHello`で使う 44 | - RTP/RTCPを送るときしか使ってはいけない 45 | - `extension_data`では、SRTPのプロファイルのリストを含める 46 | - 同意する場合、`ServerHello`でその1つが選ばれて返される 47 | - DTLSのレコードレイヤーの`ApplicationData`では何も送受信しない 48 | - RTP/RTCPパケットは、SRTPスタックで処理される 49 | - つまりDTLSを確立するUDP上を流れる 50 | - DTLS-SRTPでは、1つ以上のコンテキストを確立する 51 | - それらはすべて同じプロファイルと、MKI（MasterKeyIdentifier）を持つ 52 | 53 | #### 4.1.1. use_srtp Extension Definition 54 | 55 | - `use_srtp`拡張の`extension_data`に何をいれるか 56 | - サポートする、使用したいプロファイル 57 | - `SRTPProtectionProfiles` 58 | - 降順にいれる 59 | - MKI 60 | - `srtp_mki` 61 | - `0`の場合は使われない 62 | - サーバー側は、`SRTPProtectionProfiles`で1つだけ返す 63 | - クライアントからの提示に使えるものがない場合、`use_srtp`自体返してはいけない 64 | - `Alert`を返してもよい 65 | 66 | #### 4.1.2. SRTP Protection Profiles 67 | 68 | - この仕様で定義するSRTPのプロファイルは以下 69 | - `SRTP_AES128_CM_HMAC_SHA1_80`: `0x00, 0x01` 70 | - WebRTC的にはコレ 71 | - `SRTP_AES128_CM_HMAC_SHA1_32`: `0x00, 0x02` 72 | - `SRTP_NULL_HMAC_SHA1_80`: `0x00, 0x05` 73 | - `SRTP_NULL_HMAC_SHA1_32`: `0x00, 0x06` 74 | - PRF(PseudoRandomFunction)はKDF(KeyDerivationFunction)のための鍵生成に使われる 75 | - KDR(KeyDerivationRate)は`0`なので、シーケンス番号を用いない 76 | - 新しいプロファイルがこの先定義される可能性はある 77 | 78 | #### 4.1.3. srtp_mki value 79 | 80 | - `srtp_mki`は、SRTP/SRTCPのMKIフィールドのために使われるかもしれない 81 | - そのパケットがどの鍵を使用したかを受信時にわかるように 82 | - TLSセッションの間でユニークな値がよい 83 | - サーバー側は、同じ`srtp_mki`値を返す 84 | - 空を返すことで、MKIを利用できないことを示せる 85 | - クライアントが渡したのと異なる値が帰ってきたら、ハンドシェイクは中止する 86 | 87 | ### 4.2. Key Derivation 88 | 89 | - SRTP拡張を使うとき、DTLSのレコードの暗号化と、SRTPのパケット暗号化には異なる鍵が使われる 90 | - 鍵はRFC5705で定義されるKeying Material Exportersに則って得られる 91 | - コンテキストはなし 92 | - ラベルは`EXTRACTOR-dtls_srtp` 93 | - 4つの値が得られる 94 | - 鍵/ソルト、read/writeの組み合わせ 95 | - これらを使って、SRTPの鍵を導出する 96 | - SRTPとSRTCPそれぞれに鍵が必要 97 | - 同一のトランスポートアドレスな場合は、どちらかの鍵を使えばよい 98 | 99 | ### 4.3. Key Scope 100 | 101 | - DTLS-SRTPの実装は、複数の鍵を保持していてもよい 102 | - パケットの順序が保証されないので 103 | 104 | ### 4.4. Key Usage Limitations 105 | 106 | - `maximum_lifetime`パラメータが、その鍵で保護できる最大パケット数を表す 107 | - その上限に達したら、新しいDTLSセッションを確立する 108 | - 上限に達したキーは、その後使ってはいけない 109 | 110 | ## 5. Use of RTP and RTCP over a DTLS-SRTP Channel 111 | 112 | - 本文なし 113 | 114 | ### 5.1. Data Protection 115 | 116 | - DTLSのハンドシェイクが完了すると、RTP/RTCPが送信できるようになる 117 | - それ以前ではもちろんSRTPを用意することもできない 118 | 119 | #### 5.1.1. Transmission 120 | 121 | - まずは送信について 122 | - DTLS-SRTPが有効な場合は、通常のDTLSとは異なり、SRTPによって暗号化される 123 | - SRTPパケットは、DTLSのレコードとしてではなく、単なるデータグラムとして送信される 124 | - DTLSではなくRTPのシーケンス番号が含まれる 125 | 126 | #### 5.1.2. Reception 127 | 128 | - 次に受信について 129 | - 受け取ったパケットの先頭1byteを見て判別する 130 | - 詳細はRFC7983 131 | 132 | ### 5.2. Rehandshake and Rekey 133 | 134 | - DTLSの鍵の再生成は、既存のDTLSチャンネル上で新しくハンドシェイクする 135 | - 既存のデータ転送と並列に行える 136 | - 切り替えのタイミングでは、古い鍵を使ったパケットが送受信されるかも 137 | - そのためにも、鍵の生存期間の間は、鍵を維持しておくべき 138 | - MKIを使う場合は、対応する鍵を使う必要がある 139 | 140 | ## 6. Multi-Party RTP Sessions 141 | 142 | - DTLSもDTLS-SRTPも、1:1のユニキャストを想定したプロトコル 143 | - ただしRTPミキサーで使えないわけではない 144 | - ただし、ミキサーが参加者とそれぞれのキーを使って、暗号・復号する 145 | - 昨今のSFUがやってるのがコレ 146 | 147 | ## 7. Security Considerations 148 | 149 | - セキュリティの懸念について 150 | 151 | ### 7.1. Security of Negotiation 152 | 153 | - bid-down攻撃について 154 | - より弱い暗号やプロファイルを使うよう仕向ける攻撃 155 | - ハンドシェイクはDTLS上で行われるため、検知できる 156 | 157 | ### 7.2. Framing Confusion 158 | 159 | - SRTPのパケットを、DTLSのハンドシェイクのパケットのように見せる攻撃 160 | - それぞれ異なるMACを使って検証するので、勘違いすることはない 161 | 162 | ### 7.3. Sequence Number Interactions 163 | 164 | - SRTPとDTLSは異なるシーケンス番号を管理する 165 | - これは`Alert`と再ハンドシェイクに関連する 166 | 167 | #### 7.3.1. Alerts 168 | 169 | - DTLSの`Alert`がSRTP層に作用してしまう実装について 170 | - `Alert`の再送攻撃に備えて、再送信かを確認する・破棄するなどが必要 171 | - そもそも本来のDTLSの`Alert`の使い方ではない 172 | 173 | #### 7.3.2. Renegotiation 174 | 175 | - MKIが使用されない場合、再ハンドシェイク時に複数の鍵が存在することになる 176 | - 対象が複数ある分だけ、認証の堅牢さは低くなる 177 | - ただしそれぞれが十分に堅牢なので問題はないはず 178 | 179 | ### 7.4. Decryption Cost 180 | 181 | - 適当なSRTPパケットを送りつけて復号させる攻撃について 182 | - SRTPの復号よりも、DTLS-SRTPを確立して攻撃する側のコストのほうが高い 183 | - 未知のSSRCは優先的に処理しないなど対策できる 184 | 185 | ## 8. Session Description for RTP/SAVP over DTLS 186 | 187 | - SDPの`m=`セクションの`proto`に新たなトークンを追加する 188 | - `RTP/SAVP` OR `RTP/SAVPF`を、DCCP（DatagramCongestionControlProtocol）で使う場合 189 | - `DCCP/TLS/RTP/SAVP` OR `DCCP/TLS/RTP/SAVPF`に 190 | - `RTP/SAVP` OR `RTP/SAVPF`の場合 191 | - `UDP/TLS/RTP/SAVP` OR `UDP/TLS/RTP/SAVPF`に 192 | - この仕様では、TCP上でRTPをセキュアに扱う方法については触れない 193 | 194 | ## 9. IANA Considerations 195 | 196 | - DTLS拡張に`use_srtp`を追加 197 | - TLSでは使えない 198 | - SDPの`proto`に`UDP/TLS/RTP/SAVP`や`UDP/TLS/RTP/SAVPF`を追加 199 | - TLSのExtractorLabelとして、`EXTRACTOR-dtls_srtp`を追加 200 | 201 | ## Appendix A. Overview of DTLS 202 | 203 | - DTLSについてのおさらい 204 | - UDPのためのTLSであり、基本はTLSと同じ 205 | - UDPで信頼性がないため、再送タイマーなどを使いながらハンドシェイクを行う 206 | - ハンドシェイクが終わると、`ApplicationData`が送信できるようになる 207 | - ただしDTLS-SRTPでは、これを使わず代わりにSRTPを別途送信する 208 | 209 | ## Appendix B. Performance of Multiple DTLS Handshakes 210 | 211 | - 異なるネットワークチャネルを、異なる接続とすることの利点について 212 | - セキュリティコンテキストの単純化と独立性の利点 213 | - ただしオーバーヘッドの懸念もある 214 | - セッション再開の仕組みを使えばRTTを減らせる 215 | - ただし帯域を消費することは避けられない 216 | -------------------------------------------------------------------------------- /summary/rfc5888.md: -------------------------------------------------------------------------------- 1 | > Read [original](https://tools.ietf.org/html/rfc5888) / [markdown](../markdown/rfc5888.md) 2 | 3 | --- 4 | 5 | # The SDP Grouping Framework 6 | 7 | ## 1. Introduction 8 | 9 | - SDPの`m=`行のグルーピングについて定義したRFCがあったがそれを刷新する 10 | - RFC3888 11 | - `m=`セクションが複数あった場合に、どう解釈すればいいかわからないから 12 | - それを決めたのがこれ 13 | 14 | ## 2. Terminology 15 | 16 | - いつもの 17 | 18 | ## 3. Overview of Operation 19 | 20 | - 各`m=`セクションは、`a=mid`というIDで識別される 21 | - そしてセッションレベルに`a=group`属性でもって、各`mid`の関連づけを行う 22 | - たとえば`LS: Lip Synchronization` 23 | 24 | ## 4. Media Stream Identification Attribute 25 | 26 | - メディアレベルの属性として`a=mid`属性を追加する 27 | 28 | ## 5. Group Attribute 29 | 30 | - セッションレベルの属性として`a=group`属性を追加する 31 | - 値としては`LS`と`FID`(Flow IDentification)の2つを追加 32 | 33 | ## 6. Use of "group" and "mid" 34 | 35 | - `a=mid`が現れないSDPでは、グルーピングは行わない 36 | - 存在しない`a=mid`を見ている`a=group`などは無効 37 | - `a=group`は複数あるかもしれない 38 | 39 | ## 7. Lip Synchronization (LS) 40 | 41 | - `a=group:LS`が指定される場合 42 | - それらで関連付けられたメディアは同期して再生される 43 | - RTPの場合、RTCPのタイムスタンプでそれは元からできたりする 44 | - ただしSDPはRTPのためのものではないので、それ以外の場合には有用 45 | 46 | ### 7.1. Example of LS 47 | 48 | - `a=group:LS`をしているSDPの例 49 | 50 | ## 8. Flow Identification (FID) 51 | 52 | - `m=`行はメディアストリームを表すが、メディアストリームとは具体的に何？ 53 | - RTSPの仕様にその答えがある 54 | - RFC2326 55 | - 単一のオーディオ、またはビデオのストリーム、またはホワイトボードなどの入力ソース 56 | - それらが単一のRTPセッションになる 57 | - しかし単一の入力ソースが複数のRTPセッションを構成することもある 58 | - SIPを使うセルラーのシステムや、DTMFを受信するシステム 59 | 60 | ### 8.1. SIP and Cellular Access 61 | 62 | - セルラーシステムはメディアをさまざまなコーデックで受け取る 63 | - そしてネットワークも安定していないことが多く、フォールバックが用意される 64 | - その場合は、単一の入力ソースで複数のRTPセッションを設けることになる 65 | 66 | ### 8.2. DTMF Tones 67 | 68 | - DTMFは、音声と別のホストやポートにつなげる 69 | - この場合も複数のRTPセッションが設けられる 70 | - 入力ソースという意味では単一ではあるものの 71 | 72 | ### 8.3. Media Flow Definition 73 | 74 | - 単一の入力ソースが単一のRTPセッションには必ずしもならないことがわかった 75 | - そんな複数のRTPセッションにはなるが、真に単一な入力ソースであることを表すために`FID`を使う 76 | - 単一の入力ソースが異なるポートに送信される場合に使う 77 | 78 | ### 8.4. FID Semantics 79 | 80 | - `FID`でマークされた`m=`に表されるメディアは必ず単一の入力ソースのコピーである 81 | - ただしエンコードに使われるコーデックは通常1つになるはず 82 | - その時、指定したコーデックが使われている`m=`でのみメディアは送信される 83 | - 合致しない場合、そのストリームでは何も送信されない 84 | 85 | #### 8.4.1. Examples of FID 86 | 87 | - `a=group:FID`を指定するSDPの例 88 | 89 | ### 8.5. Scenarios That FID Does Not Cover 90 | 91 | - `FID`の指定ができないケースについての補足 92 | 93 | #### 8.5.1. Parallel Encoding Using Different Codecs 94 | 95 | - 同じメディアでも、並列で異なるコーデックに変換して送ってる場合 96 | - DTMFを送りながらメディアも送れる場合 97 | 98 | #### 8.5.2. Layered Encoding 99 | 100 | - `c=`行でLayered Encodingが使用される場合 101 | - 階層別のメディアはもちろん同じ入力ソースではないので 102 | 103 | #### 8.5.3. Same IP Address and Port Number 104 | 105 | - 同じIP・ポートに複数のコーデック送るだけの場合 106 | - 従来のSDPの記述通り、単一の`m=`行にコーデックを複数書くこと 107 | 108 | ## 9. Usage of the "group" Attribute in SIP 109 | 110 | - SIPでの使われ方について 111 | 112 | ### 9.1. Mid Value in Answers 113 | 114 | - `mid`はオファーとアンサーで同じ値になる 115 | - `a=group`があっても、`m=`セクションの並び順は変えない 116 | - 今まで通りであるべき 117 | 118 | #### 9.1.1. Example 119 | 120 | - その場合のSDPの例 121 | 122 | ### 9.2. Group Value in Answers 123 | 124 | - `a=group`を解釈しない場合は、`a=group`を削除してアンサーを返す 125 | - `a=mid`は残す 126 | - オファーを拒否する場合に、`m=`行のポートを`0`にする 127 | - その場合、`a=group`にはその`m=`行の`mid`を含んではいけない 128 | 129 | #### 9.2.1. Example 130 | 131 | - その場合のSDPの例 132 | 133 | ### 9.3. Capability Negotiation 134 | 135 | - 実際には使わないが、サポートしていることを示したい場合 136 | - `a=group:LS`のように、値なしで含める 137 | - 複数書いてもいい 138 | 139 | #### 9.3.1. Example 140 | 141 | - その場合のSDPの例 142 | 143 | ### 9.4. Backward Compatibility 144 | 145 | - 後方互換性について 146 | - ただ無視されるだけ 147 | 148 | #### 9.4.1. Offerer Does Not Support "group" 149 | 150 | - オファー側が非対応の場合 151 | - オファーに含めないだけなので問題なし 152 | 153 | #### 9.4.2. Answerer Does Not Support "group" 154 | 155 | - アンサー側が非対応の場合 156 | - オファーに含まれるそれを無視する 157 | - `FID`も別々のポートに別々のものが届けられるだけ 158 | - 実装としてはオファーを拒否してもいい 159 | 160 | ## 10. Changes from RFC 3388 161 | 162 | - Section 3.を追記 163 | - 同じ`m=`セクションが複数のグルーピング対象になってもよい 164 | 165 | ## 11. Security Considerations 166 | 167 | - `FID`を指定したメディアは、各送信先に対して必ずコピーを送信する 168 | - つまりSDPが改ざんされて勝手にグルーピングされると、メディアが送られてしまうかも 169 | - なのでセキュアにSDPをやり取りすること 170 | 171 | ## 12. IANA Considerations 172 | 173 | - SDPのメディアレベルに`a=mid`属性を追加 174 | - SDPのセッションレベルに`a=group`属性を追加 175 | - 値として`FID`と`LS`を追加 176 | - 現時点では他にも`SRF`や`ANAT`や`FEC`や`DDP`などがある 177 | -------------------------------------------------------------------------------- /summary/rfc6347.md: -------------------------------------------------------------------------------- 1 | > Read [original](https://tools.ietf.org/html/rfc6347) / [markdown](../markdown/rfc6347.md) 2 | 3 | --- 4 | 5 | # Datagram Transport Layer Security Version 1.2 6 | 7 | ## 1. Introduction 8 | 9 | - インターネットでのセキュリティ担保の仕組みといえばTLS 10 | - TLSのいいところは、既存のプロトコルはそのままに、その上で展開できるところ 11 | - 最近使われることが多いUDPでも同様に使いたい 12 | - しかしそのままは使えない 13 | - そこでなんとか最小コストで使えるように、DTLSという仕様を定義する 14 | - DTLS 1.0はTLS1.1を使っていた 15 | - このDTLS 1.2は、TLS 1.2を使う 16 | 17 | ### 1.1. Requirements Terminology 18 | 19 | - いつもの 20 | 21 | ## 2. Usage Model 22 | 23 | - カーネルに手を入れることなく使える 24 | - UDPはそもそも信頼性なしで順不同である 25 | - DTLSを使ったからといってそこは変わらない 26 | - データ欠損や並び替えを補正しないので 27 | 28 | ## 3. Overview of DTLS 29 | 30 | - 基本的にはTLSをそのままUDP上で使うのがコンセプト 31 | - そのまま使えない理由は、パケットが欠けたり順序が変わったりするから 32 | - そこを補うことをDTLSではやっていく 33 | - 信頼性がないことでTLSが困ること 34 | - TLSはシーケンス番号を含めて完全性を検証するから 35 | - TLSはハンドシェイクでパケットが欠落する可能性を考慮していない 36 | 37 | ### 3.1. Loss-Insensitive Messaging 38 | 39 | - TLSのレコードレイヤーの各レコードは独立していない 40 | - ストリーム暗号のキーストリームが各レコードとの関係を保持するから 41 | - リプレイ耐性や並び替え耐性を担保するMACが、シーケンス番号を含むから 42 | - DTLSではこれを解消する 43 | - ストリーム暗号を使わない 44 | - それ用のシーケンス番号を別途用意する 45 | 46 | ### 3.2. Providing Reliability for Handshake 47 | 48 | - TLSのハンドシェイクは手順が決まってる 49 | - 順序が違うとエラー 50 | - 通常のUDPパケットより大きいパケットになるはず 51 | - 分割される可能性もある 52 | - それらを解決する必要がある 53 | 54 | #### 3.2.1. Packet Loss 55 | 56 | - パケロス対策として、再送用のタイマーを持つ 57 | - クライアント、サーバーのどちらの役割でも持つ 58 | - TODO: `HelloVerifyRequest`は再送しないって書いてあるけどほんと？ 59 | - そういうプロトコルの性質なのか 60 | - ただここの図の都合なのか 61 | 62 | #### 3.2.2. Reordering 63 | 64 | - ハンドシェイクの各メッセージには、それ用のシーケンス番号が割り当てられる 65 | - それで次のハンドシェイクのメッセージを期待するかどうかチェックする 66 | - 未来のが先に来てしまったら、キューに取っておく 67 | 68 | #### 3.2.3. Message Size 69 | 70 | - TLS、DTLSのハンドシェイクメッセージのパケットは大きくなりがち 71 | - 数KBとか 72 | - UDPはそもそも1500バイト以下になることが多いのに 73 | - 大きすぎる場合はパケットを分割する 74 | - オフセットとパケットの個数を見て、受信側が復号する 75 | 76 | ### 3.3. Replay Detection 77 | 78 | - リプレイ検出はオプショナルでサポート 79 | - IPsecのAH/ESPで使われるのと同様の手法を使う 80 | - 受信したレコードをマップに保持しておく 81 | - 重複したメッセージを破棄する 82 | - オプショナルなのは、よくあることだから 83 | 84 | ## 4. Differences from TLS 85 | 86 | - TLSとの違いについて 87 | - 何も言及していないところは、TLS 1.2と同様である 88 | 89 | ### 4.1. Record Layer 90 | 91 | - レコードレイヤーはTLS 1.2とほぼ同じ 92 | - `sequence_number`: TLS MACを証明するために増える 93 | - `version`: `254.253`でDTLS 1.2となる 94 | - `epoch`: `ChangeCipherSpec`の度にインクリメント 95 | - `sequence_number`は`epoch`ごとに管理される 96 | - 最初は`0`から 97 | - この2つから成るペアは、ユニークである必要がある 98 | - このペアが重複するレコードは存在してはならないということ 99 | - 新しい`epoch`でやり取りしているなら、古い`epoch`のパケットは捨てる 100 | - `Finished`メッセージがくるまでは、他のパケットの受信を待つ必要がある 101 | - 既にコンテキストが確立できているなら処理してもよい 102 | 103 | #### 4.1.1. Transport Layer Mapping 104 | 105 | - 1レコードは、1データグラムに収めて送る必要がある 106 | - PMTUの推定値にレコードのサイズを調整する 107 | - 複数レコードを1データグラムに含めることはできる 108 | 109 | ##### 4.1.1.1. PMTU Issues 110 | 111 | - PMTUのチェックはDTLSではやらないのが基本 112 | - しかし無視できるわけではない 113 | - 下層のPMTUの推定値が取得できるなら、それを上層に伝えるべき 114 | - 伝えるのも推定値でよい 115 | - ハンドシェイクメッセージを再送するときは、サイズを小さくして2-3回は再送を試みてもよい 116 | 117 | #### 4.1.2. Record Payload Protection 118 | 119 | - TLSと一緒で、一連の保護されたレコードとして送信する 120 | 121 | ##### 4.1.2.1. MAC 122 | 123 | - MACはTLS 1.2と同じ 124 | - ただし計算に使うのは、`epoch`と`sequence_number`を結合した64bitの値 125 | - これはTLSのシーケンス番号と同じ長さ 126 | - パラメータにバージョン番号を渡す 127 | - `254`と`253` 128 | - TLSと違って、MACのエラーで接続終了しなくてもよい 129 | - 各レコード間に依存がないから 130 | - DTLSでは、無効なレコードは黙って捨てる 131 | - エラーログは残しても良い 132 | - `Alert`を出す場合は、FATALな`bad_record_mac`を出して接続終了する 133 | 134 | ##### 4.1.2.2. Null or Standard Stream Cipher 135 | 136 | - NULL暗号はTLS 1.2と同様に動作する 137 | - TLS 1.2で使えるストリーム暗号であるRC4は、DTLSでは使用不可 138 | 139 | ##### 4.1.2.3. Block Cipher 140 | 141 | - ブロック暗号はTLS 1.2と同様に動作 142 | 143 | ##### 4.1.2.4. AEAD Ciphers 144 | 145 | - AEAD暗号スイートもTLS 1.2と同様に使用できる 146 | 147 | ##### 4.1.2.5. New Cipher Suites 148 | 149 | - 新たな暗号スイートが追加される際は、DTLSでも使用できるか検討されるだろう 150 | 151 | ##### 4.1.2.6. Anti-Replay 152 | 153 | - リプレイ攻撃への耐性として、シーケンス番号を含んでいる 154 | - セッション確立後、最初にやることとして、このカウンタを`0`で初期化する 155 | - 以後、受け取ったレコードのシーケンス番号が一意になるように管理する 156 | - 受信側は、スライディングウィンドウで重複をみつける 157 | - 詳細はRFC2406にて 158 | - サイズは`32`が最低限必要で、デフォルトの推奨値は`64` 159 | - 他の値でもよいし、送信側に通知しなくてよい 160 | - ウィンドウの右端は、最も大きなシーケンス番号 161 | - 左端のシーケンス番号より古いレコードは拒否される 162 | - 重複確認の処理には、ビットマスクを使うと効率的 163 | - MACの検証に成功したら、ウィンドウを更新する 164 | 165 | ##### 4.1.2.7. Handling Invalid Records 166 | 167 | - 不正なレコードは黙って捨てる 168 | - しかし接続は継続する 169 | - ログは記録してもよい 170 | - `Alert`を出す場合は、FATALにする必要がある 171 | - 攻撃者に実装を調査されないようにするため 172 | - ただし元からUDPは偽造しやすいので、DoSに弱くなりがちで推奨されない方針である 173 | 174 | ### 4.2. The DTLS Handshake Protocol 175 | 176 | - ハンドシェイクフローにおけるTLSとの違いは3つ 177 | - DoS対策として、ステートレスなCookieを交換する 178 | - データグラムの特性のため、ハンドシェイクメッセージのヘッダに変更がある 179 | - メッセージを再送するためのタイマーがある 180 | 181 | #### 4.2.1. Denial-of-Service Countermeasures 182 | 183 | - DoS対策について 184 | - `ClientHello`が送られてくると、`HelloVerifyRequest`をレスポンスする 185 | - このとき、ステートレスなCookieを含める 186 | - 0-255byte(以前のバージョンでは32byte) 187 | - そしてもう1度`ClientHello`をCookie付きで送り直す 188 | - そこからハンドシェイクが進む 189 | - このCookieのためのフィールドを、`ClientHello`に追加する 190 | - 最初はCookieを持たないので、空でよい 191 | - `HelloVerifyRequest`の`server_version`では、DTLS 1.0とする必要がある 192 | - ここではバージョンをネゴシエーションしない 193 | - DTLS 1.2を使用するとしても 194 | - `HelloVerifyRequest`にレスポンスするときは、`ClientHello`で使用したのと同じパラメータをつける 195 | - `version`, `random`, `session_id`, `cipher_suites`, `compression_method` 196 | - それをサーバー側でCookieにするし、検証する 197 | - `HelloVerifyRequest`のシーケンス番号は、`ClientHello`のシーケンス番号を使う 198 | - Cookieの生成コードの例 199 | - `hmac(secret, clientIP, clientParams)` 200 | - `secret`はIPごとに変える 201 | - 2度目の`ClientHello`を受け取ったら、CookieとIPでそれを検証できる 202 | - `ServerHello`のシーケンス番号には、`ClientHello`のシーケンス番号を使う 203 | - 新たなハンドシェイクでも、Cookieのやり取りは行うべき 204 | - ただし、サーバーはそれを選択してよい 205 | - クライアントはやり取りする準備が必要 206 | - `HelloVerifyRequest`を使用する場合、`ClientHello`と`HelloVerifyRequest`は、 207 | `CertificateVerify`メッセージの`handshake_messages`と 208 | `Finished`メッセージの`verify_data`の計算には使わない 209 | - サーバーは、不正なCookieを含む`ClientHello`メッセージを、Cookieを含まないものと同様に扱う 210 | 211 | #### 4.2.2. Handshake Message Format 212 | 213 | - UDPの特性に対応するために、ハンドシェイクのヘッダーにも修正がある 214 | - `message_seq`という`0`からはじまる値を使う 215 | - 新たなハンドシェイクメッセージを使うごとにインクリメントする 216 | - 再送するときは同じ値になる 217 | - DTLSのレコードとしての`sequence_number`は、インクリメントされたもの 218 | - 実装的には、`next_receive_seq`というカウンタを用意する 219 | - それと同じ値のメッセージを処理する 220 | - その値より小さいものは捨てる 221 | - その値より大きいものはキューにいれておくか、捨てる 222 | 223 | #### 4.2.3. Handshake Message Fragmentation and Reassembly 224 | 225 | - DTLSのメッセージは、単一のデータグラムに収める必要がある 226 | - しかしハンドシェイクメッセージは別で、断片化できるようになってる 227 | - 断片は同じ`message_seq`を持つ 228 | - `fragment_offset`: この断片より前に送られた断片の長さ 229 | - `fragment_length`: この断片の長さ 230 | - `length`: 元のレコードの長さのまま 231 | - 断片を受信したら、それはバッファして貯めておく 232 | - 断片の範囲は重複してるかもしれない 233 | 234 | #### 4.2.4. Timeout and Retransmission 235 | 236 | - ハンドシェイクで送信する一連のメッセージの塊をフライトと称して扱う 237 | - 以下はフルハンドシェイクの場合のフライトのリスト 238 | - CtoS: `ClientHello` 239 | - StoC: `HelloVerifyRequest` 240 | - CtoS: `ClientHello w/ Cookie` 241 | - StoC: `ServerHello` + `Certificate` + `ServerKeyExchange` + `CertificateRequest` + `ServerHelloDone` 242 | - CtoS: `Certificate` + `ClientKeyExchange` + `CertificateVerify` + `[ChangeCipherSpec]` + `Finished` 243 | - StoC: `[ChangeCipherSpec]` + `Finished` 244 | - DTLSのステートマシン 245 | - `PREPARING` 246 | - `SENDING` 247 | - `WAITING` 248 | - `FINISHED` 249 | - クライアントは`PREPARING`からはじまって、`ClientHello`を送信 250 | - すると`SENDING`から`WAITING`へ遷移 251 | - サーバーは`WAITING`からはじまる 252 | - `FINISHED`のとき、最後のフライトを送信するノード 253 | - 通常のハンドシェイクならサーバー、再開ならクライアント 254 | - TCPのデフォルトMSL（Maximum Segment Lifetime）の2倍の間、対向の最後のフライトにレスポンスを再送する 255 | - これでサーバーからの`Finished`メッセージがパケロスし、クライアントから`Finished`が再送されてきても対応できる 256 | - `epoch`ごとに`Finished`メッセージが両方で受信されるまで、アプリケーションのデータは処理されてはいけない 257 | - データは送られてくるかもしれないが、破棄するかバッファに貯めておくかする 258 | 259 | ##### 4.2.4.1. Timer Values 260 | 261 | - 再送タイマーについて 262 | - RFC6298では、TCPの再送タイマーの最小値は1s 263 | - デフォルトは3s 264 | - DTLSでは、1sからはじめて、再送するたびに2倍にしていき、最大で60s 265 | - タイマーの値は保持しておいて、ロスなしで転送できたらリセット 266 | - タイマーの値の10倍待ったときも、リセットしてよい 267 | 268 | #### 4.2.5. ChangeCipherSpec 269 | 270 | - `ChangeCipherSpec`はハンドシェイクではない 271 | - ただし、関連する`Finished`メッセージと同じフライトで扱われる 272 | 273 | #### 4.2.6. CertificateVerify and Finished Messages 274 | 275 | - `CertificateVerify`と`Finished`メッセージはTLSと同様 276 | - ハッシュの計算には、ハンドシェイクメッセージの全体を含む 277 | - `Finished`のMACは、ハンドシェイクメッセージすべてを単一の断片として計算する 278 | - Cookieが使われた場合、最初の`ClientHello`と`HelloVerifyRequest`はMACの計算に含まない 279 | 280 | #### 4.2.7. Alert Messages 281 | 282 | - `Alert`メッセージは再生されない 283 | - 不正なレコードを受け取ったなら、また送信する 284 | - 永続的に不正なレコードを送ってくると判断できたなら、接続を終了する 285 | 286 | #### 4.2.8. Establishing New Associations with Existing Parameters 287 | 288 | - 既に接続しているのに、同じアドレス、ポートで接続をやり直すこともできる 289 | - サーバー側は、`epoch`が`0`の新しい接続がきたように思う 290 | - その場合もハンドシェイクを続行してもよい 291 | - ただし、`Finished`をやり取りするまで、以前の接続は続ける必要がある 292 | - 2本同時に接続することはない 293 | 294 | ### 4.3. Summary of New Syntax 295 | 296 | - データ構造のおさらい 297 | 298 | #### 4.3.1. Record Layer 299 | 300 | - レコードレイヤーには、`epoch`と`sequence_number`が追加 301 | 302 | #### 4.3.2. Handshake Protocol 303 | 304 | - ハンドシェイクのタイプに、`HelloVerifyRequest`が追加 305 | - ハンドシェイクメッセージに、`message_seq`、`fragment_offset`、`fragment_length`が追加 306 | - `ClientHello`に`cookie`が追加 307 | 308 | ## 5. Security Considerations 309 | 310 | - 基本的にはTLS 1.2と同じセキュリティの懸念がある 311 | - DTLSはCookie交換の実装が必要 312 | - これが実装されてないと、DoSに対して脆弱 313 | - DoSの踏み台にもなる 314 | - TLSと違って、DTLSではセッションを終わらせようとする不正なレコードに対応してはいけない 315 | 316 | ## 6. Acknowledgments 317 | 318 | - いつもの 319 | 320 | ## 7. IANA Considerations 321 | 322 | - TLS 1.2と同じレジストリに登録する 323 | - TLSに適応されるパラメータは、DTLSでも使えるかどうかのフラグを持つ 324 | - `HelloVerifyRequest`という新しいハンドシェイクメッセージを追加 325 | 326 | ## 8. Changes since DTLS 1.0 327 | 328 | - DTLS 1.0からの変更について 329 | - TLS 1.2に対応 330 | - AEAD暗号スイートに対応 331 | - `epoch`と`sequence_number`について明文化 332 | - PMTUについて加筆 333 | - 不正なレコードへの対応について 334 | - Cookieが不正な値の場合について 335 | - ハンドシェイクのデッドロック回避について 336 | - `CertificateVerify`メッセージについて 337 | - `epoch`の更新について 338 | - IANAの要求と更新 339 | - `ClientHello`を再送する場合の`sequence_number`の扱いについて 340 | - `HelloVerifyRequest`での`version`指定について 341 | - その他てにおはを修正 342 | -------------------------------------------------------------------------------- /summary/rfc7064.md: -------------------------------------------------------------------------------- 1 | > Read [original](https://tools.ietf.org/html/rfc7064) / [markdown](../markdown/rfc7064.md) 2 | 3 | --- 4 | 5 | # URI Scheme for the Session Traversal Utilities for NAT (STUN) Protocol 6 | 7 | ## 1. Introduction 8 | 9 | - STUN関連のURIスキーマについての仕様 10 | - `stun`と`stuns`をSTUNサーバーをデプロイするときに使えるように 11 | 12 | ## 2. Terminology 13 | 14 | - いつもの 15 | 16 | ## 3. Definition of the "stun" or "stuns" URI 17 | 18 | - 本文なし 19 | 20 | ### 3.1. URI Scheme Syntax 21 | 22 | - `http`や他のスキーマと同じ 23 | - パースするときの注意も同じ 24 | 25 | ### 3.2. URI Scheme Semantics 26 | 27 | - スタンドアローンなSTUNサーバーを指すスキーマ 28 | - また、STUNサーバー的な振る舞いをするホストを指す 29 | - `stuns`は、TLS-over-TCP or DTLS-over-UDPでアクセスされる 30 | - `stun`はそれ以外 31 | - SRVルックアップの観点 32 | - `stun`: UDP 33 | - `stuns`: TCP 34 | - デフォルトポートは`3478` 35 | - STUN over TLSの場合は`5349` 36 | 37 | ## 4. Security Considerations 38 | 39 | - セキュリティ関連で特別なことはない 40 | - STUNでUSERNAMEやPASSWORDを送るが、それは平文 41 | - なので`stuns`といってもセキュアではないかもしれない 42 | - `stuns`を使うなら、ちゃんとセキュアな経路かどうかを事前に調べる必要がある 43 | - TLSのセッションを使うなど 44 | 45 | ## 5. IANA Considerations 46 | 47 | - NAT越えの用途以外には使わないように 48 | 49 | ### 5.1. "stun" URI Registration 50 | 51 | - `stun`を登録するよ 52 | 53 | ### 5.2. "stuns" URI Registration 54 | 55 | - `stuns`を登録するよ 56 | -------------------------------------------------------------------------------- /summary/rfc7478.md: -------------------------------------------------------------------------------- 1 | > Read [original](https://tools.ietf.org/html/rfc7478) / [markdown](../markdown/rfc7478.md) 2 | 3 | --- 4 | 5 | # Web Real-Time Communication Use Cases and Requirements 6 | 7 | ## 1. Introduction 8 | 9 | - WebRTCのユースケースを列挙したのがこの文章 10 | - FnやらAnは要件へのアンカーで、詳細は後述 11 | 12 | ## 2. Use Cases 13 | 14 | - 本文なし 15 | 16 | ### 2.1. Introduction 17 | 18 | - 以後ユースケースと要件 19 | - IPv4のみ、UDP使えないなど、様々なクライアントを想定せよ 20 | 21 | ### 2.2. Common Requirements 22 | 23 | - 基礎となるユースケースはSection2.3.1のビデオ通話 24 | - 他はすべてそれの拡張 25 | 26 | ## 2.3. Browser-to-Browser Use Cases 27 | 28 | - 本文なし 29 | 30 | ### 2.3.1. Simple Video Communication Service 31 | 32 | - 本文なし 33 | 34 | #### 2.3.1.1. Description 35 | 36 | - 基本的なビデオ通話の要件について 37 | - 自分のビデオを消したり追加したりできるとか 38 | - サービスは通話品質をチェックするとか 39 | 40 | #### 2.3.1.2. Common Requirements 41 | 42 | - ↑の内容の詳細 43 | - 各要件の番号とか載ってる 44 | 45 | 46 | ### 2.3.2. Simple Video Communication Service: NAT/Firewall That Blocks UDP 47 | 48 | - 本文なし 49 | 50 | #### 2.3.2.1. Description 51 | 52 | - ↑のと基本的に同じ 53 | - ただしUDPが使えない場合のこと 54 | 55 | #### 2.3.2.2. Additional Requirements 56 | 57 | - それでも通信できるようにすること 58 | 59 | ### 2.3.3. Simple Video Communication Service: Firewall That Only Allows Traffic via an HTTP Proxy 60 | 61 | - 本文なし 62 | 63 | #### 2.3.3.1. Description 64 | 65 | - またもSection2.3.1と同じ 66 | - ただしHTTPしか通さない場合 67 | 68 | #### 2.3.3.2. Additional Requirements 69 | 70 | - それでも通信できるようにすること 71 | 72 | #### 2.3.4. Simple Video Communication Service: Global Service Provider 73 | 74 | - 本文なし 75 | 76 | ##### 2.3.4.1. Description 77 | 78 | - またも基本的なビデオ通話と同じ 79 | - ただそれより物理的に遠い拠点を対象とする 80 | - なのでICE（STUN/TURN）をサポートする必要がある 81 | 82 | ##### 2.3.4.2. Additional Requirements 83 | 84 | - STUN/TURNサーバーを使えるようにせよ 85 | 86 | #### 2.3.5. Simple Video Communication Service: Enterprise Aspects 87 | 88 | - 本文なし 89 | 90 | ##### 2.3.5.1. Description 91 | 92 | - エンプラ利用のビデオ通話 93 | - それ用のTURNを用意しないといけないだろう 94 | 95 | ##### 2.3.5.2. Additional Requirements 96 | 97 | - 自分たちが管理しないSTUN/TURNサーバーも使えるようにせよ 98 | 99 | #### 2.3.6. Simple Video Communication Service: Access Change 100 | 101 | - 本文なし 102 | 103 | ##### 2.3.6.1. Description 104 | 105 | - これも基本のビデオ通話と同じ 106 | - 違うのは、エンドポイントのネット回線の種別が変わるケース 107 | - Ethernet / Wi-Fi / Cellularなど 108 | 109 | ##### 2.3.6.2. Additional Requirements 110 | 111 | - 回線種別が変わろうと利用できるようにせよ 112 | 113 | #### 2.3.7. Simple Video Communication Service: QoS 114 | 115 | - 本文なし 116 | 117 | ##### 2.3.7.1. Description 118 | 119 | - Section 2.3.6と同じ 120 | - QoSも意識すること 121 | 122 | ##### 2.3.7.2. Additional Requirements 123 | 124 | - なんらかのQoSによるメリットがある 125 | 126 | #### 2.3.8. Simple Video Communication Service with Screen Sharing 127 | 128 | - 本文なし 129 | 130 | ##### 2.3.8.1. Description 131 | 132 | - 基本のビデオ通話と同じ 133 | - それに加えての画面共有の要件 134 | 135 | ##### 2.3.8.2. Additional Requirements 136 | 137 | - 画面全体・一部など選んで共有できるように 138 | 139 | #### 2.3.9. Simple Video Communication Service with File Exchange 140 | 141 | - 本文なし 142 | 143 | ##### 2.3.9.1. Description 144 | 145 | - 基本のビデオ通話に加えて、ファイルの送受信ができること 146 | 147 | ##### 2.3.9.2. Additional Requirements 148 | 149 | - Reliableなデータ送信ができる 150 | 151 | #### 2.3.10. Hockey Game Viewer 152 | 153 | - 本文なし 154 | 155 | ##### 2.3.10.1. Description 156 | 157 | - ホッケーの試合をスカウトマンとマネージャーが一緒に見ながら通話する 158 | - 試合前は1:1のビデオ通話、試合中は試合の様子も配信する 159 | 160 | ##### 2.3.10.2. Additional Requirements 161 | 162 | - 複数のストリームを表示できるように 163 | 164 | #### 2.3.11. Multiparty Video Communication 165 | 166 | - 本文なし 167 | 168 | ##### 2.3.11.1. Description 169 | 170 | - 基本のビデオ通話だが、参加者が複数いるユースケース 171 | - ルームの概念 172 | - 音量を個別に調整できたり、話している人のビデオが表示されたり 173 | 174 | ##### 2.3.11.2. Additional Requirements 175 | 176 | - 複数のストリームを独立して調整・再生できるように 177 | 178 | #### 2.3.12. Multiparty Online Game with Voice Communication 179 | 180 | - 本文なし 181 | 182 | ##### 2.3.12.1. Description 183 | 184 | - オンラインゲームしながらボイチャ 185 | - ゲームの体験が最優先 186 | 187 | ##### 2.3.12.2. Additional Requirements 188 | 189 | - ゲーム音と通話音を合わせて再生できるように 190 | - UDPが送信できる 191 | 192 | ### 2.4. Browser - GW/Server Use Cases 193 | 194 | - 本文なし 195 | 196 | #### 2.4.1. Telephony Terminal 197 | 198 | - 本文なし 199 | 200 | ##### 2.4.1.1. Description 201 | 202 | - 電話窓口に電話ではなくブラウザからも問い合わせできる 203 | - ログインすれば電話がかけられて、受けられる 204 | 205 | ##### 2.4.1.2. Additional Requirements 206 | 207 | - 電話で使われてるオーディオコーデックが解釈できるように 208 | - SIPでセッションが確立できるように 209 | 210 | #### 2.4.2. FedEx Call 211 | 212 | - 本文なし 213 | 214 | ##### 2.4.2.1. Description 215 | 216 | - FedExの電話やり取りができる 217 | - 「xxxの人は1を押してください」みたいなやつ 218 | 219 | ##### 2.4.2.2. Additional Requirements 220 | 221 | - DTMFでのやり取りができるように 222 | 223 | #### 2.4.3. Video Conferencing System with Central Server 224 | 225 | - 本文なし 226 | 227 | ##### 2.4.3.1. Description 228 | 229 | - 中央サーバーを介してのビデオ会議 230 | - なのでN:NのいわゆるSFU 231 | 232 | ##### 2.4.3.2. Additional Requirements 233 | 234 | - 既知の要件のみ 235 | 236 | ## 3. Requirements Summary 237 | 238 | - 本文なし 239 | 240 | ### 3.1. General 241 | 242 | - 今まで解説したFnの詳細をまとめたよ 243 | 244 | ### 3.2. Browser Requirements 245 | 246 | - F1からF36まである要件の説明 247 | 248 | ## 4. Security Considerations 249 | 250 | - 本文なし 251 | 252 | ### 4.1. Introduction 253 | 254 | - 悪意のある人がDoS攻撃に使うかもしれない 255 | - TURNのクレデンシャル漏洩に備えていつでもrevokeできるようにしようなど 256 | - ユーザー認証なしでこっそりP2Pしちゃうとか 257 | 258 | ### 4.2. Browser Considerations 259 | 260 | - カメラやマイクの利用はユーザーに確認し、使用状況も出すし、いつでも止められる 261 | - ちゃんと確立できたセッションのストリームのみを表示する 262 | - セッション確立の過程がDoS攻撃みたいにならないようにする 263 | 264 | ### 4.3. Web Application Considerations 265 | 266 | - メディアの送受信がユーザーにわかるようにする 267 | 268 | ## 5. Normative References 269 | 270 | - ただの参照先へのリンク 271 | 272 | ## Appendix A. API Requirements 273 | 274 | - A1からA26まである要件の説明 275 | -------------------------------------------------------------------------------- /summary/rfc7675.md: -------------------------------------------------------------------------------- 1 | > Read [original](https://tools.ietf.org/html/rfc7675) / [markdown](../markdown/rfc7675.md) 2 | 3 | --- 4 | 5 | # Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness 6 | 7 | ## 1. Introduction 8 | 9 | - 実際のデータを送る前に、そのピアがトラフィックを受け付けているか知っておく必要がある 10 | - ICEの疎通確認のタイミングと、その後のタイミングで同意が必要 11 | - この仕様によって、ICEに特別な手順が増えるわけではない 12 | - Full実装でのみ必要 13 | - そもそもLiteは疎通確認を送ったりせずレスポンスするだけなので 14 | 15 | ## 2. Applicability 16 | 17 | - non-ICEなパケットを送る前に同意を得るべきという文書 18 | - ICEを使ってる仕組みには適用できる 19 | 20 | ## 3. Terminology 21 | 22 | - いつもの 23 | 24 | ## 4. Design Considerations 25 | 26 | - ICEにはもともとキープアライブの仕様がある 27 | - STUNのバインディングインディケーションを送る 28 | - レスポンスは返ってこない 29 | - 同意にはレスポンスが必要 30 | - なので代わりにバインディングリクエストを送ることで、キープアライブも満たす 31 | - SRTPの場合 32 | - お互いにキーを知ってて認証されてるので、同意は得られていると思いがち 33 | - しかし3人以上が相互にやり取りしてる場合は、3人目が偽装するかも 34 | - なので、これによって同意を満たすことはできない 35 | 36 | ## 5. Solution 37 | 38 | - canidateペアがSucceededになったら、同意を得ることを開始する 39 | - `30s`に1度、同意を得るようにする 40 | - やめるタイミングは次に解説する 41 | 42 | ### 5.1. Expiration of Consent 43 | 44 | - selectedな経路に大して同意を得るようにする 45 | - 同意が得られるまでは、疎通確認のパケット以外は送ってはいけない 46 | - 実際のデータ（RTPとかDTLSとかのこと） 47 | - STUNのshort-term認証でバインディングリクエストを送ることで同意を得る 48 | - 毎回あたらしいTransactionIDを発行する 49 | - 同意を得るためのリクエストは、`5s`のインターバルをデフォルト 50 | - 0.8から1.2倍つまり`4s`から`6s`の間でランダムな間隔で送る必要がある 51 | - `4s`より小さくなってはいけない 52 | - 同意は`30s`で期限が切れる 53 | - 期限切れ = 同意を失う = データが送信できなくなる 54 | - 再送信にはICEリスタートが必要 55 | - 送信する前に、レスポンスを待つべき 56 | - これはSTUNのRTTに従う 57 | 58 | ### 5.2. Immediate Revocation of Consent 59 | 60 | - タイムアウトを待つよりも明示的に終わることもある 61 | - TLSのfatalアラートや、STUNのエラーレスポンスなど 62 | - SRTCPのBYEは関係ない 63 | - ただ単にパケロスもありえるので、タイムアウトを待つのが正解 64 | 65 | ## 6. DiffServ Treatment for Consent 66 | 67 | - ICEの疎通確認と同じDiffServの処理をされるべき 68 | 69 | ## 7. DTLS Applicability 70 | 71 | - DTLSとの兼ね合いは、RFC7350のSection 4.2にて 72 | 73 | ## 8. Security Considerations 74 | 75 | - STUNのTransactionIDは、あれで十分な長さ 76 | -------------------------------------------------------------------------------- /summary/rfc7742.md: -------------------------------------------------------------------------------- 1 | > Read [original](https://tools.ietf.org/html/rfc7742) / [markdown](../markdown/rfc7742.md) 2 | 3 | --- 4 | 5 | # WebRTC Video Processing and Codec Requirements 6 | 7 | ## 1. Introduction 8 | 9 | - WebRTCのコア機能は映像を送受信できること 10 | - カメラでもスクリーンシェアでも、どんな映像でも送れる 11 | - そのためのコーデックやパラメータについて解説する 12 | 13 | ## 2. Terminology 14 | 15 | - いつもの 16 | 17 | ## 3. Pre- and Post-Processing 18 | 19 | - 映像のストリームの前後の処理について 20 | 21 | ### 3.1. Camera-Source Video 22 | 23 | - 以下の要素はオートで調整されるとよい 24 | - フォーカス 25 | - ホワイトバランス 26 | - 明るさ 27 | - フレームレート 28 | - 必須な要件ではなく、よりWebRTCの特性にあってるだけ 29 | 30 | ### 3.2. Screen-Source Video 31 | 32 | - 画面を共有する場合 33 | - 解像度の変更に追従する必要がある 34 | - その他、セキュリティにも注意 35 | 36 | ## 4. Stream Orientation 37 | 38 | - モバイル端末など、カメラがローテーションできる場合 39 | - エンコーダーの期待する向きと異なるかも 40 | - 受信者側が向きを変更する必要があるかも 41 | - その可能性があるエンドポイントは、CVOのサポートが必要 42 | - Coordination of Video Orientation 43 | - `R0`や`R1`のビットを送信する 44 | - そのほか一部のコーデックは、in-bandで通知できる 45 | - H.264/H.265の`SEI`の`Display Orientation` 46 | 47 | 48 | ## 5. Mandatory-to-Implement Video Codec 49 | 50 | - WebRTCの実装は、VP8とH.264をサポートする必要がある 51 | - それ以外のコーデックを使うこともできるが、この2つのどちらかだけでも実装しておくのが推奨 52 | 53 | ## 6. Codec-Specific Considerations 54 | 55 | - SDPの`a=imageattr`属性で、最大解像度を指定できる 56 | - 送信側が受信側のためにこの属性を尊重する必要がある 57 | - そのほかフレームレートやビットレートに対してもサポートできる最大値を通知するかも 58 | - 最低でも320x240pxの解像度と20fpsをデコードできる必要がある 59 | - 送信側も受信側もどちらも 60 | 61 | ### 6.1. VP8 62 | 63 | - サポートすべき実装 64 | - RFC6386 65 | - RFC7741 66 | - RFC6236 67 | - `a=max-fr`や`a=max-fs`にも対応するように 68 | - ピクセルのアスペクト比は、1:1でエンコード・デコードされる前提になってる 69 | 70 | ### 6.2. H.264 71 | 72 | - サポートすべき実装 73 | - RFC6184 74 | - サポートすべきプロファイル 75 | - Constrained Baseline Profile Level 1.2 76 | - Constrained High Profile Level 1.3 77 | - よく使われるオプション 78 | - `packetization-mode`: `1`は必須、他はシグナリングされれば 79 | - `profile-level-id`: SDPでシグナリングする 80 | - `max-mbps`, `max-smbps`, `max-fs`, `max-cpb`, `max-dpb`, `max-br`: シグナリングされれば`profile-level-id`より優先 81 | - `sprop-parameter-sets`: in-bandで調整するので、SDPには含めない 82 | - そのほか`SEI`の、`Filler Payload`と`Full Frame Freeze`のサポートが必要 83 | - `User data registered by Rec`や`User data unregistered`なども受信するかも 84 | - それらを受け取っても影響のない実装にしておく必要がある 85 | - ピクセルのアスペクト比は、1:1でエンコード・デコードされる前提になってる 86 | 87 | ## 7. Security Considerations 88 | 89 | - 新たなセキュリティの懸念などはない 90 | - DTLS-SRTPの注意などを参照 91 | - 特に可変ビットレートの問題など 92 | - H.264の`SEI`メッセージの扱いにも注意 93 | - RFC6184 94 | -------------------------------------------------------------------------------- /summary/rfc7874.md: -------------------------------------------------------------------------------- 1 | > Read [original](https://tools.ietf.org/html/rfc7874) / [markdown](../markdown/rfc7874.md) 2 | 3 | --- 4 | 5 | # WebRTC Audio Codec and Processing Requirements 6 | 7 | ## 1. Introduction 8 | 9 | - WebRTCエンドポイントの音声に関する決まりについて 10 | 11 | ## 2. Terminology 12 | 13 | - いつもの 14 | 15 | ## 3. Codec Requirements 16 | 17 | - WebRTCエンドポイントは下記の要件を満たすこととする 18 | - できる限り対応しておくと、トランスコードが不要になるのでよい 19 | - OPUS 20 | - RFC6716 21 | - RFC7587 22 | - PCMA/PCMU, G.711 23 | - RFC3551 24 | - Comfort Noise(CN) 25 | - RFC3389 26 | - 使用するコーデックが独自のCNを実装していない場合に 27 | - DTX/CNの送信時の利用はオプショナル 28 | - `audio/telephone-event` 29 | - RFC4733 30 | - DTMF 31 | - その他の情報については 32 | - RFC7875 33 | 34 | ## 4. Audio Level 35 | 36 | - 音量について 37 | - ユーザーが手動で調整しなくてもよいように、標準化されると望ましい 38 | - G.169とG.115に従って、`-19dBm0`に収まるようにするとよい 39 | - しかしG.712など、その範囲外の8-48 kHz以上のサンプリングレートを使用できる 40 | - なので`300Hz`以上について調整し、`-19dBm0`に収めるようにするのがよい 41 | - +/-32767のレンジの16bitのPCM音源を想定すると、そのRMS(Root Mean Square)は`2600`になる 42 | - なのでその範囲に調整することを推奨 43 | - ただアプリケーションによっては、ユーザーが手動で音量を調整できるようにすべき 44 | - 推奨されるフィルターの実装は、二次バターワースフィルタ 45 | - `300Hz`でカットオフ 46 | 47 | ## 5. Acoustic Echo Cancellation (AEC) 48 | 49 | - WebRTCのメインターゲットは、映像と音声による双方向の通話 50 | - それもノートPCでカメラとマイクとスピーカーがセットになったデバイス 51 | - なのでエコーキャンセラーが重要になってくる 52 | - 一方でそのアルゴリズムや仕組みに規定はしていない 53 | - AEC(Acoustic Echo Cancellation)などの仕組みはあるとよい 54 | - 一般的なノートPCだと、ADC/DACはそれぞれ異なるクロックを使用する 55 | - それを考慮したAECでないといけない 56 | - AECやNLPなどは、設定可能でないといけない 57 | - 音楽を流すときなどは不要なため 58 | - 送信側で対応していない場合に、受信側でキャンセルすることも考えられる 59 | - ただしデフォルトでは無効化されてるべき 60 | 61 | ## 6. Legacy VoIP Interoperability 62 | 63 | - ここに書かれた要件を満たすことで、WebRTCエンドポイントはサポートできる 64 | - G.711だけをサポートするレガシーなエンドポイントもサポートできる 65 | 66 | ## 7. Security Considerations 67 | 68 | - コーデックに関する注意点は、それぞれの仕様を参照 69 | - その他は基本的なWebRTCのセキュリティ事項を参照 70 | -------------------------------------------------------------------------------- /summary/rfc7983.md: -------------------------------------------------------------------------------- 1 | > Read [original](https://tools.ietf.org/html/rfc7983) / [markdown](../markdown/rfc7983.md) 2 | 3 | --- 4 | 5 | # Multiplexing Scheme Updates for SRTP Extension for DTLS 6 | 7 | ## 1. Introduction 8 | 9 | - RFC5764で、SRTPとDTLSとSTUNが多重化されるようになった 10 | - しかし単一ポートに様々なパケットが送られることによって暗黙的に発生しうる問題もある 11 | - IANAに登録のないSTUNメソッドやTLSのタイプ 12 | - ZRTPとの兼ね合い 13 | - TURNとの兼ね合い 14 | - 新たな仕様で定義されると困る値を、先に使ってしまうかもしれない可能性もある 15 | - この文書でもって今を明らかにし、今後のためにまとめておく 16 | 17 | ## 2. Terminology 18 | 19 | - いつもの 20 | 21 | ## 3. Implicit Allocation of Codepoints for New STUN Methods 22 | 23 | - RFC5764によると、先頭1byteでどのパケットか識別する 24 | - `0`か`1`ならSTUN 25 | - ただこの暗黙の判定のために、RFC5389で本来STUNに割り当てられている範囲が使えない 26 | - STUNメソッドには、`0x000`から`0x7ff`までが割当られてる 27 | - `0x800`から`0xfff`まではDesignated Expert向け 28 | - しかし実際は、`0x000`から`0x07f`までになってしまう 29 | - Designated Expertの範囲を維持するために、この文書で`0`から`3`までをSTUNと識別するようにする 30 | - そしてSTUNの割当を次のように変更する 31 | - `0x000`から`0x07f`: IETF 32 | - `0x080`から`0x0ff`: Designated Expert用 33 | - `0x100`から`0xfff`: Reserved 34 | 35 | ## 4. Multiplexing of ZRTP 36 | 37 | - ZRTPのために、`16`から`19`までを割り当てておく 38 | 39 | ## 5. Implicit Allocation of New Codepoints for TLS ContentTypes 40 | 41 | - `20`から`63`は、DTLSと識別される 42 | - この先頭1byteはTLSの`ContentType`フィールドである 43 | - よって`0`から`19`と、`64`から`255`に意味をもたせる場合は注意 44 | - 多重化という視点からすると問題はない 45 | - TLSのContentType Registryで要注意とマークされるようになった 46 | 47 | ## 6. Multiplexing of TURN Channels 48 | 49 | - ICEを使ってる場合は、次の3つからパケットが送られてくることになる 50 | - 送信元から直接 51 | - NATを介して 52 | - TURN経由で 53 | - TURNのChannelは、4byteのヘッダーを使う 54 | - RFC5764ではこれに触れていない 55 | - `64`から`127`が先頭の1byteになる 56 | - この仕様では、`64`から`79`までの値を割り当てる 57 | 58 | ## 7. Updates to RFC 5764 59 | 60 | - RFC5764に対する修正のまとめ 61 | - 先頭の1byteで識別することは変わらず 62 | - `0`から`3`: STUN 63 | - `16`から`19`: ZRTP 64 | - `20`から`63`: DTLS 65 | - `64`から`79`: TURN Channel 66 | - `128`から`191`: RTP/RTCP 67 | 68 | ## 8. Security Considerations 69 | 70 | - TURN Channelのために新たなレンジを追加 71 | 72 | ## 9. IANA Considerations 73 | 74 | - 本文なし 75 | 76 | ### 9.1. STUN Methods 77 | 78 | - STUNメソッドのレジストリの変更 79 | - 上述の通り 80 | 81 | ### 9.2. TLS ContentType 82 | 83 | - TLS ContentTypeのレジストリの変更 84 | - 上述の通り 85 | 86 | ### 9.3. Traversal Using Relays around NAT (TURN) Channel Numbers 87 | 88 | - TURN Channel Numbersのレジストリへの追加 89 | - `0x5000`から`0xffff`: Reserved 90 | -------------------------------------------------------------------------------- /summary/rfc8122.md: -------------------------------------------------------------------------------- 1 | > Read [original](https://tools.ietf.org/html/rfc8122) / [markdown](../markdown/rfc8122.md) 2 | 3 | --- 4 | 5 | # Connection-Oriented Media Transport over the TLS Protocol in the SDP 6 | 7 | ## 1. Introduction 8 | 9 | - RFC4145でTCPにしか触れてなかった 10 | - でも実際はセキュアにメディア転送したいはず 11 | - なので今回TLSを使用できる拡張を行う 12 | - 自己証明書でFingerprintを生成し、それをSDPに載せる 13 | 14 | ### 1.1. Changes from RFC 4572 15 | 16 | - RFC4572からのアップデート 17 | - 後方互換性は保ちつつ 18 | - 複数のFingerprintをマッチングするロジックを明示する 19 | - より強力な暗号スイートを使うように更新など 20 | 21 | ## 2. Terminology 22 | 23 | - いつもの 24 | 25 | ## 3. Overview 26 | 27 | - なぜTLSを使う必要があるのかについて 28 | 29 | ### 3.1. SDP Operational Modes 30 | 31 | - SDPの用途 32 | - SAP: セッションの告知 33 | - オファー・アンサー: 示し合わせて交換 34 | 35 | ### 3.2. Threat Model 36 | 37 | - どんな脅威が考えられるか 38 | - セッションの傍受 39 | - なりすまし 40 | - アンサーを代わりに返しちゃうかも 41 | - これらはTLSで防ぐことができる 42 | 43 | ### 3.3. The Need for Self-Signed Certificates 44 | 45 | - SDPを作成するエンドポイントのIPは不定 46 | - だいたいが動的にIPやホスト名を決定する 47 | - そうなると自己証明書しかない 48 | - 自己証明書でSDPの記述の整合性を保証する 49 | - 自己証明書のFingerprintをSDPの属性につける 50 | 51 | ### 3.4. Example SDP Description for TLS Connection 52 | 53 | - SDPにFingerprintを載せる例 54 | - `a=fingerprint`属性を`m=`セクションごとに 55 | 56 | ## 4. Protocol Identifiers 57 | 58 | - `m=`行のプロトコルに`TCP/TLS`を使う 59 | - そのほか`a=setup`と`a=connection`も 60 | - WebRTCでは`a=setup`だけ 61 | 62 | ## 5. Fingerprint Attribute 63 | 64 | - 認証にはX.509証明書を使う 65 | - 自身が提示したFingerprintでTLSのハンドシェイクされることを期待する 66 | - `a=fingerprint`行でそれを示す 67 | - ハッシュ関数の名前とそのハッシュ値を記述する 68 | - `a=fingerprint:sha-256 92:BB:7F:59:47:FD:21:4D:D2:...` 69 | - MD2とMD5をハッシュ関数に使ってはいけない 70 | - この属性は、セッションレベルでもいいし、メディアレベルでもいい 71 | - セッションレベルにある場合は、すべてのメディアレベルで共通になる 72 | 73 | ### 5.1. Multiple Fingerprints 74 | 75 | - 複数の`a=fingerprint`属性を、単一の`m=`セクションに紐付けられる 76 | - その場合は、SHA-256と任意のアルゴリズムにする 77 | - WebRTCではそうならない 78 | 79 | ## 6. Endpoint Identification 80 | 81 | - 本文なし 82 | 83 | ### 6.1. Certificate Choice 84 | 85 | - 証明書の用意について 86 | - `c=`行にあるIPに一致する証明書にしてもよい 87 | - ただしワイルドカードパターンはだめ 88 | - セキュリティの懸念はSection7.にて 89 | 90 | ### 6.2. Certificate Presentation 91 | 92 | - TLSのハンドシェイクでFingerprintが不一致の場合 93 | - `bad_certificate`エラーで終了する 94 | - オファー・アンサーでは、`a=setup:active`の側が証明書を提示する 95 | - クライアントが提示しない場合も、`bad_certificate`エラーで終了する 96 | - `a=setup:passive`または`a=setup:actpass`の場合は、オファー送信後すぐに接続を開始する 97 | - ただしFingerprintを照合できるまではそのデータを信頼してはいけない 98 | 99 | ## 7. Security Considerations 100 | 101 | - SDP自体をセキュアに転送する必要がある 102 | - 保護されていないチャネルでSDPを受け取る場合は、ユーザーに警告が必要かも 103 | - TLSより安全な選択肢もあるかもしれない 104 | 105 | ## 8. IANA Considerations 106 | 107 | - SDPの`proto`として`TCP/TLS`を追加 108 | - メディアレベルの属性に`fingerprint`を追加 109 | -------------------------------------------------------------------------------- /summary/rfc8421.md: -------------------------------------------------------------------------------- 1 | > Read [original](https://tools.ietf.org/html/rfc8421) / [markdown](../markdown/rfc8421.md) 2 | 3 | --- 4 | 5 | # Guidelines for Multihomed and IPv4/IPv6 Dual-Stack Interactive Connectivity Establishment (ICE) 6 | 7 | ## 1. Introduction 8 | 9 | - IPv4とIPv6に両対応してれば、ICEの接続はよりうまくいく 10 | - より早くつながる 11 | - より安定する 12 | - IPv4よりもIPv6を優先するRFCもある 13 | - RFC6724 14 | - これによってICEの手順が変わったりはしない 15 | 16 | ## 2. Notational Conventions 17 | 18 | - いつもの 19 | 20 | ## 3. ICE Multihomed Recommendations 21 | 22 | - インターフェースによって、性質が異なるはず 23 | - 優先・無線・セルラー・仮想など 24 | - それを知った上で、信頼できる順に優先度を上げるべき 25 | - そういった事前情報がない場合は、どれも信頼できると過程する 26 | 27 | ## 4. ICE Dual-Stack Recommendations 28 | 29 | - アドレスファミリーを公平に混在させるためにどうするか 30 | - candidateの優先度の計算に使うtype prefを適切に設定するとよい 31 | - つまりIPv6のほうが優先度が高くなるように 32 | - `(N_4 + N_6) / N_4`番目までv6、v4、またv6というように並べる 33 | - 2つのIPv4と6つのIPv6のアドレスがある場合は、 34 | - [v6, v6, v6, v6, v4, v4, v6, v6] 35 | 36 | ## 5. Compatibility 37 | 38 | - ICEの優先度の計算式があった 39 | - `(2^24) * (type preference) + (2^8) * (local preference) + (2^0) * (256 - component ID)` 40 | - このlocal prefの値を動的に計算する 41 | - ただしこの計算式で！というものはない 42 | - 指標としては 43 | - IPv6とIPv4がバランスよく 44 | - 信頼できるインターフェースが上位 45 | - 信頼できないとわかっているインターフェースは最後に回す 46 | 47 | ## 6. IANA Considerations 48 | 49 | - IANA関係なし 50 | 51 | ## 7. Security Considerations 52 | 53 | - 優先度による並べ替えによって、リモートへインターフェースの情報が漏洩するかも 54 | --------------------------------------------------------------------------------