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
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.
版权所有（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).
本文档描述了一种将综合业务数字网络用户部分（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
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.
RFC 3398[3]中描述了会话发起协议（SIP）[1]和SS7的ISDN用户部分（ISUP）[2]之间的映射。然而，RFC3398只考虑ISUP整体信令。整体信令包括在第一条信令消息中发送被叫方的完整电话号码。尽管现代交换机总是使用整体信令，但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.
重叠信令包括在第一个信令消息中仅发送被叫号码的一些数字。在后续的信令消息中发送更多的数字。虽然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请求的请求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节描述了如何通过这种方式将ISUP重叠信令转换为整体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.
然而，尽管它是首选解决方案，但将重叠转换为整体信令有时会导致人类用户无法接受（多秒）的呼叫设置延迟。在这些情况下，必须在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在收到最小位数（或停止位数）之前过期，则向ISUP侧发送一个原因值为28的REL。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.
如果收到停止数字，网关就可以生成一个包含完整被叫号码的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---------->|
| | |
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]建议的4-6秒范围内——以将重叠ISUP转换为整体ISUP。本文件使用T10并推荐Q.764[4]中定义的值范围，该范围似乎适合从重叠转换为整体SIP操作。计时器值的实际选择取决于本地策略。
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重叠信令（即，一个IAM和一个或多个SAM）的入口网关需要将其映射到SIP信令。一种可能的方法是用IAM中接收到的数字发送INVITE，一旦建立了早期对话，就在该早期对话中以SIP请求（例如，INFO）的形式发送SAMs中接收到的数字。
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.
在这种方法中，一旦初始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代表一个新事务，因此它们可以以不同的方式路由。这样，每个新的INVITE都可以利用网络可能提供的任何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。由于其中一个IAM（或两者）的编号不完整，它将失败，因为它已经消耗了PSTN资源。甚至可能两个IAM都包含完整但不同的数字（即，一个数字是另一个数字的前缀）。
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路由基础设施确保邀请将仅到达一个网关时，网关才能被配置为以下面描述的方式生成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中的某些拨号计划中，电话号码可能是另一个号码的前缀。这种情况并不常见，但也可能发生。在使用整块信令的情况下，在将数字放入整块信令中之前，将解决此歧义。如果在这种情况下使用重叠信令，则可能会联系到与调用者打算呼叫的用户不同的用户。这就是为什么在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（后续地址消息），这些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是按照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，并发送带有接收到的新数字的新邀请。新的INVITE与发送的第一个INVITE具有相同的调用ID和包含标记的From头字段，但具有更新的请求URI。新的请求URI包含迄今为止收到的所有数字。新邀请的To header字段也包含所有数字，但没有标记。
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.
请注意，在发送第二个邀请之前，可以接收对第一个邀请的响应。在这种情况下，收到的响应将包含To标记和信息（记录路由和联系人）以构建路由标头字段。要发送的新邀请（包含新数字）不应使用这些标题中的任何一个。也就是说，新的INVITE既不包含To tag也不包含Route header字段。这样，提供服务的网络就可以动态地路由这个新的邀请。
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发送一个新的邀请，而该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主体，则应将IAM和迄今为止接收到的所有SAM放置在此INVITE中。
PSTN MGC/MG SIP
| | |
|-----------IAM----------->| Starts T10 |
| |---------INVITE---------->|
| | |
|-----------SAM----------->| Starts T10 |
| |---------INVITE---------->|
| | |
|-----------SAM----------->| Starts T10 |
| |---------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).
如果在T10过期之前，挂起的INVITE事务的4xx、5xx或6xx最终响应到达（例如484地址不完整），则网关不应发送任何REL。只有当没有更多SAM到达，T10过期，并且发送的所有邀请都已得到最终响应（不同于200 OK）时，才会发送REL。
PSTN MGC/MG SIP
| | |
|-----------IAM----------->| Starts T10 |
| |---------INVITE---------->|
| |<---------484-------------|
| |----------ACK------------>|
| | |
| | |
| T10 expires | |
|<----------REL------------| |
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).
最佳响应的计算方法与forking代理计算针对特定邀请返回给客户端的最佳响应的方法相同。请注意，最佳响应并不总是对包含更多数字的邀请的响应。如果用户拨了一个特定的号码，然后错误地键入了一个额外的数字，第一个邀请可能会收到486（此处忙），第二个邀请可能会收到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中使用重叠信令时，入口网关发送多个邀请。因此，它将收到多个响应。除了一个（通常，但不一定是最后一个）之外，对发送的所有邀请的响应通常是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事务。此取消可能在新邀请到达出口网关之前到达，并在新邀请到达之前触发REL。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事务。特定网关可能会实现一个计时器，以便在发送任何取消之前等待一段时间。这使所有先前的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网络），网关接收具有相同呼叫ID但具有不同请求URI的多个邀请。在接收到第一个邀请后，网关按照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.
当网关接收到与前一个具有相同呼叫ID和From标记的后续INVITE以及更新的请求URI时，应生成SAM，而不是新的IAM。收到后续邀请后，先前收到的邀请将得到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请求的发送者进行身份验证，首先是为了对呼叫来源负责（将网关访问权授予Internet上的未知用户是非常不明智的），其次是，以便网关能够确定何时在短时间内从同一来源发起多个呼叫。网关应跟踪某种类型的挂起重叠呼叫阈值，超过该限制后，应拒绝进一步的类似呼叫，以防止网关中继资源饱和。
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：会话启动协议”，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] “CCITT第7号信令系统的ISDN用户部分在国际ISDN互连中的应用”，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.和L.Ong，“综合业务数字网（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高级信号研究实验室FIN-02420 Jorvas芬兰
EMail: Gonzalo.Camarillo@ericsson.com
EMail: Gonzalo.Camarillo@ericsson.com
Adam Roach dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, TX 75024 USA
美国德克萨斯州普莱诺市坦尼森大道1200号亚当·罗奇动力软件5100套房，邮编75024
EMail: adam@dynamicsoft.com
EMail: adam@dynamicsoft.com
Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 USA
美国加利福尼亚州康科德市萨特街1800号570室Jon Peterson NeuStar，Inc.94520
EMail: jon.peterson@neustar.biz
EMail: jon.peterson@neustar.biz
Lyndon Ong Ciena 5965 Silver Creek Valley Road San Jose, CA 95138 USA
美国加利福尼亚州圣何塞银溪谷路5965号林登·翁·西纳，邮编95138
EMail: lyong@ciena.com
EMail: 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编辑功能的资金目前由互联网协会提供。