[要約] RFC 4123は、SIPとH.323の間での相互運用性の要件を定義しています。このRFCの目的は、SIPとH.323のプロトコル間の相互運用性を確保し、異なるネットワーク環境での通信を可能にすることです。
Network Working Group H. Schulzrinne
Request for Comments: 4123 Columbia University
Category: Informational C. Agboh
July 2005
Session Initiation Protocol (SIP)-H.323 Interworking Requirements
セッション開始プロトコル（SIP）-H.323インターワーキング要件
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
IESG Note
IESGノート
This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose, and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment. See [RFC3932] for more information.
このRFCは、インターネット標準のレベルの候補者ではありません。IETFは、あらゆる目的のためにこのRFCのフィットネスに関する知識を放棄します。特に、公開する決定は、セキュリティ、混雑制御、または展開されたプロトコルとの不適切な相互作用のIETFレビューに基づいていないことに注意してください。RFCエディターは、その裁量でこのドキュメントを公開することを選択しました。このドキュメントの読者は、実装と展開の価値を評価する際に注意する必要があります。詳細については、[RFC3932]を参照してください。
Abstract
概要
This document describes the requirements for the logical entity known as the Session Initiation Protocol (SIP)-H.323 Interworking Function (SIP-H.323 IWF) that will allow the interworking between SIP and H.323.
このドキュメントでは、SIPとH.323の間のインターワーキングを可能にするセッション開始プロトコル（SIP）-H.323インターワーキング関数（SIP-H.323 IWF）として知られる論理エンティティの要件について説明します。
Table of Contents
目次
1. Introduction ....................................................3
2. Definitions .....................................................3
3. Functionality within the SIP-H.323 IWF ..........................4
4. Pre-Call Requirements ...........................................4
4.1. Registration with H.323 Gatekeeper .........................5
4.2. Registration with SIP Server ...............................5
5. General Interworking Requirements ...............................5
5.1. Basic Call Requirements ....................................5
5.1.1. General Requirements ................................5
5.1.2. Address Resolution ..................................6
5.1.3. Call with H.323 Gatekeeper ..........................6
5.1.4. Call with SIP Registrar .............................6
5.1.5. Capability Negotiation ..............................6
5.1.6. Opening of Logical Channels .........................7
5.2. IWF H.323 Features .........................................7
5.3. Overlapped Sending .........................................7
5.3.1. DTMF Support ........................................7
6. Transport .......................................................8
7. Mapping between SIP and H.323 ...................................8
7.1. General Requirements .......................................8
7.2. H.225.0 and SIP Call Signaling .............................8
7.3. Call Sequence ..............................................9
7.4. State Machine Requirements .................................9
8. Security Considerations ........................................10
9. Examples and Scenarios .........................................10
9.1. Introduction ..............................................10
9.2. IWF Configurations ........................................11
9.3. Call Flows ................................................11
9.3.1. Call from H.323 Terminal to SIP UA .................11
9.3.2. Call from SIP UA to H.323 Terminal .................12
10. Acknowledgments ...............................................12
11. Contributors ..................................................13
12. References ....................................................14
12.1. Normative References ....................................14
12.2. Informative References ..................................15
The SIP-H.323 Interworking function (IWF) converts between SIP (Session Initiation Protocol) [RFC3261] and the ITU Recommendation H.323 protocol [H.323]. This document describes requirements for this protocol conversion.
SIP-H.323インターワーキング関数（IWF）は、SIP（セッション開始プロトコル）[RFC3261]とITU推奨H.323プロトコル[H.323]との間を変換します。このドキュメントでは、このプロトコル変換の要件について説明します。
H.323 gatekeeper (GK): An H.323 gatekeeper is an optional component in an H.323 network. If it is present, it performs address translation, bandwidth control, admission control, and zone management.
H.323 GateKeeper（GK）：H.323 GateKeeperは、H.323ネットワークのオプションのコンポーネントです。存在する場合、アドレス翻訳、帯域幅制御、入場制御、ゾーン管理を実行します。
H.323 network: In this document, we refer to the collection of all H.323-speaking components as the H.323 network.
H.323ネットワーク：このドキュメントでは、すべてのH.323語を話すコンポーネントのコレクションをH.323ネットワークと呼びます。
SIP network: In this document, we refer to the collection of all SIP servers and user agents as the SIP network.
SIPネットワーク：このドキュメントでは、すべてのSIPサーバーとユーザーエージェントのコレクションをSIPネットワークと呼びます。
Interworking Function (IWF): This function performs interworking between H.323 and SIP. It belongs to both the H.323 and SIP networks.
インターワーキング関数（IWF）：この関数は、H.323とSIPの間でインターワーキングを実行します。H.323とSIPネットワークの両方に属します。
SIP server: A SIP server can be a SIP proxy, redirect server, or registrar server.
SIPサーバー：SIPサーバーは、SIPプロキシ、リダイレクトサーバー、またはレジストラサーバーにすることができます。
Endpoint: An endpoint can call and be called. An endpoint is an entity from which the media such as voice, video, or fax originates or terminates. An endpoint can be H.323 terminal, H.323 Gateway, H.323 MCU [H.323], or SIP user agent (UA) [RFC3261].
エンドポイント：エンドポイントは呼び出して呼ばれます。エンドポイントは、音声、ビデオ、ファックスなどのメディアが発生または終了するエンティティです。エンドポイントは、H.323ターミナル、H.323ゲートウェイ、H.323 MCU [H.323]、またはSIPユーザーエージェント（UA）[RFC3261]です。
Media-Switching Fabric (MSF): This is an optional logical entity within the IWF. The MSF switches media such as voice, video, or fax from one network association to another.
メディアスイッチングファブリック（MSF）：これは、IWF内のオプションの論理エンティティです。MSFは、音声、ビデオ、ファックスなどのメディアを、あるネットワークアソシエーションから別のネットワークアソシエーションに切り替えます。
This section summarizes the functional requirements of the SIP-H.323 interworking function (IWF).
このセクションでは、SIP-H.323インターワーキング関数（IWF）の機能要件を要約します。
A SIP-H.323 IWF may be integrated into an H.323 gatekeeper or SIP server. Interworking should not require any optional components in either the SIP or H.323 network, such as H.323 gatekeepers. IWF redundancy in the network is beyond the scope of this document.
SIP-H.323 IWFは、H.323ゲートキーパーまたはSIPサーバーに統合できます。インターワーキングは、H.323ゲートキーパーなどのSIPまたはH.323ネットワークのいずれにもオプションのコンポーネントを必要としないでください。ネットワーク内のIWF冗長性は、このドキュメントの範囲を超えています。
An IWF contains functions from the following list, inter alia:
IWFには、次のリストからの関数が含まれています。
o Mapping of the call setup and teardown sequences;
o コールのセットアップと分解シーケンスのマッピング。
o Registering H.323 and SIP endpoints with SIP registrars and H.323 gatekeepers;
o H.323およびSIPエンドポイントをSIPレジストラとH.323ゲートキーパーで登録します。
o Resolving H.323 and SIP addresses;
o H.323とSIPアドレスを解決します。
o Maintaining the H.323 and SIP state machines;
o H.323およびSIPステートマシンの維持。
o Negotiating terminal capabilities;
o ターミナル機能の交渉。
o Opening and closing media channels;
o メディアチャネルの開閉。
o Mapping media-coding algorithms for H.323 and SIP networks;
o H.323およびSIPネットワークのメディアコーディングアルゴリズムのマッピング。
o Reserving and releasing call-related resources;
o コール関連のリソースの予約とリリース。
o Processing of mid-call signaling messages;
o ミッドコールシグナリングメッセージの処理。
o Handling of services and features.
o サービスと機能の処理。
The IWF should not process media. We assume that the same media transport protocols, such as RTP, are used in both the SIP and H.323 networks. Thus, media packets are exchanged directly between the endpoints. If a particular service requires the IWF to handle media, we assume that the IWF simply forwards media packets without modification from one network to the other, using a media-switching fabric (MSF). The conversion of media from one encoding or format to another is out of scope for SIP-H.323 protocol translation.
IWFはメディアを処理すべきではありません。RTPなどの同じメディアトランスポートプロトコルが、SIPとH.323ネットワークの両方で使用されていると想定しています。したがって、メディアパケットはエンドポイント間で直接交換されます。特定のサービスがIWFにメディアを処理する必要がある場合、IWFは、メディアスイッチングファブリック（MSF）を使用して、1つのネットワークから別のネットワークに変更せずにメディアパケットを単純に転送するだけであると仮定します。あるエンコードまたはフォーマットから別の形式へのメディアの変換は、SIP-H.323プロトコル翻訳の範囲外です。
The IWF function may use a translation table to resolve the H.323 and SIP addresses to IP addresses. This translation table can be updated by using an H.323 gatekeeper, a SIP proxy server, or a locally-maintained database.
IWF関数は、翻訳テーブルを使用して、H.323とSIPアドレスをIPアドレスに解決できます。この翻訳テーブルは、H.323 GateKeeper、SIPプロキシサーバー、またはローカルにメンテナンスされたデータベースを使用して更新できます。
An IWF may provide and update the H.323 gatekeeper with the addresses of SIP UAs. A SIP user agent can make itself known to the H.323 network by registering with an IWF serving as a registrar. The IWF creates an H.323 alias address and registers this alias, together with its own network address, with the appropriate GK.
IWFは、H.323ゲートキーパーにSIP UASのアドレスを提供し、更新する場合があります。SIPユーザーエージェントは、レジストラとして機能するIWFに登録することにより、H.323ネットワークに自分自身を知らせることができます。IWFは、H.323エイリアスアドレスを作成し、このエイリアスを適切なGKとともに独自のネットワークアドレスとともに登録します。
The gatekeeper can then use this information to route calls to SIP UAs via the IWF, without being aware that the endpoint is not a "native" H.323 endpoint.
ゲートキーパーは、この情報を使用して、エンドポイントが「ネイティブ」H.323エンドポイントではないことを認識することなく、IWFを介してSIPに呼び出しをルーティングできます。
The IWF can register SIP UAs with one or more H.323 gatekeepers.
IWFは、SIP UASを1つ以上のH.323ゲートキーパーに登録できます。
The IWF can provide information about H.323 endpoints to a SIP registrar. This allows the SIP proxy using this SIP registrar to direct calls to the H.323 endpoints via the IWF.
IWFは、H.323エンドポイントに関する情報をSIPレジストラに提供できます。これにより、このSIPレジストラを使用してSIPプロキシを使用して、IWFを介してH.323エンドポイントに電話をかけることができます。
The IWF can easily obtain information about H.323 endpoints if it also serves as a gatekeeper. Other architectures require further study.
IWFは、ゲートキーパーとしても機能する場合、H.323エンドポイントに関する情報を簡単に取得できます。その他のアーキテクチャには、さらなる研究が必要です。
If the H.323 endpoints are known through E.164 (telephone number) addresses, the IWF can use IGREP [TGREP] or SLP [GWLOC] to inform the SIP proxy server of these endpoints.
H.323エンドポイントがE.164（電話番号）アドレスを介して既知である場合、IWFはIGREP [TGREP]またはSLP [GWLOC]を使用して、これらのエンドポイントのSIPプロキシサーバーに通知できます。
The IWF only needs to register with multiple SIP registrars if the H.323 terminal is to appear under multiple, different addresses-of-record.
IWFは、H.323端子が複数の異なる録音アドレスの下に表示される場合にのみ、複数のSIPレジストラに登録する必要があります。
The IWF should use H.323 Version 2 or later and SIP according to RFC 3261 [RFC3261]. The protocol translation function must not require modifications or additions to either H.323 or SIP. However, it may not be possible to support certain features of each protocol across the IWF.
IWFは、h.323バージョン2以降を使用し、RFC 3261 [RFC3261]に従ってSIPを使用する必要があります。プロトコル変換関数は、H.323またはSIPの修正または追加を必要としないはずです。ただし、IWF全体で各プロトコルの特定の機能をサポートすることはできない場合があります。
The IWF should provide default settings for translation parameters. The IWF specification must identify these defaults.
IWFは、変換パラメーターのデフォルト設定を提供する必要があります。IWF仕様は、これらのデフォルトを特定する必要があります。
The IWF must release any call-related resource at the end of a call. SIP session timers [RFC4028] may be used on the SIP side.
IWFは、呼び出しの終了時にコール関連のリソースをリリースする必要があります。SIPセッションタイマー[RFC4028]は、SIP側で使用できます。
The IWF should support all the addressing schemes in H.323, including the H.323 URI [RFC3508], and the "sip", "sips", and "tel" URI schemes in SIP. It should support the DNS-based SIP server location mechanisms described in [RFC3263] and H.323 Annex O, which details how H.323 uses DNS and, in particular, DNS SRV records.
IWFは、H.323 URI [RFC3508]、SIPの「SIP」、「SIP」、および「Tel」URIスキームを含む、H.323のすべてのアドレス指定スキームをサポートする必要があります。[RFC3263]およびH.323 Annex Oで説明されているDNSベースのSIPサーバーの位置メカニズムをサポートする必要があります。これは、H.323がDNS、特にDNS SRVレコードを使用する方法を詳述しています。
The IWF should register with the H.323 Gatekeeper and the SIP registrar when available.
IWFは、利用可能な場合はH.323ゲートキーパーとSIPレジストラに登録する必要があります。
The IWF may use any means to translate between SIP and H.323 addresses. Examples include translation tables populated by the gatekeeper, SIP registrar or other database, LDAP, DNS or TRIP.
IWFは、任意の手段を使用して、SIPとH.323のアドレスを翻訳することができます。例には、ゲートキーパー、SIPレジストラまたはその他のデータベース、LDAP、DNSまたは旅行が入力した翻訳テーブルが含まれます。
When an H.323 GK is present in the network, the IWF should resolve addresses with the help of the GK.
ネットワークにH.323 GKが存在する場合、IWFはGKの助けを借りてアドレスを解決する必要があります。
The IWF applies normal SIP call routing and does not need to be aware whether there is a proxy server.
IWFは通常のSIPコールルーティングを適用し、プロキシサーバーがあるかどうかを認識する必要はありません。
The IWF should not make any assumptions about the capabilities of either the SIP user agent or the H.323 terminal. However, it may indicate a guaranteed-to-be-supported list of codecs of the H.323 terminal or SIP user agent before exchanging capabilities with H.323 (using H.245) and SIP (using SDP [RFC2327]). H.323 defines mandatory capabilities, whereas SIP currently does not. For example, the G.711 audio codec is mandatory for higher bandwidth H.323 networks.
IWFは、SIPユーザーエージェントまたはH.323端子のいずれかの機能について仮定を立てるべきではありません。ただし、H.323（H.245を使用）およびSIP（SDP [RFC2327]を使用）と能力を交換する前に、H.323端子またはSIPユーザーエージェントのコーデックのサポートされている保証されたリストを示している場合があります。H.323は必須の機能を定義しますが、SIPは現在そうではありません。たとえば、G.711オーディオコーデックは、より高い帯域幅H.323ネットワークに必須です。
The IWF should attempt to map the capability descriptors of H.323 and SDP in the best possible fashion. The algorithm for finding the best mapping between H.245 capability descriptors and the corresponding SDP is left for further study.
IWFは、可能な限り最高の方法でH.323とSDPの機能記述子をマッピングしようとする必要があります。H.245機能記述子と対応するSDPの間に最適なマッピングを見つけるためのアルゴリズムは、さらなる研究のために残されています。
The IWF should be able to map the common audio, video, and application format names supported in H.323 to and from the equivalent RTP/AVP [RFC3550] names.
IWFは、H.323でサポートされている一般的なオーディオ、ビデオ、およびアプリケーション形式名を、同等のRTP/AVP [RFC3550]名との間でマッピングできるはずです。
The IWF may use the SIP OPTIONS message to derive SIP UA capabilities. It may support mid-call renegotiation of media capabilities.
IWFは、SIPオプションメッセージを使用して、SIP UA機能を導き出すことができます。メディア機能の中間再交渉をサポートする場合があります。
The IWF should support the seamless exchange of messages for opening, reopening, changing, and closing of media channels during a call. The procedures for opening, reopening, closing, and changing the existing media sessions during a call are for further study.
IWFは、通話中にメディアチャネルを開設、再開、変更、閉鎖するためのメッセージのシームレスな交換をサポートする必要があります。通話中の既存のメディアセッションを開設、再開、閉鎖、および変更する手順は、さらなる調査のためのものです。
The IWF should open media channels between the endpoints whenever possible. If this is not possible, then the channel can be opened at the MSF of the IWF.
IWFは、可能な限りエンドポイント間のメディアチャネルを開く必要があります。これが不可能な場合は、IWFのMSFでチャネルを開くことができます。
The IWF should support unidirectional, symmetric bi-directional, and asymmetric bi-directional opening of channels.
IWFは、チャネルの単方向、対称性双方向、および非対称の双方向開口部をサポートする必要があります。
The IWF may respond to the mode request and to the request for reopening and changing an existing logical channel and may support the flow control mechanism in H.323.
IWFは、モード要求と既存の論理チャネルの再開および変更の要求に応答し、H.323のフロー制御メカニズムをサポートする場合があります。
The IWF should support Fast Connect; i.e., H.245 tunneling in H.323 Setup messages. If IWF and GK are the same device, pre-granted ARQ should be supported. If pre-granted ARQ is supported, the IWF may perform the address resolution from H.323 GK using the LRQ/LCF exchange.
IWFは高速接続をサポートする必要があります。つまり、H.323セットアップメッセージのH.245トンネル。IWFとGKが同じデバイスである場合、事前に授与されたARQをサポートする必要があります。事前に授与されたARQがサポートされている場合、IWFはLRQ/LCF Exchangeを使用してH.323 GKのアドレス解像度を実行できます。
An IWF should follow the recommendations outlined in [RFC3578] when receiving overlapped digits from the H.323 side. If the IWF receives overlapped dialed digits from the SIP network, it may use the Q.931 Setup, Setup Ack, and Information Message in H.323.
IWFは、H.323側から重複した数字を受信するときに[RFC3578]で概説されている推奨事項に従う必要があります。IWFがSIPネットワークからオーバーラップされたダイヤル桁を受信した場合、Q.931セットアップ、セットアップACK、および情報メッセージをH.323で使用できます。
The IWF may support the transfer of digits during a call by using the appropriate SIP mechanism and UserInputIndication in H.245 (H.323).
IWFは、H.245（H.323）の適切なSIPメカニズムとUserinputindicationを使用して、呼び出し中の数字の転送をサポートする場合があります。
An IWF should support the mapping between DTMF and possibly other telephony tones carried in signaling messages.
IWFは、DTMFと、信号メッセージで運ばれる他のテレフォニートーンとの間のマッピングをサポートする必要があります。
The H.323 and SIP systems do not have to be in close proximity. The IP networks hosting the H.323 and SIP systems do not need to assure quality of service (QoS). In particular, the IWF should not assume that signaling messages have priority over packets from other applications. H.323 signaling over UDP (H.323 Annex E) is optional.
H.323およびSIPシステムは、近接している必要はありません。H.323およびSIPシステムをホストするIPネットワークは、サービス品質（QoS）を保証する必要はありません。特に、IWFは、シグナリングメッセージが他のアプリケーションからのパケットよりも優先されると想定すべきではありません。H.323 UDP（H.323 Annex E）を介したシグナリングはオプションです。
o The call message sequence of both protocols must be maintained.
o 両方のプロトコルのコールメッセージシーケンスを維持する必要があります。
o The IWF must not set up or tear down calls on its own.
o IWFは、独自に電話を設定または解体してはなりません。
o Signaling messages that do not have a match for the destination protocol should be terminated on the IWF, with the IWF taking the appropriate action for them. For example, SIP allows a SIP UA to discard an ACK request silently for a non-existent call leg.
o 宛先プロトコルに一致しないシグナリングメッセージは、IWFで終了する必要があり、IWFは適切なアクションを実行します。たとえば、SIPを使用すると、SIP UAが存在しないコールレッグのACKリクエストを静かに破棄できます。
o If the IWF is required to generate a message on its own, IWF should use pre-configured default values for the message parameters.
o IWFがそれ自体でメッセージを生成する必要がある場合、IWFはメッセージパラメーターに事前に構成されたデフォルト値を使用する必要があります。
o The information elements and header fields of the respective messages are to be converted as follows:
o それぞれのメッセージの情報要素とヘッダーフィールドは、次のように変換されます。
* The contents of connection-specific information elements, such as Call Reference Value for H.323, are converted to similar information required by SIP or SDP, such as the SDP session ID and the SIP 'Call-ID'.
* H.323の呼び出し参照値などの接続固有の情報要素の内容は、SIPまたはSDPが必要とする同様の情報に変換されます。
* The IWF generates protocol elements that are not available from the other side.
* IWFは、反対側から使用できないプロトコル要素を生成します。
o The IWF must conform to the call signaling procedures recommended for the SIP side regardless of the behavior of the H.323 elements.
o IWFは、H.323要素の動作に関係なく、SIP側に推奨されるコールシグナル手順に準拠する必要があります。
o The IWF must conform to the call signaling procedures recommended for the H.323 side regardless of the behavior of the SIP elements.
o IWFは、SIP要素の動作に関係なく、H.323側に推奨されるコールシグナル手順に準拠する必要があります。
o The IWF serves as the endpoint for the Q.931 Call Signaling Channel to either an H.323 endpoint or H.323 Gatekeeper (in case of GK routed signaling). The IWF also acts as a SIP user agent client and server.
o IWFは、Q.931コールシグナリングチャネルのエンドポイントとして、H.323エンドポイントまたはH.323ゲートキーパー（GKルーティングシグナリングの場合）のいずれかです。IWFは、SIPユーザーエージェントクライアントおよびサーバーとしても機能します。
o The IWF also establishes a Registration, Admission, Status (RAS) Channel to the H.323 GK, if available.
o IWFは、登録、入場、ステータス（RAS）チャネルをH.323 GKに確立します。
o The IWF should process messages for H.323 supplementary services (FACILITY, NOTIFY, and the INFORMATION messages) only if the service itself is supported.
o IWFは、サービス自体がサポートされている場合にのみ、H.323補足サービス（施設、通知、および情報メッセージ）のメッセージを処理する必要があります。
The call sequence on both sides should be maintained in such a way that neither the H.323 terminal nor the SIP UA is aware of presence of the IWF.
両側のコールシーケンスは、H.323端子もSIP UAもIWFの存在を認識していないように維持する必要があります。
The state machine for IWF will follow the following general guidelines:
IWFの州のマシンは、次の一般的なガイドラインに従います。
o Unexpected messages in a particular state shall be treated as "error" messages.
o 特定の状態の予期しないメッセージは、「エラー」メッセージとして扱われます。
o All messages that do not change the state shall be treated as "non-triggering" or informational messages.
o 状態を変更しないすべてのメッセージは、「非トリガー」または情報メッセージとして扱われるものとします。
o All messages that expect a change in state shall be treated as "triggering" messages.
o 州の変更を期待するすべてのメッセージは、「トリガー」メッセージとして扱われるものとします。
For each state, an IWF specification must classify all possible protocol messages into the above three categories. It must specify the actions taken on the content of the message and the resulting state. Below is an example of such a table:
各状態について、IWF仕様は、可能なすべてのプロトコルメッセージを上記の3つのカテゴリに分類する必要があります。メッセージの内容と結果の状態に対して取られたアクションを指定する必要があります。以下はそのようなテーブルの例です。
State: Idle
状態：アイドル
Possible Messages Message Category Action Next state
-------------------------------------------------------------------
All RAS msg. Triggering Add Reg.Info. WaitForSetup
All H.245 msg. Error Send 4xx Idle
SIP OPTIONS Non Triggering Return cap. Idle
SIP INVITE Triggering Send SETUP WaitForConnect
Because the IWF whose requirements have been described in this document combines both SIP and H.323 functionality, security considerations for both of these protocols apply.
このドキュメントで要件が説明されているIWFは、SIPとH.323の両方の機能を組み合わせているため、これらのプロトコルの両方のセキュリティに関する考慮事項が適用されます。
The eventual security solution for interworking must rely on the standard mechanisms in RFC3261 [RFC3261] and H.323, without extending them for the interworking function. Signaling security for H.323 is described in H.235 [H.235].
インターワーキングのための最終的なセキュリティソリューションは、インターワーキング関数に拡張せずに、RFC3261 [RFC3261]およびH.323の標準メカニズムに依存する必要があります。H.323のシグナリングセキュリティは、H.235 [H.235]に記載されています。
Because all data elements in SIP or H.323 have to terminate at the IWF, the resulting security cannot be expected to be end-to-end. Thus, the IWF terminates not only the signalling protocols but also the security in each domain. Therefore, users at the SIP or H.323 endpoint have to trust the IWF, like they would any other gateway, to authenticate the other side correctly. Similarly, they have to trust the gateway to respect the integrity of data elements and to apply appropriate security mechanisms on the other side of the IWF.
SIPまたはH.323のすべてのデータ要素はIWFで終了する必要があるため、結果として生じるセキュリティはエンドツーエンドであるとは期待できません。したがって、IWFは、シグナル伝達プロトコルだけでなく、各ドメインのセキュリティも終了します。したがって、SIPまたはH.323エンドポイントのユーザーは、他のゲートウェイと同様にIWFを信頼して、反対側を正しく認証する必要があります。同様に、データ要素の完全性を尊重し、IWFの反対側に適切なセキュリティメカニズムを適用するために、ゲートウェイを信頼しなければなりません。
The IWF must not indicate the identity of a user on one side without first performing authentication. For example, if the SIP user was not authenticated, it would be inappropriate to use mechanisms on the H.323 side, such as H.323 Annex D, to indicate that the user identity had been authenticated.
IWFは、最初に認証を実行せずに片側にユーザーの身元を示してはなりません。たとえば、SIPユーザーが認証されていない場合、H.323付録DなどのH.323側でメカニズムを使用して、ユーザーIDが認証されていることを示すことは不適切です。
An IWF must not accept 'sips' requests unless it can guarantee that the H.323 side uses equivalent H.235 [H.235] security mechanisms. Similarly, the IWF must not accept H.235 sessions unless it succeeds in using SIP-over-TLS (sips) on the SIP side of the IWF.
IWFは、H.323側が同等のH.235 [H.235]セキュリティメカニズムを使用していることを保証できない限り、「SIPS」リクエストを受け入れてはなりません。同様に、IWFは、IWFのSIP側でSIP-Over-TLS（SIP）を使用することに成功しない限り、H.235セッションを受け入れてはなりません。
We present some examples of call scenarios that will show the signaling messages received and transmitted. The following situations can occur:
受信および送信された信号メッセージを表示するコールシナリオの例をいくつか提示します。次の状況が発生する可能性があります。
o Some signaling messages can be translated one-to-one.
o 一部の信号メッセージは1対1で翻訳できます。
o In some cases, parameters on one side do not match those on the other side.
o 場合によっては、片側のパラメーターは反対側のパラメーターと一致しません。
o Some signaling messages do not have an equivalent message on the other side. In some cases, the IWF can gather further information and the signal on the other side. In some cases, only an error indication can be provided.
o 一部の信号メッセージには、反対側に同等のメッセージがありません。場合によっては、IWFはさらに情報と反対側の信号を収集できます。場合によっては、エラー表示のみを提供できます。
Below are some common architectures involving an IWF:
以下は、IWFを含むいくつかの一般的なアーキテクチャです。
Basic Configuration: H.323 EP -- IWF -- SIP UA
Calls using H.323 GK: H.323 EP -- H.323 GK -- IWF -- SIP UA
Calls using SIP proxies: H.323 EP -- IWF -- SIP proxies -- SIP UA
Calls using both H.323 GK and SIP proxy: H.323 EP -- H.323 GK -- IWF
-- SIP proxies -- SIP UA
SIP trunking between H.323 networks: H.323 EP -- IWF -- SIP network
-- IWF -- H.323 EP
H.323 trunking between SIP networks: SIP EP -- IWF -- H.323 network
-- IWF -- SIP UA
Some call flow examples for two different configurations and call scenarios are given below.
2つの異なる構成と呼び出しシナリオのコールフローの例を以下に示します。
H.323 SIP
EP Setup IWF UA
|------------>| INVITE |
| |------------>|
| | 180 RINGING |
| Alerting |<------------|
|<------------| 200 OK |
| Connect |<------------|
|<------------| |
| H.245 | |
|<----------->| ACK |
| |------------>|
| RTP |
|<.........................>|
SIP H.323
UA IWF EP
| | |
| INVITE | |
|------------>| Setup |
| |------------>|
| | Alerting |
| 180 RINGING |<------------|
|<------------| Connect |
| |<------------|
| | H.245 |
| 200 OK |<----------->|
|<------------| |
| ACK | |
|------------>| |
| RTP |
|<.........................>|
The authors would like to acknowledge the many contributors who discussed the SIP-H.323 interworking architecture and requirements on the IETF, SIP, and SG16 mailing lists. In particular, we would like to thank Joon Maeng, Dave Walker, and Jean-Francois Mule. Contributions to this document have also been made by members of the H.323, aHIT!, TIPHON, and SG16 forums.
著者は、IETF、SIP、およびSG16のメーリングリストに関するSIP-H.323インターワーキングアーキテクチャと要件について議論した多くの貢献者を認めたいと考えています。特に、Joon Maeng、Dave Walker、Jean-Francois Muleに感謝したいと思います。この文書への貢献は、H.323、Ahit！、Tiphon、およびSG16フォーラムのメンバーによっても行われています。
In addition to the editors, the following people provided substantial technical and written contributions to this document. They are listed alphabetically.
編集者に加えて、次の人々はこの文書に実質的な技術的および書面による貢献を提供しました。それらはアルファベット順にリストされています。
Hemant Agrawal Telverse Communications 1010 Stewart Drive Sunnyale, CA 94085 USA
Hemant Agrawal Telverse Communications 1010 Stewart Drive Sunnyale、CA 94085 USA
EMail: hagrawal@telverse.com
Alan Johnston MCI WorldCom 100 South Fourth Street St. Louis, MO 63102 USA
アランジョンストンマクイワールドコム100サウスフォースストリートセントルイス、ミズーリ州63102 USA
EMail: alan.johnston@wcom.com
Vipin Palawat Cisco Systems Inc. 900 Chelmsford Street Lowell, MA 01851 USA
Vipin Palawat Cisco Systems Inc. 900 Chelmsford Street Lowell、MA 01851 USA
EMail: vpalawat@cisco.com
Radhika R. Roy AT&T Room C1-2B03 200 Laurel Avenue S. Middletown, NJ 07748 USA
RADHIKA R. ROY AT＆TルームC1-2B03 200ローレルアベニューS.ミドルタウン、ニュージャージー07748 USA
EMail: rrroy@att.com
Kundan Singh
Dept. of Computer Science
Columbia University
1214 Amsterdam Avenue, MC 0401
New York, NY 10027
USA
EMail: kns10@cs.columbia.edu
David Wang Nuera Communications Inc. 10445 Pacific Center Court San Diego, CA 92121 USA
David Wang Nuera Communications Inc. 10445 Pacific Center Court San Diego、CA 92121 USA
EMail: dwang@nuera.com
[H.235] International Telecommunication Union, "Security and encryption for H-Series (H.323 and other H.245-based) multimedia terminals", Recommendation H.235, February 1998.
[H.235]国際電気通信ユニオン、「Hシリーズのセキュリティと暗号化（H.323およびその他のH.245ベース）マルチメディアターミナル」、推奨H.235、1998年2月。
[H.323] International Telecommunication Union, "Packet based multimedia communication systems", Recommendation H.323, July 2003.
[H.323] International Telecommunication Union、「パケットベースのマルチメディア通信システム」、推奨H.323、2003年7月。
[RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[RFC2327] Handley、M。and V. Jacobson、「SDP：セッション説明プロトコル」、RFC 2327、1998年4月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION Intioniation Protocol」、RFC 3261、2002年6月。
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[RFC3263] Rosenberg、J。およびH. Schulzrinne、「セッション開始プロトコル（SIP）：SIPサーバーの位置」、RFC 3263、2002年6月。
[RFC3508] Levin, O., "H.323 Uniform Resource Locator (URL) Scheme Registration", RFC 3508, April 2003.
[RFC3508] Levin、O。、「H.323ユニフォームリソースロケーター（URL）スキーム登録」、RFC 3508、2003年4月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、STD 64、RFC 3550、2003年7月。
[GWLOC] Zhao, W. and H. Schulzrinne, "Locating IP-to-Public Switched Telephone Network (PSTN) Telephony Gateways via SLP", work in progress, February 2004.
[GWLOC] Zhao、W。およびH. Schulzrinne、「SLP経由でIPからパブリックの切り替え電話ネットワーク（PSTN）テレフォニーゲートウェイの位置」、2004年2月、Work in Progress。
[RFC3578] Camarillo, G., Roach, A., Peterson, J., and L. Ong, "Mapping of Integrated Services Digital Network (ISDN) User Part (ISUP) Overlap Signalling to the Session Initiation Protocol (SIP)", RFC 3578, August 2003.
[RFC3578] Camarillo、G.、Roach、A.、Peterson、J。、およびL. Ong、「統合サービスデジタルネットワーク（ISDN）ユーザーパーツのマッピング（ISUP）セッション開始プロトコル（SIP）にシグナルをオーバーラップする」、RFC 3578、2003年8月。
[RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents: Procedures", BCP 92, RFC 3932, October 2004.
[RFC3932] Alvestrand、H。、「IESGおよびRFCエディタードキュメント：手順」、BCP 92、RFC 3932、2004年10月。
[RFC4028] Donovan, S. and J. Rosenberg, "Session Timers in the Session Initiation Protocol (SIP)", RFC 4028, April 2005.
[RFC4028] Donovan、S。およびJ. Rosenberg、「セッション開始プロトコル（SIP）のセッションタイマー」、RFC 4028、2005年4月。
[TGREP] Bangalore, M., "A Telephony Gateway REgistration Protocol (TGREP)", work in progress, March 2004.
[TGREP] Bangalore、M。、「テレフォニーゲートウェイ登録プロトコル（TGREP）」、2004年3月の作業。
Authors' Addresses
著者のアドレス
Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US
ヘニングシュルツリンコロンビア大学コンピュータサイエンス学科450コンピューターサイエンスビル、ニューヨーク、ニューヨーク10027米国
Phone: +1 212 939 7042
EMail: hgs@cs.columbia.edu
URI: http://www.cs.columbia.edu
Charles Agboh 61 Bos Straat 3540 Herk-de-Stad Belgium
チャールズ・アグボ61 BOS STRAAT 3540 HERK-DE-STADベルギー
Phone: +32479736250
EMail: charles.agboh@packetizer.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78およびwww.rfc-editor.org/copyright.htmlに含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。