RFC 2637: Point-to-Point Tunneling Protocol (PPTP) 中文翻译

URL : https://datatracker.ietf.org/doc/html/rfc2637
标题 : RFC 2637
翻译类型 : 自动生成

Network Working Group                                          K. Hamzeh
Request for Comments: 2637                         Ascend Communications
Category: Informational                                          G. Pall
                                                   Microsoft Corporation
                                                             W. Verthein
                                                                    3Com
                                                               J. Taarud
                                                Copper Mountain Networks
                                                               W. Little
                                                          ECI Telematics
                                                                 G. Zorn
                                                   Microsoft Corporation
                                                               July 1999

Network Working Group                                          K. Hamzeh
Request for Comments: 2637                         Ascend Communications
Category: Informational                                          G. Pall
                                                   Microsoft Corporation
                                                             W. Verthein
                                                                    3Com
                                                               J. Taarud
                                                Copper Mountain Networks
                                                               W. Little
                                                          ECI Telematics
                                                                 G. Zorn
                                                   Microsoft Corporation
                                                               July 1999

Point-to-Point Tunneling Protocol (PPTP)

点对点隧道协议（PPTP）

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.

本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。

版权公告

IESG Note

IESG注释

The PPTP protocol was developed by a vendor consortium. The documentation of PPTP is provided as information to the Internet community. The PPP WG is currently defining a Standards Track protocol (L2TP) for tunneling PPP across packet-switched networks.

PPTP协议由一个供应商联盟开发。PPTP文件作为信息提供给互联网社区。PPP工作组目前正在定义一个标准跟踪协议（L2TP），用于在分组交换网络上通过隧道传输PPP。

Abstract

摘要

This document specifies a protocol which allows the Point to Point Protocol (PPP) to be tunneled through an IP network. PPTP does not specify any changes to the PPP protocol but rather describes a new vehicle for carrying PPP. A client-server architecture is defined in order to decouple functions which exist in current Network Access Servers (NAS) and support Virtual Private Networks (VPNs). The PPTP Network Server (PNS) is envisioned to run on a general purpose operating system while the client, referred to as a PPTP Access Concentrator (PAC) operates on a dial access platform. PPTP specifies a call-control and management protocol which allows the server to control access for dial-in circuit switched calls originating from a PSTN or ISDN or to initiate outbound circuit-

本文件规定了一种协议，允许点对点协议（PPP）通过IP网络进行隧道传输。PPTP并未规定PPP协议的任何变更，而是描述了一种用于承载PPP的新车辆。定义了客户机-服务器体系结构，以解耦当前网络访问服务器（NAS）中存在的功能，并支持虚拟专用网络（VPN）。PPTP网络服务器（PNS）预计在通用操作系统上运行，而客户端（称为PPTP访问集中器（PAC））在拨号访问平台上运行。PPTP指定呼叫控制和管理协议，该协议允许服务器控制来自PSTN或ISDN的拨入电路交换呼叫的访问，或启动出站电路-

switched connections. PPTP uses an enhanced GRE (Generic Routing Encapsulation) mechanism to provide a flow- and congestion-controlled encapsulated datagram service for carrying PPP packets.

交换连接。PPTP使用增强的GRE（通用路由封装）机制来提供用于承载PPP数据包的流和拥塞控制封装数据报服务。

Specification of Requirements

需求说明

In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as described in [12].

在本文件中，关键词“可能”、“必须”、“不得”、“可选”、“建议”、“应该”和“不应该”的解释如[12]所述。

The words "silently discard", when used in reference to the behavior of an implementation upon receipt of an incoming packet, are to be interpreted as follows: the implementation discards the datagram without further processing, and without indicating an error to the sender. The implementation SHOULD provide the capability of logging the error, including the contents of the discarded datagram, and SHOULD record the event in a statistics counter.

“静默丢弃”一词在用于参考接收到传入数据包时的实现行为时，将被解释为：该实现丢弃数据报，而无需进一步处理，也无需向发送方指示错误。实现应提供记录错误的能力，包括丢弃数据报的内容，并应在统计计数器中记录事件。

Table of Contents

   1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   1.1.  Protocol Goals and Assumptions . . . . . . . . . . . . . .   4
   1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .   5
   1.3.  Protocol Overview  . . . . . . . . . . . . . . . . . . . .   6
   1.3.1.  Control Connection Overview  . . . . . . . . . . . . . .   7
   1.3.2.  Tunnel Protocol Overview . . . . . . . . . . . . . . . .   7
   1.4.  Message Format and Protocol Extensibility  . . . . . . . .   8
   2.  Control Connection Protocol Specification  . . . . . . . . .  10
   2.1.  Start-Control-Connection-Request . . . . . . . . . . . . .  10
   2.2.  Start-Control-Connection-Reply . . . . . . . . . . . . . .  12
   2.3.  Stop-Control-Connection-Request  . . . . . . . . . . . . .  15
   2.4.  Stop-Control-Connection-Reply  . . . . . . . . . . . . . .  16
   2.5.  Echo-Request . . . . . . . . . . . . . . . . . . . . . . .  17
   2.6.  Echo-Reply . . . . . . . . . . . . . . . . . . . . . . . .  18
   2.7.  Outgoing-Call-Request  . . . . . . . . . . . . . . . . . .  19
   2.8.  Outgoing-Call-Reply  . . . . . . . . . . . . . . . . . . .  22
   2.9.  Incoming-Call-Request  . . . . . . . . . . . . . . . . . .  25
   2.10.  Incoming-Call-Reply . . . . . . . . . . . . . . . . . . .  28
   2.11.  Incoming-Call-Connected . . . . . . . . . . . . . . . . .  29
   2.12.  Call-Clear-Request  . . . . . . . . . . . . . . . . . . .  31
   2.13.  Call-Disconnect-Notify  . . . . . . . . . . . . . . . . .  32
   2.14.  WAN-Error-Notify  . . . . . . . . . . . . . . . . . . . .  33
   2.15.  Set-Link-Info . . . . . . . . . . . . . . . . . . . . . .  35
   2.16.  General Error Codes . . . . . . . . . . . . . . . . . . .  36
   3.  Control Connection Protocol Operation  . . . . . . . . . . .  36
   3.1.  Control Connection States  . . . . . . . . . . . . . . . .  37
   3.1.1.  Control Connection Originator (may be PAC or PNS)  . . .  37
   3.1.2.  Control connection Receiver (may be PAC or PNS)  . . . .  39

   1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   1.1.  Protocol Goals and Assumptions . . . . . . . . . . . . . .   4
   1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .   5
   1.3.  Protocol Overview  . . . . . . . . . . . . . . . . . . . .   6
   1.3.1.  Control Connection Overview  . . . . . . . . . . . . . .   7
   1.3.2.  Tunnel Protocol Overview . . . . . . . . . . . . . . . .   7
   1.4.  Message Format and Protocol Extensibility  . . . . . . . .   8
   2.  Control Connection Protocol Specification  . . . . . . . . .  10
   2.1.  Start-Control-Connection-Request . . . . . . . . . . . . .  10
   2.2.  Start-Control-Connection-Reply . . . . . . . . . . . . . .  12
   2.3.  Stop-Control-Connection-Request  . . . . . . . . . . . . .  15
   2.4.  Stop-Control-Connection-Reply  . . . . . . . . . . . . . .  16
   2.5.  Echo-Request . . . . . . . . . . . . . . . . . . . . . . .  17
   2.6.  Echo-Reply . . . . . . . . . . . . . . . . . . . . . . . .  18
   2.7.  Outgoing-Call-Request  . . . . . . . . . . . . . . . . . .  19
   2.8.  Outgoing-Call-Reply  . . . . . . . . . . . . . . . . . . .  22
   2.9.  Incoming-Call-Request  . . . . . . . . . . . . . . . . . .  25
   2.10.  Incoming-Call-Reply . . . . . . . . . . . . . . . . . . .  28
   2.11.  Incoming-Call-Connected . . . . . . . . . . . . . . . . .  29
   2.12.  Call-Clear-Request  . . . . . . . . . . . . . . . . . . .  31
   2.13.  Call-Disconnect-Notify  . . . . . . . . . . . . . . . . .  32
   2.14.  WAN-Error-Notify  . . . . . . . . . . . . . . . . . . . .  33
   2.15.  Set-Link-Info . . . . . . . . . . . . . . . . . . . . . .  35
   2.16.  General Error Codes . . . . . . . . . . . . . . . . . . .  36
   3.  Control Connection Protocol Operation  . . . . . . . . . . .  36
   3.1.  Control Connection States  . . . . . . . . . . . . . . . .  37
   3.1.1.  Control Connection Originator (may be PAC or PNS)  . . .  37
   3.1.2.  Control connection Receiver (may be PAC or PNS)  . . . .  39

   3.1.3.  Start Control Connection Initiation Request Collision  .  40
   3.1.4.  Keep Alives and Timers . . . . . . . . . . . . . . . . .  40
   3.2.  Call States  . . . . . . . . . . . . . . . . . . . . . . .  41
   3.2.1.  Timing considerations  . . . . . . . . . . . . . . . . .  41
   3.2.2.  Call ID Values . . . . . . . . . . . . . . . . . . . . .  41
   3.2.3.  Incoming Calls . . . . . . . . . . . . . . . . . . . . .  41
   3.2.3.1.  PAC Incoming Call States . . . . . . . . . . . . . . .  42
   3.2.3.2.  PNS Incoming Call States . . . . . . . . . . . . . . .  43
   3.2.4.  Outgoing Calls . . . . . . . . . . . . . . . . . . . . .  44
   3.2.4.1.  PAC Outgoing Call States . . . . . . . . . . . . . . .  45
   3.2.4.2.  PNS Outgoing Call States . . . . . . . . . . . . . . .  46
   4.  Tunnel Protocol Operation  . . . . . . . . . . . . . . . . .  47
   4.1.  Enhanced GRE header  . . . . . . . . . . . . . . . . . . .  47
   4.2.  Sliding Window Protocol  . . . . . . . . . . . . . . . . .  49
   4.2.1.  Initial Window Size  . . . . . . . . . . . . . . . . . .  49
   4.2.2.  Closing the Window . . . . . . . . . . . . . . . . . . .  49
   4.2.3.  Opening the Window . . . . . . . . . . . . . . . . . . .  50
   4.2.4.  Window Overflow  . . . . . . . . . . . . . . . . . . . .  50
   4.2.5.  Multi-packet Acknowledgment  . . . . . . . . . . . . . .  50
   4.3.  Out-of-sequence Packets  . . . . . . . . . . . . . . . . .  50
   4.4.  Acknowledgment Time-Outs . . . . . . . . . . . . . . . . .  51
   4.4.1.  Calculating Adaptive Acknowledgment Time-Out . . . . . .  53
   4.4.2.  Congestion Control: Adjusting for Time-Out . . . . . . .  54
   5.  Security Considerations  . . . . . . . . . . . . . . . . . .  54
   6.  Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  55
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . .  56
   8.  Full Copyright Statement . . . . . . . . . . . . . . . . . .  57

   3.1.3.  Start Control Connection Initiation Request Collision  .  40
   3.1.4.  Keep Alives and Timers . . . . . . . . . . . . . . . . .  40
   3.2.  Call States  . . . . . . . . . . . . . . . . . . . . . . .  41
   3.2.1.  Timing considerations  . . . . . . . . . . . . . . . . .  41
   3.2.2.  Call ID Values . . . . . . . . . . . . . . . . . . . . .  41
   3.2.3.  Incoming Calls . . . . . . . . . . . . . . . . . . . . .  41
   3.2.3.1.  PAC Incoming Call States . . . . . . . . . . . . . . .  42
   3.2.3.2.  PNS Incoming Call States . . . . . . . . . . . . . . .  43
   3.2.4.  Outgoing Calls . . . . . . . . . . . . . . . . . . . . .  44
   3.2.4.1.  PAC Outgoing Call States . . . . . . . . . . . . . . .  45
   3.2.4.2.  PNS Outgoing Call States . . . . . . . . . . . . . . .  46
   4.  Tunnel Protocol Operation  . . . . . . . . . . . . . . . . .  47
   4.1.  Enhanced GRE header  . . . . . . . . . . . . . . . . . . .  47
   4.2.  Sliding Window Protocol  . . . . . . . . . . . . . . . . .  49
   4.2.1.  Initial Window Size  . . . . . . . . . . . . . . . . . .  49
   4.2.2.  Closing the Window . . . . . . . . . . . . . . . . . . .  49
   4.2.3.  Opening the Window . . . . . . . . . . . . . . . . . . .  50
   4.2.4.  Window Overflow  . . . . . . . . . . . . . . . . . . . .  50
   4.2.5.  Multi-packet Acknowledgment  . . . . . . . . . . . . . .  50
   4.3.  Out-of-sequence Packets  . . . . . . . . . . . . . . . . .  50
   4.4.  Acknowledgment Time-Outs . . . . . . . . . . . . . . . . .  51
   4.4.1.  Calculating Adaptive Acknowledgment Time-Out . . . . . .  53
   4.4.2.  Congestion Control: Adjusting for Time-Out . . . . . . .  54
   5.  Security Considerations  . . . . . . . . . . . . . . . . . .  54
   6.  Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  55
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . .  56
   8.  Full Copyright Statement . . . . . . . . . . . . . . . . . .  57

1. Introduction

1. 介绍

PPTP allows existing Network Access Server (NAS) functions to be separated using a client-server architecture. Traditionally, the following functions are implemented by a NAS:

PPTP允许使用客户机-服务器体系结构分离现有的网络访问服务器（NAS）功能。传统上，以下功能由NAS实现：

1) Physical native interfacing to PSTN or ISDN and control of external modems or terminal adapters.

1) 与PSTN或ISDN的物理本机接口，并控制外部调制解调器或终端适配器。

A NAS may interface directly to a telco analog or digital circuit or attach via an external modem or terminal adapter. Control of a circuit-switched connection is accomplished with either modem control or DSS1 ISDN call control protocols.

NAS可以直接连接到电信公司的模拟或数字电路，或通过外部调制解调器或终端适配器连接。电路交换连接的控制通过调制解调器控制或DSS1 ISDN呼叫控制协议完成。

The NAS, in conjunction with the modem or terminal adapters, may perform rate adaption, analog to digital conversion, sync to async conversion or a number of other alterations of data streams.

NAS与调制解调器或终端适配器一起，可以执行速率自适应、模拟到数字转换、同步到异步转换或数据流的许多其他更改。

2) Logical termination of a Point-to-Point-Protocol (PPP) Link Control Protocol (LCP) session.

2) 点对点协议（PPP）链路控制协议（LCP）会话的逻辑终止。

3) Participation in PPP authentication protocols [3,9,10].

3) 参与PPP认证协议[3,9,10]。

4) Channel aggregation and bundle management for PPP Multilink Protocol.

4) PPP多链路协议的通道聚合和捆绑管理。

5) Logical termination of various PPP network control protocols (NCP).

5) 各种PPP网络控制协议（NCP）的逻辑终端。

6) Multiprotocol routing and bridging between NAS interfaces.

6) NAS接口之间的多协议路由和桥接。

PPTP divides these functions between the PAC and PNS. The PAC is responsible for functions 1, 2, and possibly 3. The PNS may be responsible for function 3 and is responsible for functions 4, 5, and 6. The protocol used to carry PPP protocol data units (PDUs) between the PAC and PNS, as well as call control and management is addressed by PPTP.

PPTP在PAC和PNS之间划分这些功能。PAC负责功能1、2，可能还有3。PNS可能负责功能3，也可能负责功能4、5和6。PPTP解决了用于在PAC和PNS之间传输PPP协议数据单元（PDU）以及呼叫控制和管理的协议。

The decoupling of NAS functions offers these benefits:

NAS功能的解耦提供了以下好处：

Flexible IP address management. Dial-in users may maintain a single IP address as they dial into different PACs as long as they are served from a common PNS. If an enterprise network uses unregistered addresses, a PNS associated with the enterprise assigns addresses meaningful to the private network.

灵活的IP地址管理。拨入用户可以在拨入不同的PAC时维护一个IP地址，只要它们是从一个公共PNS提供服务的。如果企业网络使用未注册的地址，则与企业关联的PNS会为专用网络分配有意义的地址。

Support of non-IP protocols for dial networks behind IP networks. This allows Appletalk and IPX, for example to be tunneled through an IP-only provider. The PAC need not be capable of processing these protocols.

为IP网络后面的拨号网络支持非IP协议。例如，这允许Appletalk和IPX通过仅限IP的提供程序进行隧道传输。PAC不需要能够处理这些协议。

A solution to the "multilink hunt-group splitting" problem. Multilink PPP, typically used to aggregate ISDN B channels, requires that all of the channels composing a multilink bundle be grouped at a single NAS. Since a multilink PPP bundle can be handled by a single PNS, the channels comprising the bundle may be spread across multiple PACs.

“多链接搜索组拆分”问题的解决方案。通常用于聚合ISDN B信道的多链路PPP要求组成多链路束的所有信道在单个NAS上分组。由于多链路PPP捆绑包可以由单个pn处理，因此组成捆绑包的信道可以分布在多个pac上。

1.1. Protocol Goals and Assumptions

1.1. 协议目标和假设

The PPTP protocol is implemented only by the PAC and PNS. No other systems need to be aware of PPTP. Dial networks may be connected to a PAC without being aware of PPTP. Standard PPP client software should continue to operate on tunneled PPP links.

PPTP协议仅由PAC和PNS实施。没有其他系统需要知道PPTP。拨号网络可以在不知道PPTP的情况下连接到PAC。标准PPP客户端软件应继续在隧道PPP链路上运行。

PPTP can also be used to tunnel a PPP session over an IP network. In this configuration the PPTP tunnel and the PPP session runs between the same two machines with the caller acting as a PNS.

PPTP还可用于通过IP网络隧道PPP会话。在此配置中，PPTP隧道和PPP会话在相同的两台机器之间运行，调用者充当PNS。

