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)
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.
著作権（C）インターネット協会（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).
この文書では、セッション開始プロトコル（SIP）へのシグナリング重複総合デジタル通信サービス網ユーザ部（ISUP）をマップする方法を説明します。公衆交換電話網（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.
セッション開始プロトコル（SIP）との間のマッピング[1]とSS7のISDNユーザパート（ISUP）[2] RFC 3398に記載されている[3]。ただし、RFC 3398にのみ考慮ISUPエン圏のシグナルになります。アンブロックシグナリングは、第1のシグナリングメッセージで被呼者の完全な電話番号を送信することから成ります。現代のスイッチは常にアンブロックシグナリングを使用しているが、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.
オーバーラップシグナリングは、第1のシグナリングメッセージでのみ呼び出し先の番号のいくつかの数字を送信する構成されています。また、数字は、後続のシグナリングメッセージで送信されます。重複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は、エン圏シグナリングを使用しています。 INVITEリクエストのRequest-URIは、常に呼び出し先のアドレス全体が含まれています。ネイティブ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シグナリングにシグナリング重なります。被呼者の番号の部分を運ぶすべてのシグナリングメッセージが到着するまでゲートウェイが待機し、だけにし、それは、SIP INVITE要求を生成します。セクション2はエンブロックSIPにこの方法をシグナリングISUP重複を変換する方法について説明します。
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-ブロックシグナリングすることであるがしかし、時には人間のユーザーに受け入れられない（複数の第2）コールセットアップ遅延をもたらします。これらの状況では、オーバーラップシグナリングのいくつかのフォームは、呼設定遅延を最小化するために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（初期アドレスメッセージ）を受信します。数字の残りの部分は、一の以上の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とRELはISUP側に送られます。 T35は15〜20秒とQ.764 [4]で定義されています。
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.
ストップディジットが受信された場合、ゲートウェイは、既に完全な被呼番号を持つINVITEリクエストを生成することができます。そのため、コールはいつものように進行します。
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.
電話番号を表すことができ桁の最小量が受信されると、ゲートウェイは、これまでに受信されている番号が完了数があるかどうかを判断するために番号分析を使用する必要があります。もしそうであれば、ゲートウェイは完全と呼ばれる番号で、INVITEリクエストを生成することができます。そのため、コールはいつものように進行します。
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側に送られ、これまでに収集した数字でINVITE。この後、任意のSAMは無視されました。
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：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）シグナリング重なり、専用ブロックISUP間の変換のために定義されていることに留意されたいです。 PSTNスイッチは、通常、タイマT10の局所的に定義された値を実装 - Q.764によって推奨4-6秒の範囲内ではない場合がある[4] - アンブロックISUPに重なりISUPを変換します。この文書では、T10を使用し、オーバーラップからアンブロックSIP動作に変換するのに適し思わ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シグナリングにそれをマッピングする必要があります。一つの可能なアプローチは、希望IAMで受信桁のINVITEを送信で構成されており、初期ダイアログが確立されると、送信桁はその初期ダイアログ内のSIP要求（例えば、INFO）でのSAMで受信しました。
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.
このアプローチにはいくつかの問題があります。それは初期の初期のダイアログを確立するためのINVITEを受信として（ゲートウェイかもしれない）、リモートSIPユーザエージェントは、すぐに非100暫定応答を送信することが必要です。 RFC 3398における手順に従って現在のゲートウェイは、[3]、そのような暫定的な応答を生成しません。持つゲートウェイでも、オーバーラップシグナリングを使用していない呼び出しでPSTNステートマシンを混乱させ、早期のACMを生成するための進入ゲートウェイを引き起こすような応答（例えば、183セッションプログレス）を生成します。
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.
このアプローチでは、最初のINVITEリクエストがルーティングされると、初期のダイアログ内で送信されるすべての後続の要求は、同じパスをたどります。つまり、彼らは、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を受信するたびに受信含まれたINVITEの送信で構成されています。すべての新しいINVITEて送信するので、新しいトランザクションを表し、それらは異なる方法でルーティングすることができます。この方法で、すべての新しいネットワークにより提供されたSIPサービスを利用することができINVITE。
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).
しかし、さまざまな方法でルーティングされ、後続のINVITEを有するだけでなく、いくつかの問題をもたらします。 INVITE最初は、例えば、特定のゲートウェイにルーティングされるかもしれない、それ以降は他に、INVITE。結果は、両方のゲートウェイは、IAMを生成することです。 IAMS（または両方）のいずれかが不完全数を有しているので、既に消費PSTNリソースを有する、失敗します。それも、両方のアイムスが完了含まれていることが起こる可能性がありますが、異なる数（すなわち、1人の数は、他の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ルーティングインフラストラクチャは、のINVITEが唯一のゲートウェイに到達することを保証する場合にのみ、以下に説明するように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におけるいくつかのダイヤルプラン内では、電話番号が別のものの接頭辞であるかもしれません。この状況は一般的ではありませんが、それが発生する可能性があります。アンブロックシグナリングが使用される場合ディジットがアンブロックシグナリングに配置される前に、このあいまいさが解決されます。オーバーラップシグナリングが、このような状況で使用された場合は、1より別のユーザーを呼び出すことを意図し、発信者が連絡される可能性があります。重複が使用されているPSTNの一部では、電話番号のプレフィックスが別の有効な番号を識別したことがない理由です。それが数と異なる端末の両方であり、有効なアドレスに同じ数のいくつかの短いプレフィックスが可能であるPSTNの部分に到達しようとする場合したがって、SIPのオーバーラップシグナリングが使用されるべきではありません。
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（初期アドレスメッセージ）と電話番号を表すことができる数字の最小量よりも多くを提供する可能性の一つ以上の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].
できるだけ早く桁の最小量が受信されると、ゲートウェイは、INVITE送信及びT10を開始します。このINVITEは、[3] RFC 3398に記載された手順に従って構築されます。
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が更新され、新しいが送信され受信した新たな数字でINVITE。新しいINVITEは最初が送信されたINVITEとしてタグを含むヘッダフィールドから、同じCall-IDと同じを持っていますが、更新のRequest-URIを持っています。新しいRequest-URIは、これまでに受信したすべての数字が含まれています。新しいINVITEのToヘッダーフィールドは、同様にすべての桁が含まれていますが、何のタグを持っていません。
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.
最初のINVITE秒を送信した前に、INVITEに対する応答を受信することが可能であることに留意されたいです。この場合には、受信した応答は、ルートヘッダーフィールドを構築するタグ情報（レコードルートとの接触）を含有するであろう。新しいは、これらのヘッダのいずれかを使用しないでください（新しい数字を含む）送信するINVITE。つまり、新しいINVITEは、タグにどちらもRouteヘッダーフィールドが含まれていません。このように、INVITEこの新しいは、サービスを提供するネットワークによって動的にルーティングすることができます。
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).
新しいINVITEを、当然のことながら、CSeqフィールドを含める必要があります。新しいINVITEの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.
フォークをINVITE場合は、異なる場所からの応答は、一つ以上の早期のダイアログを確立するに到着することがあります。このようPRACKまたはUPDATE、などの新しい要求は、すべての特定の早期ダイアログ内で送信することができます。これは、異なる初期のダイアログのCSEQ数のスペースが異なっていることを意味します。新しいは、リモート宛先のいずれかが先での混乱を避けることで、まだ未使用であるCSEQとINVITEを送信します。
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.
ゲートウェイは、SIP体としてISUPメッセージをカプセル化されている場合は、IAMを配置する必要があり、すべてのSAMは、このINVITEでこれまでに受け取りました。
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を送信するべきではないトランザクションをINVITE。 RELは、これ以上のSAMが到着しない場合にのみ送信され、T10が満了すると、送信されるすべてのINVITEは（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に記載されるように生成された全てのINVITEのために受信されたすべての応答の中で最高のステータスコードは、RELの原因値を計算するために使用されている[3]。
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).
最良の応答の計算は、プロキシは、INVITE、特定のクライアントに返される最良の応答を計算フォークと同じ方法で行われます。最良の応答は、常に複数の数字が含まれていることがINVITEへの応答ではないことに注意してください。ユーザが誤って余分な桁を特定の番号をダイヤルし、次にタイプ場合、（ここでBUSY）486は、（より多くの桁を含有）は、第2のいずれかのINVITE第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におけるオーバーラップシグナリングが使用される場合、入力ゲートウェイは複数のINVITEを送信します。これにより、複数の応答を受信します。 1を除いて、送信されたすべてのINVITEに対する応答（通常は、必ずしも必要ではないが、最後の1）は、通常、INVITEトランザクションを終了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を使用する場合二股INVITE場合、いくつかの応答は、ゲートウェイに到達することができます。これは、ユーザに再生されるべきメディアストリームを決定するゲートウェイまで続いています。
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.
しかし、オーバーラップシグナリングは、このプロセスの要件を追加します。原則として、数字の大きい数でINVITEに対する応答に対応するメディアストリームは、メディアが少ない桁の応答からストリームよりも優先されるべきです。
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.
ゲートウェイは新しい新しい数字を含むINVITEを送信するとき、それは以前のINVITEトランザクションをキャンセルべきではありません。これは新しいが、出口ゲートウェイに招待し、到着した新しいINVITE前にRELをトリガーする前に到着することができCANCEL。 INVITEトランザクションは、通常の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応答が受信された後しかし、ゲートウェイは、他のすべてのINVITEトランザクションが生成されたキャンセルすべきです。特定のゲートウェイは、任意のは、CANCEL送信する前にいくつかの時間を待つようにタイマーを実装する場合があります。これは、より多くのシグナリングトラフィックを（メッセージCANCEL）発生させることなくスムーズに終了するために、以前のすべてのINVITE取引に時間を与えます。
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].
このシナリオでは（コールは、SIPネットワークに起因する）、ゲートウェイは同じCall-IDを有するが、別のRequest-URIを持つ複数のINVITEを受信します。 INVITE最初の受信時に、ゲートウェイは、[3] RFC 3398に記載の手順を以下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.
ゲートウェイは、その後は、同じCall-IDを用いてINVITEと前の、及び更新のRequest-URIとしてタグから受信した場合、新しいIAMとは対照的に、SAMは、生成されるべきです。それ以降の受信がINVITEの際に、以前に受信したINVITE 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.
ゲートウェイは、アンブロックシグナリングが使用されている領域に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.
オーバーラップシグナリングが使用される場合には、攻撃者がすべての利用可能なポートを占有し、それによって、正当な発信者へのサービスを拒否しようとして、同じゲートウェイへの不完全なアドレスを含む複数のINVITEを送信することが可能です。これらのどれも部分的に呼び出し、これまで完全に希望を扱っていないので、従来の課金方式では、招待状の送信者が課金されることはないかもしれません。この脅威に対処するために、著者は第1、第2、呼び出し元のためのいくつかの説明責任を有するために（インターネット上の未知のユーザへのゲートウェイのアクセス権を与えることは非常に軽率である）、ゲートウェイ事業者は、INVITEリクエストの送信者を認証することをお勧めしますが、 、複数のコールを短時間で同じ供給源に由来している場合、ゲートウェイが決定することができるようになっています。重複コールをぶら下げの閾値の何らかのゲートウェイによって追跡されるべきであり、制限を超えた後、さらに同様の通話は、ゲートウェイトランキングリソースの飽和を防止するために拒否されるべきです。
Jonathan Rosenberg, Olli Hynonen, and Mike Pierce provided useful feedback on this document.
ジョナサン・ローゼンバーグ、オッリHynonen、およびマイク・ピアースはこのドキュメントに有益なフィードバックを提供します。
[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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル"、 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.
、ITU-T Q.767、1991年2月[2] "国際ISDN相互接続のためのCCITTシグナリングシステム番号7のISDNユーザ部の応用"。
[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]カマリロ、RFC 3398、2002年12月、G.、ローチ、A. B.、ピーターソン、J.、およびL.オング、 "セッション開始プロトコル（SIP）へのマッピング総合デジタル通信網（ISDN）ユーザ部（ISUP）"。
[4] "Signalling system no. 7 - ISDN user part signalling procedures," ITU-T Q.764, December 1999.
[4] "いいえ信号方式7 - ISDNユーザ部のシグナリング手順、" ITU-T Q.764 12月1999。
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
ゴンサロ・カマリロエリクソン高度なシグナリング研究所。 FIN-02420 Jorvasフィンランド
EMail: Gonzalo.Camarillo@ericsson.com
メールアドレス：Gonzalo.Camarillo@ericsson.com
Adam Roach dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, TX 75024 USA
アダムローチdynamicsoft 5100テニソンパークウェイスイート1200プラノ、TX 75024 USA
EMail: adam@dynamicsoft.com
メールアドレス：adam@dynamicsoft.com
Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 USA
ジョンピーターソンNeuStar、Inc.の1800サッターセントスイート570コンコード、CA 94520 USA
EMail: jon.peterson@neustar.biz
メールアドレス：jon.peterson@neustar.biz
Lyndon Ong Ciena 5965 Silver Creek Valley Road San Jose, CA 95138 USA
リンドン・オングCienaの5965シルバークリーク渓谷の道サンノゼ、CA 95138 USA
EMail: lyong@ciena.com
メールアドレス：lyong@ciena.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。