Ross Carter
概要
このホワイト ペーパーは、IT プロフェッショナルおよび開発者を対象として、リアルタイム コミュニケーションの概念、プロトコル、およびテクノロジを解説します。ここでは、IETF (Internet Engineering Task Force) SIP (Session Initiation Protocol)、SIMPLE (SIP Instant Messaging and Presence Language Extensions)、および RTP (Real-time Transport Protocol) などのプロトコルについて説明します。Microsoft は、これらのプロトコルを使用して、音声および映像通信、インスタント メッセージング、アプリケーション共有、およびコラボレーションを含んだ企業でのマルチモーダル コミュニケーション用の RTC (リアルタイム コミュニケーション) プラットフォームを構築しています。このホワイト ペーパーでは、Microsoft Windows XP オペレーティング システムが音声通信をサポートする方法を具体例として、その基盤にあるテクノロジがどのように動作するのかを紹介します。
トピック
はじめに
RTC 呼処理
SIP (Session Initiation Protocol)
SDP (Session Description Protocol)
音声と映像のデジタル化と圧縮
RTP と RTCP
音声品質テクノロジ
SIMPLE (SIP Instant Messaging and Presence Language Extensions)
まとめ
関連情報
はじめに
Microsoft RTC プラットフォームは、業界標準の通信規格をサポートする Microsoft のコミットメントに基づいています。Windows XP は、IETF (Internet Engineering Task Force) SIP (Session Initiation Protocol)、SIMPLE (SIP Instant Messaging and Presence Language Extensions)、および RTP (Real-time Transport Protocol) をサポートしています。これらのプロトコルと関連テクノロジは、音声、映像、またはインスタント メッセージングなど、その通信手段にかかわらず、リアルタイム コミュニケーションをパケット交換ネットワーク上で行うためのニーズを満たすために設計されています。
このホワイト ペーパーでは、交換回線音声ネットワークでの音声通信プロセスを簡単に説明した後、RTC 音声通信を具体例として、RTC の基盤となるテクノロジがいかにパケット交換ネットワーク上でリアルタイム コミュニケーションを実現する方法を解説します。
RTC 呼処理
RTC をある 1 点から他の 1 点に送信するプロセスでは、複数の手順がふまれて、複数のプロトコルが使用されます。呼の確立、変更、および終了を行うためには何らかの信号化および呼制御が必要です。回線交換ネットワークである PSTN (公衆交換電話網) では、SS7 (Signaling System 7) が呼設定および終了に使用されます。パケットベースのネットワークでは、呼制御に SIP および H.323 プロトコルを使用できます。SIP の詳細については、このドキュメントの後の「SIP (Session Initiation Protocol)」を参照してください。H.323 の詳細については、『Microsoft Windows 2000 Server Resource Kit』の『Windows 2000 Internetworking Guide』の「Telephony Integration and Conferencing (英語)」を参照してください。
呼セッションが確立されると、音声または映像入力をサンプリングして、デジタル形式に変換します。その後、サンプリングされたデータは RTP (Real-time Transport Protocol) にカプセル化されます。RTP は、パケットベースのネットワーク上のリアルタイム コミュニケーションに特化された設計です。
次に、RTP パケットはネットワーク転送プロトコルにカプセル化されます。一般的にネットワーク転送プロトコルとして UDP (User Datagram Protocol) が使用されます。TCP (Transmission Control Protocol) もカプセル化に使用することができます。ただし、TCP は保証型転送プロトコルのため、TCP パケットを再送するための時間によって待ち時間 (パケットの送受信に要する時間) が発生して、受信音声が判読不能になる可能性があります。RTP パケットの転送中、RTP セッションの品質を監視するために RTCP (Real-time Control Protocol) が使用されます。RTP および RTCP の詳細については、このドキュメントの後の「RTP と RTCP」を参照してください。
次に、UDP または TCP のネットワーク転送プロトコルは IP パケットにカプセル化され、IP パケットは Ethernet などのリンク レイヤ プロトコルにカプセル化されます。リンク レイヤ パケットは着呼コンピュータに転送されます。図 1 では、RTP パケットのカプセルからリンク レイヤ パケットまでのカプセル化手順を示します。
.gif)
図
1: RTCommunication
プロトコル
カプセル化
SIP (Session Initiation Protocol)
HTTP (HyperText Transfer Protocol) と類似する SIP (Session Initiation Protocol) は、テキストベースのアプリケーション層信号化、呼制御プロトコルです。SIP を使用して SIP セッションの作成、変更、および終了を行います。SIP はユニキャストとマルチキャスト通信を共にサポートしています。SIP はテキストベースのため、H.323 に比較して実装、開発、およびデバッグが容易に行うことができます。
メモWindows Messenger は SIP ベースのアプリケーションです。Windows XP は、TAPI (Telephony Application Programming Interface) をとおして SIP をサポートしていません。Windows Messenger の詳細については、Windows XP Professional の [
ヘルプとサポート
センター
] の「Windows Messenger を使用する」および『Microsoft Windows XP Professional リソース キット』の「Configuring Telephony and Conferencing (英語)」を参照してください。
SIP
コンポーネント
SIP 環境の主要なコンポーネントは SIP サーバーと SIP ユーザー エージェントの 2 つの主要カテゴリに分類されます。
SIP
サーバー
SIP サーバーにはプロキシ、登録、およびリダイレクトの 3 種類が存在します。表 1 に示すように、それぞれのサーバーは異なる機能を担います。サーバーが担当する機能に応じて、そのサーバーが処理する SIP リクエストが決まります。
表
1 SIP
サーバーの種類
|
SIP サーバー
|
機能
|
|---|
|
プロキシ サーバー
|
SIP ユーザー エージェント クライアントと SIP ユーザー エージェント サーバーの仲介として機能します。プロキシ サーバーは、クライアントとサーバー間の通信方向に応じて、SIP ユーザー エージェントと SIP ユーザー エージェント サーバーの両方の機能を担当します。プロキシ サーバーは、単に SIP リクエストを転送するか、または転送する前に修正することができます。
|
|
登録サーバー
|
ユーザー エージェントの IP アドレスおよび SIP アドレス、つまり URL (Uniform Resource Locator) が含まれる REGISTER リクエストを受け取ります。これにより、登録サーバーは REGISTER リクエストを送信したユーザー エージェントの所在を管理することができます。
|
|
リダイレクト サーバー
|
発呼ユーザー エージェントから送信された SIP INVITE リクエストで SIP セッション開始を承認し、着呼ユーザー エージェントの正しい SIP アドレスを取得し、発呼ユーザー エージェントに正しい SIP アドレスを応答します。発呼ユーザー エージェントは、正しい SIP アドレスを使用して着呼ユーザー エージェントと直接 SIP セッションを開始します。
|
プロキシ、登録、およびリダイレクトの SIP サーバーは、個別のアプリケーションとして開発、または各サーバーの機能を統合した単一のアプリケーションとして開発できます。登録サーバーとプロキシ サーバーを統合したものを "rendezvous" サーバーと呼びます。
SIP
ユーザー
エージェント
表 2 に 2 つの SIP ユーザー エージェントおよびその機能を示します。
表
2 SIP
ユーザー
エージェントの種類
|
SIP ユーザー エージェント
|
機能
|
|---|
|
ユーザー エージェント クライアント
|
SIP リクエストを開始
|
|
ユーザー エージェント サーバー
|
SIP リクエストを受け取る
|
各ユーザー エージェントには、SIP アドレスが関連付けされます。
SIP
コール
フロー
SIP セッションのコール フローは、SIP セッションが SIP ユーザー エージェント間で直接確立されているか、SIP ユーザー エージェントの間に SIP サーバー (プロキシ、登録、またはリダイレクト) が存在するかによって異なります。
図 2 に 2 つのユーザー エージェント間の一般的なコール フローを示します。かっこ内の数字は順番を示します。まず、ユーザー エージェント A は INVITE リクエストを送信して呼の開始をリクエストします。ユーザー エージェント B は Trying 応答コード (100) に応答し、呼リクエストが処理されていることを示します。ユーザー エージェント B は OK 応答コード (200) に応答し、ユーザー エージェントが呼を承認したことを示します。ユーザー エージェント A は、ユーザー エージェント B の確認 (ACK) リクエストに応答し、ユーザー エージェント A がユーザー エージェント B から最終応答コードを受け取ったことを示します。次に、リアルタイム データが RTP パケットにカプセル化 (このホワイト ペーパーの後の「RTP と RTCP」を参照) され、ユーザー エージェント A とユーザー エージェント B の間で交換されます。ユーザー エージェント A またはユーザー エージェント B は、ユーザー エージェントがセッションを終了することを示す BYE リクエストを送信することができます。BYE リクエストを受け取ったユーザー エージェント B は、ユーザー エージェント A に OK 応答コード (200) を送信し、リクエストが成功したことを示します。
.gif)
図
2:
ユーザー
エージェント
SIP
コール
フロー
図 3 に 2 つのユーザー エージェントの間にプロキシ サーバーが存在する場合の一般的なコール フローを示します。プロキシ サーバーは実質的な通信中継地点として機能し、ユーザー サーバーとユーザー エージェントの両方として機能します。ユーザー サーバーとして機能するプロキシは、SIP リクエストを受け取り、目的ユーザー エージェントに転送します。ユーザー エージェントとして機能するプロキシは、SIP 応答を受け取り、目的ユーザー エージェントに転送します。
.gif)
図
3:
プロキシ
サーバー
SIP
コール
フロー
図 4 にユーザー エージェントと登録サーバー間の一般的なコール フローを示します。登録サーバーはユーザー エージェントから REGISTER リクエストを受け取り、着呼ユーザー エージェントと通信が可能なアドレスを伝えます。登録サーバーは一般的にプロキシまたはリダイレクト サーバーに統合されています。
.gif)
図
4:
登録サーバー
SIP
コール
フロー
図 5 に 2 つのユーザー エージェントの間にリダイレクト サーバーが存在する場合の一般的なコール フローを示します。ユーザー エージェント A は INVITE リクエストを送信して呼の開始をリクエストします。リダイレクト サーバーは Moved 応答コード (302) に応答し、ユーザー エージェント B が一時的に移動したことを示します。ユーザー エージェント A は、ACK リクエストに応答し、ユーザー エージェント A がリダイレクト サーバーから応答コードを受け取ったことを示します。ユーザー エージェント A は、新しく取得したユーザー エージェント B のアドレスに直接 INVITE リクエストを送信します。
.gif)
図
5:
リダイレクト
サーバー
SIP
コール
フロー
SIP
アーキテクチャの例
図 6 では、SIP コンポーネント間の通信方法およびネットワーク環境での SIP コンポーネントの位置づけを示すために SIP アーキテクチャの例を示します。
.gif)
図
6: SIP
アーキテクチャの例
架空の A. Datum Corporation は社内で SIP リクエストをドメイン間でリダイレクトする 2 つのプロキシ サーバーが配置されています。ファイアウォールに接続された SIP プロキシ サーバーは社外の受信者に送信される SIP メッセージ、および社外から社内の受信者に送信されるメッセージを処理します。たとえば、A. Datum Corporation の SIP クライアントから Fabrikam, Inc. の SIP クライアントに送信された SIP INVITE メッセージは、Fabrikam, Inc. の SIP プロキシ サーバーに送信されます。
SIP プロキシ サーバーは、SIP INVITE リクエストを Fabrikam, Inc. の SIP プロキシ サーバーのドメインに含まれる目的 SIP クライアント コンピュータまたは SIP IP フォンに転送します。たとえば、Fabrikam, Inc. の SIP サーバーが、グローバル電話番号の形式の SIP URL が含まれた SIP INVITE リクエストを受け取るとします。グローバル電話番号が Fabrikam, Inc. の SIP IP フォンを指定する場合は、SIP INVITE リクエストは SIP IP フォンに直接転送されます。しかし、グローバル電話番号がアナログ電話など、SIP IP フォンではない到達点を指定している場合は、SIP INVITE リクエストは SIP/PSTN ゲートウェイに転送されます。SIP/PSTN ゲートウェイは SIP INVITE リクエストを PSTN 用に変換します。Fabrikam, Inc. の PBX (構内交換機) はグローバル電話番号を参照して、呼を社内のアナログ電話にルートするか、社外の電話にルートするために PSTN に転送するかどうかを判断します。
SIP
プロトコル
SIP メッセージは RFC 822「Standard for the Format of ARPA Internet Text Messages」で規定されている標準 Internet メッセージ形式に基づいています。RFC 822 の詳細については、http://www.microsoft.com/windows/reskits/webresources/ の「Web Resources page (英語)」を参照してください。SIP メッセージはクライアントからサーバーへのリクエスト、またはサーバーからクライアントへの応答のいずれかになります。
各 SIP メッセージは 3 つの要素から構成されます。それぞれを表 3 に示します。
表
3 SIP
メッセージの要素
|
SIP メッセージ要素
|
定義
|
|---|
|
開始行
|
内容はメッセージがリクエストまたは応答によって異なります。リクエストおよび応答の開始行はいずれも SIP バージョンが含まれます。リクエストの開始行は、メソッド タイプおよびリクエストを受信する送信先の SIP アドレスまたは一般 URL が含まれます。応答の開始行は、数値のステータスコードおよびリクエストに対する応答を説明する reason-phrase が含まれます。
|
|
ヘッダー
|
ヘッダー タイプおよび関連する変数が含まれます。
|
|
メッセージ ボディ
|
SIP セッションのメディア能力など、SDP (Session Description Protocol) が提供する情報が含まれます。
|
SIP が開始行およびヘッダーの値を決定します。SDP がメッセージ ボディの値を決定します。
SIP
メッセージ開始行
表 4 に示すように、開始行の構文はメッセージがリクエストまたは応答によって異なります。
表
4
開始行の構文
|
開始行
|
構文
|
|---|
|
リクエスト
|
Method Request-URI SIP-Version
|
|
応答
|
SIP-Version Status-Code Response-Phrase
|
リクエストメソッド
リクエスト開始行の最初の項目は、信号化コマンドである SIP メソッドです。表 5 に示す SIP メソッドは、RFC 3261 およびインターネット ドラフト「SIP Extensions for Presence」と「SIP Extensions for Instant Messaging」で定義されています。
表
5 SIP
メソッドとその機能
|
SIP メソッド
|
機能
|
|---|
|
INVITE
|
SIP セッションを開始するリクエスト。INVITE は発呼側から着呼側に送信されます。
|
|
ACK
|
着呼側が呼を承認。着呼側から発呼側に ACK が送信されます。
|
|
OPTIONS
|
発呼側は、着呼側に能力を応答するようリクエスト。
|
|
BYE
|
セッションを終了するリクエスト。BYE は着呼側または発呼側のいずれも送信できます。BYE を受け取った側は、BYE で応答する必要はありません。
|
|
CANCEL
|
未処理のリクエストをキャンセル。
|
|
REGISTER
|
発呼側が、現在の位置を登録サーバーに登録することをリクエスト。
|
|
SUBSCRIBE
|
発呼側が、着呼側のプレゼンス情報の更新をリクエスト。
|
|
NOTIFY
|
自身のステータスが更新されたことを自身にサブスクライブしているパーティに通知。
|
|
MESSAGE
|
インスタント メッセージ送信に使用。
|
Request URI
リクエスト開始行の 2 つ目の項目は、着呼側の URL が含まれる Request-URI (Uniform Resource Identifier ) です。一般的に URL は SIP URL が使用されます。SIP URL は複数の書式が存在します。表 6 に、サポートされる一部の書式を示します。利用可能な SIP URL 書式および構文については、http://www.microsoft.com/windows/reskits/webresources/ の「Web Resources page (英語)」を参照してください。
表
6 SIP
リクエスト
URL
書式
(
一部掲載
)
|
SIP URL 書式
|
説明
|
|---|
|
sip:user@reskit.com
|
基本的な SIP URL。
|
|
sip:user@reskit.com;transport=TCP
|
TCP を転送プロトコルとして指定された基本 SIP URL。転送プロトコルが設定されていなければ、既定値として UDP が適用されます。
|
|
sip:user@172.16.20.54
|
IP アドレスを使用した SIP URL。
|
|
sip:+1-425-707-9796@reskit.com;user=phone
|
グローバル電話番号を使用した SIP URL。
|
|
sip:marketing@reskit.com;maddr=225.0.2.1;ttl=64
|
マルチキャスト アドレスを指定した SIP URL。直前に指定されているホスト名は無視されます。TTL (time-to-live) 値は 64 (0 ～ 255) に設定されています。マルチキャスト アドレスを使用する場合は、TTL を指定し、転送プロトコルとして UDP を使用する必要があります。
|
リクエストまたは応答バージョン
リクエストの開始行の最後の項目、および応答開始行の最初の項目は SIP バージョンです。現在の SIP バージョンは 2.0 です。
次のサンプルの SIP リクエスト メッセージは、Windows Messenger セッションから取ったものであり、一般的な SIP リクエスト行を示します。
.gif)
応答ステータス
コード
ステータス コードには情報、成功、リダイレクト、クライアント エラー、サーバー エラー、およびグローバル失敗の 6 つのカテゴリに分類されます。表 7 で示すように、ステータス コードの最左側の値がコードのカテゴリを示します。
表
7: SIP
応答ステータス
コード
|
ステータス コード
|
応答カテゴリ
|
説明
|
|---|
|
1xx
|
情報
|
リクエストを受け取って処理しています。
|
|
2xx
|
成功
|
リクエストした動作を正しく理解し、承認されました。
|
|
3xx
|
リダイレクト
|
リクエストを完了するにはさらなる操作が必要です。
|
|
4xx
|
クライアント エラー
|
リクエストの構文に誤りが存在するか、サーバーが受け取ることはできません。
|
|
5xx
|
サーバー エラー
|
サーバーはリクエストを受け取りましたが、処理できません。他のサーバーで処理できる可能性があります。
|
|
6xx
|
グローバル失敗
|
リクエストを受け取ったサーバーはリクエストを処理できません。他のサーバーでも失敗します。よって、リクエストを転送しないでください。
|
応答フレーズ
表 8 に SIP version 2.0 で定義されているすべての SIP 応答コードおよびそのカテゴリと応答フレーズを示します。
表
8 SIP
応答ステータス
コードとフレーズ
|
ステータス コード
|
応答カテゴリ
|
応答フレーズ
|
|---|
|
100
|
情報
|
Trying
|
|
180
|
情報
|
Ringing
|
|
181
|
情報
|
Call is being forwarded
|
|
182
|
情報
|
Queued
|
|
200
|
成功
|
OK
|
|
300
|
リダイレクト
|
Multiple choices
|
|
301
|
リダイレクト
|
Moved permanently
|
|
302
|
リダイレクト
|
Moved temporarily
|
|
303
|
リダイレクト
|
See other
|
|
305
|
リダイレクト
|
Use proxy
|
|
380
|
リダイレクト
|
Alternative service
|
|
400
|
クライアント エラー
|
Bad request
|
|
401
|
クライアント エラー
|
Unauthorized
|
|
402
|
クライアント エラー
|
Payment required
|
|
403
|
クライアント エラー
|
Forbidden
|
|
404
|
クライアント エラー
|
Not found
|
|
405
|
クライアント エラー
|
Method not allowed
|
|
406
|
クライアント エラー
|
Not acceptable
|
|
407
|
クライアント エラー
|
Proxy authentication required
|
|
408
|
クライアント エラー
|
Request timeout
|
|
409
|
クライアント エラー
|
Conflict
|
|
410
|
クライアント エラー
|
Gone
|
|
411
|
クライアント エラー
|
Length required
|
|
413
|
クライアント エラー
|
Request entity too large
|
|
414
|
クライアント エラー
|
Request-URI too large
|
|
415
|
クライアント エラー
|
Unsupported media type
|
|
420
|
クライアント エラー
|
Bad extension
|
|
480
|
クライアント エラー
|
Temporarily not available
|
|
481
|
クライアント エラー
|
Call leg/transaction does not exist
|
|
482
|
クライアント エラー
|
Loop detected
|
|
483
|
クライアント エラー
|
Too many hops
|
|
484
|
クライアント エラー
|
Address incomplete
|
|
485
|
クライアント エラー
|
Ambiguous
|
|
486
|
クライアント エラー
|
Busy here
|
|
500
|
サーバー エラー
|
Internal server error
|
|
501
|
サーバー エラー
|
Not implemented
|
|
502
|
サーバー エラー
|
Bad gateway
|
|
503
|
サーバー エラー
|
Service unavailable
|
|
504
|
サーバー エラー
|
Gateway time-out
|
|
505
|
サーバー エラー
|
SIP version not supported
|
|
600
|
グローバル失敗
|
Busy everywhere
|
|
603
|
グローバル失敗
|
Decline
|
|
604
|
グローバル失敗
|
Does not exist anywhere
|
|
606
|
グローバル失敗
|
Not acceptable
|
SIP
メッセージ
ヘッダー
SIP メッセージの開始行の後に 1 つ以上のヘッダーが続きます。ヘッダーはメッセージがリクエストまたは応答によって異なります。ヘッダーは RFC 3261「SIP: Session Initiation Protocol」で定義されています。詳細については、http://www.microsoft.com/windows/reskits/webresources/ の「Web Resources page (英語)」を参照してください。
表 9 で示すように、ヘッダーは "全般"、"リクエスト"、"応答"、および "エンティティ" の 4 つのカテゴリに分類されます。全般カテゴリのヘッダーはリクエストおよび応答の両方のメッセージで使用できます。
表
9 SIP
ヘッダー
|
全般
|
リクエスト
|
応答
|
エンティティ
|
|---|
|
Accept
|
Authorization
|
Allow
|
Content-encoding
|
|
Accept-encoding
|
Contact
|
Proxy-authenticate
|
Content-length
|
|
Accept-language
|
Hide
|
Retry-after
|
Content-type
|
|
Call-ID
|
Max-forwards
|
Server
|
|
|
Contact
|
Organization
|
Unsupported
|
|
|
Cseq
|
Priority
|
Warning
|
|
|
Date
|
Proxy-authorization
|
WWW-authenticate
|
|
|
Encryption
|
Proxy-require
|
|
|
|
Expires
|
Route
|
|
|
|
From
|
Require
|
|
|
|
Record-route
|
Response-key
|
|
|
|
Time stamp
|
Subject
|
|
|
|
To
|
User-agent
|
|
|
|
Via
|
|
|
|
次のサンプルの SIP リクエストは、Windows Messenger セッションから取ったものであり、SIP ヘッダーを示します。
.gif)
SDP がメッセージ ボディの値を決定します。
SDP (Session Description Protocol)
SDP (Session Description Protocol) は、マルチメディア会議のアナウンスおよび記述を定義する IETF 規格です。SIP メッセージ ボディは、SDP が定義するセッション記述が含まれます。セッションの記述は、セッション記述 (必ず 1 つ)、日時記述、メディア記述の 3 つの主な部分に細分化されます。日時記述およびメディア記述については、複数記述することも省略することもできます。セッション記述には、会議全体またはすべてのメディア ストリームに適用されるグローバル属性が含まれます。日時記述には、会議の開始、終了、および再開催日時が記述されます。メディア記述には、メディア ストリーム固有の詳細情報が記述されます。表 10 に SDP タイプおよび SDP メッセージの各 3 種類の部分に使用できる記述値を示します。
表
10 SDP
記述
|
セッション
|
|
日時
|
|
メディア
|
|
|---|
|
タイプ
|
値
|
タイプ
|
値
|
タイプ
|
値
|
|
v
|
プロトコル バージョン
|
t
|
セッションの時間
|
m
|
メディア名とトランスポート アドレス
|
|
o
|
所有者/作成者とセッション識別子
|
r
|
0 回以上の繰り返し
|
i
|
メディア タイトル
|
|
s
|
セッション名
|
|
|
c
|
接続情報
|
|
i
|
セッション情報
|
|
|
b
|
帯域幅情報
|
|
u
|
記述の URI
|
|
|
k
|
暗号化鍵
|
|
e
|
電子メール アドレス
|
|
|
a
|
0 行以上のメディア属性行
|
|
p
|
電話番号
|
|
|
|
|
|
c
|
接続情報
|
|
|
|
|
|
b
|
帯域幅情報
|
|
|
|
|
|
z
|
タイムゾーンの調整
|
|
|
|
|
|
a
|
0 行以上のセッション属性行
|
|
|
|
|
次のサンプルの SIP リクエスト メッセージは、Windows Messenger セッションから取ったものであり、SIP メッセージ ボディを示します。
.gif)
音声と映像のデジタル化と圧縮
SIP で呼を確立した後、データをデジタル化して圧縮する必要があります。本来アナログ形式である音声および映像データをパケットベースのネットワーク上に転送するには、アナログの波形をデジタル値に変換する必要があります。データがデジタル形式に変換されると、ソフトウェアベースのコーデックを使用してデータを圧縮します。これによりネットワーク利用率を効率化しつつ音声品質を維持できます。
音声のデジタル化
音声信号をデジタル形式に変換するには、次のような手順を行います。まず、音声入力を構成する波形を等間隔にサンプリングします。このようすを図 7 に示します。
.gif)
図
7:
周期的な波形サンプリング
サンプリング レート、つまり波形のサンプルを採取する間隔は、サンプリングされる音声メディアの種類、およびコーデックと関連する暗号化アルゴリズムによって変化します。たとえば、PCM (pulse code modulation) 暗号化アルゴリズムを使用する PSTN は、8 KHz の音声サンプリング レートを使用します。Hz は 1 秒間に 1 サイクルです。
サンプリング レートはナイキスト基準から算出されます。
Fs > 2ﾗBW
Fs = サンプリング頻度
BW = 入力アナログ音声信号の帯域幅
ナイキスト基準は、サンプリングされる最大周波数の 2 倍以上の頻度でサンプリングを行う必要があると定義しています。ほとんどのアナログ音声信号が 4 KHz の周波数帯に収まるため一般的な音声通信では 8 KHz のサンプリング レートで十分だと判断されます。
データのサンプリングを行った後、波形の各サンプルがどの間隔に該当するのかを判断します。図 8 に示すこのプロセスは "量子化" と呼ばれます。
.gif)
図
8:
量子化
データのサンプリングと量子化が完了すると、転送を行うために各サンプルに 8 ビットの記号が割り当てられます。各 8 ビットの記号はネットワーク上に転送されます。図 9 では、図 8 で示した量子化の最初の 3 つのサンプルを転送するようすを示します。
.gif)
図
9:
デジタル信号の転送
このようにして、PSTN 回線交換ネットワーク上で行われるアナログ転送 (音声またはデータ) に必要な帯域幅が 64 Kbps (8 KHz x 1 サンプルあたり 8 ビット) であることを算出できます。
音声と映像の圧縮
音声および映像のコーデックは、送信者が送信を行う前にアルゴリズムを使用してデジタル化された音声および映像信号を圧縮します。また、受信者がコンピュータでそれらを再生する前に復元します。コーデックを使用してデータの圧縮および復元を行うと、ネットワークの帯域幅の使用率を軽減し、ネットワークのトラフィック負荷を減らすことができます。
アナログからデジタル形式への変換、およびデジタルからアナログ形式に戻す操作はハードウェアで行います。つまり、ソース フィルタがデータを入手する前の段階で、既にデータは (圧縮が施されていない) デジタル化された状態です。図 10 では、コーデックを使用した映像の圧縮と復元の一連の動作を示します。
.gif)
図
10:
映像の圧縮と復元
表 11 で示すように、Windows XP は SIP および H.323 テレフォニー アプリケーションで各種音声コーデックをサポートしています。
表
11 Windows XP
がサポートする音声コーデック
|
音声コーデック
|
サンプリング レート
|
ビット レート
|
フレーム サイズ
|
暗号化アルゴリズム
|
|---|
|
DVI4
|
8 kHz
|
32 Kbs
|
20 ms
|
ADPCM
|
|
G.711
|
8 kHz
|
64 Kbs
|
20 ms
|
PCM (MuLaw) (aLaw)
|
|
G.722.1 (SIP only)
|
16 kHz
|
24 Kbs
|
20 ms or 40 ms
|
MLT
|
|
G.723.1
|
8 kHz
|
5.3 Kbs / 6.3 Kbs
|
30 ms, 60 ms, or 90 ms
|
CELP
|
|
GSM6.10 (SIP only)
|
8 kHz
|
13 Kbs
|
20 ms
|
RPE-LTP
|
|
SIREN (SIP only)
|
16 kHz
|
16 Kbs
|
20 ms or 40 ms
|
MLT
|
表 12 で示すように、Windows XP は SIP および H.323 テレフォニー アプリケーションで各種映像コーデックをサポートしています。
表
12 Windows XP
がサポートする映像コーデック
|
コーデック
|
ビット レート
|
暗号化アルゴリズム
|
|---|
|
H.261
|
64 kbs-256 Kbs
|
DCT
|
|
H.263
|
16 kbs-256 Kbs
|
DCT
|
音声帯域幅キャパシティ
音声および映像データを転送するために必要な帯域幅は、使用されるコーデックおよびそれに関連する量子化、圧縮アルゴリズムによって決定します。たとえば、PSTN 上で 1 つ分のアナログ音声通話は 64 Kbs の帯域幅が必要です。この必要帯域幅は PCM を使用した暗号化アルゴリズムによるもので、良好な品質を提供します。
IP テレフォニーを利用するメリットとして、最新のコーデック技術の進歩を利用できることが挙げられます。上で説明したように、PSTN 上の 1 つの音声通話は 64 Kbs のビット レートを占有します。しかし、CELP (Code Excited Linear Predictive) 暗号化アルゴリズムを採用した G.723.1 コーデックをパケット交換ネットワークで使用すると、同じ 64 Kbs のビット レートでも約 10 個の音声通話を収容することが可能です。IP テレフォニーでは 8 ビット PSTN コーデックよりも高品質で PSTN 呼に比べて必要帯域幅が少ない 16 KHz コーデックなども利用できます。
メモ 16 KHz のサンプリング レートを使用すると、ネットワーク帯域幅が 128 Kbps に増加します。しかし、最近の音声コーデックとネットワーク テクノロジの進歩により、IP ネットワーク上で 16 KHz のサンプリング レートを採用する価格も下がりつつあります。
RTP と RTCP
データがデジタル化され、圧縮されてパケットベースのネットワークに転送しやすいように最適化された後、RTP にカプセル化されます。RTP はリアルタイムの転送プロトコルであり、RTCP は RTP セッションを監視する制御プロトコルです。RFC 1889「RTP: A Transport Protocol for Real-time Communications」で定義される RTP と RTCP は、パケットベースのネットワーク上でのリアルタイム コミュニケーションのニーズに特化して IETF が開発しました。RTP と RTCP の詳細については、http://www.microsoft.com/windows/reskits/webresources/ の「Web Resources page (英語)」で RFC 1889 を参照してください。
SIP および H.323 は、RTP を使用して呼に参加するパーティ間でデジタル化された音声と映像データの転送を行います。各 RTP パケットは、1 つ以上のメディア ペイロード、およびタイムスタンプやシーケンス番号などの関連情報が含まれます。
一般的に、RTP と RTCP は、下位転送層として UDP を、下位ネットワーク層として IP を使用します。RTP はメディア ストリームの送信者、受信者の間でネゴシエーションされた動的 UDP ポートを使用します。しかし、RTP と RTCP は下位転送層およびネットワーク層に依存しないため、UDP および IP を転送、ネットワーク プロトコルとして使用することは必須ではありません。
RTP
RTP は、[Windows Messenger] や [
電話
] などのリアルタイム アプリケーションにエンド ツー エンド ネットワーク転送機能を提供します。RTP は、リアルタイム セッションに関する情報が含まれるため、アプリケーションはジッタ、不正なパケット順序、および破棄パケットなどを簡単に調整できます。この情報の多くは RTP ヘッダーに含まれます。
図 11 に RTP パケットの構造を示します。
.gif)
図
11: RTP
パケット構造
|
Version
|
RTP のバージョン。Windows XP は Version 2 をサポートします。
|
|
Padding
|
"1" に設定された場合、ペイロードの末端に 1 つ以上のパディング オクテットが追加されていることを示します。最初のパディング オクテットに追加されたオクテットの数を示します。
|
|
Extension
|
拡張ビットがセットされている場合、固定の RTP ヘッダーに拡張ヘッダーが追加されていることを示します。
|
|
CSRC count
|
固定 RTP ヘッダーに続く CSRC (Contributing Source) 識別子の数を示します。
|
|
Marker
|
Marker ビットの定義と用法は RTP プロファイルが決定します。
|
|
Payload type
|
RTP のペイロード タイプを定義します。
|
|
Sequence number
|
最初のシーケンス番号はランダムな値で始まり、RTP パケットの送信毎に 1 つずつ増えます。リアルタイム アプリケーションは、この値を使用してパケット破棄の有無を判断し、適切なパケット順序を復元するために利用できます。
|
|
Timestamp
|
タイムスタンプ値は RTP パケットの最初のオクテットのサンプリングの瞬間を示します。サンプリングの周波数はデータ タイプに依存します。たとえば、Windows XP が G.711 音声コーデックを使用する場合、サンプリング周波数は 8 KHz に固定されます。
|
|
Synchronization source (SSRC)
|
SSRC 値はランダムに選択された値で、各 RTP セッションの RTP ストリームのソースを識別します。
|
|
Contributing source (CSRC)
|
CSRC 値は、RTP セッションに複数の提供ソースが存在することを示し、RTP ミキサーで各ソースの SSRC 値が CSRC 値に追加されます。
|
RTCP
RTCP パケットは、RTP セッションの品質に関する情報、およびセッションに参加している個人の情報が含まれます。送信者および受信者は、RTP セッションの各参加者に RTCP パケットを定期的に送信します。リアルタイム アプリケーションは、この情報を利用して RTP セッションの品質を監視することができます。たとえば、ジッタおよびパケット破棄を監視できます。
RTCP パケットには 5 つの種類があります。それぞれを表 13 に示します。
表
13 RTCP
パケット
タイプ
|
SR (Sender Report)
|
RTP セッションの品質に関する情報が含まれます。
|
|
RR (Receiver Report)
|
RTP セッションの品質に関する情報が含まれます。
|
|
SDES (Source Description)
|
RTP セッションの参加者の身元に関する情報が含まれます。
|
|
BYE (Goodbye)
|
1 つ以上のソースが RTP セッションを終了したことを示します。
|
|
APP (Application-defined)
|
新アプリケーションによる実験用。
|
RTP セッションの参加者は RR パケット タイプを送信して、アクティブな送信者の場合、SR パケット タイプを送信します。図 12 に示すように、RR パケットはヘッダーとレポート ブロックの 2 つのセクションから構成されます。各ソースに対して 1 つのレポート ブロックがあります。
|
RTCP RR パケット セクション
|
|---|
|
Header
|
|
Report Block 1
|
|
Report Block…n
|
図
12 RR
パケット構造
図 13 に示す SR パケットの構造は、20 バイトの送信者情報が含まれる点で RR パケットと異なります。
|
RTCP SR パケット セクション
|
|---|
|
Header
|
|
Sender Information
|
|
Report Block 1
|
|
Report Block…n
|
図
13: SR
パケット構造
Receiver Report
と
Sender Report
ヘッダー構造
図 14 に RR と SR のヘッダー構造を示します。この 2 つの相違点は、パケット タイプの値のみです。
.gif)
図
14: RTCP RR
と
SR
ヘッダー構造
|
Version
|
RTP のバージョン。Windows XP は Version 2 をサポートします。
|
|
Padding
|
"1" に設定された場合、ペイロードの末端に 1 つ以上のパディング オクテットが追加されていることを示します。最初のパディング オクテットに追加されたオクテットの数を示します。
|
|
Reception Report Count (RC)
|
RTCP パケットに含まれる reception ブロックの数を示します。
|
|
Packet Type
|
RTCP パケット タイプ。RR の値は 201 で SR の値は 200 です。
|
|
Length
|
RTCP パケットの長さを 32 ビット word-1 で示します。
|
|
SSRC
|
RTCP パケットの同期ソース識別子を含みます。
|
図 15 に SR パケットに含まれる追加の 20 バイトの送信者情報を示します。
.gif)
図
15: RTCP SR
情報
|
NTP Timestamp
|
NTP (Network Time Protocol) タイムスタンプまたは絶対現地時間が含まれます。現地時間が取得できない場合、送信者は RTP セッション参加後の経過時間を NTP Timestamp 値として使用できます。経過時間が使用される場合、上位ビットは 0 に設定されます。現地時間または経過時間が利用できない場合、NTP Timestamp 値は完全に 0 に設定されます。
|
|
RTP Timestamp
|
NTP Timestamp と同じ時刻が含まれます。ただし、RTP Timestamp は RTP パケットのヘッダーに含まれるタイムスタンプと同じ単位と同じランダムなオフセットが与えられます。
|
|
Sender痴 Packet Count
|
RTP セッションの開始後、この SR パケットが送信されるまでの総 RTP パケット数が含まれます。何らかの理由で送信者の SSRC 値が変更されるとこの値はリセットされます。
|
|
Sender痴 Octet Count
|
RTP セッションの開始後、この SR パケットが送信されるまでの総オクテット数が含まれます。何らかの理由で送信者の SSRC 値が変更されるとこの値はリセットされます。
|
レポート
ブロック構造
SR と RR パケットは、0 個以上のレポート ブロックを含むことができます。RTCP ヘッダーの直後に添付されるレポート ブロックは、受信者が最後にレポートを受け取ってから受信した RTP データ パケットに含まれる各 SSRC に対して 1 つずつ作成されます。
図 16 に示すように、SR と RR パケットのレポート ブロックの構造は同じです。
.gif)
図
16: RTCP
レポート
ブロック構造
|
SSRC_n
|
RTCP パケットに含まれる各レポート ブロックの同期ソース識別子を含みます。
|
|
Fraction Lost
|
最後に SR または RR パケットを送信してからソース (SSRC_n) から損失した RTP パケットの割合を含みます。
|
|
Cumulative Number of Packets Lost
|
セッション確立後、ソース (SSRC_n) から損失した RTP パケットの総数を含みます。この値は、RTP パケットのシーケンス番号から判断されます。シーケンス番号の欠番は破棄 RTP パケットと見なされます。
|
|
Extended Highest Sequence Number Received
|
このフィールドは 2 つの部分に分かれます。下位 16 ビットはソース (SSRC_n) から受け取った RTP パケットの最高シーケンス番号を含みます。上位 16 ビットはシーケンス番号サイクルの数を含みます。
|
|
Interarrival Jitter
|
RTP パケットの到着時間の差異の予測値が含まれます。この値は RTP タイムスタンプ単位で計測され、2 つのパケットの受信者と送信者のパケット間隔の差異から計算されます。
|
|
Last SR Timestamp (LSR)
|
ソース SSRC_n の最近の RTCP SR から取得した 64 ビット NTP タイムスタンプの中間 32 ビットが含まれます。
|
|
Delay Since Last SR (DLSR)
|
ソース SSRC_n から最後の SR パケットの受領、およびこの reception report ブロックの送信の時間差を含みます。このカウンタの 1 目盛りは 1/65536 秒を意味します。
|
RTP と RTCP は、パケットベースのネットワーク上のリアルタイム コミュニケーションに特化された設計ですが、サービス品質機構は用意されていません。サービス品質は下位のネットワークおよびデータリンク層に依存します。
音声品質テクノロジ
PSTN などの回線交換ネットワークは、2 つの端末間で専用の通信路を確保します。データグラムベースのパケット交換ネットワークは、元のデータを複数のパケットに分割して、そのパケットはそれぞれネットワーク上を別々のルートで転送されます。データグラムベースのパケット交換ネットワークで、専用の通信路や帯域確保は既定では行われません。これらの相違点やリアルタイム コミュニケーションは待ち時間が許容できない性質のため、パケット交換ネットワークでは、次の課題を解決しないと "課金が可能な品質" の音声転送を実現することはできません。
|
ジッタ
|
パケットの遅延時間の差異。音声転送は、データ転送と異なり、ジッタの影響を受けやすい性質です。パケットの送信と受信に大きな遅延が発生すると、不安定な、聞きづらい音声通信が発生してしまいます。
|
|
パケット破棄
|
パケットベースのネットワークは、回線交換ネットワークでの音声通信に比べて、パケット破棄の影響を受けやすい性質です。パケット破棄が大量に発生すると、音声品質は著しく劣化する可能性があります。
|
|
パケット順序
|
音声通信の性質上、受信パケットは送信元から送信されたのと同じ順序で処理される必要があります。
|
|
音響エコー
|
音響エコーは、音信号の反射です。音響エコーの出力または振幅、および元の信号と反射信号 (音響エコー) の間の遅延時間によって、エコーを確認できたり、うるさく感じるかどうかは決まります。
|
Windows XP は、ジッタ制御、音響エコー キャンセル、および QoS (Quality of Service) プロトコルなどのサービス品質機構を提供します。
ジッタ制御
RTP と RTCP は、リアルタイム コミュニケーション アプリケーションがセッション中にジッタの補正を行うためのタイムスタンプや到着ジッタ値などの情報を提供します。アプリケーションのジッタ バッファは、タイムスタンプおよび到着ジッタ値を使用して安定した、一定のパケット受信を行うために調整します。
アプリケーションは、RTP と RTCP パケットから取得した情報を使用して、2 つのパケットの転送時間の差異を計算します。次の計算が使用されます。
D(
n,n-1)=[R
(
n)
-S(
n
)]-[R
(
n-1)
-S(
n-1
)]
D(
n,n-1) がパケット n および n-1 の転送時間の違いで、S はパケット (n,n-1) が送信された時刻、R はパケット (n,n-1) が受信された時刻です。
転送時間の差異 D(
n,n-1), は、次の計算で使用され、RTP セッションの安定化を行うために到着パケット ジッタ J(
n) を求めます。詳細については RFC 1889「RTP: A Transport Protocol for Real-Time Communications」を参照してください。
J(
n)=J(
n-1)+(|D(
n,n-1)|- J(
n-1))/16
詳細については、http://www.microsoft.com/windows/reskits/webresources/ の「Web Resources page (英語)」で RFC 1889 を参照してください。
メモ
[Windows Messenger] および [
電話
] はジッタ バッファが組み込まれています。
音響エコー
キャンセラ
コンピュータで音声通話などのリアルタイム コミュニケーションを実行すると、音響エコーが発生する場合があります。別体式のマイクロホンとスピーカーではなく、統合されたマイクロホンとスピーカーが搭載されたヘッドセットを使用すると音響エコーの一部をなくすことができます。しかし、音響エコーをより制御するには、AEC (音響エコー キャンセラ) が必要です。
メモ Windows XP の [Windows Messenger] クライアントおよび Windows TAPI version 3.1 に音響エコー キャンセラが組み込まれています。
QoS (Quality of Service)
RTP と RTCP プロトコル、ジッタ制御機構、および音響エコー キャンセラはアプリケーションにリアルタイム コミュニケーションの品質を改善するための情報とツールを提供します。しかし、これらのプロトコルやテクノロジは、下位のネットワーク環境を制御することができません。Differentiated Services (Diff-Serv) および 802.1p などの IETF 定義プロトコルを採用した QoS は、下位のネットワーク環境を柔軟に制御して、あらゆるレベルのサービス品質を確保することができます。
メモ Windows XP は、QoS を利用できるすべてのアプリケーションをサポートします。これらのアプリケーションは、Windows XP の QoS API をコールするように設計されています。
音声品質の数値化
MOS (Mean Opinion Score) 値は、音声品質を客観的に測定、評価する手段を提供します。MOS 値は 1 ～ 5 の段階評価を採用し、1 が低品質、5 が高品質を意味します。"課金が可能な品質" とも呼ばれる PSTN 上の音声品質は、MOS 値で 4 ～ 5 に評価されます。
SIREN または G.722.1 など、16 KHz のサンプリング レートを使用する音声コーデックは約 4 の MOS 値を達成しています。しかし、コーデックの種類によってサンプリング レートが異なるため、ユーザー エクスペリエンスと MOS 値が一致しない場合があります。これらのコーデックはより広範囲の周波数をサンプリングすることで、より自然な音声を再現をできるため、より良好なユーザー エクスペリエンスを提供できます。PSTN ネットワーク上の音声通信よりも、パケットベースの IP ネットワーク上の音声通信がより良好な音声品質を提供できます。
メモ パケット交換ネットワーク上の音声通信は、"課金が可能な品質" を達成するには 200 ミリ秒 (ms) 以下の待ち時間を必要とします。しかし、200 ～ 400 ms 以内の遅延でも許容レベルの品質が可能です。遅延が 400 ms を超えると、音声通信は不可能になります。
図 17 に Windows XP がサポートする、8 KHz サンプリング レートを使用する音声コーデックの MOS 値を示します。
.gif)
表
17: Windows XP 8 KHz
サンプリング
レート音声コーデック
MOS
値
SIMPLE (SIP Instant Messaging and Presence Language Extensions)
SIMPLE (SIP Instant Messaging and Presence Language Extensions) により、ユーザーはリアルタイムのメッセージ (一般的にテキスト メッセージ) を送受信し、他のユーザーの状況を確認することができます。SIMPLE の汎用的なモデルは、RFC 2778「A Model for Presence and Instant Messaging」に定義されています。詳細については、http://www.microsoft.com/windows/reskits/webresources/ の「Web Resources page (英語)」で RFC 2778 を参照してください。
RFC 2778 に定義されている Instant Messaging モデルは、Instant Message Service と呼ばれるサーバーと、Sender または Instant Inboxes と呼ばれるクライアント間の通信を規定しています。メッセージが Sender クライアントから Instant Message Service に送信されると、Instant Message Service は Instant Inbox クライアントにメッセージを転送します。このようすを図 18 に示します。
.gif)
図
18: Instant Message
通信フロー
RFC 2778 は、情報交換にかかわるオブジェクトおよびその相互通信を規定しています。しかし、プレゼンス情報を伝えるため、およびインスタント メッセージング情報をやり取りするためのプロトコルが定義されていません。
RFC 2778 に定義されている Presence モデルは、Presence Service と呼ばれるサーバーと、Presentity または Watcher と呼ばれるクライアント間の通信を規定しています。Presentity は Presence Service にプレゼンス情報を提供し、Watcher は Presence Service からプレゼンス情報を取得します。
Fetcher および Subscriber という 2 種類の Watcher クライアントがあります。Fetcher は Presence Service から Presentity の現在のプレゼンス情報のみを要求します。Subscriber は、Presentity のプレゼンス情報が変わるとそれを通知することを要求します。図 19 に、プレゼンス クライアントの関係を示します。
.gif)
図
19:
プレゼンス
クライアント
SIP は、一部のプレゼンス情報を提供します。たとえば、SIP ユーザー エージェントが SIP 登録サーバーに登録すると、SIP ユーザー エージェントのプレゼンスまたは所在が SIP 登録サーバーから利用できます。このレベルのプレゼンス情報によって、SIP ベースの呼が可能になります。しかし、この方法ではある SIP ユーザー エージェントが他の SIP ユーザー エージェントのプレゼンス情報を得るためにサブスクライブすることはできません。
SIP に Presence および Instant Messaging の能力を追加するため、「SIP Extensions for Presence」および「SIP Extensions for Instant Messaging」の 2 つのインターネット ドラフトが作成されました。SIP プロトコルでプレゼンス能力を提供する SUBSCRIBE と NOTIFY という 2 つの新しい SIP メソッドが「SIP Extensions for Presence」ドラフトに含まれます。SIP プロトコルでインスタント メッセージング能力を提供する MESSAGE という SIP メソッドが「SIP Extensions for Instant Messaging」ドラフトに含まれます。SIP メソッドの詳細については、このドキュメントの前半の「SIP プロトコル」を参照してください。
まとめ
Microsoft のリアルタイム コミュニケーション プラットホームは、業界標準に基づき、音声および映像通信、インスタント メッセージング、アプリケーション共有、およびコラボレーションを含んだ企業でのマルチモーダル コミュニケーションを対象に設計されています。Windows XP は呼セッションの作成および終了を行う SIP、音声および映像信号をデジタル化して、効率的な転送のために圧縮、展開する各種コーデック、マルチメディア セッションを記述する SDP、および通信セッションを監視する RTP/RTCP をサポートします。さらに、Windows XP はパケット交換ネットワーク上での音声通信の品質を改善する音声品質テクノロジを含みます。また、SIMPLE をサポートすることで、Windows XP はプレゼンスおよびインスタント メッセージング能力も提供します。
関連情報
詳細情報については、次のリソースを参照してください。