It is envisioned that there will be a many-to-many relationship between PACs and PNSs. A PAC may provide service to many PNSs. For example, an Internet service provider may choose to support PPTP for a number of private network clients and create VPNs for them. Each private network may operate one or more PNSs. A single PNS may associate with many PACs to concentrate traffic from a large number of geographically diverse sites.

预计PACs和PNS之间将存在多对多关系。PAC可以向多个PNS提供服务。例如，Internet服务提供商可以选择为许多专用网络客户端支持PPTP，并为它们创建VPN。每个专用网络可以操作一个或多个pns。单个PNS可能与多个PAC关联，以集中来自大量地理位置不同的站点的流量。

PPTP uses an extended version of GRE to carry user PPP packets. These enhancements allow for low-level congestion and flow control to be provided on the tunnels used to carry user data between PAC and PNS. This mechanism allows for efficient use of the bandwidth available for the tunnels and avoids unnecessary retransmisions and buffer overruns. PPTP does not dictate the particular algorithms to be used for this low level control but it does define the parameters that must be communicated in order to allow such algorithms to work. Suggested algorithms are included in section 4.

PPTP使用GRE的扩展版本来承载用户PPP数据包。这些增强功能允许在用于在PAC和PNS之间传输用户数据的隧道上提供低级别的拥塞和流量控制。这种机制允许有效利用隧道可用的带宽，并避免不必要的重传和缓冲区溢出。PPTP没有规定用于此低级别控制的特定算法，但它确实定义了必须通信的参数，以便允许此类算法工作。建议的算法包含在第4节中。

1.2. Terminology

1.2. 术语

Analog Channel

模拟通道

A circuit-switched communication path which is intended to carry 3.1 Khz audio in each direction.

一种电路交换通信路径，用于在每个方向上传输3.1 Khz音频。

Digital Channel

数字频道

A circuit-switched communication path which is intended to carry digital information in each direction.

一种电路交换通信路径，用于在每个方向上传送数字信息。

Call

呼叫

A connection or attempted connection between two terminal endpoints on a PSTN or ISDN -- for example, a telephone call between two modems.

PSTN或ISDN上两个终端端点之间的连接或尝试的连接——例如，两个调制解调器之间的电话呼叫。

Control Connection

控制连接

A control connection is created for each PAC, PNS pair and operates over TCP [4]. The control connection governs aspects of the tunnel and of sessions assigned to the tunnel.

为每个PAC、PNS对创建一个控制连接，并通过TCP进行操作[4]。控制连接控制隧道和分配给隧道的会话的各个方面。

Dial User

拨号用户

An end-system or router attached to an on-demand PSTN or ISDN which is either the initiator or recipient of a call.

连接到按需PSTN或ISDN的终端系统或路由器，它是呼叫的发起方或接收方。

Network Access Server (NAS)

网络访问服务器（NAS）

A device providing temporary, on-demand network access to users. This access is point-to-point using PSTN or ISDN lines.

向用户提供临时的按需网络访问的设备。此访问是使用PSTN或ISDN线路的点对点访问。

PPTP Access Concentrator (PAC)

PPTP接入集中器（PAC）

A device attached to one or more PSTN or ISDN lines capable of PPP operation and of handling the PPTP protocol. The PAC need only implement TCP/IP to pass traffic to one or more PNSs. It may also tunnel non-IP protocols.

连接到一条或多条PSTN或ISDN线路的设备，能够进行PPP操作并处理PPTP协议。PAC只需实现TCP/IP即可将流量传递给一个或多个PNS。它还可以通过隧道传输非IP协议。

PPTP Network Server (PNS)

PPTP网络服务器（PNS）

A PNS is envisioned to operate on general-purpose computing/server platforms. The PNS handles the server side of the PPTP protocol. Since PPTP relies completely on TCP/IP and is independent of the interface hardware, the PNS may use any combination of IP interface hardware including LAN and WAN devices.

PNS设想在通用计算/服务器平台上运行。PNS处理PPTP协议的服务器端。由于PPTP完全依赖于TCP/IP并且独立于接口硬件，因此PNS可以使用包括LAN和WAN设备的IP接口硬件的任何组合。

Session

一场

PPTP is connection-oriented. The PNS and PAC maintain state for each user that is attached to a PAC. A session is created when end-to-end PPP connection is attempted between a dial user and the PNS. The datagrams related to a session are sent over the tunnel between the PAC and PNS.

PPTP是面向连接的。PNS和PAC为连接到PAC的每个用户维护状态。当拨号用户和PNS之间尝试端到端PPP连接时，将创建会话。与会话相关的数据报通过PAC和PNS之间的隧道发送。

Tunnel

地下通道

A tunnel is defined by a PNS-PAC pair. The tunnel protocol is defined by a modified version of GRE [1,2]. The tunnel carries PPP datagrams between the PAC and the PNS. Many sessions are multiplexed on a single tunnel. A control connection operating over TCP controls the establishment, release, and maintenance of sessions and of the tunnel itself.

隧道由PNS-PAC对定义。隧道协议由GRE[1,2]的修改版本定义。隧道在PAC和PNS之间传输PPP数据报。许多会话在单个通道上多路复用。通过TCP操作的控制连接控制会话和隧道本身的建立、释放和维护。

1.3. Protocol Overview

1.3. 协议概述

There are two parallel components of PPTP: 1) a Control Connection between each PAC-PNS pair operating over TCP and 2) an IP tunnel operating between the same PAC-PNS pair which is used to transport GRE encapsulated PPP packets for user sessions between the pair.

PPTP有两个并行组件：1）在TCP上运行的每个PAC-PNS对之间的控制连接，2）在同一个PAC-PNS对之间运行的IP隧道，用于在对之间传输GRE封装的PPP数据包，用于用户会话。

1.3.1. Control Connection Overview

1.3.1. 控制连接概述

Before PPP tunneling can occur between a PAC and PNS, a control connection must be established between them. The control connection is a standard TCP session over which PPTP call control and management information is passed. The control session is logically associated with, but separate from, the sessions being tunneled through a PPTP tunnel. For each PAC-PNS pair both a tunnel and a control connection exist. The control connection is responsible for establishment, management, and release of sessions carried through the tunnel. It is the means by which a PNS is notified of an incoming call at an associated PAC, as well as the means by which a PAC is instructed to place an outgoing dial call.

在PAC和PNS之间进行PPP隧道之前，必须在它们之间建立控制连接。控制连接是一个标准TCP会话，PPTP调用控制和管理信息通过该会话传递。控制会话在逻辑上与通过PPTP隧道传输的会话相关联，但与之分离。对于每个PAC-PNS对，都存在一个隧道和一个控制连接。控制连接负责建立、管理和释放通过隧道进行的会话。它是在相关PAC处通知PNS来电的方式，以及指示PAC拨打拨出电话的方式。

A control connection can be established by either the PNS or the PAC. Following the establishment of the required TCP connection, the PNS and PAC establish the control connection using the Start-Control-Connection-Request and -Reply messages. These messages are also used to exchange information about basic operating capabilities of the PAC and PNS. Once the control connection is established, the PAC or PNS may initiate sessions by requesting outbound calls or responding to inbound requests. The control connection may communicate changes in operating characteristics of an individual user session with a Set-Link-Info message. Individual sessions may be released by either the PAC or PNS, also through Control Connection messages.

可以通过PNS或PAC建立控制连接。在建立所需的TCP连接之后，PNS和PAC使用启动控制连接请求和-应答消息建立控制连接。这些消息还用于交换有关PAC和PNS基本操作能力的信息。一旦建立了控制连接，PAC或PNS可以通过请求出站呼叫或响应入站请求来启动会话。控制连接可以使用Set Link Info消息来传递单个用户会话的操作特性的变化。PAC或PNS也可以通过控制连接消息来释放单个会话。

The control connection itself is maintained by keep-alive echo messages. This ensures that a connectivity failure between the PNS and the PAC can be detected in a timely manner. Other failures can be reported via the

控制连接本身由保持活动的回显消息维护。这可确保及时检测到PNS和PAC之间的连接故障。其他故障可通过以下方式报告：

Wan-Error-Notify message, also on the control connection.

Wan错误通知消息，也在控制连接上。

It is intended that the control connection will also carry management related messages in the future, such as a message allowing the PNS to request the status of a given PAC; these message types have not yet been defined.

预期控制连接将来也将携带与管理相关的消息，例如允许PNS请求给定PAC的状态的消息；这些消息类型尚未定义。

1.3.2. Tunnel Protocol Overview

1.3.2. 隧道协议概述

PPTP requires the establishment of a tunnel for each communicating PNS-PAC pair. This tunnel is used to carry all user session PPP packets for sessions involving a given PNS-PAC pair. A key which is present in the GRE header indicates which session a particular PPP packet belongs to.

PPTP要求为每个通信PNS-PAC对建立一个隧道。此隧道用于为涉及给定PNS-PAC对的会话承载所有用户会话PPP数据包。GRE报头中的密钥指示特定PPP数据包属于哪个会话。

In this manner, PPP packets are multiplexed and demultiplexed over a single tunnel between a given PNS-PAC pair. The value to use in the key field is established by the call establishment procedure which takes place on the control connection.

以这种方式，PPP分组在给定PNS-PAC对之间的单个隧道上被多路复用和解多路复用。键字段中要使用的值由控制连接上发生的呼叫建立过程确定。

The GRE header also contains acknowledgment and sequencing information that is used to perform some level of congestion-control and error detection over the tunnel. Again the control connection is used to determine rate and buffering parameters that are used to regulate the flow of PPP packets for a particular session over the tunnel. PPTP does not specify the particular algorithms to use for congestion-control and flow-control. Suggested algorithms for the determination of adaptive time-outs to recover from dropped data or acknowledgments on the tunnel are included in section 4.4 of this document.

GRE报头还包含确认和排序信息，用于在隧道上执行某种程度的拥塞控制和错误检测。同样，控制连接用于确定速率和缓冲参数，这些参数用于调节隧道上特定会话的PPP数据包流。PPTP没有指定用于拥塞控制和流量控制的特定算法。本文件第4.4节包含了用于确定自适应超时以从隧道上丢失的数据或确认中恢复的建议算法。

1.4. Message Format and Protocol Extensibility

1.4. 消息格式和协议扩展性

PPTP defines a set of messages sent as TCP data on the control connection between a PNS and a given PAC. The TCP session for the control connection is established by initiating a TCP connection to port 1723 [6]. The source port is assigned to any unused port number.

PPTP定义了在PNS和给定PAC之间的控制连接上作为TCP数据发送的一组消息。通过启动到端口1723的TCP连接来建立控制连接的TCP会话[6]。源端口分配给任何未使用的端口号。

Each PPTP Control Connection message begins with an 8 octet fixed header portion. This fixed header contains the following: the total length of the message, the PPTP Message Type indicator, and a "Magic Cookie".

每个PPTP控制连接消息都以8个八位组的固定头部分开始。此固定标头包含以下内容：消息的总长度、PPTP消息类型指示符和“魔法Cookie”。

Two Control Connection message types are indicated by the PPTP Message Type field:

PPTP消息类型字段指示两种控制连接消息类型：

1 - Control Message 2 - Management Message

1-控制消息2-管理消息

Management messages are currently not defined.

当前未定义管理消息。

The Magic Cookie is always sent as the constant 0x1A2B3C4D. Its basic purpose is to allow the receiver to ensure that it is properly synchronized with the TCP data stream. It should not be used as a means for resynchronizing the TCP data stream in the event that a transmitter issues an improperly formatted message. Loss of synchronization must result in immediate closing of the control connection's TCP session.

魔法Cookie始终作为常量0x1A2B3C4D发送。其基本目的是允许接收方确保其与TCP数据流正确同步。如果发送器发出格式不正确的消息，则不应将其用作重新同步TCP数据流的手段。同步丢失必须导致立即关闭控制连接的TCP会话。

For clarity, all Control Connection message templates in the next section include the entire PPTP Control Connection message header. Numbers preceded by 0x are hexadecimal values.

为清楚起见，下一节中的所有控制连接消息模板都包括整个PPTP控制连接消息头。前面带有0x的数字是十六进制值。

The currently defined Control Messages, grouped by function, are:

按功能分组的当前定义的控制消息包括：

Control Message Message Code

控制信息代码

(Control Connection Management)

（控制连接管理）

Start-Control-Connection-Request 1 Start-Control-Connection-Reply 2 Stop-Control-Connection-Request 3 Stop-Control-Connection-Reply 4 Echo-Request 5 Echo-Reply 6

启动控制连接请求1启动控制连接回复2停止控制连接请求3停止控制连接回复4回显请求5回显回复6

(Call Management)

（呼叫管理）

Outgoing-Call-Request 7 Outgoing-Call-Reply 8 Incoming-Call-Request 9 Incoming-Call-Reply 10 Incoming-Call-Connected 11 Call-Clear-Request 12 Call-Disconnect-Notify 13

呼出呼叫请求7呼出呼叫应答8呼入呼叫请求9呼入呼叫应答10呼入呼叫已连接11呼叫清除请求12呼叫断开通知13

(Error Reporting)

（错误报告）

WAN-Error-Notify 14

广域网错误通知14

(PPP Session Control)

（PPP会话控制）

Set-Link-Info 15

设置链接信息15

The Start-Control-Connection-Request and -Reply messages determine which version of the Control Connection protocol will be used. The version number field carried in these messages consists of a version number in the high octet and a revision number in the low octet. Version handling is described in section 2. The current value of the version number field is 0x0100 for version 1, revision 0.

启动控制连接请求和-回复消息确定将使用哪个版本的控制连接协议。这些消息中包含的版本号字段由高八位字节中的版本号和低八位字节中的修订号组成。第2节描述了版本处理。对于版本1，版本0，版本号字段的当前值为0x0100。

The use of the GRE-like header for the encapsulation of PPP user packets is specified in section 4.1.

第4.1节规定了使用类GRE报头封装PPP用户数据包。

The MTU for the user data packets encapsulated in GRE is 1532 octets, not including the IP and GRE headers.

GRE中封装的用户数据包的MTU为1532个八位字节，不包括IP和GRE头。

2. Control Connection Protocol Specification

2. 控制连接协议规范

Control Connection messages are used to establish and clear user sessions. The first set of Control Connection messages are used to maintain the control connection itself. The control connection is initiated by either the PNS or PAC after they establish the underlying TCP connection. The procedure and configuration information required to determine which TCP connections are established is not covered by this protocol.

控制连接消息用于建立和清除用户会话。第一组控制连接消息用于维护控制连接本身。控制连接由PNS或PAC在建立基础TCP连接后启动。本协议不包括确定建立哪些TCP连接所需的过程和配置信息。

The following Control Connection messages are all sent as user data on the established TCP connection between a given PNS-PAC pair. Note that care has been taken to ensure that all word (2 octet) and longword (4 octet) values begin on appropriate boundaries. All data is sent in network order (high order octets first). Any "reserved" fields MUST be sent as 0 values to allow for protocol extensibility.

以下控制连接消息均作为给定PNS-PAC对之间已建立TCP连接的用户数据发送。请注意，已注意确保所有单词（2个八位字节）和长单词（4个八位字节）值都从适当的边界开始。所有数据以网络顺序发送（高阶八位字节优先）。任何“保留”字段必须作为0值发送，以允许协议扩展。

2.1. Start-Control-Connection-Request

2.1. 启动控制连接请求

The Start-Control-Connection-Request is a PPTP control message used to establish the control connection between a PNS and a PAC. Each PNS-PAC pair requires a dedicated control connection to be established. A control connection must be established before any other PPTP messages can be issued. The establishment of the control connection can be initiated by either the PNS or PAC. A procedure which handles the occurrence of a collision between PNS and PAC Start-Control-Connection-Requests is described in section 3.1.3.

启动控制连接请求是用于在PNS和PAC之间建立控制连接的PPTP控制消息。每个PNS-PAC对都需要建立专用的控制连接。必须先建立控制连接，然后才能发出任何其他PPTP消息。控制连接的建立可由PNS或PAC启动。第3.1.3节描述了处理PNS和PAC启动控制连接请求之间发生冲突的程序。

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Length            |       PPTP Message Type       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Magic Cookie                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Control Message Type      |           Reserved0           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Protocol Version        |           Reserved1           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Framing Capabilities                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Bearer Capabilities                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Maximum Channels        |       Firmware Revision       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                     Host Name (64 octets)                     +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                   Vendor String (64 octets)                   +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Length            |       PPTP Message Type       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Magic Cookie                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Control Message Type      |           Reserved0           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Protocol Version        |           Reserved1           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Framing Capabilities                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Bearer Capabilities                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Maximum Channels        |       Firmware Revision       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                     Host Name (64 octets)                     +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                   Vendor String (64 octets)                   +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Length Total length in octets of this PPTP message, including the entire PPTP header.

长度此PPTP消息的总长度（以八位字节为单位），包括整个PPTP标头。

PPTP Message Type 1 for Control Message.

控制消息的PPTP消息类型1。

Magic Cookie 0x1A2B3C4D. This constant value is used as a sanity check on received messages (see section 1.4).

神奇饼干0x1A2B3C4D。该常量值用作接收消息的健全性检查（见第1.4节）。

Control Message Type 1 for Start-Control-Connection-Request.

启动控制连接请求的控制消息类型1。

Reserved0 This field MUST be 0.

Reserved0此字段必须为0。

Protocol Version The version of the PPTP protocol that the sender wishes to use.

协议版本发送方希望使用的PPTP协议的版本。

Reserved1 This field MUST be 0.

Reserved1此字段必须为0。

Framing Capabilities A set of bits indicating the type of framing that the sender of this message can provide. The currently defined bit settings are:

帧功能一组位，指示此消息的发送方可以提供的帧类型。当前定义的位设置为：

1 - Asynchronous Framing supported

1-支持异步帧

2 - Synchronous Framing supported

2-支持同步帧

Bearer Capabilities A set of bits indicating the bearer capabilities that the sender of this message can provide. The currently defined bit settings are:

承载能力一组位，指示此消息的发送方可以提供的承载能力。当前定义的位设置为：

1 - Analog access supported

1-支持模拟访问

2 - Digital access supported

2-支持数字访问

Maximum Channels The total number of individual PPP sessions this PAC can support. In Start-Control-Connection-Requests issued by the PNS, this value SHOULD be set to 0. It MUST be ignored by the PAC.

最大通道—此PAC可支持的单个PPP会话总数。在PNS发出的启动控制连接请求中，此值应设置为0。委员会必须忽略这一点。

Firmware Revision This field contains the firmware revision number of the issuing PAC, when issued by the PAC, or the version of the PNS PPTP driver if issued by the PNS.

固件版本此字段包含PAC发布时发布PAC的固件版本号，或PNS PPTP驱动程序的版本（如果由PNS发布）。

Host Name A 64 octet field containing the DNS name of the issuing PAC or PNS. If less than 64 octets in length, the remainder of this field SHOULD be filled with octets of value 0.

主机名包含发出PAC或PNS的DNS名称的64个八位字段。如果长度小于64个八位字节，则此字段的其余部分应填充值为0的八位字节。

Vendor Name A 64 octet field containing a vendor specific string describing the type of PAC being used, or the type of PNS software being used if this request is issued by the PNS. If less than 64 octets in length, the remainder of this field SHOULD be filled with octets of value 0.

供应商名称64个八位字节的字段，其中包含供应商特定的字符串，该字符串描述正在使用的PAC的类型，或者如果此请求是由PNS发出的，则描述正在使用的PNS软件的类型。如果长度小于64个八位字节，则此字段的其余部分应填充值为0的八位字节。

2.2. Start-Control-Connection-Reply

2.2. 启动控制连接应答

The Start-Control-Connection-Reply is a PPTP control message sent in reply to a received Start-Control-Connection-Request message. This message contains a result code indicating the result of the control connection establishment attempt.

启动控制连接回复是一条PPTP控制消息，发送该消息是为了回复收到的启动控制连接请求消息。此消息包含一个结果代码，指示尝试建立控制连接的结果。

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Length            |       PPTP Message Type       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Magic Cookie                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Control Message Type      |           Reserved0           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Protocol Version        |  Result Code  |  Error Code   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Framing Capability                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Bearer Capability                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Maximum Channels        |       Firmware Revision       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                     Host Name (64 octets)                     +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                   Vendor String (64 octets)                   +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Length            |       PPTP Message Type       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Magic Cookie                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Control Message Type      |           Reserved0           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Protocol Version        |  Result Code  |  Error Code   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Framing Capability                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Bearer Capability                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Maximum Channels        |       Firmware Revision       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                     Host Name (64 octets)                     +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                   Vendor String (64 octets)                   +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Length Total length in octets of this PPTP message, including the entire PPTP header.

长度此PPTP消息的总长度（以八位字节为单位），包括整个PPTP标头。

PPTP Message Type 1 for Control Message.

控制消息的PPTP消息类型1。

Magic Cookie 0x1A2B3C4D.

神奇饼干0x1A2B3C4D。

Control Message Type 2 for Start-Control-Connection-Reply.

启动控制连接回复的控制消息类型2。

Reserved0 This field MUST be 0.

Reserved0此字段必须为0。

Protocol Version The version of the PPTP protocol that the sender wishes to use.

协议版本发送方希望使用的PPTP协议的版本。

Result Code Indicates the result of the command channel establishment attempt. Current valid Result Code values are:

结果代码表示命令通道建立尝试的结果。当前有效的结果代码值为：

1 - Successful channel establishment

1-成功建立渠道

2 - General error -- Error Code indicates the problem

2-一般错误-错误代码指示问题

3 - Command channel already exists;

3-命令通道已存在；

4 - Requester is not authorized to establish a command channel

4-请求者无权建立命令通道

5 - The protocol version of the requester is not supported

5-不支持请求程序的协议版本

Error Code This field is set to 0 unless a "General Error" exists, in which case Result Code is set to 2 and this field is set to the value corresponding to the general error condition as specified in section 2.2.

错误代码除非存在“一般错误”，否则此字段设置为0，在这种情况下，结果代码设置为2，并且此字段设置为与第2.2节中规定的一般错误条件对应的值。

Framing Capabilities A set of bits indicating the type of framing that the sender of this message can provide. The currently defined bit settings are:

帧功能一组位，指示此消息的发送方可以提供的帧类型。当前定义的位设置为：

1 - Asynchronous Framing supported

1-支持异步帧

2 - Synchronous Framing supported.

2-支持同步帧。

Bearer Capabilities A set of bits indicating the bearer capabilities that the sender of this message can provide. The currently defined bit settings are:

承载能力一组位，指示此消息的发送方可以提供的承载能力。当前定义的位设置为：

1 - Analog access supported

1-支持模拟访问

2 - Digital access supported

2-支持数字访问

Maximum Channels The total number of individual PPP sessions this PAC can support. In a Start-Control-Connection-Reply issued by the PNS, this value SHOULD be set to 0 and it must be ignored by the PAC. The PNS MUST NOT use this value to try to track the remaining number of PPP sessions that the PAC will allow.

最大通道—此PAC可支持的单个PPP会话总数。在PNS发出的启动控制连接回复中，该值应设置为0，PAC必须忽略该值。PNS不得使用此值尝试跟踪PAC将允许的剩余PPP会话数。

Firmware Revision This field contains the firmware revision number of the issuing PAC, or the version of the PNS PPTP driver if issued by the PNS.

固件版本此字段包含发布PAC的固件版本号，或PNS PPTP驱动程序的版本（如果由PNS发布）。

Host Name A 64 octet field containing the DNS name of the issuing PAC or PNS. If less than 64 octets in length, the remainder of this field SHOULD be filled with octets of value 0.

主机名包含发出PAC或PNS的DNS名称的64个八位字段。如果长度小于64个八位字节，则此字段的其余部分应填充值为0的八位字节。

2.3. Stop-Control-Connection-Request

2.3. 停止控制连接请求

The Stop-Control-Connection-Request is a PPTP control message sent by one peer of a PAC-PNS control connection to inform the other peer that the control connection should be closed. In addition to closing the control connection, all active user calls are implicitly cleared. The reason for issuing this request is indicated in the Reason field.

停止控制连接请求是由PAC-PNS控制连接的一个对等方发送的PPTP控制消息，用于通知另一个对等方控制连接应关闭。除了关闭控制连接外，所有活动的用户调用都会被隐式清除。发出此请求的原因在“原因”字段中指明。

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Length            |       PPTP Message Type       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Magic Cookie                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Control Message Type      |           Reserved0           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Reason     |   Reserved1   |           Reserved2           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Length            |       PPTP Message Type       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Magic Cookie                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Control Message Type      |           Reserved0           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Reason     |   Reserved1   |           Reserved2           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Length Total length in octets of this PPTP message, including the entire PPTP header.

长度此PPTP消息的总长度（以八位字节为单位），包括整个PPTP标头。

PPTP Message Type 1 for Control Message.

控制消息的PPTP消息类型1。

Magic Cookie 0x1A2B3C4D.

神奇饼干0x1A2B3C4D。

Control Message Type 3 for Stop-Control-Connection-Request.

停止控制连接请求的控制消息类型3。

Reserved0 This field MUST be 0.

Reserved0此字段必须为0。

Reason Indicates the reason for the control connection being closed. Current valid Reason values are:

原因指示关闭控制连接的原因。当前有效的原因值为：

1 (None) - General request to clear control connection

1（无）-清除控制连接的一般请求

2 (Stop-Protocol) - Can't support peer's version of the protocol

2（停止协议）-无法支持对等方版本的协议

3 (Stop-Local-Shutdown) - Requester is being shut down

3（停止本地关闭）-请求程序正在关闭

Reserved1, Reserved2 These fields MUST be 0.

Reserved1、Reserved2这些字段必须为0。

2.4. Stop-Control-Connection-Reply

2.4. 停止控制连接应答

The Stop-Control-Connection-Reply is a PPTP control message sent by one peer of a PAC-PNS control connection upon receipt of a Stop-Control-Connection-Request from the other peer.

停止控制连接回复是由PAC-PNS控制连接的一个对等方在收到另一个对等方的停止控制连接请求后发送的PPTP控制消息。

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Length             |       PPTP Message Type       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Magic Cookie                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Control Message Type      |           Reserved0           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Result Code  |   Error Code  |           Reserved1           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Length             |       PPTP Message Type       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Magic Cookie                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Control Message Type      |           Reserved0           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Result Code  |   Error Code  |           Reserved1           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Length Total length in octets of this PPTP message, including the entire PPTP header.

长度此PPTP消息的总长度（以八位字节为单位），包括整个PPTP标头。

PPTP Message Type 1 for Control Message.

控制消息的PPTP消息类型1。

Magic Cookie 0x1A2B3C4D.

神奇饼干0x1A2B3C4D。

Control Message Type 4 for Stop-Control-Connection-Reply.

停止控制连接回复的控制消息类型4。

Reserved0 This field MUST be 0.

Reserved0此字段必须为0。

Result Code Indicates the result of the attempt to close the control connection. Current valid Result Code values are:

结果代码表示尝试关闭控制连接的结果。当前有效的结果代码值为：

1 (OK) - Control connection closed

1（正常）-控制连接关闭

2 (General Error) - Control connection not closed for reason indicated in Error Code

2（一般错误）-由于错误代码中指示的原因，控制连接未关闭

Reserved1 This field MUST be 0.

Reserved1此字段必须为0。

2.5. Echo-Request

2.5. 回显请求

The Echo-Request is a PPTP control message sent by either peer of a PAC-PNS control connection. This control message is used as a "keep-alive" for the control connection. The receiving peer issues an Echo-Reply to each Echo-Request received. As specified in section 3.1.4, if the sender does not receive an Echo-Reply in response to an Echo-Request, it will eventually clear the control connection.

Echo请求是由PAC-PNS控制连接的任一对等方发送的PPTP控制消息。此控制消息用作控制连接的“保持活动”。接收对等方对接收到的每个回显请求发出回显回复。如第3.1.4节所述，如果发送方没有收到回应回显请求的回显回复，它将最终清除控制连接。

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Length             |       PPTP Message Type       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Magic Cookie                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Control Message Type      |           Reserved0           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Identifier                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Length             |       PPTP Message Type       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Magic Cookie                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Control Message Type      |           Reserved0           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Identifier                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Length Total length in octets of this PPTP message, including the entire PPTP header.

长度此PPTP消息的总长度（以八位字节为单位），包括整个PPTP标头。

PPTP Message Type 1 for Control Message.

控制消息的PPTP消息类型1。

Magic Cookie 0x1A2B3C4D.

神奇饼干0x1A2B3C4D。

Control Message Type 5 for Echo-Request.

回显请求的控制消息类型5。

Reserved0 This field MUST be 0.

Reserved0此字段必须为0。

Identifier A value set by the sender of the Echo-Request that is used to match the reply with the corresponding request.

标识符回显请求的发送方设置的值，用于将应答与相应的请求相匹配。

2.6. Echo-Reply

2.6. 回音回复

The Echo-Reply is a PPTP control message sent by either peer of a PAC-PNS control connection in response to the receipt of an Echo-Request.

回送回复是由PAC-PNS控制连接的任一对等方发送的PPTP控制消息，以响应回送请求的接收。

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Length             |      PPTP Message Type        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Magic Cookie                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Control Message Type      |           Reserved0           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Identifier                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Result Code  |   Error Code  |           Reserved1           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Length             |      PPTP Message Type        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Magic Cookie                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Control Message Type      |           Reserved0           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Identifier                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Result Code  |   Error Code  |           Reserved1           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Length Total length in octets of this PPTP message, including the entire PPTP header.

长度此PPTP消息的总长度（以八位字节为单位），包括整个PPTP标头。

PPTP Message Type 1 for Control Message.

控制消息的PPTP消息类型1。

Magic Cookie 0x1A2B3C4D.

神奇饼干0x1A2B3C4D。

Control Message Type 6 for Echo-Reply.

回显回复的控制消息类型6。

Reserved0 This field MUST be 0.

Reserved0此字段必须为0。

Identifier The contents of the identify field from the received Echo-Request is copied to this field.

标识符收到的回显请求中标识字段的内容复制到此字段。

Result Code Indicates the result of the receipt of the Echo-Request. Current valid Result Code values are:

结果代码表示接收回显请求的结果。当前有效的结果代码值为：

1 (OK) - The Echo-Reply is valid

1（确定）-回音回复有效

2 (General Error) - Echo-Request not accepted for the reason indicated in Error Code

2（一般错误）-由于错误代码中指示的原因，不接受回显请求

Error Code This field is set to 0 unless a "General Error" condition exists, in which case Result Code is set to 2 and this field is set to the value corresponding to the general error condition as specified in section 2.2.

错误代码除非存在“一般错误”条件，否则此字段设置为0，在这种情况下，结果代码设置为2，并且此字段设置为与第2.2节中规定的一般错误条件对应的值。

Reserved1 This field MUST be 0.

Reserved1此字段必须为0。

2.7. Outgoing-Call-Request

2.7. 外呼请求

The Outgoing-Call-Request is a PPTP control message sent by the PNS to the PAC to indicate that an outbound call from the PAC is to be established. This request provides the PAC with information required to make the call. It also provides information to the PAC that is used to regulate the transmission of data to the PNS for this session once it is established.

传出呼叫请求是由PNS发送给PAC的PPTP控制消息，用于指示将建立来自PAC的出站呼叫。此请求向PAC提供拨打电话所需的信息。它还向PAC提供信息，用于在建立该会话后调节向PNS的数据传输。

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Length             |       PPTP Message Type       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Magic Cookie                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Control Message Type      |           Reserved0           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Call ID            |      Call Serial Number       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Minimum BPS                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Maximum BPS                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Bearer Type                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Framing Type                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Packet Recv. Window Size    |    Packet Processing Delay    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Phone Number Length      |           Reserved1           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                   Phone Number (64 octets)                    +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                    Subaddress (64 octets)                     +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Length             |       PPTP Message Type       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Magic Cookie                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Control Message Type      |           Reserved0           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Call ID            |      Call Serial Number       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Minimum BPS                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Maximum BPS                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Bearer Type                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Framing Type                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Packet Recv. Window Size    |    Packet Processing Delay    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Phone Number Length      |           Reserved1           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                   Phone Number (64 octets)                    +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                    Subaddress (64 octets)                     +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Length Total length in octets of this PPTP message, including the entire PPTP header.

长度此PPTP消息的总长度（以八位字节为单位），包括整个PPTP标头。

PPTP Message Type 1 for Control Message.

控制消息的PPTP消息类型1。

Magic Cookie 0x1A2B3C4D.

神奇饼干0x1A2B3C4D。

Control Message Type 7 for Outgoing-Call-Request.

传出呼叫请求的控制消息类型7。

Reserved0 This field MUST be 0.

Reserved0此字段必须为0。

Call ID A unique identifier, unique to a particular PAC-PNS pair assigned by the PNS to this session. It is used to multiplex and demultiplex data sent over the tunnel between the PNS and PAC involved in this session.

Call ID是唯一的标识符，对于由PNS分配给该会话的特定PAC-PNS对是唯一的。它用于在本会话中涉及的PNS和PAC之间对通过隧道发送的数据进行多路复用和解多路复用。

Call Serial Number An identifier assigned by the PNS to this session for the purpose of identifying this particular session in logged session information. Unlike the Call ID, both the PNS and PAC associate the same Call Serial Number with a given session. The combination of IP address and call serial number SHOULD be unique.

Call Serial Number由PNS分配给该会话的标识符，用于在记录的会话信息中标识该特定会话。与呼叫ID不同，PNS和PAC都将同一呼叫序列号与给定会话相关联。IP地址和呼叫序列号的组合应该是唯一的。

Minimum BPS The lowest acceptable line speed (in bits/second) for this session.

最小BPS此会话可接受的最低线路速度（以位/秒为单位）。

Maximum BPS The highest acceptable line speed (in bits/second) for this session.

最大BPS此会话可接受的最高线路速度（以位/秒为单位）。

Bearer Type A value indicating the bearer capability required for this outgoing call. The currently defined values are:

承载类型指示此传出呼叫所需承载能力的值。当前定义的值为：

1 - Call to be placed on an analog channel

1-将呼叫置于模拟信道上

2 - Call to be placed on a digital channel

2-通过数字频道拨打电话

3 - Call can be placed on any type of channel

3-呼叫可以在任何类型的频道上进行

Framing Type A value indicating the type of PPP framing to be used for this outgoing call.

Framing Type一个值，指示用于此传出呼叫的PPP帧的类型。

1 - Call to use Asynchronous framing

1-调用以使用异步帧

2 - Call to use Synchronous framing

2-调用以使用同步帧

3 - Call can use either type of framing

3-调用可以使用任何一种类型的框架

Packet Recv. Window Size The number of received data packets the PNS will buffer for this session.

数据包接收。Window Size PNS将为此会话缓冲的接收数据包数。

Packet Processing Delay A measure of the packet processing delay that might be imposed on data sent to the PNS from the PAC. This value is specified in units of 1/10 seconds. For the PNS this number should be very small. See section 4.4 for a description of how this value is determined and used.

数据包处理延迟—可能对从PAC发送到PNS的数据施加的数据包处理延迟的度量。该值以1/10秒为单位指定。对于PNS，这个数字应该非常小。有关如何确定和使用该值的说明，请参见第4.4节。

Phone Number Length The actual number of valid digits in the Phone Number field.

Phone Number Length电话号码字段中有效数字的实际数目。

Reserved1 This field MUST be 0.

Reserved1此字段必须为0。

Phone Number The number to be dialed to establish the outgoing session. For ISDN and analog calls this field is an ASCII string. If the Phone Number is less than 64 octets in length, the remainder of this field is filled with octets of value 0.

