RFC 2848
The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services
RFC 2848: The PINT Service Protocol ✨
okay bestie, welcome to RFC 2848! 🦋 This one is all about the PINT Service Protocol, which lets your IP network ask the telephone network to do stuff for you. Here's the title block tea:
- Network Working Group: the group this lived in 🌸
- Authors: S. Petrack from MetaTel and L. Conroy from Siemens Roke Manor Research 👑
- Category: Standards Track, so it's an official Internet standard 💅
- Date: June 2000 📅
- Obsoletes or updates: the title block doesn't list anything, so this one isn't replacing or changing any earlier RFC 🙈
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. 🫶
Copyright Notice ©️
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract 🎀
okay so this doc is the spec for the PINT Service Protocol 1.0 🔥 It's a protocol that lets you invoke certain telephone services from an IP network, and we're talking the iconic stuff: placing basic calls, sending and receiving faxes, and receiving content over the phone 📞 The protocol is built as a set of enhancements and additions to SIP 2.0 and SDP, so it's basically an upgrade pack for two protocols you probably already know and love 💜
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
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 ........................................ 731. Introduction ✨
Okay bestie, so SO many groups have wanted to invoke phone services from the Internet 📞💖 (users, public and private network operators, call center service providers, and equipment vendors, see [7]). The generic scenario goes like this when the invocation works out:
- an IP host sends a request to a server on an IP network;
- the server relays the request into a telephone network;
- the telephone network performs the requested call service.
Picture this: a customer wants someone in a business's support department to call them back 💅. Or a user wants to hear a weather warning from a remote automatic weather service when a storm rolls in ⛈️. Main character energy, literally.
We use the term "PSTN/Internet Interworking (PINT) Service" to mean the whole transaction ✨, starting with the request sent from an IP client and including the phone call itself. PINT services are distinguished by the fact that they always involve two separate networks:
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 🦋.
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, though, to develop a protocol that is aligned with other Internet protocols where possible 🫶, so future extensions to PINT could grow alongside Internet conferencing.
Within the Internet conference architecture, establishing media calls is done with a combination of protocols 🎀. SIP [1] is used to establish the association between the participants within the call (this association 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, adding some extensions and enhancements so that SIP clients and servers can become PINT clients and servers 🧚.
A PINT user who wants 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 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.
When SIP is used to invoke a PINT service, it 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 🌸.
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, that is no guarantee against a subsequent failure of audio hardware 🙈.)
The particular requirements of PINT users lead to some new messages 💜. When a PINT server agrees to send a fax to telephone B, the fax transmission may fail after part of the fax is sent. So 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 🔥.
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 the protocol specified here can handle a much wider class of call services than just the Milestone services 👑.
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 🍓.
For a summary of the extensions to SIP and SDP specified in this document, section 3.2 gives a combined list, plus one each describing the extensions to SIP and SDP respectively.
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 🫶💅.
1.1 Glossary
- Requestor - An Internet host from which a request for service originates.
- PINT Service - A service invoked within a phone system in response to a request received from a PINT client.
- PINT Client - An Internet host that sends requests for invocation of a PINT Service, in accordance with this document.
- PINT Gateway - An Internet host that accepts requests for PINT Service and dispatches them onwards towards a telephone network.
- 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.
- 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) 🧚.
2. PINT Milestone Services 💖
The original motivation for defining this protocol was the desire to invoke the following three telephone network services from within an IP network:
2.1 Request to Call
A request is sent from an IP host that causes a phone call to be made, connecting party A to some remote party B 📞.
2.2 Request to Fax Content
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 📠.
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 🙈.
2.3 Request to Speak/Send/Play Content
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 a Web page with 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 🌸.
2.4 Relation between PINT milestone services and traditional telephone services
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 📞.
There may be thousands of agents in the call center, and there may be any number of sophisticated algorithms and pieces of equipment 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 will the original user be called. Or perhaps the user might be called first, and hear some horrible music or a 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 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) 🎀.
3. PINT Functional and Protocol Architecture ✨
3.1. PINT Functional Architecture ✨
Okay bestie, first things first: you need to already know SIP 2.0 [1] and SDP [2], because familiarity is assumed 💅
PINT clients and servers are SIP clients and servers 🦋 SIP carries the request over the IP network to the correct PINT server in a secure and reliable way 🔒 and SDP describes the telephone network session that's supposed to be invoked, or whose status is supposed to come back 📞
A PINT system uses SIP proxy servers and redirect servers for their usual purpose, but at some point there has to be a PINT server that can relay incoming requests into a telephone system and receive acknowledgements for those relayed requests. A PINT server with this ability is called a "PINT gateway" 🌈 To a SIP system, a PINT gateway looks like a User Agent Server. Here's the twist: to the PINT infrastructure, a PINT gateway seems like it represents a "user", but really it represents a whole telephone network infrastructure that can provide a bunch of telephone network services 🤯
So the PINT system might look like this to an individual PINT client:
/\/\/\/\/\/\/\ /\/\/\/\/\/\/\/\
___________ \ __/___ ___\_ \
| PINT | PINT \ PINT | PINT | |Exec| Telephone /
| client |<-------------->| server |gatewy|=====|Syst| Network \
|_________| protocol / cloud |______| |____| Cloud /
\ \ / \
/\/\/\/\/\/\/\ \/\/\/\/\/\/\/\/Figure 1: PINT Functional Architecture
The system of PINT servers gets drawn as a cloud ☁️ because a single PINT request might bounce through a series of location servers, proxy servers, and redirect servers before it finally reaches the right PINT gateway, the one that can actually process it by passing it to the Telephone Network Cloud.
The PINT gateway might have a true telephone network interface, or it might connect via some other protocol or API to an "Executive System" that can invoke services inside the telephone cloud 🔌
For example, inside an I.N. (Intelligent Network) system, the PINT gateway might act like the Service Control Gateway Function 👑 In an office, it might be a server adjunct to the office PBX, connected to both the office LAN and the office PBX 🏢
The Executive System that sits beyond the PINT gateway is outside the scope of PINT 🙈
3.2. PINT Protocol Architecture 🌸
This section explains how SIP and SDP work together to carry the info needed to invoke telephone network sessions 💜
Here's the rundown of the extension features used in PINT 1.0 ✨ Then we look at SDP and SIP separately:
- 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
- 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.
Both PINT and SIP rely on features of MIME[4] 🎀 Using SIP 2.0 is implied by PINT 1.0, and that also implies compliance with version 1.0 of MIME 💅
3.2.1. SDP operation in PINT 🦋
The SDP payload describes the particular telephone network session the requestor wants to happen in the GSTN 📞 That includes stuff like the telephone network address (aka the "telephone number") of the terminal(s) in the call, the media type to be carried (e.g. audio, text, image or application data), and whether the info goes over the telephone network via voice, fax, or pager transport. If there's content to send to the remote telephone terminal, that's included too 📨
SDP is flexible enough to convey these parameters independently 🧠 For example, a request to send some text via voice transport gets fulfilled by invoking a text-to-speech-over-the-phone service, and a request to send text via fax gets fulfilled by invoking a text-to-fax service 🖨️
Here's the list of PINT 1.0 enhancements and additions to SDP:
- 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)
- 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)
3.2.2. SIP Operation in PINT 💖
SIP carries the request for telephone service from the PINT client to the PINT gateway, and it may include a telephone number if the particular service needs one 📱 Here's the complete list of PINT enhancements and additions to 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)
Section 3.5.8 has remarks about how BYE requests get used within PINT 🧚 This isn't an extension to baseline SIP. It's just here to clarify the semantics when it's used with telephone network sessions 💀
3.3. REQUIRED and OPTIONAL elements for PINT compliance 🎀
Of all 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, and references to Data Objects in requests are the most likely to show up in PINT requests 📦
Each of the other new PINT constructs enables a different function, and a client or server that wants to enable that particular function MUST do so by the construct specified in this document 🔥 For example, building a PINT client and server that only provides the Request-to-Call telephone call service, without support for the other Milestone services, is allowed 📞✨
The "Require:" SIP header and the "require" attribute give clients and servers a mechanism to signal their need and/or ability to support specific "new" PINT protocol elements 🚦
It's worth noting 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 describe the preferred language of the callee 🌍 Another is using the t= parameter to indicate the time the PINT service is to be invoked, which 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 🙌
Flip side: support for Data Objects within Internet Conference sessions might be useful even if the goal isn't a GSTN service request 💻 In that case, the extensions covering these items can be slotted into an otherwise "plain" SIP/SDP invitation. Likewise, support for SDP "require" might be useful as a framework for adding features to a "traditional" SIP/SDP infrastructure 🧱 Again, these can be convenient to fold into SIP/SDP implementations that would never be used for PINT service requests. Those additions are beyond the scope of this document though 🙈
3.4. PINT Extensions to SDP 🦋
PINT 1.0 adds the ability to describe audio, fax, and pager telephone sessions to SDP 📞 It's 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 like "ISDN" or "GSM" are not defined 🚫 Similarly, the transport protocols are just called "fax", "voice", and "pager", with no more specific identifiers for the various telephone network voice, fax, or pager protocols 📠 And the data to be transported is only identified by a MIME content type, like "text" data, "image" data, or some more general "application" data 🗂️
One important example of transporting "application" data is the milestone service "Voice Access to Web Content" 🌐 In that case, the data is 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 🗣️
This section gives the details of the new SDP keywords 💜
3.4.1. Network Type "TN" and Address Type "RFC2543" 💜
The TN ("Telephone Network") network type indicates that the terminal is connected to a telephone network ☎️
The address types allowed for network type TN are "RFC2543" and private address types, and private address types MUST begin with an "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 ⚠️
Examples:
c= TN RFC2543 +1-201-406-4090
c= TN RFC2543 12014064090A telephone-subscriber string is one of two types: global-phone-number or local-phone-number. You tell them apart by putting a "plus" sign ("+") in front of a global-phone-number 🌍 A global-phone-number is interpreted by default as an internationally significant E.164 Number Plan Address, as defined by [6]. A local-phone-number is a number specified in the default dialling plan within the context of the recipient PINT Gateway 📍
An implementation MAY use private addressing types, which can be useful within a local domain 🏠 These address types MUST begin with an "X-", and they SHOULD contain a domain name after the X-, for example "X-mytype.mydomain.com" 🌸 Here's what that kind of connection line looks like:
c= TN X-mytype.mydomain.com A*8-HELENIn that line, "X-mytype.mydomain.com" identifies this private address type, and "A*8-HELEN" is the number in this format. A format like this is defined as an "OtherAddr" in the ABNF of Appendix A 📖 Also, most dialable telephone numbers can be written as local-phone-numbers within address RFC2543, so new address types SHOULD only be used for formats that can't be written that way 🙌
3.4.2. Support for Data Objects within PINT ✨
okay so this is where PINT gets SO good 💖 one big difference from regular SIP/SDP Internet Conference sessions is that a PINT service request can point at a Data Object to use as source info. for example, a request can say "fax this document" 📠 or a GSTN service can take a Web page, have a vocoder read it out, and speak it over a phone call 🎙️📞
the SDP spec doesn't have explicit support for referencing or carrying Data Objects inside requests 🥺 so to use SDP for PINT, you basically have to describe the whole thing as "a telephone call to a certain number during which such-and-such an image is sent as a fax" 🖼️✨
to make that work, the session description format gets two extensions 🎀 first, some new allowed values for the Media Field. second, a description of the "fmtp" parameter when it's used with those Media Field values (inside the Contact Field Network type "TN" context).
there's also an addition to the SIP message format, so data objects can be included as sub-parts inside the request message itself 🧚 the original SDP syntax (from [2]) for media-field looks like this:
media-field = "m=" media space port ["/" integer]
space proto 1*(space fmt) CRLFwhen it's used in PINT requests, the sub-fields are expanded a little bit 💅 the Media sub-field is relaxed to accept all of the discrete "top-level" media types defined in [4]. the milestone services don't use the discrete type "video", and the extra types "data" and "control" aren't needed for them either. using those types isn't precluded, but what a PINT Gateway is expected to do when it gets a request including one of them is not defined here 🤷♀️
the Port sub-field has no meaning in PINT requests, since the destination terminals are specified with "TN" addressing. so in PINT requests it's normally set to 1. a value of 0 may be used, same as in SDP, to say the terminal isn't receiving media 📵 this is handy for showing that a telephone terminal has gone "on hold" for a bit 🫶 and the optional integer sub-field isn't used in PINT either.
as [2] mentions, the Transport Protocol sub-field depends on the Address Type it goes with. if the Address Type in the preceding Contact field is one of the ones defined for the Network Type "TN", these are the values for the Transport Protocol sub-field:
"voice", "fax", and "pager"
in PINT requests, this sub-field is about what happens to the resulting GSTN service 🔥 transport protocol "voice" means the service results in a GSTN voice call, "fax" means a GSTN fax transmission, and "pager" means a pager message gets sent 📟
heads up, this sub-field doesn't automatically tell you the media type and subtype of the source data 👀 for example, one of the milestone services has a textual source get vocoded and spoken in a phone call. in that case the transport protocol is "voice", but the media type is "text". iconic 💜
the Fmt sub-field is described in [2] as being specific to the transport protocol 🌸 when it's used in PINT requests with one of the protocol values above, it's a list of one or more values, and each one is a defined MIME sub-type of the matching Media sub-field value. the special value - is allowed and means there's no MIME sub-type 🙈 it still keeps the meaning it had in [2]: the list is a set of alternative sub-types, and the first one is the preferred one 🥇
for experimental purposes, and only with mutual consent from the sender and recipient, a sub-type can be written as an <X-token>, which is just a character string that starts with "X-" 🧪 honestly, using these is discouraged 🙅♀️ but if one of them is expected to find common use, it SHOULD be registered with IANA through the standard content type registration process (see Appendix C) 📝
when the Fmt parameter is just the single character - (a dash), it means an unspecified or default sub-type can be used for the service 🎲 so m=audio 1 voice -<CRLF> means a voice call is requested, using whatever audio sub-type the Executive System thinks is appropriate 🎧 PINT is a special case, because the request comes from the IP network but the service call happens within the GSTN 🌈 so the service request usually can't define the particular codec used for the resulting GSTN call. if that intent IS needed, the quality attribute can be used (see "Suggested Attributes" section of [2]) ✨
3.4.2.1. Use of fmtp attributes in PINT requests
okay, the rules for fmtp here are pretty strict 🔒 for each element of the Fmt sub-field, there MUST be a following fmtp attribute 💅 when it's used within PINT requests, the fmtp attribute has the general structure defined here:
"a=fmtp:" <subtype> <space> resolution
*(<space> resolution)
(<space> ";" 1(<attribute>)
*(<space> <attribute>))
where:
<resolution> := (<uri-ref> | <opaque-ref> | <sub-part-ref>)so an fmtp attribute describes the sources used with a given Fmt entry in the Media field 🧚 the entries in a Fmt sub-field are alternatives (preferred one first), and each entry gets a matching fmtp attribute. the list of resolutions in an fmtp attribute describes the set of sources that resolve that Fmt choice, and every element of that set gets used 🫧
one thing to note: for PINT services, the elements in that set get sent as a sequence 🔁 trying to send them in parallel is unlikely to work 🙃
an fmtp attribute can mix different kinds of element 🍓 for example, one attribute might have a sub-part-ref for data included in a sub-part of the current message, then an opaque-ref pointing to some content on the GSTN, and then a uri-ref pointing to data held out on the IP network. wild, but iconic 🌈
to show which form each resolution element takes, every one of them starts with its own literal tag. the detailed syntax for each form is in the sub-sections that follow 📚
3.4.2.2. Support for Remote Data Object References in PINT
when data objects stored elsewhere on the IP Network are being used as sources for a PINT service, they can be referred to using the uri-ref form 🌐 that's just a Uniform Resource Identifier (URI), as described in [9] 🔗
quick but important: the reference SHOULD be an absolute URI 🚨 there might not be enough context for the recipient server to resolve a relative reference. any use of relative references needs some private agreement between the sender and recipient, and it SHOULD be avoided unless the sender can be sure the recipient is the one intended and the reference is unambiguous in context 🙅♀️
this also goes for partial URIs (like "uri:http://aNode/index.htm") 🫠 those have to be resolved in the context of the eventual recipient of the message, so they're kind of a mess to rely on 😭
the general syntax for a reference to an Internet-based external data object in an fmtp line within a PINT session description is:
<uri-ref> := ("uri:" URI-reference)where URI-reference is as defined in Appendix A of [9] 💖 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.txtor:
c= TN RFC2543 +1-201-406-4090
m= text 1 fax plain
a=fmtp:plain
uri:http://www.ietf.org/meetings/glance_minneapolis.txtthat means: get this data object from the Internet and use it as a source for the requested GSTN Fax service 📠💕
3.4.2.3. Support for GSTN-based Data Objects in PINT
PINT services can also refer to data that lives not on the IP Network but inside the GSTN 🏠 how these items are indicated doesn't need any meaning inside the Requestor or the PINT Gateway. the reference is just some data the Executive System can use to figure out which content is meant as part of the request 🕵️♀️ these data form an opaque reference, which means they get sent "untouched" through the PINT infrastructure 🫶
a reference to a data object held on the GSTN has the general definition:
<opaque-ref> := ("opr:" *uric)where uric is as defined in Appendix A of [9] 🧠 for example:
c= TN RFC2543 +1-201-406-4090
m= text 1 fax plain
a=fmtp:plain opr:APPL.123.456that means: send the data that's 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 look at the Telephone URL in the To: field of the enclosing SIP message when it's deciding the context for the data object dereference 🔍
an opaque reference can also be used for other purposes 👑 for example, it could be needed to authorise access to a document held on the GSTN, instead of only disambiguating the data object. what an opaque reference is used for, though, is out of scope for this document 🙅♀️ it's just an indicator carried inside a PINT Request 🫧
an opaque reference can have no value when the value to be used is already implied by the rest of the request 🧚 for example, say some company wants to use PINT for a "fax-back service" 📠 in their current setup, the images to be faxed are completely defined by the telephone number that gets dialled. inside the PINT request, that telephone number shows up in the "To:" field, so there's no need for an opaque reference value 💅
if there are several resolutions for a PINT Service Request, and one of them is an opaque reference with no value, then that opaque reference MUST be included in the attribute line, but with an empty value field 🚨 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:this might be used to put a covering note before some data being faxed 📝💖
in the special case where an opaque reference is the only resolution of a PINT Service Request, AND that reference needs no value, there's no need for a Fmt list at all 🥳 the intent of the service is clear without any further resolution ✨ for example:
c= TN RFC2543 +1-201-406-4090
m= text 1 fax -that means there's implied content stored on the GSTN, and it's uniquely identified by the combination of the SIP To-URI and the Contact field of the session description 🔐🌸
3.4.2.4. Session Description support for included Data Objects ✨
okay so, instead of pointing to the data with a URI or an opaque reference to something sitting on the GSTN, you can just stuff the actual content right into the SIP request 📦 🫶 It's done with multipart MIME for the SIP payload. The first MIME part holds the SDP description of the telephone network session that's supposed to happen, and the other MIME parts carry the content data being transported.
Format specific attribute lines in the session description say which other MIME part in the request has the content data. So rather than a URI or opaque reference, the format-specific attribute gives the Content-ID of the MIME part that holds the actual data. It's defined like this:
<sub-part-ref> := ("spr:" Content-ID)where Content-ID is as defined in Appendix A of [3] and in [10]).
Here's an example, bestie:
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. This fragment means the requesting user wants the data object held in the sub-part labelled <Content-ID> to be faxed to the machine at phone number +1-201-406-4090. Iconic 🖨️💅
See also section 3.5.1 for a discussion on the support needed in the enclosing SIP request for included data objects.
3.4.3. Attribute Tags to pass information into the Telephone Network 🧚
okay so sometimes you want to include service parameters in the PINT request that only some entity inside the "Telephone Network Cloud" can understand. That's what SDP attribute parameters are for 💜 They MAY appear within a particular media description or outside of a media description.
These attributes can also show up as parameters within PINT URLs (see section 3.5.6) as part of a SIP request.
This matters because telephone terminals that need these attributes defined can show up in the To: line of a PINT request, as well as inside the PINT session descriptions. Main character energy for those terminals, honestly 👑
The whole point of these attributes is to let the client give extra context for how a particular telephone number should be interpreted. There are a bunch of reasons a number might need extra context:
- a. The telephone number might be reachable in many different ways (like through competing telephone service providers), and the PINT client wants to pick which service provider to use.
- b. The telephone number might only be reachable from a limited number of networks (like an '800' freephone number).
- c. The telephone number might only be reachable within a single telephone network (like the '152' customer service number of BT). Same deal with an internal corporate extension that can only be reached from inside the PBX 🏢
Now, as noted above, you usually don't need SDP attributes to specify the phone context 🙈 URLs like 152@pint.bt.co.il in the To: and From: headers and/or Request-URI usually give enough context to resolve telephone numbers. Slay, no extra work needed.
If the client wants the request to fail when the attributes aren't supported, these attributes SHOULD be used together with the "require" attribute (section 3.4.4) and the Require:org.ietf.sdp.require header (section 3.5.4). That's the move if you want a hard fail 🚫
It's not possible to standardise every possible internal telephone network parameter, ngl. PINT 1.0 attributes were picked for specification because they're common enough that lots of different PINT systems will want to use them. Having one shared spec means interoperability goes up 📈 🦋
Proprietary attribute "a=" lines are by definition not interoperable, but they can still be useful when you need to carry some proprietary internal telephone network variables over the IP network. For example, you could use them to say what order the service call legs should be made in. These private attributes SHOULD BE, however, subject to the same IANA registration procedures mentioned in the SDP specification[2] (see also this Appendix C). Lowkey a little bureaucratic, but it keeps things tidy 🌸
3.4.3.1. The phone-context attribute 🎀
An attribute is specified to enable "remote local dialling". This is the service that lets a PINT client reach a number from way outside the area or network that can normally reach it. It's useful when the sending or receiving address is only dialable within some local context, which might be remote from where the PINT client is.
For example, say Alice wants to report a problem with her telephone. She might dial a "network wide" customer care number. Within the British Telecom network in the U.K., that's "152". Note that she doesn't dial any trunk prefix here, because this is the whole dialable number 🙃 If it's dialled from another operator's network, it won't connect to British Telecom's Engineering Enquiries service, and dialling "+44 152" will not normally succeed either. These are called Network-Specific Service Numbers.
Inside the telephone network, the "local context" comes from the physical connection between the subscriber's terminal and the central office. There might not be an analogous association between the PINT client and the PINT server that first receives the request, which is why you may need to supply this missing "telephone network context". This attribute is defined like so:
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*uricAn 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"). No fake prefixes, periodt 🙅♀️
You can register new private-prefixes with IANA so they don't collide with anyone else's. Prefixes that aren't registered MUST begin with an "X-" to show they're private and non-standard (see Appendix C). Think of the X- as a little flag that says "this one's mine" 🏳️🌈
Example 1:
c= TN RFC2543 1-800-765-4321
a=phone-context:+972This describes a terminal whose address in Israel (E.164 country code 972) is 1-800-765-4321.
Example 2:
c= TN RFC2543 1-800-765-4321
a=phone-context:+1This describes a terminal whose address in North America (E.164 country code 1) is 1-800-765-4321.
The two telephone terminals described in examples 1 and 2 are different. In fact, they're located in different countries 🌍 Same digits, totally different phone, wild.
Example 3:
c=TN RFC2543 123
a=phone-context:+97252This describes a terminal whose address, when dialled from within the network identified by +97252, is the string "123". Iykyk: +97252 is one of the Israeli cell phone providers, and 123 reaches customer service when dialled within that network 📱
It may well be useful or necessary to use the SDP "require" parameter together with the phone-context attribute.
Example 4:
c= TN RFC2543 321
a=phone-context:X-acme.com-23This might describe the telephone terminal at extension 321 of PBX number 23 inside the acme.com private PBX network. Such a description is expected to be understandable by the acme.com PINT server that receives the request 🧠
Note that if the PINT server receiving the request is inside the acme.com network, the same terminal might be addressable like this:
c= TN RFC2543 7-23-321(assuming that "7" is dialled in order to reach the private PBX network from within acme.com)
3.4.3.2. Presentation Restriction attribute 🙈
Okay this one has no effect on how the service request travels through the IP Network, but there can be a requirement to let originators of a PINT service request say whether they want the "B party" in the resulting service call to see the "A party's" calling telephone number. It's a legal requirement in some jurisdictions that a caller can choose whether their correspondent can find out their calling number (using Automatic Number Indication, Caller Display or Calling Line Identity Presentation equipment). So an attribute might be needed to show the originator's preference 💖
Whether 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. It's also not mandatory in every territory for a PINT Gateway or Executive System to act on this attribute. It's 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 👑
The attribute is specified as follows:
a=clir:<"true" | "false">This boolean value is needed within the attribute because the GSTN address might by default be set to NOT present its identity to correspondents, while the originator wants to present it for this particular call. That fits the aim of this attribute, which is to let the originator specify what treatment they want for the requested service call 🫶
The expected interpretation is this: if the attribute is present and the value is "false", then the Calling Line Identity CAN be presented to the correspondent terminal. If it's "true", then, if possible, the Executive System is requested to NOT present the Calling Line Identity. 🔥
3.4.3.3. ITU-T CalledPartyAddress attributes parameters 📞
okay so these attributes line up with fields in the ITU-T Q.763 "CalledPartyAddress" field (see [8] ,section 3.9) 💅 PINT clients use them to spell out extra details about a Terminal Address when the address is a "local-phone-number" ✨ And if the PINT request points at a GSTN terminal, these details might be needed to actually pin down that remote terminal 📞🦋
The general form of the attribute looks like this:
a=Q763-<token>((":" <value>) |"")Three of the possible elements, and how they show up in SDP attributes, are covered here 🌸 If anyone wants to use other Q763 elements, they'll need their own spec to define how the attribute gets mapped. Any spec like that is recommended to keep the value sets shown in Q.763 💜
The defined attributes are:
a=Q763-nature: 🌈 This one indicates the "nature of address indicator". The value MAY be any number between 0 and 127, and these values are specified:
"1" a subscriber number
"2" unknown
"3" a nationally significant number
"4" an internationally significant numberThe values were picked to match the ones in Q.763. Just know that other values are possible, depending on national rules or future expansion of Q.763 ✨
a=Q763-plan: 🍓 This one indicates the numbering plan the address belongs to. The value MAY be any number between 0 and 7, and these values are specified:
"1" Telephone numbering plan (ITU-T E.164)
"3" Data numbering plan (ITU-T X.121)
"4" Telex numbering plan (ITU-T F.69)Again, these match Q.763. Other values are allowed too, according to national rules or future expansion of Q.763 🌸
a=Q763-INN 🔥 This one indicates whether routing to the Internal Network Number is allowed. The value MUST be ONE of:
"0" routing to internal network number allowed
"1" routing to internal network number not
allowedThese values also match Q.763 💅
Here's a sneaky one 👀 It's possible to use a local-phone-number and then use attributes to say the number is actually an internationally significant E.164 number. But normally this SHOULD NOT be done 🙈 An internationally significant E.164 number gets indicated by using a "global-phone-number" for the address string instead 🫶
3.4.4. The "require" attribute 🔒
okay so according to the SDP spec, a PINT server is allowed to just ignore attribute parameters it doesn't understand 🙃 But if a client wants to force a server to decline a request when it doesn't understand one of the PINT attributes, the client SHOULD use the "require" attribute 💖 It looks like this:
a=require:<attribute-list>Where the attribute-list is a comma-separated list of attributes that show up somewhere else in the session description ✨
To process the request successfully, the PINT server must BOTH understand the attribute AND ALSO fulfill the request implied by the presence of that attribute. This goes for every attribute listed in the require attribute's attribute-list 💅
If the server doesn't recognise an attribute on the list, the PINT server MUST return an error status code (like 420 (Bad Extension) or 400 (Bad Request)). It SHOULD also return suitable Warning: lines explaining the problem, or an Unsupported: header containing the attribute it doesn't understand 🦋 If the server does recognize the attribute but can't fulfill the request that the attribute implies, the request MUST be rejected with a status code of (606 Not Acceptable), along with a suitable Unsupported: header or Warning: line 💀
The "require" attribute can show up anywhere in the session description, and as many times as needed 🌈 But it MUST appear before the use of the attribute that's marked as required 🫶
Since the "require" attribute is itself an attribute, the SIP specification lets a server that doesn't understand it just ignore it 😭 So to make sure the PINT server actually complies with the "require" attribute, a PINT client SHOULD include a Require: header with the tag "org.ietf.sdp.require" (section 3.5.4) 🧚
Also, most of the PINT extensions are "tagged", and those tags can be put in Require strictures ✨ The exception is phone numbers in SDP parts. But those are defined as a new network and address type, so a receiving SIP/SDP server should be able to tell whether it supports those forms 👑 The default behaviour for any SDP recipient is to fail a PINT request if it doesn't recognise or support the TN and RFC2543 or X-token network and address types, because without the contents being recognised, no media session could be created. So a separate stricture isn't required in this case 💜
3.5. PINT Extensions to SIP 2.0 🎀
okay so PINT requests are SIP requests, period 💅 A lot of the specs in this document just explain how to use existing SIP facilities for PINT purposes 🌸
3.5.1. Multi-part MIME (sending data along with SIP request) 📦
A PINT request can carry a payload that's multipart MIME 🎁 In that 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 ✨ The later parts hold content data that can be transferred to the requested Telephone Call Service 💖 As we talked about earlier, inside a single PINT request, some of the data MAY be pointed to by a URI in the request, and some of the data MAY be included right in the request 🦋
When included data rides along in a PINT service request, the Content Type entity header of the enclosing SIP message MUST indicate this 😭 To do that, the media type value in this header MUST be set to "multipart" 🌈 There's a content sub-type made for exactly this situation, where sub-parts get handled together. It's multipart/related (defined in [19]), and its use is recommended 🫶
The enclosed body parts SHOULD include the part-specific Content Type headers where they make sense ("application/sdp" for the first body part holding the session description, plus an appropriate content type for each of the later "included data object" parts) 🧚 This matches the standard syntax of MIME multipart messages as defined in [4] 🍓
For example, say the boundary is "------next-------". The first two parts might look like this:
------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
This is the text that is to be paged to +1-201-406-4090
----------next-----------Being able to offer different alternatives for the content is super useful, even when those alternatives are included in the request too 💅 For instance, a request to send a short message to a pager might include the message in Unicode [5], plus an alternative version of the same content in text/plain, in case the PINT server or telephone network can't process the Unicode 🌸
PINT clients should be extremely careful when sending included data in a PINT request 😬 Those requests SHOULD be sent via TCP, to avoid fragmentation and to transmit the data reliably 🔥 It's possible the PINT server is a proxy server that replicates and forks the request, which could be disastrous if the request carries a large amount of application data 💀 PINT proxy servers should be careful not to make lots of copies of a request with big chunks of data in it 🙈
If the client doesn't know where the PINT gateway actually is, and it's using SIP location services to find it, and the included data makes the PINT request likely to be transported in several IP datagrams, then it is RECOMMENDED that the initial PINT request not include the data object and instead hold a reference to it 🦋
3.5.2. Warning header ⚠️
A PINT server MUST support the SIP "Warning:" header so it can signal lack of support for individual PINT features 🎀 For example, imagine the PINT request is to send a jpeg picture to a fax machine, but the server can't retrieve and/or translate jpeg pictures from the Internet into fax transmissions 📠
In a case like that, the server fails the request and includes a Warning like this:
Warning: 305 pint.acme.com Incompatible media format: jpegSIP servers that don't understand the PINT extensions at all are strongly encouraged to implement Warning: headers to indicate that PINT extensions aren't understood 🌈
Also, Warning: headers may be included within NOTIFY requests if the client needs to be told about some condition related to the invocation of the PINT service (more on that next) 🧚
3.5.3. Mechanism to register interest in the disposition of a PINT service, and to receive indications on that disposition 👀
It can be super useful to find out whether a requested service has completed, and if so, whether it worked 💖 This matters a lot for PINT, since the person asking for the service isn't necessarily a party to it, so they might not have an easy way to check how it turned out 😭 It can also be useful to know when the service has changed state, like when the service call has started 📞
Setting up a flexible system for extensive monitoring and control during a service is non-trivial (see section 6.4 for some issues) 🧠 So PINT 1.0 uses a simple scheme that should still give useful info 💅 It's possible to expand the scheme in a "backwards compatible" way, so if needed it can be enhanced later 🦋
The PINT 1.0 status registration and indication scheme uses three new methods: SUBSCRIBE, UNSUBSCRIBE, and NOTIFY 🎀 These let a PINT client register an interest in the status of a service request (that's "subscribe"), indicate that a prior interest has lapsed (that's "unsubscribe" from the status), and let the server return service indications 🫶 The state machine for SUBSCRIBE/UNSUBSCRIBE is identical to INVITE/BYE 🌈 Just like 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 ✨ While that monitoring session is running, NOTIFY messages get sent to inform the subscriber of a change in session state or disposition 👑
3.5.3.1. Opening a monitoring session with a SUBSCRIBE request
okay so when a SUBSCRIBE request hits a PINT Server, it's basically saying "hey, I wanna know what's up with this service session" 👀. The request points at the session it cares about by including the original session description, and it uses the SDP global-session-id inside the origin-field to identify the service session uniquely 🔍.
The SUBSCRIBE request (like any other SIP request about an ongoing session) goes to the same server that got the original INVITE, or to a server that was named in the Contact: field of a later response (this might well be the PINT gateway for the session) 🦋.
Re-using the Call-ID from the original INVITE is sometimes possible, but not always 💅. If the person subscribing is the same one who started the service request, the Call-ID is fine because the receiver already knows it as a previously established session. But when the request comes from someone else, the SUBSCRIBE is a brand new SIP call leg, so the Call-ID SHOULD NOT be used 🙈. The only thing both sides share is the origin-field of the session description in the original service request, so that MUST be used 💜.
Instead of juggling two different ways to find the "session of interest," we just go with the origin-field of the SDP sub-part, which shows up in both the original INVITE and this SUBSCRIBE 🎀.
Note that the request MUST NOT include any sub-parts other than the session description, even if they were in the original INVITE 🚫. And a server MUST ignore whatever sub-parts are included in a SUBSCRIBE request, with the sole exception of the enclosed session description 🧹.
The request MAY contain a Contact: header, which tells the PINT User Agent Server where to send the info 📬.
It SHOULD also have an Expires: header saying how long the PINT Requestor wants to be notified about the session status ⏰. We call the time before that SUBSCRIBE expires the "subscription period" 🌸. Check section 5.1.4. for security considerations, especially the privacy stuff, because it is not nothing 🔐.
An Expires: value of 0 means "just give me one single immediate response," aka the request expires right away ⚡. It's totally possible to have a bunch of monitoring sessions open, exist, and complete, all for the same service session 🔁.
A successful response to the SUBSCRIBE includes the session description, according to the Gateway. Normally it's identical to the last cached response the Gateway gave for any request about the same SDP global session id (see [2], section 6, o= field) 📚. The t= line can change to show the actual start or stop time, though ⏱️. The Gateway might also add an i= line to say stuff like how many fax pages got sent 📠.
The Gateway SHOULD include an Expires: header showing how long it's willing to keep the monitoring session going 🕰️. If that timing is unacceptable to the PINT Requestor, they can close the session by sending an immediate UNSUBSCRIBE message (see 3.5.3.3) 🙅.
In principle, a user might send a SUBSCRIBE after the telephone network service has finished 🌙. That's how you check "the morning after" to see if the fax went through 📠✨. But a PINT gateway is only required to keep state about a call for as long as it said in an Expires: header, whether that was in the response to the original INVITE, the response to the SUBSCRIBE, the response to any UNSUBSCRIBE, or its own UNSUBSCRIBE (but see section 3.5.8, point 3) 🧠.
If the Server no longer has a record of the session the Requestor SUBSCRIBEd to, it returns "606 Not Acceptable," along with the appropriate Warning: 307 header saying the SDP session ID is no longer valid 💀. So a Client that knows it'll want status info after the session terminates SHOULD send a SUBSCRIBE request before the session terminates 🫶.
3.5.3.2. Sending Status Indications with a NOTIFY request
During the subscription period, the Gateway may, from time to time, send a spontaneous NOTIFY request to the entity named in the Contact: header of the "opening" SUBSCRIBE 📣. This usually happens whenever the status of the service session the Requestor subscribed to changes 🔔.
The receiving user agent server MUST acknowledge this by sending back a final response (normally a "200 OK") 🙌. In this version of the PINT extensions, the Gateway is not required to support redirects (3xx codes), so it may treat them as a failure 🙃.
So if the response code class is above 2xx, the Gateway may treat that as a failure of the monitoring session, and in that case it will immediately attempt to close the session (see next) 💔.
The NOTIFY request contains the modified session description ✏️. For example, the Gateway may be able to indicate a more accurate start or stop time ⏰.
The Gateway may include a Warning: header to describe some problem with the invocation of the service, and it may indicate within an i= line some information about the telephone network session itself 📞.
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=...3.5.3.3. Closing a monitoring session with an UNSUBSCRIBE request
At some point, either the Client's representative User Agent Server or the Gateway may decide to end the monitoring session 🎬. This is done by sending an UNSUBSCRIBE request to the correspondent server 🚪. It basically says "I'm closing this monitoring session right now," and once the final response comes back from the receiving server, the session is deemed over 🏁.
Here's the thing: 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 say the monitoring session is closed 🤯. (This is kinda like how a gateway never sends an INVITE, but it can send a BYE to say a telephone call has ended 📞.)
If the Gateway starts closing the monitoring session by sending an UNSUBSCRIBE message, it SHOULD include an "Expires:" header showing how much longer after the session is closed it's willing to store info on the service session 🗓️. That acts as a minimum window for the Client to send a new SUBSCRIBE and open another monitoring session 🪟. Once the time in the Expires: header is up, the Gateway is free to toss any record of the service session, so later SUBSCRIBE requests can be rejected with a "606" response 🗑️.
If the subscription period the Client specified has expired, the Gateway may send an immediate UNSUBSCRIBE request to the Client's representative User Agent Server ⏳. This makes sure the monitoring session always completes with an UNSUBSCRIBE/response exchange 🤝, and it means the representative User Agent Server can avoid maintaining state in certain circumstances 🧘.
3.5.3.4. Timing of SUBSCRIBE requests
So the SUBSCRIBE message is kinda limited in when it can be issued, because it relies on the Gateway already having a copy of the INVITEd session description ⏳. The Gateway must have received the service request this monitoring session is tied to, which from the Client's point of view happens as soon as the Gateway has sent back a 1xx response 🙌.
BUT once that's happened, there's no reason the Client shouldn't send a monitoring request 🙆. It doesn't have to wait for the Gateway's final response, and it can totally send the SUBSCRIBE before sending the ACK for the service request's final response ✅. After that point, the Client is free to send a SUBSCRIBE whenever it decides, unless the Gateway's final response to the initial service request indicated a short Expires: 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 that moment the Gateway has decided whether or not it can handle the service request, but it hasn't passed the request on to the Executive System yet 🧩. So it's in a really good position to ask the Executive System to enable monitoring when it sends the service request onwards 🚀. In practical implementations, more info on transient service status will likely be available if it's flagged as important BEFORE or AS the service execution phase starts 💡. Once execution has begun, the level of info that can be returned may be difficult to change 🫠.
So while it's free to send a SUBSCRIBE at any point after getting an Interim response from the Gateway to its service request, it is recommended that the Client send such a monitoring request immediately prior to sending an ACK confirming the service, if it's interested in transient service status messages 🎀.
3.5.4. The "Require:" header for PINT
PINT clients use the Require: header to tell 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 🧵:
org.ietf.sip.subscribe -- the server can fulfill SUBSCRIBE requests
and associated methods (see section 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)Example:
Require:org.ietf.sip.subscribe,org.ietf.sdp.requireA client SHOULD only include a Require: header where it truly requires the server to reject the request if the option is not supported 🙅♀️.
3.5.5. PINT URLs within PINT requests
Normally the hostnames and domain names that appear in PINT URLs are the internal affair of each individual PINT system 🤫. A client uses the appropriate SDP payload to indicate the particular service it wants to invoke, so it's not necessary to use a particular URL to identify the service 🧾.
A PINT URL gets used in two different ways within PINT requests: within the Request-URI, and within the To: and From: headers 🔗. Use within the Request-URI needs clarification to make sure interworking with the Telephone Network serviced by the PINT infrastructure goes smoothly, and that's covered next 💖.
3.5.5.1. PINT URLS within Request-URIs ✨
okay so there are a few moments where it's lowkey useful to put the service info right inside the URL, in a standardized way 🎀
- a. it may not be possible to use SDP information to route the request if it is encrypted 🔒
- b. it allows implementations 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) 👑
so for these reasons, the following conventions for URLs are offered for use in PINT requests 💖
- The user portion of a sip URL indicates the service to be requested. at the moment these services are defined:
R2C (for Request-to-Call)
R2F (for Request-to-Fax)
R2HC (for Request-to-Hear-Content)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 about registrations by competing PINT systems to a single PINT proxy server acting as a service broker 🦋
- The host portion of a sip URL contains the domain name of the PINT service provider 🌸
- 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 💅
so, 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.03.5.6. Telephony Network Parameters within PINT URLs 🧚♀️
literally any legal SIP URL can show up as a PINT URL within the Request-URI or To: header of a PINT request. BUT if the address is a telephone address, we said back in section 3.4.3 that you might need more info to correctly identify the remote telephone terminal or service 📞 so PINT clients MAY include these attribute tags within PINT URLs if they're 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) 🫶
here's an example of a PINT URL with extra attribute tags:
sip:+9725228808@pint.br.com;user=phone;require=Q763-plan;a=Q763-plan:4as we noted in section 3.4.3, these extra attribute parameters won't normally be needed in a URL, because there's already a ton of context to help the server read the phone number correctly 🙌 like, there's the SIP URL in the To: header, and there's also the Request-URI. in most cases that gives the telephone network enough info, no cap ✨
the SDP attributes defined in section 3 above will normally only be used when they're needed to supply necessary context to identify a telephone terminal 💜
3.5.7. REGISTER requests within PINT 📮
okay so 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's available to "receive calls" (i.e. to service requests). so a PINT Gateway registers with a proxy or redirect server the service that's accessible via itself, whilst in SIP, a user is registering his/her presence at a particular SIP Server 🦋
there might be competing PINT servers that can offer the same PINT service all 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 lets independent PINT systems 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. no notes, it's the same vibe 💅
of course, the info in the PINT URLs within the REGISTER request may not be enough to fully define the service a gateway can offer. using SIP and SDP within PINT REGISTER requests so a gateway can specify in more detail the services it can offer is the subject of future study 🔮
3.5.8. BYE Requests in PINT 📴
ngl the semantics of BYE requests within PINT need some extra precision 🙈 one issue is about conferences that "cannot be left", and the other is about keeping call state after the 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.
you might expect this to be the case if the telephone call hasn't started when the BYE request is received. for example, if a request to fax is sent with a t= line saying the fax should go out tomorrow at 4 AM, the requestor might want to cancel before that time 🍓
however, even if the call hasn't started yet, it may not be possible to terminate the media session on the telephone system side 😭 for example, the fax call may already be in progress when the BYE arrives, and maybe it's just not possible to cancel the fax mid-session. another possibility is that the entire telephone-side service might be completed before the BYE is received. in the Request-to-Fax example above, the BYE might be sent the next morning, and the whole fax has already been sent before the BYE got there. it's too late to send the 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's causing the problem 🚫
so in PINT, a "Not Acceptable" response MAY be returned to both INVITE and BYE requests. it indicates that some aspect of the session description makes the request unacceptable 🙅♀️
by letting a server return a "Not Acceptable" response to BYE requests, we're not changing its semantics, just enlarging its use ✨
a combo of Warning: headers and i= lines within the session description can be used to show the precise nature of the problem 🔥
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: ...
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.tifnote 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 show the actual start and stop times of the telephone session, or how many pages were sent in the fax transmission 📄
the second issue is about how long a server must keep call state after receiving a BYE 👀 this is a question because other clients might still want 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 💜
- 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 🙅♀️
- 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) ⏳
- 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 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 🫠
4. Examples of PINT Requests and Responses ✨🎀
4.1. A request to a call center from an anonymous user to receive a phone call. 📞💖
here's the vibe 👇
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-4090in this example, the context needed to read the To: address as a telephone number isn't given explicitly; it's implicitly known to the R2C@pint.mailorder.com server 🧚 but the telephone of the person who wants 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) 🌸✨
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
okay so this one is giving customer service with a personal touch 🧺🫶 John has a busted ironing board, he wants a refund, and he wants a real phone call from Mary. Bestie, the example is literally an INVITE aimed at the marketing gateway:
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
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 -ngl the To: line could totally carry Mary's phone number instead of an email-ish address 📞✨ But here's the tea: if an implementation can't handle email-like URLs in To:, it has to decline the request with a 606 Not Acceptable 💀 no drama, just a clear no.
Also, the sending PINT client is basically "knowing" that the PINT Gateway reached via marketing@pint.mailorder.com can process the request the way it's supposed to be processed. (See 3.5.5.1 for the full discussion on that one, it's a whole vibe 🙈)
Also, this kind of phone service can be built with different details on the phone side 🎀 Maybe the agent's phone rings first and then the customer's phone rings, or maybe the customer's phone rings first and he gets to enjoy silly hold music until Mary picks up 🎶 If that kind of thing needs to be specified, it can go in a= attribute lines inside the session description. Defining those attribute lines for consistency across services is out of scope for the PINT 1.0 specifications, so that's a different story for a different day 💅
4.3. A request from the same user to get a fax back on how to assemble the Ironing Board
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
c=TN RFC2543 1-201-406-4091
a=fmtp:URI uri:http://localstore/Products/IroningBoards/2344.htmlOkay this one is giving "I need instructions and I need them now" 🧚📠 The fax is stored on a local server called localstore, and that name might only resolve, or only be reachable, from inside the IP network where the PINT server lives 🏠 The number being dialled is a "local phone number" too.
Here's the detail that matters 👀 There's no phone-context attribute, so the context (meaning which nation the number is "nationally significant" in) has to be supplied by the faxback@pint.mailorder.com PINT server.
If the server that gets this request doesn't understand the number, it SHOULD decline the request and include a "Network Address Not Understood" warning ⚠️ Also, no require attribute got used here, because it's very likely the request can still get serviced even by a server that doesn't support the require attribute. Chill vibes 🌸
4.4. A request from same user to have that same information read out over the phone
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.htmlSame John, same ironing board, but now he wants it read to him out loud 🗣️🎧 Look at the m= line switching from fax to voice. Iconic glow-up of a request 💖
4.5. A request to send an included text page to a friend's pager.
In this one, the text being paged out is included right in the request 📟💌 Scott is paging his friend with a super short message.
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
----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
Hi Joe! Please call me asap at 555-1234.
----next--Bestie, the message is basically "call me asap" 😭 and it rides along inside a multipart/related body, with the text tagged by Content-ID: 2@53655768 so the a=fmtp:plain spr:2@53655768 line can point right at it 🫶
4.6. A request to send an image as a fax to phone number +972-9-956-1867
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
Scott sends a picture as a fax 🖼️📠 The image comes in tif or gif, and tif is the preferred format, so that's the main character here 👑 The http server holding the pictures is local, and so is the PINT server, because it can resolve the machine name petrack. Local everything, no cap 🏡
4.7. A request to read out over the phone two pieces of content in sequence.
Two things get read out in order 🎙️ First, some included text gets read by text-to-speech. Then some text stored at a URI on the internet gets read out too.
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
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
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--The greeting is so extra and I'm obsessed 😭💅 "We hope you like acme.com's new speech synthesis server." Iconic.
4.8. Request for the prices for ISDN to be sent to my fax machine
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-8331010Hank wants the ISDN price list faxed over 📄💸 Notice the phone-context=+44 on the To: line, which is how we know this number is a UK one 🇬🇧
4.9. Request for a callback
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 -Hank's subject line says it all: "It costs HOW much?" 😭💀 He wants a callback instead of a fax this time. Same fabulous energy, different delivery 📞✨
4.10. Sending a set of information in response to an enquiry
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: 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--
Colin is replying to Hank's enquiry with a whole packet of info 💌📎 The cottage is covered, the install quote is included, and the job reference is isdn/hh/123.45.9901, so Hank knows exactly what to quote 🙌
Here's a fun detail 👀 The "implicit" faxback content is given by an EMPTY opaque reference sitting in the middle of the fmtp line in this example. So there's a blank spot where the content goes, and it's totally intentional 🧠✨
4.11. Sportsline "headlines" message sent to your phone/pager/fax
Okay this one is so good 🏈🎉 Fred wants the NFL final scores sent to him, and the same request shows up three ways: by phone, by fax, and by pager. Here are all three versions, bestie 💖
(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>(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>(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>Notice that these are all VERY similar 👯♀️ Same subject line, same signature line, just a different m= and c= line in each one. Literally the same request in three outfits 💅🧚
4.12. Automatically giving someone a fax copy of your phone bill ✨
okay so this one is giving "send Joe's itemised bill straight to the fax machine" energy 🧾💅 here's the full INVITE:
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>🔍 bestie, the opaque reference here isn't really picking out which content you get. it's a bundle of data that convinces the Executive System that the requester is allowed to see this information 🔐 the A party in the To: field of the SIP "wrapper" is the thing that does the actual selecting all on its own 💖
5. Security Considerations 🛡️
5.1. Basic Principles for PINT Use
okay this section is the whole vibe check 🫶 a PINT Gateway, plus the Executive System(s) it's hooked up with, exist to serve PINT Requestors. the goal of the PINT protocol is to pass requests from those users along to a PINT Gateway, so an associated Executive System can actually handle them ✨
5.1.1. Responsibility for service requests
ngl this part is kinda serious 😭 making a GSTN-based call to the numbers in a PINT request comes with real risks. the request might name a wrong telephone or fax number. the Requestor might also have deliberately typed in the number of an innocent third party 💀 and the request could get intercepted on its way through any PINT or SIP infrastructure in between, then altered.
any of those things can end with a call going to the wrong place. if someone meant to do it, or was careless about it, that can count as harassment of whoever gets the call 🚨 the rules for misusing Internet connections differ all over the world and aren't always well defined yet, but the rules for GSTN calls are way more settled. someone may be liable for mistaken or incorrect calls.
GSTN Operators would really prefer that someone not be them 🙃 so they need to make sure that no PINT Gateway and Executive System combo creates incorrect calls, whether from a bug in the Gateway or Executive System implementation or from a GSTN-internal communications fault. it's also important that the Operator can show they only act on requests they have good reason to believe are correct. which means the Gateway must not pass on requests unless it's sure they haven't been corrupted in transit from the Requestor 🔒
if a request can be shown to have come from a particular Requestor, and the PINT service provider acted on it in good faith, then responsibility for making the requests may well fall on the Requestor rather than the Operator who carried them out 👑
finally, it may matter that the PINT service provider can show they only act on requests where they have some degree of assurance about where the request came from 💅 in lots of jurisdictions, GSTN Operators are required to only place calls when they can identify the parties to the call if asked (for example, when they have to carry out a Malicious Call Trace). it's at least likely that PINT service providers will have a similar responsibility put on them 📞
so the PINT service provider may require that the identity of the Requestor be confirmed. if that confirmation isn't available, they may be forced to (or choose to) not provide service 🙅♀️ this identification may require personal authentication of the Requesting User.
5.1.2. Authority to make requests
if GSTN resources are used to provide a PINT service, it's at least possible that someone will have to pay for it 💸 that person might not be the Requestor. take existing GSTN split-charging services like free phone, where the person receiving the call is the one who pays for it instead of the caller 📱
that's not the only option, though. for example, PINT service might be sold on a subscription basis, and there are a bunch of other models too 🌈 but whichever model gets picked, there may be a requirement that the authority of a Requestor to make a PINT request gets confirmed.
if that confirmation isn't available, then again, the PINT Gateway and its associated Executive System may choose not to provide service 🚫
5.1.3. Privacy
even if the identity of the Requesting User and the Authority they're making the request under are known, the request could still get corrupted, maliciously altered, or even replaced while it's in transit between the Requestor and the PINT Gateway 😱
the information about the Authority a request is made under may also be carried inside that request. that can be really sensitive, since an eavesdropper could steal it and use it in their own requests 🕵️ such Authority SHOULD be treated as if it were financial information (like a credit card number or PIN) 💖
the data that authorizes a Requesting User to make a PINT request should be known only to them and the service provider. but this information might be in a form that doesn't match the schemes normally used on 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 a GSTN provider may only store an account code and a PIN (which is a fixed string of numbers).
a Requesting User reasonably expects their service requests to be confidential 🔐 for some PINT services, no content goes over the Internet at all. still, the telephone or fax numbers of the parties to a resulting service call may be considered sensitive 🫣 so it's likely that the Requestor (and their PINT service provider) will require that any request sent across the Internet be protected against eavesdroppers. in short, the requests SHOULD to be encrypted 🔒✨
5.1.4. Privacy Implications of SUBSCRIBE/NOTIFY
okay this one is a whole thing 👀 some special considerations apply to monitoring sessions using the SUBSCRIBE and NOTIFY messages. the SUBSCRIBE message used to register interest in how a PINT service transaction turns out uses the original Session Description carried in the related INVITE message. this spec doesn't restrict where a SUBSCRIBE message can come from, so an eavesdropper could capture an unprotected session description and reuse it in a later SUBSCRIBE request 😳 that way, someone could find out details about that transaction that may well be considered sensitive.
the first fix for this risk is to recommend that a session description which might be used in a later SUBSCRIBE message SHOULD be protected 🛡️
but there's a further risk too. if the origin-field is "guessable," an attacker might be able to reconstruct the session description and use that reconstruction in a SUBSCRIBE message 🧩
SDP (see section 6 of [2], "o=" field) doesn't specify how the sess-id field gets generated, and it suggests that a method based on timestamps from Network Time Protocol [16] can be used. that's enough to guarantee uniqueness, but it may let the value be guessed, especially if other unprotected requests from the same originator are available 😬
so to make sure the session identifier isn't guessable, the techniques described in section 6.3 of [17] can be used when generating the origin-field for a session description that's going inside a PINT INVITE message 🔑 if all requests from (and responses to) a particular PINT requesting entity are protected, you don't need this. but where that isn't assured, AND where session monitoring is supported, then a method that keeps the origin-field inside a session description from being guessable SHOULD be used 💜
5.2. Registration Procedures
any number of PINT Gateways may register to provide the same service 🎀 this happens when the Gateways specify the same "userinfo" part in the To: header field of the REGISTER request. SIP's "core" scenarios would be unlikely to have this kind of ambiguity, but for PINT it's very likely. there could be loads of service providers who all want to support a "Request-To-Fax" service, for example 📠
unless a request names the Gateway explicitly, an intervening Proxy that works from a registration database where several Gateways have registered can pick from the registrands using whatever algorithm it likes 🎲 in principle, any Gateway that has registered as "R2F" would be appropriate.
but this opens up a door for attackers, and a "rogue" Gateway operator stands to gain a lot from walking through it 😈 the standard SIP procedure for releasing a registration is to send a REGISTER request with a Contact field that has a wildcard value and an expires parameter set to 0. it's really important that a PINT Registrar uses authentication on the Registrand. otherwise, one PINT service provider could "spoof" another and remove its registration 💀 since that would stop the Proxy from passing any requests to that provider, it would both increase the requests going to the rogue and stop requests going to the victim.
another version of this attack would be to register a Gateway under a name another provider has already registered. so a rogue Operator might register its Gateway as "R2C@pint.att.com" and hijack requests that way 🏴☠️
the fix is the same across the board: all registrations by PINT Gateways MUST be authenticated. that covers new registrations, apparent replacement registrations, and any cancellation of current registrations ✅ this recommendation is also made in the SIP specification, but for PINT to work correctly, it is very, very important indeed 🫶
5.3. Security mechanisms and implications on PINT service 🔐✨
okay so PINT is basically a set of extensions to SIP[1] and SDP[2], which means it's gonna use the security procedures SIP already describes 💅. that comes with a few consequences, so let's go through them 🫶
the To: header field in SIP is used to pick out one of the parties in the resulting service call (the PINT Request-To-Call service is a good example 📞). as the SIP spec says, that field is what routes SIP messages through the Redirect and Proxy servers between the User Agent Servers, which means it cannot be encrypted 🙈. so yeah, most of the personal or sensitive stuff can be protected on the way over, BUT the telephone (or fax) number of one party to a PINT service call can't be, and it'll be "visible" to anyone intercepting. for the PINT milestone services that's probably fine, since the party named in To: is usually a "well known" provider address, like a Call Center 📞🎀
another thing: even if the Requesting User doesn't think the telephone or fax numbers are private, those other parties might 🤷♀️. if PINT servers have reason to think that could be the case, they SHOULD encrypt the request, even if the Requestor didn't. for example, a Requesting User inside a company places a PINT request, it goes over the company Intranet to their Proxy/firewall, and then across the Internet to a PINT Gateway somewhere else 🏢🌍
if a request carries data that an eavesdropper could reuse, either to "spoof" the Requestor or to get PINT service by sticking the Requestor's authorization token into the eavesdropper's own request, then that data MUST be protected 🚨. this matters EXTRA if the authorization token is static text (like an account code and/or PIN) 💀
one approach is to encrypt the whole request using the methods in the SIP spec 🔒. or, 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 it's resistant to interception and re-use. another idea: the authorization token might not be usable outside of a request the Requestor cryptographically signed. if so, that requirement can be relaxed, since then nobody else can reuse it 🫧. BUT unless both the Requestor and the Gateway are sure that's the case, any authorization token MUST be treated as sensitive, and so MUST be encrypted 🔥
a PINT request may contain data within the SDP message body that can be used to route it more efficiently 🗺️. for example, one Gateway and Executive System combo might not be able to handle a request that says one of the parties is a pager, while another one can. both gateways may have registered with a PINT/SIP Registrar, and this info may be available to intervening PINT/SIP Proxies. however, if the message body is encrypted, the request can't be decoded at the Proxy server, so Gateway selection based on what's inside can't happen there 😭
the result is that the Proxy may deliver the request to a Gateway that can't handle it. so a PINT/SIP Proxy SHOULD treat its choice of the appropriate Gateway as subject to correction, and on receiving a 501 or 415 rejection from the first gateway chosen, it should try another one 🔁. that way the request will succeed if at all possible, even though it may be delayed (and tie up resources in the inappropriate Gateways) ⏳
this opens up a sneaky Denial Of Service avenue 😤: send a valid request that looks suitable for a bunch of different Gateways, and just keep them busy decrypting a message asking for a service they can't provide. as mentioned in section 3.5.5.1, the service name passed in the userinfo portion of the SIP Request-URI is flexible, and it is RECOMMENDED that names be chosen so a Proxy can pick an appropriate Gateway without having to examine the SDP body part. so in the example here, the service might be called "Request-To-Page" or "R2P" rather than the more general "R2F", if there's a possibility of the SDP body part being protected during transit 🧁
a variation on this attack is to send a request that's syntactically invalid but that, because of the encryption, can't be detected without spending resources decoding it 🥴. the effects can be minimised 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 one 🛑
finally, the Requesting User may not have a prior relationship with a PINT Gateway, while still having one with the Operator of the Executive System that fulfills their request 🤝. so there may be two levels of authentication and authorization: one using the techniques in the SIP spec (between the Requestor and the Gateway), and another between the Requesting User or the Requestor and the Executive System 🔐🔐
for example, the Requesting User may have an account with the PINT service provider. that provider might require requests to include this identity before it will provide service 🪪. in addition, to counter attacks on the request while it's in transit across the Internet, the Gateway may require a separate X.509-based certification of the request 📜. these are two separate procedures, and the data needed for the former would normally be expected to be held in opaque references inside the SDP body part 🫧
the detailed operation of this mechanism is, by definition, outside the scope of an Internet Protocol, so it must be considered a private matter 🤐. however, one way to tell the Requestor that their Service Provider requires this "second level" authentication or authorization would be to ask for it inside the textual description carried with a 401 response returned from the PINT Gateway 📝
5.4. Summary of Security Implications 🧾
from all of the above, PINT always carries sensitive data items, and there may be financial considerations as well as the more normal privacy concerns 💸. so the transactions MUST be protected from interception, modification and replay in transit 🛡️
PINT is based on SIP and SDP, and can use the security procedures outlined in [1] (sections 13 and 15). however, for 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 💪
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 already protected. Clients and servers SHOULD support manual configuration to use such lower layer security facilities ⚙️
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 that's configured for TLS 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 🎀
authentication of the Client making the request is required, though, so if the underlying mechanism doesn't provide it, it MUST be included within the PINT messages using SIP authentication techniques 🪪. unlike SIP, PINT requests are often sent to parties you already have a relationship with (such as a Telephone Carrier) 📞. in that 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 they do, the message integrity and privacy must be guaranteed by some lower layer mechanism 🧱
there are implications for how PINT operates here though 👀. if a PINT proxy or redirect server is used, it must be able to examine the contents of the IP datagrams carried. so an end-to-end approach using network-layer security between the PINT Client and a PINT Gateway rules out an intervening proxy: communication between the Client and Gateway is carried via a tunnel that no intervening entity can access, even if the IP datagrams pass through that node 🚇. conversely, if a "hop-by-hop" approach is used, then any intervening PINT proxies (or redirect servers) are, by implication, trusted entities 🤝
however, if there's any doubt that an underlying network or transport layer security association is 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's an alternative protection scheme agreed between the parties 📜. either way, the content of any message body (or bodies) carried within a PINT request or response MUST be protected, and this affects the options for routing requests via Proxies (see 5.3) 🗺️
using SIP techniques for protection, the Request-URI and To: fields within PINT requests can't 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 the sole use of SIP techniques is ruled out. in that situation, transport [12] or network layer [13] protection mechanisms MUST be used 🙅
as a final point, this choice in turn influences which transport layer protocol 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) 🔄
6. Deployment considerations and the Relationship PINT to I.N. (Informative) 🏗️
6.1. Web Front End to PINT Infrastructure 🌐
it's possible that some other protocol may be used to communicate a Requesting User's requirements 💬. with the huge number of Web Browsers and servers out there, it seems likely that some PINT systems will use HTML/HTTP as a "front end" 🖥️. in this setup, HTTP runs 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 represents the Requesting User to the PINT Gateway, and so to the Executive System that carries out the required action 🎬
[WC]------[WS]
[PC]
\
\
[PG]
[XS]
Figure 2: Basic "Web-fronted" Configuration6.2. Redirects to Multiple Gateways 💖
okay so, it's totally possible that one PINT Gateway is hooked up to an Executive System (or a few of them) that can plug into the GSTN in different places 🌸 Same vibe if you've got a chain of PINT Servers: each intermediate or proxy server (PP) might be able to route PINT requests to Executive Systems that connect at specific points on the GSTN ✨ So there could be more than one PINT Gateway or Executive System that can handle a given request. How the choice gets made about where to deliver a request is outside the scope of this document 🧚
[WC]------[WS] [WC]------[WS]
[PC] [PC]
\ \
\ \
[PG] [PP]
.........[XS]......... / \
: : / \
[PG] [PG]
[XS] [XS]Figure 3: Multiple Access Configurations
Honestly though, there seem to be two approaches 👑 Either a Server that acts as a proxy or redirect will pick the appropriate Gateway itself and make sure the request gets sent on accordingly, or a list of possible Locations gets returned to the Requesting User so they can pick their choice 💅
In SIP, the implication is that, if a proxy can't 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 🙈
However, within PINT, that kind of ambiguity may be quite common 😭 It basically means there are a bunch of possible providers of a given service.
6.3. Competing PINT Gateways REGISTERing to offer the same service 🎀
okay this one is so good 🦋 With PINT, the registration isn't for an individual, it's for a service that a service provider can handle. So you can picture the PINT Server of the domain telcoA.com registering its ability to support the service R2C as "R2C@telcoA.com". It gets sent to an intermediary server that acts as registrar for the "broker.telcos.com" domain, coming from "R2C@pint.telcoA.com", like this:
REGISTER sip:registrar@broker.telcos.com SIP/2.0
To: sip:R2C@pint.telcoA.com
From: sip:R2C@pint.telcoA.com
...This is the standard SIP registration service, nothing too wild yet 💜
But what happens if there are a bunch of different Service Providers, all of whom support the "R2C" service? 👀 Say there's a PINT system at domain "broker.com". PINT clients asking for a Request-to-Call service from broker.com might be super willing to get redirected or proxied to any one of the various service providers that had previously registered with the registrar. PINT servers might also want to provide service for requests that didn't name the service provider explicitly, as well as those requests that were directed "at them" 🧚
To make that happen, PINT servers would REGISTER at the broker PINT server registrations of the form:
REGISTER sip:registrar@broker.com SIP/2.0
To: sip:R2C@broker.com
From: sip:R2C@pint.telcoA.comNow when several of these REGISTER messages show up at the registrar, each one differing only in the URL in the From: line, the registrar has a lot of possibilities 🌈 For example:
- (i) it overwrites the prior registration for "R2C@broker.telcos.com" when the next one comes in;
- (ii) it rejects the subsequent registration for "R2C@broker.telcos.com";
- (iii) it maintains all such registrations.
In that last case, when an Invitation for the "general" service comes in, the registrar can do either of these:
- (iii.1) it passes on the invitation to all registered service providers, returning a collated response with all acceptances, using multiple
Location:headers, - (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.
And as an alternative to all of the above, it:
- (iv) may choose to not allow registrations for the "general" service, rejecting all such REGISTER requests.
The algorithm for making that choice is up to the implementation, so it's outside the scope of PINT 🫶 If a behaviour is going to be defined by requesting users, then some sort of call processing language might be used. Those clients could download the behaviour they expect to the server making those decisions, as a pre-service operation. But this is a topic for other protocols, not for PINT 💀
6.4. Limitations on Available Information and Request Timing for SUBSCRIBE 🌸
so the reference setup for PINT is that service requests get sent, via a PINT Gateway, to an Executive System that fulfills the Service Control Function (SCF) of an Intelligent Network (see [11]) 🧚 Whether the service call worked or not might be info the SCF has, so it could potentially be made available to the PINT Gateway. But here's the catch: a big SCF might be handling a million call attempts per hour 😭 At that volume there are finite limits on how many service disposition records it can store, so expecting to find out if a Fax was sent last month from a busy SCF is just unrealistic 💀
Other status changes, like a successful service call completing, need the SCF to set up monitoring of the call in a way the service doesn't normally do, for performance reasons 👀 In most implementations it's hard to efficiently interrupt a service to change it once it's already running, so it might be necessary to have two different services: one that sets up GSTN resources to monitor call termination, and one that doesn't. It's unlikely you can decide monitoring is needed once the service has started 🙈
These factors can affect both what info might be available at the PINT Gateway and when a request to register interest in a PINT service's status can succeed 🦋 The alternative to a general SCF is a dedicated Service Node just for PINT services. Since that node is involved in placing all service calls, it's in a great position to collect the info it needs. Still, it may well not be able to successfully respond to a registration of interest in call state changes once a service logic program instance is running 😭
So even though a Requesting User may register interest in the status of a service request, the PINT Gateway might not be in a position to comply. This doesn't change the protocol used between the Requestor and the PINT Gateway, but it may influence the response that comes back 💅 To avoid the problem of changing service logic while it's running, any registration of interest in status changes should be made at or before the time the service request is made ✨
Now the flip side: if a historical request is made about the disposition of a service, it should be done within a short time after the service has completed 🫠 The Executive System is unlikely to keep the results of service requests for long. They get processed quickly as AMA (Automatic Message Accounting) records, after which the Executive System has no reason to keep them, so they may be discarded 🍓
Where the PINT Gateway and the Executive System are closely linked, the Gateway can respond to status subscription requests that come in while a service is running. It might accept these requests and not even bother querying the Executive System until it has info that a service has completed, then just return the final status 🌈 So the PINT Requestor may think it's in a monitoring state, while the PINT Gateway hasn't even told the Executive System a request was made 🙃 This makes the PINT Gateway's internal complexity go up, since it ends up with a complex set of interlocking state machines, but it does mean that status registration and indication CAN be provided in conjunction with an I.N. system 👑
6.5. Parameters needed for invoking traditional GSTN Services within PINT 🧚
This section is all about how the parameters needed to specify certain traditional GSTN services can be carried within PINT requests 💖
6.5.1. Service Identifier ✨
When a Requesting User asks for a service to be performed, they'll obviously have to specify somehow which service. This can be done in the URLs within the To: header and the Request-URI (see section 3.5.5.1) 🎀
6.5.2. A and B parties 💅
With the Request-to-Call service, they'll also need to specify the A and B parties they want engaged in the resulting service call. The A party could identify, for example, the Call Center they want a call back from, whilst the B party is their telephone number (i.e. who the Call Center agent is to call) 📞
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 it's implicit. The Requesting User doesn't (and can't) specify it 🙈
With the "Fax-Back" variant of the Request-to-Fax service (where the content to be delivered lives on the GSTN), they'll also have to specify two parties 🦋 Same as before, the B party is the telephone number of the fax machine they want a fax sent to. But in this variant the A party identifies the "document context" for the GSTN-based document store where a particular document gets retrieved from. The analogy is a GSTN user dialling a particular telephone number and then entering the document number to be returned using "touch tone" digits 🌸 The number they dial is the document store (the A party), and the "touch tone" digits pick out the document inside that store 🫶
6.5.3. Other Service Parameters ✨
Okay so the extra parameters are where the services really go their own way 💅. Request-to-Call only needs the A and B parties, which is honestly so clean 🫶. It's also convenient to assert that the resulting service call will carry voice 🎤, because the Executive System inside the destination GSTN may be able to check that claim against the A and B party numbers and treat the call differently 🔥.
Request-to-Fax and Request-to-Hear-Content have a different energy. The source information they need to transcode lives on the Internet, so it either rides along inside the request itself, or the request carries a reference that points to where it lives 🌸.
It's also 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 Request-to-Fax needs to specify the Document Store number and the Fax machine number that the information gets delivered to 📠. It's convenient to assert that the call will carry Fax data too 💖, since the destination Executive System may be able to check that assertion against the document store number and the destination Fax machine's number 🧚.
The document number may also need to be sent 🗂️. This parameter is an opaque reference: it travels through the Internet, but it only has meaning within the GSTN 🙈. Together, the document store number and document number uniquely specify the actual content to be faxed 👑.
6.5.4. Service Parameter Summary
Bestie, here's the cheat sheet 📋. The table below summarises all the information needed to fully specify the intent of a GSTN service request. It leaves out other stuff that might show up in a request, like authentication or authorisation tokens, or Expires: or CallId: headers 🔐.
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/ILSFIn this table, "x" means the parameter is required, whilst "-" means it is not required 💅.
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) 🎧.
The Call Format parameter values "voice" or "fax" show what kind of service call results 🎀.
The Source Indicator "URI/IL" means 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 the value is an Opaque Reference. It should be carried along with the rest of the message, but it's only interpreted within the destination (GSTN) context 🦋. As an alternative, it could be given as a "local" reference with the "file" style, or even as a partial reference with the "http" style 🧚. How such a reference gets interpreted is a matter for the receiving PINT Server and Executive System, so in effect it stays opaque 🫠.
The Source Format value "ISF/ILSF" means 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 can be detected by inspection or, if all else fails, assumed from the URI. For example, you can assume that the file extension part of a URL indicates the data type 👀. For an opaque reference, the Source Format isn't available on the Internet, so it isn't given 💀.
6.6. Parameter Mapping to PINT Extensions ✨
This section describes how the parameters needed to fully specify a GSTN service request might be carried within a "PINT extended" message 🎁. There are other choices, and these aren't precluded 🙌. Still, to make sure the Requesting User gets the service they expect, everyone needs a shared understanding of the parameters passed and the behaviour expected of the PINT Server and its attendant Executive System 🤝.
The Service Identifier can be sent as the userinfo element of the Request-URI 🪪. So the first line of a PINT Invitation looks like this:
INVITE <serviceID>@<pint-server>.<domain> SIP/2.0The 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. For the services where the A party isn't specified, the "To:" field is free to repeat the value in the Request-URI. That's the case for Request-to-Fax and Request-to-Hear-Content 🔄.
The B party is needed in all of these milestone services, and it can be held in the enclosed SDP sub-part, as the value of the "c=" field 🎯.
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 🗺️.
The source format specifier is held in the "m=" field, as a type and either "-" or a sub-type 🎨. The sub-type 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 aren't always required when generating service requests. But including a source format specifier in all requests can make parsing simpler and leaves room for other services to be specified in the future, so values are always given 🧠. The source format parameter is covered in section 3.4.2 as the "media type" element 📚.
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" 💭.
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) ---
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
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>7. References ✨
These are the sources the document leans on 📚.
[1] Handley, M., Schooler, E., Schulzrinne, H. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[2] Handley, M. and V. Jacobsen, "SDP: Session Description Protocol", RFC 2327, April 1998.
[3] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[5] The Unicode Consortium, "The Unicode Standard -- Version 2.0", Addison-Wesley, 1996.
[6] ITU-T Study Group 2, "E.164 - The International Public Network Numbering Plan", ITU-T, June 1997.
[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.
[8] ITU-T Study Group XI, "Q.763 - Formats and Codes for the ISDN User Part of SS No7" ITU-T, August 1994.
[9] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[10] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.
[11] ITU-T Study Group XI, "Q.1204 - IN Distributed Functional Plane Architecture", ITU-T, February 1994.
[12] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[13] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[14] Housley, R., Ford, W., Polk W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", RFC 2459, January 1999.
[15] Crocker, D. and P. Overall, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[16] Mills, D., "Network Time Protocol (version 3) specification and implementation", RFC 1305, March 1992.
[17] Eastlake, D., Crocker, S. and J.Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[18] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987.
[19] Levinson, E., "The MIME Multipart/Related Content-type" RFC 2387, August 1998.
8. Acknowledgements ✨
okay bestie, huge thank-you 🫶 to the members of the PINT working group, whose comments genuinely made this spec better 💖. Ian Elz's comments were extremely useful for understanding how the internal PSTN operates 🧠. The SUBSCRIBE and NOTIFY requests were first suggested by Henning Schulzrinne and Jonathan Rosenberg 👑. The idea of using an audio port of 0 to show that the phone is "on hold" (so it's not receiving voice) came from Ray Zibman 🎀. And last but not least, thanks to Bernie Hoeneisen for his super close proofreading 🔥.
Appendix A: Collected ABNF for PINT Extensions
Here's the whole ABNF collection in one place 🧚, copied exactly so nothing gets lost in translation.
;; --(ABNF is specified in RFC 2234 [15])
;; --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
nettype = ("IN"/"TN")
; -- 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
TNAddrType = ("RFC2543"/OtherAddrType)
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
TNAddr = (RFC2543Addr/OtherAddr)
; -- TNAddr defined only in context of nettype == "TN"
RFC2543Addr = (INPAddr/LDPAddr)
INPAddr = "+" <POS-DIGIT> 0*(("-" <DIGIT>)/<DIGIT>)
; -- POS-DIGIT and DIGIT as defined in SDP
LDPAddr = <DIGIT> 0*(("-" <DIGIT>)/<DIGIT>)
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 = ("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)
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"
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-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)
clir-attribute = clir-tag ":" ("true" / "false")
clir-tag = "clir"
q763-nature-attribute = Q763-nature-tag ":" q763-natures
q763-nature-tag = "Q763-nature"
q763-natures = ("1" / "2" / "3" / "4")
q763-plan-attribute = Q763-plan-tag ":" q763-plans
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-INN-attribute = Q763-INN-tag ":" q763-INNs
q763-INN-tag = "Q763-INN"
q763-INNs = ("0" / "1")
phone-context-attribute = phone-context-tag ":" phone-context-ident
phone-context-tag = "phone-context"
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>
private-prefix = 1*excldigandplus 0*<uric>
excldigandplus = (0x21-0x2d,0x2f,0x40-0x7d))
tsp-attribute = tsp-tag "=" provider-domainname
tsp-tag = "tsp"
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
resolution = (uri-ref / opaque-ref / sub-part-ref)
uri-ref = uri-tag ":" <URI-Reference>
; -- URI-Reference defined in RFC2396
uritag = "uri"
opaque-ref = opr-tag ":" 0*<uric>
opr-tag = "opr"
sub-part-ref = spr-tag ":" <Content-ID>
; -- Content-ID is as defined in RFC2046 and RFC822
spr-tag = "spr"
strict-attribute = "require:" att-tag-list
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-fmtp-tag-list = (uri-tag / opr-tag / spr-tag)
;; --Variations on SIP definitions
clir-parameter = clir-tag "=" ("true" / "false")
q763-nature-parameter = Q763-nature-tag "=" Q763-natures
q763plan-parameter = Q763-plan-tag "=" q763plans
q763-INN-parameter = Q763-INN-tag "=" q763-INNs
tsp-parameter = tsp-tag "=" provider-domainname
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
PINT-param = ( clir-parameter / q763-nature-parameter /
q763plan-parameter / q763-INN-parameter/
tsp-parameter / phone-context-parameter )
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)
required-extensions = ("org.ietf.sip.subscribe" /
"org.ietf.sdp.require")Appendix B: IANA Considerations 🌸
Three kinds of identifier used in PINT extensions SHOULD be registered with IANA, if a new value is specified. Here they are:
- 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.
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. So those ones don't need to go through IANA 🙈.
B.1. Media Format Sub-types
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.
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" 💅.
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.
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".
B.2. Private Attributes
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.
Heads up: in PINT 1.0, freshly registered attribute lines can't be added to a "require:" clause. No cap, that's a real limit to keep in mind 🚫.
B.3. Private phone-contexts 📞✨
Okay bestie, so inside the session description used for PINT requests, there's a phone-context attribute 💅. It tells you the prefix or context that an associated telephone-number (in a connection line) should be read within 🎀.
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 🦋. A prefix like that is super useful for identifying a private network, potentially with an associated numeric ID (see example 4 in section 3.4.3.1) 🧚. In that example, the prefix acts as the context for X-acme.com's private network numbering plan 💜.
It is recommended that any private context being registered has the general form of a token that includes a domain name, optionally followed by a digit string or other token. The initial token name space should look a lot like the one used for private or vendor registrations for sub-types (e.g. vnd.acme.com) 🍓. BUT note that the registration is used to specify a customer's private network numbering plan format, NOT every customer of an equipment vendor 💀. So fbi.gov would be appropriate, but lucent.com would not (unless the private network were the one Lucent uses internally) 🙈.
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's enough that the private context can be parsed, without the value being interpreted 🫶.
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.
In short, this context is the telephone equivalent of a "Net 10" address space behind a NAT 🧠. The initial name (and contact information) shows the context within which that address is valid, and it also specifies the format for the network and address types (and address value syntax) that this context is associated with 💖.
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 👑.
Authors' Addresses 🖊️
Scott Petrack
MetaTel, Inc.
45 Rumford Ave.
Waltham MA 02453-3844
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
Phone: +44 (1794) 833666
EMail: lwc@roke.co.ukFull Copyright Statement ⚖️
Copyright (C) The Internet Society (2000). All Rights Reserved.
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. 💜
📦 where this page comes from
- ietf: rfc2848 2000-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms