...

(MMTel)サービス

by user

on
Category: Documents
9

views

Report

Comments

Transcript

(MMTel)サービス
第23章
マルチメディアテレフォニー
(MMTel)サービス
(PSTN/ISDNシミュレーションサービス)
第
23
章
ここまで、IMS はマルチメディアサービスと既存の通話サービスを実現できると説明してき
た。本章では、PSTN/ISDN の付加サービスとしてPSTN およびISDN 環境で提供される既
存の通話サービスについて説明する。なお、既存の付加サービスには自動転送、呼び出し保持
および通話の再開等が挙げられる。
また、IMS 環境下において、アプリケーションサーバ(AS)はマルチメディアテレフォニー
( M M T e l )サービスも提 供 することができる。 ただし、 S I P は呼 制 御 プロトコルであり
PSTN/ISDN のプロトコルとは異なっているので、PSTN/ISDN の付加サービスと同様の機
能を提供するものの、実現方法は全く異なる。ただし、PSTN/ISDN シミュレーションサー
ビスの目的はPSTN/ISDN と同様である。
PSTN/ISDN シミュレーションサービスの多くはサービスを提供できるAS を立てて展開さ
れ、通常サービス自体は単独のAS の中で帰結される。
そもそもPSTN/ISDN シミュレーションサービスは、IMS へ固定網を経由してアクセスす
るためのサービスとしてESTI TISPAN によって開発された。そして、TISPAN IMS が
3GPP と合併した際には、モバイルアクセスのために改良されマルチメディアをサポートする
IMS サービスとなった。
本章では、ほぼ同様の意味としてIMS マルチメディアサービスとPSTN/ISDN サービスを
使用している。これは、文書管理において3GPP TS24.173[36]では様々な関連サービ
スを統合しているためである。しかし、過去の経緯によりETSI ではPSTN/ISDN シミュレ
ーションサービスセットをETSI の仕様として記述されている。その後、このETSI で定義さ
れた仕様は3GPP へと移行した。この辺りの詳細については、3GPP TS24.173[36]を
参照して欲しい。
既存のPTSN/ISDN の付加サービスと互換性を持つことを目的として明確にした状態で、
PSTN/ISDN シミュレーションサービスは開発された。そして元来、PSTN/ISDN シミュレ
ーションサービスはIMS への固定系広帯域アクセス環境での利用を念頭に開発されたが、現
在ではワイヤレス機器を含むIMS の一機能となっている。
またPSTN/ISDN シミュレーションサービスは、PSTN/ISDN が持っていた様々な付加サ
ービスに基づき対応している。しかし、PSTN/ISDN シミュレーションサービスの名称の多
507
くは、IMS の中ではメッセージ、サブスクリプト、マルチメディアセッション等のようにSIP
で使用される名称を取り入れて変更されている。つまり、PSTN/ISDN シミュレーションサ
ービスの多くは呼処理だけではなく通信サービス自体を示すものとなったわけだ。
表 23.1 に、本章で解説するPSTN/ISDN シミュレーションサービスの概要を示す。右側
の「O/T」の列は、発着信のどちら側に提供されるサービスであるのかを示している(O が発
側で、T が着側)。
表 23.1
短縮形
第
Ⅲ
部
I
M
S
の
サ
ー
ビ
ス
508
IMSで提供されるPSTN/ISDNシミュレーションサービス
PSTN/ISDN
シミュレーションサービス
PSTN/ISDNサービス
サービス内容
O/T
CDIV
CFU
Communication Diversion
Communication Forwarding
Unconditional
Call Diversion
Call Forwarding
呼の転送
無条件着信転送
T
T
CFB
Communication Forwarding on
Busy user
Call Forwarding Busy
話中転送
T
CFNR
Communication Forwarding on
No Reply
Call Forwarding No Reply
無応答時着信転送
T
CFNL
Communication Forwarding on
Not Logged-in
─
非加入者転送
T
CONF
MWI
OIP
Conference
Message Waiting Indication
Originating Identification
Presentation
Conference Calling
Message Waiting Indication
Calling Line Identification
Presentation
会議通話
メッセージ受信インディケータ
発信者番号表示
O/T
T
T
OIR
Originating Identification
Restriction
Calling Line Identification
Restriction
発信者番号表示禁止
O
TIP
Terminating Identification
Presentation
Connected Line Identification
Presentation
接続先番号表示
O
TIR
Terminating Identification
Restriction
Connected Line Identification
Restriction
接続先番号表示禁止
T
CW
HOLD
ACR
Communication Waiting
Communication Hold
Anonymous Communication
Rejection
Call Waiting
Call Hold
Anonymous Call Rejection
T
O/T
T
CB
ICB
OCB
AoC
CCBS
Communication Barring
Incoming Communication Barring
Outgoing Communication Barring
Advice of Charge
Completion of Communications
to Busy Subscriber
Call Barring
Incoming Call Barring
Outgoing Call Barring
Advice of Charge
Completion of Calls
to Busy Subscriber
コールウェイティング
呼び出し保留
発信番号非通知
着信拒否
発着信の制限
着信制限
発信制限
料金通知
自動再呼び出し
O/T
T
O
O
O
CCNR
Completion of Communications
on No Reply
Completion of Calls
on No Reply
無応答時接続完了
O
MCID
Malicious Communication
Identification
Malicious Call Identification
悪意呼識別
T
ECT
Explicit Communication Transfer
Explicit Call Transfer
特定呼転送
O/T
第23章 マルチメディアテレフォニー(MMTel)サービス(PSTN/ISDNシミュレーションサービス)
23.1
音声ガイダンスサービス
表 23.1で示した様々なマルチメディア通信サービスについて言及する前に、これらのサービ
スでしばしば使用されている共通のメカニズムについて説明しておこう。このメカニズムとは、
PSTN/ISDNサービスから引き継がれている音声ガイダンスを伴ったサービスであり、このガイ
ダンスによってユーザへのフィードバックを行う。IMSでは、電話のディスプレイにWebページ
のような表示をすることでインスタントメッセージを送信するように、他のメカニズムを使用す
第
23
章
ることがある。しかし、IMSにとって最小限の機能は、ガイダンスを提供することである。本章
では、この音声ガイダンスを提供するメカニズムについて解説する。そしてこれから説明するマ
ルチメディア通話サービスの多くは、この音声ガイダンスを利用することができる。
音声ガイダンスを提供する手順についてはETSI TS183 028[142]、あるいは3GPP TS24.628
[60]で規定されている。音声ガイダンスは、セッションが確立している間、もしくは解放され
ている間のいずれの場合にも利用することができ、その手順はそれぞれ場合で少し異っている。
また、セッションの確立を拒否する際に音声ガイダンスを送ることもできる。
23.1.1
セッション確立時の音声ガイダンス
セッションが確立されている時に提供される音声ガイダンスには、4つの方法がある。
(i) 音声ガイダンスが聞き取り側でレンダリング(創出)される場合:INVITEリクエストにおけ
るCall-Informationヘッダフィールドに含まれているURLをユーザへ提供する。
(ii)音声ガイダンスが聞き取り側でレンダリングされる場合:Alert-Infoヘッダフィールド
は180(Ringing)レスポンスに格納され、Alert-Infoヘッダには音声ガイダンスの提供
元を特定するSIP URIあるいはHTTP URIを含むため、Alert-Infoヘッダに含まれてい
るURLをユーザへ提供する。
(iii)P-Early-Mediaヘッダフィールド(RFC 5009[128])に関連してRFC 3960[111]で定義
されたゲートウェイモデルにアーリーメディアを使用する。
(iv)P-Early-Mediaヘッダフィールド(RFC 5009[128])に関連してRFC 3960[111]で記述
されているようなアーリーダイアログにアーリーメディアを使用する。
上記(iv)における全体的な効果としては、セッションが確立されている際は、聞き取り側が
アーリーダイアログを保持していることで成立することになる。その際、ダイアログの1つは聞
き取り側と音声ガイダンス提供側との間で確立され、もう1つのダイアログは聞き取り側とAS
との間で確立される。そしてASは、アーリーダイアログで確立されたプレセッションに一方的
にアーリーメディアを送信することができる。
図 23.1は、Call-Infoヘッダフィールドを利用したメカニズムによって音声ガイダンスが
送信された場合について示したものである。なおこの場合は、S-CSCFとASは聞き取り側、あ
るいは音声ガイダンス提供側のどちらかの同一のネットワーク内に揃って位置している必要が
ある。まず、S-CSCFがイニシャルフィルタクライテリアの評価のためにASへ送信されるINVITE
23.1 音声ガイダンスサービス
509
iFCの評価
ローカルで
ann.wavを再生
第
Ⅲ
部
通常手順でセッションセットアップを続行
I
M
S
の
サ
ー
ビ
ス
図 23.1
着信側がアナウンスに Call-Info ヘッダフィールドを使用した場合
リクエストを受信すると(①)音声ガイダンス送信処理が始まる。ASは保持しているファイルを
示すHTTPリンクを含んでいるprotoCall-Infoヘッダフィールドを、このINVITEリクエス
トに挿入する。次に、ASは通常通りS-CSCFへINVITEリクエストを送信し(⑤)、S-CSCFはこ
のリクエストを聞き取り側へ転送する(⑦)。受信した聞き取り側は、INVITE リクエストの
Call-Infoヘッダフィールドに含まれているURLを呼び出す。その際聞き取り側はHTTP GET
リクエストによる、音声ガイダンスファイルを取得するためのリクエストも送信する。そして、
音声ガイダンスファイルは200(OK)レスポンスによって送出される(⑩)。音声ガイダンス提供
側はユーザに180(Ringing)レスポンスを送信し、ユーザに伝えるべき音声ガイダンスが届けて
いる旨を通知する。以降のセッションセットアップは通常の手順によって処理される。
図 23.2はAlert-Infoヘッダフィールドを使って音声ガイダンスの送信が提供される場合
について示したものである。S-CSCFとASは聞き取り側か音声ガイダンス提供側のどちらかのネ
ットワークになければならない。S-CSCF(①)がイニシャルフィルタクライテリアの評価(③)を
ASに送信するためのINVITEリクエストを受信すると音声ガイダンス送信処理が開始する。AS
が通常のルーティングを実行し、S-CSCFへINVITEリクエストを送信し(⑤)、S-CSCFはINVITE
リクエストを聞き取り側へ送信する(⑦)。音声ガイダンス提供側は180(Ringing)レスポンスを
送信し(⑨)
、これは最終的にはASで受信される(⑩)
。そしてASはS-CSCFと聞き取り側へ、保
510
第23章 マルチメディアテレフォニー(MMTel)サービス(PSTN/ISDNシミュレーションサービス)
iFCの評価
第
23
章
ローカルの
ann.wavを再生
通常手順でセッションセットアップを続行
図 23.2 発信側が Alert-Info ヘッダフィールドを使用する場合
持している音声ガイダンスファイルへのHTTPリンクを含むAlert-Infoヘッダフィールドを
加えて180(Ringing)レスポンスを送信する(⑪、⑫)。次に聞き取り側は180(Ringing)レスポ
ンスのAlert-Infoヘッダフィールドに含まれていたURIを呼び出す。つまり、Alert-Info
ヘッダフィールドに基づき、HTTP GETリクエストを送信する(⑬)。聞き取り側は呼び出し音
としてセッションセットアップまで(INVITEリクエストに対する200(OK)レスポンスを受け取
るまで)音声ガイダンスを流す。
図 23.3はセッションが確立される際に音声ガイダンスを提供するメカニズムの一例を示した
ものである。このフロー例ではアーリーメディアを使用し、聞き取り側あるいは音声ガイダンス
提供側のどちらかで使用できるASがあると仮定する。S-CSCFが聞き取り側か音声ガイダンス
提供側のネットワークで新規セッションを確立するためのINVITEリクエストを受信すると(①)、
処理が始まる。まずイニシャルフィルタクライテリアの評価のため、S-CSCFはINVITEリクエ
ストをASへ送信することになる(③)。この際にASはMRFと共に音声ガイダンスを流すことを
決定する。ASは音声ガイダンスを提供するためにMRFCと連動し、MRFCはアーリーダイアロ
グのための接続先アドレスを通知するためにMRFPと連動する(⑤)。そしてMRFCはMRFPの
接続パラメータにSDPを含む183(Session Progress)レスポンスを送信する(⑥)。なお、この
183レスポンスは、許可されたアーリーメディアがsend-onlyモードで送信されることを示す
23.1 音声ガイダンスサービス
511
Fly UP