电话号码为建立传出会话而拨打的号码。对于ISDN和模拟呼叫，此字段是ASCII字符串。如果电话号码长度小于64个八位字节，则此字段的剩余部分将填充值为0的八位字节。

Subaddress A 64 octet field used to specify additional dialing information. If the subaddress is less than 64 octets long, the remainder of this field is filled with octets of value 0.

子地址用于指定其他拨号信息的64个八位字节字段。如果子地址长度小于64个八位字节，则此字段的其余部分将填充值为0的八位字节。

2.8. Outgoing-Call-Reply

2.8. 呼出应答

The Outgoing-Call-Reply is a PPTP control message sent by the PAC to the PNS in response to a received Outgoing-Call-Request message. The reply indicates the result of the outgoing call attempt. It also provides information to the PNS about particular parameters used for the call. It provides information to allow the PNS to regulate the transmission of data to the PAC for this session.

传出呼叫应答是由PAC向PNS发送的PPTP控制消息，以响应接收到的传出呼叫请求消息。应答指示呼出呼叫尝试的结果。它还向PNS提供有关用于呼叫的特定参数的信息。它提供的信息允许PNS为该会话调节向PAC的数据传输。

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Length             |      PPTP Message Type        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Magic Cookie                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Control Message Type      |           Reserved0           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Call ID            |       Peer's Call ID          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Result Code  |  Error Code   |          Cause Code           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Connect Speed                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Packet Recv. Window Size    |    Packet Processing Delay    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Physical Channel ID                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Length             |      PPTP Message Type        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Magic Cookie                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Control Message Type      |           Reserved0           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Call ID            |       Peer's Call ID          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Result Code  |  Error Code   |          Cause Code           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Connect Speed                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Packet Recv. Window Size    |    Packet Processing Delay    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Physical Channel ID                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Length Total length in octets of this PPTP message, including the entire PPTP header.

长度此PPTP消息的总长度（以八位字节为单位），包括整个PPTP标头。

PPTP Message Type 1 for Control Message.

控制消息的PPTP消息类型1。

Magic Cookie 0x1A2B3C4D.

神奇饼干0x1A2B3C4D。

Control Message Type 8 for Outgoing-Call-Reply.

传出呼叫应答的控制消息类型8。

Reserved0 This field MUST be 0.

Reserved0此字段必须为0。

Call ID A unique identifier for the tunnel, assigned by the PAC to this session. It is used to multiplex and demultiplex data sent over the tunnel between the PNS and PAC involved in this session.

Call ID隧道的唯一标识符，由PAC分配给该会话。它用于在本会话中涉及的PNS和PAC之间对通过隧道发送的数据进行多路复用和解多路复用。

Peer's Call ID This field is set to the value received in the Call ID field of the corresponding Outgoing-Call-Request message. It is used by the PNS to match the Outgoing-Call-Reply with the Outgoing-Call-Request it issued. It also is used as the value sent in the GRE header for mux/demuxing.

对等方的呼叫ID此字段设置为相应传出呼叫请求消息的呼叫ID字段中接收到的值。PNS使用它将呼出呼叫应答与其发出的呼出呼叫请求相匹配。它还用作GRE头中发送的值，用于mux/解复用。

Result Code This value indicates the result of the Outgoing-Call-Request attempt. Currently valid values are:

结果代码此值表示传出呼叫请求尝试的结果。当前有效值为：

1 (Connected) - Call established with no errors

1（已连接）-已建立呼叫，无错误

2 (General Error) - Outgoing Call not established for the reason indicated in Error Code

2（一般错误）-由于错误代码中指示的原因，未建立传出呼叫

3 (No Carrier) - Outgoing Call failed due to no carrier detected

3（无运营商）-由于未检测到运营商，传出呼叫失败

4 (Busy) - Outgoing Call failed due to detection of a busy signal

4（忙）-由于检测到忙信号，传出呼叫失败

5 (No Dial Tone) - Outgoing Call failed due to lack of a dial tone

5（无拨号音）-由于缺少拨号音，传出呼叫失败

6 (Time-out) - Outgoing Call was not established within time allotted by PAC

6（超时）-未在PAC分配的时间内建立传出呼叫

7 (Do Not Accept) - Outgoing Call administratively prohibited

7（不接受）-行政禁止拨出电话

Cause Code This field gives additional failure information. Its value can vary depending upon the type of call attempted. For ISDN call attempts it is the Q.931 cause code.

原因代码此字段提供其他故障信息。其值可能因尝试调用的类型而异。对于ISDN呼叫尝试，它是Q.931原因码。

Connect Speed The actual connection speed used, in bits/second.

连接速度使用的实际连接速度，单位为位/秒。

Packet Recv. Window Size The number of received data packets the PAC will buffer for this session.

数据包接收。窗口大小PAC将为此会话缓冲的接收数据包数。

Packet Processing Delay A measure of the packet processing delay that might be imposed on data sent to the PAC from the PNS. This value is specified in units of 1/10 seconds. For the PAC, this number is related to the size of the buffer used to hold packets to be sent to the client and to the speed of the link to the client. This value should be set to the maximum delay that can normally occur between the time a packet arrives at the PAC and is delivered to the client. See section 4.4 for an example of how this value is determined and used.

数据包处理延迟—可能对从PNS发送到PAC的数据施加的数据包处理延迟的度量。该值以1/10秒为单位指定。对于PAC，该数字与用于保存要发送到客户端的数据包的缓冲区大小以及到客户端的链接速度有关。该值应设置为数据包到达PAC并交付给客户机之间通常发生的最大延迟。有关如何确定和使用该值的示例，请参见第4.4节。

Physical Channel ID This field is set by the PAC in a vendor-specific manner to the physical channel number used to place this call. It is used for logging purposes only.

物理通道ID此字段由PAC以特定于供应商的方式设置为用于拨打此电话的物理通道号。它仅用于日志记录目的。

2.9. Incoming-Call-Request

2.9. 来电请求

The Incoming-Call-Request is a PPTP control message sent by the PAC to the PNS to indicate that an inbound call is to be established from the PAC. This request provides the PNS with parameter information for the incoming call.

传入呼叫请求是由PAC发送给PNS的PPTP控制消息，用于指示将从PAC建立入站呼叫。此请求为PNS提供传入呼叫的参数信息。

This message is the first in the "three-way handshake" used by PPTP for establishing incoming calls. The PAC may defer answering the call until it has received an Incoming-Call-Reply from the PNS indicating that the call should be established. This mechanism allows the PNS to obtain sufficient information about the call before it is answered to determine whether the call should be answered or not.

此消息是PPTP用于建立传入呼叫的“三方握手”中的第一条消息。PAC可以延迟应答呼叫，直到它收到来自PNS的来电应答，指示应建立呼叫。此机制允许PNS在应答呼叫之前获取有关呼叫的足够信息，以确定是否应应答呼叫。

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Length             |       PPTP Message Type       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Magic Cookie                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Control Message Type      |           Reserved0           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Call ID            |      Call Serial Number       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Call Bearer Type                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Physical Channel ID                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Dialed Number Length      |     Dialing Number Length     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                   Dialed Number (64 octets)                   +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                  Dialing Number (64 octets)                   +
      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                    Subaddress (64 octets)                     +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Length             |       PPTP Message Type       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Magic Cookie                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Control Message Type      |           Reserved0           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Call ID            |      Call Serial Number       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Call Bearer Type                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Physical Channel ID                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Dialed Number Length      |     Dialing Number Length     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                   Dialed Number (64 octets)                   +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                  Dialing Number (64 octets)                   +
      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                    Subaddress (64 octets)                     +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Length Total length in octets of this PPTP message, including the entire PPTP header.

长度此PPTP消息的总长度（以八位字节为单位），包括整个PPTP标头。

PPTP Message Type 1 for Control Message.

控制消息的PPTP消息类型1。

Magic Cookie 0x1A2B3C4D.

神奇饼干0x1A2B3C4D。

Control Message Type 9 for Incoming-Call-Request.

传入呼叫请求的控制消息类型9。

Reserved0 This field MUST be 0.

Reserved0此字段必须为0。

Call ID A unique identifier for this tunnel, assigned by the PAC to this session. It is used to multiplex and demultiplex data sent over the tunnel between the PNS and PAC involved in this session.

Call ID此隧道的唯一标识符，由PAC分配给此会话。它用于在本会话中涉及的PNS和PAC之间对通过隧道发送的数据进行多路复用和解多路复用。

Call Serial Number An identifier assigned by the PAC to this session for the purpose of identifying this particular session in logged session information. Unlike the Call ID, both the PNS and PAC associate the same Call Serial Number to a given session. The combination of IP address and call serial number should be unique.

呼叫序列号PAC分配给该会话的标识符，用于在记录的会话信息中标识该特定会话。与呼叫ID不同，PNS和PAC都将相同的呼叫序列号关联到给定会话。IP地址和呼叫序列号的组合应该是唯一的。

Bearer Type A value indicating the bearer capability used for this incoming call. Currently defined values are:

承载类型指示此传入呼叫所使用的承载能力的值。当前定义的值为：

1 - Call is on an analog channel

1-呼叫在模拟信道上

2 - Call is on a digital channel

2-呼叫是在数字频道上进行的

Physical Channel ID This field is set by the PAC in a vendor-specific manner to the number of the physical channel this call arrived on.

物理通道ID此字段由PAC以特定于供应商的方式设置为该呼叫到达的物理通道的编号。

Dialed Number Length The actual number of valid digits in the Dialed Number field.

已拨号码长度“已拨号码”字段中的实际有效位数。

Dialing Number Length The actual number of valid digits in the Dialing Number field.

拨号号码长度“拨号号码”字段中的实际有效位数。

Dialed Number The number that was dialed by the caller. For ISDN and analog calls this field is an ASCII string. If the Dialed Number is less than 64 octets in length, the remainder of this field is filled with octets of value 0.

已拨号码来电者拨打的号码。对于ISDN和模拟呼叫，此字段是ASCII字符串。如果所拨号码的长度小于64个八位字节，则此字段的其余部分将填充值为0的八位字节。

Dialing Number The number from which the call was placed. For ISDN and analog calls this field is an ASCII string. If the Dialing Number is less than 64 octets in length, the remainder of this field is filled with octets of value 0.

拨号号码拨打电话的号码。对于ISDN和模拟呼叫，此字段是ASCII字符串。如果拨号号码长度小于64个八位字节，则此字段的剩余部分将填充值为0的八位字节。

Subaddress A 64 octet field used to specify additional dialing information. If the subaddress is less than 64 octets long, the remainder of this field is filled with octets of value 0.

子地址用于指定其他拨号信息的64个八位字节字段。如果子地址长度小于64个八位字节，则此字段的其余部分将填充值为0的八位字节。

2.10. Incoming-Call-Reply

2.10. 来电应答

The Incoming-Call-Reply is a PPTP control message sent by the PNS to the PAC in response to a received Incoming-Call-Request message. The reply indicates the result of the incoming call attempt. It also provides information to allow the PAC to regulate the transmission of data to the PNS for this session.

传入呼叫应答是由PNS向PAC发送的PPTP控制消息，以响应接收到的传入呼叫请求消息。应答指示传入呼叫尝试的结果。它还提供信息，使PAC能够为本次会话调节向PNS的数据传输。

This message is the second in the three-way handshake used by PPTP for establishing incoming calls. It indicates to the PAC whether the call should be answered or not.

此消息是PPTP用于建立传入呼叫的三方握手中的第二条消息。它向PAC指示是否应接听呼叫。

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Length             |       PPTP Message Type       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Magic Cookie                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Control Message Type      |           Reserved0           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Call ID            |       Peer's Call ID          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Result Code  |  Error Code   |   Packet Recv. Window Size    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Packet Transmit Delay     |           Reserved1           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Length             |       PPTP Message Type       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Magic Cookie                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Control Message Type      |           Reserved0           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Call ID            |       Peer's Call ID          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Result Code  |  Error Code   |   Packet Recv. Window Size    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Packet Transmit Delay     |           Reserved1           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Length Total length in octets of this PPTP message, including the entire PPTP header.

长度此PPTP消息的总长度（以八位字节为单位），包括整个PPTP标头。

PPTP Message Type 1 for Control Message.

控制消息的PPTP消息类型1。

Magic Cookie 0x1A2B3C4D.

神奇饼干0x1A2B3C4D。

Control Message Type 10 for Incoming-Call-Reply.

传入呼叫应答的控制消息类型10。

Reserved0 This field MUST be 0.

Reserved0此字段必须为0。

Call ID A unique identifier for this tunnel assigned by the PNS to this session. It is used to multiplex and demultiplex data sent over the tunnel between the PNS and PAC involved in this session.

Call ID由PNS分配给此会话的此隧道的唯一标识符。它用于在本会话中涉及的PNS和PAC之间对通过隧道发送的数据进行多路复用和解多路复用。

Peer's Call ID This field is set to the value received in the Call ID field of the corresponding Incoming-Call-Request message. It is used by

对等方的呼叫ID此字段设置为相应传入呼叫请求消息的呼叫ID字段中接收到的值。它是由

the PAC to match the Incoming-Call-Reply with the Incoming-Call-Request it issued. This value is included in the GRE header of transmitted data packets for this session.

PAC将传入呼叫应答与其发出的传入呼叫请求相匹配。该值包含在此会话的已传输数据包的GRE报头中。

Result Code This value indicates the result of the Incoming-Call-Request attempt. Current valid Result Code values are:

结果代码此值表示传入呼叫请求尝试的结果。当前有效的结果代码值为：

1 (Connect) - The PAC should answer the incoming call

1（连接）-PAC应接听来电

2 (General Error) - The Incoming Call should not be established due to the reason indicated in Error Code

2（一般错误）-由于错误代码中指示的原因，不应建立传入呼叫

3 (Do Not Accept) - The PAC should not accept the incoming call. It should hang up or issue a busy indication

3（不接受）-PAC不应接受传入呼叫。它应该挂断或发出忙碌指示

Packet Recv. Window Size The number of received data packets the PAC will buffer for this session.

数据包接收。窗口大小PAC将为此会话缓冲的接收数据包数。

Packet Transmit Delay A measure of the packet processing delay that might be imposed on data sent to the PAC from the PNS. This value is specified in units of 1/10 seconds.

数据包传输延迟—可能对从PNS发送到PAC的数据施加的数据包处理延迟的度量。该值以1/10秒为单位指定。

Reserved1 This field MUST be 0.

Reserved1此字段必须为0。

2.11. Incoming-Call-Connected

2.11. 来电已接通

The Incoming-Call-Connected message is a PPTP control message sent by the PAC to the PNS in response to a received Incoming-Call-Reply. It provides information to the PNS about particular parameters used for the call. It also provides information to allow the PNS to regulate the transmission of data to the PAC for this session.

传入呼叫连接消息是由PAC向PNS发送的PPTP控制消息，以响应接收到的传入呼叫应答。它向PNS提供有关用于呼叫的特定参数的信息。它还提供信息，允许PNS为本次会话调节向PAC的数据传输。

This message is the third in the three-way handshake used by PPTP for establishing incoming calls. It provides a mechanism for providing the PNS with additional information about the call that cannot, in

此消息是PPTP用于建立传入呼叫的三方握手中的第三条消息。它提供了一种机制，用于向PNS提供有关呼叫的附加信息，但在

general, be obtained at the time the Incoming-Call-Request is issued by the PAC.

一般，在PAC发出呼入请求时获取。

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Length             |      PPTP Message Type        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Magic Cookie                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Control Message Type      |           Reserved0           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Peer's Call ID          |           Reserved1           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Connect Speed                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Packet Recv. Window Size    |     Packet Transmit Delay     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Framing Type                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Length             |      PPTP Message Type        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Magic Cookie                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Control Message Type      |           Reserved0           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Peer's Call ID          |           Reserved1           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Connect Speed                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Packet Recv. Window Size    |     Packet Transmit Delay     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Framing Type                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Length Total length in octets of this PPTP message, including the entire PPTP header.

长度此PPTP消息的总长度（以八位字节为单位），包括整个PPTP标头。

PPTP Message Type 1 for Control Message.

控制消息的PPTP消息类型1。

Magic Cookie 0x1A2B3C4D.

神奇饼干0x1A2B3C4D。

Control Message Type 11 for Incoming-Call-Connected.

已连接的传入呼叫的控制消息类型11。

Reserved0 This field MUST be 0.

Reserved0此字段必须为0。

Peer's Call ID This field is set to the value received in the Call ID field of the corresponding Incoming-Call-Reply message. It is used by the PNS to match the Incoming-Call-Connected with the Incoming-Call-Reply it issued.

对等方的呼叫ID此字段设置为相应传入呼叫应答消息的呼叫ID字段中接收到的值。PNS使用它来匹配与其发出的传入呼叫应答连接的传入呼叫。

Connect Speed The actual connection speed used, in bits/second.

连接速度使用的实际连接速度，单位为位/秒。

Packet Recv. Window Size The number of received data packets the PAC will buffer for this session.

数据包接收。窗口大小PAC将为此会话缓冲的接收数据包数。

Packet Transmit Delay A measure of the packet processing delay that might be imposed on data sent to the PAC from the PNS. This value is specified in units of 1/10 seconds.

数据包传输延迟—可能对从PNS发送到PAC的数据施加的数据包处理延迟的度量。该值以1/10秒为单位指定。

Framing Type A value indicating the type of PPP framing being used by this incoming call.

Framing Type一个值，指示此传入呼叫使用的PPP帧的类型。

1 - Call uses asynchronous framing

1-调用使用异步帧

2 - Call uses synchronous framing

2-调用使用同步帧

2.12. Call-Clear-Request

2.12. 呼叫清除请求

The Call-Clear-Request is a PPTP control message sent by the PNS to the PAC indicating that a particular call is to be disconnected. The call being cleared can be either an incoming or outgoing call, in any state. The PAC responds to this message with a Call-Disconnect-Notify message.

