TrickleICEとは - WebRTCの要素技術 -
WebRTCで用いられる要素技術の一つとして、TrickleICEがある。本ポストではTrickleICEについてわかりやすく解説する。 イメージを掴んでもらえるよう平易説明するので、正確さを重視される場合は、RFCを参照いただきたい。 本記事のサマリ：TrickleICEとは？ TrickleICEを一言で表すと、 「ICEの候補をインクリメンタルに探して、 見つかったICE候補を接続先ピアと交換して、 すぐに接続を試行する仕組み」 である。 以下に、背景を含め詳細を解説する。 最低限のおさらい（STUN/TURN) WebRTCで通信をするブラウザは、NAT配下に隠れていることが多い。 そのため、ブラウザ間で直接通信するためには、プライベートアドレスではなく、 グローバルアドレスの情報を利用する必要があり、何らかの仕組みを活用する必要がある。 その仕組みとして用意されているのが、STU
Engineers in VOYAGE - 事業をエンジニアリングする技術者たち - を読んだ
はじめに 話題となっていた書籍である Engineers in VOYAGE を読み終えたので、その簡単な書評を書く。 書評 結論から述べると、本書籍で多く触れられるWeb技術に関わる技術者だけでなく、普段は上流工程から技術やプロジェクトマネジメントに携わっているエンタープライズな技術者にも本書籍を読んで欲しいとおもった。なぜかと言うと、通常であれば隠蔽されていて見えないエンジニアの考えや努力が、生々しく記載されており、エンタープライズ領域でも有用である知見が多く記載されているからだ。 レガシーシステムとの戦い たとえば、Voyage Marketing社におけるECナビでの、経済産業省の述べる2025年の崖への戦いの知見が1つの例だ。1200を超えるテーブルを持つオンプレシステムに対して、いかに泥臭く改善を進めたか、書籍で説明されている。具体的な取り組みとしては、オンプレからクラウドへの
エンタープライズ向けWebRTCの外堀が埋まってきている
本記事は、WebRTCをエンタープライズで利用したいと考えている人（例えば情シスの人）向けに、WebRTCの技術的な内容をいくつかまとめた記事。 エンタープライズ向けWebRTCの外堀が埋まってきている 社内向けなどの施策で、たとえば先進的な技術をつかったコスト削減を狙う担当者はそれなりにいると思う。WebRTCは、そこで目をつけられる技術の1つだ。（典型的なケースでは、既存のWebビデオ会議などのリプレース候補など） 新技術を導入するとなると、当然のことながら観点の1つとしてセキュリティに目がいく。すなわち、社内で「WebRTCは安全に使えるのだろうか？」と考えるということだ。たとえば、「音声・映像のトラフィックが暗号化されていたとしても、インターネットに出るのは怖い」、と偉い人が言うかもしれない。これに対する一定の回答はあるので、本記事前半で紹介する。 また、WebRTC登場初期時は、
WebRTC MediaServer(SFU/MCU)の情報まとめ
はじめに WebRTCの通信形態は大きく分けて、暗号化を解く/メディアを解釈するサーバを介するもの と 介さないもの、の2種類がある。 暗号化を解く or メディアを解釈する サーバを介さないもの P2P TURN経由 暗号化を解く or メディアを解釈する サーバを介するもの MCU経由★ SFU経由★ (VoIP-WebRTC Gatewayなどもあるが、ここでは取り上げない) どれが必要になるかは、WebRTCを利用するアプリケーションのユースケースに依存するので、一概に何が1番良いというものはない。 本記事では、上記のうち、★をつけているメディアサーバ(SFU/MCU)の現状(2016年)について記載する。WebRTCを使う上で、特にMCUやSFUに興味がある方には参考になれば幸いだ。 もし、記載で誤っている点などがあれば @iwashi86 までメンション/DMをいただきたい。
2016/3末時点のWebRTCブラウザ対応状況まとめ
はじめに WebRTCは様々なブラウザでサポートが進んでいる。これらの対応状況について世の中に多くの情報があるが、アップデートされていない情報も多いため、最新の情報を追うのはなかなか骨が折れる。そこで、本記事では2016年3末時点での対応状況をまとめていく。 本記事を読むと得られるもの・得られないもの 得られるもの 2016年3末時点での各ブラウザにおけるWebRTCの対応状況 得られないもの ソースコードレベルの実装詳細 対象読者 WebRTCに関わっているエンジニア、WebRTCの動向に興味がある人 WebRTCを多少なりとも知っている人 では本題に進む。 Google Chrome WebRTCの提唱をはじめたGoogleだけあって、WebRTCの黎明期から様々な機能を提供している。現在も活発に開発が進んでおり、Chrome/FirefoxにおけるWebRTCのマイルストーンの記事に
WebRTCのSDP typeにおけるpranswerとは
はじめに WebRTCではSDPを示すオブジェクトとして、RTCSessionDescriptionが利用される。RTCSessionDescriptionにはいくつかのタイプがあり、通常利用するのが”offer”と”answer”だ。実はあまり知られていないが、UXを向上させるための手段として”pranswer”というタイプもある。 私の知る限り、日本語で言及されている情報は見つからなかったので、本記事にて”pranswer”について解説する。 本記事の概要、読むと得られるもの “pranswer”とは？なぜ必要なのか？ JavaScriptからどうやったら使えるのか？ 対象読者 WebRTCのクライアントサイドを開発しているエンジニア SDPについて多少なりとも知識がある人 では本題。 pranswerとは？ まず、pranswerとはProvisional Answerの略だ。Pro
Slackにおける音声通話機能のWebRTC観点からの解析
はじめに 2016/3/3より、Slackに音声通話機能が搭載された。 試しに使ってみたSlackユーザもそれなりにいると思う。 Slack音声通話機能の対応クライアントは、現時点では限定的だ。Slackの設定画面の一文を引用すると Currently on Mac and Windows desktop apps and in Chrome; coming soon to mobile! の通りで、Chromeまたはデスクトップのネイティブアプリとなる。 音声機能が実装されていてこの種類の対応状況なら、もちろん利用技術はWebRTCと考えるのが素直だ。(しかもWebRTCベースのスタートアップであるScreenHeroを買収していることもあり) ここで、最も気になるのは内部でWebRTCをどのように利用しているか、という点だ。 すでに、WebRTCエンジニア御用達のWebRTCHacks
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Building and Scaling Video Conferencing in Slack 講演から取ったメモ