(57)【要約】【課題】初期セッション開設手続でセッション参加を応答したクライアント情報をトークバスト制御信号に含んで伝達することによって、トラフィック負担を低減し、モバイル環境に適合した環境をＰｏＣネットワークに提供する。【解決手段】本発明に係るプッシュ・トゥ・トーク・オーバー・セルラー（Ｐｕｓｈ−ｔｏ−ｔａｌｋ ｏｖｅｒ Ｃｅｌｌｕｌａｒ：ＰｏＣ）網のセッションに参加する応答者の情報を転送する方法は、送信側ＰｏＣサーバが送信側ＰｏＣクライアントの通話要請メッセージを受信側ＰｏＣサーバに送信する段階と、前記送信側ＰｏＣサーバが前記通話要請メッセージに対する受信側ＰｏＣクライアントからの応答メッセージを受信する段階と、前記送信側ＰｏＣクライアントが前記応答メッセージを送信した受信側ＰｏＣクライアントの情報が含まれたメッセージを前記送信側ＰｏＣサーバから受信する段階と、を備えることを特徴とする。【選択図】図５
2006287940.tif 000002
【特許請求の範囲】
【請求項１】
プッシュ・トゥ・トーク・オーバー・セルラー（Ｐｕｓｈ−ｔｏ−ｔａｌｋ ｏｖｅｒ Ｃｅｌｌｕｌａｒ：ＰｏＣ）網のセッションに参加する応答者の情報を転送する方法であって、
送信側ＰｏＣサーバが送信側ＰｏＣクライアントの通話要請メッセージを受信側ＰｏＣサーバに送信する段階と、
前記送信側ＰｏＣサーバが前記通話要請メッセージに対する受信側ＰｏＣクライアントからの応答メッセージを受信する段階と、
前記送信側ＰｏＣクライアントが前記応答メッセージを送信した受信側ＰｏＣクライアントの情報が含まれたメッセージを前記送信側ＰｏＣサーバから受信する段階と、を備えることを特徴とする前記方法。
【請求項２】
前記通話要請メッセージに対する応答メッセージは、セッション連結に対する成功的な応答メッセージであることを特徴とする請求項１に記載の前記方法。
【請求項３】
前記成功的な応答メッセージは、ＳＩＰ応答メッセージの２ｘｘのうちいずれか１つであることを特徴とする請求項２に記載の前記方法。
【請求項４】
任意の受信側ＰｏＣクライアントから成功的な応答メッセージを受信する場合、前記送信側ＰｏＣサーバは、受信側応答ＰｏＣクライアントの情報を含むトークバスト制御プロトコル（ＴＢＣＰ）信号を前記送信側ＰｏＣクライアントに転送することを特徴とする請求項２に記載の前記方法。
【請求項５】
前記応答メッセージは、実時間転送制御プロトコル（ＲＴＣＰ）アプリケーション（ＲＴＣＰ ＡＰＰ）パケットのペイロード形態を取ることを特徴とする請求項４に記載の前記方法。
【請求項６】
前記ＲＴＣＰ ＡＰＰパケットは、少なくとも１つの一般転送関連情報フィールドを含むことを特徴とする請求項５に記載の前記方法。
【請求項７】
前記少なくとも１つの一般転送関連情報フィールドは、バージョンフィールド、サブタイプフィールド、パケットタイプフィールド、パケット長さフィールド、応答者の識別子フィールド、開設されたＰｏＣ群フィールド、セッションの識別子フィールド、受信側クライアントの応答種類フィールド、受信側ＰｏＣクライアントの応答内容フィールドを含むことを特徴とする請求項６に記載の前記方法。
【請求項８】
前記ＲＴＣＰ ＡＰＰパケットは、応答者の識別子と前記応答者の応答種類を示すフィールドを含むことを特徴とする請求項５に記載の前記方法。
【請求項９】
前記ＰｏＣ通話要請メッセージに対する応答メッセージは、セッション連結エラー応答メッセージであることを特徴とする請求項１に記載の前記方法。
【請求項１０】
前記受信側ＰｏＣクライアントから応答メッセージを受信した場合、前記送信側ＰｏＣサーバは、発言権許諾信号と受信側応答ＰｏＣクライアントの情報を含むトークバスト制御プロトコル（ＴＢＣＰ）信号を送信側ＰｏＣクライアントに転送することを特徴とする請求項１に記載の前記方法。
【請求項１１】
プッシュ・トゥ・トーク・オーバー・セルラー（Ｐｕｓｈ−ｔｏ−ｔａｌｋ ｏｖｅｒ Ｃｅｌｌｕｌａｒ：ＰｏＣ）網のセッションに参加する応答者の情報を転送する方法であって、
ＰｏＣ網セッションを管理するＰｏＣサーバが送信側ＰｏＣクライアントの通話要請メッセージを受信側ＰｏＣサーバに送信する段階と、
前記ＰｏＣサーバが前記通話要請メッセージに対する受信側ＰｏＣクライアントからの応答メッセージを受信する段階と、
前記送信側ＰｏＣクライアントが前記応答メッセージを送信したクライアントの情報が含まれたメッセージを前記ＰｏＣサーバから受信する段階と、を備えることを特徴とする前記方法。
【請求項１２】
プッシュ・トゥ・トーク・オーバー・セルラー（Ｐｕｓｈ−ｔｏ−ｔａｌｋ ｏｖｅｒ  Ｃｅｌｌｕｌａｒ：ＰｏＣ）網のセッションに参加する応答者の情報を転送するＰｏＣシステムであって、
受信側ＰｏＣシステムにセッション通話要請メッセージを送信する送信側ＰｏＣクライアントと、
前記通話要請メッセージに対する応答メッセージを受信する送信側ＰｏＣサーバと、を備え、
前記送信側ＰｏＣクライアントは、応答メッセージを送信した受信側ＰｏＣクライアントの情報を含むメッセージを前記送信側ＰｏＣサーバから受信することを特徴とする前記ＰｏＣシステム。
【請求項１３】
前記送信側ＰｏＣクライアントの通話要請メッセージに対する応答メッセージは、セッション連結に対する成功的な応答メッセージを含むことを特徴とする請求項１２に記載の前記システム。
【請求項１４】
前記成功的な応答メッセージは、２ｘｘのＳＩＰ応答メッセージを含むことを特徴とする請求項１３に記載の前記システム。
【請求項１５】
前記受信側ＰｏＣクライアントによる応答メッセージの場合、前記送信側ＰｏＣサーバは、受信側応答ＰｏＣクライアントの情報を含むトークバスト制御プロトコル（ＴＢＣＰ）信号を前記送信側ＰｏＣクライアントに送信することを特徴とする請求項１３に記載の前記システム。
【請求項１６】
前記ＴＢＣＰ信号は、実時間転送制御プロトコル（ＲＴＣＰ）アプリケーション（ＲＴＣＰ ＡＰＰ）パケットのペイロードに含まれることを特徴とする請求項１５に記載の前記システム。
【請求項１７】
前記ＲＴＣＰ ＡＰＰパケットは、少なくとも１つの一般転送関連情報フィールドを含むことを特徴とする請求項１６に記載の前記システム。
【請求項１８】
前記少なくとも１つの一般転送関連情報は、
バージョンフィールド、
サブタイプフィールド、
パケットタイプフィールド、
パケット長さフィールド、
応答者の識別子フィールド、
開設されたＰｏＣ群フィールド、
セッションの識別子フィールド、
受信側ＰｏＣクライアントの応答種類フィールド、及び
受信側ＰｏＣクライアントの応答内容フィールドのうち少なくとも１つを含むことを特徴とする請求項１６に記載の前記システム。
【請求項１９】
前記ＲＴＣＰ ＡＰＰパケットは、応答者の識別子と前記応答者による応答種類を示すフィールドを含むことを特徴とする請求項１６に記載の前記システム。
【請求項２０】
前記受信側ＰｏＣクライアントの通話要請メッセージに対する応答メッセージは、セッション連結エラー応答メッセージであることを特徴とする請求項１２に記載の前記システム。
【請求項２１】
前記送信側ＰｏＣクライアントの通話要請メッセージに対する応答メッセージは、前記受信側ＰｏＣクライアントに転送され、前記送信側ＰｏＣサーバは、受信側応答ＰｏＣクライアントの情報と一緒に発言権許諾信号を含むトークバスト制御プロトコル（ＴＢＣＰ）信号を送信側ＰｏＣクライアントに転送することを特徴とする請求項１２に記載の前記システム。
【請求項２２】
プッシュ・トゥ・トーク・オーバー・セルラー（Ｐｕｓｈ−ｔｏ−ｔａｌｋ ｏｖｅｒ Ｃｅｌｌｕｌａｒ：ＰｏＣ）網のセッションに参加する応答者の情報を転送するＰｏＣシステムであって、
受信側ＰｏＣシステムにセッション通話要請メッセージを送信する送信側ＰｏＣクライアントと、
セッションを全般的に管理し、前記通話要請メッセージに対する応答メッセージを受信するＰｏＣサーバと、を備え、
前記送信側ＰｏＣクライアントは、応答メッセージを送信した受信側ＰｏＣクライアントの情報を含むメッセージを前記ＰｏＣサーバから受信することを特徴とする前記ＰｏＣシステム。
【請求項２３】
プッシュ・トゥ・トーク・オーバー・セルラー（Ｐｕｓｈ−ｔｏ−ｔａｌｋ ｏｖｅｒ Ｃｅｌｌｕｌａｒ：ＰｏＣ）網のセッションに参加する応答者の情報を転送するＰｏＣサーバであって、
送信側ＰｏＣクライアントの通話要請メッセージに対する応答メッセージが受信側ＰｏＣクライアントに伝達され、セッションが連結されれば、
応答メッセージを送信した受信側ＰｏＣクライアントの情報が含まれたメッセージを送信側ＰｏＣクライアントに提供することを特徴とするＰｏＣサーバ。
【請求項２４】
前記送信側ＰｏＣクライアントの通話要請メッセージに対する応答メッセージは、セッション連結に対する成功的な応答メッセージを含むことを特徴とする請求項２３に記載の前記ＰｏＣサーバ。
【請求項２５】
前記成功的な応答メッセージは、２ｘｘのＳＩＰ応答メッセージを含むことを特徴とする請求項２４に記載の前記ＰｏＣサーバ。
【請求項２６】
前記受信側ＰｏＣクライアントによるセッション連結に対する成功的な応答メッセージを受信した場合、前記ＰｏＣサーバは、受信側応答ＰｏＣクライアントの情報を含むトークバスト制御プロトコル（ＴＢＣＰ）信号を前記送信側ＰｏＣクライアントに送信することを特徴とする請求項２４に記載の前記ＰｏＣサーバ。
【請求項２７】
前記ＴＢＣＰ信号は、実時間転送制御プロトコル（ＲＴＣＰ）アプリケーション（ＲＴＣＰ ＡＰＰ）パケットのペイロードに含まれることを特徴とする請求項２６に記載の前記ＰｏＣサーバ。
【請求項２８】
前記ＲＴＣＰ ＡＰＰパケットは、少なくとも１つの一般転送関連情報フィールドを含むことを特徴とする請求項２７に記載の前記ＰｏＣサーバ。
【請求項２９】
前記少なくとも１つの一般転送関連情報は、
バージョンフィールド、
サブタイプフィールド、
パケットタイプフィールド、
パケット長さフィールド、
応答者の識別子フィールド、
開設されたＰｏＣ群フィールド、
セッションの識別子フィールド
受信側ＰｏＣクライアントの応答種類フィールド、及び
受信側ＰｏＣクライアントの応答内容フィールドのうち少なくとも１つを含むことを特徴とする請求項２８に記載の前記ＰｏＣサーバ。
【請求項３０】
前記ＲＴＣＰ ＡＰＰパケットは、応答者の識別子と前記応答者による応答種類を示すフィールドを含むことを特徴とする請求項２７に記載の前記ＰｏＣサーバ。
【請求項３１】
前記送信側ＰｏＣクライアントの通話要請メッセージに対する応答メッセージは、セッション連結に対するエラー応答メッセージを含むことを特徴とする請求項２３に記載の前記ＰｏＣサーバ。
【請求項３２】
前記送信側ＰｏＣクライアントの通話要請メッセージに対する応答メッセージが前記受信側ＰｏＣクライアントに転送される場合、前記ＰｏＣサーバは、受信側応答ＰｏＣクライアントの情報と発言権許諾信号を含むトークバスト制御プロトコル（ＴＢＣＰ）信号を前記送信側ＰｏＣクライアントに送信することを特徴とする請求項２３に記載の前記ＰｏＣサーバ。
【請求項３３】
プッシュ・トゥ・トーク・オーバー・セルラー（Ｐｕｓｈ−ｔｏ−ｔａｌｋ ｏｖｅｒ Ｃｅｌｌｕｌａｒ：ＰｏＣ）網のセッションに参加する応答者の情報を提供されるＰｏＣクライアントが転送する方法であって、
受信側ＰｏＣシステムに通話要請メッセージを送信し、
前記通話要請メッセージに対する受信側ＰｏＣクライアントからの応答メッセージが送信側ＰｏＣサーバに転送されれば、前記応答メッセージを送信した受信側ＰｏＣクライアントのセッション連結情報を含むメッセージを前記送信側ＰｏＣサーバから受信することを特徴とする前記転送方法。
【請求項３４】
前記通話要請メッセージに対する応答メッセージは、セッション連結に対する成功的な応答メッセージを含むことを特徴とする請求項３３に記載の前記転送方法。
【請求項３５】
前記成功的な応答メッセージは、２ｘｘのＳＩＰ応答メッセージを含むことを特徴とする請求項３４に記載の前記転送方法。
【請求項３６】
前記通話要請メッセージに対する応答メッセージを受信側ＰｏＣクライアントから受信する場合、前記ＰｏＣクライアントは、受信側応答ＰｏＣクライアントの情報を含むトークバスト制御プロトコル（ＴＢＣＰ）信号を送信側ＰｏＣサーバから転送することを特徴とする請求項３４に記載の前記転送方法。
【請求項３７】
前記ＴＢＣＰ信号は、実時間転送制御プロトコル（ＲＴＣＰ）アプリケーション（ＲＴＣＰ ＡＰＰ）パケットのペイロードに含まれることを特徴とする請求項３６に記載の前記転送方法。
【請求項３８】
前記ＲＴＣＰ ＡＰＰパケットは、少なくとも１つの一般転送関連情報フィールドを含むことを特徴とする請求項３７に記載の前記転送方法。
【請求項３９】
前記少なくとも１つの一般転送関連情報フィールドは、バージョンフィールド、サブタイプフィールド、パケットタイプフィールド、パケット長さフィールド、応答者の識別子フィールド、開設されたＰｏＣ群フィールド、セッションの識別子フィールド、受信側ＰｏＣクライアントの応答種類フィールド、及び受信側ＰｏＣクライアントの応答内容フィールドを含むことを特徴とする請求項３８に記載の前記転送方法。
【請求項４０】
前記ＲＴＣＰ ＡＰＰパケットは、応答者の識別子と前記応答者による応答種類を示すフィールドを含むことを特徴とする請求項３７に記載の前記転送方法。
【請求項４１】
前記通話要請メッセージに対する応答メッセージが前記受信側ＰｏＣクライアントに転送される場合、前記ＰｏＣクライアントは、受信側応答ＰｏＣクライアントの情報と発言権許諾信号を含むトークバスト制御プロトコル（ＴＢＣＰ）信号を前記送信側ＰｏＣクライアントに送信することを特徴とする請求項３３に記載の前記転送方法。
【請求項４２】
前記通話要請メッセージに対する応答メッセージは、セッション連結に対するエラー応答メッセージを含むことを特徴とする請求項３３に記載の前記転送方法。
【請求項４３】
プッシュ・トゥ・トーク・オーバー・セルラー（Ｐｕｓｈ−ｔｏ−ｔａｌｋ ｏｖｅｒ Ｃｅｌｌｕｌａｒ：ＰｏＣ）網のセッションに参加する応答者の情報を提供されるＰｏＣクライアントが受信する方法であって、
受信側ＰｏＣシステムに通話要請メッセージを送信し、
前記通話要請メッセージに対する受信側ＰｏＣクライアントからの応答メッセージがセッションを管理するＰｏＣサーバに転送されれば、前記応答メッセージを送信した受信側ＰｏＣクライアントのセッション連結情報を含むメッセージを前記ＰｏＣサーバから受信することを特徴とする前記受信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、モバイル環境に適合するように無線接続区間などでトラフィック負担を低減し、且つ効率的な群通話情報を伝達できるようにするためのＰｏＣ（Ｐｕｓｈ−ｔｏ−ｔａｌｋ ｏｖｅｒ Ｃｅｌｌｕｌａｒ）通話技術に関し、特にＰｏＣ群に参加するＰｏＣユーザのセッション参加情報を伝達する方法及びシステムに関する。
【背景技術】
【０００２】
移動通信の画期的な発展と通信網の拡大に伴って、携帯電話を用いたサービスやアプリケーションがさらに拡張され多様化されている。また、ユーザの要求も多様化され、単純な通話サービスから脱皮し、位置サービス、マルチメディアサービス、ＰＴＴサービスなどに拡大されている。特にＰＴＴサービスは、従来無電機やＴＲＳなどで可能であった群通話と音声通話はもちろん、インスタントメッセンジャー、状態表示など多様な付加機能を支援する。
【０００３】
現在、このようなＰＴＴ（Ｐｕｓｈ Ｔｏ Ｔａｌｋ）概念を移動通信網を用いてサービスするＰｏＣ（Ｐｕｓｈ−ｔｏ−ｔａｌｋ ｏｖｅｒ ｃｅｌｌｕｌａｒ：以下、ＰｏＣという）サービスに対する標準制定が活発に論議されている。既存の移動通信サービスと区別されるＰｏＣサービスの特徴のうち１つは、ユーザが複数のセッションに属していて、必要に応じてセッション間を移動しつつ通話することができるという点である。ユーザが複数のセッションを移動しつつ通話可能であるべきという要求事項は、移動通信サービスを定義している団体であるＯＭＡ（Ｏｐｅｎ Ｍｏｂｉｌｅ Ａｌｌｉａｎｃｅ）の要求事項に明示されている。
【０００４】
以下、一般的なＰｏＣサービスシステムの構造を説明する。
【０００５】
図１は、一般的なＰｏＣ（Ｐｕｓｈ−ｔｏ−ｔａｌｋ ｏｖｅｒ Ｃｅｌｌｕｌａｒ）基本構造を示す概念図である。図１を参照すれば、ＰｏＣクライアント１０は、移動端末に内蔵されるサービス要請者であり、一般的に、アクセス網２０を介してＳＩＰ（ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）とＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）マルチメディア支援核心網であるＳＩＰ／ＩＰコア（ｃｏｒｅ）３０網に連結される。
【０００６】
この際、ＰｏＣクライアント１０は、ＰｏＣユーザ端末機に常住しながらＰｏＣサービスへの接続を可能にする。主な機能は、ＰｏＣユーザ側面からＰｏＣセッションを生成し、既存のセッションに参加し、セッションを終了することである。その他、トークバストを作って伝達する機能、Ｉｎｓｔａｎｔ Ｐｅｒｓｏｎａｌ ａｌｅｒｔを支援する機能、Ｐｏｃサービスに接続した時、認証する機能などの役目を行う。以下、別の言及がない限り、ＰｏＣクライアント１０という用語は、ＰｏＣサービス加入者と同じ意味として使われる。
【０００７】
ＳＩＰ／ＩＰ基盤のコア網は、ＰｏＣサービスを支援するためにＰｏＣサーバ６０と、ＧＬＭＳ（Ｇｒｏｕｐ Ｌｉｓｔ ａｎｄ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）５０、及びプレゼンスサーバ７０などに連結され、サービスを提供する。この際、ＰｏＣサーバ６０は、ＰｏＣセッションを維持、管理するＣｏｎｔｒｏｌｌｉｎｇ ＰｏＣ Ｆｕｎｃｔｉｏｎ機能を行ったり、一対一通話や多者間通話のために開設されるＰｏＣセッションに参加するためのＰａｒｔｉｃｉｐａｔｉｎｇ ＰｏＣ Ｆｕｎｃｔｉｏｎ（以下、ＰＦという）などの機能を有する。
【０００８】
一般的に、ＰｏＣ群通話のセッション参加情報を伝達するために、代表的に、インターネットマルチメディア通話（ＩＰ Ｔｅｌｅｐｈｏｎｙ）制御の応用階層プロトコルであるＳＩＰ／ＳＩＰ拡張プロトコルを利用する。
【０００９】
一般的に、ＳＩＰは、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）ＲＦＣ（Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ）２５４３文書に標準が定義され、映像及び音声などのマルチメディア通信のためのセッション（ｓｅｓｓｉｏｎ）や呼を設定、修正、終了するためのアプリケーション階層の制御プロトコルである。ＳＩＰは、ＵＤＰ／ＴＣＰ／ＩＰ階層上に存在するプロトコルであり、要求／応答方式でＳＩＰ要求（Ｒｅｑｕｅｓｔ）メッセージ及びＳＩＰ応答（Ｒｅｓｐｏｎｓｅ）メッセージを送受信できるクライアント／サーバプロトコルであって、マルチメディア会議に招待（ｉｎｖｉｔｅ）することで、セッションを開始できるようにユニキャスト（Ｕｎｉｃａｓｔ）及びマルチキャスト（Ｍｕｌｔｉｃａｓｔ）セッションの両方を支援する。
【００１０】
ＳＩＰ要求メッセージは、ＲＦＣ２５４３ではＩＮＶＩＴＥ（Ｓｅｓｓｉｏｎ酸化招待）、ＡＣＫ（招待要求に対する承認）、ＢＹＥ（呼終了）、ＲＥＧＩＳＴＥＲ（ユーザエージェントがリダイレクトサーバのデータベースに登録）、ＣＡＮＣＥＬ（待機中の要求取消）、ＯＰＴＩＯＮＳの６つの基本機能が提供され、ＳＩＰ応答メッセージは、状態コードとして、１ｘｘ（情報応答）、２ｘｘ（成功的応答）、３ｘｘ（リダイレクト応答）、４ｘｘ（クライアントエラー、要求失敗）、５ｘｘ（サーバ失敗）、６ｘｘ（グローバル失敗）が提供される。
【００１１】
以下、図２を参照してＰｏＣサーバ内の機能別ブロックを説明する。図２は、一般的なＰｏＣサーバの概略的構造図である。前記ＰｏＣサーバは、ＰｏＣセッションを全般的に維持、管理するＣＦと各セッション間の維持管理を担当するＰＦとに区分され、各表を参照してさらに詳しく説明すれば、次の通りである。
【００１２】
【表１】
2006287940.tif 000003
【００１３】
ＣＦは、表１に示されたように、ＰｏＣサーバの機能のうちＰｏＣセッションを総体的に管理する役目をし、特にＰｏＣクライアントの話す権利（ｒｉｇｈｔ−ｔｏ−ｓｐｅａｋ）（ＰｏＣシステムでは通常“ｆｌｏｏｒ”という）要請を受け入れ、順序を定めて権限を付与し、任意のクライアントが要請したトークバスト（ｔａｌｋ ｂｕｒｓｔ）を群呼出に参加した全ての他のクライアントに分配し、群呼出に参加したクライアントの情報を提供する。
【００１４】
ＰＦは、下記表２に示すように、ＰｏＣセッションでＣＦと各クライアントと関連したセッションを管理し、特にクライアントが発言権を要求したり、ＣＦからクライアントに発言権を付与する時、ＰＦが中継する役目をする。また、ＣＦとクライアントとの間にメディアを中継する役目、両者が異なるコーデックを使用していれば、トランスコーディングする役目、同時セッションの場合には、１つのセッションで話している時、他のセッションでも話せば、ＰｏＣユーザの選択に応じて１つをフィルタリングする役目をする。
【００１５】
【表２】
2006287940.tif 000004
【００１６】
上記のように構成されたＰｏＣシステムにおいて、ＰｏＣユーザが自分の端末機を介してＧＬＭＳ４０に群及び群メンバーに関する情報を入力することができ、または、ＧＬＭＳ４０から転送された個人あるいは群目録を通じて自分が呼出できるＰｏＣユーザの情報を把握することができる。ＧＬＭＳに群及び群メンバーの生成、修正及び管理を実行できる他の方法として、インターネットやイントラネットなどＰｏＣサービス提供者が信頼できる通信網を介して入力する方法もある。
【００１７】
ＰｏＣ呼出サービスを利用するために、ＰｏＣユーザは、ＳＩＰ／ＩＰに自分のＰｏＣアドレスを登録する。この際、ＳＩＰ／ＩＰコア網では、ＰｏＣユーザの要請に基づいてＰｏＣユーザに関する情報を格納する。したがって、他のＰｏＣユーザがＰｏＣ群呼出をしようとする時、前述したように、自分の情報をＳＩＰ／ＩＰコア網にまず登録し、ＧＬＭＳから伝送された群識別情報を用いて自分のＳＩＰ／ＩＰコア網に呼出要請をする。この際、ＳＩＰ／ＩＰコア網は、要請するＰｏＣユーザ情報を用いてアドレス決定とドメイン位置決定過程を進行した後、要請するＰｏＣユーザが登録されたホームＰｏＣサーバにＰｏＣ通話要請を伝達する。ＰｏＣサーバは、このようなＰｏＣ通話要請に対してＰｏＣセッション開設を準備し、ＧＬＭＳサーバから各々のユーザ情報を獲得した後、該当ＳＩＰ／ＩＰコア網に通話要請信号を伝達する。この際、イントラ・ドメイン内のユーザに対する通話要請である場合、ＰｏＣサーバは、ＰＦとＣＦの機能を共に行うようになる。通話要請されたＰｏＣユーザを管理するＰｏＣサーバは、自分に伝達されたＰｏＣユーザの情報を用いてＳＩＰ／ＩＰコア網の位置決定過程を進行した後、ＰｏＣユーザに通話要請をするようになる。
【００１８】
図３は、ＰｏＣサーバのＣＦブロックとＰＦブロックを模式的に説明するための図である。図３を参照すれば、各ＰｏＣクライアント１１１、１２１、１３１、１４１は、ＰＦ１１０、１２０、１３０、１４０を介してＣＦ１００に接続し、ＰｏＣセッションを結成する。この際、ＣＦ１００で許諾した発言要請者に発言権が付与されれば、該当ＰｏＣクライアントの発言に対するメディアが各ＰｏＣクライアントに伝達される。この際、発言権を付与されたユーザは、群セッションに参加している参加者の情報を確認した後、適切な発言をすることができる。
【００１９】
一方、ＯＭＡで要求しているＰｏＣシステムの特徴は、次の通りである。
【００２０】
第一に、受信側は、ＰｏＣユーザの要求に応じて自分の応答モードを設定することができ、大きく、自動応答モードと受動応答モードとに分けられる。
【００２１】
仮に、受信側で自動応答モードユーザリストに登録しておいた状態なら、受信者の受動的な応答に代わって該当ネットワークから送信側に直ちに応答を送ることができる。このようなネットワークにおいて、端末の動作に代わって自動的な応答を送ることは、端末の応答モード設定要求に応じてＰｏＣサーバで応答モードと該当ユーザリストを格納する機能を有するからである。
【００２２】
一方、受動応答モードは、自動応答ユーザリストに含まれていないか、不明な場合、または、受信者が全てのユーザに対して受動応答に設定した場合に該当し、ＰｏＣ通話要請は、受信ネットワークを経てユーザの端末まで転送され、ＰｏＣユーザの許諾により通話が連結されることを意味する。
【００２３】
第二に、ＰｏＣシステムは、ユーザのホームネットワーク内のＰｏＣサーバとの連結設定可否に応じてｏｎ−ｄｅｍａｎｄセッションモードとｐｒｅ−ｅｓｔａｂｌｉｓｈｅｄセッションモードとに分けられる。
【００２４】
ｐｒｅ−ｅｓｔａｂｌｉｓｈｅｄセッションモードは、ＰｏＣユーザが自分の要求に応じてＰｏＣクライアント（ＰｏＣ Ｃｌｉｅｎｔ）と自分のホームネットワークに属するＰｏＣサーバとの間に事前にセッションを設定しておく技術である。このようなｐｒｅ−ｅｓｔａｂｌｉｓｈｅｄセッションは、ＰｏＣユーザが、自分が使用するメディアパラメーターをＰｏＣサーバと事前に交渉して、今後使われるＰｏＣサーバ−クライアント間のメディアパラメーターを再交渉する必要なく、早いセッション開設進行をするために必要な機能である。事前セッションの設定のためには、ＰｏＣクライアントがＳＩＰ ＩＮＶＩＴＥのｍｅｔｈｏｄにより本文部（ＳＤＰ ＭＩＭＥ ｂｏｄｙ）に支援するメディアパラメーターを提供し、サーバから提供されたメディアパラメーターに対する応答をすることによって具現され、サーバから受信する応答メッセージに新しく設定される事前セッションの識別情報をコンファレンス識別子（ｃｏｎｆｅｒｅｎｃｅ ＵＲＩ）を含んでＰｏＣユーザに返信するようになる。前述の事前セッションを利用する場合、ＩＰアドレス、ポート番号、使われるコーデック（ｃｏｄｅｃ）及びトークバストの制御のためのプロトコル（ｔａｌｋ ｂｕｒｓｔ ｃｏｎｔｒｏｌ ｐｒｏｔｏｃｏｌ）などの事前交渉が可能である。Ｏｎ−ｄｅｍａｎｄセッションモードは、ＰｏＣユーザが事前セッションを設定しない状態を意味し、他のＰｏＣユーザの招待メッセージを受けた後、ＰｏＣ呼連結手続を行うことを意味する。
【００２５】
前記ＰｏＣシステムのセッション開設について送信側と受信側とに区分して説明する。
【００２６】
まず、送信側ＰｏＣクライアントＡは、自分が話そうとする受信者のＳＩＰ ａｄｄｒｅｓｓ情報を含むＳＩＰ ＩＮＶＩＴＥ要請を該当ＳＩＰ／ＩＰ Ｃｏｒｅ Ａに送る。この際、ＳＩＰ ＩＮＶＩＴＥメッセージには、通話要請クライアントのＰｏＣアドレス情報、要求されるメディアパラメーター（この際、要求されるセッションがマルチメディアであるから、メディア特性値としてオーディオとビデオに関するインコーディング方法、レート、ペイロードタイプなどの多数の特性値を含む）、ＰｏＣサービスであることを知らせる特性値情報などのエレメントを含み、ＤＨＣＰサーバやＤＮＳサーバなどにおいての経路ｑｕｅｒｙを通じてＩＭＳ網内での該当ＩＭＳサーバ（Ｐ−ＣＳＣＦ及びＳ−ＣＳＣＦ）を経由してＰＦに伝達される。一般的な通話要請時、ＰｏＣユーザが連結されたＰＦは、開設されるセッションのトークバストを管理するＣＦと分離して具現されることができるので、先にＰＦに送られたＳＩＰ ＩＮＶＩＴＥ要請は、該当ネットワークのＳＩＰ／ＩＰ核心網を経由してＣＦに伝達される。
【００２７】
一方、ＣＦを含むＰｏＣセッション制御ネットワークは、受信側ネットワークにＳＩＰ ＩＮＶＩＴＥ要請メッセージを伝達した後、これに対する応答メッセージを受信するようになる。受信側ネットワークで応答されるＳＩＰメッセージは、受信側クライアントとＰＦの設定によって１ｘｘの臨時応答メッセージ（ｐｒｏｖｉｓｉｏｎａｌ ｒｅｓｐｏｎｓｅ）や２ｘｘの成功応答メッセージ（ｓｕｃｃｅｓｓｆｕｌ ｒｅｓｐｏｎｓｅ）または４ｘｘ〜６ｘｘなどの誤謬応答メッセージであることができる。仮に、ＡＵＴＯ−ＡＮＳＷＥＲ応答モードで設定された場合、受信側クライアントの応答がある前に、サーバで予めＳＩＰ１８３‘Ｓｅｓｓｉｏｎ ｐｒｏｇｒｅｓｓ’信号を送信し、これにより、通話要請者のＩＭＳ網でＰｏＣサーバとクライアント間の連結を進行できる。受信者の通話許諾信号は、前記ＳＩＰ１８３‘ＳｅｓｓｉｏｎＰｒｏｇｒｅｓｓ’やＳＩＰ２００‘ＯＫ’ｒｅｓｐｏｎｓｅとして返信され、ＣＦとＰＦのＰｏＣサーバを経由してＰｏＣクライアントＡに伝達するようになる。その後、ＣＦは、受信側ＰｏＣサーバから２００ ＯＫ応答や１８３ Ｓｅｓｓｉｏｎ ｐｒｏｇｒｅｓｓ信号を受信した後、ＰｏＣ呼が連結されたことを判断し、クライアントＡに対してトークバスト発言権を付与するｆｌｏｏｒ ｇｒａｎｔｅｄ信号を送るようになる。上記応答（２００ ＯＫまたは１８３ ｓｅｓｓｉｏｎ ｐｒｏｇｒｅｓｓ）によってトークバスト権限を付与することは、‘ｃｏｎｆｉｒｍｅｄ’または‘ｕｎｃｏｎｆｉｒｍｅｄ’に区分されることができ、‘ｕｎｃｏｎｆｉｒｍｅｄ’応答を受信する場合、ＣＦでバッファリング機能が必要となる。
【００２８】
一方、送信側ＰｏＣクライアントＡは、ＳＩＰ ＩＮＶＩＴＥ要請信号に対する応答信号を受信した後、トークバスト転送許可信号（通話連結音）を伝達するｆｌｏｏｒ ｇｒａｎｔｅｄ信号をＲＴＣＰプロトコルを用いて受信するようになる。この際、ｆｌｏｏｒ ｇｒａｎｔｅｄ信号は、トークバスト仲裁権限を有するＣＦで生成され、前記該当ＰｏＣクライアントを管理するＰＦを経てＰｏＣクライアントに転送され、ＳＩＰプロトコルを利用せず、ベアラーの経路を利用するので、ＳＩＰ／ＩＰ核心網を経ることなく転送されることができる。最後に、このような通話連結音を確認したＰｏＣユーザは、メディア（代表的に音声）ストリームをＲＴＰプロトコルを用いて転送するようになる。
【００２９】
以下、応答者情報伝達に関する従来の技術を説明する。
【００３０】
図４は、従来の群セッション連結時、連続的な参加者情報を伝達されるためのＰｏＣクライアントのＳＩＰ呼処理過程に関する流れ図である。また、ＰｏＣクライアントＡがクライアントＢ１、Ｂ２及びＣにｏｎ−ｄｅｍａｎｄアドホック群セッション要請（Ｐｒｅ−ａｒｒａｎｇｅｄ群に対しても同じ原理により手続を取るので、アドホック場合に対する例として代表することにする）をし、各クライアントから他の応答メッセージを獲得する状況を示す。
【００３１】
図４を参照すれば、送信側ＰｏＣクライアントＡ １１１は、コンファレンスセッション情報（受信側クライアントアドレス情報を含むＵＲＩリスト、ｐｒｏｖｉｓｉｏｎｅｄ ｃｏｎｆｅｒｅｎｃｅ ｉｄｅｎｔｉｔｙ）を含んでＳＩＰ ＩＮＶＩＴＥ要請を転送し（ステップＳ１、Ｓ２）、これにより、該当クライアントにＳＩＰ ＩＮＶＩＴＥメッセージが転送される（ステップＳ３、Ｓ４）。一方、受信クライアントＣ １３１から最初の２００ ＯＫ応答メッセージが返信されることによって、クライアントＡ １１１は、ＰｏＣメディアセッションを開始する（ステップＳ５ａ〜Ｓ８）。一方、送信側ＰｏＣクライアントＡ １１１は、群セッションの参加情報を得るために、ＳＩＰ ＳＵＢＳＣＲＩＢＥメッセージをコンファレンスサーバに要請する（ステップＳ１１、Ｓ１２）。この際、情報を得ようとするコンファレンスの識別のために、先に返信される２００ ＯＫ応答（ステップＳ７、Ｓ８）からセッション識別子（ＰｏＣ Ｓｅｓｓｉｏｎ ｉｄｅｎｔｉｔｙ）を抽出し、これをＳＩＰ ＳＵＢＳＣＲＩＢＥメッセージのＲｅｑｕｅｓｔ ＵＲＩに設定し、イベントヘッダーに‘ｃｏｎｆｅｒｅｎｃｅ’を含むことによって、該当コンファレンスサーバにセッション情報要請が可能である。一方、ＳＩＰ ＳＵＢＳＣＲＩＢＥメッセージの要請に応じてＳＩＰ ｕｓｅｒ ａｇｅｎｔとして動作するＣＦは、イベントが発生する毎に、コンファレンス状態イベントパッケージ（ｃｏｎｆｅｒｅｎｃｅ ｓｔａｔｅ ｅｖｅｎｔ ｐａｃｋａｇｅ）を作成する。
【００３２】
最後に、上記セッション情報獲得要請に応じて、その後、ＣＦ Ｘ １００は、セッション参加メッセージを受信する毎に、発生したイベントを含むｃｏｎｆｅｒｅｎｃｅ ｓｔａｔｅ ｅｖｅｎｔ ｐａｃｋａｇｅの結果をＳＩＰ ＮＯＴＩＦＹメッセージを通じて転送するようになる（ステップＳ１５、Ｓ１６）。また、その後、セッションに参加する受信側ＰｏＣクライアントＢ１ １２１も前記と同様の手続によりコンファレンス状態情報を受信するようになる。
【００３３】
しかし、前述のような従来技術を用いて開設されるセッションの参加者情報を獲得する方法は、次のような短所を有する。
【００３４】
第一に、セッション開設者がコンファレンス状態情報を獲得するために、ＳＩＰメッセージ（ＳＩＰ ＳＵＢＳＣＲＩＢＥ）を要請しなければならないので、追加的なＳＩＰシグナルリングが必要である。
【００３５】
第二に、開設される群が特別にアドホックセッションである場合、初期ＳＩＰ ＩＮＶＩＴＥメッセージに対する最初２００ ＯＫ応答以後、ＳＩＰ ＳＵＢＳＣＲＩＢＥメッセージを要請しなければならない（前述したように、ＰｏＣセッション識別子をＳ７、Ｓ８応答として受信した後、ＳＩＰ ＳＵＢＳＣＲＩＢＥ要請が可能である）。
【００３６】
また、セッションに招請されるクライアントの場合、返信した２００ ＯＫ応答に対するＡＣＫ信号を返信した後、群情報要請をすることができる。前述のような場合、群初期開設時に参加者の情報をリアルタイムで得ないので、ＰｏＣユーザが適切な方法でメディアを転送しないこともある。
【発明の開示】
【発明が解決しようとする課題】
【００３７】
本発明は、前述のような問題点を解決するためになされたもので、本発明の目的は、初期セッション開設手続でセッション参加を応答したクライアント情報をトークバスト制御信号に含んで伝達することによって、トラフィック負担を低減し、モバイル環境に適合した環境をＰｏＣネットワークに提供することにある。
【００３８】
また、本発明の別の目的は、セッション参加応答種類によって発生する全ての情報を初期セッション開始者に提供することにある。
【課題を解決するための手段】
【００３９】
前記目的を達成するために、本発明の一態様に係るプッシュ・トゥ・トーク・オーバー・セルラー（Push-to-talk over Cellular：ＰｏＣ）網のセッションに参加する応答者の情報を転送する方法は、送信側ＰｏＣサーバが送信側ＰｏＣクライアントの通話要請メッセージを受信側ＰｏＣサーバに送信する段階と、前記送信側ＰｏＣサーバが前記通話要請メッセージに対する受信側ＰｏＣクライアントからの応答メッセージを受信する段階と、前記送信側ＰｏＣクライアントが前記応答メッセージを送信した受信側ＰｏＣクライアントの情報が含まれたメッセージを前記送信側ＰｏＣサーバから受信する段階と、を備えることを特徴とする。
【００４０】
また、本発明の他の態様に係るプッシュ・トゥ・トーク・オーバー・セルラー（Ｐｕｓｈ−ｔｏ−ｔａｌｋ ｏｖｅｒ Ｃｅｌｌｕｌａｒ：ＰｏＣ）網のセッションに参加する応答者の情報を転送する方法は、ＰｏＣ網セッションを管理するＰｏＣサーバが送信側ＰｏＣクライアントの通話要請メッセージを受信側ＰｏＣサーバに送信する段階と、前記ＰｏＣサーバが前記通話要請メッセージに対する受信側ＰｏＣクライアントからの応答メッセージを受信する段階と、前記送信側ＰｏＣクライアントが前記応答メッセージを送信したクライアントの情報が含まれたメッセージを前記ＰｏＣサーバから受信する段階と、を備えることを特徴とする。
【００４１】
また、本発明のさらに他の態様に係るプッシュ・トゥ・トーク・オーバー・セルラー（Ｐｕｓｈ−ｔｏ−ｔａｌｋ ｏｖｅｒ Ｃｅｌｌｕｌａｒ：ＰｏＣ）網のセッションに参加する応答者の情報を転送するＰｏＣシステムは、受信側ＰｏＣシステムにセッション通話要請メッセージを送信する送信側ＰｏＣクライアントと、前記通話要請メッセージに対する応答メッセージを受信する送信側ＰｏＣサーバと、を備え、前記送信側ＰｏＣクライアントは、応答メッセージを送信した受信側ＰｏＣクライアントの情報を含むメッセージを前記送信側ＰｏＣサーバから受信する前記送信側ＰｏＣクライアントと、を備えることを特徴とする。
【００４２】
また、本発明のさらに他の態様に係るプッシュ・トゥ・トーク・オーバー・セルラー（Ｐｕｓｈ−ｔｏ−ｔａｌｋ ｏｖｅｒ Ｃｅｌｌｕｌａｒ：ＰｏＣ）網のセッションに参加する応答者の情報を転送するＰｏＣシステムは、受信側ＰｏＣシステムにセッション通話要請メッセージを送信する送信側ＰｏＣクライアントと、セッションを全般的に管理し、前記通話要請メッセージに対する応答メッセージを受信するＰｏＣサーバと、を備え、前記送信側ＰｏＣクライアントは、応答メッセージを送信した受信側ＰｏＣクライアントの情報を含むメッセージを前記ＰｏＣサーバから受信する前記送信側ＰｏＣクライアントと、を備えることを特徴とする。
【００４３】
また、本発明のさらに他の態様に係るプッシュ・トゥ・トーク・オーバー・セルラー（Ｐｕｓｈ−ｔｏ−ｔａｌｋ ｏｖｅｒ Ｃｅｌｌｕｌａｒ：ＰｏＣ）網のセッションに参加する応答者の情報を転送するＰｏＣサーバは、送信側ＰｏＣクライアントの通話要請メッセージに対する応答メッセージが受信側ＰｏＣクライアントに伝達され、セッションが連結されれば、応答メッセージを送信した受信側ＰｏＣクライアントの情報が含まれたメッセージを送信側ＰｏＣクライアントに提供することを特徴とする。
【００４４】
また、本発明のさらに他の態様に係るプッシュ・トゥ・トーク・オーバー・セルラー（Ｐｕｓｈ−ｔｏ−ｔａｌｋ ｏｖｅｒ Ｃｅｌｌｕｌａｒ：ＰｏＣ）網のセッションに参加する応答者の情報を提供されるＰｏＣクライアントが転送する方法は、受信側ＰｏＣシステムに通話要請メッセージを送信し、前記通話要請メッセージに対する受信側ＰｏＣクライアントからの応答メッセージが送信側ＰｏＣサーバに転送されれば、前記応答メッセージを送信した受信側ＰｏＣクライアントのセッション連結情報を含むメッセージを前記送信側ＰｏＣサーバから受信することを特徴とする。
【００４５】
また、本発明のさらに他の態様に係るプッシュ・トゥ・トーク・オーバー・セルラー（Ｐｕｓｈ−ｔｏ−ｔａｌｋ ｏｖｅｒ Ｃｅｌｌｕｌａｒ：ＰｏＣ）網のセッションに参加する応答者の情報を提供されるＰｏＣクライアントが受信する方法は、受信側ＰｏＣシステムに通話要請メッセージを送信し、前記通話要請メッセージに対する受信側ＰｏＣクライアントからの応答メッセージがセッションを管理するＰｏＣサーバに転送されれば、前記応答メッセージを送信した受信側ＰｏＣクライアントのセッション連結情報を含むメッセージを前記ＰｏＣサーバから受信することを特徴とする。
【００４６】
本発明の基本構成は、通常のＰｏＣシステム、すなわちＰｏＣ端末機と、ＰｏＣサーバと、両端を連結するための下部ネットワーク（ＳＩＰ／ＩＰ核心網及び無線接続網など）とで構成される。
【００４７】
ＰｏＣ端末機は、ＰｏＣサービスを利用するためのＰｏＣクライアントを含む。また、ＰｏＣクライアントは、サーバに対応する用語であるが、本発明では、ＰｏＣサービスを使用するユーザまたはＰｏＣ端末機と同じ意味として使われる。
【００４８】
ＰｏＣサーバは、群セッションの所有可否によってＣＦやＰＦで作動することができ、これに対する内容は、先に一般的なＰｏＣシステムで説明したので、省略するようにする。一方、ＰｏＣクライアントは、ＳＩＰ／ＳＩＰ拡張プロトコルを支援して、群セッションを開設することができ、開設されたセッションに伝達されるトークバスト制御信号（ＴＢＣＰ）メッセージをＲＴＣＰメッセージフォーマットとして受信し、解析することによって、ＰｏＣユーザがＲＴＰメディアとその他セッション関連情報を認識できるようにする機能を有する。
【発明の効果】
【００４９】
本発明は、ＰｏＣ群通話を行うにあたって、最初応答以後のＳＩＰセッション連結応答を受信する時、連結したセッションを用いて応答受信クライアントのセッション連結情報をトークバスト制御プロトコルを用いて伝達するので、無線環境においてトラフィック負担を低減することができるという効果がある。
【００５０】
また、ＰｏＣ群通話の開始者及び群通話要請にまず応答したＰｏＣユーザは、以後に群に参加する構成員情報を追加的なＳＩＰメッセージの要請がなくても提供することができ、セッション開始者の場合、セッション参加を承認しないユーザの拒絶情報をも提供することができるので、情報提供の信頼性を向上させることができるという効果がある。
【発明を実施するための最良の形態】
【００５１】
以下、本発明の原理は、該当分野における通常の知識を有する者が本発明を容易に実施できるように、好ましい実施例を参照して詳細に説明する。
【００５２】
図５は、本発明に係るセッション参加情報をＲＴＣＰメッセージを通じて転送する概念を示す流れ図である。
【００５３】
図５は、群セッションを要請したＰｏＣクライアントＡが最初２００ ＯＫ応答を受信してセッションを開設した後、群内の他のクライアントからＳＩＰ ｒｅｓｐｏｎｓｅを受信し、これによるＲＴＣＰメッセージを開設されたセッションに転送する概念を示す。
【００５４】
この際、コンファレンスサーバＣＦは、ステップＳ１０１、Ｓ１０２から分かるように、クライアントＢ１とＢ２から受信する臨時応答（ｐｒｏｖｉｓｉｏｎａｌ ｒｅｓｐｏｎｓｅ）１００、１８０または１８３に対してセッション参加の最終応答でないので、ＲＴＣＰメッセージを伝達しないことを基本的機能とする（ＣＦの機能によって選択的に伝達することもできる）。
【００５５】
一方、他のクライアントから成功的な応答を受信する場合（ステップＳ１０３）、ＲＴＣＰメッセージ（ＯＭＡ ＰｏＣの用法によってＴＢＣＰメッセージで表現される）のペイロードを通じてセッションに参加したＰｏＣクライアントの識別子と応答可否、応答内容を転送する（ステップＳ１０４）。また、連続的に伝達される他のクライアントのＳＩＰ最終応答（ｆｉｎａｌ ｒｅｓｐｏｎｓｅ）を受信する場合、成功的な応答と拒絶する応答の内容をＲＴＣＰペイロードに含んで転送する（ステップＳ１０６〜Ｓ１１１）。
【００５６】
一方、図５に示してはいないが、本発明の原理で言及した通り、セッションに成功的な応答を送ったクライアントも同様の方法により、以後にセッションに連結される参加者の情報を伝達されることができる。すなわち、図５で、クライアントＣは、以後にクライアントＢ１のセッション参加情報を伝達されることができる。この際、セッション参加要請に対する臨時応答や拒絶情報は、セッション開設者以外には送る必要がないことを特徴とする。
【００５７】
前記図５の概念を用いてＰｏＣ群セッションの好ましい開設手続を説明する。
【００５８】
図６は、本発明の好ましい実施例により送信側ＰｏＣシステムのセッション連結要請メッセージに対して受信側ＰｏＣシステムが応答メッセージを送り、且つ前記受信側ＰｏＣシステムの情報を含むメッセージを送信側ＰｏＣサーバ及び送信側ＰｏＣクライアントに転送する方法を示している。また、受信側で２００ ＯＫを送信したクライアントのセッション参加情報は、ＴＢＣＰに含んで転送する方法にを示す流れ図である。ここで、前記送信側ＰｏＣシステムは、送信側ＰｏＣサーバ、送信側ＰｏＣクライアントとを含み、受信側ＰｏＣシステムは、受信側ＰｏＣサーバと受信側ＰｏＣクライアントとを含む。
【００５９】
まず、本発明を具現するためのセッション参加情報に対するＲＴＣＰメッセージを説明する。
【００６０】
新しく定義されるＲＴＣＰメッセージは、‘ＴＢＣＰ Ｒｅｐｏｒｔ’メッセージまたは‘ＴＢＣＰ Ｉｎｆｏｒｍ’などの用語で表現されることができる。
【００６１】
セッション参加情報は、前記‘ＴＢＣＰ Ｒｅｐｏｒｔ’メッセージまたは‘ＴＢＣＰＩｎｆｏｒｍ’などの用語を新設したり、既に存在するＴＢＣＰメッセージのうちＴＢＣＰ Ｃｏｎｎｅｃｔなどのメッセージに本発明で提案するフィールドを追加して伝達することができる。但し、ＴＢＣＰメッセージのうち前記２つの方法に限定されず、本発明の根本原理を逸脱しない範囲内で、多様な形態のＴＢＣＰメッセージを利用することができる。但し、本発明では、セッション参加情報を‘ＴＢＣＰ Ｒｅｐｏｒｔ’として定義して説明することにする。
【００６２】
図６を参照すれば、群セッションを要請するＰｏＣクライアントＡ １１０１は、ＳＩＰ ＩＮＶＩＴＥに受信者のＵＲＩリストを含んでセッション連結要請をし（ステップＳ２０１、Ｓ２０２）、これにより、ＣＦ Ｘは、各クライアントにセッション参加を要請するようになる（ステップＳ２０３ａ、Ｓ２０３ｂ、Ｓ２０３ｃ、Ｓ２０４ａ、Ｓ２０４ｂ、Ｓ２０４ｃ）。次に、クライアントＣ １３０１からまず応答を受け（ステップＳ２０５ａ、Ｓ２０６ａ、Ｓ２０７、Ｓ２０８）、その後、クライアントＢ１ １２０１、及びＢ２ １２０２から各々の応答を受ける場合を仮定する（ステップＳ２０５ｂ、Ｓ２０６ｂ、Ｓ２０５ｃ、Ｓ２０６ｃ）。
【００６３】
この際、クライアントＡ １１０１は、クライアントＣ １３０１と最初セッションを開設した後、以後に応答されるセッション参加情報が前記定義されたＴＢＣＰ Ｒｅｐｏｒｔメッセージを通じて伝送される（Ｓ２０９、Ｓ２１０）。
【００６４】
このために、コンファレンスサーバ役目を行うＣＦ Ｘ １０００は、受信されるＳＩＰ応答メッセージの状態ライン（ｓｔａｔｕｓ−ｌｉｎｅ）と応答者のＳＩＰ識別子から前記ＴＢＣＰ Ｒｅｐｏｒｔに含まれるデータペイロードを生成し転送する。
【００６５】
ＲＴＣＰメッセージを通じて伝達される情報は、ステップＳ２０７ｂ、Ｓ２０８ｂのように、クライアントの識別子（プライバシーの設定によってｎｉｃｋ ｎａｍｅやＳＩＰアドレス情報が選択的に設定されることができる）と応答種類（ＯＫ）を含むことができる。
【００６６】
または、ステップＳ２０９ｃ、Ｓ２１０ｃのように、クライアントの識別子（プライバシーの設定によってｎｉｃｋ ｎａｍｅやＳＩＰアドレス情報が選択的に設定されることができる）とエラー応答種類（４８０ Ｔｅｍｐｏｒａｒｉｌｙ Ｕｎａｖａｉｌａｂｌｅ、４８６ Ｂｕｓｙ Ｈｅｒｅ、４８８ Ｎｏｔ Ａｃｃｅｐｔａｂｌｅ Ｈｅｒｅ、４０３ Ｆｏｒｂｉｄｄｅｎなど）を含むことができる。
【００６７】
追加的に、前記で説明した通り、群セッションに招待されたクライアントが２００  ＯＫを応答したり、またはこれに対するＡＣＫ応答を返信してセッションに参加した後、以降に参加する他のクライアントのセッション参加情報（クライアント識別子と２００ ＯＫ応答情報など）が伝達されることもできる。これにより、セッションに参加するクライアントは、群情報に対するＳＩＰ購読要請をしなくとも、自分より以後に参加するクライアントの情報が伝達されることができるので、メディア転送を効率的に行うことができる。
【００６８】
一方、前記図６は、特別にＰｏＣクライアントＡが３名の受信クライアントを対象にする一般的なＰｏＣ群セッションを開設する場合を説明するが、本発明の原理は、ＰｏＣサービスの群種類（ａｄ ｈｏｃ群、ｐｒｅ−ａｒｒａｎｇｅｄ群、ｃｈａｔ群など）、セッション種類（ｐｒｅ−ｅｓｔａｂｌｓｉｈｅｄセッション、あるいはｏｎ−ｄｅｍａｎｄセッション）、多様な応答モード（自動応答あるいは受動応答など）及び応答内容によって変形された開設手続においても同様に適用することができ、これにより、本発明のいろいろな変形または変更された方法は、本発明の創案された技術から外れることができない。例えば、アドホック群に対する手続では、ＰＦとＣＦの役目を同時に行うＰｏＣサーバからＰｏＣクライアントに直接ＴＢＣＰメッセージを転送できる。また、図６で、ＣＦ Ｘ １０００は、本発明では独立的なサーバとして提示されたが、これは、Ｎｅｔｗｏｒｋ Ｔｏｐｏｌｏｇｙに限定されない。すなわち、送信側ＰｏＣシステム内で前記ステップＳ２０７ｂでのＴＢＣＰ Ｒｅｐｏｒｔを送信側ＰｏＣクライアントに送信することによって、送信側ＰｏＣサーバになることができ、受信側ＰｏＣシステム内で２００ ＯＫを発信するＰｏＣクライアントの情報を含むＴＢＣＰ Ｒｅｐｏｒｔを送信側ＰｏＣシステムに送信することによって、受信側ＰｏＣサーバになることができる。
【００６９】
図７は、本発明のＴＢＣＰメッセージを表現するＲＴＣＰペイロード形態を示す図である。図７は、前記図５及び図６を具現するために本発明で創案するＴＢＣＰ Ｒｅｐｏｒｔメッセージの好ましい実施例に関するものである。ＴＢＣＰ Ｒｅｐｏｒｔメッセージは、ＰｏＣリリース１に対するＯＭＡ標準に応じてＲＴＣＰＡＰＰメッセージフォーマットで構成される。
【００７０】
図７を参照すれば、前記ＲＴＣＰ ＡＰＰパケットは、バージョン情報、パケットタイプ、サブタイプ情報、パケット長さなど一般的なＲＴＣＰ転送関連情報を含み、本発明のために応答者の識別子情報、開設されるＰｏＣ群あるいはセッションの識別子、受信クライアントの応答種類と応答内容を含む。
【００７１】
前記サブタイプ情報は、固有なＴＢＣＰ Ｒｅｐｏｒｔメッセージであることを知らせるために、‘１００００’で設定したり、この値以外の予備値（ｒｅｓｅｒｖｅｄ）のうちいずれか１つを選択できる。
【００７２】
そして、コンファレンスサーバは、該当群セッションを管理する自分のアドレス情報とＰｏＣリリース情報をＳＳＲＣフィールドとｎａｍｅフィールドに各々含まれる。一方、クライアントからｆｉｎａｌ ｒｅｓｐｏｎｓｅ応答情報を受信することによって、該当クライアントの識別子と応答内容を追加的なフィールド定義を用いて伝達する。例えば、図７では、クライアント‘ＫＴ Ｌｅｅ’が成功的な応答を送り（Ｒｅａｓｏｎ Ｃｏｄｅ＝１）、これは、‘ｓｅｓｓｉｏｎ ｊｏｉｎｅｄ’という応答理由で表現されて伝達されることができる。
【００７３】
一方、他の例として、Ｒｅａｓｏｎ Ｃｏｄｅが‘２’である場合、ＳＩＰ ４ｘｘ応答などのエラー発生可否を指示することができ、この際の応答理由をｔｅｘｔに含むことができる。
【００７４】
図８は、本発明のＴＢＣＰ応答種類に関するテーブルを示す図である。
【００７５】
前記ＴＢＣＰ ＲｅｐｏｒｔメッセージにおいてＴＢＣＰ‘ｒｅａｓｏｎ’のコードが１である場合、セッション連結成功を表示し、この際の成功内容を表示するテキスト（‘ｓｅｓｓｉｏｎ ｊｏｉｎｅｄ’）を含むことができる。ＴＢＣＰ‘ｒｅａｓｏｎ’のコードが２である場合、セッション開設エラーを表示し、エラー内容（ｆｏｒｂｉｄｄｅｎ、ｕｎａｖａｉｌａｂｌｅ、ｂｕｓｙなど）を各エラー応答状況に適合するように、セッション開始者に伝達することができる。
【００７６】
前記ＴＢＣＰメッセージは、今後マルチメディアを表現するために、ＭＢＣＰ（Ｍｕｌｔｉｍｅｄｉａ Ｂｕｒｓｔ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）などに変更され得る。このような単純な名称の変更などを含んで、以上において説明した本発明は、本発明が属する技術の分野における通常の知識を有する者であれば、本発明の技術的思想を逸脱しない範囲内で、様々な置換、変形及び変更が可能であるので、上述した実施例及び添付された図面に限定されるものではない。
【図面の簡単な説明】
【００７７】
【図１】一般的なＰｏＣ（Ｐｕｓｈ−ｔｏ−ｔａｌｋ ｏｖｅｒ Ｃｅｌｌｕｌａｒ）基本構造を示す概念図である。
【図２】一般的なＰｏＣサーバの概略的構造図である。
【図３】ＰｏＣサーバのＣｏｎｔｒｏｌｌｉｎｇ ＰｏＣ ＦｕｎｃｔｉｏｎブロックとＰａｒｔｉｃｉｐａｔｉｎｇ ＰｏＣ Ｆｕｎｃｔｉｏｎブロックを模式的に説明するための図である。
【図４】従来の群セッション連結時、連続的な参加者情報を伝達されるためのＰｏＣクライアントのＳＩＰ呼処理過程を示す流れ図である。
【図５】本発明に係るセッション参加情報をＲＴＣＰメッセージを用いて転送する概念を示す概略的流れ図である。
【図６】本発明の好ましい実施例に係るセッション参加情報をＴＢＣＰに含んで転送する方法を示す流れ図である。
【図７】本発明のＴＢＣＰメッセージを表現するＲＴＣＰペイロード形態を示す図である。
【図８】本発明のＴＢＣＰ応答種類に関するテーブルを示す図である。
【符号の説明】
【００７８】
１００  ＣＦ（Ｃｏｎｔｒｏｌｌｉｎｇ機能を担当するサーバ）
１１０、１２０  ＰＦ（Ｐａｒｔｉｃｉｐａｔｉｎｇ機能を担当するサーバ） Ａ、ＰＦ Ｂ
１１１、１２１  ＰｏＣクライアントＡ、Ｂ
【図１】
2006287940.tif 000005
【図２】
2006287940.tif 000006
【図３】
2006287940.tif 000007
【図４】
2006287940.tif 000008
【図５】
2006287940.tif 000009
【図６】
2006287940.tif 000010
【図７】
2006287940.tif 000011
【図８】
2006287940.tif 000012