呼叫清除请求是由PNS发送给PAC的PPTP控制消息，指示要断开特定呼叫。正在清除的呼叫可以是任何状态的传入或传出呼叫。PAC通过呼叫断开通知消息响应此消息。

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Length             |      PPTP Message Type        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Magic Cookie                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Control Message Type      |           Reserved0           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Call ID            |           Reserved1           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Length             |      PPTP Message Type        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Magic Cookie                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Control Message Type      |           Reserved0           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Call ID            |           Reserved1           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Length Total length in octets of this PPTP message, including the entire PPTP header.

长度此PPTP消息的总长度（以八位字节为单位），包括整个PPTP标头。

PPTP Message Type 1 for Control Message.

控制消息的PPTP消息类型1。

Magic Cookie 0x1A2B3C4D.

神奇饼干0x1A2B3C4D。

Control Message Type 12 for Call-Clear-Request.

呼叫清除请求的控制消息类型12。

Reserved0 This field MUST be 0.

Reserved0此字段必须为0。

Call ID The Call ID assigned by the PNS to this call. This value is used instead of the Peer's Call ID because the latter may not be known to the PNS if the call must be aborted during call establishment.

Call ID由PNS分配给此呼叫的呼叫ID。使用此值代替对等方的呼叫ID，因为如果在呼叫建立期间必须中止呼叫，则PNS可能不知道后者。

Reserved1 This field MUST be 0.

Reserved1此字段必须为0。

2.13. Call-Disconnect-Notify

2.13. 呼叫断开通知

The Call-Disconnect-Notify message is a PPTP control message sent by the PAC to the PNS. It is issued whenever a call is disconnected, due to the receipt by the PAC of a Call-Clear-Request or for any other reason. Its purpose is to inform the PNS of both the disconnection and the reason for it.

呼叫断开通知消息是由PAC发送到PNS的PPTP控制消息。当由于PAC收到呼叫清除请求或任何其他原因导致呼叫断开时，会发出该命令。其目的是通知PNS断开连接及其原因。

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Length             |      PPTP Message Type        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Magic Cookie                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Control Message Type      |           Reserved0           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Call ID            |  Result Code  |  Error Code   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Cause Code           |           Reserved1           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +              Call Statistics (128 octets)                     +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Length             |      PPTP Message Type        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Magic Cookie                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Control Message Type      |           Reserved0           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Call ID            |  Result Code  |  Error Code   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Cause Code           |           Reserved1           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +              Call Statistics (128 octets)                     +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Length Total length in octets of this PPTP message, including the entire PPTP header.

长度此PPTP消息的总长度（以八位字节为单位），包括整个PPTP标头。

PPTP Message Type 1 for Control Message.

控制消息的PPTP消息类型1。

Magic Cookie 0x1A2B3C4D.

神奇饼干0x1A2B3C4D。

Control Message Type 13 for Call-Disconnect-Notify.

呼叫断开通知的控制消息类型13。

Reserved0 This field MUST be 0.

Reserved0此字段必须为0。

Call ID The value of the Call ID assigned by the PAC to this call. This value is used instead of the Peer's Call ID because the latter may not be known to the PNS if the call must be aborted during call establishment.

Call ID PAC分配给此呼叫的呼叫ID值。使用此值代替对等方的呼叫ID，因为如果在呼叫建立期间必须中止呼叫，则PNS可能不知道后者。

Result Code This value indicates the reason for the disconnect. Current valid Result Code values are:

结果代码该值指示断开的原因。当前有效的结果代码值为：

1 (Lost Carrier) - Call disconnected due to loss of carrier

1（载波丢失）-由于载波丢失，呼叫已断开

2 (General Error) - Call disconnected for the reason indicated in Error Code

2（一般错误）-由于错误代码中指示的原因，呼叫已断开

3 (Admin Shutdown) - Call disconnected for administrative reasons

3（管理员关机）-由于管理原因，呼叫已断开

4 (Request) - Call disconnected due to received Call-Clear-Request

4（请求）-由于收到呼叫清除请求，呼叫已断开

Error Code This field is set to 0 unless a "General Error" condition exists, in which case the Result Code is set to 2 and this field is set to the value corresponding to the general error condition as specified in section 2.2.

Cause Code This field gives additional disconnect information. Its value varies depending on the type of call being disconnected. For ISDN calls it is the Q.931 cause code.

原因代码此字段提供其他断开连接信息。其值根据断开的呼叫类型而变化。对于ISDN呼叫，它是Q.931原因码。

Call Statistics This field is an ASCII string containing vendor-specific call statistics that can be logged for diagnostic purposes. If the length of the string is less than 128, the remainder of the field is filled with octets of value 0.

呼叫统计信息此字段是ASCII字符串，包含特定于供应商的呼叫统计信息，可记录这些信息以进行诊断。如果字符串长度小于128，则字段的其余部分将填充值为0的八位字节。

2.14. WAN-Error-Notify

2.14. 广域网错误通知

The WAN-Error-Notify message is a PPTP control message sent by the PAC to the PNS to indicate WAN error conditions (conditions that occur on the interface supporting PPP). The counters in this message are cumulative. This message should only be sent when an error occurs, and not more than once every 60 seconds. The counters are reset when a new call is established.

WAN错误通知消息是由PAC发送给PNS的PPTP控制消息，用于指示WAN错误情况（在支持PPP的接口上发生的情况）。此消息中的计数器是累积的。仅当发生错误时才应发送此消息，且每60秒发送一次。当建立新呼叫时，计数器被重置。

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Length             |      PPTP Message Type        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Magic Cookie                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Control Message type      |           Reserved0           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Peer's Call ID         |           Reserved1           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          CRC Errors                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Framing Errors                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Hardware Overruns                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Buffer Overruns                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Time-out Errors                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Alignment Errors                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Length             |      PPTP Message Type        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Magic Cookie                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Control Message type      |           Reserved0           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Peer's Call ID         |           Reserved1           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          CRC Errors                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Framing Errors                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Hardware Overruns                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Buffer Overruns                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Time-out Errors                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Alignment Errors                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Length Total length in octets of this PPTP message, including the entire PPTP header.

长度此PPTP消息的总长度（以八位字节为单位），包括整个PPTP标头。

PPTP Message Type 1 for Control Message.

控制消息的PPTP消息类型1。

Magic Cookie 0x1A2B3C4D.

神奇饼干0x1A2B3C4D。

Control Message Type 14 for WAN-Error-Notify.

WAN错误通知的控制消息类型14。

Reserved0 This field MUST be 0.

Reserved0此字段必须为0。

Peer's Call ID Th Call ID assigned by the PNS to this call.

对等方的呼叫ID由PNS分配给该呼叫的呼叫ID。

CRC Errors Number of PPP frames received with CRC errors since session was established.

CRC错误自会话建立以来接收到的带有CRC错误的PPP帧数。

Framing Errors Number of improperly framed PPP packets received.

帧错误接收到的帧不正确的PPP数据包数。

Hardware Overruns Number of receive buffer over-runs since session was established.

自会话建立以来，硬件超出了接收缓冲区的运行次数。

Buffer Overruns Number of buffer over-runs detected since session was established.

Buffer Overruns Number of buffer over-runs detected since session was established.translate error, please retry

Time-out Errors Number of time-outs since call was established.

超时错误自呼叫建立以来的超时次数。

Alignment Errors Number of alignment errors since call was established.

对齐错误自建立调用以来的对齐错误数。

2.15. Set-Link-Info

2.15. 设置链接信息

The Set-Link-Info message is a PPTP control message sent by the PNS to the PAC to set PPP-negotiated options. Because these options can change at any time during the life of the call, the PAC must be able to update its internal call information dynamically and perform PPP negotiation on an active PPP session.

Set Link Info消息是由PNS发送给PAC的PPTP控制消息，用于设置PPP协商选项。由于这些选项在通话期间随时可能发生变化，PAC必须能够动态更新其内部通话信息，并在活动PPP会话上执行PPP协商。

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Length             |      PPTP Message Type        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Magic Cookie                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Control Message type      |           Reserved0           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Peer's Call ID         |           Reserved1           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Send ACCM                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Receive ACCM                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Length             |      PPTP Message Type        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Magic Cookie                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Control Message type      |           Reserved0           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Peer's Call ID         |           Reserved1           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Send ACCM                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Receive ACCM                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Length Total length in octets of this PPTP message, including the entire PPTP header.

长度此PPTP消息的总长度（以八位字节为单位），包括整个PPTP标头。

PPTP Message Type 1 for Control Message.

控制消息的PPTP消息类型1。

Magic Cookie 0x1A2B3C4D.

神奇饼干0x1A2B3C4D。

Control Message Type 15 for Set-Link-Info.

设置链接信息的控制消息类型15。

Reserved0 This field MUST be 0.

Reserved0此字段必须为0。

Peer's Call ID The value of the Call ID assigned by the PAC to this call.

对等呼叫ID PAC分配给该呼叫的呼叫ID值。

Reserved1 This field MUST be 0.

Reserved1此字段必须为0。

Send ACCM The send ACCM value the client should use to process outgoing PPP packets. The default value used by the client until this message is received is 0XFFFFFFFF. See [7].

Send ACCM客户端应用于处理传出PPP数据包的Send ACCM值。在收到此消息之前，客户端使用的默认值为0xFFFFFF。见[7]。

Receive ACCM The receive ACCM value the client should use to process incoming PPP packets. The default value used by the client until this message is received is 0XFFFFFFFF. See [7].

Receive ACCM客户端处理传入PPP数据包时应使用的Receive ACCM值。在收到此消息之前，客户端使用的默认值为0xFFFFFF。见[7]。

2.16. General Error Codes

2.16. 一般错误代码

General error codes pertain to types of errors which are not specific to any particular PPTP request, but rather to protocol or message format errors. If a PPTP reply indicates in its Result Code that a general error occurred, the General Error value should be examined to determined what the error was. The currently defined General Error codes and their meanings are:

一般错误代码与不特定于任何特定PPTP请求的错误类型有关，而与协议或消息格式错误有关。如果PPTP应答在其结果代码中指出发生了一般错误，则应检查一般错误值以确定错误是什么。当前定义的一般错误代码及其含义如下：

0 (None) - No general error

0（无）-无常规错误

1 (Not-Connected) - No control connection exists yet for this PAC-PNS pair

1（未连接）-此PAC-PNS对尚不存在控制连接

2 (Bad-Format) - Length is wrong or Magic Cookie value is incorrect

2（格式错误）-长度错误或Magic Cookie值不正确

3 (Bad-Value) - One of the field values was out of range or reserved field was non-zero

3（错误值）-其中一个字段值超出范围或保留字段非零

4 (No-Resource) - Insufficient resources to handle this command now

4（无资源）-资源不足，无法立即处理此命令

5 (Bad-Call ID) - The Call ID is invalid in this context

5（错误呼叫ID）-呼叫ID在此上下文中无效

6 (PAC-Error) - A generic vendor-specific error occurred in the PAC

6（PAC错误）-PAC中发生一般供应商特定错误

3. Control Connection Protocol Operation

3. 控制连接协议操作

This section describes the operation of various PPTP control connection functions and the Control Connection messages which are used to support them. The protocol operation of the control connection is simplified because TCP is used to provide a reliable transport mechanism. Ordering and retransmission of messages is not a concern at this level. The TCP connection itself, however, can close at any time and an appropriate error recovery mechanism must be provided to handle this case.

本节介绍各种PPTP控制连接功能的操作以及用于支持这些功能的控制连接消息。由于TCP用于提供可靠的传输机制，因此简化了控制连接的协议操作。在这个级别上，消息的排序和重新传输不是一个问题。但是，TCP连接本身可以随时关闭，必须提供适当的错误恢复机制来处理这种情况。

Some error recovery procedures are common to all states of the control connection. If an expected reply does not arrive within 60 seconds, the control connection is closed, unless otherwise specified. Appropriate logging should be implemented for easy determination of the problems and the reasons for closing the control connection.

某些错误恢复过程对于控制连接的所有状态都是通用的。除非另有规定，否则如果预期的回复未在60秒内到达，则控制连接将关闭。应执行适当的日志记录，以便于确定问题和关闭控制连接的原因。

Receipt of an invalid or malformed Control Connection message should be logged appropriately, and the control connection should be closed and restarted to ensure recovery into a known state.

收到无效或格式错误的控制连接消息时，应适当记录，并关闭并重新启动控制连接，以确保恢复到已知状态。

3.1. Control Connection States

3.1. 控制连接状态

The control connection relies on a standard TCP connection for its service. The PPTP control connection protocol is not distinguishable between the PNS and PAC, but is distinguishable between the originator and receiver. The originating peer is the one which first attempts the TCP open. Since either PAC or PNS may originate a connection, it is possible for a TCP collision to occur. See section 3.1.3 for a description of this situation.

控制连接的服务依赖于标准TCP连接。PPTP控制连接协议在PNS和PAC之间无法区分，但在发端和接收方之间可以区分。发起的对等方是第一个尝试打开TCP的对等方。由于PAC或PNS都可能发起连接，因此可能发生TCP冲突。有关这种情况的说明，请参见第3.1.3节。

3.1.1. Control Connection Originator (may be PAC or PNS)

3.1.1. 控制连接发起人（可能是PAC或PNS）

                TCP Open Indication
                /Send Start Control
                  Connection Request       +-----------------+
     +------------------------------------>|  wait_ctl_reply |
     |                                     +-----------------+
     |     Collision/See (4.1.3) Close TCP   V  V  V   Receive Start Ctl
     |       +-------------------------------+  |  |   Connection Reply
     |       |                                  |  |   Version OK
     ^       V                                  |  V
+-----------------+          Receive Start Ctl  | +-----------------+
|      idle       |          Connection Reply   | |   established   |
+-----------------+          Version Not OK     | +-----------------+
     ^                                          |  V   Local Terminate
     |         Receive Stop Control             |  |   /Send Stop
     |         Connection Request               |  |    Control Request
     |         /Send Stop Control Reply         V  V
     |          Close TCP                  +-----------------+
     +-------------------------------------| wait_stop_reply |
                                           +-----------------+

                TCP Open Indication
                /Send Start Control
                  Connection Request       +-----------------+
     +------------------------------------>|  wait_ctl_reply |
     |                                     +-----------------+
     |     Collision/See (4.1.3) Close TCP   V  V  V   Receive Start Ctl
     |       +-------------------------------+  |  |   Connection Reply
     |       |                                  |  |   Version OK
     ^       V                                  |  V
+-----------------+          Receive Start Ctl  | +-----------------+
|      idle       |          Connection Reply   | |   established   |
+-----------------+          Version Not OK     | +-----------------+
     ^                                          |  V   Local Terminate
     |         Receive Stop Control             |  |   /Send Stop
     |         Connection Request               |  |    Control Request
     |         /Send Stop Control Reply         V  V
     |          Close TCP                  +-----------------+
     +-------------------------------------| wait_stop_reply |
                                           +-----------------+

idle The control connection originator attempts to open a TCP connection to the peer during idle state. When the TCP connection is open, the originator transmits a send Start-Control-Connection-Request and then enters the wait_ctl_reply state.

空闲控制连接发起人尝试在空闲状态下打开与对等方的TCP连接。当TCP连接打开时，发起者发送发送启动控制连接请求，然后进入等待ctl回复状态。

wait_ctl_reply The originator checks to see if another TCP connection has been requested from the same peer, and if so, handles the collision situation described in section 3.1.3.

wait_ctl_reply发起人检查是否已从同一对等方请求另一个TCP连接，如果已请求，则处理第3.1.3节中描述的冲突情况。

When a Start-Control-Connection-Reply is received, it is examined for a compatible version. If the version of the reply is lower than the version sent in the request, the older (lower) version should be used provided it is supported. If the version in the reply is earlier and supported, the originator moves to the established state. If the version is earlier and not supported, a Stop-Control-Connection-Request SHOULD be sent to the peer and the originator moves into the wait_stop_reply state.

当收到启动控制连接回复时，将检查是否存在兼容版本。如果回复的版本低于请求中发送的版本，则应使用较旧（较低）的版本，前提是该版本受支持。如果回复中的版本更早且受支持，则发起者将移动到已建立状态。如果版本更早且不受支持，则应向对等方发送停止控制连接请求，发起方将进入等待\u停止\u回复状态。

established An established connection may be terminated by either a local condition or the receipt of a Stop-Control-Connection-Request. In the event of a local termination, the originator MUST send a Stop-Control-Connection-Request and enter the wait_stop_reply state.

已建立的连接可以通过本地条件或接收停止控制连接请求来终止。在本地终止的情况下，发起者必须发送停止控制连接请求并进入等待停止回复状态。

If the originator receives a Stop-Control-Connection-Request it SHOULD send a Stop-Control-Connection-Reply and close the TCP connection making sure that the final TCP information has been "pushed" properly.

如果发端人收到停止控制连接请求，则应发送停止控制连接回复并关闭TCP连接，确保已正确“推送”最终TCP信息。

wait_stop_reply If a Stop-Control-Connection-Reply is received, the TCP connection SHOULD be closed and the control connection becomes idle.

等待\u停止\u回复如果收到停止控制连接回复，则应关闭TCP连接，控制连接变为空闲。

3.1.2. Control connection Receiver (may be PAC or PNS)

3.1.2. 控制连接接收器（可以是PAC或PNS）

Receive Start Control Connection Request
Version Not OK/Send Start Control Connection
Reply with Error
  +--------+
  |        |         Receive Control Connection Request Version OK
  |        |         /Send Start Control Connection Reply
  |        |   +----------------------------------------+
  ^        V   ^                                        V
+-----------------+             Receive Start Ctl    +-----------------+
|      Idle       |             Connection Request   |   Established   |
+-----------------+             /Send Stop Reply     +-----------------+
        ^      ^                 Close TCP           V  V Local Terminate
        |      +-------------------------------------+  | /Send Stop
        |                                               |  Control Conn.
        |                                               V  Request
        |                                     +-----------------+
        +-------------------------------------| Wait-Stop-Reply |
                 Receive Stop Control         +-----------------+
                 Connection Reply
                 /Close TCP

