Network Working Group S. Petrack
Request for Comments: 2848 MetaTel
Category: Standards Track L. Conroy
Siemens Roke Manor Research
June 2000
Network Working Group S. Petrack
Request for Comments: 2848 MetaTel
Category: Standards Track L. Conroy
Siemens Roke Manor Research
June 2000
The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services
PINT服务协议：SIP和SDP的扩展，用于电话呼叫服务的IP访问
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
This document contains the specification of the PINT Service Protocol 1.0, which defines a protocol for invoking certain telephone services from an IP network. These services include placing basic calls, sending and receiving faxes, and receiving content over the telephone. The protocol is specified as a set of enhancements and additions to the SIP 2.0 and SDP protocols.
本文档包含PINT服务协议1.0的规范，该协议定义了从IP网络调用某些电话服务的协议。这些服务包括拨打基本电话、发送和接收传真以及通过电话接收内容。该协议被指定为SIP 2.0和SDP协议的一组增强和补充。
Table of Contents
目录
1. Introduction ................................................. 4
1.1 Glossary .................................................... 6
2. PINT Milestone Services ...................................... 6
2.1 Request to Call ............................................. 7
2.2 Request to Fax Content ...................................... 7
2.3 Request to Speak/Send/Play Content .......................... 7
2.4 Relation between PINT milestone services and traditional
telephone services .......................................... 7
3. PINT Functional and Protocol Architecture .................... 8
3.1. PINT Functional Architecture ............................... 8
3.2. PINT Protocol Architecture ................................. 9
3.2.1. SDP operation in PINT .................................... 10
3.2.2. SIP Operation in PINT .................................... 11
3.3. REQUIRED and OPTIONAL elements for PINT compliance ......... 11
3.4. PINT Extensions to SDP 2.0 ................................. 12
1. Introduction ................................................. 4
1.1 Glossary .................................................... 6
2. PINT Milestone Services ...................................... 6
2.1 Request to Call ............................................. 7
2.2 Request to Fax Content ...................................... 7
2.3 Request to Speak/Send/Play Content .......................... 7
2.4 Relation between PINT milestone services and traditional
telephone services .......................................... 7
3. PINT Functional and Protocol Architecture .................... 8
3.1. PINT Functional Architecture ............................... 8
3.2. PINT Protocol Architecture ................................. 9
3.2.1. SDP operation in PINT .................................... 10
3.2.2. SIP Operation in PINT .................................... 11
3.3. REQUIRED and OPTIONAL elements for PINT compliance ......... 11
3.4. PINT Extensions to SDP 2.0 ................................. 12
3.4.1. Network Type "TN" and Address Type "RFC2543" ............. 12
3.4.2. Support for Data Objects within PINT ..................... 13
3.4.2.1. Use of fmtp attributes in PINT requests ................ 15
3.4.2.2. Support for Remote Data Object References in PINT ...... 16
3.4.2.3. Support for GSTN-based Data Objects in PINT ............ 17
3.4.2.4. Session Description support for included Data Objects .. 18
3.4.3. Attribute Tags to pass information into the Telephone
Network .................................................. 19
3.4.3.1. The phone-context attribute ............................ 20
3.4.3.2. Presentation Restriction attribute ..................... 22
3.4.3.3. ITU-T CalledPartyAddress attributes parameters ......... 23
3.4.4. The "require" attribute .................................. 24
3.5. PINT Extensions to SIP 2.0 ................................. 25
3.5.1. Multi-part MIME (sending data along with SIP request) .... 25
3.5.2. Warning header ........................................... 27
3.5.3. Mechanism to register interest in the disposition of a PINT
service, and to receive indications on that disposition .. 27
3.5.3.1. Opening a monitoring session with a SUBSCRIBE request .. 28
3.5.3.2. Sending Status Indications with a NOTIFY request ....... 30
3.5.3.3. Closing a monitoring session with an UNSUBSCRIBE request 30
3.5.3.4. Timing of SUBSCRIBE requests ........................... 31
3.5.4. The "Require:" header for PINT ........................... 32
3.5.5. PINT URLs within PINT requests ........................... 32
3.5.5.1. PINT URLS within Request-URIs .......................... 33
3.5.6. Telephony Network Parameters within PINT URLs ............ 33
3.5.7. REGISTER requests within PINT ............................ 34
3.5.8. BYE Requests in PINT ..................................... 35
4. Examples of PINT Requests and Responses ...................... 37
4.1. A request to a call center from an anonymous user to receive
a phone call ............................................... 37
4.2. A request from a non anonymous customer (John Jones) to
receive a phone call from a particular sales agent
(Mary James) ............................................... 37
4.3. A request to get a fax back ................................ 38
4.4. A request to have information read out over the phone ...... 39
4.5. A request to send an included text page to a friend's pager. 39
4.6. A request to send an image as a fax to phone number
+972-9-956-1867 ............................................ 40
4.7. A request to read out over the phone two pieces of content
in sequence ................................................ 41
4.8. Request for the prices for ISDN to be sent to my fax
machine .................................................... 42
4.9. Request for a callback ..................................... 42
4.10.Sending a set of information in response to an enquiry ..... 43
4.11.Sportsline "headlines" message sent to your phone/fax/pager 44
4.12.Automatically giving someone a fax copy of your phone bill . 45
5. Security Considerations ...................................... 46
5.1. Basic Principles for PINT Use ............................. 46
3.4.1. Network Type "TN" and Address Type "RFC2543" ............. 12
3.4.2. Support for Data Objects within PINT ..................... 13
3.4.2.1. Use of fmtp attributes in PINT requests ................ 15
3.4.2.2. Support for Remote Data Object References in PINT ...... 16
3.4.2.3. Support for GSTN-based Data Objects in PINT ............ 17
3.4.2.4. Session Description support for included Data Objects .. 18
3.4.3. Attribute Tags to pass information into the Telephone
Network .................................................. 19
3.4.3.1. The phone-context attribute ............................ 20
3.4.3.2. Presentation Restriction attribute ..................... 22
3.4.3.3. ITU-T CalledPartyAddress attributes parameters ......... 23
3.4.4. The "require" attribute .................................. 24
3.5. PINT Extensions to SIP 2.0 ................................. 25
3.5.1. Multi-part MIME (sending data along with SIP request) .... 25
3.5.2. Warning header ........................................... 27
3.5.3. Mechanism to register interest in the disposition of a PINT
service, and to receive indications on that disposition .. 27
3.5.3.1. Opening a monitoring session with a SUBSCRIBE request .. 28
3.5.3.2. Sending Status Indications with a NOTIFY request ....... 30
3.5.3.3. Closing a monitoring session with an UNSUBSCRIBE request 30
3.5.3.4. Timing of SUBSCRIBE requests ........................... 31
3.5.4. The "Require:" header for PINT ........................... 32
3.5.5. PINT URLs within PINT requests ........................... 32
3.5.5.1. PINT URLS within Request-URIs .......................... 33
3.5.6. Telephony Network Parameters within PINT URLs ............ 33
3.5.7. REGISTER requests within PINT ............................ 34
3.5.8. BYE Requests in PINT ..................................... 35
4. Examples of PINT Requests and Responses ...................... 37
4.1. A request to a call center from an anonymous user to receive
a phone call ............................................... 37
4.2. A request from a non anonymous customer (John Jones) to
receive a phone call from a particular sales agent
(Mary James) ............................................... 37
4.3. A request to get a fax back ................................ 38
4.4. A request to have information read out over the phone ...... 39
4.5. A request to send an included text page to a friend's pager. 39
4.6. A request to send an image as a fax to phone number
+972-9-956-1867 ............................................ 40
4.7. A request to read out over the phone two pieces of content
in sequence ................................................ 41
4.8. Request for the prices for ISDN to be sent to my fax
machine .................................................... 42
4.9. Request for a callback ..................................... 42
4.10.Sending a set of information in response to an enquiry ..... 43
4.11.Sportsline "headlines" message sent to your phone/fax/pager 44
4.12.Automatically giving someone a fax copy of your phone bill . 45
5. Security Considerations ...................................... 46
5.1. Basic Principles for PINT Use ............................. 46
5.1.1. Responsibility for service requests ..................... 46
5.1.2. Authority to make requests .............................. 47
5.1.3. Privacy ................................................. 47
5.1.4. Privacy Implications of SUBSCRIBE/NOTIFY ................ 48
5.2. Registration Procedures ................................... 49
5.3. Security mechanisms and implications on PINT service ...... 50
5.4. Summary of Security Implications .......................... 52
6. Deployment considerations and the Relationship PINT to I.N.
(Informative) ................................................ 54
6.1. Web Front End to PINT Infrastructure ....................... 54
6.2. Redirects to Multiple Gateways ............................. 54
6.3. Competing PINT Gateways REGISTERing to offer the same
service .................................................... 55
6.4. Limitations on Available Information and Request Timing for
SUBSCRIBE .................................................. 56
6.5. Parameters needed for invoking traditional GSTN Services
within PINT................................................. 58
6.5.1. Service Identifier ....................................... 58
6.5.2. A and B parties .......................................... 58
6.5.3. Other Service Parameters ................................. 59
6.5.4. Service Parameter Summary ................................ 59
6.6. Parameter Mapping to PINT Extensions........................ 60
7. References ................................................... 62
8. Acknowledgements ............................................. 64
Appendix A: Collected ABNF for PINT Extensions .................. 65
Appendix B: IANA Considerations ................................. 69
Authors' Addresses .............................................. 72
Full Copyright Statement ........................................ 73
5.1.1. Responsibility for service requests ..................... 46
5.1.2. Authority to make requests .............................. 47
5.1.3. Privacy ................................................. 47
5.1.4. Privacy Implications of SUBSCRIBE/NOTIFY ................ 48
5.2. Registration Procedures ................................... 49
5.3. Security mechanisms and implications on PINT service ...... 50
5.4. Summary of Security Implications .......................... 52
6. Deployment considerations and the Relationship PINT to I.N.
(Informative) ................................................ 54
6.1. Web Front End to PINT Infrastructure ....................... 54
6.2. Redirects to Multiple Gateways ............................. 54
6.3. Competing PINT Gateways REGISTERing to offer the same
service .................................................... 55
6.4. Limitations on Available Information and Request Timing for
SUBSCRIBE .................................................. 56
6.5. Parameters needed for invoking traditional GSTN Services
within PINT................................................. 58
6.5.1. Service Identifier ....................................... 58
6.5.2. A and B parties .......................................... 58
6.5.3. Other Service Parameters ................................. 59
6.5.4. Service Parameter Summary ................................ 59
6.6. Parameter Mapping to PINT Extensions........................ 60
7. References ................................................... 62
8. Acknowledgements ............................................. 64
Appendix A: Collected ABNF for PINT Extensions .................. 65
Appendix B: IANA Considerations ................................. 69
Authors' Addresses .............................................. 72
Full Copyright Statement ........................................ 73
The desire to invoke certain telephone call services from the Internet has been identified by many different groups (users, public and private network operators, call center service providers, equipment vendors, see [7]). The generic scenario is as follows (when the invocation is successful):
许多不同的群体（用户、公共和私人网络运营商、呼叫中心服务提供商、设备供应商，参见[7]）都已确定了从互联网调用某些电话呼叫服务的愿望。一般场景如下（调用成功时）：
1. an IP host sends a request to a server on an IP network; 2. the server relays the request into a telephone network; 3. the telephone network performs the requested call service.
1. IP主机向IP网络上的服务器发送请求；2.服务器将请求中继到电话网络中；3.电话网络执行请求的呼叫服务。
As examples, consider a user who wishes to have a callback placed to his/her telephone. It may be that a customer wants someone in the support department of some business to call them back. Similarly, a user may want to hear some announcement of a weather warning sent from a remote automatic weather service in the event of a storm.
作为例子，考虑一个希望将回调放在他/她的电话中的用户。客户可能希望某个业务部门的支持部门有人给他们回电话。类似地，用户可能希望在发生风暴时听到从远程自动气象服务发送的天气警报。
We use the term "PSTN/Internet Interworking (PINT) Service" to denote such a complete transaction, starting with the sending of a request from an IP client and including the telephone call itself. PINT services are distinguished by the fact that they always involve two separate networks:
我们使用术语“PSTN/互联网互通（PINT）服务”来表示这样一个完整的事务，从IP客户端发送请求开始，包括电话呼叫本身。PINT服务的区别在于，它们始终涉及两个独立的网络：
an IP network to request the placement of a call, and the Global Switched Telephone Network (GSTN) to execute the actual call. It is understood that Intelligent Network systems, private PBXs, cellular phone networks, and the ISDN can all be used to deliver PINT services. Also, the request for service might come from within a private IP network that is disconnected from the whole Internet.
一个IP网络用于请求呼叫位置，而全球交换电话网络（GSTN）用于执行实际呼叫。据了解，智能网络系统、专用PBX、移动电话网络和ISDN都可用于提供PINT服务。此外，服务请求可能来自与整个Internet断开连接的专用IP网络。
The requirements for the PINT protocol were deliberately restricted to providing the ability to invoke a small number of fixed telephone call services. These "Milestone PINT services" are specified in section 2. Great care has been taken, however, to develop a protocol that is aligned with other Internet protocols where possible, so that future extensions to PINT could develop along with Internet conferencing.
PINT协议的要求被故意限制为提供调用少量固定电话呼叫服务的能力。第2节规定了这些“里程碑式PINT服务”。然而，已经非常小心地开发了一个协议，该协议在可能的情况下与其他互联网协议保持一致，以便将来PINT的扩展可以与互联网会议一起开发。
Within the Internet conference architecture, establishing media calls is done via a combination of protocols. SIP [1] is used to establish the association between the participants within the call (this association between participants within the call is called a "session"), and SDP [2] is used to describe the media to be exchanged within the session. The PINT protocol uses these two protocols together, providing some extensions and enhancements to enable SIP clients and servers to become PINT clients and servers.
在Internet会议体系结构中，通过协议组合建立媒体呼叫。SIP[1]用于建立呼叫中参与者之间的关联（呼叫中参与者之间的这种关联称为“会话”），SDP[2]用于描述会话中要交换的媒体。PINT协议将这两个协议结合使用，提供了一些扩展和增强功能，使SIP客户端和服务器成为PINT客户端和服务器。
A PINT user who wishes to invoke a service within the telephone network uses SIP to invite a remote PINT server into a session. The invitation contains an SDP description of the media session that the user would like to take place. This might be a "sending a fax session" or a "telephone call session", for example. In a PINT service execution session the media is transported over the phone system, while in a SIP session the media is normally transported over an internet.
希望在电话网络中调用服务的PINT用户使用SIP邀请远程PINT服务器加入会话。邀请包含用户希望进行的媒体会话的SDP描述。例如，这可能是“发送传真会话”或“电话呼叫会话”。在PINT服务执行会话中，媒体通过电话系统传输，而在SIP会话中，媒体通常通过互联网传输。
When used to invoke a PINT service, SIP establishes an association between a requesting PINT client and the PINT server that is responsible for invoking the service within the telephone network. These two entities are not the same entities as the telephone network entities involved in the telephone network service. The SIP messages carry within their SDP payloads a description of the telephone network media session.
当用于调用PINT服务时，SIP在请求PINT客户端和负责调用电话网络内服务的PINT服务器之间建立关联。这两个实体与电话网络服务中涉及的电话网络实体不同。SIP消息在其SDP有效载荷中携带电话网络媒体会话的描述。
Note that the fact that a PINT server accepts an invitation and a session is established is no guarantee that the media will be successfully transported. (This is analogous to the fact that if a SIP invitation is accepted successfully, this is no guarantee against a subsequent failure of audio hardware).
请注意，PINT服务器接受邀请并建立会话并不能保证媒体能够成功传输。（这类似于如果成功接受SIP邀请，则不能保证音频硬件不会出现后续故障）。
The particular requirements of PINT users lead to some new messages. When a PINT server agrees to send a fax to telephone B, it may be that the fax transmission fails after part of the fax is sent. Therefore, the PINT client may wish to receive information about the status of the actual telephone call session that was invoked as a result of the established PINT session. Three new requests, SUBSCRIBE, UNSUBSCRIBE, and NOTIFY, are added here to vanilla SIP to allow this.
PINT用户的特殊要求导致了一些新消息。当PINT服务器同意向电话B发送传真时，可能是部分传真发送后传真传输失败。因此，PINT客户端可能希望接收关于作为所建立的PINT会话的结果而被调用的实际电话呼叫会话的状态的信息。三个新的请求，订阅、取消订阅和通知，在这里被添加到vanilla SIP以允许这样做。
The enhancements and additions specified here are not intended to alter the behaviour of baseline SIP or SDP in any way. The purpose of PINT extensions is to extend the usual SIP/SDP services to the telephone world. Apart from integrating well into existing protocols and architectures, and the advantages of reuse, this means that the protocol specified here can handle a rather wider class of call services than just the Milestone services.
此处指定的增强和添加并非旨在以任何方式改变基线SIP或SDP的行为。PINT扩展的目的是将通常的SIP/SDP服务扩展到电话世界。除了很好地集成到现有协议和体系结构中以及重用的优点之外，这意味着这里指定的协议可以处理比里程碑服务更广泛的呼叫服务类。
The rest of this document is organised as follows: Section 2 describes the PINT Milestone services; section 3 specifies the PINT functional and protocol architecture; section 4 gives examples of the PINT 1.0 extensions of SIP and SDP; section 5 contains some security considerations for PINT. The final section contains descriptions of how the PINT protocol may be used to provide service over the GSTN.
本文件的其余部分组织如下：第2节描述了PINT里程碑服务；第3节规定了PINT功能和协议架构；第4节给出了SIP和SDP的PINT 1.0扩展示例；第5节包含PINT的一些安全注意事项。最后一节描述了如何使用PINT协议通过GSTN提供服务。
For a summary of the extensions to SIP and SDP specified in this document, Section 3.2 gives an combined list, plus one each describing the extensions to SIP and SDP respectively.
对于本文件中规定的SIP和SDP扩展的总结，第3.2节给出了一个组合列表，以及一个分别描述SIP和SDP扩展的列表。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. In addition,
the construct "MUST .... OR ...." implies that it is an absolute
requirement of this specification to implement one of the two
possibilities stated (represented by dots in the above phrase). An
implementation MUST be able to interoperate with another
implementation that chooses either of the two possibilities.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. In addition,
the construct "MUST .... OR ...." implies that it is an absolute
requirement of this specification to implement one of the two
possibilities stated (represented by dots in the above phrase). An
implementation MUST be able to interoperate with another
implementation that chooses either of the two possibilities.
Requestor - An Internet host from which a request for service originates
请求者-服务请求发起的Internet主机
PINT Service - A service invoked within a phone system in response to a request received from an PINT client.
PINT服务-在电话系统中响应从PINT客户端接收的请求而调用的服务。
PINT Client - An Internet host that sends requests for invocation of a PINT Service, in accordance with this document.
PINT客户端-根据本文档发送调用PINT服务请求的互联网主机。
PINT Gateway - An Internet host that accepts requests for PINT Service and dispatches them onwards towards a telephone network.
PINT网关-一个互联网主机，它接受PINT服务请求并将其发送到电话网络。
Executive System - A system that interfaces to a PINT Server and to a telephone network that executes a PINT service. It need not be directly associated with the Internet, and is represented by the PINT Server in transactions with Internet entities.
执行系统-与PINT服务器和执行PINT服务的电话网络连接的系统。它不需要与Internet直接关联，在与Internet实体的事务中由PINT服务器表示。
Requesting User - The initiator of a request for service. This role may be distinct from that of the "party" to any telephone network call that results from the request.
请求用户-服务请求的发起人。此角色可能不同于请求产生的任何电话网络呼叫的“一方”。
(Service Call) Party - A person who is involved in a telephone network call that results from the execution of a PINT service request, or a telephone network-based resource that is involved (such as an automatic Fax Sender or a Text-to-Speech Unit).
（服务呼叫）方-参与因执行PINT服务请求而产生的电话网络呼叫的人员，或参与的基于电话网络的资源（如自动传真发送器或文本语音转换单元）。
The original motivation for defining this protocol was the desire to invoke the following three telephone network services from within an IP network:
定义此协议的最初动机是希望从IP网络中调用以下三种电话网络服务：
A request is sent from an IP host that causes a phone call to be made, connecting party A to some remote party B.
从IP主机发送请求，导致进行电话呼叫，将甲方连接到某个远程乙方。
A request is sent from an IP host that causes a fax to be sent to fax machine B. The request MAY contain a pointer to the fax data (that could reside in the IP network or in the Telephone Network), OR the fax data itself. The content of the fax MAY be text OR some other more general image data. The details of the fax transmission are not accessible to the IP network, but remain entirely within the telephone network.
从IP主机发送的请求导致传真发送到传真机B。该请求可能包含指向传真数据（可能位于IP网络或电话网络中）或传真数据本身的指针。传真的内容可以是文本或一些其他更一般的图像数据。IP网络无法访问传真传输的详细信息，但仍完全在电话网络中。
Note that this service does not relate to "Fax over IP": the IP network is only used to send the request that a certain fax be sent. Of course, it is possible that the resulting telephone network fax call happens to use a real-time IP fax solution, but this is completely transparent to the PINT transaction.
请注意，此服务与“IP传真”无关：IP网络仅用于发送发送特定传真的请求。当然，产生的电话网络传真呼叫可能恰好使用实时IP传真解决方案，但这对PINT事务是完全透明的。
A request is sent from an IP host that causes a phone call to be made to user A, and for some sort of content to be spoken out. The request MUST EITHER contain a URL pointing to the content, OR include the content itself. The content MAY be text OR some other more general application data. The details of the content transmission are not accessible to the IP network, but remain entirely within the telephone network. This service could equally be called "Request to Hear Content"; the user's goal is to hear the content spoken to them. The mechanism by which the request is formulated is outside the scope of this document; however, an example might be that a Web page has a button that when pressed causes a PINT request to be passed to the PSTN, resulting in the content of the page (or other details) being spoken to the person.
从IP主机发送一个请求，该请求会导致向用户A打电话，并发出某种内容。请求必须包含指向内容的URL，或者包含内容本身。内容可以是文本或一些其他更一般的应用程序数据。IP网络无法访问内容传输的详细信息，但仍完全在电话网络中。这项服务同样可以称为“听取内容请求”；用户的目标是听到与他们交谈的内容。提出请求的机制不在本文件范围内；然而，一个例子可能是网页上有一个按钮，按下该按钮时会导致一个PINT请求被传递到PSTN，从而导致该网页的内容（或其他细节）被告知该人。
2.4 Relation between PINT milestone services and traditional telephone services
2.4 PINT里程碑业务与传统电话业务的关系
There are many different versions and variations of each telephone call service invoked by a PINT request. Consider as an example what happens when a user requests to call 1-800-2255-287 via the PINT Request-to-Call service.
PINT请求调用的每个电话呼叫服务都有许多不同的版本和变体。作为一个例子，当用户请求通过呼叫请求的PoT请求调用1-800—2255-87时发生了什么。
There may be thousands of agents in the call center, and there may be any number of sophisticated algorithms and pieces of equipment that are used to decide exactly which agent will return the call. And once
呼叫中心中可能有数千名代理，并且可能有任意数量的复杂算法和设备用于确定哪个代理将返回呼叫。一次
this choice is made, there may be many different ways to set up the call: the agent's phone might ring first, and only then the original user will be called; or perhaps the user might be called first, and hear some horrible music or pre-recorded message while the agent is located.
如果做出这种选择，可能会有许多不同的方式来设置呼叫：代理的电话可能会先响，然后才会呼叫原始用户；或者，用户可能会首先被呼叫，并在代理定位时听到一些可怕的音乐或预先录制的消息。
Similarly, when a PINT request causes a fax to be sent, there are hundreds of fax protocol details to be negotiated, as well as transmission details within the telephone networks used.
类似地，当PINT请求导致发送传真时，需要协商数百个传真协议细节，以及所用电话网络内的传输细节。
PINT requests do not specify too precisely the exact telephone-side service. Operational details of individual events within the telephone network that executes the request are outside the scope of PINT. This does not preclude certain high-level details of the telephone network session from being expressed within a PINT request. For example, it is possible to use the SDP "lang" attribute to express a language preference for the Request-to-Hear-Content Service. If a particular PINT system wishes to allow requests to contain details of the telephone-network-side service, it uses the SDP attribute mechanism (see section 3.4.2).
品脱请求没有太精确地指定确切的电话端服务。执行请求的电话网络内的单个事件的操作细节不在PINT的范围内。这并不排除在PINT请求中表达电话网络会话的某些高级细节。例如，可以使用SDP“lang”属性来表示请求收听内容服务的语言偏好。如果特定PINT系统希望允许请求包含电话网络端服务的详细信息，则使用SDP属性机制（见第3.4.2节）。
Familiarity is assumed with SIP 2.0 [1] and with SDP [2].
假设熟悉SIP 2.0[1]和SDP[2]。
PINT clients and servers are SIP clients and servers. SIP is used to carry the request over the IP network to the correct PINT server in a secure and reliable manner, and SDP is used to describe the telephone network session that is to be invoked or whose status is to be returned.
PINT客户端和服务器是SIP客户端和服务器。SIP用于通过IP网络以安全可靠的方式将请求传送到正确的PINT服务器，SDP用于描述要调用或要返回其状态的电话网络会话。
A PINT system uses SIP proxy servers and redirect servers for their usual purpose, but at some point there must be a PINT server with the means to relay received requests into a telephone system and to receive acknowledgement of these relayed requests. A PINT server with this capability is called a "PINT gateway". A PINT gateway appears to a SIP system as a User Agent Server. Notice that a PINT gateway appears to the PINT infrastructure as if it represents a "user", while in fact it really represents an entire telephone network infrastructure that can provide a set of telephone network services.
PINT系统通常使用SIP代理服务器和重定向服务器，但在某些情况下，PINT服务器必须能够将接收到的请求中继到电话系统中，并接收对这些中继请求的确认。具有此功能的PINT服务器称为“PINT网关”。PINT网关在SIP系统中显示为用户代理服务器。请注意，PINT网关在PINT基础设施中看起来好像代表一个“用户”，而实际上它实际上代表了一个可以提供一组电话网络服务的整个电话网络基础设施。
So the PINT system might appear to an individual PINT client as follows:
因此，PINT系统可能对单个PINT客户端显示如下：
/\/\/\/\/\/\/\ /\/\/\/\/\/\/\/\
___________ \ __/___ ___\_ \
| PINT | PINT \ PINT | PINT | |Exec| Telephone /
| client |<-------------->| server |gatewy|=====|Syst| Network \
|_________| protocol / cloud |______| |____| Cloud /
\ \ / \
/\/\/\/\/\/\/\ \/\/\/\/\/\/\/\/
/\/\/\/\/\/\/\ /\/\/\/\/\/\/\/\
___________ \ __/___ ___\_ \
| PINT | PINT \ PINT | PINT | |Exec| Telephone /
| client |<-------------->| server |gatewy|=====|Syst| Network \
|_________| protocol / cloud |______| |____| Cloud /
\ \ / \
/\/\/\/\/\/\/\ \/\/\/\/\/\/\/\/
Figure 1: PINT Functional Architecture
图1:PINT功能架构
The system of PINT servers is represented as a cloud to emphasise that a single PINT request might pass through a series of location servers, proxy servers, and redirect servers, before finally reaching the correct PINT gateway that can actually process the request by passing it to the Telephone Network Cloud.
PINT服务器系统被表示为一个云，以强调单个PINT请求可能会通过一系列位置服务器、代理服务器和重定向服务器，然后最终到达正确的PINT网关，该网关可以通过将请求传递到电话网络云来实际处理请求。
The PINT gateway might have a true telephone network interface, or it might be connected via some other protocol or API to an "Executive System" that is capable of invoking services within the telephone cloud.
PINT网关可能有一个真正的电话网络接口，也可能通过其他协议或API连接到能够调用电话云中服务的“执行系统”。
As an example, within an I.N. (Intelligent Network) system, the PINT gateway might appear to realise the Service Control Gateway Function. In an office environment, it might be a server adjunct to the office PBX, connected to both the office LAN and the office PBX.
例如，在I.N.（智能网络）系统中，PINT网关可能实现服务控制网关功能。在办公环境中，它可能是办公PBX的服务器附件，连接到办公LAN和办公PBX。
The Executive System that lies beyond the PINT gateway is outside the scope of PINT.
PINT网关之外的执行系统不在PINT范围内。
This section explains how SIP and SDP work in combination to convey the information necessary to invoke telephone network sessions.
本节介绍SIP和SDP如何结合使用，以传递调用电话网络会话所需的信息。
The following list summarises the extension features used in PINT 1.0. Following on from this the features are considered separately for SDP and then for SIP:
下表总结了PINT 1.0中使用的扩展功能。在此基础上，分别考虑SDP和SIP的功能：
1) Telephony URLs in SDP Contact Fields 2) Refinement of SIP/SDP Telephony URLs * Inclusion of private dialling plans 3) Specification of Telephone Service Provider (TSP) and/or phone-context URL-parameters 4) Data Objects as session media
1) SDP联系人字段中的电话URL 2）SIP/SDP电话URL的细化*包括私人拨号计划3）电话服务提供商（TSP）和/或电话上下文URL参数的规范4）作为会话介质的数据对象
4a) Protocol Transport formats to indicate the treatment of the media within the GSTN 5) Implicit (Indirect) media streams and opaque arguments 6) In-line data objects using multipart/mime 7) Refinement/Clarification of Opaque arguments passed onwards to Executive Systems * Framework for Presentation Restriction Indication * Framework for Q.763 arguments 8) An extension mechanism for SDP to specify strictures and force failure when a recipient does NOT support the specified extensions, using "require" headers. 9) Mandatory support for "Warning" headers to give more detailed information on request disposition. 10) Mechanism to register interest in the disposition of a requested service, and to receive indications on that disposition.
4a）协议传输格式，用于指示GSTN内介质的处理方式5）隐式（间接）媒体流和不透明参数6）使用多部分/mime的内嵌数据对象7）对传递给执行系统的不透明参数进行细化/澄清*表示限制指示框架*Q.763参数框架8）SDP的扩展机制，用于指定限制，并在接收者未指定时强制失败使用“require”标题支持指定的扩展。9） 强制支持“警告”标题，以提供有关请求处理的更详细信息。10） 注册所请求服务的处置权益并接收该处置指示的机制。
Both PINT and SIP rely on features of MIME[4]. The use of SIP 2.0 is implied by PINT 1.0, and this also implies compliance with version 1.0 of MIME.
PINT和SIP都依赖MIME的特性[4]。PINT 1.0暗示了SIP 2.0的使用，这也意味着符合MIME的1.0版本。
The SDP payload contains a description of the particular telephone network session that the requestor wishes to occur in the GSTN. This information includes such things as the telephone network address (i.e. the "telephone number") of the terminal(s) involved in the call, an indication of the media type to be transported (e.g. audio, text, image or application data), and an indication if the information is to be transported over the telephone network via voice, fax, or pager transport. An indication of the content to be sent to the remote telephone terminal (if there is any) is also included.
SDP有效负载包含请求者希望在GSTN中发生的特定电话网络会话的描述。该信息包括呼叫中涉及的终端的电话网络地址（即“电话号码”），要传输的媒体类型指示（例如音频、文本、图像或应用程序数据），以及是否通过语音、传真通过电话网络传输信息的指示，或寻呼机传输。还包括要发送到远程电话终端（如果有）的内容指示。
SDP is flexible enough to convey these parameters independently. For example, a request to send some text via voice transport will be fulfilled by invoking some text-to-speech-over-the-phone service, and a request to send text via fax will be fulfilled by invoking some text-to-fax service.
SDP足够灵活，可以独立地传递这些参数。例如，通过语音传输发送某些文本的请求将通过电话服务调用某些文本到语音来实现，通过传真发送文本的请求将通过调用某些文本到传真服务来实现。
The following is a list of PINT 1.0 enhancements and additions to SDP.
以下是对SDP的PINT 1.0增强和添加的列表。
a. A new network type "TN" and address types "RFC2543" and "X-..." (section 3.4.1) b. New media types "text", "image", and "application", new protocol transport keywords "voice", "fax" and "pager" and the associated format types and attribute tags (section 3.4.2)
a. 新的网络类型“TN”和地址类型“RFC2543”和“X-…”（第3.4.1节）b。新媒体类型“文本”、“图像”和“应用”，新协议传输关键词“语音”、“传真”和“寻呼机”，以及相关格式类型和属性标签（第3.4.2节）
c. New format specific attributes for included content data (section 3.4.2.4) d. New attribute tags, used to pass information to the telephone network (section 3.4.3) e. A new attribute tag "require", used by a client to indicate that some attribute is required to be supported in the server (section 3.4.4)
c. 包含内容数据的新格式特定属性（第3.4.2.4节）d。新的属性标签，用于将信息传递到电话网络（第3.4.3节）e。一个新的属性标签“require”，客户端使用该标签表示服务器中需要支持某些属性（第3.4.4节）
SIP is used to carry the request for telephone service from the PINT client to the PINT gateway, and may include a telephone number if needed for the particular service. The following is a complete list of PINT enhancements and additions to SIP:
SIP用于将电话服务请求从PINT客户端传送到PINT网关，如果特定服务需要，还可以包括电话号码。以下是对SIP的品脱增强和添加的完整列表：
f. The multipart MIME payloads (section 3.5.1) g. Mandatory support for "Warning:" headers (section 3.5.2) h. The SUBSCRIBE and NOTIFY, and UNSUBSCRIBE requests (section 3.5.3) i. Require: headers (section 3.5.4) j. A format for PINT URLS within a PINT request (section 3.5.5) k. Telephone Network Parameters within PINT URLs (section 3.5.6)
f. 多部分MIME有效载荷（第3.5.1节）g。强制支持“警告：”标题（第3.5.2节）h。订阅、通知和取消订阅请求（第3.5.3节）i。要求：标题（第3.5.4节）j。PINT请求中PINT URL的格式（第3.5.5节）k。PINT URL内的电话网络参数（第3.5.6节）
Section 3.5.8 contains remarks about how BYE requests are used within PINT. This is not an extension to baseline SIP; it is included here only for clarification of the semantics when used with telephone network sessions.
第3.5.8节包含关于如何在品脱中使用BYE请求的备注。这不是对基线SIP的扩展；这里包含它只是为了澄清与电话网络会话一起使用时的语义。
Of these, only the TN network type (with its associated RFC2543 address type) and the "require" attribute MUST be supported by PINT 1.0 clients and servers. In practice, most PINT service requests will use other changes, of which references to Data Objects in requests are most likely to appear in PINT requests.
其中，PINT 1.0客户端和服务器只能支持TN网络类型（及其关联的RFC2543地址类型）和“require”属性。实际上，大多数PINT服务请求将使用其他更改，其中对请求中数据对象的引用最有可能出现在PINT请求中。
Each of the other new PINT constructs enables a different function, and a client or server that wishes to enable that particular function MUST do so by the construct specified in this document. For example, building a PINT client and server that provide only the Request-to-Call telephone call service, without support for the other Milestone services, is allowed.
其他每个新的PINT构造都启用不同的功能，希望启用该特定功能的客户端或服务器必须通过本文档中指定的构造来实现。例如，可以构建一个PINT客户端和服务器，该客户端和服务器只提供请求呼叫电话服务，而不支持其他里程碑服务。
The "Require:" SIP header and the "require" attribute provide a mechanism that can be used by clients and servers to signal their need and/or ability to support specific "new" PINT protocol elements.
“Require:”SIP头和“Require”属性提供了一种机制，客户机和服务器可以使用该机制来表示其需要和/或支持特定“新”PINT协议元素的能力。
It should be noted that many optional features of SIP and SDP make sense as specified in the PINT context. One example is the SDP a=lang: attribute, which can be used to describe the preferred language of the callee. Another example is the use of the "t=" parameter to indicate that the time at which the PINT service is to be invoked. This is the normal use of the "t=" field. A third example is the quality attributes. Any SIP or SDP option or facility is available to PINT clients and servers without change.
应该注意的是，SIP和SDP的许多可选特性在PINT上下文中是有意义的。一个例子是SDP a=lang:attribute，它可以用来描述被调用方的首选语言。另一个例子是使用“t=”参数指示调用PINT服务的时间。这是“t=”字段的正常用法。第三个例子是质量属性。PINT客户端和服务器无需更改即可使用任何SIP或SDP选项或设施。
Conversely, support for Data Objects within Internet Conference sessions may be useful, even if the aim is not to provide a GSTN service request. In this case, the extensions covering these items may be incorporated into an otherwise "plain" SIP/SDP invitation. Likewise, support for SDP "require" may be useful, as a framework for addition of features to a "traditional" SIP/SDP infrastructure. Again, these may be convenient to incorporate into SIP/SDP implementations that would not be used for PINT service requests. Such additions are beyond the scope of this document, however.
相反，即使目的不是提供GSTN服务请求，对Internet会议会话中的数据对象的支持也可能有用。在这种情况下，覆盖这些项目的扩展可以合并到其他“普通”SIP/SDP邀请中。类似地，对SDP“require”的支持可能很有用，可以作为向“传统”SIP/SDP基础设施添加功能的框架。同样，可以方便地将它们合并到不会用于PINT服务请求的SIP/SDP实现中。然而，此类添加超出了本文件的范围。
PINT 1.0 adds to SDP the possibility to describe audio, fax, and pager telephone sessions. It is deliberately designed to hide the underlying technical details and complexity of the telephone network. The only network type defined for PINT is the generic "TN" (Telephone Network). More precise tags such as "ISDN", "GSM", are not defined. Similarly, the transport protocols are designated simply as "fax", "voice", and "pager"; there are no more specific identifiers for the various telephone network voice, fax, or pager protocols. Similarly, the data to be transported are identified only by a MIME content type, such as "text" data, "image" data, or some more general "application" data. An important example of transporting "application" data is the milestone service "Voice Access to Web Content". In this case the data to be transported are pointed to by a URI, the data content type is application/URI, and the transport protocol would be "voice". Some sort of speech-synthesis facility, speaking out to a Phone, will have to be invoked to perform this service.
品脱1.0为SDP增加了描述音频、传真和寻呼机电话会话的可能性。它被故意设计来隐藏电话网络的潜在技术细节和复杂性。为PINT定义的唯一网络类型是通用的“TN”（电话网络）。没有定义更精确的标签，如“ISDN”、“GSM”。类似地，传输协议被简单地指定为“传真”、“语音”和“寻呼机”；各种电话网络语音、传真或寻呼机协议没有更具体的标识符。类似地，要传输的数据仅由MIME内容类型标识，例如“文本”数据、“图像”数据或一些更一般的“应用程序”数据。传输“应用程序”数据的一个重要示例是里程碑服务“Web内容语音访问”。在这种情况下，要传输的数据由URI指向，数据内容类型为application/URI，传输协议为“voice”。为了执行这项服务，必须调用某种语音合成功能，向电话讲话。
This section gives details of the new SDP keywords.
本节提供了新SDP关键字的详细信息。
The TN ("Telephone Network") network type is used to indicate that the terminal is connected to a telephone network.
TN（“电话网络”）网络类型用于指示终端连接到电话网络。
The address types allowed for network type TN are "RFC2543" and private address types, which MUST begin with an "X-".
网络类型TN允许的地址类型为“RFC2543”和专用地址类型，必须以“X-”开头。
Address type RFC2543 is followed by a string conforming to a subset of the "telephone-subscriber" BNF specified in figure 4 of SIP [1]). Note that this BNF is NOT identical to the BNF that defines the "phone-number" within the "p=" field of SDP.
地址类型RFC2543后面是符合SIP[1]图4中规定的“电话用户”BNF子集的字符串。请注意，此BNF与在SDP的“p=”字段中定义“电话号码”的BNF不同。
Examples:
示例：
c= TN RFC2543 +1-201-406-4090
c=TN RFC2543+1-201-406-4090
c= TN RFC2543 12014064090
c=TN RFC2543 12014064090
A telephone-subscriber string is of one of two types: global-phone-number or local-phone-number. These are distinguished by preceeding a global-phone-number with a "plus" sign ("+"). A global-phone-number is by default to be interpreted as an internationally significant E.164 Number Plan Address, as defined by [6], whilst a local-phone-number is a number specified in the default dialling plan within the context of the recipient PINT Gateway.
电话用户字符串有两种类型：全局电话号码或本地电话号码。通过在全球电话号码前面加上加号（“+”）来区分这些号码。根据[6]的定义，默认情况下，全局电话号码被解释为具有国际意义的E.164号码计划地址，而本地电话号码是在收件人PINT网关上下文中的默认拨号计划中指定的号码。
An implementation MAY use private addressing types, which can be useful within a local domain. These address types MUST begin with an "X-", and SHOULD contain a domain name after the X-, e.g. "X-mytype.mydomain.com". An example of such a connection line is as follows:
实现可以使用私有寻址类型，这在本地域中很有用。这些地址类型必须以“X-”开头，并且应该在X-”后面包含域名，例如“X-mytype.mydomain.com”。此类连接线的示例如下所示：
c= TN X-mytype.mydomain.com A*8-HELEN
c=TN X-mytype.mydomain.com A*8-1
where "X-mytype.mydomain.com" identifies this private address type, and "A*8-HELEN" is the number in this format. Such a format is defined as an "OtherAddr" in the ABNF of Appendix A. Note that most dialable telephone numbers are expressable as local-phone-numbers within address RFC2543; new address types SHOULD only be used for formats which cannot be so written.
其中“X-mytype.mydomain.com”标识此专用地址类型，“A*8-HELEN”是此格式的数字。这种格式在附录a的ABNF中定义为“OtherAddr”。请注意，大多数可拨打电话号码可表示为地址RFC2543内的本地电话号码；新地址类型只能用于不能这样写的格式。
One significant change over traditional SIP/SDP Internet Conference sessions with PINT is that a PINT service request may refer to a Data Object to be used as source information in that request. For example, a PINT service request may specify a document to be processed as part of a GSTN service by which a Fax is sent. Similarly, a GSTN service may be take a Web page and result in a vocoder processing that page and speaking the contents over a telephone.
与使用PINT的传统SIP/SDP Internet会议会话相比，一个重要的变化是PINT服务请求可能引用一个数据对象，该数据对象将用作该请求中的源信息。例如，PINT服务请求可以指定要作为发送传真的GSTN服务的一部分处理的文档。类似地，GSTN服务可以接收网页并导致声码器处理该网页并通过电话说出内容。
The SDP specification does not have explicit support for reference to or carriage of Data Objects within requests. In order to use SDP for PINT, there is a need to describe such media sessions as "a telephone
SDP规范不明确支持在请求中引用或携带数据对象。为了将SDP用于品脱，需要将此类媒体会话描述为“电话”
call to a certain number during which such-and-such an image is sent as a fax".
打电话给某个号码，在此期间，某个或某个图像作为传真发送”。
To support this, two extensions to the session description format are specified. These are some new allowed values for the Media Field, and a description of the "fmtp" parameter when used with the Media Field values (within the context of the Contact Field Network type "TN").
为了支持这一点，对会话描述格式指定了两个扩展。这些是媒体字段的一些新允许值，以及与媒体字段值一起使用时“fmtp”参数的说明（在联系人字段网络类型“TN”的上下文中）。
An addition is also made to the SIP message format to allow the inclusion of data objects as sub-parts within the request message itself. The original SDP syntax (from [2]) for media-field is given as:
还对SIP消息格式进行了添加，以允许将数据对象作为子部分包含在请求消息本身中。媒体字段的原始SDP语法（来自[2]）如下所示：
media-field = "m=" media space port ["/" integer]
space proto 1*(space fmt) CRLF
media-field = "m=" media space port ["/" integer]
space proto 1*(space fmt) CRLF
When used within PINT requests, the definition of the sub-fields is expanded slightly. The Media sub-field definition is relaxed to accept all of the discrete "top-level" media types defined in [4]. In the milestone services the discrete type "video" is not used, and the extra types "data" and "control" are likewise not needed. The use of these types is not precluded, but the behaviour expected of a PINT Gateway receiving a request including such a type is not defined here.
在PINT请求中使用时，子字段的定义会稍微扩展。介质子字段定义放宽，以接受[4]中定义的所有离散“顶级”介质类型。在里程碑服务中，不使用离散类型的“视频”，也不需要额外类型的“数据”和“控制”。不排除使用这些类型，但此处未定义PINT网关接收包括此类类型的请求的预期行为。
The Port sub-field has no meaning in PINT requests as the destination terminals are specified using "TN" addressing, so the value of the port sub-field in PINT requests is normally set to "1". A value of "0" may be used as in SDP to indicate that the terminal is not receiving media. This is useful to indicate that a telephone terminal has gone "on hold" temporarily. Likewise, the optional integer sub-field is not used in PINT.
端口子字段在PINT请求中没有意义，因为目标终端是使用“TN”寻址指定的，因此PINT请求中端口子字段的值通常设置为“1”。在SDP中，值“0”可用于指示终端未接收媒体。这有助于指示电话终端暂时处于“暂停”状态。同样，PINT中不使用可选的整数子字段。
As mentioned in [2], the Transport Protocol sub-field is specific to the associated Address Type. In the case that the Address Type in the preceeding Contact field is one of those defined for use with the Network Type "TN", the following values are defined for the Transport Protocol sub-field:
如[2]所述，传输协议子字段特定于关联的地址类型。如果上述联系人字段中的地址类型是为与网络类型“TN”一起使用而定义的地址类型之一，则为传输协议子字段定义以下值：
"voice", "fax", and "pager".
“语音”、“传真”和“寻呼机”。
The interpretation of this sub-field within PINT requests is the treatment or disposition of the resulting GSTN service. Thus, for transport protocol "voice", the intent is that the service will result in a GSTN voice call, whilst for protocol "fax" the result will be a GSTN fax transmission, and protocol "pager" will result in a pager message being sent.
PINT请求中此子字段的解释是对生成的GSTN服务的处理或处置。因此，对于传输协议“语音”，目的是服务将导致GSTN语音呼叫，而对于协议“传真”，结果将是GSTN传真传输，而协议“寻呼机”将导致发送寻呼机消息。
Note that this sub-field does not necessarily dictate the media type and subtype of any source data; for example, one of the milestone services calls for a textual source to be vocoded and spoken in a resulting telephone service call. The transport protocol value in this case would be "voice", whilst the media type would be "text".
请注意，此子字段不一定指定任何源数据的媒体类型和子类型；例如，其中一个里程碑服务调用文本源，以便在生成的电话服务调用中进行声码和语音编码。在这种情况下，传输协议值为“语音”，而媒体类型为“文本”。
The Fmt sub-field is described in [2] as being transport protocol-specific. When used within PINT requests having one of the above protocol values, this sub-field consists of a list of one or more values, each of which is a defined MIME sub-type of the associated Media sub-field value. The special value "-" is allowed, meaning that there is no MIME sub-type. This sub-field retains (from [2]) its meaning that the list will contain a set of alternative sub-types, with the first being the preferred value.
[2]中将Fmt子字段描述为特定于传输协议。当在具有上述协议值之一的PINT请求中使用时，此子字段由一个或多个值的列表组成，每个值都是相关媒体子字段值的已定义MIME子类型。允许使用特殊值“-”，这意味着没有MIME子类型。此子字段保留（从[2]）其含义，即列表将包含一组备选子类型，第一个是首选值。
For experimental purposes and by mutual consent of the sender and recipient, a sub-type value may be specified as an <X-token>, i.e. a character string starting with "X-". The use of such values is discouraged, and if such a value is expected to find common use then it SHOULD be registered with IANA using the standard content type registration process (see Appendix C).
出于实验目的并经发送方和接收方双方同意，可以将子类型值指定为<X-token>，即以“X-”开头的字符串。不鼓励使用此类值，如果预计此类值将被普遍使用，则应使用标准内容类型注册流程向IANA注册（见附录C）。
When the Fmt parameter is the single character "-" ( a dash ), this is interpreted as meaning that a unspecified or default sub-type can be used for this service. Thus, the media field value "m=audio 1 voice -<CRLF>" is taken to mean that a voice call is requested, using whatever audio sub type is deemed appropriate by the Executive System. PINT service is a special case, in that the request comes from the IP network but the service call is provided within the GSTN. Thus the service request will not normally be able to define the particular codec used for the resulting GSTN service call. If such an intent IS required, then the quality attribute may be used (see "Suggested Attributes" section of [2]).
当Fmt参数为单字符“-”（破折号）时，这意味着未指定或默认的子类型可用于此服务。因此，媒体字段值“m=音频1语音-<CRLF>”被认为意味着使用执行系统认为合适的任何音频子类型请求语音呼叫。PINT服务是一种特殊情况，因为请求来自IP网络，但服务调用是在GSTN中提供的。因此，服务请求通常无法定义用于生成的GSTN服务调用的特定编解码器。如果需要这样的意图，则可以使用质量属性（参见[2]的“建议属性”一节）。
For each element of the Fmt sub-field, there MUST be a following fmtp attribute. When used within PINT requests, the fmtp attribute has a general structure as defined here:
对于Fmt子字段的每个元素，必须有以下fmtp属性。在PINT请求中使用时，fmtp属性具有如下定义的一般结构：
"a=fmtp:" <subtype> <space> resolution
*(<space> resolution)
(<space> ";" 1(<attribute>)
*(<space> <attribute>))
where:
<resolution> := (<uri-ref> | <opaque-ref> | <sub-part-ref>)
"a=fmtp:" <subtype> <space> resolution
*(<space> resolution)
(<space> ";" 1(<attribute>)
*(<space> <attribute>))
where:
<resolution> := (<uri-ref> | <opaque-ref> | <sub-part-ref>)
A fmtp attribute describes the sources used with a given Fmt entry in the Media field. The entries in a Fmt sub-field are alternatives (with the preferred one first in the list). Each entry will have a matching fmtp attribute. The list of resolutions in a fmtp attribute describes the set of sources that resolve the matching Fmt choice; all elements of this set will be used.
fmtp属性描述与媒体字段中给定Fmt条目一起使用的源。Fmt子字段中的条目是备选项（首选项位于列表的第一位）。每个条目都有一个匹配的fmtp属性。fmtp属性中的分辨率列表描述解析匹配Fmt选择的源集合；将使用此集合的所有元素。
It should be noted that, for use in PINT services, the elements in such a set will be sent as a sequence; it is unlikely that trying to send them in parallel would be successful.
应注意，对于PINT服务中的使用，此类集合中的元素将作为序列发送；试图将它们并行发送是不可能成功的。
A fmtp attribute can contain a mixture of different kinds of element. Thus an attribute might contain a sub-part-ref indicating included data held in a sub-part of the current message, followed by an opaque-ref referring to some content on the GSTN, followed by a uri-ref pointing to some data held externally on the IP network.
fmtp属性可以包含不同类型元素的混合。因此，属性可能包含一个子部分ref，该子部分ref指示当前消息的子部分中包含的数据，后跟一个不透明ref，该不透明ref表示GSTN上的某些内容，后跟一个uri ref，该uri ref指向IP网络外部保存的一些数据。
To indicate which form each resolution element takes, each of them starts with its own literal tag. The detailed syntax of each form is described in the following sub-sections.
为了指示每个解析元素采用哪种形式，每个解析元素都以自己的文本标记开始。每个表单的详细语法将在以下小节中描述。
Where data objects stored elsewhere on the IP Network are to be used as sources for processing within a PINT service, they may be referred to using the uri-ref form. This is simply a Uniform Resource Identifier (URI), as described in [9].
如果存储在IP网络上其他位置的数据对象将用作PINT服务内处理的源，则可以使用uri ref表单来引用它们。这只是一个统一资源标识符（URI），如[9]所述。
Note that the reference SHOULD be an absolute URI, as there may not be enough contextual information for the recipient server to resolve a relative reference; any use of relative references requires some private agreement between the sender and recipient of the message, and SHOULD be avoided unless the sender can be sure that the recipient is the one intended and the reference is unambiguous in context.
注意，引用应该是绝对URI，因为可能没有足够的上下文信息供接收方服务器解析相对引用；任何相对引用的使用都需要消息的发送者和接收者之间达成某种私人协议，除非发送者能够确保接收者是预期的接收者，并且引用在上下文中是明确的，否则应该避免使用相对引用。
This also holds for partial URIs (such as"uri:http://aNode/index.htm") as these will need to be resolved in the context of the eventual recipient of the message.
这也适用于部分uri（例如“uri:http://aNode/index.htm），因为这些问题需要在邮件最终收件人的上下文中解决。
The general syntax of a reference to an Internet-based external data object in a fmtp line within a PINT session description is:
PINT会话描述中fmtp行中对基于Internet的外部数据对象的引用的一般语法为：
<uri-ref> := ("uri:" URI-reference)
<uri-ref> := ("uri:" URI-reference)
where URI-reference is as defined in Appendix A of [9]
其中URI引用如[9]附录A中所定义
For example:
例如：
c= TN RFC2543 +1-201-406-4090
m= text 1 fax plain
a=fmtp:plain uri:ftp://ftp.isi.edu/in-notes/rfc2468.txt
or:
c= TN RFC2543 +1-201-406-4090
m= text 1 fax plain
a=fmtp:plain
uri:http://www.ietf.org/meetings/glance_minneapolis.txt
c= TN RFC2543 +1-201-406-4090
m= text 1 fax plain
a=fmtp:plain uri:ftp://ftp.isi.edu/in-notes/rfc2468.txt
or:
c= TN RFC2543 +1-201-406-4090
m= text 1 fax plain
a=fmtp:plain
uri:http://www.ietf.org/meetings/glance_minneapolis.txt
means get this data object from the Internet and use it as a source for the requested GSTN Fax service.
表示从Internet获取此数据对象，并将其用作请求的GSTN传真服务的源。
PINT services may refer to data that are held not on the IP Network but instead within the GSTN. The way in which these items are indicated need have no meaning within the context of the Requestor or the PINT Gateway; the reference is merely some data that may be used by the Executive System to indicate the content intended as part of the request. These data form an opaque reference, in that they are sent "untouched" through the PINT infrastructure.
PINT服务可能指的是不在IP网络上而是在GSTN内保存的数据。指示这些项目的方式在请求者或PINT网关的上下文中没有意义；参考仅仅是一些数据，执行系统可以使用这些数据来指示作为请求一部分的内容。这些数据形成一个不透明的引用，因为它们通过PINT基础设施“未被触及”地发送。
A reference to some data object held on the GSTN has the general definition:
对GSTN上某些数据对象的引用具有一般定义：
<opaque-ref> := ("opr:" *uric)
<opaque-ref> := ("opr:" *uric)
where uric is as defined in Appendix A of [9].
其中，尿酸定义见[9]附录A。
For example:
例如：
c= TN RFC2543 +1-201-406-4090
m= text 1 fax plain
a=fmtp:plain opr:APPL.123.456
c= TN RFC2543 +1-201-406-4090
m= text 1 fax plain
a=fmtp:plain opr:APPL.123.456
means send the data that is indexed ON THE GSTN by the reference value "APPL.123.456" to the fax machine on +1-201-406-4090. The Executive System may also take the Telephone URL held in the To: field of the enclosing SIP message into account when deciding the context to be used for the data object dereference.
是指将GSTN上索引为参考值“APPL.123.456”的数据发送至+1-201-406-4090上的传真机。在决定用于数据对象解引用的上下文时，执行系统还可以考虑包含在SIP消息的To:字段中的电话URL。
Of course, an opaque reference may also be used for other purposes; it could, for example, be needed to authorise access to a document held on the GSTN rather than being required merely to disambiguate
当然，不透明的引用也可以用于其他目的；例如，可能需要授权访问GSTN上持有的文件，而不仅仅是为了消除歧义
the data object. The purpose to which an opaque reference is put, however, is out of scope for this document. It is merely an indicator carried within a PINT Request.
数据对象。然而，不透明引用的目的超出了本文件的范围。它只是一品脱请求中携带的指示器。
An opaque reference may have no value in the case where the value to be used is implicit in the rest of the request. For example, suppose some company wishes to use PINT to implement a "fax-back service". In their current implementation, the image(s) to be faxed are entirely defined by the telephone number dialled. Within the PINT request, this telephone number would appear within the "To:" field of the PINT request, and so there is no need for an opaque reference value.
如果要使用的值在请求的其余部分中是隐式的，则不透明引用可能没有值。例如，假设一些公司希望使用PINT实现“传真回服务”。在它们当前的实现中，要传真的图像完全由所拨打的电话号码定义。在PINT请求中，此电话号码将显示在PINT请求的“收件人：”字段中，因此不需要不透明的参考值。
If there are several resolutions for a PINT Service Request, and one of these is an opaque reference with no value, then that opaque reference MUST be included in the attribute line, but with an empty value field.
如果PINT服务请求有多个解析，其中一个是不带值的不透明引用，则该不透明引用必须包含在属性行中，但带有空值字段。
For example:
例如：
c= TN RFC2543 +1-201-406-4090 m= text 1 fax plain a=fmtp:plain uri:http://www.sun.com/index.html opr:
c=TN RFC2543+1-201-406-4090 m=text 1传真普通a=fmtp:普通uri:http://www.sun.com/index.html opr：
might be used to precede some data to be faxed with a covering note.
可用于将某些数据与附页通知一起传真之前。
In the special case where an opaque reference is the sole resolution of a PINT Service Request, AND that reference needs no value, there is no need for a Fmt list at all; the intent of the service is unambiguous without any further resolution.
在特殊情况下，不透明引用是PINT服务请求的唯一解决方案，且该引用不需要值，则根本不需要Fmt列表；服务的意图是明确的，没有任何进一步的解决方案。
For example:
例如：
c= TN RFC2543 +1-201-406-4090
m= text 1 fax -
c= TN RFC2543 +1-201-406-4090
m= text 1 fax -
means that there is an implied content stored on the GSTN, and that this is uniquely identified by the combination of SIP To-URI and the Contact field of the session description.
意味着GSTN上存储有隐含内容，并且通过SIP到URI和会话描述的联系人字段的组合来唯一标识。
As an alternative to pointing to the data via a URI or an opaque reference to a data item held on the GSTN, it is possible to include the content data within the SIP request itself. This is done by using multipart MIME for the SIP payload. The first MIME part contains the SDP description of the telephone network session to be executed. The other MIME parts contain the content data to be transported.
作为通过URI或对GSTN上保存的数据项的不透明引用指向数据的替代方法，可以在SIP请求本身中包含内容数据。这是通过对SIP负载使用多部分MIME实现的。第一个MIME部分包含要执行的电话网络会话的SDP描述。其他MIME部分包含要传输的内容数据。
Format specific attribute lines within the session description are used to indicate which other MIME part within the request contains the content data. Instead of a URI or opaque reference, the format-specific attribute indicates the Content-ID of the MIME part of the request that contains the actual data, and is defined as:
会话描述中特定于格式的属性行用于指示请求中包含内容数据的其他MIME部分。与URI或不透明引用不同，format-specific属性指示包含实际数据的请求MIME部分的内容ID，并定义为：
<sub-part-ref> := ("spr:" Content-ID)
<sub-part-ref> := ("spr:" Content-ID)
where Content-ID is as defined in Appendix A of [3] and in [10]).
其中，内容ID的定义见[3]附录A和[10]）。
For example:
例如：
c= TN RFC2543 +1-201-406-4090
m= text 1 fax plain
a=fmtp:plain spr:<Content-ID>
c= TN RFC2543 +1-201-406-4090
m= text 1 fax plain
a=fmtp:plain spr:<Content-ID>
The <Content-ID> parameter is the Content-ID of one of the MIME parts inside the message, and this fragment means that the requesting user would like the data object held in the sub-part of this message labelled <Content-ID> to be faxed to the machine at phone number +1- 201-406-4090.
<Content ID>参数是消息中一个MIME部分的内容ID，此片段表示请求用户希望将此消息子部分中标记为<Content ID>的数据对象传真到电话号码为+1-201-406-4090的机器。
See also section 3.5.1 for a discussion on the support needed in the enclosing SIP request for included data objects.
另请参见第3.5.1节，以了解关于包含数据对象的随附SIP请求所需支持的讨论。
It may be desired to include within the PINT request service parameters that can be understood only by some entity in the "Telephone Network Cloud". SDP attribute parameters are used for this purpose. They MAY appear within a particular media description or outside of a media description.
可能希望在PINT请求服务参数中包含只能由“电话网络云”中的某些实体理解的参数。SDP属性参数用于此目的。它们可能出现在特定媒体描述内或媒体描述外。
These attributes may also appear as parameters within PINT URLS (see section 3.5.6) as part of a SIP request.
作为SIP请求的一部分，这些属性也可以作为PINT URL中的参数出现（参见第3.5.6节）。
This is necessary so that telephone terminals that require the attributes to be defined can appear within the To: line of a PINT request as well as within PINT session descriptions.
这是必要的，以便需要定义属性的电话终端可以出现在PINT请求的to:行以及PINT会话描述中。
The purpose of these attributes is to allow the client to specify extra context within which a particular telephone number is to be interpreted. There are many reasons why extra context might be necessary to interpret a given telephone number:
这些属性的目的是允许客户端指定解释特定电话号码的额外上下文。解释给定电话号码可能需要额外的上下文，原因有很多：
a. The telephone number might be reachable in many different ways (such as via competing telephone service providers), and the PINT client wishes to indicate its selection of service provider. b. The telephone number might be reachable only from a limited number of networks (such as an '800' freephone number). c. The telephone number might be reachable only within a single telephone network (such as the '152' customer service number of BT). Similarly, the number might be an internal corporate extension reachable only within the PBX.
a. 可以通过许多不同的方式（例如通过竞争的电话服务提供商）访问电话号码，PINT客户希望表明其对服务提供商的选择。B只能从有限数量的网络（如“800”免费电话号码）访问电话号码。C电话号码可能只能在单个电话网络中访问（例如BT的“152”客户服务号码）。类似地，该号码可能是只能在PBX内访问的内部公司扩展。
However, as noted above, it is not usually necessary to use SDP attributes to specify the phone context. URLs such as 152@pint.bt.co.il within the To: and From: headers and/or Request-URI, normally offer sufficient context to resolve telephone numbers.
但是，如上所述，通常不需要使用SDP属性来指定电话上下文。URL，例如152@pint.bt.co.il在To:和From:头和/或请求URI中，通常提供足够的上下文来解析电话号码。
If the client wishes the request to fail if the attributes are not supported, these attributes SHOULD be used in conjunction with the "require" attribute (section 3.4.4) and the "Require:org.ietf.sdp.require" header (section 3.5.4).
如果客户希望在属性不受支持的情况下请求失败，则这些属性应与“require”属性（第3.4.4节）和“require:org.ietf.sdp.require”标题（第3.5.4节）一起使用。
It is not possible to standardise every possible internal telephone network parameter. PINT 1.0 attributes have been chosen for specification because they are common enough that many different PINT systems will want to use them, and therefore interoperability will be increased by having a single specification.
不可能将所有可能的内部电话网络参数标准化。PINT 1.0属性之所以被选为规范，是因为它们非常常见，许多不同的PINT系统都想使用它们，因此通过使用单个规范可以提高互操作性。
Proprietary attribute "a=" lines, that by definition are not interoperable, may be nonetheless useful when it is necessary to transport some proprietary internal telephone network variables over the IP network, for example to identify the order in which service call legs are to be be made. These private attributes SHOULD BE, however, subject to the same IANA registration procedures mentioned in the SDP specification[2] (see also this Appendix C).
定义为不可互操作的专有属性“a=”线路，在需要通过IP网络传输某些专有内部电话网络变量时可能仍然有用，例如，用于确定进行服务呼叫分支的顺序。但是，这些私有属性应遵守SDP规范[2]中提到的相同IANA注册程序（另见附录C）。
An attribute is specified to enable "remote local dialling". This is the service that allows a PINT client to reach a number from far outside the area or network that can usually reach the number. It is useful when the sending or receiving address is only dialable within some local context, which may be remote to the origin of the PINT client.
指定了一个属性以启用“远程本地拨号”。这是一项服务，它允许PINT客户机从远离通常可以到达该号码的区域或网络的地方到达该号码。当发送或接收地址只能在某些本地上下文中拨号时，它非常有用，这些本地上下文可能是PINT客户端的远程来源。
For example, if Alice wanted to report a problem with her telephone, she might then dial a "network wide" customer care number; within the British Telecom network in the U.K., this is "152". Note that in this case she doesn't dial any trunk prefix - this is the whole dialable
例如，如果Alice想报告电话出现问题，她可能会拨打“网络范围”的客户服务号码；在英国的英国电信网络中，这是“152”。请注意，在这种情况下，她不拨任何中继前缀-这是整个可拨电话
number. If dialled from another operator's network, it will not connect to British Telecom's Engineering Enquiries service; and dialling "+44 152" will not normally succeed. Such numbers are called Network-Specific Service Numbers.
数字如果从其他运营商的网络拨号，它将无法连接到英国电信的工程咨询服务；而拨打“+44 152”通常不会成功。这些号码称为网络特定服务号码。
Within the telephone network, the "local context" is provided by the physical connection between the subscriber's terminal and the central office. An analogous association between the PINT client and the PINT server that first receives the request may not exist, which is why it may be necessary to supply this missing "telephone network context". This attribute is defined as follows:
在电话网络中，“本地上下文”由用户终端和中央办公室之间的物理连接提供。PINT客户端和首先接收请求的PINT服务器之间可能不存在类似的关联，这就是为什么可能需要提供缺少的“电话网络上下文”。该属性定义如下：
a=phone-context: <phone-context-ident>
phone-context-ident = network-prefix / private-prefix
network-prefix = intl-network-prefix / local-network-prefix
intl-network-prefix = "+" 1*DIGIT
local-network-prefix = 1*DIGIT
excldigandplus = (0x21-0x2d,0x2f,0x40-0x7d))
private-prefix = 1*excldigandplus 0*uric
a=phone-context: <phone-context-ident>
phone-context-ident = network-prefix / private-prefix
network-prefix = intl-network-prefix / local-network-prefix
intl-network-prefix = "+" 1*DIGIT
local-network-prefix = 1*DIGIT
excldigandplus = (0x21-0x2d,0x2f,0x40-0x7d))
private-prefix = 1*excldigandplus 0*uric
An intl-network-prefix and local-network-prefix MUST be a bona fide network prefix, and a network-prefix that is an intl-network-prefix MUST begin with an E.164 service code ("country code").
intl网络前缀和本地网络前缀必须是真正的网络前缀，作为intl网络前缀的网络前缀必须以E.164服务代码（“国家代码”）开头。
It is possible to register new private-prefixes with IANA so as to avoid collisions. Prefixes that are not so registered MUST begin with an "X-" to indicate their private, non-standard nature (see Appendix C).
可以使用IANA注册新的专用前缀，以避免冲突。未注册的前缀必须以“X-”开头，以表明其私有的非标准性质（见附录C）。
Example 1:
例1：
c= TN RFC2543 1-800-765-4321
a=phone-context:+972
c= TN RFC2543 1-800-765-4321
a=phone-context:+972
This describes an terminal whose address in Israel (E.164 country code 972) is 1-800-765-4321.
这描述了一个终端，其在以色列的地址（E.164国家代码972）为1-800-765-4321。
Example 2:
例2：
c= TN RFC2543 1-800-765-4321
a=phone-context:+1
c= TN RFC2543 1-800-765-4321
a=phone-context:+1
This describes an terminal whose address in North America (E.164 country code 1) is 1-800-765-4321.
这描述了其在北美的地址（E.164国家代码1）为1-800-765-4321的终端。
The two telephone terminals described by examples 1 and 2 are different; in fact they are located in different countries.
实施例1和2描述的两个电话终端不同；事实上，它们位于不同的国家。
Example 3:
例3：
c=TN RFC2543 123
a=phone-context:+97252
c=TN RFC2543 123
a=phone-context:+97252
This describes a terminal whose address when dialled from within the network identified by +97252 is the string "123". It so happens that +97252 defines one of the Israeli cell phone providers, and 123 reaches customer service when dialled within that network.
这描述了当从+97252标识的网络内拨号时，其地址为字符串“123”的终端。碰巧+97252定义了一家以色列手机提供商，123在该网络内拨打时可以联系客户服务部。
It may well be useful or necessary to use the SDP "require" parameter in conjunction with the phone-context attribute.
将SDP“require”参数与phone context属性结合使用可能非常有用或必要。
Example 4:
例4：
c= TN RFC2543 321 a=phone-context:X-acme.com-23
c=TN RFC2543 321 a=电话上下文：X-acme.com-23
This might describe the telephone terminal that is at extension 321 of PBX number 23 within the acme.com private PBX network. It is expected that such a description would be understandable by the acme.com PINT server that receives the request.
这可能描述acme.com专用PBX网络内PBX号码23分机321处的电话终端。预计接收请求的acme.com PINT服务器可以理解这样的描述。
Note that if the PINT server receiving the request is inside the acme.com network, the same terminal might be addressable as follows:
请注意，如果接收请求的PINT服务器位于acme.com网络内，则同一终端的地址可能如下所示：
c= TN RFC2543 7-23-321
c=TN RFC2543 7-23-321
(assuming that "7" is dialled in order to reach the private PBX network from within acme.com)
（假设拨打“7”是为了从acme.com内到达专用PBX网络）
Although it has no affect on the transport of the service request through the IP Network, there may be a requirement to allow originators of a PINT service request to indicate whether or not they wish the "B party" in the resulting service call to be presented with the "A party's" calling telephone number. It is a legal requirement in some jurisdictions that a caller be able to select whether or not their correspondent can find out the calling telephone number (using Automatic Number Indication or Caller Display or Calling Line Identity Presentation equipment). Thus an attribute may be needed to indicate the originator's preference.
虽然它不会影响通过IP网络传输服务请求，但可能需要允许PINT服务请求的发起人指示他们是否希望结果服务呼叫中的“B方”显示“a方”的呼叫电话号码。在某些司法管辖区，法律要求来电者能够选择其通讯员是否能够找到主叫电话号码（使用自动号码指示或来电显示或主叫线路身份显示设备）。因此，可能需要一个属性来指示发起人的偏好。
Whether or not the default behaviour of the Executive System is to present or not present a party's telephone number to the correspondent GSTN terminal is not specified, and it is not mandatory in all territories for a PINT Gateway or Executive System to act on
执行系统的默认行为是否是向相应的GSTN终端提供或不提供一方的电话号码，没有明确规定，也不是所有地区都强制要求PINT网关或执行系统采取行动
this attribute. It is, however, defined here for use where there are regulatory restrictions on GSTN operation, and in that case the Executive System can use it to honour the originator's request.
这个属性。然而，此处对GSTN操作有监管限制时使用它进行了定义，在这种情况下，执行系统可以使用它来满足发起人的请求。
The attribute is specified as follows:
a=clir:<"true" | "false">
The attribute is specified as follows:
a=clir:<"true" | "false">
This boolean value is needed within the attribute as it may be that the GSTN address is, by default, set to NOT present its identity to correspondents, and the originator wants to do so for this particular call. It is in keeping with the aim of this attribute to allow the originator to specify what treatment they want for the requested service call.
属性中需要此布尔值，因为GSTN地址在默认情况下可能设置为不向通信方显示其标识，并且发起者希望为此特定调用执行此操作。这与此属性的目的一致，即允许发起者为请求的服务调用指定他们想要的处理方式。
The expected interpretation of this attribute is that, if it is present and the value is "false" then the Calling Line Identity CAN be presented to the correspondent terminal, whilst if it is "true" then if possible the Executive System is requested to NOT present the Calling Line Identity.
该属性的预期解释是，如果该属性存在且值为“false”，则主叫线标识可以呈现给相应的终端，而如果该属性为“true”，则如果可能，则请求执行系统不呈现主叫线标识。
These attributes correspond to fields that appear within the ITU-T Q.763 "CalledPartyAddress" field (see [8] ,section 3.9). PINT clients use these attributes in order to specify further parameters relating to Terminal Addresses, in the case when the address indicates a "local-phone-number". In the case that the PINT request contains a reference to a GSTN terminal, the parameters may be required to correctly identify that remote terminal.
这些属性对应于出现在ITU-T Q.763“CalledPartyAddress”字段中的字段（见[8]，第3.9节）。PINT客户端使用这些属性，以便在地址指示“本地电话号码”的情况下，指定与终端地址相关的其他参数。如果PINT请求包含对GSTN终端的引用，则可能需要参数来正确识别该远程终端。
The general form of this attribute is: "a=Q763-<token>((":" <value>) |"")". Three of the possible elements and their use in SDP attributes are described here. Where other Q763 elements are to be used, then these should be the subject of further specification to define the syntax of the attribute mapping. It is recommended that any such specification maintains the value sets shown in Q.763.
该属性的一般形式是：“a=Q763-<token>（（“：”<value>）|”）。这里描述了三种可能的元素及其在SDP属性中的使用。如果要使用其他Q763元素，则应进一步规范这些元素，以定义属性映射的语法。建议任何此类规范保持Q.763中所示的值集。
The defined attributes are:
定义的属性包括：
a=Q763-nature: - indicates the "nature of address indicator". The value MAY be any number between 0 and 127. The following values are specified:
a=Q763性质：-表示“地址指示器的性质”。该值可以是0到127之间的任何数字。指定了以下值：
"1" a subscriber number "2" unknown "3" a nationally significant number "4" an internationally significant number
“1”用户号码“2”未知“3”国家重要号码“4”国际重要号码
The values have been chosen to coincide with the values in Q.763. Note that other values are possible, according to national rules or future expansion of Q.763.
选择的值与Q.763中的值一致。请注意，根据国家规则或Q.763的未来扩展，其他值是可能的。
a=Q763-plan: - indicates the numbering plan to which the address belongs. The value MAY be any number between 0 and 7. The following values are specified:
a=Q763计划：-表示地址所属的编号计划。该值可以是0到7之间的任何数字。指定了以下值：
"1" Telephone numbering plan (ITU-T E.164) "3" Data numbering plan (ITU-T X.121) "4" Telex numbering plan (ITU-T F.69)
“1”电话编号计划（ITU-T E.164）“3”数据编号计划（ITU-T X.121）“4”电传编号计划（ITU-T F.69）
The values have been chosen to coincide with the values in Q.763. Other values are allowed, according to national rules or future expansion of Q.763.
选择的值与Q.763中的值一致。根据国家规定或Q.763的未来扩展，允许使用其他值。
a=Q763-INN - indicates if routing to the Internal Network Number is allowed. The value MUST be ONE of:
a=Q763-INN-表示是否允许路由到内部网络号。该值必须是以下值之一：
"0" routing to internal network number allowed "1" routing to internal network number not allowed
允许“0”路由到内部网络号不允许“1”路由到内部网络号
The values have been chosen to coincide with the values in Q.763. Note that it is possible to use a local-phone-number and indicate via attributes that the number is in fact an internationally significant E.164 number. Normally this SHOULD NOT be done; an internationally significant E.164 number is indicated by using a "global-phone-number" for the address string.
选择的值与Q.763中的值一致。请注意，可以使用本地电话号码，并通过属性表明该号码实际上是一个具有国际意义的E.164号码。通常不应该这样做；国际重要的E.164号码通过使用“全球电话号码”作为地址字符串来表示。
According to the SDP specification, a PINT server is allowed simply to ignore attribute parameters that it does not understand. In order to force a server to decline a request if it does not understand one of the PINT attributes, a client SHOULD use the "require" attribute, specified as follows:
根据SDP规范，PINT服务器只允许忽略它不理解的属性参数。为了强制服务器在不理解PINT属性之一时拒绝请求，客户机应使用“require”属性，如下所示：
a=require:<attribute-list>
a=require:<attribute-list>
where the attribute-list is a comma-separated list of attributes that appear elsewhere in the session description.
其中，属性列表是以逗号分隔的属性列表，这些属性出现在会话描述的其他位置。
In order to process the request successfully the PINT server must BOTH understand the attribute AND ALSO fulfill the request implied by the presence of the attribute, for each attribute appearing within the attribute-list of the require attribute.
为了成功地处理请求，PINT服务器必须理解属性，并且对于require属性的属性列表中出现的每个属性，满足属性存在所隐含的请求。
If the server does not recognise the attribute listed, the PINT server MUST return an error status code (such as 420 (Bad Extension) or 400 (Bad Request)), and SHOULD return suitable Warning: lines explaining the problem or an Unsupported: header containing the attribute it does not understand. If the server recognizes the attribute listed, but cannot fulfill the request implied by the presence of the attribute, the request MUST be rejected with a status code of (606 Not Acceptable), along with a suitable Unsupported: header or Warning: line.
如果服务器无法识别列出的属性，PINT服务器必须返回一个错误状态代码（例如420（错误扩展）或400（错误请求）），并应返回适当的警告：说明问题的行或包含其无法理解的属性的不受支持的：标头。如果服务器识别出列出的属性，但无法满足该属性所暗示的请求，则必须拒绝该请求，状态代码为（606 Not Acceptable）（不可接受），以及适当的Unsupported:标头或Warning:行。
The "require" attribute may appear anywhere in the session description, and any number of times, but it MUST appear before the use of the attribute marked as required.
“require”属性可以出现在会话描述中的任何位置，也可以出现任意次数，但必须在使用标记为required的属性之前出现。
Since the "require" attribute is itself an attribute, the SIP specification allows a server that does not understand the require attribute to ignore it. In order to ensure that the PINT server will comply with the "require" attribute, a PINT client SHOULD include a Require: header with the tag "org.ietf.sdp.require" (section 3.5.4)
由于“require”属性本身就是一个属性，因此SIP规范允许不理解require属性的服务器忽略它。为了确保PINT服务器符合“require”属性，PINT客户机应包括带有标签“org.ietf.sdp.require”的require:头（第3.5.4节）
Note that the majority of the PINT extensions are "tagged" and these tags can be included in Require strictures. The exception is the use of phone numbers in SDP parts. However, these are defined as a new network and address type, so that a receiving SIP/SDP server should be able to detect whether or not it supports these forms. The default behaviour for any SDP recipient is that it will fail a PINT request if it does not recognise or support the TN and RFC2543 or X-token network and address types, as without the contents being recognised no media session could be created. Thus a separate stricture is not required in this case.
请注意，大多数品脱加长件都带有“标签”，这些标签可以包含在Require Structures中。例外情况是在SDP部件中使用电话号码。但是，这些被定义为新的网络和地址类型，因此接收SIP/SDP服务器应该能够检测它是否支持这些表单。任何SDP收件人的默认行为是，如果其不识别或不支持TN和RFC2543或X-token网络和地址类型，则其PINT请求将失败，因为如果未识别内容，则无法创建媒体会话。因此，在这种情况下不需要单独狭窄。
PINT requests are SIP requests; Many of the specifications within this document merely explain how to use existing SIP facilities for the purposes of PINT.
PINT请求是SIP请求；本文档中的许多规范仅解释了如何使用现有SIP设施进行PINT。
A PINT request can contain a payload which is multipart MIME. In this case the first part MUST contain an SDP session description that includes at least one of the format specific attribute tags for "included content data" specified above in section 3.4.3. Subsequent parts contain content data that may be transferred to the requested Telephone Call Service. As discussed earlier, within a single PINT request, some of the data MAY be pointed to by a URI within the request, and some of the data MAY be included within the request.
PINT请求可以包含多部分MIME的有效负载。在这种情况下，第一部分必须包含SDP会话描述，其中至少包括一个上文第3.4.3节中规定的“包含的内容数据”的格式特定属性标记。后续部分包含可传输到请求的电话呼叫服务的内容数据。如前所述，在单个PINT请求中，一些数据可以由请求中的URI指向，并且一些数据可以包括在请求中。
Where included data is carried within a PINT service request, the Content Type entity header of the enclosing SIP message MUST indicate this. To do so, the media type value within this entity header MUST be set to a value of "multipart". There is a content sub-type that is intended for situations like this in which sub-parts are to be handled together. This is the multipart/related type (defined in [19]), and it's use is recommended.
如果包含的数据在PINT服务请求中携带，则封装的SIP消息的内容类型实体头必须指明这一点。为此，必须将此实体标头中的媒体类型值设置为“multipart”。有一个内容子类型，用于将子部分一起处理的情况。这是多部分/相关类型（定义见[19]），建议使用它。
The enclosed body parts SHOULD include the part-specific Content Type headers as appropriate ("application/sdp" for the first body part holding the session description, with an appropriate content type for each of the subsequent, "included data object" parts). This matches the standard syntax of MIME multipart messages as defined in [4].
随附的正文部分应酌情包括特定于部分的内容类型标题（“应用程序/sdp”用于保存会话描述的第一个正文部分，以及相应的内容类型用于后续的每个“包含的数据对象”部分）。这与[4]中定义的MIME多部分消息的标准语法相匹配。
For example, in a multipart message where the string
例如，在多部分消息中，字符串
"------next-------" is the boundary, the first two parts might be as
follows:
"------next-------" is the boundary, the first two parts might be as
follows:
------next-------
Content-Type: application/sdp
....
c= TN RFC2543 +1-201-406-4090
m= text 1 pager plain
a=fmtp:plain spr:17@mymessage.acme.com
------next-------
Content-Type: application/sdp
....
c= TN RFC2543 +1-201-406-4090
m= text 1 pager plain
a=fmtp:plain spr:17@mymessage.acme.com
----------next-------
Content-Type: text/plain
Content-ID: 17@mymessage.acme.com
----------next-------
Content-Type: text/plain
Content-ID: 17@mymessage.acme.com
This is the text that is to be paged to +1-201-406-4090
这是要分页到+1-201-406-4090的文本
----------next-----------
----------next-----------
The ability to indicate different alternatives for the content to be transported is useful, even when the alternatives are included within the request. For example, a request to send a short message to a pager might include the message in Unicode [5] and an alternative version of the same content in text/plain, should the PINT server or telephone network not be able to process the unicode.
指示要传输的内容的不同备选方案的能力非常有用，即使这些备选方案包含在请求中。例如，如果PINT服务器或电话网络无法处理Unicode，则向寻呼机发送短消息的请求可能包括Unicode[5]格式的消息以及相同内容的文本/纯文本替代版本。
PINT clients should be extremely careful when sending included data within a PINT request. Such requests SHOULD be sent via TCP, to avoid fragmentation and to transmit the data reliably. It is possible that the PINT server is a proxy server that will replicate and fork the request, which could be disastrous if the request contains a large amount of application data. PINT proxy servers should be careful not to create many copies of a request with large amounts of data in it.
PINT客户端在发送PINT请求中包含的数据时应该非常小心。此类请求应通过TCP发送，以避免碎片并可靠地传输数据。PINT服务器可能是一个代理服务器，它将复制和分叉请求，如果请求包含大量应用程序数据，这可能是灾难性的。PINT代理服务器应该小心，不要创建包含大量数据的请求的多个副本。
If the client does not know the actual location of the PINT gateway, and is using the SIP location services to find it, and the included data makes the PINT request likely to be transported in several IP datagrams, it is RECOMMENDED that the initial PINT request not include the data object but instead hold a reference to it.
如果客户端不知道PINT网关的实际位置，并且正在使用SIP定位服务来查找它，并且包含的数据使得PINT请求可能在多个IP数据报中传输，建议初始PINT请求不包括数据对象，而是保留对它的引用。
A PINT server MUST support the SIP "Warning:" header so that it can signal lack of support for individual PINT features. As an example, suppose the PINT request is to send a jpeg picture to a fax machine, but the server cannot retrieve and/or translate jpeg pictures from the Internet into fax transmissions.
PINT服务器必须支持SIP“Warning:”标头，这样它就可以表示缺少对单个PINT功能的支持。例如，假设PINT请求将jpeg图片发送到传真机，但服务器无法从Internet检索和/或将jpeg图片转换为传真传输。
In such a case the server fails the request and includes a Warning such as the following:
在这种情况下，服务器请求失败，并包含如下警告：
Warning: 305 pint.acme.com Incompatible media format: jpeg
警告：305 pint.acme.com不兼容的媒体格式：jpeg
SIP servers that do not understand the PINT extensions at all are strongly encouraged to implement Warning: headers to indicate that PINT extensions are not understood.
强烈建议根本不理解PINT扩展的SIP服务器实现警告：标头以指示PINT扩展不被理解。
Also, Warning: headers may be included within NOTIFY requests if it is necessary to notify the client about some condition concerning the invocation of the PINT service (see next).
另外，警告：如果有必要通知客户机有关调用PINT服务的某些条件，则可能会在NOTIFY请求中包含标头（请参见下一步）。
3.5.3. Mechanism to register interest in the disposition of a PINT service, and to receive indications on that disposition
3.5.3. 登记PINT服务处置权益并接收处置指示的机制
It can be very useful to find out whether or not a requested service has completed, and if so whether or not it was successful. This is especially true for PINT service, where the person requesting the service is not (necessarily) a party to it, and so may not have an easy way of finding out the disposition of that service. Equally, it may be useful to indicate when the service has changed state, for example when the service call has started.
了解请求的服务是否已完成，如果已完成，是否成功，可能非常有用。对于PINT服务尤其如此，请求服务的人（不一定）是服务的一方，因此可能无法轻松找到该服务的处置方式。同样，指示服务何时改变了状态（例如，服务调用何时开始）可能很有用。
Arranging a flexible system to provide extensive monitoring and control during a service is non-trivial (see section 6.4 for some issues); PINT 1.0 uses a simple scheme that should nevertheless provide useful information. It is possible to expand the scheme in a "backwards compatible" manner, so if required it can be enhanced at a later date.
在服务期间安排一个灵活的系统来提供广泛的监测和控制是非常重要的（一些问题见第6.4节）；PINT 1.0使用了一个简单的方案，尽管如此，它还是应该提供有用的信息。可以以“向后兼容”的方式扩展该方案，因此如果需要，可以在以后对其进行增强。
The PINT 1.0 status registration and indication scheme uses three new methods; SUBSCRIBE, UNSUBSCRIBE, and NOTIFY. These are used to allow a PINT client to register an interest in (or "subscribe" to) the
PINT 1.0状态注册和指示方案使用了三种新方法；订阅、取消订阅和通知。这些用于允许PINT客户机注册（或“订阅”）项目的权益
status of a service request, to indicate that a prior interest has lapsed (i.e "unsubscribe" from the status), and for the server to return service indications. The state machine of SUBSCRIBE/UNSUBSCRIBE is identical to that of INVITE/BYE; just as INVITE signals the beginning and BYE signals the end of participation in a media session, SUBSCRIBE signals the beginning and UNSUBSCRIBE signals the end of participation in a monitoring session. During the monitoring session, NOTIFY messages are sent to inform the subscriber of a change in session state or disposition.
服务请求的状态，以指示先前的兴趣已失效（即从状态中“取消订阅”），以及服务器返回服务指示。SUBSCRIBE/UNSUBSCRIBE的状态机与INVITE/BYE的状态机相同；正如INVITE表示开始，BYE表示结束参与媒体会话一样，SUBSCRIBE表示开始，UNSUBSCRIBE表示结束参与监控会话。在监视会话期间，将发送NOTIFY消息以通知订阅者会话状态或处置的更改。
When a SUBSCRIBE request is sent to a PINT Server, it indicates that a user wishes to receive information about the status of a service session. The request identifies the session of interest by including the original session description along with the request, using the SDP global-session-id that forms part of the origin-field to identify the service session uniquely.
当向PINT服务器发送订阅请求时，它表示用户希望接收有关服务会话状态的信息。该请求通过将原始会话描述与请求一起包含，并使用构成原始字段一部分的SDP全局会话id来唯一标识服务会话，从而标识感兴趣的会话。
The SUBSCRIBE request (like any other SIP request about an ongoing session) is sent to the same server as was sent the original INVITE, or to a server which was specified in the Contact: field within a subsequent response (this might well be the PINT gateway for the session).
订阅请求（与正在进行的会话的任何其他SIP请求一样）被发送到与原始INVITE相同的服务器，或者发送到后续响应中联系人：字段中指定的服务器（这很可能是会话的PINT网关）。
Whilst there are situations in which re-use of the Call-ID used in the original INVITE that initiated the session of interest is possible, there are other situations in which it is not. In detail, where the subscription is being made by the user who initiated the original service request, the Call-ID may be used as it will be known to the receiver to refer to a previously established session. However, when the request comes from a user other than the original requesting user, the SUBSCRIBE request constitutes a new SIP call leg, so the Call-ID SHOULD NOT be used; the only common identifier is the origin-field of the session description enclosed within the original service request, and so this MUST be used.
虽然在某些情况下可以重复使用发起感兴趣会话的原始邀请中使用的呼叫ID，但在其他情况下则不可能重复使用。具体地说，在发起原始服务请求的用户正在进行预订的情况下，可以使用呼叫ID，因为接收机将知道该呼叫ID是指先前建立的会话的。然而，当请求来自除原始请求用户之外的用户时，订阅请求构成新的SIP呼叫分支，因此不应使用呼叫ID；唯一的公共标识符是原始服务请求中包含的会话描述的原始字段，因此必须使用该字段。
Rather than have two different methods of identifying the "session of interest" the choice is to use the origin-field of the SDP sub-part included both in the original INVITE and in this SUBSCRIBE request.
与其有两种不同的方法来识别“感兴趣的会话”，不如选择使用原始INVITE和此SUBSCRIBE请求中包含的SDP子部分的origin字段。
Note that the request MUST NOT include any sub-parts other than the session description, even if these others were present in the original INVITE request. A server MUST ignore whatever sub-parts are included within a SUBSCRIBE request with the sole exception of the enclosed session description.
请注意，请求不得包含会话描述以外的任何子部分，即使这些子部分在原始INVITE请求中也存在。服务器必须忽略订阅请求中包含的任何子部分，附带的会话描述除外。
The request MAY contain a "Contact:" header, specifying the PINT User Agent Server to which such information should be sent.
请求可能包含一个“Contact:”标头，指定应向其发送此类信息的PINT用户代理服务器。
In addition, it SHOULD contain an Expires: header, which indicates for how long the PINT Requestor wishes to receive notification of the session status. We refer to the period of time before the expiration of the SUBSCRIBE request as the "subscription period". See section 5.1.4. for security considerations, particularly privacy implications.
此外，它还应该包含一个Expires:头，指示PINT请求者希望接收会话状态通知的时间。我们将订阅请求到期前的一段时间称为“订阅期”。见第5.1.4节。出于安全考虑，特别是隐私影响。
A value of 0 within the Expires: header indicates a desire to receive one single immediate response (i.e. the request expires immediately). It is possible for a sequence of monitoring sessions to be opened, exist, and complete, all relating to the same service session.
Expires:header中的值为0表示希望接收一个即时响应（即请求立即过期）。可以打开、存在和完成一系列监控会话，所有这些会话都与同一服务会话相关。
A successful response to the SUBSCRIBE request includes the session description, according to the Gateway. Normally this will be identical to the last cached response that the Gateway returned to any request concerning the same SDP global session id (see [2], section 6, o= field). The t= line may be altered to indicate the actual start or stop time, however. The Gateway might add an i= line to the session description to indicate such information as how many fax pages were sent. The Gateway SHOULD include an Expires: header indicating how long it is willing to maintain the monitoring session. If this is unacceptable to the PINT Requestor, then it can close the session by sending an immediate UNSUBSCRIBE message (see 3.5.3.3).
根据网关，对订阅请求的成功响应包括会话描述。通常情况下，这将与网关返回给与相同SDP全局会话id有关的任何请求的最后一个缓存响应相同（请参阅[2]，第6节，o=字段）。然而，t=线可以改变以指示实际的启动或停止时间。网关可能会在会话描述中添加i=行，以指示发送了多少传真页等信息。网关应该包含一个Expires:头，指示它愿意维护监视会话的时间。如果PINT请求者无法接受，则可以通过发送立即取消订阅消息来关闭会话（参见3.5.3.3）。
In principle, a user might send a SUBSCRIBE request after the telephone network service has completed. This allows, for example, checking up "the morning after" to see if the fax was successfully transmitted. However, a PINT gateway is only required to keep state about a call for as long as it indicated previously in an Expires: header sent within the response to the original INVITE message that triggered the service session, within the response to the SUBSCRIBE message, within the response to any UNSUBSCRIBE message, or within its own UNSUBSCRIBE message (but see section 3.5.8, point 3).
原则上，用户可以在电话网络服务完成后发送订阅请求。例如，这允许检查“第二天早上”以查看传真是否成功传输。但是，PINT网关只需在之前在Expires:头中指示的时间内保持呼叫状态，该头在对触发服务会话的原始INVITE消息的响应中发送，在对SUBSCRIBE消息的响应中发送，在对任何UNSUBSCRIBE消息的响应中发送，或在其自身的退订信息中（但请参见第3.5.8节第3点）。
If the Server no longer has a record of the session to which a Requestor has SUBSCRIBEd, it returns "606 Not Acceptable", along with the appropriate Warning: 307 header indicating that the SDP session ID is no longer valid. This means that a requesting Client that knows that it will want information about the status of a session after the session terminates SHOULD send a SUBSCRIBE request before the session terminates.
如果服务器不再具有请求者已订阅的会话的记录，它将返回“606不可接受”，以及相应的警告：307标头，指示SDP会话ID不再有效。这意味着，知道在会话终止后需要会话状态信息的请求客户端应该在会话终止前发送订阅请求。
During the subscription period, the Gateway may, from time to time, send a spontaneous NOTIFY request to the entity indicated in the Contact: header of the "opening" SUBSCRIBE request. Normally this will happen as a result of any change in the status of the service session for which the Requestor has subscribed.
在订阅期间，网关可不时向“打开”订阅请求的联系人：报头中指示的实体发送自发通知请求。通常，请求者所订阅的服务会话的状态发生任何更改都会导致这种情况。
The receiving user agent server MUST acknowledge this by returning a final response (normally a "200 OK"). In this version of the PINT extensions, the Gateway is not required to support redirects (3xx codes), and so may treat them as a failure.
接收用户代理服务器必须通过返回最终响应（通常为“200OK”）来确认这一点。在此版本的PINT扩展中，网关不需要支持重定向（3xx代码），因此可能会将其视为故障。
Thus, if the response code class is above 2xx then this may be treated by the Gateway as a failure of the monitoring session, and in that situation it will immediately attempt to close the session (see next).
因此，如果响应代码类高于2xx，则网关可能会将其视为监控会话失败，在这种情况下，它将立即尝试关闭会话（请参阅下一步）。
The NOTIFY request contains the modified session description. For example, the Gateway may be able to indicate a more accurate start or stop time.
NOTIFY请求包含修改的会话描述。例如，网关可以指示更准确的开始或停止时间。
The Gateway may include a Warning: header to describe some problem with the invocation of the service, and may indicate within an i= line some information about the telephone network session itself.
网关可以包括一个Warning:header来描述服务调用的一些问题，并且可以在i＝线内指示关于电话网络会话本身的一些信息。
Example:
NOTIFY sip:petrack@pager.com SIP/2.0
To: sip:petrack@pager.com
From: sip:R2F.pint.com@service.com
Call-ID: 19971205T234505.56.78@pager.com
CSeq: 4711 SUBSCRIBE
Warning: xxx fax aborted, will try for the next hour.
Content-Type:application/sdp
Example:
NOTIFY sip:petrack@pager.com SIP/2.0
To: sip:petrack@pager.com
From: sip:R2F.pint.com@service.com
Call-ID: 19971205T234505.56.78@pager.com
CSeq: 4711 SUBSCRIBE
Warning: xxx fax aborted, will try for the next hour.
Content-Type:application/sdp
c=... i=3 pages of 5 sent t=...
c=。。。i=3页，共5页发送t=。。。
At some point, either the Client's representative User Agent Server or the Gateway may decide to terminate the monitoring session. This is achieved by sending an UNSUBSCRIBE request to the correspondent server. Such a request indicates that the sender intends to close the monitoring session immediately, and, on receipt of the final response from the receiving server, the session is deemed over.
在某个时刻，客户机的代表用户代理服务器或网关可能决定终止监视会话。这是通过向相应的服务器发送取消订阅请求来实现的。这样的请求表示发送方打算立即关闭监视会话，并且在接收到来自接收服务器的最终响应后，会话被视为结束。
Note that unlike the SUBSCRIBE request, which is never sent by a PINT gateway, an UNSUBSCRIBE request can be sent by a PINT gateway to the User Agent Server to indicate that the monitoring session is closed. (This is analogous to the fact that a gateway never sends an INVITE, although it can send a BYE to indicate that a telephone call has ended.)
请注意，与从不由PINT网关发送的订阅请求不同，取消订阅请求可以由PINT网关发送到用户代理服务器，以指示监视会话已关闭。（这类似于网关从不发送邀请，尽管它可以发送BYE以表示电话呼叫已结束。）
If the Gateway initiates closure of the monitoring session by sending an UNSUBSCRIBE message, it SHOULD include an "Expires:" header showing for how much longer after this monitoring session is closed it is willing to store information on the service session. This acts as a minimum time within which the Client can send a new SUBSCRIBE message to open another monitoring session; after the time indicated in the Expires: header the Gateway is free to dispose of any record of the service session, so that subsequent SUBSCRIBE requests can be rejected with a "606" response.
如果网关通过发送取消订阅消息来启动监视会话的关闭，那么它应该包括一个“Expires:”标头，显示在关闭此监视会话后，它愿意在服务会话上存储信息的时间。这作为客户端可以发送新订阅消息以打开另一个监视会话的最短时间；在Expires:报头中指示的时间之后，网关可以自由地处理服务会话的任何记录，以便可以使用“606”响应拒绝后续订阅请求。
If the subscription period specified by the Client has expired, then the Gateway may send an immediate UNSUBSCRIBE request to the Client's representative User Agent Server. This ensures that the monitoring session always completes with a UNSUBSCRIBE/response exchange, and that the representative User Agent Server can avoid maintaining state in certain circumstances.
如果客户端指定的订阅期已过期，则网关可立即向客户端的代表用户代理服务器发送取消订阅请求。这确保了监视会话始终通过取消订阅/响应交换完成，并且代表性用户代理服务器可以避免在某些情况下维护状态。
As it relies on the Gateway having a copy of the INVITEd session description, the SUBSCRIBE message is limited in when it can be issued. The Gateway must have received the service request to which this monitoring session is to be associated, which from the Client's perspective happens as soon as the Gateway has sent a 1xx response back to it.
由于它依赖于网关具有被邀请会话描述的副本，因此订阅消息在何时可以发出受到限制。网关必须已收到与此监视会话关联的服务请求，从客户端的角度来看，只要网关向其发送1x响应，就会发生此情况。
However, once this has been done, there is no reason why the Client should not send a monitoring request. It does not have to wait for the final response from the Gateway, and it can certainly send the SUBSCRIBE request before sending the ACK for the Service request final response. Beyond this point, the Client is free to send a SUBSCRIBE request when it decides, unless the Gateway's final response to the initial service request indicated a short Expires: time.
但是，一旦完成此操作，客户端就没有理由不发送监视请求。它不必等待来自网关的最终响应，它当然可以在发送服务请求最终响应的ACK之前发送订阅请求。除此之外，客户机在做出决定时可以自由发送订阅请求，除非网关对初始服务请求的最终响应指示短时间过期：time。
However, there are good reasons (see 6.4) why it may be appropriate to start a monitoring session immediately before the service is confirmed by the PINT Client sending an ACK. At this point the Gateway will have decided whether or not it can handle the service request, but will not have passed the request on to the Executive System. It is therefore in a good position to ask the Executive
但是，有充分的理由（见6.4）说明为什么在PINT客户端发送ACK确认服务之前立即启动监控会话是合适的。此时，网关将决定是否可以处理服务请求，但不会将请求传递给执行系统。因此，它可以向行政部门提出要求
System to enable monitoring when it sends the service request onwards. In practical implementations, it is likely that more information on transient service status will be available if this is indicated as being important BEFORE or AS the service execution phase starts; once execution has begun the level of information that can be returned may be difficult to change.
系统在发送服务请求时启用监控。在实际实现中，如果在服务执行阶段开始之前或开始时指示瞬态服务状态非常重要，则可能会获得更多关于瞬态服务状态的信息；一旦执行开始，可以返回的信息级别可能很难更改。
Thus, whilst it is free to send a SUBSCRIBE request at any point after receiving an Interim response from the Gateway to its service request, it is recommended that the Client should send such a monitoring request immediately prior to sending an ACK message confirming the service if it is interested in transient service status messages.
因此，虽然在从网关接收到对其服务请求的临时响应之后，可以在任何时候自由地发送订阅请求，但是如果客户机对瞬时服务状态消息感兴趣，则建议客户机在发送确认服务的ACK消息之前立即发送这样的监视请求。
PINT clients use the Require: header to signal to the PINT server that a certain PINT extension of SIP is required. PINT 1.0 defines two strings that can go into the Require header:
PINT客户端使用Require:头向PINT服务器发出信号，表示需要SIP的特定PINT扩展。PINT 1.0定义了两个可以进入Require标题的字符串：
org.ietf.sip.subscribe -- the server can fulfill SUBSCRIBE requests and associated methods (see section 3.5.3)
org.ietf.sip.subscribe——服务器可以实现订阅请求和相关方法（参见第3.5.3节）
org.ietf.sdp.require -- the PINT server (or the SDP parser associated to it) understands the "require" attribute defined in (section 3.4.4)
org.ietf.sdp.require——PINT服务器（或与其关联的sdp解析器）理解（第3.4.4节）中定义的“require”属性
Example: Require:org.ietf.sip.subscribe,org.ietf.sdp.require
示例：Require:org.ietf.sip.subscribe，org.ietf.sdp.Require
A client SHOULD only include a Require: header where it truly requires the server to reject the request if the option is not supported.
客户端应该只包含Require:header，如果不支持该选项，则它确实需要服务器拒绝请求。
Normally the hostnames and domain names that appear in the PINT URLs are the internal affair of each individual PINT system. A client uses the appropriate SDP payload to indicate the particular service it wishes to invoke; it is not necessary to use a particular URL to identify the service.
通常，出现在PINT URL中的主机名和域名是每个PINT系统的内部事务。客户端使用适当的SDP有效负载来指示它希望调用的特定服务；不必使用特定的URL来标识服务。
A PINT URL is used in two different ways within PINT requests: within the Request-URI, and within the To: and From: headers. Use within the Request-URI requires clarification in order to ensure smooth interworking with the Telephone Network serviced by the PINT infrastructure, and this is covered next.
PINT URL在PINT请求中以两种不同的方式使用：在请求URI中，以及在To:和From:头中。请求URI中的使用需要澄清，以确保与PINT基础设施所服务的电话网络的平滑互通，下面将介绍这一点。
There are some occasions when it may be useful to indicate service information within the URL in a standardized way:
在某些情况下，以标准化的方式在URL中指示服务信息可能很有用：
a. it may not be possible to use SDP information to route the
request if it is encrypted;
b. it allows implementation that make use of I.N. "service
indicators";
c. It enables multiple competing PINT gateways to REGISTER with a
single "broker" server (proxy or redirect) (see section 6.3)
a. it may not be possible to use SDP information to route the
request if it is encrypted;
b. it allows implementation that make use of I.N. "service
indicators";
c. It enables multiple competing PINT gateways to REGISTER with a
single "broker" server (proxy or redirect) (see section 6.3)
For these reasons, the following conventions for URLs are offered for use in PINT requests:
出于这些原因，在PINT请求中提供了以下URL约定：
1. The user portion of a sip URL indicates the service to be requested. At present the following services are defined:
1. SIPURL的用户部分指示要请求的服务。目前定义了以下服务：
R2C (for Request-to-Call) R2F (for Request-to-Fax) R2HC (for Request-to-Hear-Content)
R2C（请求呼叫）R2F（请求传真）R2HC（请求收听内容）
The user portions "R2C", "R2F", and "R2HC" are reserved for the PINT milestone services. Other user portions MUST be used in case the requested service is not one of the Milestone services. See section 6.2 for some related considerations concerning registrations by competing PINT systems to a single PINT proxy server acting as a service broker.
用户部分“R2C”、“R2F”和“R2HC”保留用于品脱里程碑服务。如果请求的服务不是里程碑服务之一，则必须使用其他用户部分。请参阅第6.2节，了解有关通过竞争PINT系统向充当服务代理的单个PINT代理服务器注册的一些相关注意事项。
2. The host portion of a sip URL contains the domain name of the PINT service provider.
2. SIPURL的主机部分包含PINT服务提供商的域名。
3. A new url-parameter is defined to be "tsp" (for "telephone service provider"). This can be used to indicate the actual telephone network provider to be used to fulfill the PINT request.
3. 新的url参数定义为“tsp”（用于“电话服务提供商”）。这可用于指示用于满足PINT请求的实际电话网络提供商。
Thus, for example:-
INVITE sip:R2C@pint.pintservice.com SIP/2.0
INVITE sip:R2F@pint.pintservice.com;tsp=telco.com SIP/2.0
INVITE sip:R2HC@pint.mycom.com;tsp=pbx23.mycom.com SIP/2.0
INVITE sip:13@pint.telco.com SIP/2.0
Thus, for example:-
INVITE sip:R2C@pint.pintservice.com SIP/2.0
INVITE sip:R2F@pint.pintservice.com;tsp=telco.com SIP/2.0
INVITE sip:R2HC@pint.mycom.com;tsp=pbx23.mycom.com SIP/2.0
INVITE sip:13@pint.telco.com SIP/2.0
Any legal SIP URL can appear as a PINT URL within the Request-URI or To: header of a PINT request. But if the address is a telephone address, we indicated in section 3.4.3 that it may be necessary to include more information in order correctly to identify the remote
任何合法的SIPURL都可以在请求URI或PINT请求的To:头中显示为PINT URL。但是，如果地址是电话地址，我们在第3.4.3节中指出，可能需要包含更多信息，以便正确识别遥控器
telephone terminal or service. PINT clients MAY include these attribute tags within PINT URLs if they are necessary or a useful complement to the telephone number within the SIP URL. These attribute tags MUST be included as URL parameters as defined in [1] (i.e. in the semi-colon separated manner).
电话终端或服务。PINT客户端可以在PINT URL中包含这些属性标记（如果必要），或者是SIP URL中电话号码的有用补充。这些属性标记必须包含为[1]中定义的URL参数（即以分号分隔的方式）。
The following is an example of a PINT URL containing extra attribute tags:
以下是包含额外属性标记的品脱URL示例：
sip:+9725228808@pint.br.com;user=phone;require=Q763-plan;a=Q763-plan:4
sip:+9725228808@pint.br.com;user=phone;require=Q763-plan;a=Q763-plan:4
As we noted in section 3.4.3, these extra attribute parameters will not normally be needed within a URL, because there is a great deal of context available to help the server interpret the phone number correctly. In particular, there is the SIP URL within the To: header, and there is also the Request-URI. In most cases this provides sufficient information for the telephone network.
正如我们在第3.4.3节中所指出的，URL中通常不需要这些额外的属性参数，因为有大量上下文可用于帮助服务器正确解释电话号码。特别是，To:头中有SIPURL，还有请求URI。在大多数情况下，这为电话网络提供了足够的信息。
The SDP attributes defined in section 3 above will normally only be used when they are needed to supply necessary context to identify a telephone terminal.
上文第3节中定义的SDP属性通常仅在需要提供必要的上下文以识别电话终端时使用。
A PINT gateway is a SIP user agent server. A User Agent Server uses the REGISTER request to tell a proxy or redirect server that it is available to "receive calls" (i.e. to service requests). Thus a PINT Gateway registers with a proxy or redirect server the service that is accessible via itself, whilst in SIP, a user is registering his/her presence at a particular SIP Server.
PINT网关是SIP用户代理服务器。用户代理服务器使用注册请求通知代理服务器或重定向服务器它可用于“接收呼叫”（即服务请求）。因此，PINT网关向代理服务器或重定向服务器注册可通过自身访问的服务，而在SIP中，用户在特定SIP服务器上注册其存在。
There may be competing PINT servers that can offer the same PINT service trying to register at a single PINT server. The PINT server might act as a "broker" among the various PINT gateways that can fulfill a request. A format for PINT URLs was specified in section 3.5.5 that enables independent PINT systems to REGISTER an offer to provide the same service. The registrar can apply its own mechanisms and policies to decide how to respond to INVITEs from clients seeking service (See section 6.3 for some possible deployment options). There is no change between SIP and PINT REGISTER semantics or syntax.
可能有竞争对手的PINT服务器可以提供相同的PINT服务，试图在单个PINT服务器上注册。PINT服务器可以充当各种PINT网关中的“代理”，以满足请求。第3.5.5节规定了PINT URL的格式，使独立的PINT系统能够注册提供相同服务的报价。注册官可以应用自己的机制和策略来决定如何响应寻求服务的客户的邀请（有关一些可能的部署选项，请参阅第6.3节）。SIP和PINT寄存器的语义或语法没有变化。
Of course, the information in the PINT URLs within the REGISTER request may not be sufficient to completely define the service that a gateway can offer. The use of SIP and SDP within PINT REGISTER requests to enable a gateway to specify in more detail the services it can offer is the subject of future study.
当然，注册请求中PINT URL中的信息可能不足以完全定义网关可以提供的服务。在PINT注册请求中使用SIP和SDP使网关能够更详细地指定它可以提供的服务，这是未来研究的主题。
The semantics of BYE requests within PINT requires some extra precision. One issue concerns conferences that "cannot be left", and the other concerns keeping call state after the BYE.
PINT中BYE请求的语义需要一些额外的精度。一个问题涉及“不能离开”的会议，另一个问题涉及在拜拜后保持通话状态。
The BYE request [1] is normally used to indicate that the originating entity no longer wishes to be involved in the specified call. The request terminates the call and the media session. Applying this model to PINT, if a PINT client makes a request that results in invocation of a telephone call from A to B, a BYE request from the client, if accepted, should result in a termination of the phone call.
BYE请求[1]通常用于指示发起实体不再希望参与指定呼叫。请求终止呼叫和媒体会话。将此模型应用于PINT，如果PINT客户端发出的请求导致从a到B调用电话，则来自客户端的BYE请求（如果被接受）应导致电话呼叫终止。
One might expect this to be the case if the telephone call has not started when the BYE request is received. For example, if a request to fax is sent with a t= line indicating that the fax is to be sent tomorrow at 4 AM, the requestor might wish to cancel the request before the specified time.
如果在收到BYE请求时电话尚未开始，则可能会出现这种情况。例如，如果发送传真请求时使用t=行表示传真将于明天凌晨4点发送，则请求者可能希望在指定时间之前取消该请求。
However, even if the call has yet to start, it may not be possible to terminate the media session on the telephone system side. For example, the fax call may be in progress when the BYE arrives, and perhaps it is just not possible to cancel the fax in session. Another possibility is that the entire telephone-side service might be completed before the BYE is received. In the above Request-to-Fax example, the BYE might be sent the following morning, and the entire fax has been sent before the BYE was received. It is too late to send the BYE.
但是，即使呼叫尚未开始，也可能无法在电话系统端终止媒体会话。例如，当BYE到达时，传真呼叫可能正在进行中，并且可能无法在会话中取消传真。另一种可能性是，整个电话端服务可能在收到BYE之前完成。在上面的传真请求示例中，BYE可能在第二天早上发送，并且在收到BYE之前已发送了整个传真。现在说再见已经太晚了。
In the case where the telephone network cannot terminate the call, the server MUST return a "606 Not Acceptable" response to the BYE, along with a session description that indicates the telephone network session that is causing the problem.
在电话网络无法终止呼叫的情况下，服务器必须向BYE返回“606不可接受”响应，以及指示导致问题的电话网络会话的会话描述。
Thus, in PINT, a "Not Acceptable" response MAY be returned both to INVITE and BYE requests. It indicates that some aspect of the session description makes the request unacceptable.
因此，在PINT中，可以向INVITE和BYE请求返回“不可接受”响应。它表示会话描述的某些方面使请求不可接受。
By allowing a server to return a "Not Acceptable" response to BYE requests, we are not changing its semantics, just enlarging its use.
通过允许服务器返回对BYE请求的“不可接受”响应，我们并没有改变它的语义，只是扩大了它的使用范围。
A combination of Warning: headers and i= lines within the session description can be used to indicate the precise nature of the problem.
会话描述中的Warning:headers和i=行组合可用于指示问题的确切性质。
Example:
例子：
SIP/2.0 606 Not Acceptable
From: ...
To: .......
.....
Warning: 399 pint.mycom.com Fax in progress, service cannot be
aborted
Content-Type: application/sdp
Content-Length: ...
SIP/2.0 606 Not Acceptable
From: ...
To: .......
.....
Warning: 399 pint.mycom.com Fax in progress, service cannot be
aborted
Content-Type: application/sdp
Content-Length: ...
v=0
...
...
i=3 of 5 pages sent OK
c=TN RFC2543 +12014064090
m=image 1 fax tif
a=fmtp:tif uri:http://tifsRus.com/yyyyyy.tif
v=0
...
...
i=3 of 5 pages sent OK
c=TN RFC2543 +12014064090
m=image 1 fax tif
a=fmtp:tif uri:http://tifsRus.com/yyyyyy.tif
Note that the server might return an updated session description within a successful response to a BYE as well. This can be used, for example, to indicate the actual start times and stop times of the telephone session, or how many pages were sent in the fax transmission.
请注意，服务器也可能在对BYE的成功响应中返回更新的会话描述。例如，这可用于指示电话会话的实际开始时间和停止时间，或传真传输中发送了多少页。
The second issue concerns how long must a server keep call state after receiving a BYE. A question arises because other clients might still wish to send queries about the telephone network session that was the subject of the PINT transaction. Ordinary SIP semantics have three important implications for this situation:
第二个问题涉及服务器在收到BYE后必须保持呼叫状态多长时间。出现了一个问题，因为其他客户端可能仍希望发送有关PINT事务主题的电话网络会话的查询。对于这种情况，普通SIP语义有三个重要含义：
1. A BYE indicates that the requesting client will clear out all call state as soon as it receives a successful response. A client SHOULD NOT send a SUBSCRIBE request after it has sent a BYE.
1. BYE表示请求客户端在收到成功响应后将清除所有呼叫状态。客户端发送BYE后不应发送订阅请求。
2. A server may return an Expires: header within a successful response to a BYE request. This indicates for how long the server will retain session state about the telephone network session. At any point during this time, a client may send a SUBSCRIBE request to the server to learn about the session state (although as explained in the previous paragraph, a client that has sent a BYE will not normally send a SUBSCRIBE).
2. 服务器可能会在对BYE请求的成功响应中返回Expires:头。这表示服务器将保留电话网络会话的会话状态多长时间。在此期间的任何时候，客户端都可以向服务器发送订阅请求，以了解会话状态（尽管如前一段所述，发送BYE的客户端通常不会发送订阅）。
3. When engaged in a SUBSCRIBE/NOTIFY monitoring session, PINT servers that send UNSUBSCRIBE to a URL listed in the Contact: header of a client request SHOULD not clear session state until after the successful response to the UNSUBSCRIBE message is received. For example, it may be that the requesting client host is turned off (or
3. 当参与订阅/通知监视会话时，向客户端请求的Contact:标头中列出的URL发送取消订阅的PINT服务器在收到对取消订阅消息的成功响应之前不应清除会话状态。例如，可能是请求的客户端主机已关闭（或
in a low power mode) when the telephone service is executed (and is therefore not available at the location previously specified in the Contact: attribute) to receive the PINT server's UNSUBSCRIBE. Of course, it is possible that the UNSUBSCRIBE request will simply time out.
在低功耗模式下）执行电话服务（因此在Contact:属性中先前指定的位置不可用）以接收PINT服务器的取消订阅。当然，取消订阅请求可能只是超时。
4.1. A request to a call center from an anonymous user to receive a phone call.
4.1. 匿名用户向呼叫中心发出的接收电话的请求。
C->S: INVITE sip:R2C@pint.mailorder.com SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5
From: sip:anon-1827631872@chinet.net
To: sip:+1-201-456-7890@iron.org;user=phone
Call-ID: 19971205T234505.56.78@pager.com
CSeq: 4711 INVITE
Subject: Sale on Ironing Boards
Content-type: application/sdp
Content-Length: 174
C->S: INVITE sip:R2C@pint.mailorder.com SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5
From: sip:anon-1827631872@chinet.net
To: sip:+1-201-456-7890@iron.org;user=phone
Call-ID: 19971205T234505.56.78@pager.com
CSeq: 4711 INVITE
Subject: Sale on Ironing Boards
Content-type: application/sdp
Content-Length: 174
v=0
o=- 2353687637 2353687637 IN IP4 128.3.4.5
s=R2C
i=Ironing Board Promotion
e=anon-1827631872@chinet.net
t=2353687637 0
m=audio 1 voice -
c=TN RFC2543 +1-201-406-4090
v=0
o=- 2353687637 2353687637 IN IP4 128.3.4.5
s=R2C
i=Ironing Board Promotion
e=anon-1827631872@chinet.net
t=2353687637 0
m=audio 1 voice -
c=TN RFC2543 +1-201-406-4090
In this example, the context that is required to interpret the To: address as a telephone number is not given explicitly; it is implicitly known to the R2C@pint.mailorder.com server. But the telephone of the person who wishes to receive the call is explicitly identified as an internationally significant E.164 number that falls within the North American numbering plan (because of the "+1" within the c= line).
在本例中，没有明确给出将to:地址解释为电话号码所需的上下文；这是隐含的已知的R2C@pint.mailorder.com服务器但是，希望接听电话的人的电话被明确标识为国际重要的E.164号码，属于北美编号计划（因为c=线中有“+1”）。
4.2. A request from a non anonymous customer (John Jones) to receive a phone call from a particular sales agent (Mary James) concerning the defective ironing board that was purchased
4.2. 一位非匿名客户（约翰·琼斯）要求接到某销售代理（玛丽·詹姆斯）关于购买的有缺陷熨衣板的电话
C->S: INVITE sip:marketing@pint.mailorder.com SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5
From: sip:john.jones.3@chinet.net
To: sip:mary.james@mailorder.com
Call-ID: 19971205T234505.56.78@pager.com
CSeq: 4712 INVITE
C->S: INVITE sip:marketing@pint.mailorder.com SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5
From: sip:john.jones.3@chinet.net
To: sip:mary.james@mailorder.com
Call-ID: 19971205T234505.56.78@pager.com
CSeq: 4712 INVITE
Subject: Defective Ironing Board - want refund
Content-type: application/sdp
Content-Length: 150
Subject: Defective Ironing Board - want refund
Content-type: application/sdp
Content-Length: 150
v=0
o=- 2353687640 2353687640 IN IP4 128.3.4.5
s=marketing
e=john.jones.3@chinet.net
c= TN RFC2543 +1-201-406-4090
t=2353687640 0
m=audio 1 voice -
v=0
o=- 2353687640 2353687640 IN IP4 128.3.4.5
s=marketing
e=john.jones.3@chinet.net
c= TN RFC2543 +1-201-406-4090
t=2353687640 0
m=audio 1 voice -
The To: line might include the Mary James's phone number instead of a email-like address. An implementation that cannot accept email-like URLs in the "To:" header must decline the request with a 606 Not Acceptable. Note that the sending PINT client "knows" that the PINT Gateway contacted with the "marketing@pint.mailorder.com" Request-URI is capable of processing the client request as expected. (see 3.5.5.1 for a discussion on this).
收件人：行可能包括玛丽·詹姆斯的电话号码，而不是类似电子邮件的地址。无法接受“收件人：”标题中类似电子邮件的URL的实现必须以606不可接受的名称拒绝请求。请注意，发送PINT客户端“知道”PINT网关与marketing@pint.mailorder.com“请求URI能够按预期处理客户端请求。（有关这方面的讨论，请参见3.5.5.1）。
Note also that such a telephone call service could be implemented on the phone side with different details. For example, it might be that first the agent's phone rings, and then the customer's phone rings, or it might be that first the customer's phone rings and he hears silly music until the agent comes on line. If necessary, such service parameter details might be indicated in "a=" attribute lines within the session description. The specification of such attribute lines for service consistency is beyond the scope of the PINT 1.0 specifications.
还请注意，这样的电话呼叫服务可以在电话端使用不同的细节来实现。例如，可能是首先代理的电话响了，然后客户的电话响了，或者可能是首先客户的电话响了，他听到无聊的音乐，直到代理上线。如有必要，可以在会话描述中的“a=”属性行中指示此类服务参数详细信息。此类服务一致性属性行的规范超出了PINT 1.0规范的范围。
4.3. A request from the same user to get a fax back on how to assemble the Ironing Board
4.3. 来自同一用户的请求，要求获得关于如何组装熨衣板的传真
C->S: INVITE sip:faxback@pint.mailorder.com SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5
From: sip:john.jones.3@chinet.net
To: sip:1-800-3292225@steam.edu;user=phone;phone-context=+1
Call-ID: 19971205T234505.66.79@chinet.net
CSeq: 4713 INVITE
Content-type: application/sdp
Content-Length: 218
C->S: INVITE sip:faxback@pint.mailorder.com SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5
From: sip:john.jones.3@chinet.net
To: sip:1-800-3292225@steam.edu;user=phone;phone-context=+1
Call-ID: 19971205T234505.66.79@chinet.net
CSeq: 4713 INVITE
Content-type: application/sdp
Content-Length: 218
v=0 o=- 2353687660 2353687660 IN IP4 128.3.4.5 s=faxback e=john.jones.3@chinet.net t=2353687660 0 m=application 1 fax URI
v=0 o=-2353687660在IP4 128.3.4.5中2353687660 s=传真回e=john.jones。3@chinet.nett=2353687660 0 m=应用程序1传真URI
c=TN RFC2543 1-201-406-4091
a=fmtp:URI uri:http://localstore/Products/IroningBoards/2344.html
c=TN RFC2543 1-201-406-4091
a=fmtp:URI uri:http://localstore/Products/IroningBoards/2344.html
In this example, the fax to be sent is stored on some local server (localstore), whose name may be only resolvable, or that may only be reachable, from within the IP network on which the PINT server sits. The phone number to be dialled is a "local phone number" as well. There is no "phone-context" attribute, so the context (in this case, for which nation the number is "nationally significant") must be supplied by the faxback@pint.mailorder.com PINT server.
在此示例中，要发送的传真存储在某个本地服务器（localstore）上，该服务器的名称可能只能从PINT服务器所在的IP网络中解析，也可能只能从IP网络中访问。要拨打的电话号码也是“本地电话号码”。没有“phone context”属性，因此上下文（在本例中，数字对哪个国家具有“国家重要性”）必须由faxback@pint.mailorder.com品脱服务器。
If the server that receives it does not understand the number, it SHOULD decline the request and include a "Network Address Not Understood" warning. Note that no "require" attribute was used here, since it is very likely that the request can be serviced even by a server that does not support the "require" attribute.
如果接收该请求的服务器不理解该号码，则应拒绝该请求并发出“网络地址不理解”警告。请注意，此处未使用“require”属性，因为即使不支持“require”属性的服务器也很可能为请求提供服务。
4.4. A request from same user to have that same information read out over the phone
4.4. 同一用户要求通过电话读出相同信息的请求
C->S: INVITE sip:faxback@pint.mailorder.com SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5
From: sip:john.jones.3@chinet.net
To: sip:1-800-3292225@steam.edu;user=phone;phone-context=+1
Call-ID: 19971205T234505.66.79@chinet.net
CSeq: 4713 INVITE
Content-type: application/sdp
Content-Length: 220
C->S: INVITE sip:faxback@pint.mailorder.com SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5
From: sip:john.jones.3@chinet.net
To: sip:1-800-3292225@steam.edu;user=phone;phone-context=+1
Call-ID: 19971205T234505.66.79@chinet.net
CSeq: 4713 INVITE
Content-type: application/sdp
Content-Length: 220
v=0
o=- 2353687660 2353687660 IN IP4 128.3.4.5
s=faxback
e=john.jones.3@chinet.net
t=2353687660 0
m=application 1 voice URI
c=TN RFC2543 1-201-406-4090
a=fmtp:URI uri:http://localstore/Products/IroningBoards/2344.html
v=0
o=- 2353687660 2353687660 IN IP4 128.3.4.5
s=faxback
e=john.jones.3@chinet.net
t=2353687660 0
m=application 1 voice URI
c=TN RFC2543 1-201-406-4090
a=fmtp:URI uri:http://localstore/Products/IroningBoards/2344.html
4.5. A request to send an included text page to a friend's pager.
4.5. 向朋友的寻呼机发送包含的文本页的请求。
In this example, the text to be paged out is included in the request.
在本例中，请求中包含要分页的文本。
C->S: INVITE sip:R2F@pint.pager.com SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5
From: sip:scott.petrack@chinet.net
To: sip:R2F@pint.pager.com
Call-ID: 19974505.66.79@chinet.net
CSeq: 4714 INVITE
C->S: INVITE sip:R2F@pint.pager.com SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5
From: sip:scott.petrack@chinet.net
To: sip:R2F@pint.pager.com
Call-ID: 19974505.66.79@chinet.net
CSeq: 4714 INVITE
Content-Type: multipart/related; boundary=--next
Content-Type: multipart/related; boundary=--next
----next
Content-Type: application/sdp
Content-Length: 236
v=0
o=- 2353687680 2353687680 IN IP4 128.3.4.5
s=R2F
e=scott.petrack@chinet.net
t=2353687680 0
m=text 1 pager plain
c= TN RFC2543 +972-9-956-1867
a=fmtp:plain spr:2@53655768
----next
Content-Type: application/sdp
Content-Length: 236
v=0
o=- 2353687680 2353687680 IN IP4 128.3.4.5
s=R2F
e=scott.petrack@chinet.net
t=2353687680 0
m=text 1 pager plain
c= TN RFC2543 +972-9-956-1867
a=fmtp:plain spr:2@53655768
----next
Content-Type: text/plain
Content-ID: 2@53655768
Content-Length:50
----next
Content-Type: text/plain
Content-ID: 2@53655768
Content-Length:50
Hi Joe! Please call me asap at 555-1234.
嗨，乔！请尽快打555-1234给我。
----next--
----next--
C->S: INVITE sip:faxserver@pint.vocaltec.com SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5
From: sip:scott.petrack@chinet.net
To: sip:faxserver@pint.vocaltec.com
Call-ID: 19971205T234505.66.79@chinet.net
CSeq: 4715 INVITE
Content-type: application/sdp
Content-Length: 267
C->S: INVITE sip:faxserver@pint.vocaltec.com SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5
From: sip:scott.petrack@chinet.net
To: sip:faxserver@pint.vocaltec.com
Call-ID: 19971205T234505.66.79@chinet.net
CSeq: 4715 INVITE
Content-type: application/sdp
Content-Length: 267
v=0
o=- 2353687700 2353687700 IN IP4 128.3.4.5
s=faxserver
e=scott.petrack@chinet.net
t=2353687700 0
m=image 1 fax tif gif
c= TN RFC2543 +972-9-956-1867
a=fmtp:tif uri:http://petrack/images/tif/picture1.tif
a=fmtp:gif uri:http://petrack/images/gif/picture1.gif
v=0
o=- 2353687700 2353687700 IN IP4 128.3.4.5
s=faxserver
e=scott.petrack@chinet.net
t=2353687700 0
m=image 1 fax tif gif
c= TN RFC2543 +972-9-956-1867
a=fmtp:tif uri:http://petrack/images/tif/picture1.tif
a=fmtp:gif uri:http://petrack/images/gif/picture1.gif
The image is available as tif or as gif. The tif is the preferred format. Note that the http server where the pictures reside is local, and the PINT server is also local (because it can resolve machine name "petrack")
图像可以是tif或gif格式。tif是首选格式。请注意，图片所在的http服务器是本地的，PINT服务器也是本地的（因为它可以解析机器名“petrack”）
4.7. A request to read out over the phone two pieces of content in sequence.
4.7. 通过电话依次读出两段内容的请求。
First some included text is read out by text-to-speech. Then some text that is stored at some URI on the internet is read out.
首先，一些包含的文本通过文本到语音的方式读出。然后读取存储在internet上某个URI中的一些文本。
C->S: INVITE sip:R2HC@pint.acme.com SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5
From: sip:scott.petrack@chinet.net
To: sip:R2HC@pint.acme.com
Call-ID: 19974505.66.79@chinet.net
CSeq: 4716 INVITE
Content-Type: multipart/related; boundary=next
C->S: INVITE sip:R2HC@pint.acme.com SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5
From: sip:scott.petrack@chinet.net
To: sip:R2HC@pint.acme.com
Call-ID: 19974505.66.79@chinet.net
CSeq: 4716 INVITE
Content-Type: multipart/related; boundary=next
--next
Content-Type: application/sdp
Content-Length: 316
v=0
o=- 2353687720 2353687720 IN IP4 128.3.4.5
s=R2HC
e=scott.petrack@chinet.net
--next
Content-Type: application/sdp
Content-Length: 316
v=0
o=- 2353687720 2353687720 IN IP4 128.3.4.5
s=R2HC
e=scott.petrack@chinet.net
c= TN RFC2543 +1-201-406-4091
t=2353687720 0
m=text 1 voice plain
a=fmtp:plain spr:2@53655768
m=text 1 voice plain
a=fmtp:plain uri:http://www.your.com/texts/stuff.doc
c= TN RFC2543 +1-201-406-4091
t=2353687720 0
m=text 1 voice plain
a=fmtp:plain spr:2@53655768
m=text 1 voice plain
a=fmtp:plain uri:http://www.your.com/texts/stuff.doc
--next
Content-Type: text/plain
Content-ID: 2@53655768
Content-Length: 172
--next
Content-Type: text/plain
Content-ID: 2@53655768
Content-Length: 172
Hello!! I am about to read out to you the document you
requested, "uri:http://www.your.com/texts/stuff.doc".
We hope you like acme.com's new speech synthesis server.
--next--
Hello!! I am about to read out to you the document you
requested, "uri:http://www.your.com/texts/stuff.doc".
We hope you like acme.com's new speech synthesis server.
--next--
INVITE sip:R2FB@pint.bt.co.uk SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5
To: sip:0345-12347-01@pint.bt.co.uk;user=phone;phone-context=+44
From: sip:hank.wangford@newts.demon.co.uk
Call-ID: 19981204T201505.56.78@demon.co.uk
CSeq: 4716 INVITE
Subject: Price List
Content-type: application/sdp
Content-Length: 169
INVITE sip:R2FB@pint.bt.co.uk SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5
To: sip:0345-12347-01@pint.bt.co.uk;user=phone;phone-context=+44
From: sip:hank.wangford@newts.demon.co.uk
Call-ID: 19981204T201505.56.78@demon.co.uk
CSeq: 4716 INVITE
Subject: Price List
Content-type: application/sdp
Content-Length: 169
v=0
o=- 2353687740 2353687740 IN IP4 128.3.4.5
s=R2FB
i=ISDN Price List
e=hank.wangford@newts.demon.co.uk
t=2353687740 0
m=text 1 fax -
c=TN RFC2543 +44-1794-8331010
v=0
o=- 2353687740 2353687740 IN IP4 128.3.4.5
s=R2FB
i=ISDN Price List
e=hank.wangford@newts.demon.co.uk
t=2353687740 0
m=text 1 fax -
c=TN RFC2543 +44-1794-8331010
INVITE sip:R2C@pint.bt.co.uk SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5
To: sip:0345-123456@pint.bt.co.uk;user=phone;phone-context=+44
From: sip:hank.wangford@newts.demon.co.uk
Call-ID: 19981204T234505.56.78@demon.co.uk
CSeq: 4717 INVITE
Subject: It costs HOW much?
Content-type: application/sdp
Content-Length: 176
INVITE sip:R2C@pint.bt.co.uk SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5
To: sip:0345-123456@pint.bt.co.uk;user=phone;phone-context=+44
From: sip:hank.wangford@newts.demon.co.uk
Call-ID: 19981204T234505.56.78@demon.co.uk
CSeq: 4717 INVITE
Subject: It costs HOW much?
Content-type: application/sdp
Content-Length: 176
v=0
o=- 2353687760 2353687760 IN IP4 128.3.4.5
s=R2C
i=ISDN pre-sales query
e=hank.wangford@newts.demon.co.uk
c=TN RFC2543 +44-1794-8331013
t=2353687760 0
m=audio 1 voice -
v=0
o=- 2353687760 2353687760 IN IP4 128.3.4.5
s=R2C
i=ISDN pre-sales query
e=hank.wangford@newts.demon.co.uk
c=TN RFC2543 +44-1794-8331013
t=2353687760 0
m=audio 1 voice -
INVITE sip:R2FB@pint.bt.co.uk SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5
To: sip:0345-12347-01@pint.bt.co.uk;user=phone;phone-context=+44
From: sip:colin.masterton@sales.hh.bt.co.uk
Call-ID: 19981205T234505.56.78@sales.hh.bt.co.uk
CSeq: 1147 INVITE
Subject: Price Info, as requested
Content-Type: multipart/related; boundary=next
INVITE sip:R2FB@pint.bt.co.uk SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5
To: sip:0345-12347-01@pint.bt.co.uk;user=phone;phone-context=+44
From: sip:colin.masterton@sales.hh.bt.co.uk
Call-ID: 19981205T234505.56.78@sales.hh.bt.co.uk
CSeq: 1147 INVITE
Subject: Price Info, as requested
Content-Type: multipart/related; boundary=next
--next
Content-type: application/sdp
Content-Length: 325
v=0
o=- 2353687780 2353687780 IN IP4 128.3.4.5
s=R2FB
i=Your documents
e=colin.masterton@sales.hh.bt.co.uk
t=2353687780 0
m=application 1 fax octet-stream
c=TN RFC2543 +44-1794-8331010
a=fmtp:octet-stream uri:http://www.bt.co.uk/imgs/pipr.gif opr:
spr:2@53655768
--next
Content-type: application/sdp
Content-Length: 325
v=0
o=- 2353687780 2353687780 IN IP4 128.3.4.5
s=R2FB
i=Your documents
e=colin.masterton@sales.hh.bt.co.uk
t=2353687780 0
m=application 1 fax octet-stream
c=TN RFC2543 +44-1794-8331010
a=fmtp:octet-stream uri:http://www.bt.co.uk/imgs/pipr.gif opr:
spr:2@53655768
--next
Content-Type: text/plain
Content-ID: 2@53655768
Content-Length: 352
--next
Content-Type: text/plain
Content-ID: 2@53655768
Content-Length: 352
Dear Sir, Thank you for your enquiry. I have checked availability in your area, and we can provide service to your cottage. I enclose a quote for the costs of installation, together with the ongoing rental costs for the line. If you want to proceed with this, please quote job reference isdn/hh/123.45.9901. Yours Sincerely, Colin Masterton --next--
亲爱的先生，谢谢您的询问。我已经检查了你们地区的可用性，我们可以为你们的小屋提供服务。我随函附上一份安装费用报价，以及该线路的持续租金。如果您想继续此操作，请引用作业参考isdn/hh/123.45.9901。你诚挚的，科林·马斯顿——下一个--
Note that the "implicit" faxback content is given by an EMPTY opaque reference in the middle of the fmtp line in this example.
注意，“隐式”FAXBACK内容是由在本示例中的FMTP行的中间由一个空的不透明引用给出的。
(i) phone
INVITE sip:R2FB@pint.wwos.skynet.com SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5
To:
sip:1-900-123-456-7@wwos.skynet.com;user=phone;phone-context=+1
From: sip:fred.football.fan@skynet.com
Call-ID: 19971205T234505.56.78@chinet.net
CSeq: 4721 INVITE
Subject: Wonderful World Of Sports NFL Final Scores
Content-type: application/sdp
Content-Length: 220
(i) phone
INVITE sip:R2FB@pint.wwos.skynet.com SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5
To:
sip:1-900-123-456-7@wwos.skynet.com;user=phone;phone-context=+1
From: sip:fred.football.fan@skynet.com
Call-ID: 19971205T234505.56.78@chinet.net
CSeq: 4721 INVITE
Subject: Wonderful World Of Sports NFL Final Scores
Content-type: application/sdp
Content-Length: 220
v=0
o=- 2353687800 2353687800 IN IP4 128.3.4.5
s=R2FB
i=NFL Final Scores
e=fred.football.fan@skynet.com
c=TN RFC2543 +44-1794-8331013
t=2353687800 0
m=audio 1 voice x-pay
a=fmtp:x-pay opr:mci.com/md5:<crypto signature>
v=0
o=- 2353687800 2353687800 IN IP4 128.3.4.5
s=R2FB
i=NFL Final Scores
e=fred.football.fan@skynet.com
c=TN RFC2543 +44-1794-8331013
t=2353687800 0
m=audio 1 voice x-pay
a=fmtp:x-pay opr:mci.com/md5:<crypto signature>
(ii) fax
INVITE sip:R2FB@pint.wwos.skynet.com SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5
To: sip:1-900-123-456-7@wwos.skynet.com;user=phone;
phone-context=+1
From: sip:fred.football.fan@skynet.com
Call-ID: 19971205T234505.56.78@chinet.net
CSeq: 4722 INVITE
Subject: Wonderful World Of Sports NFL Final Scores
Content-type: application/sdp
Content-Length: 217
(ii) fax
INVITE sip:R2FB@pint.wwos.skynet.com SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5
To: sip:1-900-123-456-7@wwos.skynet.com;user=phone;
phone-context=+1
From: sip:fred.football.fan@skynet.com
Call-ID: 19971205T234505.56.78@chinet.net
CSeq: 4722 INVITE
Subject: Wonderful World Of Sports NFL Final Scores
Content-type: application/sdp
Content-Length: 217
v=0
o=- 2353687820 2353687820 IN IP4 128.3.4.5
s=R2FB
i=NFL Final Scores
e=fred.football.fan@skynet.com
c=TN RFC2543 +44-1794-8331010
t=2353687820 0
m=text 1 fax x-pay
a=fmtp:x-pay opr:mci.com/md5:<crypto signature>
v=0
o=- 2353687820 2353687820 IN IP4 128.3.4.5
s=R2FB
i=NFL Final Scores
e=fred.football.fan@skynet.com
c=TN RFC2543 +44-1794-8331010
t=2353687820 0
m=text 1 fax x-pay
a=fmtp:x-pay opr:mci.com/md5:<crypto signature>
(iii) pager
INVITE sip:R2FB@pint.wwos.skynet.com SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5
To: sip:1-900-123-456-7@wwos.skynet.com;user=phone;
phone-context=+1
From: sip:fred.football.fan@skynet.com
Call-ID: 19971205T234505.56.78@chinet.net
CSeq: 4723 INVITE
Subject: Wonderful World Of Sports NFL Final Scores
Content-type: application/sdp
Content-Length: 219
(iii) pager
INVITE sip:R2FB@pint.wwos.skynet.com SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5
To: sip:1-900-123-456-7@wwos.skynet.com;user=phone;
phone-context=+1
From: sip:fred.football.fan@skynet.com
Call-ID: 19971205T234505.56.78@chinet.net
CSeq: 4723 INVITE
Subject: Wonderful World Of Sports NFL Final Scores
Content-type: application/sdp
Content-Length: 219
v=0
o=- 2353687840 2353687840 IN IP4 128.3.4.5
s=R2FB
i=NFL Final Scores
e=fred.football.fan@skynet.com
c=TN RFC2543 +44-1794-8331015
t=2353687840 0
m=text 1 pager x-pay
a=fmtp:x-pay opr:mci.com/md5:<crypto signature>
v=0
o=- 2353687840 2353687840 IN IP4 128.3.4.5
s=R2FB
i=NFL Final Scores
e=fred.football.fan@skynet.com
c=TN RFC2543 +44-1794-8331015
t=2353687840 0
m=text 1 pager x-pay
a=fmtp:x-pay opr:mci.com/md5:<crypto signature>
Note that these are all VERY similar.
请注意，这些都非常相似。
INVITE sip:BillsRUs@pint.sprint.com SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5
To: sip:+1-555-888-1234@fbi.gov;user=phone
From: sip:agent.mulder@fbi.gov
Call-ID: 19991231T234505.56.78@fbi.gov
CSeq: 911 INVITE
Subject: Itemised Bill for January 98
Content-type: application/sdp
Content-Length: 247
INVITE sip:BillsRUs@pint.sprint.com SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5
To: sip:+1-555-888-1234@fbi.gov;user=phone
From: sip:agent.mulder@fbi.gov
Call-ID: 19991231T234505.56.78@fbi.gov
CSeq: 911 INVITE
Subject: Itemised Bill for January 98
Content-type: application/sdp
Content-Length: 247
v=0
o=- 2353687860 2353687860 IN IP4 128.3.4.5
s=BillsRUs
i=Joe Pendleton's Phone Bill
e=agent.mulder@fbi.gov
c=TN RFC2543 +1-202-833-1010
t=2353687860 0
m=text 1 fax x-files-id
a=fmtp:x-files-id opr:fbi.gov/jdcn-123@45:3des;base64,<signature>
v=0
o=- 2353687860 2353687860 IN IP4 128.3.4.5
s=BillsRUs
i=Joe Pendleton's Phone Bill
e=agent.mulder@fbi.gov
c=TN RFC2543 +1-202-833-1010
t=2353687860 0
m=text 1 fax x-files-id
a=fmtp:x-files-id opr:fbi.gov/jdcn-123@45:3des;base64,<signature>
Note: in this case the opaque reference is a collection of data used to convince the Executive System that the requester has the right to get this information, rather than selecting the particular content (the A party in the To: field of the SIP "wrapper" does that alone).
注意：在这种情况下，不透明引用是一组数据，用于使执行系统确信请求者有权获取此信息，而不是选择特定内容（SIP“包装器”的to:字段中的一方单独完成此操作）。
A PINT Gateway, and the Executive System(s) with which that Gateway is associated, exist to provide service to PINT Requestors. The aim of the PINT protocol is to pass requests from those users on to a PINT Gateway so an associated Executive System can service those requests.
PINT网关以及与该网关相关联的执行系统的存在是为了向PINT请求者提供服务。PINT协议的目的是将这些用户的请求传递到PINT网关，以便相关的执行系统能够为这些请求提供服务。
The facility of making a GSTN-based call to numbers specified in the PINT request, however, comes with some risks. The request can specify an incorrect telephone of fax number. It is also possible that the Requestor has purposely entered the telephone number of an innocent third party. Finally, the request may have been intercepted on its way through any intervening PINT or SIP infrastructure, and the request may have been altered.
然而，对PINT请求中指定的号码进行基于GSTN的呼叫的功能也存在一些风险。请求可能指定传真号码的电话不正确。也可能是请求者故意输入了无辜第三方的电话号码。最后，请求可能在通过任何介入PINT或SIP基础设施的过程中被拦截，并且请求可能已被更改。
In any of these cases, the result may be that a call is placed incorrectly. Where there is intent or negligence, this may be construed as harassment of the person incorrectly receiving the call. Whilst the regulatory framework for misuse of Internet connections differs throughout the world and is not always mature, the rules under which GSTN calls are made are much more settled. Someone may be liable for mistaken or incorrect calls.
在上述任何一种情况下，结果都可能是电话打错了。如果存在故意或疏忽，这可能被解释为对错误接听电话的人的骚扰。尽管滥用互联网连接的监管框架在全世界各不相同，并不总是成熟的，但进行GSTN呼叫所依据的规则要稳定得多。有人可能会对错误或不正确的呼叫负责。
Understandably, the GSTN Operators would prefer that this someone is not them, so they will need to ensure that any PINT Gateway and Executive System combination does not generate incorrect calls through some error in the Gateway or Executive system implementation or GSTN-internal communications fault. Equally, it is important that the Operator can show that they act only on requests that they have good reason to believe are correct. This means that the Gateway must not pass on requests unless it is sure that they have not been corrupted in transit from the Requestor.
可以理解，GSTN运营商希望此人不是他们，因此他们需要确保任何PINT网关和执行系统组合不会因网关或执行系统实施中的某些错误或GSTN内部通信故障而产生错误呼叫。同样重要的是，运营商应表明，他们仅对其有充分理由相信正确的请求采取行动。这意味着网关不能传递请求，除非它确定请求在传输过程中没有被请求者破坏。
If a request can be shown to have come from a particular Requestor and to have been acted on in good faith by the PINT service provider, then responsibility for making requests may well fall to the Requestor rather than the Operator who executed these requests.
如果可以证明某个请求来自某个特定的请求者，并且PINT服务提供商真诚地执行了该请求，那么提出请求的责任很可能落在请求者身上，而不是落在执行这些请求的运营商身上。
Finally, it may be important for the PINT service provider to be able to show that they act only on requests for which they have some degree of assurance of origin. In many jurisdictions, it is a requirement on GSTN Operators that they place calls only when they can, if required, identify the parties to the call (such as when required to carry out a Malicious Call Trace). It is at least likely that the provider of PINT services will have a similar responsibility placed on them.
最后，PINT服务提供商必须能够证明他们仅对其有一定程度原产地保证的请求采取行动。在许多司法管辖区，GSTN运营商的一项要求是，只有在需要时，他们才能识别呼叫方（例如，当需要进行恶意呼叫跟踪时），才进行呼叫。至少品脱服务的供应商也有可能承担类似的责任。
It follows that the PINT service provider may require that the identity of the Requestor be confirmed. If such confirmation is not available, then they may be forced (or choose) not to provide service. This identification may require personal authentication of the Requesting User.
因此，PINT服务提供商可能要求确认请求者的身份。如果此类确认不可用，则他们可能被迫（或选择）不提供服务。此标识可能需要请求用户的个人身份验证。
Where GSTN resources are used to provide a PINT service, it is at least possible that someone will have to pay for it. This person may not be the Requestor, as, for example, in the case of existing GSTN split-charging services like free phone in which the recipient of a call rather than the originator is responsible for the call cost.
如果GSTN资源用于提供品脱服务，则至少有可能需要有人为此付费。此人可能不是请求者，例如，在现有GSTN分离收费服务（如免费电话）的情况下，呼叫接收者而不是发起者负责呼叫成本。
This is not, of course, the only possibility; for example, PINT service may be provided on a subscription basis, and there are a number of other models. However, whichever model is chosen, there may be a requirement that the authority of a Requestor to make a PINT request is confirmed.
当然，这不是唯一的可能性；例如，PINT服务可以在订阅的基础上提供，还有许多其他型号。然而，无论选择哪种型号，都可能需要确认请求者提出PINT请求的权限。
If such confirmation is not available, then, again, the PINT Gateway and associated Executive System may choose not to provide service.
如果此类确认不可用，则PINT网关和相关执行系统可再次选择不提供服务。
Even if the identity of the Requesting User and the Authority under which they make their request is known, there remains the possibility that the request is either corrupted, maliciously altered, or even replaced whilst in transit between the Requestor and the PINT Gateway.
即使知道请求用户的身份及其发出请求的权限，请求仍有可能在请求者和PINT网关之间传输时被破坏、恶意更改，甚至被替换。
Similarly, information on the Authority under which a request is made may well be carried within that request. This can be sensitive information, as an eavesdropper might steal this and use it within their own requests. Such authority SHOULD be treated as if it were financial information (such as a credit card number or PIN).
同样，关于提出请求所依据的当局的信息也很可能包含在该请求中。这可能是敏感信息，因为窃听者可能会窃取这些信息并在自己的请求中使用。此类权限应视为财务信息（如信用卡号码或PIN）。
The data authorizing a Requesting User to make a PINT request should be known only to them and the service provider. However, this information may be in a form that does not match the schemes normally used within the Internet. For example, X.509 certificates[14] are commonly used for secured transactions on the Internet both in the IP Security Architecture[12] and in the TLS protocol[13], but the GSTN provider may only store an account code and PIN (i.e. a fixed string of numbers).
授权请求用户进行PINT请求的数据应仅为他们和服务提供商所知。但是，该信息的形式可能与互联网中通常使用的方案不匹配。例如，在IP安全体系结构[12]和TLS协议[13]中，X.509证书[14]通常用于互联网上的担保交易，但GSTN提供商只能存储账户代码和PIN（即固定的数字字符串）。
A Requesting User has a reasonable expectation that their requests for service are confidential. For some PINT services, no content is carried over the Internet; however, the telephone or fax numbers of the parties to a resulting service calls may be considered sensitive. As a result, it is likely that the Requestor (and their PINT service provider) will require that any request that is sent across the Internet be protected against eavesdroppers; in short, the requests SHOULD to be encrypted.
请求用户有一个合理的期望，即他们的服务请求是保密的。对于一些品脱服务，互联网上没有内容；然而，由此产生的服务呼叫的各方的电话或传真号码可能被认为是敏感的。因此，请求者（及其PINT服务提供商）可能会要求对通过互联网发送的任何请求进行保护，以防被窃听；简而言之，请求应该被加密。
Some special considerations relate to monitoring sessions using the SUBSCRIBE and NOTIFY messages. The SUBSCRIBE message that is used to register an interest in the disposition of a PINT service transaction uses the original Session Description carried in the related INVITE message. This current specification does not restrict the source of such a SUBSCRIBE message, so it is possible for an eavesdropper to capture an unprotected session description and use this in a subsequent SUBSCRIBE request. In this way it is possible to find out details on that transaction that may well be considered sensitive.
一些特殊注意事项与使用SUBSCRIBE和NOTIFY消息监视会话有关。用于在PINT服务事务处理中注册兴趣的SUBSCRIBE消息使用相关INVITE消息中包含的原始会话描述。此当前规范不限制此类订阅消息的源，因此窃听者可以捕获未受保护的会话描述并在后续订阅请求中使用该描述。通过这种方式，可以了解该交易的细节，这些细节很可能被认为是敏感的。
The initial solution to this risk is to recommend that a session description that may be used within a subsequent SUBSCRIBE message SHOULD be protected.
此风险的初始解决方案是建议对后续订阅消息中可能使用的会话描述进行保护。
However, there is a further risk; if the origin-field used is "guessable" then it might be possible for an attacker to reconstruct the session description and use this reconstruction within a SUBSCRIBE message.
然而，还有进一步的风险；如果使用的原始字段是“可猜测的”，则攻击者可能会重建会话描述，并在订阅消息中使用此重建。
SDP (see section 6 of [2], "o=" field) does not specify the mechanism used to generate the sess-id field, and suggests that a method based on timestamps produced by Network Time Protocol [16] can be used. This is sufficient to guarantee uniqueness, but may allow the value to be guessed, particularly if other unprotected requests from the same originator are available.
SDP（参见[2]第6节，“o=”字段）未指定用于生成sess id字段的机制，并建议可以使用基于网络时间协议[16]生成的时间戳的方法。这足以保证唯一性，但可能允许猜测值，特别是当来自同一发起人的其他未受保护的请求可用时。
Thus, to ensure that the session identifier is not guessable the techniques described in section 6.3 of [17] can be used when generating the origin-field for a session description to be used inside a PINT INVITE message. If all requests from (and responses to) a particular PINT requesting entity are protected, then this is not needed. Where such a situation is not assured, AND where session monitoring is supported, then a method by which an origin-field within a session description is not guessable SHOULD be used.
因此，为确保会话标识符不可猜测，[17]第6.3节中描述的技术可用于为PINT INVITE消息中使用的会话描述生成原始字段。如果来自特定PINT请求实体的所有请求（和对该实体的响应）都受到保护，则不需要这样做。如果无法确定这种情况，并且支持会话监视，则应使用会话描述中的源字段不可猜测的方法。
Any number of PINT Gateways may register to provide the same service; this is indicated by the Gateways specifying the same "userinfo" part in the To: header field of the REGISTER request. Whilst such ambiguity would be unlikely to occur with the scenarios covered by "core" SIP, it is very likely for PINT; there could be any number of service providers all willing to support a "Request-To-Fax" service, for example.
任何数量的PINT网关都可以注册以提供相同的服务；这由网关在注册请求的To:头字段中指定相同的“userinfo”部分表示。虽然“核心”SIP涵盖的场景不太可能出现这种模糊性，但PINT很可能出现这种情况；例如，可能有任意数量的服务提供商都愿意支持“传真请求”服务。
Unless a request specifies the Gateway name explicitly, an intervening Proxy that acts on a registration database to which several Gateways have all registered is in a position to select from the registrands using whatever algorithm it chooses; in principle, any Gateway that has registered as "R2F" would be appropriate.
除非请求明确指定网关名称，否则在多个网关已全部注册的注册数据库上运行的中间代理可以使用其选择的任何算法从注册者中进行选择；原则上，任何已注册为“R2F”的网关都是合适的。
However, this opens up an avenue for attack, and this is one in which a "rogue" Gateway operator stands to make a significant gain. The standard SIP procedure for releasing a registration is to send a REGISTER request with a Contact field having a wildcard value and an expires parameter with a value of 0. It is important that a PINT Registrar uses authentication of the Registrand, as otherwise one PINT service provider would be able to "spoof" another and remove their registration. As this would stop the Proxy passing any requests to that provider, this would both increase requests being sent to the rogue and stop requests going to the victim.
然而，这为攻击开辟了一条途径，而这正是一个“流氓”网关运营商能够获得巨大收益的途径。释放注册的标准SIP过程是发送一个注册请求，其中联系人字段具有通配符值，expires参数的值为0。重要的是，PINT注册商使用注册人的身份验证，否则一家PINT服务提供商将能够“欺骗”另一家并删除其注册。由于这将阻止代理将任何请求传递给该提供者，这将增加发送给流氓的请求，并阻止发送给受害者的请求。
Another variant on this attack would be to register a Gateway using a name that has been registered by another provider; thus a rogue Operator might register its Gateway as "R2C@pint.att.com", thereby hijacking requests.
此攻击的另一种变体是使用已由另一提供商注册的名称注册网关；因此，流氓运营商可能会将其网关注册为“R2C@pint.att.com“，从而劫持请求。
The solution is the same; all registrations by PINT Gateways MUST be authenticated; this includes both new or apparent replacement registrations, and any cancellation of current registrations. This recommendation is also made in the SIP specification, but for the correct operation of PINT, it is very important indeed.
答案是一样的；PINT网关的所有注册必须经过认证；这包括新的或明显的替代注册，以及当前注册的任何取消。SIP规范中也提出了这一建议，但对于PINT的正确操作来说，这确实非常重要。
PINT is a set of extensions to SIP[1] and SDP[2], and will use the security procedures described in SIP. There are several implications of this, and these are covered here.
PINT是SIP[1]和SDP[2]的一组扩展，将使用SIP中描述的安全过程。这有几个方面的含义，这里将介绍这些含义。
For several of the PINT services, the To: header field of SIP is used to identify one of the parties to the resulting service call. The PINT Request-To-Call service is an example. As mentioned in the SIP specification, this field is used to route SIP messages through an infrastructure of Redirect and Proxy server between the corresponding User Agent Servers, and so cannot be encrypted. This means that, although the majority of personal or sensitive data can be protected whilst in transit, the telephone (or fax) number of one of the parties to a PINT service call cannot, and will be "visible" to any interception. For the PINT milestone services this may be acceptable, since the caller named in the To: service is typically a "well known" provider address, such as a Call Center.
对于一些PINT服务，SIP的To:header字段用于标识结果服务调用的一方。PINT呼叫请求服务就是一个例子。如SIP规范中所述，此字段用于通过重定向和代理服务器基础设施在相应的用户代理服务器之间路由SIP消息，因此无法加密。这意味着，尽管大多数个人或敏感数据在传输过程中都可以得到保护，但PINT服务呼叫的一方的电话（或传真）号码不能，并且任何截获都将“可见”。对于PINT里程碑服务，这可能是可以接受的，因为To:服务中指定的调用方通常是“众所周知”的提供商地址，例如呼叫中心。
Another aspect of this is that, even if the Requesting User does not consider the telephone or fax numbers of the parties to a PINT service to be private, those parties might. Where PINT servers have reason to believe this might be the case they SHOULD encrypt the request, even if the Requestor has not done so. This could happen, for example, if a Requesting User within a company placed a PINT request and this was carried via the company's Intranet to their Proxy/firewall and thence over the Internet to a PINT Gateway at another location.
另一个方面是，即使请求用户不认为PITT服务的当事人的电话或传真号码为私有的，这些当事人也可以。如果PINT服务器有理由相信可能是这种情况，那么它们应该加密请求，即使请求者没有这样做。例如，如果公司内的请求用户发出PINT请求，该请求通过公司内部网传输到其代理/防火墙，然后通过Internet传输到另一个位置的PINT网关，则可能发生这种情况。
If a request carries data that can be reused by an eavesdropper either to "spoof" the Requestor or to obtain PINT service by inserting the Requestor's authorization token into an eavesdropper's request, then this data MUST be protected. This is particularly important if the authorization token consists of static text (such as an account code and/or PIN).
如果请求包含可被窃听者重用的数据，以“欺骗”请求者或通过将请求者的授权令牌插入窃听者的请求来获得PINT服务，则必须保护该数据。如果授权令牌由静态文本（例如帐户代码和/或PIN）组成，这一点尤为重要。
One approach is to encrypt the whole of the request, using the methods described in the SIP specification. As an alternative, it may be acceptable for the authorization token to be held as an opaque reference (see section 3.4.2.3 and examples 4.11 and 4.12), using some proprietary scheme agreed between the Requestor and the PINT service provider, as long as this is resistant to interception and re-use. Also, it may be that the authorization token cannot be used outside of a request cryptographically signed by the Requestor; if so then this requirement can be relaxed, as in this case the token cannot be re-used by another. However, unless both the Requestor and the Gateway are assured that this is the case, any authorization token MUST be treated as sensitive, and so MUST be encrypted.
一种方法是使用SIP规范中描述的方法对整个请求进行加密。作为替代方案，授权令牌可以作为不透明引用（参见第3.4.2.3节和示例4.11和4.12），使用请求者和PINT服务提供商之间商定的一些专有方案，只要这样可以防止拦截和重复使用。此外，授权令牌可能不能在请求者以加密方式签名的请求之外使用；如果是这样，那么这个要求可以放宽，因为在这种情况下，令牌不能被另一个令牌重复使用。但是，除非请求者和网关都确信是这种情况，否则任何授权令牌都必须被视为敏感令牌，因此必须进行加密。
A PINT request may contain data within the SDP message body that can be used more efficiently to route that request. For example, it may be that one Gateway and Executive System combination cannot handle a request that specifies one of the parties as a pager, whilst another can. Both gateways may have registered with a PINT/SIP Registrar, and this information may be available to intervening PINT/SIP Proxies. However, if the message body is encrypted, then the request cannot be decoded at the Proxy server, and so Gateway selection based on contained information cannot be made there.
PINT请求可以包含SDP消息体中的数据，这些数据可以更有效地用于路由该请求。例如，一个网关和执行系统组合可能无法处理将其中一方指定为寻呼机的请求，而另一方可以。两个网关可能都已向PINT/SIP注册器注册，并且该信息可供介入PINT/SIP代理使用。但是，如果消息体是加密的，则无法在代理服务器上对请求进行解码，因此无法在代理服务器上根据包含的信息选择网关。
The result is that the Proxy may deliver the request to a Gateway that cannot handle it; the implication is that a PINT/SIP Proxy SHOULD consider its choice for the appropriate Gateway subject to correction, and, on receiving a 501 or 415 rejection from the first gateway chosen, try another. In this way, the request will succeed if at all possible, even though it may be delayed (and tie up resources in the inappropriate Gateways).
结果是代理可能会将请求传递给无法处理它的网关；其含义是，一个PIT/SIP代理应该考虑其对适当的网关进行校正的选择，并且在接收到来自第一网关的501或415拒绝时，尝试另一个网关。这样，即使请求可能被延迟（并在不适当的网关中占用资源），请求也会成功。
This opens up an interesting avenue for Denial Of Service; sending a valid request that appears to be suitable for a number of different Gateways, and simply occupying those Gateways in decrypting a message requesting a service they cannot provide. As mentioned in section 3.5.5.1, the choice of service name to be passed in the userinfo portion of the SIP Request-URI is flexible, and it is RECOMMENDED that names be chosen that allow a Proxy to select an appropriate Gateway without having to examine the SDP body part. Thus, in the example given here, the service might be called "Request-To-Page" or "R2P" rather than the more general use of "R2F", if there is a possibility of the SDP body part being protected during transit.
这为拒绝服务开辟了一条有趣的途径；发送一个似乎适用于多个不同网关的有效请求，并简单地占用这些网关对请求它们无法提供的服务的消息进行解密。如第3.5.5.1节所述，在SIP请求URI的userinfo部分中传递的服务名称的选择是灵活的，建议选择允许代理选择适当网关的名称，而无需检查SDP主体部分。因此，在这里给出的示例中，如果SDP车身部件在运输过程中可能受到保护，则该服务可能被称为“页面请求”或“R2P”，而不是“R2F”的更一般用法。
A variation on this attack is to provide a request that is syntactically invalid but that, due to the encryption, cannot be detected without expending resources in decoding it. The effects of this form of attack can be minimised in the same way as for any SIP Invitation; the Proxy should detect the 400 rejection returned from the initial Gateway, and not pass the request onwards to another.
此攻击的一种变体是提供语法无效的请求，但由于加密，如果不花费资源对其进行解码，则无法检测到该请求。这种形式的攻击的影响可以通过与任何SIP邀请相同的方式最小化；代理应该检测从初始网关返回的400拒绝，而不是将请求转发给另一个网关。
Finally, note that the Requesting User may not have a prior relationship with a PINT Gateway, whilst still having a prior relationship with the Operator of the Executive System that fulfills their request. Thus there may be two levels of authentication and authorization; one carried out using the techniques described in the SIP specification (for use between the Requestor and the Gateway), with another being used between the Requesting User or the Requestor and the Executive System.
最后，请注意，请求用户可能与PINT网关没有先前的关系，同时仍然与满足其请求的执行系统的操作员有先前的关系。因此，可能有两个级别的身份验证和授权；一个是使用SIP规范中描述的技术执行的（用于请求者和网关之间），另一个是在请求用户或请求者和执行系统之间使用的。
For example, the Requesting User may have an account with the PINT service provider. That provider might require that requests include this identity before they will be convinced to provide service. In addition, to counter attacks on the request whilst it is in transit across the Internet, the Gateway may require a separate X.509-based certification of the request. These are two separate procedures, and data needed for the former would normally be expected to be held in opaque references inside the SDP body part of the request.
例如，请求用户可能拥有PINT服务提供商的帐户。该提供者可能要求请求在被说服提供服务之前包含此标识。此外，为了在请求通过互联网传输时反击攻击，网关可能需要对请求进行单独的基于X.509的认证。这是两个独立的过程，前者所需的数据通常会保存在请求的SDP主体部分内的不透明引用中。
The detailed operation of this mechanism is, by definition, outside the scope of an Internet Protocol, and so must be considered a private matter. However, one approach to indicating to the Requestor that such "second level" authentication or authorization is required by their Service Provider would be to ask for this inside the textual description carried with a 401 response returned from the PINT Gateway.
根据定义，该机制的详细操作超出了互联网协议的范围，因此必须将其视为私事。然而，向请求者表明其服务提供商需要此类“第二级”认证或授权的一种方法是在文本描述中请求该认证或授权，该文本描述带有从PINT网关返回的401响应。
From the above discussion, PINT always carries data items that are sensitive, and there may be financial considerations as well as the more normal privacy concerns. As a result, the transactions MUST be protected from interception, modification and replay in transit.
从上面的讨论中可以看出，PINT总是携带敏感的数据项，可能有财务方面的考虑以及更正常的隐私问题。因此，必须保护事务不被拦截、修改和在传输过程中重播。
PINT is based on SIP and SDP, and can use the security procedures outlined in [1] (sections 13 and 15). However, in the case of PINT, the SIP recommendation that requests and responses MAY be protected is not enough. PINT messages MUST be protected, so PINT Implementations MUST support SIP Security (as described in [1], sections 13 & 15), and be capable of handling such received messages.
PINT基于SIP和SDP，可以使用[1]（第13节和第15节）中概述的安全程序。然而，在PINT的情况下，SIP关于请求和响应可能受到保护的建议是不够的。PINT消息必须受到保护，因此PINT实现必须支持SIP安全性（如[1]第13和15节所述），并且能够处理此类接收到的消息。
In some configurations, PINT Clients, Servers, and Gateways can be sure that they operate using the services of network level security [13], transport layer security [12], or physical security for all communications between them. In these cases messages MAY be exchanged without SIP security, since all traffic is protected already. Clients and servers SHOULD support manual configuration to use such lower layer security facilities.
在某些配置中，PINT客户端、服务器和网关可以确保它们使用网络级安全服务[13]、传输层安全服务[12]或物理安全服务进行操作，以实现它们之间的所有通信。在这些情况下，由于所有流量都已受到保护，因此可以在没有SIP安全的情况下交换消息。客户端和服务器应支持手动配置以使用此类低层安全设施。
When using network layer security [13], the Security Policy Database MUST be configured to provide appropriate protection to PINT traffic. When using TLS, a port configured MUST NOT also be configured for non-TLS traffic. When TLS is used, basic authentication MUST be supported, and client-side certificates MAY be supported.
当使用网络层安全[13]时，必须将安全策略数据库配置为对PINT流量提供适当的保护。使用TLS时，配置的端口不得同时配置为非TLS流量。使用TLS时，必须支持基本身份验证，并且可以支持客户端证书。
Authentication of the Client making the request is required, however, so if this is not provided by the underlying mechanism used, then it MUST be included within the PINT messages using SIP authentication techniques. In contrast with SIP, PINT requests are often sent to parties with which a prior communications relationship exists (such as a Telephone Carrier). In this case, there may be a shared secret between the client and the PINT Gateway. Such PINT systems MAY use authentication based on shared secrets, with HTTP "basic authentication". When this is done, the message integrity and privacy must be guaranteed by some lower layer mechanism.
但是，需要对发出请求的客户端进行身份验证，因此，如果所使用的底层机制未提供此功能，则必须使用SIP身份验证技术将其包含在PINT消息中。与SIP不同的是，PINT请求通常被发送给先前存在通信关系的各方（如电话运营商）。在这种情况下，客户端和PINT网关之间可能存在共享秘密。此类PINT系统可以使用基于共享机密的身份验证，并使用HTTP“基本身份验证”。这样做时，消息的完整性和隐私性必须由一些较低层的机制来保证。
There are implications on the operation of PINT here though. If a PINT proxy or redirect server is used, then it must be able to examine the contents of the IP datagrams carried. It follows that an end-to-end approach using network-layer security between the PINT Client and a PINT Gateway precludes the use of an intervening proxy; communication between the Client and Gateway is carried via a tunnel to which any intervening entity cannot gain access, even if the IP datagrams are carried via this node. Conversely, if a "hop-by-hop" approach is used, then any intervening PINT proxies (or redirect servers) are, by implication, trusted entities.
不过，这对品脱的操作也有影响。如果使用PINT代理或重定向服务器，那么它必须能够检查所携带的IP数据报的内容。因此，在PINT客户端和PINT网关之间使用网络层安全性的端到端方法排除了中间代理的使用；客户机和网关之间的通信通过隧道进行，任何介入实体都无法访问该隧道，即使IP数据报通过该节点进行。相反，如果使用“逐跳”的方法，那么任何介入的PINT代理（或重定向服务器）都是可信的实体。
However, if there is any doubt that there is an underlying network or transport layer security association in place, then the players in a PINT protocol exchange MUST use encryption and authentication techniques within the protocol itself. The techniques described in section 15 of RFC2543 MUST be used, unless there is an alternative protection scheme that is agreed between the parties. In either case, the content of any message body (or bodies) carried within a PINT request or response MUST be protected; this has implications on the options for routing requests via Proxies (see 5.3).
但是，如果怀疑存在底层网络或传输层安全关联，则PINT协议交换中的参与者必须在协议本身中使用加密和身份验证技术。必须使用RFC2543第15节中所述的技术，除非双方商定了替代保护方案。在任何一种情况下，PINT请求或响应中包含的任何消息正文的内容都必须受到保护；这对通过代理路由请求的选项有影响（见5.3）。
Using SIP techniques for protection, the Request-URI and To: fields headers within PINT requests cannot be protected. In the baseline PINT services these fields may contain sensitive information. This is a consideration, and if these data ARE considered sensitive, then this will preclude the sole use of SIP techniques; in such a situation, transport [12] or network layer [13] protection mechanisms MUST be used.
使用SIP技术进行保护时，无法保护PINT请求中的请求URI和To:字段头。在基线PINT服务中，这些字段可能包含敏感信息。这是一个考虑因素，如果这些数据被认为是敏感的，那么这将排除单独使用SIP技术；在这种情况下，必须使用传输[12]或网络层[13]保护机制。
As a final point, this choice will in turn have an influence on the choice of transport layer protocol that can be used; if a TLS association is available between two nodes, then TCP will have to be used. This is different from the default behaviour of SIP (try UDP, then try TCP if that fails).
作为最后一点，这种选择将反过来影响可使用的传输层协议的选择；如果两个节点之间存在TLS关联，则必须使用TCP。这与SIP的默认行为不同（尝试UDP，如果失败则尝试TCP）。
6. Deployment considerations and the Relationship PINT to I.N. (Informative)
6. 部署注意事项以及PINT与I.N.的关系（资料性）
It is possible that some other protocol may be used to communicate a Requesting User's requirements. Due to the high numbers of available Web Browsers and servers it seems likely that some PINT systems will use HTML/HTTP as a "front end". In this scenario, HTTP will be used over a connection from the Requesting User's Web Browser (WC) to an Intermediate Web Server (WS). This will be closely associated with a PINT Client (using some unspecified mechanism to transfer the data from the Web Server to the PINT Client). The PINT Client will represent the Requesting User to the PINT Gateway, and thus to the Executive System that carries out the required action.
可能使用一些其他协议来传达请求用户的需求。由于有大量可用的Web浏览器和服务器，一些PINT系统可能会使用HTML/HTTP作为“前端”。在此场景中，HTTP将通过从请求用户的Web浏览器（WC）到中间Web服务器（WS）的连接使用。这将与PINT客户端密切相关（使用一些未指定的机制将数据从Web服务器传输到PINT客户端）。PINT客户端将向PINT网关代表请求用户，从而向执行所需操作的执行系统代表请求用户。
[WC]------[WS]
[PC]
\
\
[PG]
[XS]
[WC]------[WS]
[PC]
\
\
[PG]
[XS]
Figure 2: Basic "Web-fronted" Configuration
图2：基本的“面向Web”配置
It is quite possible that a given PINT Gateway is associated with an Executive System (or systems) that can connect to the GSTN at different places. Equally, if there is a chain of PINT Servers, then each of these intermediate or proxy servers (PP) may be able to route PINT requests to Executive Systems that connect at specific points to the GSTN. The result of this is that there may be more than one PINT Gateway or Executive System that can deal with a given request. The mechanisms by which the choice on where to deliver a request are outside the scope of this document.
很可能给定的PINT网关与可在不同位置连接到GSTN的一个或多个执行系统相关联。同样，如果存在PINT服务器链，则这些中间或代理服务器（PP）中的每一个都可以将PINT请求路由到在特定点连接到GSTN的执行系统。其结果是，可能有多个PINT网关或执行系统可以处理给定的请求。选择在何处提交请求的机制不在本文档的范围内。
[WC]------[WS] [WC]------[WS]
[PC] [PC]
\ \
\ \
[PG] [PP]
.........[XS]......... / \
: : / \
[PG] [PG]
[XS] [XS]
[WC]------[WS] [WC]------[WS]
[PC] [PC]
\ \
\ \
[PG] [PP]
.........[XS]......... / \
: : / \
[PG] [PG]
[XS] [XS]
Figure 3: Multiple Access Configurations
图3：多址访问配置
However, there do seem to be two approaches. Either a Server that acts as a proxy or redirect will select the appropriate Gateway itself and will cause the request to be sent on accordingly, or a list of possible Locations will be returned to the Requesting User from which they can select their choice.
然而，似乎有两种方法。充当代理或重定向的服务器将选择适当的网关本身并相应地发送请求，或者将向请求用户返回一个可能位置的列表，用户可以从中选择自己的选择。
In SIP, the implication is that, if a proxy cannot resolve to a single unique match for a request destination, then a response containing a list of the choices should be returned to the Requesting User for selection. This is not too likely a scenario within the normal use of SIP.
在SIP中，这意味着，如果代理无法解析为请求目的地的单个唯一匹配，则应将包含选项列表的响应返回给请求用户进行选择。这不太可能是正常使用SIP的情况。
However, within PINT, such ambiguity may be quite common; it implies that there are a number of possible providers of a given service.
然而，在品脱中，这种歧义可能很常见；这意味着给定服务有许多可能的提供者。
With PINT, the registration is not for an individual but instead for a service that can be handled by a service provider. Thus, one can envisage a registration by the PINT Server of the domain telcoA.com of its ability to support the service R2C as "R2C@telcoA.com", sent to an intermediary server that acts as registrar for the "broker.telcos.com" domain from "R2C@pint.telcoA.com" as follows:
使用PINT，注册不是针对个人，而是针对可由服务提供商处理的服务。因此，可以设想由域telcoA.com的PINT服务器注册其支持服务R2C的能力，作为“R2C@telcoA.com，从发送到充当“broker.telcos.com”域的注册器的中间服务器R2C@pint.telcoA.com“详情如下：
REGISTER sip:registrar@broker.telcos.com SIP/2.0 To: sip:R2C@pint.telcoA.com From: sip:R2C@pint.telcoA.com ...
注册sip：registrar@broker.telcos.comSIP/2.0至：SIP：R2C@pint.telcoA.com发件人：sip:R2C@pint.telcoA.com ...
This is the standard SIP registration service.
这是标准的SIP注册服务。
However, what happens if there are a number of different Service Providers, all of whom support the "R2C" service? Suppose there is a PINT system at domain "broker.com". PINT clients requesting a Request-to-Call service from broker.com might be very willing to be redirected or proxied to any one of the various service providers that had previously registered with the registrar. PINT servers might also be interested in providing service for requests that did not specify the service provider explicitly, as well as those requests that were directed "at them".
但是，如果有许多不同的服务提供商，他们都支持“R2C”服务，会发生什么情况？假设域“broker.com”中有一个PINT系统。从broker.com请求呼叫服务的PINT客户端可能非常愿意被重定向或代理到以前在注册中心注册过的各种服务提供商中的任何一个。PINT服务器可能也有兴趣为未明确指定服务提供者的请求以及“针对它们”的请求提供服务。
To enable such service, PINT servers would REGISTER at the broker PINT server registrations of the form:
为了启用此类服务，PINT服务器将在代理PINT服务器注册，注册形式如下：
REGISTER sip:registrar@broker.com SIP/2.0
To: sip:R2C@broker.com
From: sip:R2C@pint.telcoA.com
REGISTER sip:registrar@broker.com SIP/2.0
To: sip:R2C@broker.com
From: sip:R2C@pint.telcoA.com
When several such REGISTER messages appear at the registrar, each differing only in the URL in the From: line, the registrar has many possibilities, e.g.:
当多个这样的注册信息出现在注册器上时，每个信息仅在From:行中的URL上有所不同，注册器有许多可能性，例如：
(i) it overwrites the prior registration for "R2C@broker.telcos.com" when the next comes in;
(i) 它覆盖了“的先前注册”R2C@broker.telcos.com“当下一个进来时；
(ii) it rejects the subsequent registration for "R2C@broker.telcos.com";
（ii）拒绝随后的“注册”R2C@broker.telcos.com";
(iii) it maintains all such registrations.
（iii）其保留所有此类登记。
In this last case, on receiving an Invitation for the "general" service, either:
在最后一种情况下，在收到“一般”服务的邀请后：
(iii.1) it passes on the invitation to all registered service providers, returning a collated response with all acceptances, using multiple Location: headers, or (iii.2) it silently selects one of the registrations (using, for example, a "round robin" approach) and routes the Invitation and response onwards without further comment.
（iii.1）它将邀请传递给所有注册的服务提供商，使用多个位置：标题返回一个包含所有接受的经过整理的响应，或（iii.2）它默默地选择一个注册（例如使用“循环”方法），并将邀请和响应转发，无需进一步评论。
As an alternative to all of the above approaches, it:
作为上述所有方法的替代方法，它：
(iv) may choose to not allow registrations for the "general" service, rejecting all such REGISTER requests.
（iv）可选择不允许注册“一般”服务，拒绝所有此类注册请求。
The algorithm by which such a choice is made will be implementation-dependent, and is outside the scope of PINT. Where a behaviour is to be defined by requesting users, then some sort of call processing language might be used to allow those clients, as a pre-service operation, to download the behaviour they expect to the server making such decisions. This, however, is a topic for other protocols, not for PINT.
做出这种选择的算法将取决于实现，并且不在PINT的范围之内。如果行为是由请求用户定义的，那么可以使用某种呼叫处理语言，作为服务前操作，允许这些客户机将他们期望的行为下载给做出此类决策的服务器。然而，这是其他协议的主题，而不是PINT。
6.4. Limitations on Available Information and Request Timing for SUBSCRIBE
6.4. 对可用信息和订阅请求时间的限制
A reference configuration for PINT is that service requests are sent, via a PINT Gateway, to an Executive System that fulfills the Service Control Function (SCF) of an Intelligent Network (see [11]). The success or failure of the resulting service call may be information available to the SCF and so may potentially be made available to the PINT Gateway. In terms of historical record of whether or not a service succeeded, a large SCF may be dealing with a million call attempts per hour. Given that volume of service transactions, there
PINT的参考配置是，通过PINT网关将服务请求发送到执行系统，该执行系统实现智能网络的服务控制功能（SCF）（参见[11]）。结果服务呼叫的成功或失败可能是SCF可用的信息，因此可能使PINT网关可用。根据服务是否成功的历史记录，一个大型SCF每小时可能要处理一百万次呼叫尝试。考虑到服务交易量，有
are finite limits beyond which it cannot store service disposition records; expecting to find out if a Fax was sent last month from a busy SCF is unrealistic.
是有限的限制，超过该限制，它无法存储服务处置记录；想要知道上个月是否从繁忙的SCF发送了传真是不现实的。
Other status changes, such as that on completion of a successful service call, require the SCF to arrange monitoring of the service call in a way that the service may not do normally, for performance reasons. In most implementations, it is difficult efficiently to interrupt a service to change it once it has begun execution, so it may be necessary to have two different services; one that sets GSTN resources to monitor service call termination, and one that doesn't. It is unlikely to be possible to decide that monitoring is required once the service has started.
其他状态更改（如成功完成服务呼叫时的状态更改）需要SCF安排对服务呼叫的监控，以使服务出于性能原因无法正常进行。在大多数实现中，一旦服务开始执行，就很难有效地中断服务以对其进行更改，因此可能需要有两个不同的服务；一个设置GSTN资源以监视服务调用终止，另一个不设置。一旦服务启动，就不可能决定是否需要监控。
These factors can have implications both on the information that is potentially available at the PINT Gateway, and when a request to register interest in the status of a PINT service can succeed. The alternative to using a general SCF is to provide a dedicated Service Node just for PINT services. As this node is involved in placing all service calls, it is in a position to collect the information needed. However, it may well still not be able to respond successfully to a registration of interest in call state changes once a service logic program instance is running.
这些因素可能会影响PINT网关上潜在可用的信息，以及PINT服务状态的注册请求何时能够成功。使用通用SCF的替代方案是仅为PINT服务提供专用服务节点。由于该节点参与放置所有服务调用，因此它能够收集所需的信息。然而，一旦服务逻辑程序实例正在运行，它可能仍然无法成功响应调用状态更改中的感兴趣的注册。
Thus, although a Requesting User may register an interest in the status of a service request, the PINT Gateway may not be in a position to comply with that request. Although this does not affect the protocol used between the Requestor and the PINT Gateway, it may influence the response returned. To avoid the problem of changing service logic once running, any registration of interest in status changes should be made at or before the time at which the service request is made.
因此，尽管请求用户可以注册对服务请求的状态的兴趣，但PINT网关可能无法满足该请求。虽然这不会影响请求者和PINT网关之间使用的协议，但可能会影响返回的响应。为避免运行后更改服务逻辑的问题，应在发出服务请求时或之前进行状态更改的任何相关注册。
Conversely, if a historical request is made on the disposition of a service, this should be done within a short time after the service has completed; the Executive System is unlikely to store the results of service requests for long; these will have been processed as AMA (Automatic Message Accounting) records quickly, after which the Executive System has no reason to keep them, and so they may be discarded.
相反，如果在处置服务时提出历史请求，则应在服务完成后的短时间内完成；执行系统不太可能长期存储服务请求的结果；这些将被迅速处理为AMA（自动消息记帐）记录，之后执行系统没有理由保留它们，因此它们可能会被丢弃。
Where the PINT Gateway and the Executive System are intimately linked, the Gateway can respond to status subscription requests that occur while a service is running. It may accept these requests and simply not even try to query the Executive System until it has information that a service has completed, merely returning the final status. Thus the PINT Requestor may be in what it believes is a monitoring state, whilst the PINT Gateway has not even informed the
当PINT网关和执行系统紧密相连时，网关可以响应服务运行时发生的状态订阅请求。它可能会接受这些请求，甚至不尝试查询执行系统，直到它获得服务已完成的信息，而只是返回最终状态。因此，PINT请求者可能处于其认为的监控状态，而PINT网关甚至没有通知用户
Executive System that a request has been made. This will increase the internal complexity of the PINT Gateway in that it will have a complex set of interlocking state machines, but does mean that status registration and indication CAN be provided in conjunction with an I.N. system.
已发出请求的执行系统。这将增加PINT网关的内部复杂性，因为它将有一组复杂的联锁状态机，但这确实意味着可以结合I.N.系统提供状态注册和指示。
6.5. Parameters needed for invoking traditional GSTN Services within PINT
6.5. 在PINT中调用传统GSTN服务所需的参数
This section describes how parameters needed to specify certain traditional GSTN services can be carried within PINT requests.
本节介绍如何在PINT请求中携带指定某些传统GSTN服务所需的参数。
When a Requesting User asks for a service to be performed, he or she will, of course, have to specify in some way which service. This can be done in the URLs within the To: header and the Request-URI (see section 3.5.5.1).
当请求用户请求执行服务时，他或她当然必须以某种方式指定要执行的服务。这可以在To:头和请求URI内的URL中完成（请参见第3.5.5.1节）。
With the Request-to-Call service, they will also need to specify the A and B parties they want to be engaged in the resulting service call. The A party could identify, for example, the Call Center from which they want a call back, whilst the B party is their telephone number (i.e. who the Call Center agent is to call).
对于请求呼叫服务，他们还需要指定他们希望参与结果服务呼叫的A方和B方。例如，A方可以识别他们想要回拨的呼叫中心，而B方是他们的电话号码（即呼叫中心代理将呼叫谁）。
The Request-to-Fax and Request-to-Hear-Content services require the B party to be specified (respectively the telephone number of the destination Fax machine or the telephone to which spoken content is to be delivered), but the A party is a Telephone Network based resource (either a Fax or speech transcoder/sender), and is implicit; the Requesting User does not (and cannot) specify it.
“传真请求”和“收听请求”内容服务要求指定乙方（分别是目标传真机的电话号码或将语音内容发送到的电话号码），但甲方是基于电话网络的资源（传真或语音转码器/发送方），且是隐式的；请求用户没有（也不能）指定它。
With the "Fax-Back" variant of the Request-to-Fax service, (i.e. where the content to be delivered resides on the GSTN) they will also have specify two parties. As before, the B party is the telephone number of the fax machine to which they want a fax to be sent. However, within this variant the A party identifies the "document context" for the GSTN-based document store from which a particular document is to be retrieved; the analogy here is to a GSTN user dialling a particular telephone number and then entering the document number to be returned using "touch tone" digits. The telephone number they dial is that of the document store or A party, with the "touch tone" digits selecting the document within that store.
对于“传真请求”服务的“传真回”变体（即，要交付的内容驻留在GSTN上的位置），他们还将指定两方。如前所述，乙方是他们希望发送传真的传真机的电话号码。然而，在此变体中，A方确定了基于GSTN的文档存储的“文档上下文”，从中检索特定文档；这里的类比是GSTN用户拨打特定电话号码，然后使用“按键”数字输入要返回的文件号码。他们拨打的电话号码是文档存储或一方的电话号码，通过“按键”数字选择该存储中的文档。
In terms of the extra parameters to the request, the services again differ. The Request-to-Call service needs only the A and B parties. Also it is convenient to assert that the resulting service call will carry voice, as the Executive System within the destination GSTN may be able to check that assertion against the A and B party numbers specified and may treat the call differently.
就请求的额外参数而言，服务也有所不同。呼叫请求服务只需要A方和B方。此外，断言产生的服务呼叫将携带语音也是方便的，因为目的地GSTN内的执行系统可能能够根据指定的A和B方号码检查该断言，并且可能以不同的方式对待该呼叫。
With the Request-to-Fax and Request-to-Hear-Content services, the source information to be transcoded is held on the Internet. That means either that this information is carried along with the request itself, or that a reference to the source of this information is given.
通过请求传真和请求收听内容服务，将要转码的源信息保存在互联网上。这意味着要么该信息与请求本身一起携带，要么提供对该信息来源的引用。
In addition, it is convenient to assert that the service call will carry fax or voice, and, where possible, to specify the format for the source information.
此外，可以方便地断言服务呼叫将携带传真或语音，并在可能的情况下指定源信息的格式。
The GSTN-based content or "Fax-Back" variant of the Request-to-Fax service needs to specify the Document Store number and the Fax machine number to which the information is to be delivered. It is convenient to assert that the call will carry Fax data, as the destination Executive System may be able to check that assertion against the document store number and that of the destination Fax machine.
基于GSTN的内容或传真请求服务的“传真回”变体需要指定文档存储编号和信息要传递到的传真机编号。断言呼叫将携带传真数据是很方便的，因为目的地执行系统可能能够根据文档存储号码和目的地传真机的号码检查该断言。
In addition, the document number may also need to be sent. This parameter is an opaque reference that is carried through the Internet but has significance only within the GSTN. The document store number and document number together uniquely specify the actual content to be faxed.
此外，可能还需要发送文件编号。该参数是一个不透明的参考，通过互联网传输，但仅在GSTN中具有重要意义。文档存储编号和文档编号一起唯一地指定要传真的实际内容。
The following table summarises the information needed in order to specify fully the intent of a GSTN service request. Note that it excludes any other parameters (such as authentication or authorisation tokens, or Expires: or CallId: headers) that may be used in a request.
下表总结了完全指定GSTN服务请求意图所需的信息。请注意，它不包括可能在请求中使用的任何其他参数（如身份验证或授权令牌，或Expires:或CallId:头）。
Service ServiceID AParty BParty CallFmt Source SourceFmt
------- --------- ------ ------ ------- ------ -------
R2C x x x voice - -
R2F x - x fax URI/IL ISF/ILSF
R2FB x x x fax OR -
R2HC x - x voice URI/IL ISF/ILSF
Service ServiceID AParty BParty CallFmt Source SourceFmt
------- --------- ------ ------ ------- ------ -------
R2C x x x voice - -
R2F x - x fax URI/IL ISF/ILSF
R2FB x x x fax OR -
R2HC x - x voice URI/IL ISF/ILSF
In this table, "x" means that the parameter is required, whilst "-" means that the parameter is not required.
在本表中，“x”表示需要该参数，而“-”表示不需要该参数。
The Services listed are Request-to-Call (R2C), Request-to-Fax (R2F), the GSTN-based content or "Fax-back" Variant of Request-to-Fax (R2FB), and Request-to-Hear-Content (R2HC).
列出的服务包括呼叫请求（R2C）、传真请求（R2F）、基于GSTN的内容或传真请求（R2FB）的“传真回”变体以及收听请求内容（R2HC）。
The Call Format parameter values "voice" or "fax" indicate the kind of service call that results.
呼叫格式参数值“voice”或“fax”表示产生的服务呼叫类型。
The Source Indicator "URI/IL" implies that the information is either an Internet source reference (a Universal Resource Identifier, or URI) or is carried "in-line" with the message. The Source indicator "OR" means that the value passed is an Opaque Reference that should be carried along with the rest of the message but is to be interpreted only within the destination (GSTN) context. As an alternative, it could be given as a "local" reference with the "file" style, or even using a partial reference with the "http" style. However, the way in which such a reference is interpreted is a matter for the receiving PINT Server and Executive System; it remains, in effect, an opaque reference.
源指示符“URI/IL”意味着信息要么是因特网源引用（通用资源标识符，或URI），要么与消息“串联”在一起。源指示符“OR”表示传递的值是一个不透明的引用，应该与消息的其余部分一起携带，但只能在目标（GSTN）上下文中解释。作为替代方案，它可以作为带有“文件”样式的“本地”引用，甚至可以使用带有“http”样式的部分引用。然而，这种引用的解释方式由接收PINT服务器和执行系统决定；实际上，它仍然是一个不透明的参考。
The Source Format value "ISF/ILSF" means that the format of the source is specified either in terms of the URI or that it is carried "in-line". Note that, for some data, the format either can be detected by inspection or, if all else fails, can be assumed from the URI (for example, by assuming that the file extension part of a URL indicates the data type). For an opaque reference, the Source Format is not available on the Internet, and so is not given.
源格式值“ISF/ILSF”表示源的格式是根据URI指定的，或者是“在线”携带的。请注意，对于某些数据，可以通过检查来检测格式，或者，如果所有其他方法都失败，则可以从URI中假定格式（例如，假定URL的文件扩展名部分指示数据类型）。对于不透明引用，源格式在Internet上不可用，因此未给出。
This section describes the way in which the parameters needed to specify a GSTN service request fully might be carried within a "PINT extended" message. There are other choices, and these are not precluded. However, in order to ensure that the Requesting User receives the service that they expect, it is necessary to have some shared understanding of the parameters passed and the behaviour expected of the PINT Server and its attendant Executive System.
本节描述了完全指定GSTN服务请求所需的参数在“PINT扩展”消息中的传输方式。还有其他选择，但这些选择并不排除。然而，为了确保请求用户收到他们期望的服务，有必要对传递的参数和PINT服务器及其助理执行系统的预期行为有一些共同的理解。
The Service Identifier can be sent as the userinfo element of the Request-URI. Thus, the first line of a PINT Invitation would be of the form:
服务标识符可以作为请求URI的userinfo元素发送。因此，一品脱邀请函的第一行应为：
INVITE <serviceID>@<pint-server>.<domain> SIP/2.0
INVITE <serviceID>@<pint-server>.<domain> SIP/2.0
The A Party for the Request-to-Call and "Fax-back" variant of Request-to-Fax service can be held in the "To:" header field. In this case the "To:" header value will be different from the Request-URI. In the services where the A party is not specified, the "To:" field is free to repeat the value held in the Request-URI. This is the case for Request-to-Fax and Request-to-Hear-Content services.
请求呼叫的A方和请求传真服务的“传真回”变体可以保存在“收件人：”标题字段中。在这种情况下，“To:”头值将不同于请求URI。在未指定参与方的服务中，“To:”字段可以自由重复请求URI中的值。这是请求传真和请求收听内容服务的情况。
The B party is needed in all these milestone services, and can be held in the enclosed SDP sub-part, as the value of the "c=" field.
所有这些里程碑服务都需要乙方，并且可以作为“c=”字段的值保存在随附的SDP子部分中。
The call format parameter can be held as part of the "m=" field value. It maps to the "transport protocol" element as described in section 3.4.2 of this document.
调用格式参数可以作为“m=”字段值的一部分保留。它映射到本文件第3.4.2节所述的“传输协议”元素。
The source format specifier is held in the "m=", as a type and either "-" or sub-type. The latter is normally required for all services except Request-to-Call or "Faxback", where the "-" form may be used. As shown earlier, the source format and source are not always required when generating requests for services. However, the inclusion in all requests of a source format specifier can make parsing the request simpler and allows for other services to be specified in the future, and so values are always given. The source format parameter is covered in section 3.4.2 as the "media type" element.
源格式说明符保存在“m=”中，作为一个类型和“-”或子类型。除要求致电或“传真回”外，所有服务通常都需要后者，其中可能使用“-”格式。如前所示，在生成服务请求时，并不总是需要源格式和源。但是，在所有请求中包含源格式说明符可以简化对请求的解析，并允许将来指定其他服务，因此总是给定值。第3.4.2节将源格式参数作为“媒体类型”元素介绍。
The source itself is identified by an "a=fmtp:" field value, where needed. With the exception of the Request-to-Call service, all invitations will normally include such a field. From the perspective of the SDP extensions, it can be considered as qualifying the media sub-type, as if to say, for example, "when I say jpeg, what I mean is the following".
如果需要，源本身由“a=fmtp:”字段值标识。除请求呼叫服务外，所有邀请通常都会包含这样一个字段。从SDP扩展的角度来看，可以将其视为限定媒体子类型，例如，好像说“当我说jpeg时，我的意思是以下内容”。
In summary, the parameters needed by the different services are carried in fields as shown in the following table:
总之，不同服务所需的参数在下表所示的字段中携带：
Service Svc Param PINT/SIP or SDP field used Example value
------- --------- -------------------------- -------------
R2C
ServiceID: <SIP Request-URI userinfo> R2C
AParty: <SIP To: field> sip:123@p.com
BParty: <SDP c= field> TN RFC2543 4567
CallFormat: <SDP transport protocol
sub-field of m= field> voice
SourceFmt: <SDP media type sub-field
of m= field> audio
(--- only "-" sub-type
sub-field value used) ---
Source: (--- No source specified) ---
Service Svc Param PINT/SIP or SDP field used Example value
------- --------- -------------------------- -------------
R2C
ServiceID: <SIP Request-URI userinfo> R2C
AParty: <SIP To: field> sip:123@p.com
BParty: <SDP c= field> TN RFC2543 4567
CallFormat: <SDP transport protocol
sub-field of m= field> voice
SourceFmt: <SDP media type sub-field
of m= field> audio
(--- only "-" sub-type
sub-field value used) ---
Source: (--- No source specified) ---
R2F
ServiceID: <SIP Request-URI userinfo> R2F
AParty: (--- SIP To: field not used) sip:R2F@pint.xxx.net
BParty: <SDP c= field> TN RFCxxx +441213553
CallFormat: <SDP transport protocol
sub-field of m= field> fax
SourceFmt: <SDP media type sub-field
of m= field> image
<SDP media sub-type sub-field
of m= field> jpeg
Source: <SDP a=fmtp: field qualifying
preceding m= field> a=fmtp:jpeg<uri-ref>
R2F
ServiceID: <SIP Request-URI userinfo> R2F
AParty: (--- SIP To: field not used) sip:R2F@pint.xxx.net
BParty: <SDP c= field> TN RFCxxx +441213553
CallFormat: <SDP transport protocol
sub-field of m= field> fax
SourceFmt: <SDP media type sub-field
of m= field> image
<SDP media sub-type sub-field
of m= field> jpeg
Source: <SDP a=fmtp: field qualifying
preceding m= field> a=fmtp:jpeg<uri-ref>
R2FB
ServiceID: <SIP Request-URI userinfo> R2FB
AParty: <SIP To: field> sip:1-730-1234@p.com
BParty: <SDP c= field> TN RFCxxx +441213553
CallFormat: <SDP transport protocol
sub-field of m= field> fax
SourceFmt: <SDP media type sub-field
of m= field> image
<SDP media sub-type sub-field
of m= field> jpeg
Source: <SDP a=fmtp: field qualifying
preceding m= field> a=fmtp:jpeg opr:1234
R2FB
ServiceID: <SIP Request-URI userinfo> R2FB
AParty: <SIP To: field> sip:1-730-1234@p.com
BParty: <SDP c= field> TN RFCxxx +441213553
CallFormat: <SDP transport protocol
sub-field of m= field> fax
SourceFmt: <SDP media type sub-field
of m= field> image
<SDP media sub-type sub-field
of m= field> jpeg
Source: <SDP a=fmtp: field qualifying
preceding m= field> a=fmtp:jpeg opr:1234
R2HC
ServiceID: <SIP Request-URI userinfo> R2HC
AParty: (--- SIP To: field not used) sip:R2HC@pint.ita.il
BParty: <SDP c= field> TN RFCxxx +441213554
CallFormat: <SDP transport protocol
sub-field of m= field> voice
SourceFmt: <SDP media type sub-field
of m= field> text
<SDP media sub-type sub-field
of m= field> html
Source: <SDP a=fmtp: field qualifying
preceding m= field> a=fmtp:html<uri-ref>
R2HC
ServiceID: <SIP Request-URI userinfo> R2HC
AParty: (--- SIP To: field not used) sip:R2HC@pint.ita.il
BParty: <SDP c= field> TN RFCxxx +441213554
CallFormat: <SDP transport protocol
sub-field of m= field> voice
SourceFmt: <SDP media type sub-field
of m= field> text
<SDP media sub-type sub-field
of m= field> html
Source: <SDP a=fmtp: field qualifying
preceding m= field> a=fmtp:html<uri-ref>
[1] Handley, M., Schooler, E., Schulzrinne, H. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[1] Handley，M.，Schooler，E.，Schulzrinne，H.和J.Rosenberg，“SIP：会话启动协议”，RFC 25431999年3月。
[2] Handley, M. and V. Jacobsen, "SDP: Session Description Protocol", RFC 2327, April 1998.
[2] Handley，M.和V.Jacobsen，“SDP：会话描述协议”，RFC 2327，1998年4月。
[3] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[3] Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第一部分：互联网邮件正文格式”，RFC 20451996年11月。
[4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[4] Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年11月。
[5] The Unicode Consortium, "The Unicode Standard -- Version 2.0", Addison-Wesley, 1996.
[5] Unicode联盟，“Unicode标准——2.0版”，Addison Wesley，1996年。
[6] ITU-T Study Group 2, "E.164 - The International Public Network Numbering Plan", ITU-T, June 1997.
[6] ITU-T研究小组2，“E.164——国际公共网络编号计划”，ITU-T，1997年6月。
[7] Lu, H., Krishnaswamy, M., Conroy, L., Bellovin, S., Burg, F., DeSimone, A., Tewani, K., Davidson, P., Schulzrinne, H. and K. Vishwanathan "Toward the PSTN/Internet Inter-Networking--Pre-PINT Implementations", RFC 2458, November 1998.
[7] 卢，H.，克里希纳斯瓦米，M.，康罗伊，L.，贝洛文，S.，伯格，F.，德西莫内，A.，特瓦尼，K.，戴维森，P.，舒尔兹林内，H.和K.维什瓦纳坦，“走向PSTN/互联网互联——品脱前的实施”，RFC 2458，1998年11月。
[8] ITU-T Study Group XI, "Q.763 - Formats and Codes for the ISDN User Part of SS No7" ITU-T, August 1994.
[8] ITU-T研究小组席，“Q.763 -格式和代码的ISDN用户部分的SS N7”ITU-T，1994年8月。
[9] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[9] Berners Lee，T.，Fielding，R.和L.Masinter，“统一资源标识符（URI）：通用语法”，RFC 2396，1998年8月。
[10] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.
[10] Crocker，D.，“ARPA互联网文本信息格式标准”，STD 11，RFC 822，1982年8月。
[11] ITU-T Study Group XI, "Q.1204 - IN Distributed Functional Plane Architecture", ITU-T, February 1994.
[11] ITU-T研究小组席，“Q.04-在分布式功能平面架构”，ITU-T，1994年2月。
[12] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[12] Dierks，T.和C.Allen，“TLS协议1.0版”，RFC 2246，1999年1月。
[13] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[13] Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[14] Housley, R., Ford, W., Polk W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", RFC 2459, January 1999.
[14] Housley，R.，Ford，W.，Polk W.和D.Solo，“互联网X.509公钥基础设施证书和CRL配置文件”，RFC 2459，1999年1月。
[15] Crocker, D. and P. Overall, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[15] Crocker，D.和P.总体，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[16] Mills, D., "Network Time Protocol (version 3) specification and implementation", RFC 1305, March 1992.
[16] Mills，D.，“网络时间协议（第3版）规范和实施”，RFC13051992年3月。
[17] Eastlake, D., Crocker, S. and J.Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[17] Eastlake，D.，Crocker，S.和J.Schiller，“安全性的随机性建议”，RFC 1750，1994年12月。
[18] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987.
[18] Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 10351987年11月。
[19] Levinson, E., "The MIME Multipart/Related Content-type" RFC 2387, August 1998.
[19] Levinson，E.，“MIME多部分/相关内容类型”RFC 2387，1998年8月。
The authors wish to thank the members of the PINT working group for comments that were helpful to the preparation of this specification. Ian Elz's comments were extremely useful to our understanding of internal PSTN operations. The SUBSCRIBE and NOTIFY requests were first suggested by Henning Schulzrinne and Jonathan Rosenberg. The suggestion to use an audio port of 0 to express that the phone is "on hold" (i.e. not receiving voice) is due to Ray Zibman. Finally, thanks to Bernie Hoeneisen for his close proofreading.
作者希望感谢PINT工作组成员的意见，这些意见有助于本规范的编制。Ian Elz的评论对我们理解内部PSTN运营非常有用。订阅和通知请求首先由Henning Schulzrinne和Jonathan Rosenberg提出。建议使用音频端口0表示手机处于“保留”（即未接收语音）状态是由于Ray Zibman提出的。最后，感谢伯尼·霍内森的仔细校对。
Appendix A: Collected ABNF for PINT Extensions
附录A：为品脱扩展收集的ABNF
;; --(ABNF is specified in RFC 2234 [15])
;; --(ABNF is specified in RFC 2234 [15])
;; --Variations on SDP definitions
;; --Variations on SDP definitions
connection-field = ["c=" nettype space addrtype space
connection-address CRLF]
; -- this is the original definition from SDP, included for completeness
; -- the following are PINT interpretations and modifications
connection-field = ["c=" nettype space addrtype space
connection-address CRLF]
; -- this is the original definition from SDP, included for completeness
; -- the following are PINT interpretations and modifications
nettype = ("IN"/"TN")
; -- redefined as a superset of the SDP definition
nettype = ("IN"/"TN")
; -- redefined as a superset of the SDP definition
addrtype = (INAddrType / TNAddrType)
; -- redefined as a superset of the SDP definition
addrtype = (INAddrType / TNAddrType)
; -- redefined as a superset of the SDP definition
INAddrType = ("IP4"/"IP6")
; -- this non-terminal added to hold original SDP address types
INAddrType = ("IP4"/"IP6")
; -- this non-terminal added to hold original SDP address types
TNAddrType = ("RFC2543"/OtherAddrType)
TNAddrType = ("RFC2543"/OtherAddrType)
OtherAddrType = (<X-Token>)
; -- X-token is as defined in RFC2045
OtherAddrType = (<X-Token>)
; -- X-token is as defined in RFC2045
addr = (<FQDN> / <unicast-address> / TNAddr)
; -- redefined as a superset of the original SDP definition
; -- FQDN and unicast address as specified in SDP
addr = (<FQDN> / <unicast-address> / TNAddr)
; -- redefined as a superset of the original SDP definition
; -- FQDN and unicast address as specified in SDP
TNAddr = (RFC2543Addr/OtherAddr)
; -- TNAddr defined only in context of nettype == "TN"
TNAddr = (RFC2543Addr/OtherAddr)
; -- TNAddr defined only in context of nettype == "TN"
RFC2543Addr = (INPAddr/LDPAddr)
RFC2543Addr = (INPAddr/LDPAddr)
INPAddr = "+" <POS-DIGIT> 0*(("-" <DIGIT>)/<DIGIT>)
; -- POS-DIGIT and DIGIT as defined in SDP
INPAddr = "+" <POS-DIGIT> 0*(("-" <DIGIT>)/<DIGIT>)
; -- POS-DIGIT and DIGIT as defined in SDP
LDPAddr = <DIGIT> 0*(("-" <DIGIT>)/<DIGIT>)
LDPAddr = <DIGIT> 0*(("-" <DIGIT>)/<DIGIT>)
OtherAddr = 1*<uric>
; -- OtherAdd defined in the context of OtherAddrType
; -- uric is as defined in RFC2396
OtherAddr = 1*<uric>
; -- OtherAdd defined in the context of OtherAddrType
; -- uric is as defined in RFC2396
media-field = "m=" media <space> port <space> proto
1*(<space> fmt) <CRLF>
; -- NOTE redefined as subset/relaxation of original SDP definition
; -- space and CRLF as defined in SDP
media-field = "m=" media <space> port <space> proto
1*(<space> fmt) <CRLF>
; -- NOTE redefined as subset/relaxation of original SDP definition
; -- space and CRLF as defined in SDP
media = ("application"/"audio"/"image"/"text")
; -- NOTE redefined as a subset of the original SDP definition
; -- This could be any MIME discrete type; Only those listed are
; -- used in PINT 1.0
media = ("application"/"audio"/"image"/"text")
; -- NOTE redefined as a subset of the original SDP definition
; -- This could be any MIME discrete type; Only those listed are
; -- used in PINT 1.0
port = ("0" / "1")
; -- NOTE redefined from the original SDP definition;
; -- 0 retains usual sdp meaning of "temporarily no media"
; -- (i.e. "line is on hold")
; -- (1 means there is media)
port = ("0" / "1")
; -- NOTE redefined from the original SDP definition;
; -- 0 retains usual sdp meaning of "temporarily no media"
; -- (i.e. "line is on hold")
; -- (1 means there is media)
proto = (INProto/TNProto)
; -- redefined as a superset of the original SDP definition
proto = (INProto/TNProto)
; -- redefined as a superset of the original SDP definition
INProto = 1* (<alpha-numeric>)
; -- this is the "classic" SDP protocol, defined if nettype == "IN"
; -- alpha-numeric is as defined in SDP
TNProto = ("voice"/"fax"/"pager")
; -- this is the PINT protocol, defined if nettype == "TN"
INProto = 1* (<alpha-numeric>)
; -- this is the "classic" SDP protocol, defined if nettype == "IN"
; -- alpha-numeric is as defined in SDP
TNProto = ("voice"/"fax"/"pager")
; -- this is the PINT protocol, defined if nettype == "TN"
fmt = (<subtype> / "-")
; -- NOTE redefined as a subset of the original SDP definition
; -- subtype as defined in RFC2046, or "-". MUST be a subtype of type
held
; -- in associated media sub-field or the special value "-".
fmt = (<subtype> / "-")
; -- NOTE redefined as a subset of the original SDP definition
; -- subtype as defined in RFC2046, or "-". MUST be a subtype of type
held
; -- in associated media sub-field or the special value "-".
attribute-fields = *("a=" attribute-list <CRLF>)
; -- redefined as a superset of the definition given in SDP
; -- CRLF is as defined in SDP
attribute-fields = *("a=" attribute-list <CRLF>)
; -- redefined as a superset of the definition given in SDP
; -- CRLF is as defined in SDP
attribute-list = 1(PINT-attribute / <attribute>)
; -- attribute is as defined in SDP
attribute-list = 1(PINT-attribute / <attribute>)
; -- attribute is as defined in SDP
PINT-attribute = (clir-attribute / q763-nature-attribute /
q763plan-attribute / q763-INN-attribute /
phone-context-attribute / tsp-attribute /
pint-fmtp-attribute / strict-attribute)
PINT-attribute = (clir-attribute / q763-nature-attribute /
q763plan-attribute / q763-INN-attribute /
phone-context-attribute / tsp-attribute /
pint-fmtp-attribute / strict-attribute)
clir-attribute = clir-tag ":" ("true" / "false")
clir-attribute = clir-tag ":" ("true" / "false")
clir-tag = "clir"
clir-tag = "clir"
q763-nature-attribute = Q763-nature-tag ":" q763-natures
q763自然属性=q763自然标记“：“q763自然”
q763-nature-tag = "Q763-nature"
q763-nature-tag = "Q763-nature"
q763-natures = ("1" / "2" / "3" / "4")
q763-natures = ("1" / "2" / "3" / "4")
q763-plan-attribute = Q763-plan-tag ":" q763-plans
q763计划属性=q763计划标签“：“q763计划
q763-plan-tag = "Q763-plan"
q763-plan-tag = "Q763-plan"
q763-plans = ("1" / "2" / "3" / "4" / "5" / "6" / "7")
; -- of these, the meanings of 1, 3, and 4 are defined in the text
q763-plans = ("1" / "2" / "3" / "4" / "5" / "6" / "7")
; -- of these, the meanings of 1, 3, and 4 are defined in the text
q763-INN-attribute = Q763-INN-tag ":" q763-INNs
q763酒店属性=q763酒店标签“：“q763酒店
q763-INN-tag = "Q763-INN"
q763-INN-tag = "Q763-INN"
q763-INNs = ("0" / "1")
q763-INNs = ("0" / "1")
phone-context-attribute = phone-context-tag ":" phone-context-ident
电话上下文属性=电话上下文标记“：“电话上下文标识”
phone-context-tag = "phone-context"
phone-context-tag = "phone-context"
phone-context-ident = network-prefix / private-prefix
phone-context-ident = network-prefix / private-prefix
network-prefix = intl-network-prefix / local-network-prefix
网络前缀=国际网络前缀/本地网络前缀
intl-network-prefix = "+" 1*<DIGIT>
intl-network-prefix = "+" 1*<DIGIT>
local-network-prefix = 1*<DIGIT>
local-network-prefix = 1*<DIGIT>
private-prefix = 1*excldigandplus 0*<uric>
private-prefix = 1*excldigandplus 0*<uric>
excldigandplus = (0x21-0x2d,0x2f,0x40-0x7d))
tsp-attribute = tsp-tag "=" provider-domainname
excldigandplus = (0x21-0x2d,0x2f,0x40-0x7d))
tsp-attribute = tsp-tag "=" provider-domainname
tsp-tag = "tsp"
tsp-tag = "tsp"
provider-domainname = <domain>
; -- domain is defined in RFC1035
provider-domainname = <domain>
; -- domain is defined in RFC1035
; -- NOTE the following is redefined relative to the normal use in SDP
pint-fmtp-attribute = "fmtp:" <subtype> <space> resolution
*(<space> resolution)
(<space> ";" 1(<attribute>) *(<space>
<attribute>))
; -- subtype as defined in RFC2046.
; -- NOTE that this value MUST match a fmt on the ultimately preceeding
; -- media-field
; -- attribute is as defined in SDP
; -- NOTE the following is redefined relative to the normal use in SDP
pint-fmtp-attribute = "fmtp:" <subtype> <space> resolution
*(<space> resolution)
(<space> ";" 1(<attribute>) *(<space>
<attribute>))
; -- subtype as defined in RFC2046.
; -- NOTE that this value MUST match a fmt on the ultimately preceeding
; -- media-field
; -- attribute is as defined in SDP
resolution = (uri-ref / opaque-ref / sub-part-ref)
resolution = (uri-ref / opaque-ref / sub-part-ref)
uri-ref = uri-tag ":" <URI-Reference>
uri-ref = uri-tag ":" <URI-Reference>
; -- URI-Reference defined in RFC2396
; -- RFC2396中定义的URI引用
uritag = "uri"
uritag = "uri"
opaque-ref = opr-tag ":" 0*<uric>
opaque-ref = opr-tag ":" 0*<uric>
opr-tag = "opr"
opr-tag = "opr"
sub-part-ref = spr-tag ":" <Content-ID>
; -- Content-ID is as defined in RFC2046 and RFC822
sub-part-ref = spr-tag ":" <Content-ID>
; -- Content-ID is as defined in RFC2046 and RFC822
spr-tag = "spr"
spr-tag = "spr"
strict-attribute = "require:" att-tag-list
strict attribute=“require:”att标签列表
att-tag-list = 1(PINT-att-tag-list / <att-field> /
pint-fmtp-tag-list)
*(","
(PINT-att-tag-list / <att-field> /
pint-fmtp-tag-list)
)
; -- att-field as defined in SDP
att-tag-list = 1(PINT-att-tag-list / <att-field> /
pint-fmtp-tag-list)
*(","
(PINT-att-tag-list / <att-field> /
pint-fmtp-tag-list)
)
; -- att-field as defined in SDP
PINT-att-tag-list = (phone-context-tag / clir-tag /
q763-nature-tag / q763-plan-tag /
q763-INN-tag)
PINT-att-tag-list = (phone-context-tag / clir-tag /
q763-nature-tag / q763-plan-tag /
q763-INN-tag)
pint-fmtp-tag-list = (uri-tag / opr-tag / spr-tag)
pint-fmtp-tag-list = (uri-tag / opr-tag / spr-tag)
;; --Variations on SIP definitions
;; --Variations on SIP definitions
clir-parameter = clir-tag "=" ("true" / "false")
clir-parameter = clir-tag "=" ("true" / "false")
q763-nature-parameter = Q763-nature-tag "=" Q763-natures
q763自然参数=q763自然标记“=”q763自然
q763plan-parameter = Q763-plan-tag "=" q763plans
q763plan参数=Q763计划标签“=”q763plans
q763-INN-parameter = Q763-INN-tag "=" q763-INNs
q763 INN参数=q763 INN标记“=”q763 INN
tsp-parameter = tsp-tag "=" provider-domainname
tsp参数=tsp标记“=”提供程序域名
phone-context-parameter = phone-context-tag "=" phone-context-ident
电话上下文参数=电话上下文标记“=”电话上下文标识
SIP-param = ( <transport-param> / <user-param> / <method-param> /
<ttl-param> / <maddr-param> / <other-param> )
; -- the values in this list are all as defined in SIP
SIP-param = ( <transport-param> / <user-param> / <method-param> /
<ttl-param> / <maddr-param> / <other-param> )
; -- the values in this list are all as defined in SIP
PINT-param = ( clir-parameter / q763-nature-parameter /
PINT-param = ( clir-parameter / q763-nature-parameter /
q763plan-parameter / q763-INN-parameter/ tsp-parameter / phone-context-parameter )
q763plan参数/q763 INN参数/tsp参数/电话上下文参数）
URL-parameter = (SIP-param / PINT-param)
; -- redefined SIP's URL-parameter to include ones defined in PINT
URL-parameter = (SIP-param / PINT-param)
; -- redefined SIP's URL-parameter to include ones defined in PINT
Require-header = "require:" 1(required-extensions)
*("," required-extensions)
; -- NOTE this is redefined as a subset of the SIP definition
; -- (from RFC2543/section 6.30)
Require-header = "require:" 1(required-extensions)
*("," required-extensions)
; -- NOTE this is redefined as a subset of the SIP definition
; -- (from RFC2543/section 6.30)
required-extensions = ("org.ietf.sip.subscribe" /
"org.ietf.sdp.require")
required-extensions = ("org.ietf.sip.subscribe" /
"org.ietf.sdp.require")
Appendix B: IANA Considerations
附录B：IANA考虑事项
There are three kinds of identifier used in PINT extensions that SHOULD be registered with IANA, if a new value is specified. These are:
如果指定了新值，PINT扩展中使用的标识符有三种，应向IANA注册。这些是：
* Media Format sub-types, as described in section 3.4.2 of this document. * Private Attributes as mentioned in section 3.4.3 * Private Phone Context values, as described in section 3.4.3.1.
* 媒体格式子类型，如本文件第3.4.2节所述。*第3.4.3节*私人电话上下文值中提到的私人属性，如第3.4.3.1节所述。
It should be noted that private Address Types (in section 3.4.1) have been explicitly excluded from this process, as they must be in the form of an X-Token.
应该注意的是，私有地址类型（在第3.4.1节中）已明确排除在该过程之外，因为它们必须以X令牌的形式存在。
Taking these in turn, the media format sub-types are used within the PINT extensions to SDP to specify the attribute line that holds the data source definitions. In normal use, the values in this field are sub-types of MIME discrete types[4]. If a value other than an IANA-registered sub-type is to be used, then it should either be an X-Token (i.e. start with "X-") or it should be registered with IANA. if the intention is to describe a new MIME sub-type, then the procedures specified in RFC 2048 should be used. It is ASSUMED that any new MIME sub-type would follow the syntactic rules for interpretation of associated PINT fmtp lines defined in this document.
反过来，在SDP的PINT扩展中使用媒体格式子类型来指定保存数据源定义的属性行。在正常使用中，此字段中的值是MIME离散类型的子类型[4]。如果要使用IANA注册子类型以外的值，则该值应为X标记（即以“X-”开头）或应向IANA注册。如果目的是描述新的MIME子类型，则应使用RFC 2048中指定的过程。假设任何新的MIME子类型都将遵循解释本文档中定义的相关PINT fmtp行的语法规则。
Note that, in keeping with the SDP description, such registrations SHOULD include the "proto" field values within which they are defined; however, it is appropriate to specify only that they can be used with "all values of TNProto".
注意，根据SDP描述，此类注册应包括定义它们的“proto”字段值；但是，只指定它们可以与“TNProto的所有值”一起使用是合适的。
Conversely, if the intent is to define a new way of including data source definitions within PINT, then it will be necessary to specify, in the documentation supporting any such new "PINT Media Format Sub-type" registration, the syntax of the associated "fmtp" attribute line, as the identifier serves to indicate the interpretation that should be made of format specific attribute lines "tagged" with such a sub-type.
相反，如果目的是定义在PINT中包含数据源定义的新方法，则有必要在支持任何此类新“PINT媒体格式子类型”注册的文档中指定相关“fmtp”属性行的语法，因为标识符用于指示应使用此类子类型“标记”特定于格式的属性行的解释。
If the fmtp interpretation follows the PINT default, then it is adequate to mention this in the defining document rather than repeating the syntax definition given here (although, in this case, it is unclear why such a new registration would be required). As before, the Media Format sub-type SHOULD specify the values of "proto" field within which it is defined, but this can be "all values of TNProto".
如果fmtp解释遵循PINT默认值，那么在定义文档中提及这一点就足够了，而不是重复这里给出的语法定义（尽管在这种情况下，不清楚为什么需要这样的新注册）。与前面一样，媒体格式子类型应该指定定义它的“proto”字段的值，但这可以是“TNProto的所有值”。
Any proprietary attribute lines that are added may be registered with IANA using the procedures mentioned in [2]; the mechanism is the same as that used in SDP. If the attribute is defined for use only within PINT, then it may be appropriate to mention this in the supporting documentation. Note that, in the PINT 1.0 specification covered here, there is no mechanism to add such freshly registered attribute lines to a "require:" clause.
添加的任何专有属性行可以使用[2]中提到的程序向IANA注册；该机制与SDP中使用的机制相同。如果该属性定义为仅在PINT中使用，则在支持文档中提及该属性可能是合适的。请注意，在这里介绍的PINT 1.0规范中，没有任何机制将这些新注册的属性行添加到“require:”子句中。
Within the session description used for PINT requests, a phone-context attribute may be used to specify the prefix or context within which an associated telephone-number (in a connection line) should be interpreted.
在用于PINT请求的会话描述中，电话上下文属性可用于指定前缀或上下文，在该前缀或上下文中，关联的电话号码（在连接线路中）应在其中进行解释。
For "public" phone contexts the prefix to be used MUST start with either a DIGIT or a "+". Private phone contexts may be registered with IANA that do NOT start with either of these characters. Such a prefix may be useful to identify a private network, potentially with an associated numeric ID (see example 4 in section 3.4.3.1). In the example, the prefix acts as the context for X-acme.com's private network numbering plan.
对于“公共”电话上下文，要使用的前缀必须以数字或“+”开头。私人电话上下文可以向IANA注册，但不能以这些字符中的任何一个开头。这样的前缀可能有助于识别可能具有相关数字ID的专用网络（见第3.4.3.1节中的示例4）。在本例中，前缀充当X-acme.com专用网络编号计划的上下文。
It is recommended that any private context to be registered have the general form of a token including a domain name, optionally followed by a digit string or other token. The appropriate form of the initial token name space will be similar to that used for private or vendor registrations for sub-types (e.g. vnd.acme.com). However, note that the registration will be used to specify a customer's private network numbering plan format rather than being used generally for all of
建议要注册的任何私有上下文具有令牌的一般形式，包括域名，可选地后跟数字字符串或其他令牌。初始令牌名称空间的适当形式将类似于用于子类型（例如vnd.acme.com）的私有或供应商注册的形式。但是，请注意，注册将用于指定客户的专用网络编号计划格式，而不是通常用于所有客户
their equipment vendor's customer's; thus, fbi.gov would be appropriate, but lucent.com would not (unless the private network were to be that used by Lucent internally).
其设备供应商的客户；因此，fbi.gov是合适的，而lucent.com则不合适（除非专用网络是朗讯内部使用的）。
In addition, the supporting documentation MUST either declare that there is no associated token, or define the syntax by which that token can be parsed (e.g. vnd.fbi.gov <space> 1*DIGIT). Note that the registration describes a format, not a value range; it is sufficient that the private context can be parsed, without the value being interpreted.
此外，支持文档必须声明没有关联的令牌，或者定义解析该令牌的语法（例如vnd.fbi.gov<space>1*DIGIT）。请注意，注册描述的是格式，而不是值范围；在不解释值的情况下，可以解析私有上下文就足够了。
In detail, the registration request SHOULD include:
具体而言，注册申请应包括：
* Kind of registration (i.e. private phone-context attribute to be used within the service description of PINT service requests) * Contact details for the person responsible for the registration request (name, organisation, e-mail address, public telephone number) * Private Prefix initial token name (e.g. vnd.fbi.gov) * syntax for private context (e.g. "vnd.fbi.gov" <space> 1*DIGIT, or "vnd.gtn.gov.uk") * Description of use (e.g. "This phone context declares an associated telephone number to be within the 'government telecommunications network'; the number is in an internal or private number plan form) * Network Type and Address Type with which this private context is associated; If the "normal" telephone types (as specified in this document) are used, then the values would be shown as: "nettype=TN" , addrtype="RFC2543Addr". If, however, this context were to be used with another address type, then a reference to that address type name and the syntax of that address value would be required.
* 注册类型（即PINT服务请求的服务描述中使用的私人电话上下文属性）*负责注册请求的人员的联系方式（姓名、组织、电子邮件地址、公共电话号码）*私人前缀初始令牌名称（例如vnd.fbi.gov）*私人上下文语法（例如，“vnd.fbi.gov”<space>1*位，或“vnd.gtn.gov.uk”）*使用说明（例如，“此电话上下文声明相关电话号码位于“政府电信网络”内；该号码以内部或专用号码计划形式存在）*与此专用上下文相关联的网络类型和地址类型；如果”如果使用普通的“电话类型”（如本文档中所述），则值将显示为：“nettype=TN”，addrtype=“RFC2543Addr”。但是，如果此上下文用于另一个地址类型，则需要引用该地址类型名称和该地址值的语法。
In short, this context is the telephone equivalent of a "Net 10" address space behind a NAT, and the initial name (and contact information) shows the context within which that address is valid. It also specifies the format for the network and address types (and address value syntax) with which this context is associated.
简而言之，此上下文相当于NAT后面的“Net 10”地址空间的电话，初始名称（和联系信息）显示该地址有效的上下文。它还指定与此上下文关联的网络和地址类型（以及地址值语法）的格式。
Of course, IANA may refer the requested registration to the IESG or an appropriate IETF working group for review, and may require revisions to be made before the registration is accepted.
当然，IANA可以将请求的注册提交给IESG或适当的IETF工作组审查，并可能要求在注册被接受之前进行修改。
Authors' Addresses
作者地址
Scott Petrack MetaTel, Inc. 45 Rumford Ave. Waltham MA 02453-3844
马萨诸塞州沃尔瑟姆拉姆福德大道45号斯科特·佩特拉克梅泰尔公司，邮编02453-3844
Phone: +1 (781)-891-9000
EMail: scott.petrack@metatel.com
Phone: +1 (781)-891-9000
EMail: scott.petrack@metatel.com
Lawrence Conroy Siemens Roke Manor Research Roke Manor Old Salisbury Lane Romsey, Hampshire U.K. SO51 0ZN
劳伦斯康罗伊西门子洛克庄园研究洛克庄园老索尔兹伯里巷罗姆赛，汉普希尔英国SO51 0Zn
Phone: +44 (1794) 833666
EMail: lwc@roke.co.uk
Phone: +44 (1794) 833666
EMail: lwc@roke.co.uk
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
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编辑功能的资金目前由互联网协会提供。