JP6758472B2 - 通信方法、通信装置及び通信システム - Google Patents

通信方法、通信装置及び通信システム Download PDF

Info

Publication number
JP6758472B2
JP6758472B2 JP2019208007A JP2019208007A JP6758472B2 JP 6758472 B2 JP6758472 B2 JP 6758472B2 JP 2019208007 A JP2019208007 A JP 2019208007A JP 2019208007 A JP2019208007 A JP 2019208007A JP 6758472 B2 JP6758472 B2 JP 6758472B2
Authority
JP
Japan
Prior art keywords
codec
sdp
ims network
transcoding
sdp offer
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2019208007A
Other languages
English (en)
Other versions
JP2020025346A (ja
Inventor
宗晃 小川
宗晃 小川
健二郎 荒井
健二郎 荒井
健一 平木
健一 平木
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nippon Telegraph and Telephone Corp
Original Assignee
Nippon Telegraph and Telephone Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nippon Telegraph and Telephone Corp filed Critical Nippon Telegraph and Telephone Corp
Publication of JP2020025346A publication Critical patent/JP2020025346A/ja
Application granted granted Critical
Publication of JP6758472B2 publication Critical patent/JP6758472B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10Architectures or entities
    • H04L65/1016IP multimedia subsystem [IMS]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10Architectures or entities
    • H04L65/1046Call controllers; Call servers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • H04L65/1069Session establishment or de-establishment
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • H04L65/1101Session protocols
    • H04L65/1104Session initiation protocol [SIP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/75Media network packet handling
    • H04L65/765Media network packet handling intermediate
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M11/00Telephonic communication systems specially adapted for combination with other electrical systems
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M11/00Telephonic communication systems specially adapted for combination with other electrical systems
    • H04M11/06Simultaneous speech and data transmission, e.g. telegraphic transmission over the same conductors
    • H04M11/066Telephone sets adapted for data transmision

Description

本発明は、SIP/SDPを利用した呼制御技術に関する。特に、他網又は端末との境界制御を行うSBC(Session Border Controller)に搭載されるSIPアプリケーションソフトウェアに関する。
SIP(Session Initiation Protocol)を利用した音声・映像通信では、その通信のメディア情報を記述したSDP(Session Description Protocol)を発着端末間又は網内のSIPサーバ間で交換し、音声・映像のメディア条件(メディア種別、コーデック、パケット化周期等)をネゴシエーションして確定させた後、RTP(Real-time Transport Protocol)で実際の音声パケットの送受信が行われる。
特に、メディア情報のネゴシエーション(SDPネゴシエーション)は、発側端末が、通信に利用したいメディア(音声・映像等)と、そのメディアの各種パラメータ(コーデック、パケット化周期等)とをSDPオファーに記述し、着側端末が、SDPオファーに記述されるメディア条件から通信に利用するメディア条件を選択し、SDPアンサーに記述して発側端末に返送することで行われる。これにより、発着端末間で用いられる通信メディアの条件が確定する。
一方、3GPPでは、通信事業者が電話をはじめとするマルチメディアサービスを提供するシステムとして、IMS(IP Multimedia Subsystem)が定義されている。IMSは、移動・固定等の発着端末が利用するアクセス種別(3G、LTE、WiFi、光アクセス等)によらないマルチメディアサービスシステムである。しかし、移動端末のみを収容するIMS網と、固定端末のみを収容するIMS網とでは、それら異なるIMS網の端末同士で共通のコーデックがサポートされていない場合がある。
例えば、一般的に、固定端末ではG.711μ−lawの音声コーデックが最低限サポートされ、移動端末ではAMR−NBの音声コーデックが最低限サポートされている。それゆえ、固定端末と移動端末間で相互通信を実現するためには、通信事業者のIMS網でコーデックを変換する機能が必要となる。
なお、コーデック変換に限らず、IMS網内の中間ノードがSDPの書き換え処理(コーデックの追加・削除等)を行い、SDPの書き換え前と書き換え後の条件に従ってメディア(RTP等)の変換処理を行う機能は、一般的にトランスコーディング機能と呼ばれている。トランスコーディングは、通常、発網又は着網の中間ノードにおいて、事業者間合意やSLA(Service Level Agreement)等で事業者により規定されるオペレータポリシーに基づき、発着端末がサポートするコーデック情報を用いて行われる。
図7は、SBCで行われるトランスコーディングの処理手順を示す図である。SBC(Session Border Controller)は、IMS網の境界付近に設置された中間ノードであり、例えば、IBCF(Interconnection Border Control Function;SIPサーバ)とTrGW(Translation Gateway;メディアサーバ)とで構成される。それゆえ、実際には、SBC内のSIPサーバが、H.248を用いてSDPの書き換え処理と該SDPに基づくメディア変換の指示を行い、SBC内のメディアサーバが、該指示に基づきメディアのパケットを変換する。
具体的に、SBC(IBCF)は、SDPオファーを受信時に、SDPオファーに設定されたコーデックリストに自IMS網又は自IMS網内の端末でトランスコーディング対応可能なコーデック(例では、codec b)を追加する。そして、その後に受信したSDPアンサー内のコーデックに、以前受信していたSDPオファー内のコーデック(例では、codec a)が含まれている場合、SBCは、トランスコーディング機能を起動することなく、SDPアンサーをそのまま送信する(図7(a))。
一方、受信したSDPアンサー内のコーデックに、以前受信していたSDPオファー内のコーデック(codec a)が含まれていない場合、SBC(IBCF)は、以前受信していたSDPオファーに含まれていたコーデック(例では、codec aのみ)の中からコーデックを1つ選択し、そのコーデック情報を記述したSDPアンサーを送信する(図7(b))。その後、SBC(TrGW)は、受信したSDPアンサーのコーデックと送信したSDPアンサーのコーデックとのトランスコーディング(codec b⇔a)を実行する。
例えば、1つのIMS網内で移動端末・固定端末を収容する場合には、IMS網内の中間ノード(SIPサーバ、メディアサーバ等)又は端末に最も近いノード(P−CSCF(Proxy Call State Control Function)、MGW(Media Gateway)等)等にトランスコーディング機能を配備することにより、自IMS網の移動端末・固定端末間で通信が可能となる。
また、移動端末のみを収容するIMS網と固定端末のみを収容するIMS網とを相互接続する場合には、SDPオファー送信側のIMS網又はSDPアンサー送信側のIMS網でトランスコーディングを実行することにより、異なるIMS網の移動端末・固定端末間で通信が可能となる。SDPオファー送信側のIMS網とSDPアンサー送信側のIMS網で行うトランスコーディングの各処理手順を図8,図9にそれぞれ示す。
また、それらの具体例として、G.711μ−lawの音声コーデックのみサポートする固定端末を収容するIMS網と、AMRの音声コーデックのみサポートする移動端末を収容するIMS網との相互接続において、G.711μ−lawとAMR間のトランスコーディングをSDPオファー送信側のIMS網で行い、同トランスコーディングをSDPアンサー送信側のIMS網で行う場合の各処理手順を図10,図11にそれぞれ示す。なお、対象となるコーデック、SBCの機能配備、SDPが設定されるSIPメッセージ等は、本例に限定される訳ではない。
図10,図11に示したように、SIPを呼制御信号に利用する通信では、3PCC(3rd Party Call Control)等のサービスでない限り、発端末からSDPオファーを含むInitial‐INVITEリクエストが送信され、着端末が生成するレスポンス(18xレスポンス(xは数字)、200レスポンス等)にSDPアンサーが設定され、初回のSDPオファー/アンサーが完了することにより通信が開始される。また、SDPオファー送信側でトランスコーディングを実施する場合、初回のSDPオファー/アンサー後は、SDPオファー送信側となる発側のIMS網がトランスコーディングを実行することとなる。
"SIP:Session Initiation Protocol"、RFC3261、[online]、[平成28年6月29日検索]、<URL: https://www.ietf.org/rfc/rfc3261.txt> "SDP:Session Description Protocol"、RFC2327、[online]、[平成28年6月29日検索]、<URL: https://www.ietf.org/rfc/rfc2327.txt> "RTP:A Transport Protocol for Real-Time Applications"、RFC3550、[online]、[平成28年6月29日検索]、<URL: https://www.ietf.org/rfc/rfc3550.txt> "An Offer/Answer Model with the Session Description Protocol (SDP)"、RFC3264、[online]、[平成28年6月29日検索]、<URL: https://www.ietf.org/rfc/rfc3264.txt> "IP Multimedia Subsystem (IMS)"、3GPP TS 23.228、[online]、[平成28年6月29日検索]、<URL: http://www.3gpp.org/DynaReport/23228.htm> "IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP)"、3GPP TS 24.229、[online]、[平成28年6月29日検索]、<URL: http://www.3gpp.org/dynareport/24229.htm>
しかし、実際のサービスでは、ガイダンス又は映像呼から音声呼への切り替え等、メディアの変更を伴う通信に関し、複数回のSDPオファー/アンサーが行われる。それゆえ、SDPオファーが着側のIMS網から送信される場合、図12に示すように、初回のSDPオファー/アンサー後はトランスコーディングを発側のIMS網で実行していたが、2回目のSDPオファー/アンサー後は着側のIMS網で実行することになる等、トランスコーディングの実行位置を発側網又は着側網に固定することができないという課題があった。また、図13に示すように、初回のSDPオファー/アンサー後はトランスコーディングを着側のIMS網で実行していた場合であっても、2回目のSDPオファー/アンサー後は発側のIMS網で実行することになる等、同様の課題があった。
具体例として、固定端末を収容するIMS網と移動端末を収容するIMS網との相互接続において、移動端末のIMS網から固定端末のIMS網の発端末に対して呼確立前にガイダンスを提供し、SDPオファー送信側でトランスコーディングを実行する場合の例を図14に示す。初回のSDPオファー/アンサーでは、発端末からSDPオファーが送信されるため、呼確立前のガイダンスメディアに関するトランスコーディングは発側のIMS網で実行される。しかし、2回目のSDPオファー/アンサーでは、着側のIMS網からSDPオファーが送信されるため、発着端末間の通話メディアに関するトランスコーディングは着側のIMS網で実行されることになる。逆に、図15に示すように、呼確立前のガイダンスメディアに関するトランスコーディングを着側のIMS網で実行していた場合でも、発着端末間の通話メディアに関するトランスコーディングは発側のIMS網で実行されることとなる。
ここで、トランスコーディングは、メディアパケットを透過転送する処理に要するリソースと比較して大きなリソースを消費するため、発着信の呼数を基に呼制御システムの設備設計を行いたい場合、1callにおいて発側又は着側に固定できることが望ましい。また、トランスコーディングにより必要設備数が異なることが想定されるため、事業者間の相互接続においては、接続先網から請求されるアクセスチャージが安価になるよう、自網発の呼については自網内でトランスコーディングを実行したいとする要望もある。
しかしながら、現在のトランスコーディングの処理手順では、SDPオファー又はSDPアンサー送信側でトランスコーディングを実行できるが、1callを通してトランスコーディングの実行位置を発側又は着側に固定することはできない。
本発明は、上記事情を鑑みてなされたものであり、トランスコーディングを実行するネットワーク(発側、着側)を固定することを目的とする。
以上の課題を解決するため、本発明に係る通信方法は、複数の通信装置で行う通信方法において、前記通信装置は、いずれの側の通信装置でメディアデータのトランスコーディングを実行すべきかを要求するパラメータ情報をSDP(Session Description Protocol)に設定する第1のステップと、前記SDPに設定されたパラメータ情報に自側の通信装置が要求されている場合、自通信装置でメディアデータのトランスコーディングを実行する第2のステップと、を行うことを要旨とする。
本発明に係る通信方法は、上記通信方法において、前記第1のステップでは、前記パラメータ情報で要求された自側の通信装置で前記トランスコーディングを行わない場合、前記パラメータ情報を他側の通信装置に変更することを要旨とする。
請求項1に係る通信方法は、複数の通信装置で行う通信方法において、前記通信装置は、メディアデータのトランスコーディングを行う場合、SDP(Session Description Protocol)ネゴシエーションで決定した使用中のコーデック種別をコーデック情報記憶部に記憶する第1のステップと、SDPオファーを含むSIP(Session Initiation Protocol)メッセージを受信する第2のステップと、転送先で使用中のコーデック種別を含めた前記SDPオファーを含む前記SIPメッセージを送信する第3のステップと、を行うことを要旨とする。
請求項2に係る通信方法は、請求項1に記載の通信方法において、前記第3のステップでは、前記受信したSIPメッセージのSDPオファーに転送元で使用中のコーデック種別が含まれている場合、転送先で使用中のコーデック種別を前記送信するSIPメッセージのSDPオファーに含めることを要旨とする。
請求項3に係る通信方法は、請求項1に記載の通信方法において、前記第3のステップでは、前記受信したSIPメッセージのSDPオファーに転送元で使用中のコーデック種別が含まれていない場合、当該SDPオファーに含まれるコーデック種別と転送先で使用中のコーデック種別との間でトランスコーディング可能であれば、転送先で使用中のコーデック種別を前記送信するSIPメッセージのSDPオファーに含めることを要旨とする。
本発明に係る通信方法は、複数の通信装置で行う通信方法において、前記通信装置は、SDP(Session Description Protocol)ネゴシエーションで決定した使用中のコーデック種別をコーデック情報記憶部に記憶するステップと、メディアデータのトランスコーディングを行わない場合であって、転送元で使用中のコーデック種別を含むSDPオファーを含むSIP(Session Initiation Protocol)メッセージを受信した場合、前記SDPオファーにコーデック種別を追加することなく前記SIPメッセージを転送するステップと、を行うことを要旨とする。
請求項4に係る通信装置は、メディアデータのトランスコーディングを行うトランスコーディング部と、SDP(Session Description Protocol)ネゴシエーションで決定した使用中のコーデック種別を記憶するコーデック情報記憶部と、SDPオファーを含むSIP(Session Initiation Protocol)メッセージを受信した場合、前記SIPメッセージを転送する際に、転送先で使用中のコーデック種別を前記SDPオファーに含めるSDP処理部と、を備えることを要旨とする。
本発明に係る通信装置は、SDP(Session Description Protocol)ネゴシエーションで決定した使用中のコーデック種別を記憶するコーデック情報記憶部と、メディアデータのトランスコーディングを行わない場合であって、転送元で使用中のコーデック種別を含むSDPオファーを含むSIP(Session Initiation Protocol)メッセージを受信した場合、前記SDPオファーにコーデック種別を追加することなく前記SIPメッセージを転送するSDP処理部と、を備えることを要旨とする。
請求項5に係る通信システムは、第1の通信装置と第2の通信装置とを備えた通信システムにおいて、前記第2の通信装置は、メディアデータのトランスコーディングを行うトランスコーディング部と、SDP(Session Description Protocol)ネゴシエーションで決定した使用中のコーデック種別を記憶するコーデック情報記憶部と、前記第1の通信装置からSDPオファーを含むSIP(Session Initiation Protocol)メッセージを受信した場合、前記SIPメッセージを転送する際に、転送先で使用中のコーデック種別を前記SDPオファーに含めるSDP処理部と、を備えることを要旨とする。
本発明に係る通信プログラムは、上記通信方法をコンピュータに実行させることを要旨とする。
本発明によれば、トランスコーディングを実行するネットワーク(発側、着側)を固定できる。
呼制御システムの全体構成及びSBCの機能ブロック構成を示す図である。 初回SDPオファー送信側でトランスコーディングを実行する場合のネゴシエーション動作の処理フローを示す図である。 初回SDPアンサー送信側でトランスコーディングを実行する場合のネゴシエーション動作の処理フローを示す図である。 トランスコーディングの実行を要求したIMS網でトランスコーディングが不可能な場合の再ネゴシエーション動作の処理フローを示す図である。 初回SDPオファー送信側でトランスコーディングを実行する場合の処理フローを示す図である。 初回SDPアンサー送信側でトランスコーディングを実行する場合の処理フローを示す図である。 トランスコーディングの処理手順を示す図である。 SDPオファー送信側で行うトランスコーディングの処理手順を示す図である。 SDPアンサー送信側で行うトランスコーディングの処理手順を示す図である。 SDPオファー送信側で行うトランスコーディングの処理手順(固定端末と移動端末との相互接続時の具体例)を示す図である。 SDPアンサー送信側で行うトランスコーディングの処理手順(固定端末と移動端末との相互接続時の具体例)を示す図である。 SDPオファー送信側とSDPアンサー送信側とで順次トランスコーディングが行われる場合の処理手順を示す図である。 SDPアンサー送信側とSDPオファー送信側とで順次トランスコーディングが行われる場合の処理手順を示す図である。 SDPオファー送信側とSDPアンサー送信側とで順次トランスコーディングが行われる場合の処理手順(固定端末と移動端末との相互接続時の具体例)を示す図である。 SDPアンサー送信側とSDPオファー送信側とで順次トランスコーディングが行われる場合の処理手順(固定端末と移動端末との相互接続時の具体例)を示す図である。
以下、トランスコーディングを実行するネットワーク(IMS網,SBC)を、初回SDPオファー送信側又は初回SDPアンサー送信側に固定する方法について2つの実施形態を説明する。
<第1の実施の形態>
第1の実施の形態では、1回目のSDPネゴシエーション(1回目のSDPオファー/アンサー)において、SDPオファー送信側のIMS網とSDPアンサー送信側のIMS網との間で、トランスコーディングを実行するIMS網をネゴシエーションにより決定する。
図1は、本実施の形態に係る呼制御システムの全体構成及びSBCの機能ブロック構成を示す図である。該呼制御システムは、相互通信を行うSBC1aとSBC1bとを備えて構成される。本実施の形態において、SBC1aは、初回SDPオファー送信側のIMS網(例えば、G.711μ−lawの音声コーデックのみサポートする固定端末を収容するIMS網)に設置される。一方、SBC1bは、初回SDPアンサー送信側のIMS網(例えば、AMRの音声コーデックのみサポートする移動端末を収容するIMS網)に設置される。なお、SBCは、セッションボーダーコントローラの略称であり、通常、IMS網の境界付近に設置された中間ノードをいう。以下、SBC1aとSBC1bの機能について説明する。
SBC1aとSBC1bとは、それぞれ、SDP処理部11と、トランスコーディング部12と、コーデック情報記憶部13と、を備えて構成される。
SDP処理部11は、SDPの書き換え処理(SDPにコーデックを追加・削除等する処理)等の従来機能に加え、トランスコーディングを実行するIMS網をネゴシエーションにより決定する機能を備える。具体的に、SDP処理部11は、いずれのIMS網(ネットワーク)でトランスコーディングを行うかを要求する情報要素(パラメータ情報)をSDPに設定し、SDPネゴシエーションを行うタイミングで、該情報要素を用いて他IMS網(SBC)との間でトランスコーディングを行うIMS網を決定する。
例えば、SBC1aは、他IMS網(SBC1b)にSDPオファーを送信する際に、自IMS網(SBC1a)でトランスコーディングを実行すると判断(要求)する場合、SDPオファー送信側でトランスコーディングを担うことを示す情報要素を設定する。例えば、該情報要素をトランスコーディング実行箇所指定パラメータ“transcoder”とし、該情報要素の値として“own-side”を設定する。一方、他IMS網(SBC1b)でトランスコーディングを担うことを希望(要求)する場合、SBC1aは、上記情報要素の値として“opposite-side”を設定する。該情報要素と該情報要素の値は、SIPのヘッダフィールドと該ヘッダフィールドの値、SDPの“attribute”等、任意の形態で用いることができる。
また、SBC1aが他IMS網(SBC1b)でトランスコーディングを担うことを希望(要求)した場合であっても、該他IMS網でトランスコーディングが不可能な場合、該他IMS網からSBC1aにトランスコーディングを担うことを希望してもよい。
それゆえ、SDP処理部11は、上記情報要素で要求されたIMS網でトランスコーディングを実行できない場合、該情報要素を該IMS網以外のIMS網に変更する機能を更に備える。
トランスコーディング部12は、メディアパケット(メディアデータ)をトランスコーディングする従来機能に加え、SDP処理部11によるトランスコーディング実行主体のネゴシエーション結果に応じてトランスコーディングを実行する又は実行しない機能を備える。具体的に、トランスコーディング部12は、トランスコーディングを実行するIMS網が自IMS網の場合にはトランスコーディングを実行し、トランスコーディングを実行するIMS網が他IMS網の場合にはトランスコーディングを実行しない。
コーデック情報記憶部13は、自IMS網(自SBC)又は自IMS網内の端末でトランスコーディング対応可能なコーデック情報(例えば、自IMS網でG.711μ−lawの音声コーデックをサポートする場合、G.711μ−law)、事業者間合意やSLA等で規定されたオペレータポリシーを記憶する従来機能に加え、SDPに設定する又は設定された上記情報要素をSDP処理部11又はトランスコーディング部12により読出可能又は参照可能に記憶する機能を備える。
なお、本発明において、トランスコーディングとは、主に音声・映像通信メディアのコーデック(符号化方式)を変換する機能・処理を指す。例えば、G.711μ−lawの音声コーデックをAMRの音声コーデックに変換すること、その逆変換を行うことをいう。ただし、G.711μ−lawやAMRはコーデックの一例であり、本発明は特定の種別のコーデックに限定されない。
ここまで、SBC1aとSBC1bの機能について概説した。ただ、実際に、トランスコーディングを実行するIMS網をネゴシエーションにより決定するには、SBC1aとSBC1bの機能を詳述する必要がある。そこで、SBC1a(初回SDPオファー送信側)とSBC1b(初回SDPアンサー送信側)とが行う具体的動作を表1,表2にそれぞれ例示する。SBC1aのSDP処理部11は、表1の記載内容に沿って動作・処理を行い、SBC1bのSDP処理部11は、表2の記載内容に沿って動作・処理を行う。
Figure 0006758472
Figure 0006758472
次に、トランスコーディングの実行主体(IMS網,SBC)を決定するネゴシエーション動作について説明する。
まず、図2を参照しながら、初回SDPオファー送信側のIMS網(SBC1a)でトランスコーディングを実行する場合のネゴシエーション動作について説明する。
まず、SBC1aは、自IMS網から初回SDPオファーを受信した後、オペレータポリシーに基づき自IMS網(SBC1a)でコーデック変換を行う場合、初回SDPオファーに設定されているコーデックリストに自IMS網又は自IMS網内の端末でトランスコーディング対応可能なコーデック(codec b)を追加し、初回SDPオファーに“own-side”を設定して、初回SDPオファーを他IMS網(SBC1b)へ送信する(ステップS101)。
次に、SBC1bは、SBC1aから初回SDPオファーを受信すると、初回SDPオファーに“own-side”が設定されているため、初回SDPオファーを自IMS網へ送信(透過)する(ステップS102)。このとき、SBC1bは、コーデック情報記憶部13に“own-side”を記憶し、初回SDPオファーから“own-side”を削除する。
その後、SBC1bのIMS網内の着側端末で自身が使用したいコーデックが決定される。具体的に、着信端末は、初回SDPオファー内のメディア条件(codec a, b)に自身が通信に利用可能なメディア条件があれば、そのメディア条件(codec b)を選択し、初回SDPアンサーに記載して返送する。
次に、SBC1bは、自IMS網から初回SDPアンサーを受信すると、前回受信したSDPオファーに“own-side”が設定されていたため、初回SDPアンサーに“opposite-side”を設定して、初回SDPアンサーを他IMS網(SBC1a)へ送信する(ステップS103)。
次に、SBC1aは、SBC1bから初回SDPアンサーを受信すると、初回SDPアンサーに、前回受信したSDPオファーに含まれていたコーデック(codec a)が含まれておらず、前回送信した自身が追加したコーデック(codec b)が含まれているため、前回受信した初回SDPオファーに含まれていたコーデック(codec aのみ)の中からコーデックを1つ選択し、該コーデックを初回SDPアンサーに設定して、初回SDPアンサーを自IMS網へ送信する(ステップS104)。
ここまでの処理により、1回目のSDPネゴシエーションにおいて、SBC1aとSBC1bとの間でやり取りされた“own-side”と“opposite-side”とに基づき、トランスコーディングの実行主体を初回SDPオファー送信側のIMS網(SBC1a)に決定できる。例えば、SBC1bは、SBC1aが設定した“own-side”を参照することにより、自身でトランスコーディングを実行せず、SBC1aでトランスコーディングを実行することを把握できる。なお、SBC1aは、ステップS101で自身が設定した“own-side”、ステップS104でSBC1bが設定した“opposite-side”を保存し、それらを参照することにより、自身でトランスコーディングを実行することを把握してもよい。
その後、SBC1aは、他IMS網(SBC1b)からメディアパケットが送信された場合、“codec b→a”のトランスコーディングを実行して自IMS網へ送信し、自IMS網からメディアパケットが送信された場合、“codec a→b”のトランスコーディングを実行して他IMS網へ送信する(ステップS105)。
引き続き、後続SDPオファーが初回SDPアンサー送信側のIMS網で発生した場合について説明する。
SBC1bは、自IMS網から後続SDPオファーを受信すると、トランスコーディングの実行主体は自身でないため、後続SDPオファーに設定されているコーデックリストにコーデックを追加せず、後続SDPオファーに“opposite-side”を設定して、後続SDPオファーを他IMS網(SBC1a)へ送信する(ステップS106)。
次に、SBC1aは、SBC1bから後続SDPオファーを受信すると、トランスコーディングの実行主体は自身であるため、後続SDPオファーに設定されているコーデックリストに自IMS網又は自IMS網内の端末でトランスコーディング対応可能なコーデック(codec a)を追加し、後続SDPオファーを自IMS網へ送信する(ステップS107)。
なお、ステップS107において、SBC1aは、SBC1bから後続SDPオファーを受信した際、既に自身でトランスコーディングを実行している場合、自IMS網で利用しているコーデック(codec a)を追加対象コーデックに最低限含める。
また、ステップS107において、SBC1aは、1回目のSDPネゴシエーションの決定結果に依らず、後続SDPオファーに設定された“opposite-side”又はオペレータポリシーに基づき、トランスコーディングの実行主体が自身であることを新たに決定してもよい。
次に、SBC1aは、自IMS網から後続SDPアンサーを受信すると、後続SDPアンサーに、前回受信したSDPオファーに含まれていたコーデック(codec b)が含まれておらず、前回送信した自身が追加したコーデック(codec a)が含まれているため、前回受信したSDPオファーに含まれていたコーデック(codec bのみ)の中からコーデックを1つ選択し、該コーデックを後続SDPアンサーに設定して、後続SDPアンサーを他IMS網(SBC1b)へ送信する(ステップS108)。このとき、SBC1aは、前回受信したSDPオファーに“opposite-side”が設定されていたため、後続SDPオファーに“own-side”を設定する。
次に、SBC1bは、SBC1aから後続SDPアンサーを受信すると、後続SDPアンサーに、前回受信したSDPオファーに含まれていたコーデック(codec b)が含まれているため、後続SDPアンサーを自IMS網へ送信(透過)する(ステップS109)。
その後、SBC1aは、他IMS網(SBC1b)からメディアパケットが送信された場合、“codec b→a”のトランスコーディングを実行して自IMS網へ送信し、自IMS網からメディアパケットが送信された場合、“codec a→b”のトランスコーディングを実行して他IMS網へ送信する(ステップS110)。
ステップS106〜S110の処理により、後続SDPオファーが初回SDPアンサー送信側のIMS網で発生した場合であっても、初回SDPオファー送信側のIMS網(SBC1a)でトランスコーディングを継続できる。
次に、図3を参照しながら、初回SDPアンサー送信側のIMS網(SBC1b)でトランスコーディングを実行する場合のネゴシエーション動作について説明する。
まず、SBC1aは、自IMS網から初回SDPオファーを受信した後、オペレータポリシーに基づき自IMS網(SBC1a)でコーデック変換を行わない場合、初回SDPオファーに設定されているコーデックリストにコーデックを追加せず、初回SDPオファーに“opposite-side”を設定して、初回SDPオファーを他IMS網(SBC1b)へ送信する(ステップS201)。
次に、SBC1bは、SBC1aから初回SDPオファーを受信すると、初回SDPオファーに“opposite-side”が設定されており、かつ、オペレータポリシーに基づき自IMS網(SBC1b)でコーデック変換を行う場合、初回SDPオファーに設定されているコーデックリストに自IMS網又は自IMS網内の端末でトランスコーディング対応可能なコーデック(codec b)を追加して、初回SDPオファーを自IMS網へ送信する(ステップS202)。
その後、SBC1bのIMS網内の着側端末で自身が使用したいコーデックが決定される。具体的に、着信端末は、初回SDPオファー内のメディア条件(codec a, b)に自身が通信に利用可能なメディア条件があれば、そのメディア条件(codec b)を選択し、初回SDPアンサーに記載して返送する。
次に、SBC1bは、自IMS網から初回SDPアンサーを受信すると、前回受信したSDPオファーに“opposite-side”が設定されていたため、初回SDPアンサーに“own-side”を設定して、初回SDPアンサーを他IMS網(SBC1a)へ送信する(ステップS203)。
次に、SBC1aは、SBC1bから初回SDPアンサーを受信すると、初回SDPアンサーに、前回受信したSDPオファーに含まれていたコーデック(codec a)が含まれているため、初回SDPアンサーを自IMS網へ送信(透過)する(ステップS204)。
ここまでの処理により、1回目のSDPネゴシエーションにおいて、SBC1aとSBC1bとの間でやり取りされた“own-side”と“opposite-side”とに基づき、トランスコーディングの実行主体を初回SDPアンサー送信側のIMS網(SBC1b)に決定できる。勿論、SBC1bは、SBC1aが設定した“opposite-side”を保存し、それを参照することにより、自身でトランスコーディングを実行することを把握してもよい。また、SBC1aは、SBC1bが設定した“own-side”を保存し、それを参照することにより、自身はトランスコーディングを実行せず、SBC1bでトランスコーディングを実行することを把握してもよい。
その後、SBC1bは、自IMS網からメディアパケットが送信された場合、“codec b→a”のトランスコーディングを実行して他IMS網(SBC1a)へ送信し、他IMS網からメディアパケットが送信された場合、“codec a→b”のトランスコーディングを実行して自IMS網へ送信する(ステップS205)。
引き続き、後続SDPオファーが初回SDPアンサー送信側のIMS網で発生した場合について説明する。
SBC1bは、自IMS網から後続SDPオファーを受信すると、トランスコーディングの実行主体は自身であるため、後続SDPオファーに設定されているコーデックリストに自IMS網又は自IMS網内の端末でトランスコーディング対応可能なコーデック(codec a)を追加し、後続SDPオファーに“own-side”を設定して、後続SDPオファーを他IMS網(SBC1a)へ送信する(ステップS206)。
次に、SBC1aは、SBC1bから後続SDPオファーを受信すると、トランスコーディングの実行主体は自身でないため、後続SDPオファーに設定されているコーデックリストにコーデックを追加せず、後続SDPオファーから“own-side”を削除して、後続SDPオファーを自IMS網へ送信する(ステップS207)。
次に、SBC1aは、自IMS網から後続SDPアンサーを受信すると、後続SDPアンサーに、前回受信したSDPオファーに含まれていたコーデック(codec a)が含まれているため、後続SDPアンサーを他IMS網(SBC1b)へ送信(透過)する(ステップS208)。このとき、SBC1aは、前回受信したSDPオファーに“own-side”が設定されていたため、後続SDPオファーに“opposite-side”を設定する。
次に、SBC1bは、SBC1aから後続SDPアンサーを受信すると、後続SDPアンサーに、前回受信したSDPオファーに含まれていたコーデック(codec b)が含まれておらず、前回送信した自身が追加したコーデック(codec a)が含まれているため、前回受信したSDPオファーに含まれていたコーデック(codec bのみ)の中からコーデックを1つ選択し、該コーデックを後続SDPアンサーに設定して、後続SDPアンサーを自IMS網へ送信する(ステップS209)。
その後、SBC1bは、自IMS網からメディアパケットが送信された場合、“codec b→a”のトランスコーディングを実行して他IMS網(SBC1a)へ送信し、他IMS網からメディアパケットが送信された場合、“codec a→b”のトランスコーディングを実行して自IMS網へ送信する(ステップS210)。
ステップS206〜S210の処理により、後続SDPオファーが初回SDPアンサー送信側のIMS網で発生した場合であっても、初回SDPアンサー送信側のIMS網(SBC1b)でトランスコーディングを継続できる。
次に、図4を参照しながら、トランスコーディングの実行を要求されたIMS網でトランスコーディングが不可能な場合の再ネゴシエーション動作について説明する。
まず、SBC1aは、自IMS網から初回SDPオファーを受信した後、オペレータポリシーに基づき自IMS網(SBC1a)でコーデック変換を行わない場合、初回SDPオファーに設定されているコーデックリストにコーデックを追加せず、初回SDPオファーに“opposite-side”を設定して、初回SDPオファーを他IMS網(SBC1b)へ送信する(ステップS301)。
次に、SBC1bは、SBC1aから初回SDPオファーを受信すると、初回SDPオファーに“opposite-side”が設定されているが、オペレータポリシーに基づき自IMS網(SBC1b)でコーデック変換を行わない場合、初回SDPオファーを自IMS網へ送信(透過)する(ステップS302)。
その後、SBC1bのIMS網内の着側端末で自身が使用したいコーデックが決定される。具体的に、着信端末は、初回SDPオファー内のメディア条件(codec a)に自身が通信に利用可能なメディア条件がない場合、488応答(=Not Acceptable response;エラーレスポンス)にSDPを設定し、SDPに自身が通信に利用したいメディア条件(codec b)を記載して返送する。
次に、SBC1bは、自IMS網から488応答に設定されたSDPを受信すると、前回受信したSDPオファーに“opposite-side”が設定されていたが、488応答のため、SDPに“opposite-side”を設定して、SDPを他IMS網(SBC1a)へ送信する(ステップS303)。
なお、ステップS303では、形式的には同じ情報要素の値“opposite-side”をSDPに設定しているが、実質的にはトランスコーディングの実行主体をSBC1bからSBC1aへ変更要求している。
次に、SBC1aは、SBC1bからSDPを受信すると、SDPに“opposite-side”が設定されているが、このタイミングではステップS301と同様に自IMS網(SBC1a)でコーデック変換を行わないため、SDPを自IMS網へ送信(透過)する(ステップS304)。
その後、SBC1aのIMS網内の発信端末から、再度、同じコーデック(codec a)が設定された2回目の初回SDPオファーが送信されるものとする。
次に、SBC1aは、自IMS網から2回目の初回SDPオファーを受信すると、ステップS301ではコーデック変換を行わない予定であったが、他IMS網から前回受信したSDPに“opposite-side”が設定され、かつ、自身でトランスコーディング可能である場合、2回目の初回SDPオファーに設定されているコーデックリストに自IMS網又は自IMS網内の端末でトランスコーディング対応可能なコーデック(codec b)を追加し、2回目の初回SDPオファーに“own-side”を設定して、2回目の初回SDPオファーを他IMS網(SBC1b)へ送信する(ステップS305)。
これ以降のステップS306〜ステップS309は、上述したステップS102〜S105と同じである。
本実施の形態によれば、複数のIMS網(SBC1aとSBC1b)が、いずれのIMS網でトランスコーディングを行うかを要求する情報要素をSDPに設定し、該情報要素を用いてIMS網間(SBC1aとSBC1b間)でトランスコーディングを行うIMS網(SBC1a又はSBC1b)を決定し、決定されたIMS網でメディアデータのトランスコーディングを実行するので、トランスコーディングを実行するIMS網を固定できる。
これにより、莫大なリソースを消費するトランスコーディングの実行場所・実行主体を初回SDPオファー送信側又は初回SDPアンサー送信側に固定できるので、通信事業者にとって必要となるリソースの予測と設備設計が可能となり、通信事業者間でのアクセスチャージの整理が容易となる。
また、本実施の形態によれば、SDPの情報要素で要求されたIMS網でトランスコーディングを実行できない場合、該情報要素を該IMS網以外のIMS網に変更するので、トランスコーディングを実行するIMS網(SBC)を適切に変更できる。これにより、あるIMS網でトランスコーディングを実行できない場合であっても、他のいずれかのIMS網でトランスコーディングを実行できるので、発着端末間での呼接続確立を向上できる。
<第2の実施の形態>
第2の実施の形態では、SDPオファー送信側及び/又はSDPアンサー送信側で、自IMS網の両側との間で最後のSDPネゴシエーションにより決定されたコーデック情報をセッション関連情報要素として管理することにより、トランスコーディングを継続する。
本実施の形態に係る呼制御システムの全体構成及びSBC1a,1bの機能ブロック構成は、図1に示した第1の実施の形態と同様である。
SDP処理部11は、SDPの書き換え処理(コーデックをSDPに追加・削除等する処理)等の従来機能を備える。
コーデック情報記憶部13は、自IMS網(自SBC)又は自IMS網内の端末でトランスコーディング対応可能なコーデック情報を記憶する従来機能に加え、SDPネゴシエーションで決定された変換前後のコーデック情報をセッション関連情報要素として記憶する機能を備える。
トランスコーディング部12は、メディアパケット(メディアデータ)をトランスコーディングする従来機能に加え、コーデック情報記憶部13のセッション関連情報要素に基づきトランスコーディングを実行する又は実行しない機能を備える。具体的に、トランスコーディング部12は、受信したSDPに、セッション関連情報要素で管理している変換後のコーデック情報が含まれていない場合、トランスコーディングを実行し、変換後のコーデック情報が含まれている場合、トランスコーディングを実行しない。
ここまで、SBC1aとSBC1bとの機能について概説した。なお、より具体的には、SBC1aとSBC1bの各SDP処理部11は、表3,表4に例示する動作内容に沿って動作・処理を行う。
Figure 0006758472
Figure 0006758472
次に、図5を参照しながら、初回SDPオファー送信側のIMS網(SBC1a)でトランスコーディングを実行する場合の動作について説明する。
まず、SBC1aは、自IMS網から初回SDPオファーを受信した後、自IMS網でコーデック変換を行う場合、初回SDPオファーに設定されているコーデックリストに自IMS網又は自IMS網内の端末でトランスコーディング対応可能なコーデック(codec b)を追加して、初回SDPオファーを他IMS網(SBC1b)へ送信する(ステップS401)。
次に、SBC1bは、SBC1aから初回SDPオファーを受信すると、自IMS網でコーデック変換を行わない場合、初回SDPオファーに設定されているコーデックリストにコーデックを追加せず、初回SDPオファーを自IMS網へ送信(透過)する(ステップS402)。
その後、SBC1bのIMS網内の着側端末で自身が使用したいコーデックが決定される。具体的に、着信端末は、初回SDPオファー内のメディア条件(codec a, b)に自身が通信に利用可能なメディア条件があれば、そのメディア条件(codec b)を選択し、初回SDPアンサーに記載して返送する。
次に、SBC1bは、自IMS網から初回SDPアンサーを受信すると、初回SDPアンサーに、前回受信したSDPオファーに含まれていたコーデックが含まれているため、初回SDPアンサーを他IMS網(SBC1a)へ送信(透過)する(ステップS403)。このとき、SBC1bは、受信したコーデック(Codec b)の情報と、送信したコーデック(Codec b)の情報とを保存する。特に、SBC1bは、送信したコーデック(Codec b)の情報を変換後のコーデック情報として管理する。
次に、SBC1aは、SBC1bから初回SDPアンサーを受信すると、初回SDPアンサーに、前回受信したSDPオファーに含まれていたコーデック(codec a)が含まれておらず、前回送信した自身が追加したコーデック(codec b)が含まれているため、前回受信した初回SDPオファーに含まれていたコーデック(codec aのみ)の中からコーデックを1つ選択し、該コーデックを初回SDPアンサーに設定して、初回SDPアンサーを自IMS網へ送信する(ステップS404)。このとき、SBC1aは、受信したコーデック(Codec b)の情報と、送信したコーデック(Codec a)の情報とを保存する。特に、SBC1bは、送信したコーデック(Codec a)の情報を変換後のコーデック情報として管理する。
その後、SBC1aは、他IMS網(SBC1b)からメディアパケットが送信された場合、“codec b→a”のトランスコーディングを実行して自IMS網へ送信し、自IMS網からメディアパケットが送信された場合、“codec a→b”のトランスコーディングを実行して他IMS網へ送信する(ステップS405)。
引き続き、後続SDPオファーが初回SDPアンサー送信側のIMS網で発生した場合について説明する。
SBC1bは、自IMS網から後続SDPオファーを受信すると、自身と自身に対向する対向IMS網(SBC1a)間で前回のSDPネゴシエーションにより決定されたコーデック(ステップS403で保存していた変換後のコーデック(Codec b))が、後続SDPオファーに含まれているため、後続SDPオファーを他IMS網(SBC1a)へ送信(透過)する(ステップS406)。
次に、SBC1aは、SBC1bから後続SDPオファーを受信すると、自身と自IMS網内装置(発側端末等)間で前回のSDPネゴシエーションにより決定されたコーデック(ステップS404で保存していた変換後のコーデック(Codec a))が、後続SDPオファーに含まれていないため、また、前回のSDPネゴシエーションで決定されたコーデック(Codec a)と後続SDPオファーに含まれるコーデック(Codec b)間でトランスコーディング可能なため、前回のSDPネゴシエーションで決定されたコーデック(Codec a)を追加して、後続SDPオファーを自IMS網へ送信する(ステップS407)。
次に、SBC1aは、自IMS網から後続SDPアンサーを受信すると、後続SDPアンサーに、前回受信したSDPオファーに含まれていたコーデック(codec b)が含まれておらず、前回送信した自身が追加したコーデック(codec a)が含まれているため、前回受信したSDPオファーに含まれていたコーデック(codec bのみ)の中からコーデックを1つ選択し、該コーデックを後続SDPアンサーに設定して、後続SDPアンサーを他IMS網(SBC1b)へ送信する(ステップS408)。
次に、SBC1bは、SBC1aから後続SDPアンサーを受信すると、後続SDPアンサーに、前回受信したSDPオファーに含まれていたコーデック(codec b)が含まれているため、後続SDPアンサーを自IMS網へ送信(透過)する(ステップS409)。
その後、SBC1aは、他IMS網(SBC1b)からメディアパケットが送信された場合、“codec b→a”のトランスコーディングを実行して自IMS網へ送信し、自IMS網からメディアパケットが送信された場合、“codec a→b”のトランスコーディングを実行して他IMS網へ送信する(ステップS410)。
次に、図6を参照しながら、初回SDPアンサー送信側のIMS網(SBC1b)でトランスコーディングを実行する場合の動作について説明する。
まず、SBC1aは、自IMS網から初回SDPオファーを受信した後、自IMS網でコーデック変換を行わない場合、初回SDPオファーに設定されているコーデックリストにコーデックを追加せず、初回SDPオファーを他IMS網(SBC1b)へ送信する(ステップS501)。
次に、SBC1bは、SBC1aから初回SDPオファーを受信すると、自IMS網でコーデック変換を行う場合、初回SDPオファーに設定されているコーデックリストに自IMS網又は自IMS網内の端末でトランスコーディング対応可能なコーデック(codec b)を追加して、初回SDPオファーを自IMS網へ送信する(ステップS502)。
その後、SBC1bのIMS網内の着側端末で自身が使用したいコーデックが決定される。具体的に、着信端末は、初回SDPオファー内のメディア条件(codec a, b)に自身が通信に利用可能なメディア条件があれば、そのメディア条件(codec b)を選択し、初回SDPアンサーに記載して返送する。
次に、SBC1bは、自IMS網から初回SDPアンサーを受信すると、初回SDPアンサーに、前回受信したSDPオファーに含まれていたコーデック(codec a)が含まれておらず、前回送信した自身が追加したコーデック(codec b)が含まれているため、前回受信した初回SDPオファーに含まれていたコーデック(codec aのみ)の中からコーデックを1つ選択し、該コーデックを初回SDPアンサーに設定して、初回SDPアンサーを他IMS網(SBC1a)へ送信する(ステップS503)。このとき、SBC1bは、受信したコーデック(Codec b)の情報と、送信したコーデック(Codec a)の情報とを保存する。特に、SBC1bは、送信したコーデック(Codec a)の情報を変換後のコーデック情報として管理する。
次に、SBC1aは、SBC1bから初回SDPアンサーを受信すると、初回SDPアンサーに、前回受信したSDPオファーに含まれていたコーデック(codec a)が含まれているため、初回SDPアンサーを自IMS網へ送信(透過)する(ステップS504)。このとき、SBC1aは、受信したコーデック(Codec a)の情報と、送信したコーデック(Codec a)の情報とを保存する。特に、SBC1aは、送信したコーデック(Codec a)の情報を変換後のコーデック情報として管理する。
その後、SBC1bは、自IMS網からメディアパケットが送信された場合、“codec b→a”のトランスコーディングを実行して他IMS網(SBC1a)へ送信し、他IMS網からメディアパケットが送信された場合、“codec a→b”のトランスコーディングを実行して自IMS網へ送信する(ステップS505)。
引き続き、後続SDPオファーが初回SDPアンサー送信側のIMS網で発生した場合について説明する。
SBC1bは、自IMS網から後続SDPオファーを受信すると、自身と自に対向する対向IMS網(SBC1a)間で前回のSDPネゴシエーションにより決定されたコーデック(ステップS503で保存していた変換後のコーデック(Codec a))が、後続SDPオファーに含まれていないため、また、前回のSDPネゴシエーションで決定されたコーデック(Codec a)と後続SDPオファーに含まれるコーデック(Codec b)間でトランスコーディング可能なため、前回のSDPネゴシエーションで決定されたコーデック(Codec a)を追加して、後続SDPオファーを他IMS網(SBC1a)へ送信する(ステップS506)。
次に、SBC1aは、SBC1bから後続SDPオファーを受信すると、自身と自IMS網内装置(発側端末等)間で前回のSDPネゴシエーションにより決定されたコーデック(ステップS504で保存していた変換後のコーデック(Codec a))が、後続SDPオファーに含まれているため、後続SDPオファーを自IMS網へ送信(透過)する(ステップS507)。
次に、SBC1aは、自IMS網から後続SDPアンサーを受信すると、後続SDPアンサーに、前回受信したSDPオファーに含まれていたコーデック(codec a)が含まれているため、後続SDPアンサーを他IMS網(SBC1b)へ送信(透過)する(ステップS508)。
次に、SBC1bは、SBC1aから後続SDPアンサーを受信すると、後続SDPアンサーに、前回受信したSDPオファーに含まれていたコーデック(codec b)が含まれておらず、前回送信した自身が追加したコーデック(codec a)が含まれているため、前回受信したSDPオファーに含まれていたコーデック(codec bのみ)の中からコーデックを1つ選択し、該コーデックを後続SDPアンサーに設定して、後続SDPアンサーを自IMS網へ送信する(ステップS509)。
その後、SBC1bは、自IMS網からメディアパケットが送信された場合、“codec b→a”のトランスコーディングを実行して他IMS網(SBC1a)へ送信し、他IMS網からメディアパケットが送信された場合、“codec a→b”のトランスコーディングを実行して自IMS網へ送信する(ステップS510)。
本実施の形態によれば、複数のIMS網(SBC1aとSBC1b)が、それぞれ、SDPネゴシエーションで決定された変換後のコーデック情報を記憶し、受信したSDPに変換後のコーデック情報が含まれていない場合、自身のIMS網(SBC1a又はSBC1b)でメディアデータのトランスコーディングを実行するので、トランスコーディングを実行するIMS網を固定できる。
これにより、莫大なリソースを消費するトランスコーディングの実行場所・実行主体を初回SDPオファー送信側又は初回SDPアンサー送信側に固定できるので、通信事業者にとって必要となるリソースの予測と設備設計が可能となり、通信事業者間でのアクセスチャージの整理が容易となる。
最後に、本実施の形態で説明したSBC1aとSBC1bは、CPU、メモリ、ハードディスク等を備えたコンピュータ(情報処理装置)で実現できる。また、SBC1aとSBC1bとしてコンピュータを機能させるためのプログラム(呼制御プログラム)や該プログラムの記憶媒体を作成することも可能である。
最後に、表3及び表4について補足する。第2の実施の形態では、表3又は表4の「SDPオファー」の「後続」に対応する動作説明欄内に記載されているように、「その決定されたコーデックが含まれておらず、さらに、その前回ネゴシエーションされたコーデックと、受信したSDPオファーに含まれるコーデック間でトランスコーディングが可能な場合、その前回ネゴシエーションされたコーデックを追加する」、処理を行う。
当該処理については、例えば、“トランスコーディングを行っているSBC1aにおいて、SBC1bからのSDPオファーに前回決定されたコーデック(Codec b)が含まれておらず、前回のネゴシエーション(S401〜S404)で決定されたコーデック(Codec a)と、受信したSDPオファーに含まれるコーデック(例えば、Codec c)との間でトランスコーディング可能な場合、前回ネゴシエーションされたコーデック(Codec a)をSDPオファーに追加する”、等の処理が考えられる。この場合、SBC1aは、例えばトランスコーディング可能リスト等を予め保持しておき、当該トランスコーディング可能リストに“Codec a”のコーデック種別と“Codec c”のコーデック種別とが関連付けられていれば、トランスコーディング可能と判定する。
すなわち、SBC1(通信装置)は、表3又は表4に基づき、“自通信装置がトランスコーディングを行っており、かつ、前回決定されたコーデック(Codec b)が含まれていないSDPオファーを含むSIPメッセージを受信した場合、当該SDPオファーに含まれるコーデック(例えば、Codec c)と転送先で使用中のコーデック(Codec a)との間でトランスコーディング可能であれば、転送先で使用中のコーデック(Codec a)をSDPオファーのコーデックリストに追加する”、処理も可能である。
なお、トランスコーディング可能リストは、SBC1がトランスコーディング可能なコーデック種別を把握するための一例である。
1(1a,1b)…SBC
11…SDP処理部
12…トランスコーディング部
13…コーデック情報記憶部

Claims (5)

  1. 複数の通信装置で行う通信方法において、
    前記通信装置は、メディアデータのトランスコーディングを行う場合、
    SDP(Session Description Protocol)ネゴシエーションで決定した使用中のコーデック種別をコーデック情報記憶部に記憶する第1のステップと、
    SDPオファーを含むSIP(Session Initiation Protocol)メッセージを受信する第2のステップと、
    転送先で使用中のコーデック種別を含めた前記SDPオファーを含む前記SIPメッセージを送信する第3のステップと、
    を行うことを特徴とする通信方法。
  2. 前記第3のステップでは、
    前記受信したSIPメッセージのSDPオファーに転送元で使用中のコーデック種別が含まれている場合、転送先で使用中のコーデック種別を前記送信するSIPメッセージのSDPオファーに含めることを特徴とする請求項1に記載の通信方法。
  3. 前記第3のステップでは、
    前記受信したSIPメッセージのSDPオファーに転送元で使用中のコーデック種別が含まれていない場合、当該SDPオファーに含まれるコーデック種別と転送先で使用中のコーデック種別との間でトランスコーディング可能であれば、転送先で使用中のコーデック種別を前記送信するSIPメッセージのSDPオファーに含めることを特徴とする請求項1に記載の通信方法。
  4. メディアデータのトランスコーディングを行うトランスコーディング部と、
    SDP(Session Description Protocol)ネゴシエーションで決定した使用中のコーデック種別を記憶するコーデック情報記憶部と、
    SDPオファーを含むSIP(Session Initiation Protocol)メッセージを受信した場合、前記SIPメッセージを転送する際に、転送先で使用中のコーデック種別を前記SDPオファーに含めるSDP処理部と、
    を備えることを特徴とする通信装置。
  5. 第1の通信装置と第2の通信装置とを備えた通信システムにおいて、
    前記第2の通信装置は、
    メディアデータのトランスコーディングを行うトランスコーディング部と、
    SDP(Session Description Protocol)ネゴシエーションで決定した使用中のコーデック種別を記憶するコーデック情報記憶部と、
    前記第1の通信装置からSDPオファーを含むSIP(Session Initiation Protocol)メッセージを受信した場合、前記SIPメッセージを転送する際に、転送先で使用中のコーデック種別を前記SDPオファーに含めるSDP処理部と、
    を備えることを特徴とする通信システム。
JP2019208007A 2016-07-14 2019-11-18 通信方法、通信装置及び通信システム Active JP6758472B2 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2016139714 2016-07-14
JP2016139714 2016-07-14

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2018527680A Division JP6636157B2 (ja) 2016-07-14 2017-07-14 通信方法及び通信プログラム

Publications (2)

Publication Number Publication Date
JP2020025346A JP2020025346A (ja) 2020-02-13
JP6758472B2 true JP6758472B2 (ja) 2020-09-23

Family

ID=60952102

Family Applications (3)

Application Number Title Priority Date Filing Date
JP2018527680A Active JP6636157B2 (ja) 2016-07-14 2017-07-14 通信方法及び通信プログラム
JP2019208008A Active JP6880421B2 (ja) 2016-07-14 2019-11-18 通信方法、通信装置及び通信システム
JP2019208007A Active JP6758472B2 (ja) 2016-07-14 2019-11-18 通信方法、通信装置及び通信システム

Family Applications Before (2)

Application Number Title Priority Date Filing Date
JP2018527680A Active JP6636157B2 (ja) 2016-07-14 2017-07-14 通信方法及び通信プログラム
JP2019208008A Active JP6880421B2 (ja) 2016-07-14 2019-11-18 通信方法、通信装置及び通信システム

Country Status (3)

Country Link
US (5) US11012478B2 (ja)
JP (3) JP6636157B2 (ja)
WO (1) WO2018012615A1 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113453081A (zh) * 2020-03-28 2021-09-28 华为技术有限公司 视频传输方法、系统、相关设备及存储介质
EP3965389B1 (en) * 2020-09-08 2022-07-27 Deutsche Telekom AG Method of adaptive transcoding optimization for multimedia communication and communication system

Family Cites Families (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6359902B1 (en) * 1998-08-18 2002-03-19 Intel Corporation System for translation and delivery of multimedia streams
US20040037312A1 (en) * 2002-08-23 2004-02-26 Spear Stephen L. Method and communication network for operating a cross coding element
US8199727B1 (en) * 2003-11-17 2012-06-12 Ericsson Ab Call delivery in a CDMA legacy MS domain for SIP call origination
US7751359B1 (en) * 2003-11-26 2010-07-06 Ericsson Ab Call origination in a CDMA legacy MS domain using SIP
WO2005104574A1 (en) * 2004-04-16 2005-11-03 Nortel Networks Limited System and method for providing early ringback by a home legacy mobile station domain network
US7617319B2 (en) * 2005-06-30 2009-11-10 Motorola, Inc. Method and system for optimizing transcoder resources
US20070047707A1 (en) * 2005-08-26 2007-03-01 Net2Phone, Inc. IP-enhanced cellular services
US7944862B2 (en) * 2005-11-09 2011-05-17 Onmobile Global Limited Accelerated session establishment in a multimedia gateway
KR100800748B1 (ko) * 2006-07-28 2008-02-01 삼성전자주식회사 블루투스를 이용한 동영상 스트림 전송 장치 및 방법
CN101155191B (zh) * 2006-09-25 2011-06-08 华为技术有限公司 支持ims终端享用现有iptv业务的系统和方法
KR100744567B1 (ko) * 2006-09-29 2007-08-01 한국전자통신연구원 멀티 네트워크 멀티 코덱 환경에서 트랜스코딩 횟수를최소화하는 장치 및 방법
US8139541B2 (en) * 2006-12-15 2012-03-20 Alcatel Lucent Method and system for bypassing media gateways in wireless networks
CN101584248B (zh) * 2007-01-18 2013-01-02 艾利森电话股份有限公司 沿复杂的呼叫路径控制编解码器选择的技术
WO2008098249A1 (en) * 2007-02-09 2008-08-14 Dilithium Networks Pty Ltd. Method and apparatus for the adaptation of multimedia content in telecommunications networks
US7940793B2 (en) * 2007-04-24 2011-05-10 Avaya Communication Israel Ltd Media application
US8893204B2 (en) * 2007-06-29 2014-11-18 Microsoft Corporation Dynamically adapting media streams
US8776161B2 (en) * 2008-02-12 2014-07-08 Ciena Corporation Systems and methods for video processing in network edge devices
WO2010085470A1 (en) * 2009-01-20 2010-07-29 Ripcode, Inc. System and method for splicing media files
JP5001983B2 (ja) * 2009-07-21 2012-08-15 株式会社エヌ・ティ・ティ・ドコモ 通信制御システム、及び通信制御方法
CN102055741B (zh) * 2009-11-06 2013-08-14 华为终端有限公司 媒体会话协商的方法、设备及系统
JP2011166453A (ja) 2010-02-09 2011-08-25 Nippon Telegr & Teleph Corp <Ntt> SIP(SessionInitiationProtocol)中継装置、パケット変換装置、ネットワークシステム、制御方法及び制御プログラム
JP2012105211A (ja) * 2010-11-12 2012-05-31 Ntt Docomo Inc コアネットワークおよび通信システム
JP5679577B2 (ja) * 2011-06-28 2015-03-04 日本電信電話株式会社 中継システム及び中継網のコーディック選択方法
ES2668796T3 (es) * 2011-11-02 2018-05-22 Nokia Solutions And Networks Oy Método y aparato para indicar un tipo de una interfaz de red
US8923880B2 (en) * 2012-09-28 2014-12-30 Intel Corporation Selective joinder of user equipment with wireless cell
US9356987B2 (en) * 2012-10-09 2016-05-31 Vantrix Corporation System and method for optimizing a communication session between multiple terminals involving transcoding operations
US20150045041A1 (en) * 2013-08-12 2015-02-12 Qualcomm Incorporated Devices and methods for establishing transcoder-free communication paths with multi-sim devices
US9961116B2 (en) * 2014-11-26 2018-05-01 Edgewater Networks, Inc. Method and system for providing remote transcoding of media data on a VOIP system
US9992643B2 (en) * 2016-07-06 2018-06-05 Verizon Patent And Licensing Inc. Session establishment, maintenance, and termination by end device based on SMS messaging

Also Published As

Publication number Publication date
JPWO2018012615A1 (ja) 2019-04-11
US20230269279A1 (en) 2023-08-24
JP6636157B2 (ja) 2020-01-29
JP6880421B2 (ja) 2021-06-02
JP2020025347A (ja) 2020-02-13
WO2018012615A1 (ja) 2018-01-18
US20230269280A1 (en) 2023-08-24
US20230319117A1 (en) 2023-10-05
US20190166165A1 (en) 2019-05-30
US11012478B2 (en) 2021-05-18
US20200344276A1 (en) 2020-10-29
JP2020025346A (ja) 2020-02-13

Similar Documents

Publication Publication Date Title
US9100407B2 (en) Method and system to enhance performance of a session initiation protocol network and its elements
US20230269280A1 (en) Communication method, communication apparatus, and communication system
KR101705440B1 (ko) 미디어 통신용 하이브리드 클라우드 미디어 아키텍쳐
JP2007318343A (ja) ゲートウェイ装置及び再ネゴシエーション方法
JP2007201900A (ja) セッション制御方法、通信システム、通信制御装置、及び、接続指示装置
GB2562541A (en) A signalling protocol routing system
KR102556286B1 (ko) 인터넷 환경에서의 WebRTC 기반 통화 연결 방법 및 그 장치
JP2013510477A (ja) メディアセッションのネゴシエーションのための方法、機器およびシステム
JP2011166453A (ja) SIP(SessionInitiationProtocol)中継装置、パケット変換装置、ネットワークシステム、制御方法及び制御プログラム
JP2007251612A (ja) Ip電話交換機およびip電話交換機間ローミング方法
JP5634340B2 (ja) 中継システム及び中継網のコーディック選択方法
Shanmugalingam et al. User mobility in a Web-based communication system
JP5601421B2 (ja) サーバ装置、通信制御プログラム、及び通信制御方法
JP6348875B2 (ja) 中継装置、呼制御システム、呼制御方法、および、呼制御プログラム
JP2005198181A (ja) Sip通信制御装置
US20140269599A1 (en) Routing system for transferring data packets of a call
JP6183881B2 (ja) コーデック変換ゲートウェイ、コーデック変換方法、及び、コーデック変換プログラム
WO2013120387A1 (zh) 不同网络之间进行互通信的方法、系统和域名系统服务器
EP2059001B1 (en) Multitype SIP processing element
JP4070655B2 (ja) メディア通信方法及びメディア通信システム
Kuwadekar et al. Real time video adaptation in next generation networks
JP2014192624A (ja) Sipサーバのセッションを優先度に応じて移行させる移行制御方法及びシステム
KR100947085B1 (ko) 호 설정 프로토콜 기반의 음성패킷망 연동 서버를 포함하는 연동망 및 연동 방법
KR100998751B1 (ko) Ims망에서의 영상 링백톤 제공 장치 및 그 방법
JP2010239292A (ja) ネットワーク制御装置、BacktoBackUserAgent、呼制御装置およびネットワーク制御方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20191118

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20200817

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20200825

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20200901

R150 Certificate of patent or registration of utility model

Ref document number: 6758472

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150