Receive Start Control Connection Request
Version Not OK/Send Start Control Connection
Reply with Error
  +--------+
  |        |         Receive Control Connection Request Version OK
  |        |         /Send Start Control Connection Reply
  |        |   +----------------------------------------+
  ^        V   ^                                        V
+-----------------+             Receive Start Ctl    +-----------------+
|      Idle       |             Connection Request   |   Established   |
+-----------------+             /Send Stop Reply     +-----------------+
        ^      ^                 Close TCP           V  V Local Terminate
        |      +-------------------------------------+  | /Send Stop
        |                                               |  Control Conn.
        |                                               V  Request
        |                                     +-----------------+
        +-------------------------------------| Wait-Stop-Reply |
                 Receive Stop Control         +-----------------+
                 Connection Reply
                 /Close TCP

idle The control connection receiver waits for a TCP open attempt on port 1723. When notified of an open TCP connection, it should prepare to receive PPTP messages. When a Start-Control-Connection-Request is received its version field should be examined. If the version is earlier than the receiver's version and the earlier version can be supported by the receiver, the receiver SHOULD send a Start-Control-Connection-Reply. If the version is earlier than the receiver's version and the version cannot be supported, the receiver SHOULD send a Start-Connection-Reply message, close the TCP connection and remain in the idle state. If the receiver's version is the same as earlier than the peer's, the receiver SHOULD send a Start-Control-Connection-Reply with the receiver's version and enter the established state.

空闲控制连接接收器等待端口1723上的TCP打开尝试。当通知TCP连接已打开时，它应准备接收PPTP消息。当收到启动控制连接请求时，应检查其版本字段。如果版本早于接收方的版本，且接收方可以支持早期版本，则接收方应发送启动控制连接回复。如果版本早于接收方的版本，并且该版本不受支持，则接收方应发送启动连接回复消息，关闭TCP连接并保持空闲状态。如果接收方的版本与对等方的版本相同，则接收方应发送具有接收方版本的启动控制连接回复，并进入已建立状态。

established An established connection may be terminated by either a local condition or the reception of a Stop-Control-Connection-Request. In the event of a local termination, the originator MUST send a Stop-Control-Connection-Request and enter the wait_stop_reply state.

已建立的连接可以通过本地条件或接收停止控制连接请求来终止。在本地终止的情况下，发起者必须发送停止控制连接请求并进入等待停止回复状态。

If the originator receives a Stop-Control-Connection-Request it SHOULD send a Stop-Control-Connection-Reply and close the TCP connection, making sure that the final TCP information has been "pushed" properly.

如果发端人收到停止控制连接请求，则应发送停止控制连接回复并关闭TCP连接，确保已正确“推送”最终TCP信息。

wait_stop_reply If a Stop-Control-Connection-Reply is received, the TCP connection SHOULD be closed and the control connection becomes idle.

等待\u停止\u回复如果收到停止控制连接回复，则应关闭TCP连接，控制连接变为空闲。

3.1.3. Start Control Connection Initiation Request Collision

3.1.3. 启动控制连接启动请求冲突

A PAC and PNS must have only one control connection between them. It is possible, however, for a PNS and a PAC to simultaneously attempt to establish a control connection to each other. When a Start-Control-Connection-Request is received on one TCP connection and another Start-Control-Connection-Request has already been sent on another TCP connection to the same peer, a collision has occurred.

PAC和PNS之间必须只有一个控制连接。然而，PNS和PAC可以同时尝试建立彼此的控制连接。当在一个TCP连接上收到启动控制连接请求，并且在另一个TCP连接上已向同一对等方发送另一个启动控制连接请求时，发生冲突。

The "winner" of the initiation race is the peer with the higher IP address (compared as 32 bit unsigned values, network number more significant). For example, if the peers 192.33.45.17 and 192.33.45.89 collide, the latter will be declared the winner. The loser will immediately close the TCP connection it initiated, without sending any further PPTP control messages on it and will respond to the winner's request with a Start-Control-Connection-Reply message. The winner will wait for the Start-Control-Connection-Reply on the connection it initiated and also wait for a TCP termination indication on the connection the loser opened. The winner MUST NOT send any messages on the connection the loser initiated.

发起竞争的“赢家”是IP地址较高的对等方（与32位无符号值相比，网络号更重要）。例如，如果对等点192.33.45.17和192.33.45.89发生碰撞，则后者将被宣布为赢家。失败者将立即关闭其启动的TCP连接，而不在其上发送任何进一步的PPTP控制消息，并用启动控制连接回复消息响应胜利者的请求。赢家将等待其启动的连接上的启动控制连接回复，并等待输家打开的连接上的TCP终止指示。赢家不得在输家发起的连接上发送任何消息。

3.1.4. Keep Alives and Timers

3.1.4. 保持生命和时间

A control connection SHOULD be closed by closing the underlying TCP connection under the following circumstances:

在以下情况下，应通过关闭基础TCP连接来关闭控制连接：

1. If a control connection is not in the established state (i.e., Start-Control-Connection-Request and Start-Control-Connection-Reply have not been exchanged), a control connection SHOULD be closed after 60 seconds by a peer waiting for a Start-Control-Connection-Request or Start-Control-Connection-Reply message.

1. 如果控制连接未处于已建立状态（即，启动控制连接请求和启动控制连接回复尚未交换），则对等方应在等待启动控制连接请求或启动控制连接回复消息的60秒后关闭控制连接。

2. If a peer's control connection is in the established state and has not received a control message for 60 seconds, it SHOULD send a Echo-Request message. If an Echo-Reply is not received 60 seconds after the Echo-Request message transmission, the control connection SHOULD be closed.

2. 如果对等方的控制连接处于已建立状态，并且在60秒内未收到控制消息，则应发送回显请求消息。如果在回送请求消息传输60秒后未收到回送回复，则应关闭控制连接。

3.2. Call States

3.2. 呼叫国

3.2.1. Timing considerations

3.2.1. 时机考虑

Because of the real-time nature of telephone signaling, both the PNS and PAC should be implemented with multi-threaded architectures such that messages related to multiple calls are not serialized and blocked. The transit delay between the PAC and PNS should not exceed one second. The call and connection state figures do not specify exceptions caused by timers. The implicit assumption is that since the TCP-based control connection is being verified with keep-alives, there is less need to maintain strict timers for call control messages.

由于电话信令的实时性，PNS和PAC都应采用多线程体系结构来实现，以便与多个呼叫相关的消息不会被序列化和阻止。PAC和PNS之间的传输延迟不应超过1秒。调用和连接状态图未指定计时器引起的异常。隐式假设是，由于基于TCP的控制连接正在使用keep alives进行验证，因此不需要为呼叫控制消息维护严格的计时器。

Establishing outbound international calls, including the modem training and negotiation sequences, may take in excess of 1 minute so the use of short timers is discouraged.

建立出站国际呼叫，包括调制解调器培训和协商序列，可能需要超过1分钟，因此不鼓励使用短定时器。

If a state transition does not occur within 1 minute (except for connections in the idle or established states), the integrity of the protocol processing between the peers is suspect and the ENTIRE CONTROL CONNECTION should be closed and restarted. All Call IDs are logically released whenever a control connection is started. This presumably also helps in preventing toll calls from being "lost" and never cleared.

如果在1分钟内未发生状态转换（处于空闲或已建立状态的连接除外），则对等方之间的协议处理的完整性将受到怀疑，并且应关闭并重新启动整个控制连接。每当控制连接启动时，逻辑上释放所有调用ID。这大概也有助于防止长途电话“丢失”和永远无法清除。

3.2.2. Call ID Values

3.2.2. 调用ID值

Each peer assigns a Call ID value to each user session it requests or accepts. This Call ID value MUST be unique for the tunnel between the PNS and PAC to which it belongs. Tunnels to other peers can use the same Call ID number so the receiver of a packet on a tunnel needs to associate a user session with a particular tunnel and Call ID. It is suggested that the number of potential Call ID values for each tunnel be at least twice as large as the maximum number of calls expected on a given tunnel.

每个对等方为其请求或接受的每个用户会话分配一个调用ID值。此调用ID值对于它所属的PNS和PAC之间的隧道必须是唯一的。到其他对等方的隧道可以使用相同的呼叫ID号，因此隧道上数据包的接收器需要将用户会话与特定隧道和呼叫ID关联。建议每个隧道的潜在呼叫ID值的数量至少是给定隧道上预期的最大呼叫数目的两倍。

A session is defined by the triple (PAC, PNS, Call ID).

会话由三元组（PAC、PNS、Call ID）定义。

3.2.3. Incoming Calls

3.2.3. 来电

An Incoming-Call-Request message is generated by the PAC when an associated telephone line rings. The PAC selects a Call ID and serial number and indicates the call bearer type. Modems should always indicate analog call type. ISDN calls should indicate digital when unrestricted digital service or rate adaption is used and analog if

当相关电话线响起时，PAC将生成传入呼叫请求消息。PAC选择呼叫ID和序列号，并指示呼叫承载类型。调制解调器应始终指示模拟呼叫类型。ISDN呼叫应在使用无限制数字服务或速率自适应时指示数字，如果使用模拟，则指示模拟

digital modems are involved. Dialing number, dialed number, and subaddress may be included in the message if they are available from the telephone network.

涉及数字调制解调器。如果电话网络提供拨号号码、已拨号码和子地址，则信息中可能包含这些号码。

Once the PAC sends the Incoming-Call-Request, it waits for a response from the PNS but does not answer the call from the telephone network. The PNS may choose not to accept the call if:

一旦PAC发送传入呼叫请求，它将等待来自PNS的响应，但不应答来自电话网络的呼叫。在下列情况下，PNS可选择不接受呼叫：

- No resources are available to handle more sessions

- 没有可用于处理更多会话的资源

- The dialed, dialing, or subaddress fields are not indicative of an authorized user

- 拨号、拨号或子地址字段并不表示授权用户

- The bearer service is not authorized or supported

- 不授权或不支持承载服务

If the PNS chooses to accept the call, it responds with an Incoming-Call-Reply which also indicates window sizes (see section 4.2). When the PAC receives the Outgoing-Call-Reply, it attempts to connect the call, assuming the calling party has not hung up. A final call connected message from the PAC to the PNS indicates that the call states for both the PAC and the PNS should enter the established state.

如果PNS选择接受呼叫，它将以来电应答进行响应，该应答还指示窗口大小（参见第4.2节）。当PAC收到传出呼叫应答时，它会尝试连接呼叫，假设呼叫方没有挂断。从PAC到PNS的最终呼叫连接消息表明PAC和PNS的呼叫状态都应进入已建立状态。

When the dialed-in client hangs up, the call is cleared normally and the PAC sends a Call-Disconnect-Notify message. If the PNS wishes to clear a call, it sends a Call-Clear-Request message and then waits for a Call-Disconnect-Notify.

当拨号客户端挂断时，呼叫将正常清除，PAC将发送呼叫断开通知消息。如果PNS希望清除呼叫，它将发送呼叫清除请求消息，然后等待呼叫断开通知。

3.2.3.1. PAC Incoming Call States

3.2.3.1. PAC来电状态

    Ring/Send Incoming Call Request          +-----------------+
  +----------------------------------------->|    wait_reply   |
  |                                          +-----------------+
  |           Receive Incoming Call Reply    V  V  V
  |           Not Accepting                  |  |  |   Receive Incoming
  |         +--------------------------------+  |  |   Call Reply Accept-
  |         |    +------------------------------+  |   ing/Answer call;
  |         |    |     Abort/Send Call             |   Send Call
  ^         V    V     Disconnect Notify           V   Connected
+-----------------+                              +-----------------+
|      idle       |<-----------------------------|   established   |
+-----------------+  Receive Clear Call Request  +-----------------+
                     or telco call dropped
                     or local disconnect
                     /Send Call Disconnect Notify

    Ring/Send Incoming Call Request          +-----------------+
  +----------------------------------------->|    wait_reply   |
  |                                          +-----------------+
  |           Receive Incoming Call Reply    V  V  V
  |           Not Accepting                  |  |  |   Receive Incoming
  |         +--------------------------------+  |  |   Call Reply Accept-
  |         |    +------------------------------+  |   ing/Answer call;
  |         |    |     Abort/Send Call             |   Send Call
  ^         V    V     Disconnect Notify           V   Connected
+-----------------+                              +-----------------+
|      idle       |<-----------------------------|   established   |
+-----------------+  Receive Clear Call Request  +-----------------+
                     or telco call dropped
                     or local disconnect
                     /Send Call Disconnect Notify

The states associated with the PAC for incoming calls are:

与PAC关联的来电状态为：

idle The PAC detects an incoming call on one of its telco interfaces. Typically this means an analog line is ringing or an ISDN TE has detected an incoming Q.931 SETUP message. The PAC sends an Incoming-Call-Request message and moves to the wait_reply state.

空闲PAC在其一个电信接口上检测到传入呼叫。通常这意味着模拟线路正在振铃，或者ISDN TE检测到传入的Q.931设置消息。PAC发送传入呼叫请求消息，并进入等待应答状态。

