WebRTC においてP2PとSFUでビデオ品質の差があるかと言われればある。どちらが良いかといえば1:1なのであればP2Pが原則的には良くなると僕は考える。それはなぜか。 第一にWebRTC は相手に届くことを優先した制御を行っている。相手との通信状況が悪ければ解像度を落とす。映像が止まってしまった場合は通信相手に再生を再開するためのフレームをもらう。もし音声が途切れてしまうようであれば遅延を許容し少し溜め込んでから流すことで途切れないようにする。常に相手のことを気にして自分の処理能力も気にしつつ届くように映像を送る。これがWebRTCにおいて非常に優れた点だと僕は考えている。 映像音声通信の裏側で行われるやり取り 学習に例えるならば、相手が小学生相当ならば小学生用の教科書を高校生相当であれば高校生用の教科書を作って送っているのである。もちろん、状況に合わせて送るものは常に変えている。小
WebRTC を利用して 4K@30 配信をしたいというのは一定の需要があるようです。超低遅延で超高画質は確かに夢があります。 ただ現時点では、かなり限定された環境でしか配信することはできません。 ここでの 4K における画質の定義ですがコーデックが H.264 、解像度が 2160p (3840×2160) 、ビットレートは 35～45 Mbps とします。この値は YouTube にアップロードする動画の推奨エンコードから持ってきました。 4K を WebRTC でどうすれば実現に近づけられるのかを書いていきます。 この資料は P2P は一切考慮していません。SFU のみをターゲットとしています。P2P ではブラウザ側の制限が入るためビットレートが 5Mbps 以上上げることができないからです。 つまり P2P で WebRTC を利用しての 4K はその時点で 4K の画質を満たして
「WebSocket, WebRTC, Socket API, … 最新Webプロトコルの傾向と対策」HTML5 Conference 2013 セッションレポート 吉田 啓二 2013年11月30日（土）に開催された「HTML5 Conference 2013」の、エヌ・ティ・ティ・コミュニケーションズ株式会社・小松健作さんによるセッション「WebSocket, WebRTC, Socket API,…最新Webプロトコルの傾向と対策」の内容をご紹介します。 最新のWebプロトコルが続々と誕生 1990年から10年間ほどは、HTTPというたった一つのプロトコルが、Web通信用のプロトコルとして使われていました。その後、HTML5という言葉が出てきてから、WebSocketやSPDY、HTTP/2.0、WebRTC、Raw Socket API、SCTP over UDP、QUICといった
2012.11.08 全く知らなかったNATのタイプ(NAT,NAPT等の種別ではない) カテゴリ：カテゴリ未分類 全く知らなかったことだが、NATにタイプがある。 静的NAT,動的NAT,NAPTという種類ではなく、full cone,symmetric等のNAT変換する際のポート番号、逆変換の対象に関連するタイプ分けがある。 実際これは知らない人がほとんどだと思う。 何せ、RFCを読まなければほとんどWebでは見かけない情報だから・・・＾＾； ただ、実際はBBRに実装されているNATタイプにより様々な問題が引き起こされていると予想できる。 では、簡単にこのNATタイプについて説明しようと思う。 NATタイプは4種類あり、Full cone NAT,Address-Restricted cone NAT,Port-Restricted cone NAT,Symmetric NATの4種類
1 SIP NAT 030432047 2 � 1 SIP NAT � ICE � STUN TURN � 3 SIP NAT 4 SIP � Session Initiation Protocol � � 2 5 SIP A A B B INVITE INVITE INVITE 100(Trying) 100(Trying) 180(Ringing) 180(Ringing) 180(Ringing) 200 OK 200 OK 200 OK ACK 6 NAT � NAT LAN 7 SIP NAT SIP P1 G1 P1 NAT G1 G3 G3 G2 G3 G2 G2 P1 P1 G3 SDP(P1 SDP 8 ICE 9 ICE � Interactive Connectivity Establishment � STUN TURN SUTN Simple Traversal
ご質問の話題について初めて知った門外漢です。 ちょっと興味をもったのでgoogleしてみました。 こんなド素人の意見でも参考になるようでしたらどうぞ。 > SIPがNATを越えられない理由 次の記事では「越えられない」とは言っていませんでした。相性が良くない，さまざまな問題が発生する，と言っています。つまり，越えられる場合もある，ということでしょう。 http://www.atmarkit.co.jp/fnetwork/tanpatsu/21fi … > メッセージ部分？にも送信元IPアドレスを書く googleでヒットしたのがこちら。 http://www.atmarkit.co.jp/fnetwork/tanpatsu/21fi … http://intuniv.cs.shinshu-u.ac.jp/Lecture/VoIP/S … SDPという構文で記述されたボディ部の中に，次の行が
SIP（Session Initiation Protocol）という言葉を聞いて、IP電話やVoIPといったものを思い浮かべる読者も多いのではないでしょうか？ 確かにSIPは「IP電話のプロトコルである」といえますが、クライアントとサーバ間の通信が中心のインターネット上で、「クライアント同士の直接通信を実現」するという大きな機能と可能性を持つ技術なのです。VoIP／IP電話といったアプリケーションを基に、このSIP技術をひもといてみましょう。 電話をネットで再現する「SIP」 SIPが主に使われているVoIPは、その名のとおり音声をIPで伝えるアプリケーションです。音声をIPで単に相手に伝えることは意外と単純で、デジタル化された音声を細切れにしてパケットとして送信するだけです。このパケット送信には、通常RTP（Real-time Transport Protocol）というシンプルなプロ
2022.2.x から 2023.1.x への移行 リリースノート 既知の問題 実験的機能 非推奨機能 廃止機能 問い合わせ (サポート) FAQ トラブルシューティング Sora が期待どおりに動かない場合、または、動作に問題がある場合 Sora の仕様や使い方に関して質問がある場合 サポートライフサイクル 設定 チュートリアル 本番稼働に向けて ライセンス ログファイル sora.conf リファレンス systemd Linux カーネルチューニング IPv6 での動作について メタデータ センシティブデータ ウェブフックの audio と video 項目の JSON 構造のフラット化 シグナリング WebSocket 経由のシグナリング DataChannel 経由のシグナリング シグナリングの型定義 シグナリング通知 シグナリング通知メタデータ シグナリング通知メタデータ拡張機
こんにちは！がねこまさしです。前回は複数人の同時通話まで実現しました。社内で使うには十分なレベルです。 しかし本格的な企業ユースとなると、まだまだ障害があります。会社と家、自社と別の会社さんなど、実際に通信しようとするとNATやFirewallといった壁が立ちはだかります。 NATを越えよう NATの役割は NAT(+IPマスカレード)は企業だけでなく、一般家庭でも使われています。ブロードバンドルーターやWiFiルーターでは、1つのグローバルIPアドレスを、複数のPCやデバイスで共有することができます。このとき、NATには2つの役割があります。 インターネットにつながったグローバルなIPアドレスと、家庭内/社内のローカルなネットワークでのIPアドレスの変換 複数のPC/デバイスが同時に通信できるように、ポートマッピングによるポート変換 WebRTCでNAT越しに通信すること考えてみましょう
1 概要 サーバ & AWS 初めましてな初心者がAWS上にSTUN/TURNサーバを構築することになりました。 ここでは、coTurnによるTURNサーバ構築をわかりやすい言葉で紹介します。 2 前提 2.1 TURNサーバって？ TURNサーバ周辺の簡単な説明は【初心者向け】STUN/TURNサーバをざっくり解説してみたをお読みください。 2.2 coTurnって何者？ coTurn： https://github.com/coturn/coturn 簡単にSTUN兼TURNサーバが構築できるOSS。 3 本題 coTurnを使ったTURNサーバ構築方法です。 TURNサーバにフォーカスして記述しますが、同時にSTUNサーバも構築されます。 3.1 EC2インスタンスの作成~設定 Amazon EC2 でubuntuのインスタンスを作成します。 (ubuntuだとcoTurnのインスト
1 概要 サーバ & AWS 初めましてな初心者がAWS上にTURNサーバを構築することになりました。 ここでは、一から学んだSTUN/TURNサーバ周りの知識をわかりやすい言葉で解説します。 （ちなみにQiita記事作成も初めてです。それも含めて間違いなど見つけたらご指摘いただけると嬉しいです。） 2 STUNサーバ・TURNサーバはなぜ必要なのか？ STUNサーバとTURNサーバはどちらも「NAT越え」を可能にするために必要です。 「NAT越え」はP2PしたいPCが異なるネットワークにある場合に必要になります。 いろんな言葉が出たので、順番に整理します。 2.1 NATとは？ NATは対応するプライベートIPアドレスとグローバルIPアドレスを双方向に変換するもの。 この図だと、NATでは以下のような変換が行われる。 PC1のグローバルIPアドレス(111.111.111.111) →
VTVジャパン株式会社 元技術戦略アドバイザー 博士（工学、早稲田大学）／IEEE Fellow 大久保 榮 著 2017年4月17日発行 一般公開版
概要 WebRTC の闇の一つである TURN/STUN の TURN サーバにおいて、通常の動作では UDP ですが、それを無理矢理 UDP over TCP で動作する仕組みがあります。 それを簡単に解説していきます。 TURN について 簡単に説明してしまうと NAT 越えを実現するプロトコルです。 WebRTC では UDP 通信を前提とした動作をするため、特定条件下では NAT 越えの必要性が出てきます。 通常であれば WebRTC は P2P での動作をしますが、特定の NAT 下では TURN サーバを経由（リレー）してしか通信をすることができません。 基本は P2P で通信ができる。ただし、いろいろな条件が重なると TURN を使う必要があるというイメージで問題ありません。 用語 クライアント WebRTC ではブラウザです サーバ TURN/STUN サーバです ピア ブ
WebRTCは、音声映像メディアやデータをP2Pで通信する能力をブラウザに提供します。しかし、既存のインターネットの世界ではNATが広く用いられており、容易にP2Pを利用することはできません。この記事では、NATに対してどのような課題がWebRTCに存在し、どのようなアプローチで解決を試みているかについて解説します。 インターネットの世界におけるNATの存在 今日のインターネットにおいて、エンドユーザが用いるホストのほとんどは何らかのNATデバイスの配下に設置されています。これはWebに携わるエンジニアの間では広く知られている事実でしょう。全世界に広がった広大なインターネットの世界に対応するためにIPv6が新たなインターネットプロトコルとして発案されてかなりの時刻が経過しました。にもかかわらず、古いインターネットプロトコルであるIPv4が一般的に用いられており、しかもそのアドレスは既にとっ
WebRTC is secure,� or not secure? - WebRTC セキュリティ概説 -
WebRTCのICEについて WebRTC Meetup Tokyo #8 で講演したスライドです。 口頭説明含めて確認したい方は、以下からご覧になれます。 https://youtu.be/6v4rvLiUCvM?t=47m17s その他誤記指摘等は、twitterの@iwashi86まで。
Improving Scale and Media Quality with Cascading SFUs (Boris Grozev) Deploying media servers for WebRTC has two major challenges, scaling beyond a single server as well as optimizing the media latency for all users in the conference. While simple sharding approaches like “send all users in conference X to server Y” are easy to scale horizontally, they are far from optimal in terms of the media lat
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
