Skip to content

Latest commit

 

History

History
136 lines (96 loc) · 5.18 KB

draft-ietf-mmusic-msid-17.md

File metadata and controls

136 lines (96 loc) · 5.18 KB
Raw

Read original / markdown

WebRTC MediaStream Identification in the Session Description Protocol

1. Introduction

  • 本文なし

1.1. Terminology

  • いつもの

1.2. Structure Of This Document

  • RTPストリームにIDを振る、グルーピングするための仕様をSDPに追加する
  • WebRTCのための拡張である

1.3. Why A New Mechanism Is Needed

  • なぜ拡張が必要だったのか
  • RTPセッション中のRTPストリームは、SSRCによって一意に識別できた
    • そもそもRTPセッションは、トランスポートアドレスで別れているものだった
  • しかしWebRTCではBUNDLEすることができてしまう
    • SDPグルーピングについては、RFC5888
  • しかしそれはSDP内に閉じた話で、アプリケーションレベルでこれを知る必要が往々にしてある
    • そのためにこの拡張が必要

1.4. The WEBRTC MediaStream

  • WebRTCではメディアをMediaStreamとして扱い、MediaStreamTrackを含む
  • MediaStreamTrackは、RTPセッション中の単一のSSRCを表すもの
    • サイマルキャストなど、このSSRCが増えることもあるがそれはこの仕様と関係ない
    • そしてこれは一方通行なもの
  • RTPセッションでは、RTPストリームはSSRCで識別されつつ、CNAMEの情報を持ってる
  • しかしこのCNAMEもRTPセッションも、MediaStreamとは対応していない
  • SDPにおけるm=セクションは、それぞれがMediaStreamTrackと対応する
    • そしてBUNDLEされると、いくつかのMediaStreamTrackがRTPセッションとなる
    • そこで、どのMediaStreamにMediaStreamTrackが属するかの情報が必要になる

2. The Msid Mechanism

  • msid属性をSDPのメディアレベルに追加する
    • a=msid:{id} {appdata}
  • msid:examplefoo examplebar
    • この場合はexamplefooというIDに、examplebarという値

3. Procedures

  • msidはどう決まるのか
    • MediaStreamのidが、{id}に紐づく
    • MediaStreamTrackのidが、{appdata}に紐づく
  • msidの{id}が新たに増えた = 新たなMediaStreamを受信したとわかる
    • {appdata}が新たに増えた = 新たなMediaStreamTrack
  • {appdata}がなく{id}だけ増えるパターンもある
    • その場合は受信側が自分で割り当てる
  • {id}が-の場合は、MediaStreamがないことを表す
  • MediaStreamTrackの終了条件
    • a=msidが消えた時
    • すべてのSSRCでBYEパケットを受信したとき
    • タイムアウトしたとき
    • m=行のポートに0が指定されたとき

3.1. Handling of non-signalled tracks

  • msidを使用しない、紐付けないRTPパケットが送信されてくることもある
    • 既にセッションがあるときに、後からMediaStreamTrackを追加した場合
    • 再ネゴシエーションが発生して、アンサーが受領されるまでの間
    • = RTCSignalingStateがstableでない間

3.2. Detailed Offer/Answer Procedures

  • オファー・アンサーについては別の仕様に詳細がある
    • RFC3264

3.2.1. Generating the initial offer

  • オファーのSDPにa=msidが載るまで
  • 送信したいMediaStreamの数だけ定義する
    • idをmsidの{id}に
  • 次いで、MediaStreamTrackのidを{appdata}に

3.2.2. Answerer processing of the Offer

  • アンサー側がどうするか
  • {appdata}でもってMediaStreamTrackのインスタンスを探す or 作る
  • {id}を使ってMediaStreamを探す or 作る
  • ユーザーに知らせる

3.2.3. Generating the answer

  • アンサーを発行するときは、オファーを発行するときと同じ
  • オファー側が影響を与えることはない

3.2.4. Offerer processing of the answer

  • 同上

3.2.5. Modifying the session

  • セッション中の再ネゴシエーションで注意点が1つだけある
  • endedになっていないMediaStreamTrackについて
    • SDPにそのidが{appdata}と同じものが存在するかチェック
    • 存在しなくなってたら、endedにしてしまう

3.3. Example SDP description

  • 2つのMediaStreamを送る場合のSDPの例

4. IANA Considerations

  • 本文なし

4.1. Attribute registration in existing registries

  • msid属性をSDPのatt-fieldに追加する
    • これはメディアレベル限定

5. Security Considerations

  • SDPを改ざんされるおそれはある
    • そうなるとバッファリング実装のメモリを枯渇させることができるかも
  • IDを生成するときも、UUIDのv3や4を使うなど推奨

Appendix A. Design considerations, rejected alternatives

  • 代案について
  • CNAMEを使う案
    • CNAMEはMediaStreamTrackをsyncするためのもの
  • RTCPのSRパケットを使う案
    • 全てのMediaStreamTrackの状況を把握できない
  • a=wms-semanticという属性もあった
    • 2015年4月に削除された
    • 実際にはa=msid-semantic:WMSから続く行
      • 今もChromeやFirefoxがSDPに載せてくる