wait_reply The PAC receives an Incoming-Call-Reply message indicating non-willingness to accept the call (general error or don't accept) and moves back into the idle state. If the reply message indicates that the call is accepted, the PAC sends an Incoming-Call-Connected message and enters the established state.

wait_reply PAC收到来电回复消息，表示不愿意接受呼叫（一般错误或不接受），并返回空闲状态。如果应答消息表明呼叫已被接受，PAC将发送传入呼叫连接消息并进入已建立状态。

established Data is exchanged over the tunnel. The call may be cleared following:

已建立的数据通过隧道进行交换。可通过以下方式清除呼叫：

An event on the telco connection. The PAC sends a Call-Disconnect-Notify message

电信连接上的事件。PAC发送呼叫断开通知消息

Receipt of a Call-Clear-Request. The PAC sends a Call-Disconnect-Notify message

收到呼叫清除请求。PAC发送呼叫断开通知消息

A local reason. The PAC sends a Call-Disconnect-Notify message.

地方原因。PAC发送呼叫断开通知消息。

3.2.3.2. PNS Incoming Call States

3.2.3.2. 来电状态

  Receive Incoming Call Request
  /Send Incoming Call Reply                  +-----------------+
   Not Accepting if Error                    |   Wait-Connect  |
  +-----+                                    +-----------------+
  |     |     Receive Incoming Call Req.     ^  V  V
  |     |     /Send Incoming Call Reply OK   |  |  |   Receive Incoming
  |     |   +--------------------------------+  |  |   Call Connect
  ^     V   ^    V------------------------------+  V
+-----------------+  Receive Call Disconnect     +-----------------+
|      Idle       |  Notify                   +- |   Established   |
+-----------------+                           |  +-----------------+
        ^        ^                            |   V   Local Terminate
        |        +----------------------------+   |   /Send Call Clear
        |            Receive Call Disconnect      |    Request
        |            Notify                       V
        |                                      +-----------------+
        +--------------------------------------| Wait-Disconnect |
                     Receive Call Disconnect   +-----------------+
                     Notify

  Receive Incoming Call Request
  /Send Incoming Call Reply                  +-----------------+
   Not Accepting if Error                    |   Wait-Connect  |
  +-----+                                    +-----------------+
  |     |     Receive Incoming Call Req.     ^  V  V
  |     |     /Send Incoming Call Reply OK   |  |  |   Receive Incoming
  |     |   +--------------------------------+  |  |   Call Connect
  ^     V   ^    V------------------------------+  V
+-----------------+  Receive Call Disconnect     +-----------------+
|      Idle       |  Notify                   +- |   Established   |
+-----------------+                           |  +-----------------+
        ^        ^                            |   V   Local Terminate
        |        +----------------------------+   |   /Send Call Clear
        |            Receive Call Disconnect      |    Request
        |            Notify                       V
        |                                      +-----------------+
        +--------------------------------------| Wait-Disconnect |
                     Receive Call Disconnect   +-----------------+
                     Notify

The states associated with the PNS for incoming calls are:

与传入呼叫的PNS关联的状态为：

idle An Incoming-Call-Request message is received. If the request is not acceptable, an Incoming-Call-Reply is sent back to the PAC and the PNS remains in the idle state. If the Incoming-Call-Request message is acceptable, an Incoming-Call-Reply is sent indicating accept in the result code. The session moves to the wait_connect state.

idle接收到来电请求消息。如果请求不可接受，则将传入呼叫应答发送回PAC，并且PNS保持空闲状态。如果传入呼叫请求消息是可接受的，则发送一个传入呼叫应答，在结果代码中指示接受。会话移动到等待连接状态。

wait_connect If the session is connected on the PAC, the PAC sends an incoming call connect message to the PNS which then moves into established state. The PAC may send a Call-Disconnect-Notify to indicate that the incoming caller could not be connected. This could happen, for example, if a telephone user accidently places a standard voice call to a PAC resulting in a handshake failure on the called modem.

wait_connect如果会话连接在PAC上，PAC会向PNS发送传入呼叫连接消息，然后PNS进入已建立状态。PAC可能会发送呼叫断开通知，以指示传入呼叫者无法连接。例如，如果电话用户不小心向PAC发出标准语音呼叫，导致被呼叫调制解调器上的握手失败，则可能发生这种情况。

established The session is terminated either by receipt of a Call-Disconnect-Notify message from the PAC or by sending a Call-Clear-Request. Once a Call-Clear-Request has been sent, the session enters the wait_disconnect state.

已建立的会话通过从PAC接收呼叫断开通知消息或发送呼叫清除请求来终止。发送呼叫清除请求后，会话将进入等待断开连接状态。

wait_disconnect Once a Call-Disconnect-Notify is received the session moves back to the idle state.

等待\断开一旦收到呼叫断开通知，会话将移回空闲状态。

3.2.4. Outgoing Calls

3.2.4. 去电

Outgoing messages are initiated by a PNS and instruct a PAC to place a call on a telco interface. There are only two messages for outgoing calls: Outgoing-Call-Request and Outgoing-Call-Reply. The PNS sends an Outgoing-Call-Request specifying the dialed party phone number and subaddress as well as speed and window parameters. The PAC MUST respond to the Outgoing-Call-Request message with an Outgoing-Call-Reply message once the PAC determines that:

传出消息由PNS发起，并指示PAC在电信接口上进行呼叫。传出呼叫只有两条消息：传出呼叫请求和传出呼叫回复。PNS发送一个传出呼叫请求，指定拨号方电话号码和子地址以及速度和窗口参数。一旦PAC确定：

The call has been successfully connected

呼叫已成功连接

A call failure has occurred for reasons such as: no interfaces are available for dial-out, the called party is busy or does not answer, or no dial tone is detected on the interface chosen for dialing

发生呼叫失败的原因包括：没有可用于拨出的接口，被叫方忙或不应答，或者在选择拨号的接口上未检测到拨号音

3.2.4.1. PAC Outgoing Call States

3.2.4.1. 传出呼叫状态

Receive Outgoing Call Request in Error
/Send Outgoing Call Reply with Error
  |--------+
  |        |         Receive Outgoing Call Request No Error
  |        |         /Off Hook; Dial
  |        |   +-----------------------------------------
  ^        V   ^                                        V
+-----------------+           Incomplete Call        +-----------------+
|      idle       |           /Send Outgoing Call    |   wait_cs_ans   |
+-----------------+            Reply with Error      +-----------------+
        ^      ^           or Recv. Call Clear Req.  V  V Telco Answer
        |      |              /Send Disconnect Notify|  | /Send Outgoing
        |      +-------------------------------------+  |  Call Reply.
        |                                               V
        |                                     +-----------------+
        +-------------------------------------|   established   |
                 Receive Call Clear Request   +-----------------+
                 or local terminate
                 or telco disconnect
                 /Hangup call and send
                 Call Disconnect Notify

Receive Outgoing Call Request in Error
/Send Outgoing Call Reply with Error
  |--------+
  |        |         Receive Outgoing Call Request No Error
  |        |         /Off Hook; Dial
  |        |   +-----------------------------------------
  ^        V   ^                                        V
+-----------------+           Incomplete Call        +-----------------+
|      idle       |           /Send Outgoing Call    |   wait_cs_ans   |
+-----------------+            Reply with Error      +-----------------+
        ^      ^           or Recv. Call Clear Req.  V  V Telco Answer
        |      |              /Send Disconnect Notify|  | /Send Outgoing
        |      +-------------------------------------+  |  Call Reply.
        |                                               V
        |                                     +-----------------+
        +-------------------------------------|   established   |
                 Receive Call Clear Request   +-----------------+
                 or local terminate
                 or telco disconnect
                 /Hangup call and send
                 Call Disconnect Notify

The states associated with the PAC for outgoing calls are:

与PAC有关的传出呼叫的状态为：

idle Received Outgoing-Call-Request. If this is received in error, respond with an Outgoing-Call-Reply with error condition set. Otherwise, allocate physical channel to dial on. Place the outbound call, wait for a connection, and move to the wait_cs_ans state.

空闲接收到传出呼叫请求。如果这是错误接收的，则使用设置了错误条件的传出呼叫应答进行响应。否则，请分配要拨号的物理通道。拨打出站呼叫，等待连接，然后转到等待状态。

wait_cs_ans If the call is incomplete, send an Outgoing-Call-Reply with a non-zero Error Code. If a timer expires on an outbound call, send back an Outgoing-Call-Reply with a non-zero Error Code. If a circuit switched connection is established, send an Outgoing-Call-Reply indicating success.

等待\u cs \u ans如果呼叫未完成，请发送带有非零错误代码的传出呼叫应答。如果计时器在出站呼叫时过期，请发回带有非零错误代码的出站呼叫应答。如果建立了电路交换连接，则发送一个呼出应答，指示成功。

established If a Call-Clear-Request is received, the telco call SHOULD be released via appropriate mechanisms and a Call-Disconnect-Notify message SHOULD BE sent to the PNS. If the call is disconnected by the client or by the telco interface, a Call-Disconnect-Notify message SHOULD be sent to the PNS.

如果收到呼叫清除请求，则应通过适当的机制释放电信公司呼叫，并向PNS发送呼叫断开通知消息。如果呼叫被客户端或电信接口断开，则应向PNS发送呼叫断开通知消息。

3.2.4.2. PNS Outgoing Call States

3.2.4.2. 外呼状态

                Open Indication                              Abort/Send
                /Send Outgoing Call                          Call Clear
                 Request                  +-----------------+Request
        +-------------------------------->|    Wait-Reply   |----------+
        |                                 +-----------------+          |
        |     Receive Outgoing Call Reply   V     V   Receive Outgoing |
        |     with Error                    |     |   Call Reply       |
        |   +-------------------------------+     |   No Error         |
        ^   V                                     V                    |
+-----------------+                              +-----------------+   |
|      Idle       |<-----------------------------|   Established   |   |
+-----------------+    Receive Call Disconnect   +-----------------+   |
        ^              Notify                     V   Local Terminate  |
        |                                         |   /Send Call Clear |
        |                                         |    Request         |
        |     Receive Call Disconnect             V                    |
        |     Notify                      +-----------------+          |
        +---------------------------------| Wait-Disconnect |<---------+
                                          +-----------------+

                Open Indication                              Abort/Send
                /Send Outgoing Call                          Call Clear
                 Request                  +-----------------+Request
        +-------------------------------->|    Wait-Reply   |----------+
        |                                 +-----------------+          |
        |     Receive Outgoing Call Reply   V     V   Receive Outgoing |
        |     with Error                    |     |   Call Reply       |
        |   +-------------------------------+     |   No Error         |
        ^   V                                     V                    |
+-----------------+                              +-----------------+   |
|      Idle       |<-----------------------------|   Established   |   |
+-----------------+    Receive Call Disconnect   +-----------------+   |
        ^              Notify                     V   Local Terminate  |
        |                                         |   /Send Call Clear |
        |                                         |    Request         |
        |     Receive Call Disconnect             V                    |
        |     Notify                      +-----------------+          |
        +---------------------------------| Wait-Disconnect |<---------+
                                          +-----------------+

The states associated with the PNS for outgoing calls are:

与拨出电话的PNS关联的状态为：

idle An Outgoing-Call-Request message is sent to the PAC and the session moves into the wait_reply state.

空闲一个传出呼叫请求消息被发送到PAC，会话进入等待应答状态。

wait_reply An Outgoing-Call-Reply is received which indicates an error. The session returns to idle state. No telco call is active. If the Outgoing-Call-Reply does not indicate an error, the telco call is connected and the session moves to the established state.

等待应答收到一个传出呼叫应答，表示有错误。会话将返回空闲状态。没有电信呼叫处于活动状态。如果传出呼叫应答未指示错误，则电信呼叫已连接，会话移动到已建立状态。

established If a Call-Disconnect-Notify is received, the telco call has been terminated for the reason indicated in the Result and Cause Codes. The session moves back to the idle state. If the PNS chooses to terminate the session, it sends a Call-Clear-Request to the PAC and then enters the wait_disconnect state.

如果收到呼叫断开通知，则电信呼叫已根据结果代码和原因代码中指示的原因终止。会话将移回空闲状态。如果PNS选择终止会话，它将向PAC发送呼叫清除请求，然后进入等待断开连接状态。

wait_disconnect A session disconnection is waiting to be confirmed by the PAC. Once the PNS receives the Call-Disconnect-Notify message, the session enters idle state.

等待\断开连接会话断开连接正在等待PAC确认。一旦PNS收到Call Disconnect Notify消息，会话将进入空闲状态。

4. Tunnel Protocol Operation

4. 隧道协议操作

The user data carried by the PPTP protocol are PPP data packets. PPP packets are carried between the PAC and PNS, encapsulated in GRE packets which in turn are carried over IP. The encapsulated PPP packets are essentially PPP data packets less any media specific framing elements. No HDLC flags, bit insertion, control characters, or control character escapes are included. No CRCs are sent through the tunnel. The IP packets transmitted over the tunnels between a PAC and PNS has the following general structure:

PPTP协议携带的用户数据是PPP数据包。PPP数据包在PAC和PNS之间传输，封装在GRE数据包中，GRE数据包通过IP传输。封装的PPP分组基本上是PPP数据分组减去任何媒体特定的帧元素。不包括HDLC标志、位插入、控制字符或控制字符转义。没有通过隧道发送CRC。通过PAC和PNS之间的隧道传输的IP数据包具有以下一般结构：

      +--------------------------------+
      |          Media Header          |
      +--------------------------------+
      |           IP Header            |
      +--------------------------------+
      |           GRE Header           |
      +--------------------------------+
      |           PPP Packet           |
      +--------------------------------+

      +--------------------------------+
      |          Media Header          |
      +--------------------------------+
      |           IP Header            |
      +--------------------------------+
      |           GRE Header           |
      +--------------------------------+
      |           PPP Packet           |
      +--------------------------------+

4.1. Enhanced GRE header

4.1. 增强GRE报头

The GRE header used in PPTP is enhanced slightly from that specified in the current GRE protocol specification [1,2]. The main difference involves the definition of a new Acknowledgment Number field, used to determine if a particular GRE packet or set of packets has arrived at the remote end of the tunnel. This Acknowledgment capability is not used in conjunction with any retransmission of user data packets. It is used instead to determine the rate at which user data packets are to be transmitted over the tunnel for a given user session. The format of the enhanced GRE header is as follows:

PPTP中使用的GRE报头比当前GRE协议规范[1,2]中规定的有所增强。主要区别在于定义了一个新的确认号字段，用于确定特定GRE数据包或数据包集是否已到达隧道的远端。此确认功能不与用户数据包的任何重传一起使用。它用于确定给定用户会话中通过隧道传输用户数据包的速率。增强型GRE标题的格式如下：

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |C|R|K|S|s|Recur|A| Flags | Ver |         Protocol Type         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Key (HW) Payload Length    |       Key (LW) Call ID        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Sequence Number (Optional)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Acknowledgment Number (Optional)                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |C|R|K|S|s|Recur|A| Flags | Ver |         Protocol Type         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Key (HW) Payload Length    |       Key (LW) Call ID        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Sequence Number (Optional)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Acknowledgment Number (Optional)                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

C (Bit 0) Checksum Present. Set to zero (0).

存在C（位0）校验和。设置为零（0）。

R (Bit 1) Routing Present. Set to zero (0).

存在R（位1）路由。设置为零（0）。

K (Bit 2) Key Present. Set to one (1). S (Bit 3) Sequence Number Present. Set to one (1) if a payload (data) packet is present. Set to zero (0) if payload is not present (GRE packet is an Acknowledgment only).

K（第2位）键存在。设置为一（1）。存在S（第3位）序列号。如果存在有效负载（数据）数据包，则设置为一（1）。如果有效负载不存在，则设置为零（0）（GRE数据包仅为确认）。

s (Bit 4) Strict source route present. Set to zero (0).

s（位4）严格源路由存在。设置为零（0）。

Recur (Bits 5-7) Recursion control. Set to zero (0).

递归（位5-7）递归控制。设置为零（0）。

A (Bit 8) Acknowledgment sequence number present. Set to one (1) if packet contains Acknowledgment Number to be used for acknowledging previously transmitted data.

存在（位8）确认序列号。如果数据包包含用于确认先前传输数据的确认号，则设置为一（1）。

Flags (Bits 9-12) Must be set to zero (0).

标志（位9-12）必须设置为零（0）。

Ver (Bits 13-15) Must contain 1 (enhanced GRE).

版本（第13-15位）必须包含1（增强型GRE）。

Protocol Type Set to hex 880B [8].

协议类型设置为hex 880B[8]。

Key Use of the Key field is up to the implementation. PPTP uses it as follows: Payload Length (High 2 octets of Key) Size of the payload, not including the GRE header

密钥字段的密钥使用取决于实现。PPTP使用它如下：有效负载长度（键的高2个八位字节）有效负载的大小，不包括GRE头

Call ID (Low 2 octets) Contains the Peer's Call ID for the session to which this packet belongs.

Call ID（低2个八位字节）包含该数据包所属会话的对等方呼叫ID。

Sequence Number Contains the sequence number of the payload. Present if S bit (Bit 3) is one (1).

序列号包含有效负载的序列号。如果S位（位3）为一（1），则存在。

Acknowledgment Number Contains the sequence number of the highest numbered GRE packet received by the sending peer for this user session. Present if A bit (Bit 8) is one (1).

确认号包含发送对等方为此用户会话接收的编号最高的GRE数据包的序列号。如果位（位8）为一（1），则显示。

The payload section contains a PPP data packet without any media specific framing elements.

有效负载部分包含没有任何媒体特定帧元素的PPP数据包。

The sequence numbers involved are per packet sequence numbers. The sequence number for each user session is set to zero at session startup. Each packet sent for a given user session which contains a payload (and has the S bit (Bit 3) set to one) is assigned the next consecutive sequence number for that session.

所涉及的序列号是每个数据包的序列号。每个用户会话的序列号在会话启动时设置为零。为给定用户会话发送的每个包含有效负载（且S位（位3）设置为1）的数据包被分配该会话的下一个连续序列号。

This protocol allows acknowledgments to be carried with the data and makes the overall protocol more efficient, which in turn requires less buffering of packets.

该协议允许确认与数据一起携带，并使整个协议更高效，这反过来又需要更少的数据包缓冲。

4.2. Sliding Window Protocol

4.2. 滑动窗口协议

The sliding window protocol used on the PPTP data path is used for flow control by each side of the data exchange. The enhanced GRE protocol allows packet acknowledgments to be piggybacked on data packets. Acknowledgments can also be sent separately from data packets. Again, the main purpose of the sliding window protocol is for flow control--retransmissions are not performed by the tunnel peers.

PPTP数据路径上使用的滑动窗口协议用于数据交换各方的流量控制。增强的GRE协议允许在数据包上进行包确认。确认也可以与数据包分开发送。同样，滑动窗口协议的主要用途是流量控制——重传不是由隧道对等方执行的。

4.2.1. Initial Window Size

4.2.1. 初始窗口大小

Although each side has indicated the maximum size of its receive window, it is recommended that a conservative approach be taken when beginning to transmit data. The initial window size on the transmitter is set to half the maximum size the receiver requested, with a minimum size of one packet. The transmitter stops sending packets when the number of packets awaiting acknowledgment is equal to the current window size. As the receiver successfully digests each window, the window size on the transmitter is bumped up by one packet until the maximum is reached. This method prevents a system from flooding an already congested network because no history has been established.

尽管每侧都已指示其接收窗口的最大大小，但建议在开始传输数据时采取保守的方法。发射机上的初始窗口大小设置为接收机请求的最大窗口大小的一半，最小窗口大小为一个数据包。当等待确认的数据包数量等于当前窗口大小时，发送器停止发送数据包。当接收器成功消化每个窗口时，发射器上的窗口大小会增加一个数据包，直到达到最大值。这种方法可以防止系统淹没已经拥挤的网络，因为没有建立历史记录。

4.2.2. Closing the Window

4.2.2. 关窗

When a time-out does occur on a packet, the sender adjusts the size of the transmit window down to one half its value when it failed. Fractions are rounded up, and the minimum window size is one.

当数据包确实发生超时时，发送方将发送窗口的大小调整为失败时的一半。分数向上舍入，最小窗口大小为1。

4.2.3. Opening the Window

4.2.3. 打开窗户

With every successful transmission of a window's worth of packets without a time-out, the transmit window size is increased by one packet until it reaches the maximum window size that was sent by the other side when the call was connected. As stated earlier, no retransmission is done on a time-out. After a time-out, the transmission resumes with the window starting at one half the size of the transmit window when the time-out occurred and adjusting upward by one each time the transmit window is filled with packets that are all acknowledged without time-outs.

在没有超时的情况下，每次成功传输一个窗口的数据包时，传输窗口大小将增加一个数据包，直到它达到连接呼叫时另一方发送的最大窗口大小。如前所述，在超时时不进行重传。超时后，传输恢复，窗口从发生超时时传输窗口大小的一半开始，并在每次传输窗口充满所有已确认但未超时的数据包时向上调整1。

4.2.4. Window Overflow

4.2.4. 窗口溢出

When a receiver's window overflows with too many incoming packets, excess packets are thrown away. This situation should not arise if the sliding window procedures are being properly followed by the transmitter and receiver. It is assumed that, on the transmit side, packets are buffered for transmission and are no longer accepted from the packet source when the transmit buffer fills.

当接收器的窗口溢出过多的传入数据包时，多余的数据包将被丢弃。如果发射器和接收器正确遵循滑动窗口程序，则不应出现这种情况。假设在传输侧，分组被缓冲以用于传输，并且当传输缓冲器填充时不再从分组源接受分组。

4.2.5. Multi-packet Acknowledgment

4.2.5. 多包确认

One feature of the PPTP sliding window protocol is that it allows the acknowledgment of multiple packets with a single acknowledgment. All outstanding packets with a sequence number lower or equal to the acknowledgment number are considered acknowledged. Time-out calculations are performed using the time the packet corresponding to the highest sequence number being acknowledged was transmitted.

PPTP滑动窗口协议的一个特点是，它允许用一次确认确认多个数据包。序列号小于或等于确认号的所有未完成数据包都被视为已确认。使用与被确认的最高序列号对应的分组被发送的时间来执行超时计算。

Adaptive time-out calculations are only performed when an Acknowledgment is received. When multi-packet acknowledgments are used, the overhead of the adaptive time-out algorithm is reduced. The PAC is not required to transmit multi-packet acknowledgments; it can instead acknowledge each packet individually as it is delivered to the PPP client.

自适应超时计算仅在收到确认时执行。当使用多包确认时，自适应超时算法的开销降低。PAC不需要发送多包确认；相反，它可以在每个数据包交付给PPP客户端时单独确认。

4.3. Out-of-sequence Packets

4.3. 无序数据包

Occasionally packets lose their sequencing across a complicated internetwork. Say, for example that a PNS sends packets 0 to 5 to a PAC. Because of rerouting in the internetwork, packet 4 arrives at the PAC before packet 3. The PAC acknowledges packet 4, and may assume packet 3 is lost. This acknowledgment grants window credit beyond packet 4.

有时数据包会在复杂的网络中丢失其序列。例如，PNS向PAC发送数据包0到5。由于互联网中的重新路由，数据包4在数据包3之前到达PAC。PAC确认分组4，并且可以假设分组3丢失。此确认授予超过数据包4的窗口信用。

When the PAC does receive packet 3, it MUST not attempt to transmit it to the corresponding PPP client. To do so could cause problems, as proper PPP protocol operation is premised upon receiving packets in sequence. PPP does properly deal with the loss of packets, but not with reordering so out of sequence packets between the PNS and PAC MUST be silently discarded, or they may be reordered by the receiver. When packet 5 comes in, it is acknowledged by the PAC since it has a higher sequence number than 4, which was the last highest packet acknowledged by the PAC. Packets with duplicate sequence numbers should never occur since the PAC and PNS never retransmit GRE packets. A robust implementation will silently discard duplicate GRE packets, should it receive any.

当PAC确实收到数据包3时，它不得尝试将其发送到相应的PPP客户端。这样做可能会导致问题，因为正确的PPP协议操作是以按顺序接收数据包为前提的。PPP确实正确地处理数据包丢失，但不处理重新排序，因此PNS和PAC之间的无序数据包必须被默默地丢弃，或者它们可能被接收器重新排序。当数据包5进入时，PAC确认它，因为它的序列号高于4，4是PAC确认的最后一个最高的数据包。具有重复序列号的数据包不应出现，因为PAC和PNS从不重新传输GRE数据包。一个健壮的实现将默默地丢弃重复的GRE数据包，如果它接收到任何数据包。

4.4. Acknowledgment Time-Outs

4.4. 确认超时

PPTP uses sliding windows and time-outs to provide both user session flow-control across the internetwork and to perform efficient data buffering to keep the PAC-PNS data channels full without causing receive buffer overflow. PPTP requires that a time-out be used to recover from dropped data or acknowledgment packets. The exact implementation of the time-out is vendor-specific. It is suggested that an adaptive time-out be implemented with backoff for congestion control. The time-out mechanism proposed here has the following properties:

PPTP使用滑动窗口和超时来提供跨互联网的用户会话流控制，并执行有效的数据缓冲，以保持PAC-PNS数据通道满，而不会导致接收缓冲区溢出。PPTP要求使用超时从丢弃的数据或确认数据包中恢复。超时的具体实施取决于供应商。有人建议采用自适应超时和退避来实现拥塞控制。此处提出的超时机制具有以下特性：

Independent time-outs for each session. A device (PAC or PNS) will have to maintain and calculate time-outs for every active session.

每个会话的独立超时。设备（PAC或PNS）必须为每个活动会话维护和计算超时。

An administrator-adjustable maximum time-out, MaxTimeOut, unique to each device.

管理员可调整的最大超时MaxTimeOut，对每个设备都是唯一的。

An adaptive time-out mechanism that compensates for changing throughput. To reduce packet processing overhead, vendors may choose not to recompute the adaptive time-out for every received acknowledgment. The result of this overhead reduction is that the time-out will not respond as quickly to rapid network changes.

一种自适应超时机制，用于补偿吞吐量的变化。为了减少数据包处理开销，供应商可以选择不对每个接收到的确认重新计算自适应超时。这种开销减少的结果是，超时不会对快速的网络变化做出快速响应。

Timer backoff on time-out to reduce congestion. The backed-off timer value is limited by the configurable maximum time-out value. Timer backoff is done every time an acknowledgment time-out occurs.

计时器在超时时后退，以减少拥塞。后退计时器值受可配置的最大超时值限制。每次确认超时时都会执行计时器后退。

In general, this mechanism has the desirable behavior of quickly backing off upon a time-out and of slowly decreasing the time-out value as packets are delivered without time-outs.

一般来说，该机制具有在超时时快速后退以及在数据包在没有超时的情况下交付时缓慢降低超时值的理想行为。

Some definitions:

一些定义：

Packet Processing Delay (PPD) is the amount of time required for each side to process the maximum amount of data buffered in their receive packet sliding window. The PPD is the value exchanged between the PAC and PNS when a call is established. For the PNS, this number should be small. For a PAC making modem connections, this number could be significant.

数据包处理延迟（PPD）是指每一方处理其接收数据包滑动窗口中缓冲的最大数据量所需的时间量。PPD是建立呼叫时PAC和PNS之间交换的值。对于PNS，这个数字应该很小。对于进行调制解调器连接的PAC，此数字可能非常重要。

Sample is the actual amount of time incurred receiving an acknowledgment for a packet. The Sample is measured, not calculated.

Sample是接收数据包确认所花费的实际时间。样本是测量的，而不是计算的。

Round-Trip Time (RTT) is the estimated round-trip time for an Acknowledgment to be received for a given transmitted packet. When the network link is a local network, this delay will be minimal (if not zero). When the network link is the Internet, this delay could be substantial and vary widely. RTT is adaptive: it will adjust to include the PPD and whatever shifting network delays contribute to the time between a packet being transmitted and receiving its acknowledgment.

往返时间（RTT）是针对给定传输数据包接收确认的估计往返时间。当网络链路是本地网络时，该延迟将是最小的（如果不是零）。当网络链接是Internet时，这种延迟可能很大，并且变化很大。RTT是自适应的：它将进行调整，以包括PPD和任何移动的网络延迟，这些延迟会对数据包传输和接收确认之间的时间产生影响。

Adaptive Time-Out (ATO) is the time that must elapse before an acknowledgment is considered lost. After a time-out, the sliding window is partially closed and the ATO is backed off.

自适应超时（ATO）是确认被视为丢失之前必须经过的时间。超时后，滑动车窗部分关闭，ATO后退。

The Packet Processing Delay (PPD) parameter is a 16-bit word exchanged during the Call Control phase that represents tenths of a second (64 means 6.4 seconds). The protocol only specifies that the parameter is exchanged, it does not specify how it is calculated. The way values for PPD are calculated is implementation-dependent and need not be variable (static time-outs are allowed). The PPD must be exchanged in the call connect sequences, even if it remains constant in an implementation. One possible way to calculate the PPD is:

分组处理延迟（PPD）参数是在呼叫控制阶段交换的16位字，表示十分之一秒（64表示6.4秒）。协议只指定交换参数，不指定如何计算参数。计算PPD值的方式取决于实现，不需要可变（允许静态超时）。PPD必须在调用连接序列中交换，即使它在实现中保持不变。计算PPD的一种可能方法是：

   PPD' = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / ConnectRate
   PPD = PPD' + PACFudge

   PPD' = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / ConnectRate
   PPD = PPD' + PACFudge

Header is the total size of the IP and GRE headers, which is 36. The MTU is the overall MTU for the internetwork link between the PAC and PNS. WindowSize represents the number of packets in the sliding window, and is implementation-dependent. The latency of the internetwork could be used to pick a window size sufficient to keep the current session's pipe full. The constant 8 converts octets to bits (assuming ConnectRate is in bits per second). If ConnectRate is in bytes per second, omit the 8. PACFudge is not required but can be used to take overall processing overhead of the PAC into account.

Header是IP和GRE标头的总大小，为36。MTU是PAC和PNS之间网络链路的总体MTU。WindowsSize表示滑动窗口中的数据包数，具体取决于实现。可以使用互联网的延迟来选择一个足以保持当前会话管道满的窗口大小。常数8将八位字节转换为位（假设连接速率为每秒位）。如果ConnectRate以字节/秒为单位，则省略8。PACFudge不是必需的，但可以用于考虑PAC的总体处理开销。

The value of PPD is used to seed the adaptive algorithm with the initial RTT[n-1] value.

PPD值用于使用初始RTT[n-1]值为自适应算法播种。

4.4.1. Calculating Adaptive Acknowledgment Time-Out

4.4.1. 计算自适应确认超时

We still must decide how much time to allow for acknowledgments to return. If the time-out is set too high, we may wait an unnecessarily long time for dropped packets. If the time-out is too short, we may time out just before the acknowledgment arrives. The acknowledgment time-out should also be reasonable and responsive to changing network conditions.

我们仍然必须决定回执的时间。如果超时设置得太高，我们可能会为丢弃的数据包等待不必要的长时间。如果超时时间太短，我们可能会在确认到达之前超时。确认超时也应合理，并对不断变化的网络条件作出响应。

The suggested adaptive algorithm detailed below is based on the TCP 1989 implementation and is explained in [11]. 'n' means this iteration of the calculation, and 'n-1' refers to values from the last calculation.

下文详述的建议自适应算法基于TCP 1989实现，并在[11]中进行了解释n’表示该计算的迭代，“n-1”表示上一次计算的值。

      DIFF[n] = SAMPLE[n] - RTT[n-1]
      DEV[n] = DEV[n-1] + (beta * (|DIFF[n]| - DEV[n-1]))
      RTT[n] = RTT[n-1] + (alpha * DIFF[n])
      ATO[n] = MAX (MinTimeOut, MIN (RTT[n] +
               (chi * DEV[n]), MaxTimeOut))

      DIFF[n] = SAMPLE[n] - RTT[n-1]
      DEV[n] = DEV[n-1] + (beta * (|DIFF[n]| - DEV[n-1]))
      RTT[n] = RTT[n-1] + (alpha * DIFF[n])
      ATO[n] = MAX (MinTimeOut, MIN (RTT[n] +
               (chi * DEV[n]), MaxTimeOut))

DIFF represents the error between the last estimated round-trip time and the measured time. DIFF is calculated on each iteration.

DIFF表示最后估计的往返时间与测量的时间之间的误差。在每次迭代中计算差异。

DEV is the estimated mean deviation. This approximates the standard deviation. DEV is calculated on each iteration and stored for use in the next iteration. Initially, it is set to 0.

DEV是估计的平均偏差。这近似于标准偏差。在每次迭代中计算DEV并存储以供下一次迭代使用。最初，它被设置为0。

RTT is the estimated round-trip time of an average packet. RTT is ycalculated on each iteration and stored for use in the next iteration. Initially, it is set to PPD.

RTT是平均数据包的估计往返时间。RTT在每次迭代时计算，并存储起来以供下一次迭代使用。最初，它被设置为PPD。

ATO is the adaptive time-out for the next transmitted packet. ATO is calculated on each iteration. Its value is limited, by the MIN function, to be a maximum of the configured MaxTimeOut value.

ATO是下一个传输数据包的自适应超时。每次迭代计算ATO。其值受MIN函数限制为配置的MaxTimeOut值的最大值。

Alpha is the gain for the average and is typically 1/8 (0.125).

Alpha是平均值的增益，通常为1/8（0.125）。

Beta is the gain for the deviation and is typically 1/4 (0.250).

β是偏差的增益，通常为1/4（0.250）。

Chi is the gain for the time-out and is typically set to 4.

Chi是超时的增益，通常设置为4。

To eliminate division operations for fractional gain elements, the entire set of equations can be scaled. With the suggested gain constants, they should be scaled by 8 to eliminate all division. To simplify calculations, all gain values are kept to powers of two so that shift operations can be used in place of multiplication or division.

为了消除分数增益元素的除法运算，可以缩放整个方程组。根据建议的增益常数，它们应按8缩放以消除所有除法。为了简化计算，所有增益值都保持为2的幂，因此可以使用移位运算代替乘法或除法。

4.4.2. Congestion Control: Adjusting for Time-Out

4.4.2. 拥塞控制：调整超时

This section describes how the calculation of ATO is modified in the case where a time-out does occur. When a time-out occurs, the time-out value should be adjusted rapidly upward. Although the GRE packets are not retransmitted when a time-out occurs, the time-out should be adjusted up toward a maximum limit. To compensate for shifting internetwork time delays, a strategy must be employed to increase the time-out when it expires (notice that in addition to increasing the time-out, we are also shrinking the size of the window as described in the next section). For an interval in which a time-out occurs, the new ATO is calculated as:

本节描述了在超时情况下如何修改ATO的计算。发生超时时，应迅速向上调整超时值。尽管发生超时时GRE数据包不会被重新传输，但超时应向上调整至最大限制。为了补偿不断变化的网络间时间延迟，必须采用一种策略在超时到期时增加超时（请注意，除了增加超时外，我们还在缩小窗口的大小，如下一节所述）。对于发生超时的时间间隔，新ATO的计算公式为：

      RTT[n] = delta * RTT[n-1]
      DEV[n] = DEV[n-1]
      ATO[n] = MAX (MinTimeOut, MIN (RTT[n] +
               (chi * DEV[n]), MaxTimeOut))

      RTT[n] = delta * RTT[n-1]
      DEV[n] = DEV[n-1]
      ATO[n] = MAX (MinTimeOut, MIN (RTT[n] +
               (chi * DEV[n]), MaxTimeOut))

In this calculation of ATO, only the two values that both contribute to ATO and are stored for the next iteration are calculated. RTT is scaled by delta, and DEV is unmodified. DIFF is not carried forward and is not used in this scenario. A value of 2 for Delta, the time-out gain factor for RTT, is suggested.

在该ATO计算中，仅计算对ATO有贡献且为下一次迭代存储的两个值。RTT按增量缩放，而DEV未修改。差异不结转，也不在本场景中使用。建议RTT的超时增益因子Delta的值为2。

5. Security Considerations

5. 安全考虑

The security of user data passed over the tunneled PPP connection is addressed by PPP, as is authentication of the PPP peers.

通过隧道PPP连接传递的用户数据的安全性由PPP解决，PPP对等方的身份验证也是如此。

Because the PPTP control channel messages are neither authenticated nor integrity protected, it might be possible for an attacker to hijack the underlying TCP connection. It is also possible to manufacture false control channel messages and alter genuine messages in transit without detection.

由于PPTP控制通道消息既没有经过身份验证，也没有完整性保护，因此攻击者可能劫持底层TCP连接。也有可能在传输过程中制造虚假控制通道消息并在未经检测的情况下更改真实消息。

The GRE packets forming the tunnel itself are not cryptographically protected. Because the PPP negotiations are carried out over the tunnel, it may be possible for an attacker to eavesdrop on and modify those negotiations.

构成隧道本身的GRE数据包不受加密保护。由于PPP协商是通过隧道进行的，攻击者可能会窃听和修改这些协商。

Unless the PPP payload data is cryptographically protected, it can be captured and read or modified.

除非PPP有效负载数据受到加密保护，否则它可以被捕获、读取或修改。

6. Authors' Addresses

6. 作者地址

Kory Hamzeh Ascend Communications 1275 Harbor Bay Parkway Alameda, CA 94502

加利福尼亚州阿拉米达港湾公园路1275号科里·哈姆泽·阿森登通讯公司，邮编94502

   EMail: kory@ascend.com

   EMail: kory@ascend.com

Gurdeep Singh Pall Microsoft Corporation Redmond, WA

格迪普·辛格·帕尔微软公司，华盛顿州雷德蒙

   EMail: gurdeep@microsoft.com

   EMail: gurdeep@microsoft.com

William Verthein U.S. Robotics/3Com

William Verthein美国机器人技术/3Com

Jeff Taarud Copper Mountain Networks

杰夫·塔鲁德铜山网络公司

W. Andrew Little ECI Telematics

W.Andrew Little ECI远程信息处理

Glen Zorn Microsoft Corporation Redmond, WA

格伦·佐恩微软公司，华盛顿州雷德蒙

   EMail: glennz@microsoft.com

   EMail: glennz@microsoft.com

7. References

7. 工具书类

[1] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994.

[1] Hanks，S.，Li，T.，Farinaci，D.和P.Traina，“通用路由封装（GRE）”，RFC 17011994年10月。

[2] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing Encapsulation (GRE) over IPv4 Networks", RFC 1702, October 1994.

[2] Hanks，S.，Li，T.，Farinaci，D.和P.Traina，“IPv4网络上的通用路由封装（GRE）”，RFC 1702，1994年10月。

[3] Lloyd, B. and W. Simpson, "PPP Authentication Protocols", RFC 1334, October 1992.

[3] Lloyd，B.和W.Simpson，“PPP认证协议”，RFC 13341992年10月。

[4] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.

[4] 《传输控制协议》，标准7，RFC 793，1981年9月。

[5] Postel, J., "User Data Protocol", STD 6, RFC 768, August 1980.

[5] Postel，J.，“用户数据协议”，STD 6，RFC 768，1980年8月。

   [6]  Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
        October 1994.  See also: http://www.iana.org/numbers.html

   [6]  Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
        October 1994.  See also: http://www.iana.org/numbers.html

[7] Simpson, W., editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.

[7] 辛普森，W.，编辑，“点对点协议（PPP）”，STD 51，RFC 1661994年7月。

[8] Ethertype for PPP, Reserved with Xerox Corporation.

[8] Ethertype用于PPP，由施乐公司保留。

[9] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.

[9] 辛普森，W.，“PPP挑战握手认证协议（CHAP）”，RFC 1994，1996年8月。

[10] Blunk, L. and J Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998.

[10] Blunk，L.和J Vollbrecht，“PPP可扩展认证协议（EAP）”，RFC 2284，1998年3月。

[11] Stevens, R., "TCP/IP Illustrated, Volume 1", p. 300, Addison-Wesley, 1994.

[11] Stevens，R.，“TCP/IP图解，第1卷”，第页。艾迪生·韦斯利，1994年，第300页。

[12] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[12] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。

8. Full Copyright Statement

8. 完整版权声明

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 assigns.

上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。

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编辑功能的资金目前由互联网协会提供。