メインコンテンツへジャンプする

JPNICはインターネットの円滑な運営を支えるための組織です
文字サイズ:

ニュースレターNo.29/2005年3月発行

インターネット10分講座:VoIPとSIP

今回の10分講座では、VoIPを支える基盤技術であるSIPとその動向について解説します。

SIPとは

今回紹介するSIP(Session Initiation Protocol)は、アプリケーション層で2つ以上の相手に対して、音声や映像、テキストメッセージの交換などを行うために必要なセッションの生成・変更・切断を行うプロトコルです。

SIPは、リアルタイム通信のためのプロトコルの本命とされており、IP電話、テレビ電話、ビデオチャット、テレビ会議、インスタントメッセンジャーなど様々なリアルタイム性が要求されるアプリケーションで採用が進んでいます。

VoIPとSIP関係

VoIP(Voice Over IP)は、インターネット上で音声のやりとりを行うための技術です。最近普及の進んでいるIP電話は、従来の電話に相当するものを、VoIPとシグナリングを組み合わせてインターネット上で実現したものです。

シグナリングとは、電話で言うならば、呼制御のことで、発信者と着信者間の公衆電話交換網(電話交換機のネットワーク)上で、通信路の確保や切断等の処理を指します。同様に、IP電話におけるシグナリングは、インターネット上で音声を交換するためのセッションを確立するために必要となります。 IP電話で利用可能なシグナリングには、複数の手法が存在します。その代表例として、ITU-T(International Telecommunication Union-Telecommunication sector)が、1997年に勧告したH.323※1があります。

H.323は、大まかにシグナリング以外に、音声・映像の送受信、音声・映像コーデック等も定めています。登場してからの成熟期間があり、テレビ会議システムやIP電話など多くの製品がH.323をベースに実装されました。

H.323は、音声・映像通信を行うために広範囲なサポートが可能なプロトコルであった反面、プロトコルがバイナリ記述であったり、データ構造がASN.1(Abstract Syntax Notation One)※2を利用するなど、その処理は複雑です。

一方、SIPは、IETF(Internet Engineering Task Force)で標準化が行われ、1999年に初版が登場し、2002年に発行されたRFC3261※3において、スタンダードトラックとして規定されました。SIPにおけるメッセージは、テキストで記述され、また、HTTPやSMTPを例に設計されたため、シンプルで拡張性が高く、インターネットと親和性が高いと言われています。そのため、実装は、H.323に比べ容易となり、IP電話で用いられるシグナリング・プロトコルは、H.323やその他の独自ベンダープロトコルから、SIPへ統合されつつあります。

SIPの基本

SIPを規定するRFC3261は、269ページに及ぶ非常に厚みのあるRFCです。それだけ、膨大な規定が必要になるということを示しています。ここでは、そのすべてをご紹介することはできませんので、概要を述べるにとどめます。

SIPは、端末(User Agent:UA)間でセッションの生成、変更、切断を行うのみのプロトコルで、セッション上で交換されるデータそのものについては定めていません。従って、アプリケーションが、SIPによって制御されたセッション上で、音声のやりとりを行えばIP電話、音声と映像ならばテレビ電話、テキストメッセージならばインスタントメッセンジャーというように幅広い応用が可能となります。

次に、例としてAliceがBobへIP電話をかける場合を想定して、そのセッションの過程を概観します。ここで出てくる機器は、AliceとBobのIP電話機(=UA)、各IP電話機の収容するSIPプロキシサーバA(atlanta.com)とB(biloxi.com)です。SIPプロキシサーバは、公衆電話交換網で言うならば、交換機のようなもので、UAやプロキシからのリクエストを受け取り、適切なUA、プロキシへ送信を行います。

通話開始から終了までにおけるやりとりは、図1のようになります。

IP電話セッション確立から切断までの例
図1: IP電話セッション確立から切断までの例(参考:RFC3261)

セッションの確立は、INVITE(招待)メッセージ送信から始まります。SIPにおけるUAの識別は、sip:alice@atlanta.com、sip:bob@biloxi.comのようにURI(Uniform Resource Identifier)形式で行い、AliceはBobとのセッション確立のために、sip:bob@biloxi.comへINVITEメッセージを送信します(図1-1)。

図2は、AliceからBobへのINVITEメッセージの例です。

INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142
図2: INVITEメッセージの例 (RFC3261より引用)

このメッセージ形式からわかるように、SIPではアスキーで記述されているため、メッセージの内容を可読できます。そして、形式がHTTPやSMTPに似ているため、容易に内容を理解できます。

INVITEを受信したプロキシAでは、宛先が、bob@ biloxi.comであることから、biloxi.comのプロキシBへINVITEメッセージを送信します(図1-2)。また、プロキシAは、Aliceへ「プロキシBへのINVITEを実行中である」ことを通知する暫定応答100Tryingを送信します(図1-3)。

この「100」とは、要求に対する結果を示すステータスコードで、図3に示すようにHTTPで定めたステータスコードを拡張した仕様となっています。

