[要約] 要約：RFC 3578は、ISDNユーザーパート（ISUP）のオーバーラップシグナリングをセッションイニシエーションプロトコル（SIP）にマッピングするためのガイドラインです。 目的：このRFCの目的は、ISUPとSIPの間でオーバーラップシグナリングを実現するための標準化と相互運用性を提供することです。
Network Working Group G. Camarillo
Request for Comments: 3578 Ericsson
Category: Standards Track A. B. Roach
dynamicsoft
J. Peterson
NeuStar
L. Ong
Ciena
August 2003
Mapping of Integrated Services Digital Network (ISDN) User Part (ISUP) Overlap Signalling to the Session Initiation Protocol (SIP)
統合サービスのマッピングデジタルネットワーク（ISDN）ユーザーパーツ（ISUP）セッション開始プロトコル（SIP）へのシグナリングのオーバーラップ
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
Abstract
概要
This document describes a way to map Integrated Services Digital Network User Part (ISUP) overlap signalling to Session Initiation Protocol (SIP). This mechanism might be implemented when using SIP in an environment where part of the call involves interworking with the Public Switched Telephone Network (PSTN).
このドキュメントでは、統合サービスデジタルネットワークユーザーパーツ（ISUP）オーバーラップシグナル伝達をセッション開始プロトコル（SIP）にマッピングする方法について説明します。このメカニズムは、通話の一部が公開された電話ネットワーク（PSTN）との相互作用を伴う環境でSIPを使用する場合に実装される場合があります。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conversion of ISUP Overlap Signalling into SIP en-bloc
Signalling . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Waiting for the Minimum Amount of Digits . . . . . . . . 4
2.2. The Minimum Amount of Digits has been Received . . . . . 4
3. Sending Overlap Signalling to a SIP Network. . . . . . . . . . 5
3.1. One vs. Several Transactions . . . . . . . . . . . . . . 5
3.2. Generating Multiple INVITEs. . . . . . . . . . . . . . . 6
3.3. Receiving Multiple Responses . . . . . . . . . . . . . . 8
3.4. Canceling Pending INVITE Transactions. . . . . . . . . . 9
3.5. SIP to ISUP. . . . . . . . . . . . . . . . . . . . . . . 9
4. Security Considerations. . . . . . . . . . . . . . . . . . . . 10
5. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 10
6. Normative References . . . . . . . . . . . . . . . . . . . . . 10
7. Intellectual Property Statement. . . . . . . . . . . . . . . . 11
8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13
A mapping between the Session Initiation Protocol (SIP) [1] and the ISDN User Part (ISUP) [2] of SS7 is described in RFC 3398 [3]. However, RFC 3398 only takes into consideration ISUP en-bloc signalling. En-bloc signalling consists of sending the complete telephone number of the callee in the first signalling message. Although modern switches always use en-bloc signalling, some parts of the PSTN still use overlap signalling.
SS7のセッション開始プロトコル（SIP）[1]とISDNユーザーパーツ（ISUP）[2]の間のマッピングは、RFC 3398 [3]で説明されています。ただし、RFC 3398は、ISUP EN-BLOCシグナル伝達のみを考慮しています。EN-BLOCシグナル伝達は、最初のシグナリングメッセージでCalleeの完全な電話番号を送信することで構成されています。最新のスイッチは常にEN-BLOCシグナル伝達を使用していますが、PSTNの一部の部分は依然としてオーバーラップシグナリングを使用しています。
Overlap signalling consists of sending only some digits of the callee's number in the first signalling message. Further digits are sent in subsequent signalling messages. Although overlap signalling in the PSTN is the source of much additional complexity, it is still in use in some countries.
オーバーラップシグナリングは、最初のシグナリングメッセージにCalleeの数の数桁のみを送信することで構成されています。後続のシグナリングメッセージでさらに数字が送信されます。PSTNでのオーバーラップシグナルは、さらに多くの複雑さの原因ですが、一部の国ではまだ使用されています。
Like modern switches, SIP uses en-bloc signalling. The Request-URI of an INVITE request always contains the whole address of the callee. Native SIP end-points never generate overlap signalling.
最新のスイッチと同様に、SIPはEN-BLOCシグナリングを使用します。招待リクエストのリクエストウリには、常にCalleeのアドレス全体が含まれています。ネイティブSIPエンドポイントは、オーバーラップシグナル伝達を生成することはありません。
Therefore, the preferred solution for a gateway handling PSTN overlap signalling and SIP is to convert the PSTN overlap signalling into SIP en-bloc signalling using number analysis and timers. The gateway waits until all the signalling messages carrying parts of the callee's number arrive, and only then, it generates a SIP INVITE request. Section 2 describes how to convert ISUP overlap signalling into en-bloc SIP this way.
したがって、PSTNのオーバーラップシグナルとSIPを取り扱うゲートウェイハンドリングの優先ソリューションは、PSTNオーバーラップシグナルを数字分析とタイマーを使用してSIP EN-BLOCシグナル伝達に変換することです。ゲートウェイは、Calleeの番号の一部を運ぶすべての信号メッセージが到着するまで待機します。その場合にのみ、SIP Inviteリクエストが生成されます。セクション2では、ISUPオーバーラップシグナルをこの方法でEN-BLOC SIPに変換する方法について説明します。
However, although it is the preferred solution, conversion of overlap to en-bloc signalling sometimes results in unacceptable (multiple second) call setup delays to human users. In these situations, some form of overlap signalling has to be used in the SIP network to minimize the call setup delay. However, introducing overlap signalling in SIP introduces complexity and brings some issues. Section 3 analyzes the issues related to the use of overlap signalling in a SIP network and describe ways to deal with them in some particular network scenarios. Section 3 also describes in which particular network scenarios those issues make the use of overlap signalling in the SIP network unacceptable.
ただし、それは好ましいソリューションですが、オーバーラップのEN-BLOCシグナル伝達の変換により、人間のユーザーに容認できない（複数の秒）コールセットアップの遅延が生じることがあります。これらの状況では、SIPネットワークで何らかの形のオーバーラップシグナル伝達を使用して、コールセットアップの遅延を最小限に抑える必要があります。ただし、SIPにオーバーラップシグナル伝達を導入すると、複雑さが導入され、いくつかの問題が発生します。セクション3では、SIPネットワークでのオーバーラップシグナル伝達の使用に関連する問題を分析し、特定のネットワークシナリオでそれらに対処する方法を説明します。セクション3では、特定のネットワークシナリオのこれらの問題が、SIPネットワークでのオーバーラップシグナル伝達を許容できないことについても説明しています。
In this scenario, the gateway receives an IAM (Initial Address Message) that contains only a portion of the called number. The rest of the digits dialed arrive later in one or more SAMs (Subsequent Address Message).
このシナリオでは、ゲートウェイには、呼び出された番号の一部のみが含まれるIAM（初期アドレスメッセージ）が受信されます。ダイヤルされた残りの数字は、後に1つ以上のSAM（後続のアドレスメッセージ）で到着します。
If the IAM contains less than the minimum amount of digits to route a call, the gateway starts T35 and waits until the minimum amount of digits that can represent a telephone number is received (or a stop digit is received). If T35 expires before the minimum amount of digits (or a stop digit) has been received, a REL with cause value 28 is sent to the ISUP side. T35 is defined in Q.764 [4] as 15-20 seconds.
IAMがコールをルーティングするために最小桁の量より少ない場合、ゲートウェイはT35を起動し、電話番号を表すことができる最小桁が受信されるまで待機します（または停止桁が受信されます）。最小桁（または停止桁）が受信される前にT35が有効になると、原因値28がISUP側に送信されます。T35は、Q.764 [4]で15〜20秒で定義されています。
If a stop digit is received, the gateway can already generate an INVITE request with the complete called number. Therefore, the call proceeds as usual.
停止桁を受信した場合、ゲートウェイは既に完全な呼び出し番号を使用して招待リクエストを生成できます。したがって、コールは通常どおりに進行します。
Once the minimum amount of digits that can represent a telephone number has been received, the gateway should use number analysis to decide if the number that has been received so far is a complete number. If it is, the gateway can generate an INVITE request with the complete called number. Therefore, the call proceeds as usual.
電話番号を表す可能性のある最小桁の量を受信したら、ゲートウェイは番号分析を使用して、これまでに受信された数が完全な番号であるかどうかを判断する必要があります。もしそうなら、ゲートウェイは完全な呼び出し番号で招待リクエストを生成できます。したがって、コールは通常どおりに進行します。
However, there are cases when the gateway cannot know whether the number received is a complete number or not. In this case, the gateway should collect digits until a timer (T10) expires or a stop digit (such as, #) is entered by the user (note that T10 is refreshed every time a new digit is received).
ただし、ゲートウェイが受信した数が完全な数であるかどうかを知ることができない場合があります。この場合、ゲートウェイはタイマー（T10）が有効になるか、停止桁（＃など）がユーザーによって入力されるまで数字を収集する必要があります（新しい数字を受信するたびにT10は更新されます）。
When T10 expires, an INVITE with the digits collected so far is sent to the SIP side. After this, any SAM received is ignored.
T10が失効すると、これまでに収集された数字を招待してSIP側に招待されます。この後、受け取ったサムは無視されます。
PSTN MGC/MG SIP
| | |
|-----------IAM----------->| Starts T10 |
| | |
|-----------SAM----------->| Starts T10 |
| | |
|-----------SAM----------->| Starts T10 |
| | |
| | |
| T10 expires |---------INVITE---------->|
| | |
Figure 1: Use of T10 to convert overlap signalling to en-bloc
図1：オーバーラップシグナル伝達をEN-BLOCに変換するためにT10を使用する
Note that T10 is defined for conversion between overlap signalling (e.g., CAS) and en-bloc ISUP. PSTN switches usually implement a locally defined value of timer T10 -- which may not be within the 4-6 second range recommended by Q.764 [4] -- to convert overlap ISUP to en-bloc ISUP. This document uses T10 and recommends the range of values defined in Q.764 [4], which seems suitable for conversion from overlap to en-bloc SIP operation. The actual choice of the timer value is a matter of local policy.
T10は、オーバーラップシグナル伝達（CASなど）とEN-BLOC ISUPの間の変換のために定義されていることに注意してください。PSTNスイッチは通常、Q.764 [4]で推奨される4〜6秒の範囲内ではないタイマーT10のローカルで定義された値を実装して、オーバーラップISUPをEN-BLOC ISUPに変換します。このドキュメントはT10を使用し、Q.764 [4]で定義された値の範囲を推奨します。タイマー値の実際の選択は、ローカルポリシーの問題です。
This section analyzes the issues related to the use of overlap signalling in a SIP network and describes a possible solution and its applicability scope. It is important to note that, if used outside its applicability scope, this solution could cause a set of problems, which are identified in this section.
このセクションでは、SIPネットワークでのオーバーラップシグナル伝達の使用に関連する問題を分析し、可能なソリューションとその適用性範囲について説明します。適用性の範囲外で使用される場合、このソリューションはこのセクションで特定されている一連の問題を引き起こす可能性があることに注意することが重要です。
An ingress gateway receiving ISUP overlap signalling (i.e., one IAM and one or more SAMs) needs to map it into SIP signalling. One possible approach would consists of sending an INVITE with the digits received in the IAM, and once an early dialog is established, sending the digits received in SAMs in a SIP request (e.g., INFO) within that early dialog.
ISUPオーバーラップシグナル伝達（つまり、1つ以上のIAMと1つ以上のSAM）を受信する侵入ゲートウェイは、それをSIPシグナリングにマッピングする必要があります。考えられるアプローチの1つは、IAMで受信した数字で招待状を送信することで構成され、初期のダイアログが確立されたら、SAMで受信した数字をSIPリクエスト（例：情報）でその初期のダイアログ内で送信します。
This approach has several problems. It requires that the remote SIP user agent (which might be a gateway) sends a non-100 provisional response as soon as it receives the initial INVITE to establish the early dialog. Current gateways, following the procedures in RFC 3398 [3], do not generate such a provisional response. Having gateways generate such a response (e.g., 183 Session Progress) would cause ingress gateways to generate early ACMs, confusing the PSTN state machine even in calls that do not use overlap signalling.
このアプローチにはいくつかの問題があります。リモートSIPユーザーエージェント（これはゲートウェイかもしれません）が、初期のダイアログを確立するために最初の招待状を受け取るとすぐに、100以外の暫定的な応答を送信する必要があります。RFC 3398 [3]の手順に従って、現在のゲートウェイは、そのような暫定的な応答を生成しません。ゲートウェイにそのような応答を生成する（たとえば、183セッションの進行）により、イングレスゲートウェイが初期のACMを生成し、オーバーラップシグナル伝達を使用しない呼び出しでもPSTN状態マシンを混同します。
In this approach, once the initial INVITE request is routed, all the subsequent requests sent within the early dialog follow the same path. That is, they cannot be re-routed to take advantage of SIP-based services. Therefore, we do not recommend using this approach.
このアプローチでは、最初の招待リクエストがルーティングされると、初期のダイアログ内で送信されたすべてのリクエストは同じパスに従います。つまり、SIPベースのサービスを利用するために再ルーティングすることはできません。したがって、このアプローチを使用することはお勧めしません。
An alternative approach consists of sending a new INVITE that contains all the digits received so far every time a new SAM is received. Since every new INVITE sent represents a new transaction, they can be routed in different ways. This way, every new INVITE can take advantage of any SIP service that the network may provide.
別のアプローチは、新しいSAMを受信するたびにこれまでに受信したすべての数字を含む新しい招待状を送信することで構成されています。送信されたすべての新しい招待状は新しいトランザクションを表しているため、さまざまな方法でルーティングできます。このようにして、すべての新しい招待状は、ネットワークが提供する可能性のあるSIPサービスを利用できます。
However, having subsequent INVITEs routed in different ways brings some problems as well. The first INVITE, for instance, might be routed to a particular gateway, and a subsequent INVITE, to another. The result is that both gateways generate an IAM. Since one of the IAMs (or both) has an incomplete number, it would fail, having already consumed PSTN resources. It could even happen that both IAMs contained complete, but different numbers (i.e., one number is the prefix of the other one).
ただし、その後の招待状をさまざまな方法でルーティングすると、いくつかの問題ももたらします。たとえば、最初の招待状は、特定のゲートウェイにルーティングされ、その後の招待状に別の招待状にルーティングされる可能性があります。その結果、両方のゲートウェイがIAMを生成します。IAMS（またはその両方）の1つは不完全な数字を持っているため、既にPSTNリソースを消費しているため、失敗します。両方のIAMに完全なが、異なる数字が含まれていることも起こり得ます（つまり、1つの数字は他の数字の接頭辞です）。
Routing in SIP can be controlled by the administrator of the network. Therefore, a gateway can be configured to generate SIP overlap signalling in the way described below only if the SIP routing infrastructure ensures that INVITEs will only reach one gateway. When the routing infrastructure is not under the control of the administrator of the gateway, the procedures of Section 2 have to be used instead.
SIPでのルーティングは、ネットワークの管理者によって制御できます。したがって、SIPルーティングインフラストラクチャが招待状が1つのゲートウェイにのみ到達することを保証する場合にのみ、以下で説明する方法でSIPオーバーラップシグナル伝達を生成するようにゲートウェイを構成できます。ルーティングインフラストラクチャがゲートウェイの管理者の管理下にない場合、代わりにセクション2の手順を使用する必要があります。
Within some dialing plans in the PSTN, a phone number might be a prefix of another one. This situation is not common, but it can occur. Where en-bloc signalling is used, this ambiguity is resolved before the digits are placed in the en-bloc signalling. If overlap signaling was used in this situation, a different user than the one the caller intended to call might be contacted. That is why in the parts of the PSTN where overlap is used, a prefix of a telephone number never identifies another valid number. Therefore, SIP overlap signalling should not be used when attempting to reach parts of the PSTN where it is possible for a number and some shorter prefix of the same number to both be valid addresses of different terminals.
PSTNの一部のダイヤルプラン内では、電話番号が別のもののプレフィックスになる場合があります。この状況は一般的ではありませんが、発生する可能性があります。EN-BLOCシグナル伝達が使用される場合、このあいまいさは、桁がEN-BLOCシグナリングに配置される前に解決されます。この状況でオーバーラップシグナリングが使用された場合、呼び出し元のユーザーが呼び出しを意図したユーザーとは異なるユーザーに接触する可能性があります。そのため、オーバーラップが使用されるPSTNの部分では、電話番号のプレフィックスが別の有効な番号を識別しない理由です。したがって、SIPオーバーラップシグナル伝達は、PSTNの一部に到達しようとする場合は使用しないでください。ここでは、同じ数字の数といくつかの短い接頭辞が異なる端子の有効なアドレスであることが可能です。
In this scenario, the gateway receives an IAM (Initial Address Message) and possibly one or more SAMs (Subsequent Address Message) that provide more than the minimum amount of digits that can represent a phone number.
このシナリオでは、ゲートウェイは、電話番号を表す可能性のある最小桁を超える量を提供するIAM（初期アドレスメッセージ）と、おそらく1つ以上のSAM（後続のアドレスメッセージ）を受信します。
As soon as the minimum amount of digits is received, the gateway sends an INVITE and starts T10. This INVITE is built following the procedures described in RFC 3398 [3].
最小桁を受信するとすぐに、ゲートウェイは招待状を送信し、T10を開始します。この招待状は、RFC 3398 [3]に記載されている手順に従って構築されています。
If a SAM arrives to the gateway, T10 is refreshed and a new INVITE with the new digits received is sent. The new INVITE has the same Call-ID and the same From header field including the tag as the first INVITE sent, but has an updated Request-URI. The new Request-URI contains all the digits received so far. The To header field of the new INVITE contains all the digits as well, but has no tag.
SAMがゲートウェイに到着した場合、T10が更新され、新しい数字が受信された新しい招待状が送信されます。新しい招待状には、最初の招待状が送信されたタグを含むヘッダーフィールドから同じコール-IDと同じものがありますが、更新されたリクエストURIがあります。新しいRequest-URIには、これまでに受信したすべての数字が含まれています。新しい招待のヘッダーフィールドには、すべての数字も含まれていますが、タグはありません。
Note that it is possible to receive a response to the first INVITE before having sent the second INVITE. In this case, the response received would contain a To tag and information (Record-Route and Contact) to build a Route header field. The new INVITE to be sent (containing new digits) should not use any of these headers. That is, the new INVITE does not contain neither To tag nor Route header field. This way, this new INVITE can be routed dynamically by the network providing services.
2番目の招待状を送信する前に、最初の招待への応答を受信することが可能であることに注意してください。この場合、受信した応答には、ルートヘッダーフィールドを構築するためのタグと情報（レコードルートと連絡先）へのAが含まれます。送信される新しい招待状（新しい数字を含む）は、これらのヘッダーのいずれかを使用しないでください。つまり、新しい招待には、ヘッダーフィールドにタグを付けることもルーティングも含まれていません。このようにして、この新しい招待状は、サービスを提供するネットワークによって動的にルーティングできます。
The new INVITE should, of course, contain a Cseq field. It is recommended that the Cseq of the new INVITE is higher than any of the previous Cseq that the gateway has generated for this Call-ID (no matter for which dialog the Cseq was generated).
もちろん、新しい招待状にはCSEQフィールドが含まれている必要があります。新しい招待のCSEQは、このコールIDに対してゲートウェイが生成した以前のCSEQよりも高いことをお勧めします（CSEQが生成されたダイアログに関係なく）。
When an INVITE forks, responses from different locations might arrive establishing one or more early dialogs. New requests such as, PRACK or UPDATE can be sent within every particular early dialog. This implies that the Cseq number spaces of different early dialogs are different. Sending a new INVITE with a Cseq that is still unused by any of the remote destinations avoids confusion at the destination.
招待フォークの場合、さまざまな場所からの応答が到着する可能性があります。Prack、Updateなどの新しいリクエストは、すべての特定の早期ダイアログ内で送信できます。これは、異なる初期の対話のCSEQ数スペースが異なることを意味します。遠隔地のいずれかで未使用のCSEQで新しい招待状を送信すると、目的地での混乱は避けています。
If the gateway is encapsulating ISUP messages as SIP bodies, it should place the IAM and all the SAMs received so far in this INVITE.
ゲートウェイがISUPメッセージをSIPボディとしてカプセル化している場合、この招待状でこれまでに受け取ったすべてのSAMをIAMとすべてのSAMを配置する必要があります。
PSTN MGC/MG SIP
| | |
|-----------IAM----------->| Starts T10 |
| |---------INVITE---------->|
| | |
|-----------SAM----------->| Starts T10 |
| |---------INVITE---------->|
| | |
|-----------SAM----------->| Starts T10 |
| |---------INVITE---------->|
| | |
Figure 2: Overlap signalling in SIP
図2：SIPでのオーバーラップシグナル伝達
If 4xx, 5xx or 6xx final responses arrive (e.g., 484 address incomplete) for the pending INVITE transactions before T10 has expired, the gateway should not send any REL. A REL is sent only if no more SAMs arrive, T10 expires, and all the INVITEs sent have been answered with a final response (different than 200 OK).
4xx、5xx、または6xxの最終応答が到着した場合（たとえば、484アドレス不完全）、T10が失効する前に保留中の招待トランザクションの場合、ゲートウェイはRELを送信してはなりません。RELは、これ以上SAMSが到着しない、T10が期限切れになった場合にのみ送信され、送信されたすべての招待状に最終的な応答が回答されています（200 OK以下）。
PSTN MGC/MG SIP
| | |
|-----------IAM----------->| Starts T10 |
| |---------INVITE---------->|
| |<---------484-------------|
| |----------ACK------------>|
| | |
| | |
| T10 expires | |
|<----------REL------------| |
Figure 3: REL generation when overlap signalling is used
図3：オーバーラップシグナル伝達が使用される場合のREL生成
The best status code among all the responses received for all the INVITEs that were generated is used to calculate the cause value of the REL as described in RFC 3398 [3].
生成されたすべての招待で受け取ったすべての応答の中で最良のステータスコードは、RFC 3398 [3]で説明されているRELの原因値を計算するために使用されます。
The computation of the best response is done in the same way as forking proxies compute the best response to be returned to the client for a particular INVITE. Note that the best response is not always the response to the INVITE that contained more digits. If the user dials a particular number and then types an extra digit by mistake, a 486 (Busy Here) could be received for the first INVITE and a 484 (Address Incomplete) for the second one (which contained more digits).
最良の応答の計算は、特定の招待のためにクライアントに返される最良の応答をプロキシで計算するのと同じように行われます。最良の応答は、より多くの数字を含む招待への応答ではないことに注意してください。ユーザーが特定の番号にダイヤルしてから誤って余分な数字を入力すると、最初の招待で486（ここではビジー）、2番目の招待で484（アドレス不完全）を受信できます（より多くの数字が含まれていました）。
When overlap signalling in SIP is used, the ingress gateway sends multiple INVITEs. Accordingly, it will receive multiple responses. The responses to all the INVITEs sent, except for one (normally, but not necessarily the last one), are typically 400 class responses (e.g., 484 Address Incomplete) that terminate the INVITE transaction.
SIPのオーバーラップシグナルを使用すると、Ingress Gatewayは複数の招待状を送信します。したがって、複数の応答を受け取ります。送信されたすべての招待状への応答は、通常（通常は最後のものではない）を除き、招待状のトランザクションを終了する400のクラス応答（たとえば、484アドレスの不完全）です。
However, a 183 Session Progress response with a media description can also be received. The media stream will typically contain a message such as, "The number you have just dialed does not exist".
ただし、メディアの説明を使用した183セッションの進行状況応答も受信できます。メディアストリームには、通常、「ダイヤルしたばかりの数は存在しない」などのメッセージが含まれます。
The issue of receiving different 183 Session Progress responses with media descriptions does not only apply to overlap signalling. When vanilla SIP is used, several responses can also arrive to a gateway if the INVITE forked. It is then up to the gateway to decide which media stream should be played to the user.
メディアの説明を使用して異なる183セッションの進捗応答を受信する問題は、オーバーラップシグナル伝達に適用されるだけではありません。バニラSIPを使用すると、招待が分岐した場合、いくつかの応答がゲートウェイに到着することもあります。その後、ゲートウェイまで、ユーザーにどのメディアストリームを再生するかを決定します。
However, overlap signalling adds a requirement to this process. As a general rule, a media stream corresponding to the response to an INVITE with a greater number of digits should be given more priority than media streams from responses with less digits.
ただし、オーバーラップシグナル伝達は、このプロセスに要件を追加します。一般的なルールとして、桁数が少ない応答からメディアストリームよりも優先度が高い招待への応答に対応するメディアストリームは、より少ない数字のストリームよりも優先される必要があります。
When a gateway sends a new INVITE containing new digits, it should not CANCEL the previous INVITE transaction. This CANCEL could arrive before the new INVITE to an egress gateway and trigger a REL before the new INVITE arrived. INVITE transactions are typically terminated by the reception of 4xx responses.
ゲートウェイが新しい数字を含む新しい招待状を送信した場合、以前の招待トランザクションをキャンセルしないでください。このキャンセルは、新しい招待状が到着する前に、出口ゲートウェイへの新しい招待の前に到着し、RELをトリガーする可能性があります。招待トランザクションは通常、4XX応答の受信によって終了します。
However, once a 200 OK response has been received, the gateway should CANCEL all the other INVITE transactions were generated. A particular gateway might implement a timer to wait for some time before sending any CANCEL. This gives time to all the previous INVITE transactions to terminate smoothly without generating more signalling traffic (CANCEL messages).
ただし、200のOK応答が受信されると、ゲートウェイは他のすべての招待取引をキャンセルする必要があります。特定のゲートウェイは、キャンセルを送信する前にしばらく待つためにタイマーを実装する場合があります。これにより、より多くの信号トラフィックを生成せずにスムーズに終了するために、以前のすべての招待トランザクションに時間が与えられます（メッセージのキャンセル）。
In this scenario (the call originates in the SIP network), the gateway receives multiple INVITEs that have the same Call-ID but have different Request-URIs. Upon reception of the first INVITE, the gateway generates an IAM following the procedures described in RFC 3398 [3].
このシナリオ（CALLはSIPネットワークで発信されます）では、ゲートウェイは同じコールアイドを持っているが異なるリクエスト-urisを持つ複数の招待状を受け取ります。最初の招待状を受信すると、ゲートウェイはRFC 3398 [3]に記載されている手順に従ってIAMを生成します。
When a gateway receives a subsequent INVITE with the same Call-ID and From tag as the previous one, and an updated Request-URI, a SAM should be generated as opposed to a new IAM. Upon reception of a subsequent INVITE, the INVITE received previously is answered with 484 Address Incomplete.
ゲートウェイが以前のコールアイドと以前のタグを使用した後続の招待状を受け取った場合、更新されたリクエスト-RIは、新しいIAMとは対照的にSAMを生成する必要があります。その後の招待状を受信すると、以前に受け取った招待状は、484のアドレスが不完全で回答されます。
If the gateway is attached to the PSTN in an area where en-bloc signalling is used, a REL for the previous IAM and a new IAM should be generated.
ゲートウェイがEN-BLOCシグナル伝達が使用されている領域のPSTNに取り付けられている場合、以前のIAMと新しいIAMのRELを生成する必要があります。
When overlap signaling is employed, it is possible that an attacker could send multiple INVITEs containing an incomplete address to the same gateway in an attempt to occupy all available ports and thereby deny service to legitimate callers. Since none of these partially addressed calls would ever complete, in a traditional billing scheme, the sender of the INVITEs might never be charged. To address this threat, the authors recommend that gateway operators authenticate the senders of INVITE requests, first, in order to have some accountability for the source of calls (it is very imprudent to give gateway access to unknown users on the Internet), but second, so that the gateway can determine when multiple calls are originating from the same source in a short period of time. Some sort of threshold of hanging overlap calls should be tracked by the gateway, and after the limit is exceeded, the further similar calls should be rejected to prevent the saturation of gateway trunking resources.
オーバーラップシグナル伝達が採用されると、攻撃者は、利用可能なすべてのポートを占有し、それにより合法的な発信者へのサービスを拒否しようとして、同じゲートウェイに不完全なアドレスを含む複数の招待状を送信できる可能性があります。これらの部分的に対処された呼び出しのいずれも、従来の請求スキームでは、招待者の送信者が請求されることはないかもしれません。この脅威に対処するために、著者は、ゲートウェイオペレーターが最初に招待リクエストの送信者に認証を行うことを推奨します。、ゲートウェイが短期間で同じソースから複数の呼び出しがいつ発信されるかを決定できるようにします。ハンギングオーバーラップコールのある種のしきい値は、ゲートウェイによって追跡する必要があり、制限を超えた後、ゲートウェイトランキングリソースの飽和を防ぐために、さらに同様の呼び出しを拒否する必要があります。
Jonathan Rosenberg, Olli Hynonen, and Mike Pierce provided useful feedback on this document.
Jonathan Rosenberg、Olli Hynonen、およびMike Pierceは、この文書に関する有用なフィードバックを提供しました。
[1] 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.
[1] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M.、E。Schooler、 "SIP：SESSION INIATIATION Protocol"、RFC 3261、2002年6月。
[2] "Application of the ISDN user part of CCITT signaling system no. 7 for international ISDN interconnections", ITU-T Q.767, February 1991.
[2] 「ISDNユーザーの適用CCITTシグナル伝達システムの一部は、国際ISDN相互接続のための7項7」、ITU-T Q.767、1991年2月。
[3] Camarillo, G., Roach, A. B., Peterson, J. and L. Ong, "Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping", RFC 3398, December 2002.
[3] Camarillo、G.、Roach、A。B.、Peterson、J。and L. Ong、「Integrated Services Digital Network（ISDN）ユーザーパーツ（ISUP）セッション開始プロトコル（SIP）マッピング」、RFC 3398、2002年12月。
[4] "Signalling system no. 7 - ISDN user part signalling procedures," ITU-T Q.764, December 1999.
[4] 「シグナリングシステム番号7- ISDNユーザーパーツシグナル伝達手順」、ITU -T Q.764、1999年12月。
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETFは、知的財産またはその他の権利の有効性または範囲に関して、この文書に記載されているテクノロジーの実装または使用に関連すると主張される可能性のある他の権利、またはそのような権利に基づくライセンスがどの程度であるかについての程度に関連する可能性があるという立場はありません。利用可能;また、そのような権利を特定するために努力したことも表明していません。標準トラックおよび標準関連のドキュメントの権利に関するIETFの手順に関する情報は、BCP-11に記載されています。出版のために利用可能にされた権利の請求のコピーと、利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を得ることができますIETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、関心のある当事者に、この基準を実践するために必要な技術をカバーする可能性のある著作権、特許、または特許出願、またはその他の独自の権利を注意深く招待するよう招待しています。情報をIETFエグゼクティブディレクターに宛ててください。
Gonzalo Camarillo Ericsson Advanced Signalling Research Lab. FIN-02420 Jorvas Finland
Gonzalo Camarillo Ericsson Advanced Signaling Research Lab。Fin-02420 Jorvas Finland
EMail: Gonzalo.Camarillo@ericsson.com
Adam Roach dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, TX 75024 USA
Adam Roach Dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano、TX 75024 USA
EMail: adam@dynamicsoft.com
Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 USA
Jon Peterson Neustar、Inc。1800 Sutter St Suite 570 Concord、CA 94520 USA
EMail: jon.peterson@neustar.biz
Lyndon Ong Ciena 5965 Silver Creek Valley Road San Jose, CA 95138 USA
Lyndon Ong Ciena 5965 Silver Creek Valley Road San Jose、CA 95138 USA
EMail: lyong@ciena.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上記の限られた許可は永続的であり、インターネット社会やその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。