1xx: 暫定応答 要求への処理を実施中
2xx: 成功 要求が正しく受け入れられ、理解、承認されました。
3xx: リダイレクト 要求を完了させるためにさらなる処理が必要
4xx: クライアントエラー 要求の構文が誤っている、要求の実行ができない
5xx: サーバエラー サーバ上でのエラー
6xx: グローバルな失敗 要求はどんなサーバにおいても処理できなかった。
図3: ステータスコード

プロキシBは、受信したINVITE(図1-2)から、配下のBobへINVITEを送信します(図1-4)。

INVITEを受信したBobは、電話のベルを鳴らすなど相手からの呼び出し処理を行い、併せて、発信元(Alice)へ呼び出し中であることを伝えるため、暫定応答180RingingをプロキシBへ応答し、180 Ringingは、Aliceへ転送されます(図1-6、7、8)。

Bobは、受話器のオフフック(受話器をあげる)などによって、成功200OKをプロキシB/Aを経由してAに送信します(図1-9、10、11)。

Aliceは、Bobからの200OKを元にACK応答(セッション確立了解)をBobへ送信し(図1-12)、AliceとBobの間にセッションが生成されます。生成されたセッション上で、音声データがやりとりされ、通話状態となります。

そして、Bob上の受話器がオンフックとなったとき、BYE要求(セッション切断要求)と200OK応答によって、セッションが終了し、通話が終了します(図1-13、14)。

以上に簡単ではありますが、SIPの概要を説明致しました。

SIPのシグナリングは、シンプルで、また、HTTPやSMTPに似ていることから、理解しやすく、実装もしやすいことがお分かりいただけたかと思います。

今回紹介したのは、SIPのほんの一部の部分です。このほかにも、様々な仕組みが存在します。興味のある方は、RFCなど文献をご参照ください。

SIPと相互接続性

さて、IP電話へ普及が進むSIPですが、ここでは、その相互接続性について述べます。

昨今、企業内でのVoIP化や、ブロードバンドの普及に伴うコンシューマー市場におけるVoIP化によって、種々のVoIP端末(UA)が登場してきています。その普及に従って、VoIP機器同士の相互接続性が問題となっています。

一般的に考えて、IETFが標準化したプロトコルであるSIPを実装したIP電話やサーバ(VoIP交換機)間ならば、相互接続が可能であると考えるでしょう。しかしながら、現状、残念なことに相互接続がうまくいかない場合があります。

VoIP機器は、登場当初から、閉じたシステムである傾向が強かったため、サーバ(VoIP交換機)とIP電話機がセットで開発され、独自拡張などが施される場合もあります。また、ベンダー毎にURIの表記方法が異なっていたり、RFCが厳密に定義していない点などが影響して、SIPに対応した製品同士やVoIP事業者同士の相互接続が保証できていません。

この問題点を解決するために、規格面・実装面からの相互接続性の実現に向けての活動が行われています。規格面では、(社)情報通信技術委員会(TTC)※4が、相互接続に必要な仕様の策定をしています。実装面では、(社)テレコムサービス協会 VoIP推進協議会 相互接続WG※5や高度通信システム相互接続推進会議※6において、ベンダー間(端末とサーバ)の相互接続性の検証が行われており、VoIP/SIP相互接続検証タスクフォース※7においては、VoIP事業者間における相互接続の検証が進められています。

各所における相互接続検証活動を通して、問題は解決方向にむかっていっているといえます。

まとめ

VoIPは、インターネット上で重要な位置を占めつつあり、今後も普及が進んでいくでしょう。SIPの普及に伴い、問題となっている相互接続性の問題も、種々の活動を通して、一歩一歩解決にむけて進んでいます。

これからもVoIPとSIP技術は、市場の成長と共に成熟が進み、おもしろくなっていくことが予想されます。その動向に今後も目が離せません。

(大江将史)

※1 ITU-T recommendation「H.323」
http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-REC-H.323
※2 ASN.1(Abstract Syntax Notation One)
ASN.1は、データの型や順序といった概念を表現することができる書式で、OSI のX.680で標準化されている。OSI標準のプロトコルで、データ形式を記述するために使われていたが、今ではIETFのRFCでも多く使われている。
※3 Handley, M., Schooler, E., and H. Schulzrinne, "Session Initiation Protocol(SIP)"
http://www.ietf.org/rfc/rfc3261.txt
※4 (社)情報通信技術委員会
http://www.ttc.or.jp/
※5 (社)テレコムサービス協会
http://www.telesa.or.jp/
※6 高度通信システム相互接続推進会議
http://www.ciaj.or.jp/hats/
※7 VoIP/SIP相互接続検証タスクフォース
http://www.nic.ad.jp/ja/voip-sip-tf/

このページを評価してください

このWebページは役に立ちましたか?
ページの改良点等がございましたら自由にご記入ください。

このフォームをご利用した場合、ご連絡先の記入がないと、 回答を差し上げられません。 回答が必要な場合は、お問い合わせ先をご利用ください。