idnits 2.17.1 draft-ietf-pint-protocol-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 12 longer pages, the longest (page 41) being 63 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 930 instances of too long lines in the document, the longest one being 6 characters in excess of 72. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 31 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 734 has weird spacing: '...p:plain uri:f...' == Line 738 has weird spacing: '...p:plain uri:h...' == Line 760 has weird spacing: '...p:plain opr:A...' == Line 788 has weird spacing: '...p:plain spr:<...' == Line 828 has weird spacing: '...p:plain spr:<...' == (8 more instances...) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: 3. When engaged in a SUBSCRIBE/NOTIFY monitoring session, PINT servers that send BYE to a URL listed in the Contact: header of a client request SHOULD not clear session state until after the successful response to the BYE is received. For example, it may be that the requesting client host is turned off 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 BYE. Of course, it is possible that the BYE request will simply time out. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'PC' on line 2313 -- Looks like a reference, but probably isn't: 'PG' on line 2319 -- Looks like a reference, but probably isn't: 'XS' on line 2320 -- Looks like a reference, but probably isn't: 'PP' on line 2316 ** Obsolete normative reference: RFC 2543 (ref. '1') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) ** Obsolete normative reference: RFC 2327 (ref. '2') (Obsoleted by RFC 4566) -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Downref: Normative reference to an Informational RFC: RFC 2458 (ref. '7') -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Obsolete normative reference: RFC 2396 (ref. '9') (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 822 (ref. '10') (Obsoleted by RFC 2822) -- Possible downref: Non-RFC (?) normative reference: ref. '11' ** Obsolete normative reference: RFC 2246 (ref. '12') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2401 (ref. '13') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2459 (ref. '14') (Obsoleted by RFC 3280) ** Obsolete normative reference: RFC 2234 (ref. '15') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 1305 (ref. '16') (Obsoleted by RFC 5905) -- Duplicate reference: RFC1305, mentioned in '17', was also mentioned in '16'. ** Obsolete normative reference: RFC 1305 (ref. '17') (Obsoleted by RFC 5905) Summary: 16 errors (**), 0 flaws (~~), 11 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Scott Petrack, 2 Internet Engineering Task Force Metatel 3 PINT Working Group Lawrence Conroy, 4 Issued: 3 August 1999 Siemens Roke Manor Research 5 Expires: 14 January 2000 7 The PINT Service Protocol: 8 Extensions to SIP and SDP for IP Access to Telephone Call Services 10 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as work in progress. 27 Distribution of this memo is unlimited 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Copyright Notice 37 Copyright (c) The Internet Society (1999). All rights reserved. 39 Abstract 41 This document contains the specification of the PINT Service Protocol 1.0, 42 which defines a protocol for invoking certain telephone services from an IP 43 network. These services include placing basic calls, sending and receiving 44 faxes, and receiving content over the telephone. The protocol is specified 45 as a set of enhancements and additions to the SIP 2.0 and SDP 2.0 protocols. 47 This document is intended for the PSTN-Internet Interworking (PINT) working 48 group of the Internet Engineering Task Force. Comments are solicited and 49 should be addressed to the working group's mailing list at 50 pint@lists.research.bell-labs.com and/or the authors. 52 Petrack & Conroy [Page 1] 53 Contents 55 1. Introduction ......................................................... 4 56 1.1 Glossary ............................................................ 5 58 2. PINT Milestone Services .............................................. 6 59 2.1 Request to Call ................................................. 6 60 2.2 Request to Fax .................................................. 6 61 2.3 Request to Hear Content ......................................... 6 62 2.4 Relation between PINT milestone services and traditional 63 telephone services ............................................... 6 65 3. PINT Functional and Protocol Architecture ............................. 7 66 3.1. PINT Functional Architecture .................................... 7 67 3.2. PINT Protocol Architecture ...................................... 8 68 3.2.1. SDP operation in PINT ..................................... 9 69 3.2.2. SIP Operation in PINT ..................................... 9 70 3.3. REQUIRED and OPTIONAL elements for PINT compliance ............. 10 71 3.4. PINT Extensions to SDP 2.0 ..................................... 10 72 3.4.1. Network Type "TN" and Address Type "RFC2543" ............. 11 73 3.4.2. Support for Data Objects within PINT ..................... 11 74 3.4.2.1. Use of fmtp attributes in PINT requests ............ 13 75 3.4.2.2. Support for Remote Data Object References in PINT .. 13 76 3.4.2.3. Support for GSTN-based Data Objects in PINT ........ 14 77 3.4.2.4. Session Description support for included Data Objects 15 78 3.4.3. Attribute Tags to pass information into the Telephone 79 Network .................................................. 16 80 3.4.3.1. The phone-context attribute ........................ 17 81 3.4.3.2. Presentation Restriction attribute ................. 19 82 3.4.3.3. ITU-T CalledPartyAddress attributes parameters ..... 19 83 3.4.4. The "require" attribute .................................. 20 84 3.5. PINT Extensions to SIP 2.0 ..................................... 21 85 3.5.1. Multi-part MIME (sending data along with SIP request) .... 21 86 3.5.2. Warning header ........................................... 22 87 3.5.3. Mechanism to register interest in the disposition of a PINT 88 service, and to receive indications on that disposition .. 23 89 3.5.3.1. Opening a monitoring session with a SUBSCRIBE request 23 90 3.5.3.2. Sending Status Indications with a NOTIFY request ... 24 91 3.5.3.3. Closing a monitoring session with a BYE request .... 25 92 3.5.3.4. Timing of SUBSCRIBE requests ....................... 25 93 3.5.4. The "Require:" header for PINT ........................... 26 94 3.5.5. PINT URLs within PINT requests ........................... 26 95 3.5.5.1. PINT URLS within Request-URIs ...................... 27 96 3.5.6. Telephony Network Parameters within PINT URLs ............ 27 97 3.5.7. REGISTER requests within PINT ............................ 28 98 3.5.8. BYE Requests in PINT ..................................... 28 100 4. Examples of PINT Requests and Responses .............................. 30 101 4.1. A request to a call centre from an anonymous user to receive a 102 phone call ..................................................... 30 103 4.2. A request from a non anonymous customer (John Jones) to receive a 104 phone call from a particular sales agent (Mary James) .......... 30 105 4.3. A request to get a fax back .................................... 31 107 Petrack & Conroy [Page 2] 108 4.4. A request to have information read out over the phone .......... 32 109 4.5. A request to send an included text page to a friend's pager .... 32 110 4.6. A request to send an image as a fax to phone number 111 +972-9-956-1867 ................................................ 33 112 4.7. A request to read out over the phone two pieces of content in 113 sequence ....................................................... 33 114 4.8. Request for the prices for ISDN to be sent to my fax machine ... 34 115 4.9. Request for a callback ......................................... 34 116 4.10.Sending a set of information in response to an enquiry ......... 34 117 4.11.Sportsline "headlines" message sent to your phone/fax/pager .... 35 118 4.12.Automatically giving someone a fax copy of your phone bill ..... 36 120 5. Security Considerations .............................................. 37 121 5.1. Basic Principles for PINT Use ................................. 37 122 5.1.1. Responsibility for service requests ..................... 37 123 5.1.2. Authority to make requests .............................. 37 124 5.1.3. Privacy ................................................. 38 125 5.1.4. Privacy Implications of SUBSCRIBE/NOTIFY ................ 38 126 5.2. Registration Procedures ....................................... 39 127 5.3. Security mechanisms and implications on PINT service .......... 39 128 5.4. Summary of Security Implications .............................. 41 130 6. Deployment considerations and the Relationship PINT to I.N. 131 (Informative) ........................................................ 43 132 6.1. Web Front End to PINT Infrastructure ........................... 43 133 6.2. Redirects to Multiple Gateways ................................. 43 134 6.3. Competing PINT Gateways REGISTERing to offer the same service .. 44 135 6.4. Limitations on Available Information and Request Timing for 136 SUBSCRIBE ...................................................... 45 137 6.5. Parameters needed for invoking traditional PSTN Services within 138 PINT ........................................................... 46 139 6.5.1. Service Identifier ....................................... 46 140 6.5.2. A and B parties .......................................... 46 141 6.5.3. Other Service Parameters ................................. 47 142 6.5.4. Service Parameter Summary ................................ 47 143 6.6. Parameter Mapping to PINT Extensions............................ 48 145 7. Open Issues and Draft State .......................................... 50 146 7.1. Open Issues .................................................... 50 147 7.2. Draft State .................................................... 50 149 8. References ........................................................... 52 151 9. Acknowledgements ..................................................... 53 153 Appendix A: Collected ABNF for PINT Extensions .......................... 54 155 Appendix B: IANA Considerations ......................................... 59 157 Appendix C: Authors' Addresses .......................................... 61 159 Petrack & Conroy [Page 3] 160 1. Introduction 162 The desire to invoke certain telephone call services from the Internet has 163 been identified by many different groups (users, public and private network 164 operators, call center service providers, equipment vendors, see [7]). The 165 generic scenario is as follows (when the invocation is successful): 167 1. an IP host sends a request to a server on an IP network; 168 2. the server relays the request into a telephone network; 169 3. the telephone network performs the requested call service. 171 As examples, consider a user who wishes to have a call placed to his/her 172 telephone. It may be that a customer wishes to get a call from the support 173 department of some business, or a user wishes to hear some remote automatic 174 weather service via recorded or synthesised speech. Within a local 175 environment such a request might result in the placement of a call between 176 employees over the internal PBX. 178 We use the term "PSTN/Internet Interworking (PINT) Service" to denote such a 179 complete transaction, starting with the sending of a request from an IP 180 client and including the telephone call itself. PINT services are 181 distinguished by the fact that they always involve two separate networks: an 182 IP network to request the placement of a call, and a telephone network to 183 execute the actual call. It is understood that Intelligent Network systems, 184 private PBXs, cellular phone networks, and the ISDN can all be used to 185 deliver PINT services. Also, the request for service might come from within 186 a private IP network that is disconnected from the whole Internet. 188 *-*- 189 The requirements for the PINT protocol were deliberately restricted to 190 providing the ability to invoke a small number of fixed telephone call 191 services. These "Milestone PINT services" are specified in section 2. Great 192 care has been taken, however, to develop a protocol that is aligned with 193 other Internet protocols where possible, so that future extensions to PINT 194 could develop along with Internet conferencing. 196 Within the Internet conference architecture, establishing media calls is 197 done via a combination of protocols. SIP [1] is used to establish the 198 association between the participants within the call (this association 199 between participants within the call is called a "session"), and SDP [2] is 200 used to describe the media to be exchanged within the session. The PINT 201 protocol uses these two protocols together, providing some extensions and 202 enhancements to enable SIP clients and servers to become PINT clients and 203 servers. 205 A PINT user who wishes to invoke a service within the telephone network uses 206 SIP to invite a remote PINT server into a session. The invitation contains 207 an SDP description of the media session that the user would like to take 208 place. This might be a "sending a fax session" or a "telephone call 209 session", for example. In a PINT service execution session the media is 210 transported over the phone system, while in a SIP session the media is 211 normally transported over an internet. 213 Petrack & Conroy [Page 4] 214 When used to invoke a PINT service, SIP establishes an association between a 215 requesting PINT client and the PINT server that is responsible for invoking 216 the service within the telephone network. These two entities are not the 217 same entities as the telephone network entities involved in the telephone 218 network service. The SIP messages carry within their SDP payloads a 219 description of the telephone network media session. 221 Note that the fact that a PINT server accepts an invitation and a session is 222 established is no guarantee that the media will be successfully transported. 223 (This is analogous to the fact that if a SIP invitation is accepted 224 successfully, this is no guarantee against a subsequent failure of audio 225 hardware). 227 The particular requirements of PINT users lead to some new messages. When a 228 PINT server agrees to send a fax to telephone B, it may be that the fax 229 transmission fails after part of the fax is sent. Therefore, the PINT client 230 may wish to receive information about the status of the actual telephone 231 call session that was invoked as a result of the established PINT session. 232 Two new requests, SUBSCRIBE and NOTIFY, are added here to vanilla SIP to 233 allow this. 235 The enhancements and additions specified here are not intended to alter the 236 behaviour of baseline SIP or SDP in any way. The purpose of PINT extension 237 is to extend the usual SIP/SDP services to the telephone world. Apart from 238 integrating well into existing protocols and architectures, and the 239 advantages of reuse, this means that the protocol specified here can handle 240 a rather wider class of call services than just the Milestone services. 242 The rest of this document is organised as follows: Section 2 describes the 243 PINT Milestone services; section 3 specifies the PINT functional 244 and protocol architecture; section 4 gives examples of the PINT 1.0 245 extensions of SIP and SDP; section 5 contains some security considerations 246 for PINT. The final section contains descriptions of how the PINT protocol 247 may be used to provide service over the GSTN. 249 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 250 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 251 document are to be interpreted as described in RFC 2119. In addition, the 252 construct "MUST .... OR ...." implies that it is an absolute requirement of 253 this specification to implement one of the two possibilities stated 254 (represented by dots in the above phrase). An implementation MUST be able to 255 interoperate with another implementation that chooses either of the two 256 possibilities. 258 1.1 Glossary 259 Requestor - An Internet host from which a request for service originates 261 PINT Service - A services invoked within a phone system in response to a 262 request received from an PINT client. 264 PINT Client - An Internet host that sends requests for invocation of a PINT 265 Service, in accordance with this document. 267 PINT Gateway - An Internet host that accepts requests for PINT Service and 268 dispatches them onwards towards a telephone network. 270 Petrack & Conroy [Page 5] 271 Executive System - A system that interfaces to a telephone network that 272 executes a PINT service, and to a PINT Server. It is not directly associated 273 with the Internet, and is represented by the PINT Server. 275 Requesting User - The initiator of a request for service. This role may be 276 distinct from that of the "party" to any telephone network call that results 277 from the request. 279 (Service Call) Party - A person who is involved in a telephone network call 280 that results from the execution of a PINT service request, or a telephone 281 network-based resource that is involved (such as an automatic Fax Sender or 282 a Text-to-Speech Unit). 284 2. PINT Milestone Services 286 The original motivation for defining this protocol was the desire to invoke 287 the following three telephone network services from within an IP network: 289 2.1 Request to Call 291 A request is sent from an IP host that causes a phone call to be made, 292 connecting party A to some remote party B. 294 2.2 Request to Fax 296 A request is sent from an IP host that causes a fax to be sent to fax 297 machine B. The request MUST contain a pointer to the fax data (that 298 could reside in the IP network or in the Telephone Network), OR 299 fax data itself. The content of the fax MAY be text OR some other 300 more general image data. The details of the fax transmission are not 301 accessible to the IP network, but remain entirely within the telephone 302 network. 304 The PINT Request to Fax service does not involve "Fax over IP": the IP 305 network is only used to send the request that a certain fax be sent. Of 306 course, it is possible that the resulting telephone network fax call happens 307 to use a real-time IP fax solution, but this is completely transparent to 308 the PINT transaction. 310 2.3 Request to Hear Content 312 A request is sent from an IP host that causes a phone call to be made to 313 user A, and for some sort of content to be spoken out. The request MUST 314 EITHER contain a URL pointing to the content, OR include the content itself. 315 The content MAY be text OR some other more general application data. The 316 details of the content transmission are not accessible to the IP network, 317 but remain entirely within the telephone network. 319 2.4 Relation between PINT milestone services and traditional telephone 320 services 322 There are many different versions and variations of each telephone call 323 service invoked by a PINT request. Consider as an example what happens when 324 a user requests to call 1-800-2255-287 via the PINT Request-to-Call service. 326 Petrack & Conroy [Page 6] 327 There may be thousands of agents in the call centre, and there may be any 328 number of sophisticated algorithms and equipments that are used to decide 329 exactly which agent will return the call. And once this choice is made, 330 there may be many different ways to set up the call: the agent's phone might 331 ring first, and only then the original user will be called; or perhaps the 332 user might be called first, and hear some horrible music or pre-recorded 333 message while the agent is located. 335 Similarly, when a PINT request causes a fax to be sent, there are hundreds 336 of fax protocol details to be negotiated, as well as transmission details 337 within the telephone networks used. 339 PINT requests do not specify too precisely the exact telephone-side service. 340 Operational details of individual events within the telephone network that 341 executes the request are outside the scope of PINT. This does not preclude 342 certain high-level details of the telephone network session from being 343 expressed within a PINT request. For example, it is possible to use the SDP 344 "lang" attribute to express a language preference for the 345 Request-to-Hear-Content Service. If a particular PINT system wishes to 346 allow requests to contain details of the telephone-network-side service, it 347 uses the SDP attribute mechanism (see section 3.4.2). 349 3. PINT Functional and Protocol Architecture 351 3.1. PINT Functional Architecture 353 Familiarity is assumed with SIP 2.0 [1] and with SDP 2.0 [2]. 354 -.-. 355 PINT clients and servers are SIP clients and servers. SIP is used to carry 356 the request over the IP network to the correct PINT server in a secure and 357 reliable manner, and SDP is used to describe the telephone network session 358 that is to be invoked or whose status is to be returned. 360 A PINT system uses SIP proxy servers and redirect servers for their usual 361 purpose, but at some point there must be a PINT server with the means to 362 relay received requests into a telephone system and to receive 363 acknowledgement of these relayed requests. A PINT server with this 364 capability is called a "PINT gateway". A PINT gateway appears to a SIP 365 system as a User Agent Server. Notice that a PINT gateway appears to the 366 PINT infrastructure as if it represents a "user", while in fact it really 367 represents an entire telephone network infrastructure that can provide a 368 set of telephone network services. 370 So the PINT system might appear to an individual PINT client as follows: 372 /\/\/\/\/\/\/\ /\/\/\/\/\/\/\/\ 373 ___________ \ __/___ ___\_ \ 374 | PINT | PINT \ PINT | PINT | |Exec| Telephone / 375 | client |<-------------->| server |gatewy|=====|Syst| Network \ 376 |_________| protocol / cloud |______| |____| Cloud / 377 \ \ / \ 378 /\/\/\/\/\/\/\ \/\/\/\/\/\/\/\/ 380 Figure 1: PINT Functional Architecture 382 Petrack & Conroy [Page 7] 383 The system of PINT servers is represented as a cloud to emphasise that a 384 single PINT request might pass through a series of location servers, proxy 385 servers, and redirect servers, before finally reaching the correct PINT 386 gateway that can actually process the request by passing it to the 387 Telephone Network Cloud. 389 The PINT gateway might have a true telephone network interface, or it might 390 be connected via some other protocol or API to an "Executive System" that 391 is capable of invoking services within the telephone cloud. 393 As an example, within an I.N. (Intelligent Network) system, the PINT gateway 394 might appear to realise the Service Control Gateway Function. In an office 395 environment, it might be a server adjunct to the office PBX, connected to 396 both the office LAN and the office PBX. 398 The Executive System that lies beyond the PINT gateway is outside the scope 399 of PINT. 401 3.2. PINT Protocol Architecture 403 This section explains how SIP and SDP work in combination to convey the 404 information necessary to invoke telephone network sessions. 406 *-*- -.-. 407 The following list summarises the extension features used in PINT 1.0. 408 Following on from this the features are considered separately for SDP and 409 then for SIP: 410 1) Telephony URLs in SDP Contact Fields 411 2) Refinement of SIP/SDP Telephony URLs 412 * Inclusion of private dialling plans 413 3) Specification of Telephone Service Provider (TSP) and/or 414 phone-context URL-parameters 415 4) Data Objects as session media 416 4a) Protocol Transport formats to indicate the treatment of the media 417 within the PSTN 418 5) Implicit (Indirect) media streams and opaque arguments 419 6) In-line data objects using multipart/mime 420 7) Refinement/Clarification of Opaque arguments passed onwards to Executive 421 Systems 422 * Framework for Presentation Restriction Indication 423 * Framework for Q.763 arguments 424 8) An extension mechanism for SDP to specify strictures and force 425 failure when a recipient does NOT support the specified extensions, 426 using "require" headers. 427 9) Mandatory support for "Warning" headers to give more detailed 428 information on request disposition. 429 10) Mechanism to register interest in the disposition of a requested 430 service, and to receive indications on that disposition. 432 -*-* 433 Both PINT and SIP rely on features of MIME[4]. The use of SIP 2.0 is implied 434 by PINT 1.0, and this also implies compliance with version 1.0 of MIME. 436 Petrack & Conroy [Page 8] 437 *-*- 438 3.2.1. SDP operation in PINT 440 The SDP payload contains a description of the particular telephone network 441 session that the requestor wishes to occur in the PSTN. This information 442 includes such things as the telephone network address (i.e. the "telephone 443 number") of the terminal(s) involved in the call, an indication of the media 444 type to be transported (e.g. audio, text, image or application data), and an 445 indication if the information is to be transported over the telephone 446 network via voice, fax, or pager transport. An indication of the content to 447 be sent to the remote telephone terminal (if there is any) is also included. 449 SDP is flexible enough to convey these parameters independently. For 450 example, a request to send some text via voice transport will be fulfilled 451 by invoking some text-to-speech-over-the-phone service, and a request to 452 send text via fax will be fulfilled by invoking some text-to-fax service. 454 The following is a list of PINT 1.0 enhancements and additions to SDP. 455 -.-. 456 a. A new network type "TN" and address types "RFC2543" and "X-..." 457 (section 3.4.1) 458 b. New media types "text", "image", and "application", 459 new protocol transport keywords "voice", "fax" and 460 "pager" and the associated format types and attribute tags 461 (section 3.4.2) 462 c. New format specific attributes for included content data 463 (section 3.4.2.4) 464 d. New attribute tags, used to pass information to the telephone 465 network (section 3.4.3) 466 e. A new attribute tag "require", used by a client to indicate that 467 some attribute is required to be supported in the server 468 (section 3.4.4) 470 *-*- 471 3.2.2. SIP Operation in PINT 473 SIP is used to carry the request for telephone service from the PINT client 474 to the PINT gateway, and may include a telephone number if needed for the 475 particular service. The following is a complete list of PINT enhancements 476 and additions to SIP: 478 f. The multipart MIME payloads (section 3.5.1) 479 g. Mandatory support for "Warning:" headers (section 3.5.2) 480 h. The SUBSCRIBE and NOTIFY requests (section 3.5.3) 481 i. Require: headers (section 3.5.4) 482 j. A format for PINT URLS within a PINT request (section 3.5.5) 483 k. Telephone Network Parameters within PINT URLs (section 3.5.6) 484 *-*- 486 Section 3.5.8 contains remarks about how BYE requests are used within PINT. 487 This is not an extension to baseline SIP; it is included here only for 488 clarification of the semantics when used with telephone network sessions. 490 Petrack & Conroy [Page 9] 491 3.3. REQUIRED and OPTIONAL elements for PINT compliance 493 *-*- 494 Of these, only the TN network type (with its associated RFC2543 address 495 type) and the "require" attribute MUST be supported by PINT 1.0 clients 496 and servers. In practice, most PINT service requests will use other changes, 497 of which references to Data Objects in requests are most likely to appear 498 in PINT requests. 500 Each of the other new PINT constructs enables a different function, and a 501 client or server that wishes to enable that particular function MUST do so 502 by the construct specified in this document. For example, building a PINT 503 client and server that provide only the Request-to-Call telephone call 504 service, without support for the other Milestone services, is allowed. 505 -.-. 506 The "Require:" SIP header and the "require" attribute provide a mechanism 507 that can be used by clients and servers to signal their need and/or 508 ability to support specific "new" PINT protocol elements. 510 It should be noted that many optional features of SIP and SDP make sense as 511 specified in the PINT context. One example is the SDP a=lang: attribute, 512 which can be used to describe the preferred language of the callee. Another 513 example is the use of the "t=" parameter to indicate that the time at which 514 the PINT service is to be invoked. This is the normal use of the "t=" field. 515 A third example is the quality attributes. Any SIP or SDP option or 516 facility is available to PINT clients and servers without change. 518 *-*- 519 Conversely, support for Data Objects within Internet Conference sessions may 520 be useful, even if the aim is not to provide a PSTN service request. In this 521 case, the extensions covering these items may be incorporated into an 522 otherwise "plain" SIP/SDP invitation. Likewise, support for SDP "require" 523 may be useful, as a framework for addition of features to a "traditional" 524 SIP/SDP infrastructure. Again, these may be convenient to incorporate into 525 SIP/SDP implementations that would not be used for PINT service requests. 526 Such additions are beyond the scope of this document, however. 528 3.4. PINT Extensions to SDP 2.0 530 PINT 1.0 adds to SDP the possibility to describe audio, fax, and pager 531 telephone sessions. It is deliberately designed to hide the underlying 532 technical details and complexity of the telephone network. The only network 533 type defined for PINT is the generic "TN" (Telephone Network). More precise 534 tags such as "ISDN", "GSM", are not defined. Similarly, the transport 535 protocols are designated simply as "fax", "voice", and "pager"; there are no 536 more specific identifiers for the various telephone network voice, fax, or 537 pager protocols. Similarly, the data to be transported is identified only as 538 a MIME type, such as "text" data, "image" data, or some more general 539 "application" data, etc. An important example of transporting "application" 540 data is the milestone service "Voice Access to Web Content". In this case 541 the data to be transported is pointed to by a URI, the data type is 542 application/URI, and the transport protocol would be "voice". Some sort of 543 speech-synthesis facility, speaking out to a Phone, will have to be invoked 544 to perform this service. 546 This section gives details of the new SDP keywords. 548 3.4.1. Network Type "TN" and Address Type "RFC2543" 550 The TN ("Telephone Network") network type is used to indicate that the 551 terminal is connected to a telephone network. 553 The address types allowed for network type TN are "RFC2543" and private 554 address types, which MUST begin with an "X-". 555 -.-. 556 Address type RFC2543 is followed by a string conforming to a subset of the 557 "telephone-subscriber" BNF specified in RFC2543, (this is specified in 558 figure 4 of SIP [1]). Note that this BNF is NOT identical to the BNF that 559 defines the "phone-number" within the "p=" field of SDP. 561 Examples: 563 c= TN RFC2543 +1-201-406-4090 565 c= TN RFC2543 12014064090 567 *-*- 568 A telephone-subscriber string is of one of two types: global-phone-number or 569 local-phone-number. These are distinguished by preceeding a 570 global-phone-number with a "plus" sign ("+"). A global-phone-number is by 571 default to be interpreted as an internationally significant E.164 Number 572 Plan Address, as defined by [6], whilst a local-phone-number is a number 573 specified in the default dialling plan within the context of the recipient 574 PINT Gateway. 576 An implementation MAY use private addressing types, which can be useful 577 within a local domain. These address types MUST begin with an "X-", and 578 SHOULD contain a domain name after the X-, e.g. "X-mytype.mydomain.com". 579 An example of such a connection line is as follows: 581 c= TN X-mytype.mydomain.com A*8-HELEN 583 where "X-mytype.mydomain.com" identifies this private address type, and 584 "A*8-HELEN" is the number in this format. Such a format is defined as an 585 "OtherAddr" in the ABNF of Appendix A. 586 Note that most dialable telephone numbers are expressable as 587 local-phone-numbers within address RFC2543; new address types should only be 588 used for formats which cannot be so written. 590 *-*- 591 3.4.2. Support for Data Objects within PINT 593 One significant change over traditional SIP/SDP Internet Conference sessions 594 with PINT is that a PINT service request may refer to a Data Object to be 595 used as source information in that request. For example, a PINT service 596 request may specify a document to be processed as part of a GSTN service by 597 which a Fax is sent. Similarly, a GSTN service may be take a Web page and 598 result in a vocoder processing that page and speaking the contents over a 599 telephone. 601 The SDP specification does not have explicit support for reference to or 602 carriage of Data Objects within requests. In order to use SDP for PINT, 603 there is a need to describe such media sessions as "a telephone call to a 604 certain number during which such-and-such an image is sent as a fax". 606 To support this, two extensions to the session description format are 607 specified. These are some new allowed values for the Media Field, 608 and a description of the "fmtp" parameter when used with the Media 609 Field values (within the context of the Contact Field Network type "TN"). 611 An addition is also made to the SIP message format to allow the inclusion 612 of data objects as sub-parts within the request message itself. 613 The original SDP syntax (from [2]) for media-field is given as: 614 media-field = "m=" media space port ["/" integer] 615 space proto 1*(space fmt) CRLF 616 When used within PINT requests, the definition of the sub-fields is 617 expanded slightly. 618 The Media sub-field definition is relaxed to accept all of the discrete 619 "top-level" media types defined in [4]. In the milestone services the 620 discrete type "video" is not used, and the extra types "data" and "control" 621 are likewise not needed. The use of these types is not precluded, but the 622 behaviour expected of a PINT Gateway receiving a request including such a 623 type is not defined here. 624 -.-. 625 The Port sub-field has no meaning in PINT requests as the destination 626 terminals are specified using "TN" addressing, so the value of the port 627 sub-field in PINT requests is normally set to "1". A value of "0" may 628 be used as in SDP to indicate that the terminal is not receiving media. 629 This is useful to indicate that a telephone terminal has gone "on hold" 630 temporarily. Likewise, the optional integer sub-field is not used in PINT. 632 As mentioned in [2], the Transport Protocol sub-field is specific to the 633 associated Address Type. In the case that the Address Type in the preceeding 634 Contact field is one of those defined for use with the Network Type "TN", 635 the following values are defined for the Transport Protocol sub-field: 636 "voice", "fax", and "pager". 638 The interpretation of this sub-field within PINT requests is the treatment 639 or disposition of the resulting GSTN service. Thus, for transport protocol 640 "voice", the intent is that the service will result in a GSTN voice call, 641 whilst for protocol "fax" the result will be a GSTN fax transmission, and 642 protocol "pager" will result in a pager message being sent. 644 Note that this sub-field does not necessarily dictate the media type and 645 subtype of any source data; for example, one of the milestone services calls 646 for a textual source to be vocoded and spoken in a resulting telephone 647 service call. The transport protocol value in this case would be "voice", 648 whilst the media type would be "text". 649 -.-. 650 The Fmt sub-field is described in [2] as being transport protocol-specific. 651 When used within PINT requests having one of the above protocol values, 652 this sub-field consists of a list of one or more values, each of which is 653 a defined MIME sub-type of the associated Media sub-field value. The 654 special value "-" is allowed, meaning that there is no MIME sub-type. 655 This sub-field retains (from [2]) its meaning that the list will contain 656 a set of alternative sub-types, with the first being the preferred value. 658 -.-. 659 For experimental purposes and by mutual consent of the sender and recipient, 660 a sub-type value may be specified as an , i.e. a character string 661 starting with "X-". The use of such values is discouraged, and if such a 662 value is expected to find common use then it SHOULD be registered with IANA 663 using the standard content type registration process (see Appendix C). 664 -.-. 665 When the Fmt parameter is the single character "-" ( a dash ), this is 666 interpreted as meaning that a unspecified or default sub-type should be used 667 for this service. Thus, the media field value "m=audio 1 voice -" is 668 taken to mean that a voice call is requested, using whatever audio sub type 669 is deemed appropriate by the Executive System. PINT service is a special 670 case, in that the request comes from the IP network but the service call is 671 provided within the GSTN. Thus the service request will not normally be able 672 to define the particular codec used for the resulting GSTN service call. If 673 such an intent IS required, then the quality attribute may be used (see 674 "Suggested Attributes" section of [2]). 676 3.4.2.1. Use of fmtp attributes in PINT requests 678 For each element of the Fmt sub-field, there MUST be a following fmtp 679 attribute. When used within PINT requests, the fmtp attribute has a general 680 structure as defined here: 681 "a=fmtp:" resolution 682 *( resolution) 683 ( ";" 1() *( )) 684 where: 685 := ( | | ) 687 A fmtp attribute describes the sources used with a given Fmt entry in the 688 Media field. The entries in a Fmt sub-field are alternatives (with the 689 preferred one first in the list). Each entry will have a matching fmtp 690 attribute. The list of resolutions in a fmtp attribute describes the set of 691 sources that resolve the matching Fmt choice; all elements of this set will 692 be used. 694 It should be noted that, for use in PINT services, the elements in such a 695 set will be sent as a sequence; it is unlikely that trying to send them in 696 parallel would be successful. 698 A fmtp attribute can contain a mixture of different kinds of element. Thus 699 an attribute might contain a sub-part-ref to included data held in a 700 sub-part of the current message, followed by an opaque-ref to some content 701 on the GSTN, followed by a uri-ref pointing to some data held externally on 702 the IP network. 704 To indicate which form each resolution element takes, each of them 705 starts with its own literal tag. The detailed syntax of each form is 706 described in the following sub-sections. 708 3.4.2.2. Support for Remote Data Object References in PINT 709 Where data objects stored elsewhere on the IP Network are to be used as 710 sources for processing within a PINT service, they may be referred to using 711 the uri-ref form. This is simply a Uniform Resource Identifier (URI), as 712 described in [9]. 714 Note that the reference SHOULD be an absolute URI, as there may not be 715 enough contextual information for the recipient server to resolve a relative 716 reference; any use of relative references requires some private agreement 717 between the sender and recipient of the message, and should be avoided 718 unless the sender can be sure that the recipient is the one intended and the 719 reference is unambiguous in context. 721 This also holds for partial URIs (such as: "uri:http://aMachine/index.html") 722 as these will need to be resolved in the context of the eventual recipient 723 of the message. 725 The general syntax of a reference to an Internet-based external data object 726 in a fmtp line within a PINT session description is: 727 := ("uri:" URI-reference) 729 where URI-reference is as defined in Appendix A of [9] 731 For example: 732 c= TN RFC2543 +1-201-406-4090 733 m= text 1 fax plain 734 a=fmtp:plain uri:ftp://ftp.isi.edu/in-notes/rfc2468.txt 735 or: 736 c= TN RFC2543 +1-201-406-4090 737 m= text 1 fax plain 738 a=fmtp:plain uri:http://www.ietf.org/meetings/glance_minneapolis.txt 740 means get this data object from the Internet and use it as a source for the 741 requested GSTN Fax service. 743 3.4.2.3. Support for GSTN-based Data Objects in PINT 745 PINT services may refer to data that is held not on the IP Network but 746 instead within the GSTN. The way in which these items are indicated need 747 have no meaning within the context of the Requestor or the PINT Gateway; it 748 is merely some data that may be used by the Executive System to indicate the 749 content intended as part of the request. This data forms an opaque 750 reference, in that it is sent "untouched" through the PINT infrastructure. 752 A reference to some data object held on the GSTN has the general definition: 753 := ("opr:" *uric) 755 where uric is as defined in Appendix A of [9]. 757 For example: 758 c= TN RFC2543 +1-201-406-4090 759 m= text 1 fax plain 760 a=fmtp:plain opr:APPL.123.456 762 means send me the data that is indexed ON THE GSTN by the reference value 763 "APPL.123.456"; the Executive System may also take the Telephone URL held in 764 the To: field of the enclosing SIP message into account when deciding the 765 context to be used for the data object dereference. 767 Of course, an opaque reference may also be used for other purposes; it 768 could, for example, be needed to authorise access to a document held on the 769 GSTN rather than being required merely to disambiguate the data object. The 770 purpose to which an opaque reference is put, however, is out of scope for 771 this document. It is merely an indicator carried within a PINT Request. 773 An opaque reference may have no value in the case where the value to be used 774 is implicit in the rest of the request. For example, suppose some company 775 wishes to use PINT to implement a "fax-back service". In their current 776 implementation, the image(s) to be faxed are entirely defined by the 777 telephone number dialled. Within the PINT request, this telephone number 778 would appear within the "to:" field of the PINT request, and so there 779 is no need for an opaque reference value. 781 If there are several resolutions for a PINT Service Request, and one of 782 these is an opaque reference with no value, then that opaque reference MUST 783 be included in the attribute line, but with an empty value field. 785 For example: 786 c= TN RFC2543 +1-201-406-4090 787 m= text 1 fax plain 788 a=fmtp:plain spr: opr: 790 might be used to precede some unambiguous "faxed back" data with a covering 791 note (see next sub-section for details of the sub-part reference). 793 In the special case where an opaque reference is the sole resolution of a 794 PINT Service Request, AND that reference needs no value, there is no need 795 for a Fmt list at all; the intent of the service is unambiguous without any 796 further resolution. 798 For example: 799 c= TN RFC2543 +1-201-406-4090 800 m= text 1 fax - 802 means that there is an implied content stored on the GSTN, and that this is 803 uniquely identified by the combination of SIP To-URI and the Contact field 804 of the session description. 806 *-*- 807 3.4.2.4. Session Description support for included Data Objects 809 As an alternative to pointing to the data via a URI or an opaque reference 810 to a data item held on the GSTN, it is possible to include the content data 811 within the SIP request itself. This is done by using multipart MIME for the 812 SIP payload. The first MIME part contains the SDP description of the 813 telephone network session to be executed. The other MIME parts contain the 814 content data to be transported. 816 Format specific attribute lines within the session description are used to 817 indicate which other MIME part within the request contains the content data. 818 Instead of a URI or opaque reference, the format-specific attribute 819 indicates the Content-ID of the MIME part of the request that contains the 820 actual data, and is defined as: 821 := ("spr:" Content-ID) 823 where Content-ID is as defined in Appendix A of [3] and in [10]). 825 For example: 826 c= TN RFC2543 +1-201-406-4090 827 m= text 1 fax plain 828 a=fmtp:plain spr: 829 *-*- 830 The parameter is the Content-ID of one of the MIME parts inside 831 the message, and this fragment means that the requesting user would like the 832 data object held in the sub-part of this message labelled to be 833 faxed to the machine at phone number +1-201-406-4090. 835 *-*- 836 See also section 3.5.1 for a discussion on the support needed in the 837 enclosing SIP request for included data objects. 839 3.4.3. Attribute Tags to pass information into the Telephone Network 841 *-*- 842 It may be desired to include within the PINT request service parameters 843 that can be understood only by some entity in the "Telephone Network 844 Cloud". SDP attribute parameters are used for this purpose. They MAY appear 845 within a particular media description or outside of a media description. 847 These attributes may also appear as parameters within PINT URLS (see section 848 3.5.6) as part of a SIP request. 850 This is necessary so that telephone terminals that require the attributes to 851 be defined can appear within the To: line of a PINT request as well as 852 within PINT session descriptions. 854 The purpose of these attributes is to allow the client to specify extra 855 context within which a particular telephone number is to be interpreted. 856 There are many reasons why extra context might be necessary to interpret a 857 given telephone number: 858 a. The telephone number might be reachable in many different ways 859 (such as via competing telephone service providers), and the PINT 860 client wishes to indicate its selection of service provider. 861 b. The telephone number might be reachable only from a limited 862 number of networks (such as an '800' freephone number). 863 c. The telephone number might be reachable only within a 864 single telephone network (such as the '152' customer service 865 number of BT). Similarly, the number might be an internal 866 corporate extension reachable only within the PBX. 868 However, as noted above, it is not usually necessary to use SDP 869 attributes to specify the phone context. URLs such as 152@pint.bt.co.il 870 within the To: and From: headers and/or Request-URI, normally offer 871 sufficient context to resolve telephone numbers. 872 -.-. 873 If the client wishes the request to fail if the attributes are not 874 supported, these attributes should be used in conjunction with the 875 "require" attribute (section 3.4.4) and the "Require:org.ietf.sdp.require" 876 header (section 3.5.4). 878 It is not possible to standardise every possible internal telephone network 879 parameter. PINT 1.0 attributes have been chosen for specification because 880 they are common enough that many different PINT systems will want to use 881 them, and therefore interoperability will be increased by having a single 882 specification. 884 *-*- 885 Proprietary attribute "a=" lines, that by definition are not interoperable, 886 may be nonetheless useful when it is necessary to transport some proprietary 887 internal telephone network variables over the IP network, for example to 888 identify the order in which service call legs should be made. These private 889 attributes SHOULD BE, however, subject to the same IANA registration 890 procedures mentioned in the SDP specification[2] (see also this Appendix C). 892 3.4.3.1. The phone-context attribute 894 An attribute is specified to enable "remote local dialling". This is the 895 service that allows a PINT client to reach a number from far outside the 896 area or network that can usually reach the number. It is useful when the 897 sending or receiving address is only dialable within some local context, 898 which may be remote to the origin of the PINT client. 900 For example, if Alice wanted to report a problem with her telephone, she 901 might then dial a "network wide" customer care number; within the British 902 Telecom network in the U.K., this is "152". Note that in this case she 903 doesn't dial any trunk prefix - this is the whole dialable number. If 904 dialled from another operator's network, it will not connect to British 905 Telecom's Engineering Enquiries service; and dialling "+44 152" will not 906 normally succeed. Such numbers are called Network-Specific Service Numbers. 908 Within the telephone network, the "local context" is provided by the 909 physical connection between the subscriber's terminal and the central 910 office. An analogous association between the PINT client and the PINT server 911 that first receives the request may not exist, which is why it may be 912 necessary to supply this missing "telephone network context". 914 This attribute is defined as follows: 916 a=phone-context: 917 phone-context-ident = network-prefix / private-prefix 919 network-prefix = intl-network-prefix / local-network-prefix 920 intl-network-prefix = "+" 1*DIGIT 921 local-network-prefix = 1*DIGIT 922 excldigandplus = (0x21-0x2d,0x2f,0x40-0x7d)) 923 private-prefix = 1*excldigandplus 0*uric 925 An intl-network-prefix and local-network-prefix MUST be a bona fide network 926 prefix, and a network-prefix that is an intl-network-prefix MUST begin with 927 an E.164 service code ("country code"). 929 It is possible to register new private-prefixes with IANA so as to avoid 930 confrontation. Prefixes that are not so registered MUST begin with an "X-" 931 to indicate their private, non-standard nature (see Appendix C). 933 Example 1: 935 c= TN RFC2543 1-800-765-4321 936 a=phone-context:+972 938 This describes an terminal whose address in Israel (E.164 country code 972) 939 is 1-800-765-4321. 941 Example 2: 943 c= TN RFC2543 1-800-765-4321 944 a=phone-context:+1 946 This describes an terminal whose address in North America (E.164 country 947 code 1) is 1-800-765-4321. 949 The two telephone terminals described by examples 1 and 2 are different; in 950 fact they are located in different countries. 952 Example 3: 953 -.-. 954 c=TN RFC2543 123 955 a=phone-context:+97252 956 -.-. 957 This describes a terminal whose address when dialled from within the network 958 identified by +97252 is the string "123". It so happens that +97252 defines 959 one of the Israeli cell phone providers, and 123 reaches customer service 960 when dialled within that network. 961 -.-. 962 It may well be useful or necessary to use the SDP "require" parameter in 963 conjunction with the phone-context attribute. 965 Example 4: 967 c= TN RFC2543 321 968 a=phone-context:X-acme.com 23 970 This might describe the telephone terminal that is at extension 321 of PBX 971 number 23 within the acme.com private PBX network. It is expected that such 972 a description would be understandable by the acme.com PINT server that 973 receives the request. 975 Note that if the PINT server receiving the request is inside the acme.com 976 network, the same terminal might be addressable as follows: 978 c= TN RFC2543 7-23-321 980 (assuming that "7" is dialled in order to reach the private PBX network from 981 within acme.com) 983 *-*- 984 *-*- 985 3.4.3.2. Presentation Restriction attribute 987 Although it has no affect on the transport of the service request through 988 the IP Network, there may be a requirement to allow originators of a PINT 989 service request to indicate whether or not they wish the "B party" in 990 the resulting service call to be presented with the "A party's" calling 991 telephone number. It is a legal requirement in some jurisdictions that a 992 caller be able to select whether or not their correspondent can find out 993 the calling telephone number (using Automatic Number Indication or Caller 994 Display or Calling Line Identity Presentation equipment). Thus an attribute 995 may be needed to indicate the originator's preference. 997 Whether or not the default behaviour of the Executive System is to present 998 or not present a party's telephone number to the correspondent GSTN terminal 999 is not specified, and it is not mandatory in all territories for a PINT 1000 Gateway or Executive System to act on this attribute. It is, however, 1001 defined here for use where there are regulatory restrictions on GSTN 1002 operation, and in that case the Executive System can use it to honour the 1003 originator's request. 1005 The attribute is specified as follows: 1006 a=clir:<"true" | "false"> 1008 This boolean value is needed within the attribute as it may be that the GSTN 1009 address is, by default, set to NOT present its identity to correspondents, 1010 and the originator wants to do so for this particular call. It is in keeping 1011 with the aim of this attribute to allow the originator to specify what 1012 treatment they want for the requested service call. 1014 The expected interpretation of this attribute is that, if it is present and 1015 the value is "false" then the Calling Line Identity CAN be presented to the 1016 correspondent terminal, whilst if it is "true" then it if possible the 1017 Executive System is requested to NOT present the Calling Line Identity. 1019 *-*- 1020 3.4.3.3. ITU-T CalledPartyAddress attributes parameters 1022 These attributes correspond to fields that appear within the ITU-T Q.763 1023 "CalledPartyAddress" field (see [8] ,section 3.9). PINT clients 1024 use these attributes in order to specify further parameters relating to 1025 Terminal Addresses, in the case when the address indicates a 1026 "local-phone-number". In the case that the PINT request contains a 1027 reference to a PSTN terminal, the parameters may be required to correctly 1028 identify that remote terminal. 1030 *-*- 1031 The general form of this attribute is "a=Q763-((":" ) |"")". 1032 Three of the possible elements and their use in SDP attributes are described 1033 here. Where other Q763 elements are to be used, then these should be the 1034 subject of further specification to define the syntax of the attribute 1035 mapping. It is recommended that any such specification maintains the value 1036 sets shown in Q.763. 1038 The defined attributes are: 1040 a=Q763-nature: - indicates the "nature of address indicator". 1041 The value MAY be any number between 0 and 127. 1042 The following values are specified: 1044 "1" a subscriber number 1045 "2" unknown 1046 "3" a nationally significant number 1047 "4" an internationally significant number 1049 The values have been chosen to coincide with the values in Q.763. Note 1050 that other values are possible, according to national rules or future 1051 expansion of Q.763. 1053 a=Q763-plan: - indicates the numbering plan to which the address 1054 belongs. The value MAY be any number between 0 and 1055 7. The following values are specified: 1057 "1" Telephone numbering plan (ITU-T E.164) 1058 "3" Data numbering plan (ITU-T X.121) 1059 "4" Telex numbering plan (ITU-T F.69) 1061 The values have been chosen to coincide with the values in Q.763. 1062 Other values are allowed, according to national rules or future 1063 expansion of Q.763. 1065 a=Q763-INN - indicates if routing to the Internal Network Number 1066 is allowed. The value MUST be ONE of: 1068 "0" routing to internal network number allowed 1069 "1" routing to internal network number not 1070 allowed 1072 The values have been chosen to coincide with the values in Q.763. 1074 Note that it is possible to use a local-phone-number and indicate via 1075 attributes that the number is in fact an internationally significant 1076 E.164 number. Normally this SHOULD NOT be done; an internationally 1077 significant E.164 number is indicated by using a "global-phone-number" 1078 for the address string. 1079 -.-. 1080 3.4.4. The "require" attribute 1081 -.-. 1082 According to the SDP specification, a PINT server is allowed simply to 1083 ignore attribute parameters that it does not understand. In order to force a 1084 server to fail a request if it does not understand one of the PINT 1085 attributes, a client should use the "require" attribute, specified as 1086 follows: 1087 -.-. 1088 a=require: 1090 where the attribute-list is a comma-separated list of attributes that appear 1091 elsewhere in the session description. 1093 -.-. 1094 In order to process the request successfully the PINT server must BOTH 1095 understand the attribute AND ALSO fulfil the request implied by the presence 1096 of the attribute, for each attribute appearing within the attribute-list of 1097 the require attribute. 1099 If the server does not recognise the attribute listed, the PINT server MUST 1100 return an error status code (such as 420 (Bad Extension) or 400 (Bad 1101 Request)), 1102 and SHOULD return suitable Warning: lines explaining the problem or an 1103 Unsupported: header containing the attribute it does not understand. If the 1104 server recognizes the attribute listed, but cannot fulfil the request implied 1105 by the presence of the attribute, the request MUST fail with a status code 1106 of (606 Not Acceptable), along with a suitable Unsupported: header or 1107 Warning: line. 1108 -.-. 1109 The "require" attribute may appear anywhere in the session description, and 1110 any number of times, but it MUST appear before the use of the attribute 1111 marked as required. 1112 -.-. 1113 Since the "require" attribute is itself an attribute, the SIP specification 1114 allows a server that does not understand the require attribute to ignore 1115 it. In order to ensure that the PINT server will comply with the "require" 1116 attribute, a PINT client should include a Require: header with the tag 1117 "ietf.org.sdp.require" (section 3.5.4) 1119 *-*- 1120 Note that the majority of the PINT extensions are "tagged" and these tags 1121 can be included in Require strictures. The exception is the use of phone 1122 numbers in SDP parts. However, these are defined as a new network and 1123 address type, so that a receiving SIP/SDP server should be able to detect 1124 whether or not it supports these forms. The default behaviour for any SDP 1125 recipient is that it will fail a PINT request if it does not recognise or 1126 support the TN and RFC2543 or X-token network and address types, as without 1127 the contents being recognised no media session could be created. Thus a 1128 separate stricture is not required in this case. 1130 3.5. PINT Extensions to SIP 2.0 1132 PINT requests are SIP requests; Many of the specifications within this 1133 document merely explain how to use existing SIP facilities for the purposes 1134 of PINT. 1136 *-*- 1137 3.5.1. Multi-part MIME (sending data along with SIP request) 1139 A PINT request can contain a payload which is multipart MIME. In this case 1140 the first part MUST contain an SDP session description that includes at 1141 least one of the format specific attribute tags for "included content data" 1142 specified above in section 3.4.3. All subsequent parts contain content data 1143 that is to be transferred to the requested Telephone Call Service. As 1144 discussed earlier, within a single PINT request, some of the data MAY be 1145 pointed to by a URI within the request, and some of the data MAY be included 1146 within the request. 1148 *-*- 1149 Where included data is carried within a PINT service request, the Content 1150 Type entity header of the enclosing SIP message MUST indicate this. To do 1151 so, the media type value within this entity header MUST be set to a value of 1152 "multipart". 1154 The enclosed body parts SHOULD include the part-specific Content Type 1155 headers as appropriate ("application/sdp" for the first body part holding 1156 the session description, with an appropriate content type for each of the 1157 subsequent, "included data object" parts). This matches the standard syntax 1158 of MIME multipart messages as defined in [4]. 1160 For example, in a multipart message where the string "------next-------" is 1161 the boundary, the first two parts might be as follows: 1163 ------next------- 1164 Content-Type: application/sdp 1165 .... 1166 c= TN RFC2543 +1-201-406-4090 1167 m= text 1 pager plain 1168 a=fmtp:plain spr:17@mymessage.acme.com 1170 ----------next------- 1171 Content-Type: text/plain 1172 Content-ID: 17@mymessage.acme.com 1174 This is the text that is to be paged to +1-201-406-4090 1176 ----------next----------- 1178 The ability to indicate different alternatives for the content to be 1179 transported is useful, even when the alternatives are included within the 1180 request. For example, a request to send a short message to a pager might 1181 include the message in Unicode [5] and an alternative version of the same 1182 content in text/plain, should the PINT server or telephone network not be 1183 able to process the unicode. 1185 PINT clients should be extremely careful when sending included data within a 1186 PINT request. Such requests SHOULD be sent via TCP, to avoid fragmentation 1187 and to transmit the data reliably. It is possible that the PINT server is a 1188 proxy server that will replicate and fork the request, which could be 1189 disastrous if the request contains a large amount of application data. PINT 1190 proxy servers should be careful not to create many copies of a request with 1191 large amounts of data in it. If the client does not know the actual location 1192 of the PINT gateway, and is using the SIP location services to find it, and 1193 the included data makes the PINT request likely to be transported in several 1194 IP datagrams, it is RECOMMENDED that the initial PINT request not include 1195 the data but instead hold a reference to it. 1197 3.5.2. Warning header 1199 A PINT server MUST support the SIP "Warning:" header so that it can signal 1200 lack of support for individual PINT features. As an example, suppose the 1201 PINT request is to send a jpeg picture to a fax machine, but the server 1202 cannot retrieve and/or translate jpeg pictures from the Internet into fax 1203 transmissions. 1205 In such a case the server fails the request and includes a 1206 Warning such as the following: 1208 Warning: 305 pint.acme.com Incompatible media format: jpeg 1210 SIP servers that do not understand the PINT extensions at all are strongly 1211 encouraged to implement Warning: headers to indicate that PINT extensions 1212 are not understood. 1214 Also, Warning: headers may be included within NOTIFY requests if it is 1215 necessary to notify the client about some condition concerning the 1216 invocation of the PINT service (see next). 1218 *-*- 1219 3.5.3. Mechanism to register interest in the disposition of a PINT service, 1220 and to receive indications on that disposition 1222 It can be very useful to find out whether or not a requested service has 1223 completed, and if so whether or not it was successful. This is especially 1224 true for PINT service, where the person requesting the service is not 1225 (necessarily) a party to it, and so may not have an easy way of finding out 1226 the disposition of that service. Equally, it may be useful to indicate when 1227 the service has changed state, for example when the service call has 1228 started. 1230 Arranging a flexible system to provide extensive monitoring and control 1231 during a service is non-trivial (see section 6.4 for some issues); PINT 1.0 1232 uses a simple scheme that should nevertheless provide useful information. It 1233 is possible to expand the scheme in a "backwards compatible" manner, so if 1234 required it can be enhanced at a later date. Such enhancement would be 1235 expected to be the subject of a separate document. 1237 The PINT 1.0 status registration and indication scheme uses two new methods; 1238 SUBSCRIBE and NOTIFY. These are used to allow a PINT Requesting entity to 1239 register an interest in (or "subscribe" to) the status of a service request, 1240 and for the gateway to return service indications. Both of these messages 1241 follow the same procedure as used for all the SIP requests other than 1242 INVITE; the recipient MUST acknowledge the request with a final response 1243 message, otherwise the request will be repeated. 1244 -.-. 1245 3.5.3.1. Opening a monitoring session with a SUBSCRIBE request 1246 The SUBSCRIBE request indicates that a user wishes to receive information 1247 about the status of a session. The request identifies the session of interest 1248 normally by including the original session description along with the request. 1249 Where the subscription is being made by the user who initiated the original 1250 service request, the Call-ID may be used as it will be known to the receiver 1251 to refer to a previously established session. (When the request comes from a 1252 user other than the original requesting user, the request constitutes a new 1253 call, so the Call-ID should not be used; instead the origin-field of the 1254 session description enclosed within the original service request is used). 1255 The request MUST NOT include whatever content was present in the original 1256 request other than the session description, and a server MUST ignore 1257 whatever content is included within a SUBSCRIBE request with the sole 1258 exception of the enclosed session description. 1260 -.-. 1261 The request MAY contain a "Contact:" header, specifying the PINT User Agent 1262 Server to which such information should be sent. In addition, it SHOULD 1263 contain an Expires: header, which indicates for how long the PINT Requestor 1264 wishes to receive notification of the session status. See section 5.1.4. 1265 for security considerations, particularly privacy implications. 1267 A value of 0 within the Expires: header indicates a desire to receive one 1268 single immediate response (i.e. the request expires immediately). We refer 1269 to the period of time before the expiration of the SUBSCRIBE request as the 1270 "subscription period". 1272 A successful response to the SUBSCRIBE request includes the session 1273 description, according to the Gateway. Normally this will be identical to 1274 the last cached response that the Gateway returned to any request concerning 1275 the same SDP global session id (see [2], section 6, o= field). The t= line 1276 may be altered to indicate the actual start or stop time, however. The 1277 Gateway might add an i= line to the session description to indicate such 1278 information as how many fax pages were sent. The Gateway SHOULD include an 1279 Expires: header indicating how long it is willing to maintain the monitoring 1280 session. If this is unacceptable to the PINT Requestor, then it can close 1281 the session by sending an immediate BYE (see 3.5.3.3). 1283 In principle, a user might send a SUBSCRIBE request after the telephone 1284 network service has completed. This allows, for example, checking up "the 1285 morning after" to see if the fax was successfully transmitted. However, a 1286 PINT gateway is only required to keep state about a call for as long as it 1287 indicated previously in a Expires: header within the response to the 1288 original INVITE message that triggered the service session, within the 1289 response to the SUBSCRIBE message, or within its BYE message (but see 1290 section 3.5.8, point 3). 1292 If the Server no longer has a record of the session to which a Requestor has 1293 SUBSCRIBEd, it returns "606 Not Acceptable", along with the appropriate 1294 Warning: 307 header indicating that the SDP session ID is no longer valid. 1295 This means that a requesting Client that knows that it will want information 1296 about the status of a session after the session terminates SHOULD send a 1297 SUBSCRIBE request before the session terminates. 1299 3.5.3.2. Sending Status Indications with a NOTIFY request 1300 During the subscription period, the Gateway may, from time to time, send a 1301 spontaneous NOTIFY request to the entity indicated in the Contact: header of 1302 the "opening" SUBSCRIBE request. Normally this will happen as a result of 1303 any change in the status of the service session for which the Requestor has 1304 subscribed. 1306 The receiving user agent server MUST acknowledge this by returning a final 1307 response (normally a "200 OK"). In this version of the PINT extensions, the 1308 Gateway is not required to support redirects (3xx codes), and so may treat 1309 them as a failure. Thus, if the response code class is above 2xx then this 1310 may be treated by the Gateway as a failure of the monitoring session, and in 1311 that situation it will immediately attempt to close the session (see next). 1313 The NOTIFY request contains the modified session description. For example, 1314 the Gateway may be able to indicate a more accurate start or stop time. 1316 The Gateway may include a Warning: header to describe some problem with the 1317 invocation of the service, and may indicate within an i= line some 1318 information about the telephone network session itself. 1320 Example: 1322 NOTIFY sip:petrack@pager.com SIP/2.0 1323 To:sip:petrack@pager.com 1324 From:sip:R2F.pint.com@service.com 1325 Warning: xxx fax aborted, will try for the next hour. 1326 Content-Type:application/sdp 1328 c=... 1329 i=3 pages of 5 sent 1330 t=... 1332 3..5.3.3. Closing a monitoring session with a BYE request 1334 At some point, either the Client's representative User Agent Server or the 1335 Gateway may decide to terminate the monitoring session. This is achieved by 1336 sending a BYE request to the correspondent server. Such a request indicates 1337 that the sender intends to close the monitoring session immediately, and, on 1338 receipt of the final response from the receiving server, the session is 1339 deemed over. 1341 If the Gateway initiates closure of the monitoring session by sending a BYE 1342 message, it SHOULD include an "Expires:" header showing for how much longer 1343 after this monitoring session is closed it is willing to store information 1344 on the service session. This acts as a minimum time within which the Client 1345 can send a new SUBSCRIBE message to open another monitoring session; after 1346 the time indicated in the Expires: header the Gateway is free to dispose of 1347 any record of the service session, so that subsequent SUBSCRIBE requests can 1348 be rejected with a "606" response. 1350 If the subscription period specified by the Client has expired, then the 1351 Gateway may send an immediate BYE request to the Client's representative 1352 User Agent Server. This ensures that the monitoring session always completes 1353 with a BYE/response exchange, and that the representative User Agent Server 1354 can avoid maintaining state in certain circumstances. 1356 3.5.3.4. Timing of SUBSCRIBE requests 1358 As it relies on the Gateway having a copy of the INVITEd session 1359 description, the SUBSCRIBE message is limited in when it can be issued. The 1360 Gateway must have received the service request to which this monitoring 1361 session is to be associated, which from the Client's perspective happens as 1362 soon as the Gateway has sent a 1xx response back to it. 1364 However, once this has been done, there is no reason why the Client should 1365 not send a monitoring request. It does not have to wait for the final 1366 response from the Gateway, and it can certainly send the SUBSCRIBE request 1367 before sending the ACK for the Service request final response. Beyond this 1368 point, the Client is free to send a SUBSCRIBE request when it decides, 1369 unless the Gateway's final response to the initial service request indicated 1370 a short Expires: time. 1372 However, there are good reasons (see 6.4) why it may be appropriate to start 1373 a monitoring session immediately before the service is confirmed by the PINT 1374 Client sending an ACK. At this point the Gateway will have decided whether 1375 or not it can handle the service request, but will not have passed the 1376 request on to the Executive System. It is therefore in a good position to 1377 ask the Executive System to enable monitoring when it sends the service 1378 request onwards. In practical implementations, it is likely that more 1379 information on transient service status will be available if this is 1380 indicated as being important BEFORE or AS the service execution phase 1381 starts; once execution has begun the level of information that can be 1382 returned may be difficult to change. 1384 Thus, whilst it is free to send a SUBSCRIBE request at any point after 1385 receiving an Interim response from the Gateway to its service request, it is 1386 recommended that the Client should send such a monitoring request 1387 immediately prior to sending an ACK message confirming the service if it is 1388 interested in transient service status messages. 1390 3.5.4. The "Require:" header for PINT 1392 PINT clients use the Require: header to signal to the PINT server that a 1393 certain PINT extension of SIP is required. PINT 1.0 defines two strings that 1394 can go into the Require header: 1396 org.ietf.sip.subscribe -- the server can fulfill SUBSCRIBE requests 1397 (section 3.5.3) 1398 -.-. 1399 org.ietf.sdp.require -- the PINT server (or the SDP parser associated 1400 to it) understands the "require" attribute 1401 defined in (section 3.4.4) 1403 Example: 1404 -.-. 1405 Require:org.ietf.sip.subscribe,org.ietf.sdp.require 1407 A client should only include a Require: header where it truly requires the 1408 server to fail the request if the option is not supported. 1410 3.5.5. PINT URLs within PINT requests 1412 Normally the hostnames and domain names that appear in the PINT URLs are the 1413 internal affair of each individual PINT system. A client uses the 1414 appropriate SDP payload to indicate the particular service it wishes to 1415 invoke; it is not necessary to use a particular URL to identify the service. 1417 A PINT URL is used in two different ways within PINT requests: within the 1418 Request-URI, and within the To: and From: headers. Use within the 1419 Request-URI requires clarification in order to ensure smooth interworking 1420 with the Telephone Network serviced by the PINT infrastructure, and this 1421 is covered next. 1423 3.5.5.1. PINT URLS within Request-URIs 1425 There are some occasions when it may be useful to indicate service 1426 information within the URL in a standardized way: 1427 a. it may not be possible to use SDP information to route the request if 1428 it is encrypted; 1429 b. it allows implementation that make use of I.N. "service indicators"; 1430 c. It enables multiple competing PINT gateways to REGISTER with a single 1431 "broker" server (proxy or redirect) (see section 6.3) 1433 For these reasons, the following conventions for URLs are offered for use 1434 in PINT requests: 1436 1. The user portion of a sip URL indicates the service to be requested. At 1437 present the following services are defined: 1439 R2C (for Request-to-Call) 1440 R2F (for Request-to-Fax) 1441 R2HC (for Request-to-Hear-Content) 1443 The user portions "R2C", "R2F", and "R2HC" are reserved for the PINT 1444 milestone services. Other user portions MUST be used in case the requested 1445 service is not one of the Milestone services. See section 3.5.8 for some 1446 related considerations concerning registrations by competing PINT systems to 1447 a single PINT proxy server acting as a service broker. 1449 2. The host portion of a sip URL contains the domain name of the PINT 1450 service provider. 1452 3. A new url-parameter is defined to be "tsp" (for "telephone service 1453 provider"). This can be used to indicate the actual telephone network 1454 provider to be used to fulfil the PINT request. 1456 Thus, for example:- 1457 INVITE sip:R2C@pint.pintservice.com SIP/2.0 1459 INVITE sip:R2F@pint.pintservice.com;tsp=telco.com SIP/2.0 1461 INVITE sip:R2HC@pint.mycom.com;tsp=pbx23.mycom.com SIP/2.0 1463 INVITE sip:13@pint.telco.com SIP/2.0 1465 3.5.6. Telephony Network Parameters within PINT URLs 1466 Any legal SIP URL can appear as a PINT URL within the Request-URI or To: 1467 header of a PINT request. But if the address is a telephone address, we 1468 indicated in section 3.4.3 that it may be necessary to include more 1469 information in order correctly to identify the remote telephone terminal or 1470 service. PINT clients MAY include these attribute tags within PINT URLs if 1471 they are necessary or a useful complement to the telephone number within the 1472 SIP URL. These attribute tags MUST be included as URL parameters as defined 1473 in [1] (i.e. in the semi-colon separated manner). 1475 The following is an example of a PINT URL containing extra attribute tags: 1476 -.-. 1477 sip:+9725228808@pint.br.com;user=phone;require=Q763-plan;a=Q763-plan:4 1478 As we noted in section 3.4.3, these extra attribute parameters will not 1479 normally be needed within a URL, because there is a great deal of context 1480 available to the help the server interpret the phone number correctly. In 1481 particular, there is the SIP URL within the To: header, and there is also 1482 the Request-URI. In most cases this provides sufficient information for the 1483 telephone network. 1485 The SDP attributes defined in section 3 above will normally only be used 1486 when they are needed to supply necessary context to identify a telephone 1487 terminal. 1489 3.5.7. REGISTER requests within PINT 1491 *-*- 1492 A PINT gateway is a SIP user agent server. A User Agent Server uses the 1493 REGISTER request to tell a proxy or redirect server that it is available to 1494 "receive calls" (i.e. to service requests). Thus a PINT Gateway registers 1495 with a proxy or redirect server the service that is accessible via itself, 1496 whilst in SIP, a user is registering his/her presence at a particular SIP 1497 Server. 1499 There may be competing PINT servers that can offer the same PINT service 1500 trying to register at a single PINT server. The PINT server might act as a 1501 "broker" among the various PINT gateways that can fulfil a request. A 1502 format for PINT URLs was specified in section 3.5.5 that enables independent 1503 PINT systems to REGISTER an offer to provide the same service. The registrar 1504 can apply its own mechanisms and policies to decide how to respond to 1505 INVITEs from clients seeking service (See section 6.3 for some possible 1506 deployment options). There is no change between SIP and PINT REGISTER 1507 semantics or syntax. 1509 Of course, the information in the PINT URLs within the REGISTER request may 1510 not be sufficient to completely define the service that a gateway can offer. 1511 The use of SIP and SDP within PINT REGISTER requests to enable a gateway to 1512 specify in more detail the services it can offer is the subject of future 1513 study. 1515 3.5.8. BYE Requests in PINT 1517 The semantics of BYE requests within PINT requires some extra precision. One 1518 issue concerns conferences that "cannot be left", and the other concerns 1519 keeping call state after the BYE. 1521 The BYE request [1] is normally used to indicate that the originating entity 1522 no longer wishes to be involved in the specified call. The request 1523 terminates the call and the media session. Applying this model to PINT, if a 1524 PINT client makes a request that results in invocation of a telephone call 1525 from A to B, a BYE request from the client, if accepted, should result in a 1526 termination of the phone call. 1528 A question arises when the telephone call might not have even started at the 1529 time when the BYE request is received. For example, if a request to fax is 1530 sent with a t= line indicating that the fax is to be sent tomorrow at 4 AM, 1531 the requestor might wish to cancel the request before the specified time. 1533 Even if the call has yet to start, it may not be possible to terminate the 1534 media session on the telephone system side. For example, the fax call may 1535 be in progress when the BYE arrives, and perhaps it is just not possible to 1536 cancel the fax in session. Another possibility is that the entire 1537 telephone-side service might be completed before the BYE is received. In the 1538 above Request-to-Fax example, the BYE might be sent the following morning, 1539 and the entire fax has been sent before the BYE was received. It is too late 1540 to send the BYE. 1542 In the case where the telephone network cannot terminate the call, the 1543 server MUST return a "606 Not Acceptable" response to the BYE, along with a 1544 session description that indicates the telephone network session that is 1545 causing the problem. 1547 Thus, in PINT, a "Not Acceptable" response can be returned to INVITE or 1548 BYE requests. It indicates that some aspect of the session description makes 1549 the request unacceptable. 1551 By allowing a server to return a "Not Acceptable" response to BYE requests, 1552 we are not changing its semantics, just enlarging its use. 1554 A combination of Warning: headers and i= lines within the session 1555 description can be used to indicate the precise nature of the problem. 1557 Example: 1559 SIP/2.0 606 Not Acceptable 1560 From: ... 1561 To: ....... 1562 ..... 1563 Warning: 399 pint.mycom.com Fax in progress, service cannot be aborted 1564 Content-Type: application/sdp 1565 Content-Length: 50 1567 v=0 1568 i=3 of 5 pages sent OK 1569 c=TN RFC2543 +12014064090 1570 m=image 1 fax tif 1571 a=fmtp:tif uri:http://tifsRus.com/yyyyyy.tif 1573 Note that the server may return an updated session description within a 1574 successful response to a BYE as well. This can be used, for example, to 1575 indicate the actual start times and stop times of the telephone session, or 1576 how many pages were sent in the fax transmission. 1578 The second issue concerns how long must a server keep call state after 1579 receiving a BYE. A question arises because other clients might still wish to 1580 send queries about the telephone network session that was the subject of 1581 the PINT transaction. Ordinary SIP semantics have three important 1582 implications for this situation: 1584 1. A BYE indicates that the requesting client will clear out all call state 1585 as soon as it receives a successful response. A client SHOULD NOT send a 1586 SUBSCRIBE request after it has sent a BYE. 1588 2. A server may return an Expires: header within a successful response to a 1589 BYE request. This indicates for how long the server will retain session 1590 state about the telephone network session. At any point during this time, a 1591 client may send a SUBSCRIBE request to the server to learn about the session 1592 state. 1594 3. When engaged in a SUBSCRIBE/NOTIFY monitoring session, PINT servers that 1595 send BYE to a URL listed in the Contact: header of a client request SHOULD 1596 not clear session state until after the successful response to the BYE is 1597 received. For example, it may be that the requesting client host is turned 1598 off when the telephone service is executed (and is therefore not available 1599 at the location previously specified in the Contact: attribute) to receive 1600 the PINT server's BYE. Of course, it is possible that the BYE request will 1601 simply time out. 1603 4. Examples of PINT Requests and Responses 1605 4.1. A request to a call centre from an anonymous user to receive a phone 1606 call. 1608 C->S: INVITE sip:R2C@pint.mailorder.com SIP/2.0 1609 Via: SIP/2.0/UDP 169.130.12.5 1610 From: sip:anon-1827631872@chinet.net 1611 To: sip:+1-201-456-7890@iron.org;user=phone 1612 Call-ID: 19971205T234505.56.78@chinet.net 1613 Subject: Sale on Ironing Boards 1614 Content-type: application/sdp 1615 Content-Length: ... 1617 v=0 1618 o=- 53655765 2353687637 IN IP4 128.3.4.5 1619 i=Ironing Board Promotion 1620 c= TN RFC2543 +1-201-406-4090 1621 m=audio 1 voice - 1623 -.-. 1624 In this example, the context that is required to interpret the To: address 1625 as a telephone number is not given explicitly; it is implicitly known to the 1626 R2C@pint.mailorder.com server. But the telephone of the person who wishes to 1627 receive the call is explicitly identified as an internationally significant 1628 E.164 number that falls within the North American numbering plan 1629 (because of the "+1" within the c= line). 1631 4.2. A request from a non anonymous customer (John Jones) to receive a phone 1632 call from a particular sales agent (Mary James) concerning the defective 1633 ironing board that was purchased 1634 C->S: INVITE sip:marketing@pint.mailorder.com SIP/2.0 1635 Via: SIP/2.0/UDP 169.130.12.5 1636 From: sip:john.jones.3@chinet.net 1637 To: sip:mary.james@mailorder.com 1638 Call-ID: 19971205T234505.56.79@chinet.net 1639 Subject: Defective Ironing Board - want refund 1640 Content-type: application/sdp 1641 Content-Length: ... 1643 v=0 1644 o=- 53655765 2353687637 IN IP4 128.3.4.5 1645 c= TN RFC2543 +1-201-406-4090 1646 m=audio 1 voice 1648 The To: line might include the Mary James's phone number instead of a 1649 email-like address. An implementation that cannot accept email-like URLs in 1650 the "To:" header must fail the request with a 606 Not Acceptable. 1651 Note that the sending PINT client "knows" that the PINT Gateway contacted 1652 with the "marketing@pint.mailorder.com" Request-URI is capable of processing 1653 the client request as expected. (see 3.5.5.1 for a discussion on this). 1655 Note also that such a telephone call service could be implemented on the 1656 phone side with different details. For example, it might be that first the 1657 agent's phone rings, and then the customer's phone rings, or it might be 1658 that first the customer's phone rings and he hears silly music until the 1659 agent comes on line. If necessary, such service parameter details might be 1660 indicated in "a=" attribute lines within the session description. The 1661 specification of such attribute lines for service consistency is beyond the 1662 scope of the PINT 1.0 specifications. 1664 4.3. A request from the same user to get a fax back on how to assemble the 1665 Ironing Board 1667 C->S: INVITE sip:faxback@pint.mailorder.com SIP/2.0 1668 Via: SIP/2.0/UDP 169.130.12.5 1669 From: sip:john.jones.3@chinet.net 1670 To: sip:1-800-FAXBACK@steam.edu;user=phone;phone-context=+1 1671 Call-ID: 19971205T234505.66.79@chinet.net 1672 Content-type: application/sdp 1673 Content-Length: ... 1675 v=0 1676 o=- 53655768 2353687637 IN IP4 128.3.4.5 1677 c= TN RFC2543 1-201-406-4091 1678 m=application 1 fax URI 1679 a=fmtp:URI uri:http://localstore/Products/IroningBoards/2344.html 1681 In this example, the fax to be sent is stored on some local server 1682 (localstore), whose name may be only resolvable, or that may only be 1683 reachable, from within the IP network on which the PINT server sits. The 1684 phone number to be dialled is a "local phone number" as well. There is no 1685 "phone-context" attribute, so the context (in this case, for which nation 1686 the number is "nationally significant") must be supplied by the 1687 faxback@pint.mailorder.com PINT server. 1689 -.-. 1690 If the server that receives does not understand the number, it should fail 1691 the request with and include a "Network Address Not Understood" warning. 1692 Note that no "require" attribute was used here, since it is very likely 1693 that the request can be serviced even by a server that does not support 1694 the "require" attribute. 1696 4.4. A request from same user to have that same information read out over 1697 the phone 1699 C->S: INVITE sip:faxback@pint.mailorder.com SIP/2.0 1700 Via: SIP/2.0/UDP 169.130.12.5 1701 From: john.jones.3@chinet.net 1702 To: sip:1-800-FAXBACK@steam.edu;user=phone;phone-context=+1 1703 Call-ID: 19971205T234505.66.79@chinet.net 1704 Content-type: application/sdp 1705 Content-Length: ... 1707 v=0 1708 o=- 53655768 2353687637 IN IP4 128.3.4.5 1709 c= TN RFC2543 +1-201-406-4090 1710 m=application 1 voice URI 1711 a=fmtp:URI uri:http://localstore/Products/IroningBoards/2344.html 1713 4.5. A request to send an included text page to a friend's pager. 1715 In this example, the text to be paged out is included in the request. 1717 C->S: INVITE sip:R2F@pint.pager.com SIP/2.0 1718 Via: SIP/2.0/UDP 169.130.12.5 1719 From: scott.petrack@chinet.net 1720 To: sip:R2F@pint.pager.com 1721 Call-ID: 19974505.66.79@chinet.net 1722 Content-Type: multipart/mixed; boundary=--next 1724 ----next 1725 Content-Type: application/sdp 1726 Content-Length: ... 1727 v=0 1728 o=- 53655768 2353687637 IN IP4 128.3.4.5 1729 c= TN RFC2543 +972-9-956-1867 1730 m=text 1 pager plain 1731 a=fmtp:plain spr:2@53655768 1733 ----next 1734 Content-Type: text/plain 1735 Content-ID: 2@53655768 1736 Content-Length:... 1738 Hi Joe! Please call me asap at 555-1234. 1740 ----next-- 1742 4.6. A request to send an image as a fax to phone number +972-9-956-1867 1744 C->S: INVITE sip:faxserver@pint.vocaltec.com SIP/2.0 1745 Via: SIP/2.0/UDP 169.130.12.5 1746 From: scott.petrack@chinet.net 1747 To: sip:faxserver@pint.vocaltec.com 1748 Call-ID: 19971205T234505.66.79@chinet.net 1749 Content-type: application/sdp 1750 Content-Length: ... 1752 v=0 1753 o=- 53655768 2353687637 IN IP4 128.3.4.5 1754 c= TN RFC2543 +972-9-956-1867 1755 m=image 1 fax tif gif 1756 a=fmtp:tif uri:http://petrack/images/tif/picture1.tif 1757 a=fmtp:gif uri:http://petrack/images/gif/picture1.gif 1758 -.-. 1759 The image is available as tif or as gif. The tif is the preferred format. 1760 Note that the http server where the pictures reside is local, and the PINT 1761 server is also local (because it can resolve machine name "petrack") 1763 4.7. A request to read out over the phone two pieces of content in sequence. 1765 First some included text is read out by text-to-speech. Then some text that 1766 is stored at some URI on the internet is read out. 1768 C->S: INVITE sip:R2HC@pint.acme.com SIP/2.0 1769 Via: SIP/2.0/UDP 169.130.12.5 1770 From: scott.petrack@chinet.net 1771 To: sip:R2HC@pint.acme.com 1772 Call-ID: 19974505.66.79@chinet.net 1773 Content-Type: multipart/mixed; boundary=next 1775 --next 1776 Content-Type: application/sdp 1777 Content-Length: ... 1778 v=0 1779 o=- 53655768 2353687637 IN IP4 128.3.4.5 1780 c= TN RFC2543 +1-201-406-4091 1781 m=text 1 voice plain 1782 a=fmtp:plain spr:2@53655768 1783 m=text 1 voice plain 1784 a=fmtp:plain uri:http://www.your.com/texts/stuff.doc 1786 --next 1787 Content-Type: text/plain 1788 Content-ID: 2@53655768 1789 Content-Length: ... 1791 Hello!! I am about to read out to you the document you 1792 requested, "uri:http://www.your.com/texts/stuff.doc". 1793 We hope you like acme.com's new speech synthesis server. 1794 --next-- 1796 *-*- 1797 4.8. Request for the prices for ISDN to be sent to my fax machine 1799 INVITE sip:R2FB@pint.bt.co.uk SIP/2.0 1800 Via: SIP/2.0/UDP 169.130.12.5 1801 To:0345-12347-01;user=phone;phone-context=+44 1802 From: sip:hank.wangford@newts.demon.co.uk 1803 Call-ID: 19981204T201505.56.78@demon.co.uk 1804 Subject: Price List 1805 Content-type: application/sdp 1806 Content-Length: 116 1808 v=0 1809 o=-53655765 2353687637 IN IP4 128.3.4.5 1810 i=ISDN Price List 1811 c=TN RFC2543 +44-1794-8331010 1812 m=text 1 fax - 1814 4.9. Request for a callback 1816 INVITE sip:R2C@pint.bt.co.uk SIP/2.0 1817 Via: SIP/2.0/UDP 169.130.12.5 1818 To:0345-123456;user=phone;phone-context=+44 1819 From: sip:hank.wangford@newts.demon.co.uk 1820 Call-ID: 19981204T234505.56.78@demon.co.uk 1821 Subject: It costs HOW much? 1822 Content-type: application/sdp 1823 Content-Length: 123 1825 v=0 1826 o=- 53655765 2353687637 IN IP4 128.3.4.5 1827 i=ISDN pre-sales query 1828 c= TN RFC2543 +44-1794-8331013 1829 m=audio 1 voice - 1831 4.10.Sending a set of information in response to an enquiry 1833 INVITE sip:R2FB@pint.bt.co.uk SIP/2.0 1834 Via: SIP/2.0/UDP 169.130.12.5 1835 To:0345-12347-01;user=phone;phone-context=+44 1836 From: sip:colin.masterton@sales.hh.bt.co.uk 1837 Call-ID: 19981205T234505.56.78@sales.hh.bt.co.uk 1838 Subject: Price Info, as requested 1839 Content-Type: multipart/mixed; boundary=next 1841 --next 1842 Content-type: application/sdp 1843 Content-Length: 211 1844 v=0 1845 o=-53655765 2353687637 IN IP4 128.3.4.5 1846 i=Your documents 1847 c=TN RFC2543 +44-1794-8331010 1848 m=application 1 fax octet-stream 1849 a=fmtp:octet-stream uri:http://www.bt.co.uk/imgs/pipr.gif opr: 1850 spr:2@53655768 1852 --next 1853 Content-Type: text/plain 1854 Content-ID: 2@53655768 1855 Content-Length: 352 1857 Dear Sir, 1858 Thank you for your enquiry. I have checked availability in your 1859 area, and we can provide service to your cottage. I enclose a quote 1860 for the costs of installation, together with the ongoing rental 1861 costs for the line. If you want to proceed with this, please quote 1862 job reference isdn/hh/123.45.9901. 1863 Yours Sincerely, 1864 Colin Masterton 1865 --next-- 1867 Note that the "implicit" faxback content is given by an EMPTY opaque 1868 reference in the middle of the fmtp line in this example. 1870 4.11.Sportsline "headlines" message sent to your phone/pager/fax 1871 (i) phone 1873 INVITE sip:R2FB@pint.wwos.skynet.com SIP/2.0 1874 Via: SIP/2.0/UDP 169.130.12.5 1875 To:1-900-123-456-7;user=phone;phone-context=+1 1876 From: sip:fred.football.fan@skynet.com 1877 Call-ID: 19971205T234505.56.78@chinet.net 1878 Subject: Wonderful World Of Sports NFL Final Scores 1879 Content-type: application/sdp 1880 Content-Length: 174 1882 v=0 1883 o=- 53655765 2353687637 IN IP4 128.3.4.5 1884 i=NFL Final Scores 1885 c= TN RFC2543 +44-1794-8331013 1886 m=audio 1 voice x-pay 1887 a=fmtp:x-pay opr:mci.com/md5: 1889 (ii) fax 1890 INVITE sip:R2FB@pint.wwos.skynet.com SIP/2.0 1891 Via: SIP/2.0/UDP 169.130.12.5 1892 To:1-900-123-456-7;user=phone;phone-context=+1 1893 From: sip:fred.football.fan@skynet.com 1894 Call-ID: 19971205T234505.56.78@chinet.net 1895 Subject: Wonderful World Of Sports NFL Final Scores 1896 Content-type: application/sdp 1897 Content-Length: 173 1899 v=0 1900 o=- 53655765 2353687637 IN IP4 128.3.4.5 1901 i=NFL Final Scores 1902 c= TN RFC2543 +44-1794-8331010 1903 m=text 1 fax x-pay 1904 a=fmtp:x-pay opr:mci.com/md5: 1906 (iii) pager 1907 INVITE sip:R2FB@pint.wwos.skynet.com SIP/2.0 1908 Via: SIP/2.0/UDP 169.130.12.5 1909 To:1-900-123-456-7;user=phone;phone-context=+1 1910 From: sip:fred.football.fan@skynet.com 1911 Call-ID: 19971205T234505.56.78@chinet.net 1912 Subject: Wonderful World Of Sports NFL Final Scores 1913 Content-type: application/sdp 1914 Content-Length: 173 1916 v=0 1917 o=- 53655765 2353687637 IN IP4 128.3.4.5 1918 i=NFL Final Scores 1919 c= TN RFC2543 +44-1794-8331015 1920 m=text 1 pager x-pay 1921 a=fmtp:x-pay opr:mci.com/md5: 1923 Note that these are all VERY similar. 1925 4.12.Automatically giving someone a fax copy of your phone bill 1927 INVITE sip:BillsRUs@pint.sprint.com SIP/2.0 1928 Via: SIP/2.0/UDP 169.130.12.5 1929 To:+1-555-888-1234;user=phone 1930 From: sip:agent.mulder@fbi.gov 1931 Call-ID: 19991231T234505.56.78@fbi.gov 1932 Subject: Itemised Bill for January 98 1933 Content-type: application/sdp 1934 Content-Length: 117 1936 v=0 1937 o=-53655765 2353687637 IN IP4 128.3.4.5 1938 i=Joe Pendleton's Phone Bill 1939 c=TN RFC2543 +1-202-833-1010 1940 m=text 1 fax x-files-id 1941 a=fmtp:x-files-id opr:fbi.gov/jdcn-123@45:3des;base64, 1943 Note: in this case the opaque reference is data used to convince the 1944 Executive System that the requester has the right to get this information, 1945 rather than selecting the particular content (the A party in the To: field 1946 of the SIP "wrapper" does that alone). 1948 5. Security Considerations 1949 5.1. Basic Principles for PINT Use 1950 A PINT Gateway, and the Executive System(s) with which that Gateway is 1951 associated, exist to provide service to PINT Requestors. The aim of the PINT 1952 protocol is to pass requests from those users on to a PINT Gateway so an 1953 associated Executive System can service those requests. 1955 5.1.1. Responsibility for service requests 1956 The facility of making a PSTN-based call to numbers specified in the PINT 1957 request, however, comes with some risks. The request can specify an incorrect 1958 telephone of fax number. It is also possible that the Requestor has purposely 1959 entered the telephone number of an innocent third party. Finally, the request 1960 may have been intercepted on its way through any intervening PINT or SIP 1961 infrastructure, and the request may have been altered. 1963 In any of these cases, the result may be that a call is placed incorrectly. 1964 Where there is intent or negligence, this may be construed as harrasment of 1965 the person incorrectly receiving the call. Whilst the regulatory framework for 1966 misuse of Internet connections differs throughout the world and is not always 1967 mature, the rules under which PSTN calls are made are much more settled. 1968 Someone may be liable for mistaken or incorrect calls. 1970 Understandably, the PSTN Operators would prefer that this someone is not them, 1971 so they will need to ensure that any PINT Gateway and Executive System 1972 combination does not generate incorrect calls through some error in the 1973 Gateway or Executive system implementation or PSTN-internal communications 1974 fault. Equally, it is important that the Operator can show that they act only 1975 on requests that they have good reason to believe are correct. This means that 1976 the Gateway must not pass on requests unless it is sure that they have not 1977 been corrupted in transit from the Requestor. 1979 If a request can be shown to have come from a particular Requestor and to have 1980 been acted on in good faith by the PINT service provider, then responsibility 1981 for making requests may well fall to the Requestor rather than the Operator 1982 who executed these requests. 1984 Finally, it may be important for the PINT service provider to be able to show 1985 that they act only on requests for which they have some degree of assurance of 1986 origin. In many jurisdictions, it is a requirement on PSTN Operators that they 1987 place calls only when they can, if required, identify the parties to the call 1988 (such as when required to carry out a Malicious Call Trace). It is at least 1989 likely that the provider of PINT services will have a similar responsibility 1990 placed on them. 1991 -.-. 1992 It follows that the PINT service provider may require that the identity of the 1993 Requestor be confirmed. If such confirmation is not available, then they may 1994 be forced (or choose) not to provide service. This identification will require 1995 personal authentication of the Requesting User. 1997 5.1.2. Authority to make requests 1998 Where PSTN resources are used to provide a PINT service, it is at least 1999 possible that someone will have to pay for it. This person may not be the 2000 Requestor, as, for example, in the case of existing PSTN split-charging 2001 services like free phone in which the recipient of a call rather than the 2002 originator is responsible for the call cost. 2004 This is not, of course, the only possibility; for example, PINT service may be 2005 provided on a subscription basis, and there are a number of other models. 2006 However, whichever model is chosen, there may be a requirement that the 2007 authority of a Requestor to make a PINT request is confirmed. 2009 If such confirmation is not available, then, again, the PINT Gateway and 2010 associated Executive System may choose not to provide service. 2012 5.1.3. Privacy 2013 Even if the identity of the Requesting User and the Authority under which they 2014 make their request is known, there remains the possibility that the request is 2015 either corrupted, maliciously altered, or even replaced whilst in transit 2016 between the Requestor and the PINT Gateway. 2018 Similarly, information on the Authority under which a request is made may well 2019 be carried within that request. This can be sensitive information, as an 2020 eavesdropper might steal this and use it within their own requests. Such 2021 authority should be treated as if it were financial information (such as a 2022 credit card number or PIN). 2024 The data authorizing a Requesting User to make a PINT request should be known 2025 only to them and the service provider. However, this information may be in a 2026 form that does not match the schemes normally used within the Internet. For 2027 example, X.509 certificates[14] are commonly used for secured transactions on 2028 the Internet both in the IP Security Architecture[12] and in the TLS 2029 protocol[13], but the PSTN provider may only store an account code and PIN 2030 (i.e. a fixed string of numbers). 2032 -.-. 2033 A Requesting User has a reasonable expectation that their requests for service 2034 are confidential. For some PINT services, no content data is carried over the 2035 Internet; however, the telephone or fax numbers of the parties to a resulting 2036 service calls may be considered sensitive. As a result, it is likely that the 2037 Requestor (and their PINT service provider) will require that any request that 2038 is sent across the Internet be protected against eavesdroppers; in short, the 2039 requests should to be encrypted. 2041 -.-. 2042 5.1.4. Privacy Implications of SUBSCRIBE/NOTIFY 2043 Some special considerations relate to monitoring sessions using the SUBSCRIBE 2044 and NOTIFY messages. The SUBSCRIBE message that is used to register an 2045 interest in the disposition of a PINT service transaction uses the original 2046 Session Description carried in the related INVITE message. This current 2047 specification does not restrict the source of such a SUBSCRIBE message, so it 2048 is possible for an eavesdropper to capture an unprotected sesssion description 2049 and use this in a subsequent SUBSCRIBE request. In this way it is possible to 2050 find out details on that transaction that may well be considered sensitive. 2052 The initial solution to this risk is to recommend that a session description 2053 that may be used within a subsequent SUBSCRIBE message SHOULD be protected. 2055 However, there is a further risk; if the origin-field used is "guessable" then 2056 it might be possible for an attacker to reconstruct the session description 2057 and use this reconstruction within a SUBSCRIBE message. 2059 SDP (see section 6 of [2], "o=" field) does not specify the mechansim used to 2060 generate the sess-id field, and suggests that a method based on timestamps 2061 produced by Network Time Protocol [16] can be used. This is sufficient to 2062 guarantee uniqueness, but may allow the value to be guessed, particularly if 2063 other unprotected requests from the same originator are available. 2065 Thus, to ensure that the session identifier is not guessable the techniques 2066 described in section 6.3 of [17] can be used when generating the origin-field 2067 for a session description to be used inside a PINT INVITE message. If all 2068 requests from (and responses to) a particular PINT requesting entity are 2069 protected, then this is not needed. Where such a situation is not assured, AND 2070 where session monitoring is supported, then a method by which an origin-field 2071 within a session description is not guessable SHOULD be used. 2073 5.2. Registration Procedures 2075 Any number of PINT Gateways may register to provide the same service; this is 2076 indicated by the Gateways specifying the same "userinfo" part in the To: 2077 header field of the REGISTER request. Whilst such ambiguity would be unlikely 2078 to occur with the scenarios covered by "core" SIP, it is very likely for PINT; 2079 there could be any number of service providers all willing to support a 2080 "Request-To-Fax" service, for example. Unless a request specifies the Gateway 2081 name explicitly, an intervening Proxy that acts on a registration database to 2082 which several Gateways have all registered is in a position to select from the 2083 registrands using whatever algorithm it chooses; in principle, any Gateway 2084 that has registered as "R2F" would be appropriate. 2086 However, this opens up an avenue for attack, and this is one in which a 2087 "rogue" Gateway operator stands to make a significant gain. The standard SIP 2088 procedure for releasing a registration is to send a REGISTER request with a 2089 Contact field having a wildcard value and an expires parameter with a value of 2090 0. It is important that a PINT Registrar uses authentication of the 2091 Registrand, as otherwise one PINT service provider would be able to "spoof" 2092 another and remove their registration. As this would stop the Proxy passing 2093 any requests to that provider, this would both increase requests being sent to 2094 the rogue and stop requests going to the victim. 2096 Another variant on this attack would be to register a Gateway using a name 2097 that has been registered by another provider; thus a rogue Operator might 2098 register its Gateway as "R2C@pint.att.com", thereby hijacking requests. 2100 -.-. 2101 The solution is the same; all registrations by PINT Gateways MUST be 2102 authenticated; this includes both new or apparent replacement registrations, 2103 and any cancellation of current registrations. This recommendation is also 2104 made in the SIP specification, but for the correct operation of PINT, it is 2105 very important indeed. 2107 5.3. Security mechanisms and implications on PINT service 2109 PINT is a set of extensions to SIP[1] and SDP[2], and will use the security 2110 procedures described in SIP. There are several implications of this, and these 2111 are covered here. 2113 For several of the PINT services, the To: header field of SIP is used to 2114 identify one of the parties to the resulting service call. The PINT 2115 Request-To-Call service is an example. As mentioned in the SIP specification, 2116 this field is used to route SIP messages through an infrastructure of Redirect 2117 and Proxy server between the corresponding User Agent Servers, and so cannot 2118 be encrypted. This means that, although the majority of personal or sensitive 2119 data can be protected whilst in transit, the telephone (or fax) number of one 2120 of the parties to a PINT service call cannot, and will be "visible" to any 2121 interception. For the PINT milestone services this may be acceptable, since 2122 the caller named in the To: service is typically a "well known" provider 2123 address, such as a Call Centre. 2125 Another aspect of this is that, even if the Requesting User does not consider 2126 the telephone or fax numbers of the parties to a PINT service to be private, 2127 those parties might. Where PINT servers have reason to believe this might be 2128 the case they SHOULD encrypt the request, even if the Requestor has not done 2129 so. This could happen, for example, if a Requesting User within a company 2130 placed a PINT request and this was carried via the company's Intranet to their 2131 Proxy/firewall and thence over the Internet to a PINT Gateway at another 2132 location. 2133 -.-. 2134 If a request carries data that can be reused by an eavesdropper either to 2135 "spoof" the Requestor or to obtain PINT service by inserting the Requestor's 2136 authorization token into an eavesdropper's request, then this data MUST be 2137 protected. This is particularly important if the authorization token consists 2138 of static text (such as an account code and/or PIN). 2139 -.-. 2140 One approach is to encrypt the whole of the request, using the methods 2141 described in the SIP specification. As an alternative, it may be acceptable 2142 for the authorization token to be held as an opaque reference (see section 2143 3.4.2.3 and examples 4.11 and 4.12), using some proprietary scheme agreed 2144 between the Requestor and the PINT service provider, as long as this is 2145 resistant to interception and re-use. Also, it may be that the authorization 2146 token cannot be used outside of a request cryptographically signed by the 2147 Requestor; if so then this requirement can be relaxed, as in this case the 2148 token cannot be re-used by another. However, unless both the Requestor and the 2149 Gateway are assured that this is the case, any authorization token MUST be 2150 treated as sensitive, and so MUST be encrypted. 2152 A PINT request may contain data within the SDP message body that can be used 2153 more efficiently to route that request. For example, it may be that one 2154 Gateway and Executive System combination cannot handle a request that 2155 specifies one of the parties as a pager, whilst another can. Both gateways may 2156 have registered with a PINT/SIP Registrar, and this information may be 2157 available to intervening PINT/SIP Proxies. However, if the message body is 2158 encrypted, then the request cannot be decoded at the Proxy server, and so 2159 Gateway selection based on contained information cannot be made there. 2161 The result is that the Proxy may deliver the request to a Gateway that cannot 2162 handle it; the implication is that a PINT/SIP Proxy SHOULD consider its choice 2163 for the appropriate Gateway subject to correction, and, on receiving a 501 or 2164 415 rejection from the first gateway chosen, try another. In this way, the 2165 request will succeed if at all possible, even though it may be delayed (and 2166 tie up resources in the inappropriate Gateways). 2168 This opens up an interesting avenue for Denial Of Service; sending a valid 2169 request that appears to be suitable for a number of different Gateways, and 2170 simply occupying those Gateways in decrypting a message requesting a service 2171 they cannot provide. As mentioned in section 3.5.5.1, the choice of service 2172 name to be passed in the userinfo portion of the SIP Request-URI is flexible, 2173 and it is RECOMMENDED that names be chosen that allow a Proxy to select an 2174 appropriate Gateway without having to examine the SDP body part. Thus, in the 2175 example given here, the service might be called "Request-To-Page" or "R2P" 2176 rather than the more general use of "R2F", if there is a possibility of the 2177 SDP body part being protected during transit. 2179 A variation on this attack is to provide a request that is syntactically 2180 invalid but that, due to the encryption, cannot be detected without expending 2181 resources in decoding it. The effects of this form of attack can be minimised 2182 in the same way as for any SIP Invitation; the Proxy should detect the 400 2183 rejection returned from the initial Gateway, and not pass the request onwards 2184 to another. 2186 Finally, note that the Requesting User may not have a prior relationship with 2187 a PINT Gateway, whilst still having a prior relationship with the Operator of 2188 the Executive System that fulfils their request. Thus there may be two levels 2189 of authentication and authorization; one carried out using the techniques 2190 described in the SIP specification (for use between the Requestor and the 2191 Gateway), with another being used between the Requesting User or the Requestor 2192 and the Executive System. 2194 For example, the Requesting User may have an account with the PINT service 2195 provider. That provider might require that requests include this identity 2196 before they will be convinced to provide service. In addition, to counter 2197 attacks on the request whilst it is in transit across the Internet, the 2198 Gateway may require a separate X.509-based certification of the request. These 2199 are two separate procedures, and data needed for the former would normally be 2200 expected to be held in opaque references inside the SDP body part of the 2201 request. 2203 The detailed operation of this mechanism is, by definition, outside the scope 2204 of an Internet Protocol, and so must be considered a private matter. However, 2205 one approach to indicating to the Requestor that such "second level" 2206 authentication or authorization is required by their Service Provider would be 2207 to ask for this inside the textual description carried with a 401 response 2208 returned from the PINT Gateway. 2210 -..- 2211 5.4. Summary of Security Implications 2212 >From the above discussion, PINT always carries data items that are sensitive, 2213 and there may be financial considerations as well as the more normal privacy 2214 concerns. As a result, the transactions MUST be protected from interception, 2215 modification and replay in transit. 2217 PINT is based on SIP and SDP, and can use the security procedures outlined in 2218 [1] (sections 13 and 15). However, in the case of PINT, the SIP recommendation 2219 that requests and responses MAY be protected is not enough. PINT messages MUST 2220 be protected, so PINT Implementations MUST support SIP Security (as described 2221 in [1], sections 13 & 15), and be capable of handling such received messages. 2223 In some configurations, PINT Clients, Servers, and Gateways can be sure that 2224 they operate using the services of network level security [13], transport 2225 layer security [12], or physical security for all 2226 communications between them. In these cases messages MAY be exchanged 2227 without SIP security, since all traffic is protected already. Clients 2228 and servers SHOULD support manual configuration to use such lower 2229 layer security facilities. 2231 When using network layer security [13], the Security Policy Database 2232 MUST be configured to provide appropriate protection to PINT traffic. 2233 When using TLS, a port configured MUST NOT also 2234 be configured for non-TLS traffic. When TLS is used, basic authentication 2235 MUST be supported, and client-side certificates MAY be supported. 2237 Authentication of the Client making the request is required, however, so 2238 if this is not provided by the underlying mechanism used, then it MUST be 2239 included within the PINT messages using SIP authentication techniques. In 2240 contrast with SIP, PINT requests are often sent to parties with which a 2241 prior communications relationship exists (such as a Telephone Carrier). In 2242 this case, there may be a shared secret between the client and the PINT 2243 Gateway. Such PINT systems MAY use authentication based on shared secrets, 2244 with HTTP "basic authentication". When this is done, the message integrity 2245 and privacy must be guaranteed by some lower layer mechanism. 2247 There are implications on the operation of PINT here though. If a PINT proxy 2248 or redirect server is used, then it must be able to examine the contents of 2249 the IP datagrams carried. It follows that an end-to-end approach using 2250 network-layer security between the PINT Client and a PINT Gateway precludes 2251 the use of an intervening proxy; communication between the Client and Gateway 2252 is carried via a tunnel to which any intervening entity cannot gain access, 2253 even if the IP datagrams are carried via this node. Conversely, if a 2254 "hop-by-hop" approach is used, then any intervening PINT proxies (or redirect 2255 servers) are, by implication, trusted entities. 2257 However, if there is any doubt that there is an underlying network or 2258 transport layer security association in place, then the players in a PINT 2259 protocol exchange MUST use encryption and authentication techniques within the 2260 protocol itself. The techniques described in section 15 of RFC2543 MUST be 2261 used, unless there is an alternative protection scheme that is agreed between 2262 the parties. In either case, the content of any message body (or bodies) 2263 carried within a PINT request or response MUST be protected; this has 2264 implications on the options for routing requests via Proxies (see 5.3). 2266 Using SIP techniques for protection, the Request-URI and To: fields headers 2267 within PINT requests cannot be protected. In the baseline PINT services these 2268 fields may contain sensitive information. This is a consideration, and if 2269 these data ARE considered sensitive, then this will preclude the sole use of 2270 SIP techniques; in such a situation, transport [12] or network layer [13] 2271 protection mechanisms MUST be used. 2273 As a final point, this choice will in turn have an influence on the choice of 2274 transport layer protocol that can be used; if a TLS association is available 2275 between two nodes, then TCP will have to be used. This is different from 2276 the default behaviour of SIP (try UDP, then try TCP if that fails). 2278 6. Deployment considerations and the Relationship PINT to I.N. (Informative) 2280 6.1. Web Front End to PINT Infrastructure 2282 It is possible that some other protocol may be used to communicate a 2283 Requesting User's requirements. Due to the high numbers of available Web 2284 Browsers and servers it seems likely that some PINT systems will use 2285 HTML/HTTP as a "front end". In this scenario, HTTP will be used over a 2286 connection from the Requesting User's Web Browser (WC) to an Intermediate 2287 Web Server (WS). This will be closely associated with a PINT Client (using 2288 some unspecified mechanism to transfer the data from the Web Server to the 2289 PINT Client). The PINT Client will represent the Requesting User to the PINT 2290 Gateway, and thus to the Executive System that carries out the required 2291 action. 2293 [WC]------[WS] 2294 [PC] 2295 \ 2296 \ 2297 [PG] 2298 [XS] 2299 Figure 2: Basic "Web-fronted" Configuration 2301 6.2. Redirects to Multiple Gateways 2303 It is quite possible that a given PINT Gateway is associated with an 2304 Executive System (or systems) that can connect to the GSTN at different 2305 places. Equally, if there is a chain of PINT Servers, then each of these 2306 intermediate or proxy servers (PP) may be able to route PINT requests to 2307 Executive Systems that connect at specific points to the GSTN. The result of 2308 this is that there may be more than one PINT Gateway or Executive System that 2309 can deal with a given request. The mechanisms by which the choice on where 2310 to deliver a request are outside the scope of this document. 2312 [WC]------[WS] [WC]------[WS] 2313 [PC] [PC] 2314 \ \ 2315 \ \ 2316 [PG] [PP] 2317 .........[XS]......... / \ 2318 : : / \ 2319 [PG] [PG] 2320 [XS] [XS] 2321 Figure 3: Multiple Access Configurations 2323 However, there do seem to be two approaches. Either a Server that acts as a 2324 proxy or redirect will select the appropriate Gateway itself and will cause 2325 the request to be sent on accordingly, or a list of possible Locations will 2326 be returned to the Requesting User from which they can select their choice. 2328 In SIP, the implication is that, if a proxy cannot resolve to a single 2329 unique match for a request destination, then a response containing a list of 2330 the choices should be returned to the Requesting User for selection. This is 2331 not too likely a scenario within the normal use of SIP. 2333 However, within PINT, such ambiguity may be quite common; it implies that 2334 there are a number of possible providers of a given service. 2336 6.3. Competing PINT Gateways REGISTERing to offer the same service 2338 With PINT, the registration is not for an individual but instead for a 2339 service that can be handled by a service provider. Thus, one can envisage a 2340 registration by the PINT Server of the domain telcoA.com of its ability to 2341 support the service R2C as "R2C@telcoA.com", sent to an intermediary server 2342 that acts as registrar for the "broker.telcos.com" domain from 2343 "R2C@pint.telcoA.com" as follows: 2345 REGISTER sip:registrar@broker.telcos.com SIP/2.0 2346 To:sip:R2C@pint.telcoA.com 2347 From:R2C@pint.telcoA.com 2348 ... 2350 This is the standard SIP registration service. 2352 However, what happens if there are a number of different Service Providers, 2353 all of whom support the "R2C" service? Suppose there is a PINT system at 2354 domain "broker.com". PINT clients requesting a Request-to-Call service from 2355 broker.com might be very willing to be redirected or proxied to any one of 2356 the various service providers that had previously registered with the 2357 registrar. PINT servers might also be interested in providing service for 2358 requests that did not specify the service provider explicitly, as well as 2359 those requests that were directed "at them". 2361 To enable such service, PINT servers would REGISTER at the broker PINT 2362 server registrations of the form: 2364 REGISTER sip:registrar@broker.com SIP/2.0 2365 To:sip:R2C@broker.com 2366 From:sip:R2C@pint.telcoA.com 2368 When several such REGISTER messages appear at the registrar, each differing 2369 only in the URL in the From: line, the registrar has many possibilities, 2370 e.g.: 2372 (i) it overwrites the prior registration for "R2C@broker.telcos.com" 2373 when the next comes in; 2374 (ii) it rejects the subsequent registration for "R2C@broker.telcos.com"; 2375 (iii) it maintains all such registrations. 2377 In this last case, on receiving an Invitation for the "general" service, 2378 either: 2379 (iii.1) it passes on the invitation to all registered service 2380 providers, returning a collated response with all 2381 acceptances, using multiple Location: headers, 2382 or 2383 (iii.2) it silently selects one of the registrations (using, for 2384 example, a "round robin" approach) and routes the Invitation 2385 and response onwards without further comment. 2387 As an alternative to all of the above approaches, it: 2388 (iv) may choose to not allow registrations for the "general" service, 2389 rejecting all such REGISTER requests. 2391 The algorithm by which such a choice is made will be 2392 implementation-dependent, and is outside the scope of PINT. Where a 2393 behaviour is to be defined by requesting users, then some sort of call 2394 processing language might be used to allow those clients, as a pre-service 2395 operation, to download the behaviour they expect to the server making such 2396 decisions. This, however, is a topic for other protocols, not for PINT. 2398 *-*- 2399 6.4. Limitations on Available Information and Request Timing for SUBSCRIBE 2401 A reference configuration for PINT is that service requests are sent, via a 2402 PINT Gateway, to an Executive System that fulfils the Service Control 2403 Function (SCF) of an Intelligent Network (see [11]). The success or failure 2404 of the resulting service call may be information available to the SCF and so 2405 may potentially be made available to the PINT Gateway. In terms of 2406 historical record of whether or not a service succeeded, a large SCF may be 2407 dealing with a million call attempts per hour. Given that volume of service 2408 transactions, there are finite limits beyond which it cannot store service 2409 disposition records; expecting to find out if a Fax was sent last month from 2410 a busy SCF is unrealistic. 2412 Other status changes, such as that on completion of a successful service 2413 call, require the SCF to arrange monitoring of the service call in a way 2414 that the service may not do normally, for performance reasons. In most 2415 implementations, it is difficult efficiently to interrupt a service to 2416 change it once it has begun execution, so it may be necessary to have two 2417 different services; one that sets GSTN resources to monitor service call 2418 termination, and one that doesn't. It is unlikely to be possible to decide 2419 that monitoring is required once the service has started. 2421 These factors can have implications both on the information that is 2422 potentially available at the PINT Gateway, and when a request to register 2423 interest in the status of a PINT service can succeed. The alternative to 2424 using a general SCF is to provide a dedicated Service Node just for PINT 2425 services. As this node is involved in placing all service calls, it is in a 2426 position to collect the information needed. However, it may well still not 2427 be able to respond successfully to a registration of interest in call state 2428 changes once a service logic program instance is running. 2430 Thus, although a Requesting User may register an interest in the status of a 2431 service request, the PINT Gateway may not be in a position to comply with 2432 that request. Although this does not affect the protocol used between the 2433 Requestor and the PINT Gateway, it may influence the response returned. 2434 To avoid the problem of changing service logic once running, any 2435 registration of interest in status changes should be made at or before the 2436 time at which the service request is made. 2438 Conversely, if a historical request is made on the disposition of a service, 2439 this should be done within a short time after the service has completed; the 2440 Executive System is unlikely to store the results of service requests for 2441 long; these will have been processed as AMA (Automatic Message Accounting) 2442 records quickly, after which the Executive System has no reason to keep 2443 them, and so they may be discarded. 2445 Where the PINT Gateway and the Executive System are intimately linked, the 2446 Gateway can respond to status subscription requests that occur while a 2447 service is running. It may accept these requests and simply not even try to 2448 query the Executive System until it has information that a service has 2449 completed, merely returning the final status. Thus the PINT Requestor may be 2450 in what it believes is a monitoring state, whilst the PINT Gateway has not 2451 even informed the Executive System that a request has been made. This will 2452 increase the internal complexity of the PINT Gateway in that it will have a 2453 complex set of interlocking state machines, but does mean that status 2454 registration and indication CAN be provided in conjunction with an I.N. 2455 system. 2457 6.5. Parameters needed for invoking traditional PSTN Services within PINT 2459 This section describes how parameters needed to specify certain traditional 2460 PSTN services can be carried within PINT requests. 2462 6.5.1. Service Identifier 2464 When a Requesting User asks for a service to be performed, he or she will, 2465 of course, have to specify in some way which service. This can be done 2466 in the URLs within the To: header and the Request-URI (see section 3.5.5.1). 2468 6.5.2. A and B parties 2470 With the Request-to-Talk service, they will also need to specify the A and B 2471 parties they want to be engaged in the resulting service call. The A party 2472 could identify, for example, the Call Centre from which they want a call 2473 back, whilst the B party is their telephone number (i.e. who the Call Centre 2474 agent is to call). 2476 The Request-to-Fax and Request-to-Hear-Content services require the B party 2477 to be specified (respectively the telephone number of the destination Fax 2478 machine or the telephone to which spoken content is to be delivered), but 2479 the A party is a Telephone Network based resource (either a Fax or speech 2480 transcoder/sender), and is implicit; the Requesting User does not (and 2481 cannot) specify it. 2483 With the "Fax-Back" variant of the Request-to-Fax service, (i.e. where the 2484 content to be delivered resides on the GSTN) they will also have specify two 2485 parties. As before, the B party is the telephone number of the fax machine 2486 to which they want a fax to be sent. However, within this variant the A 2487 party identifies the "document context" for the PSTN-based document store 2488 from which a particular document is to be retrieved; the analogy here is to 2489 a PSTN user dialling a particular telephone number and then entering the 2490 document number to be returned using "touch tone" digits. The telephone 2491 number they dial is that of the document store or A party, with the "touch 2492 tone" digits selecting the document within that store. 2494 6.5.3. Other Service Parameters 2496 In terms of the extra parameters to the request, the services again differ. 2497 The Request-to-Talk service needs only the A and B parties. Also it is 2498 convenient to assert that the resulting service call will carry voice, as 2499 the Executive System within the destination GSTN may be able to check that 2500 assertion against the A and B party numbers specified and may treat the call 2501 differently. 2503 With the Request-to-Fax and Request-to-Hear-Content services, the source 2504 information to be transcoded is held on the Internet. That means either that 2505 this information is carried along with the request itself, or that a 2506 reference to the source of this information is given. In addition, it is 2507 convenient to assert that the service call will carry fax or voice, and, 2508 where possible, to specify the format for the source information. 2510 The PSTN-based content or "Fax-Back" variant of the Request-to-Fax service 2511 needs to specify the Document Store number and the Fax machine number to 2512 which the information is to be delivered. It is convenient to assert that 2513 the call will carry Fax data, as the destination Executive System may be 2514 able to check that assertion against the document store number and that of 2515 the destination Fax machine. 2517 In addition, the document number may also need to be sent. This parameter is 2518 an opaque reference that is carried through the Internet but has 2519 significance only within the GSTN. The document store number and document 2520 number together uniquely specify the actual content to be faxed. 2522 6.5.4. Service Parameter Summary 2524 The following table summarises the information needed in order to specify 2525 fully the intent of a PSTN service request. Note that it excludes any other 2526 parameters (such as authentication or authorisation tokens, or Expires: or 2527 CallId: headers) that may be used in a request. 2529 Service ServiceID AParty BParty CallFmt Source SourceFmt 2530 ------- --------- ------ ------ ------- ------ ------- 2531 R2C x x x voice - - 2532 R2F x - x fax URI/IL ISF/ILSF 2533 R2FB x x x fax OR - 2534 R2HC x - x voice URI/IL ISF/ILSF 2536 In this table, "x" means that the parameter is required, whilst "-" means 2537 that the parameter is not required. 2539 The Services listed are Request to Talk (R2C), Request to Fax (R2F), the 2540 PSTN-based content or "Fax-back" Variant of Request-to-Fax (R2FB), and 2541 Request-to-Hear-Content (R2HC). 2543 The Call Format parameter values "voice" or "fax" indicate the kind of 2544 service call that results. 2546 The Source Indicator "URI/IL" implies either that the data is either an 2547 Internet source reference (a Universal Resource Identifier, or URI) or is 2548 carried "in-line" with the message. The Source indicator "OR" means that 2549 the value passed is an Opaque Reference that should be carried along 2550 with the rest of the message but is to be interpreted only within the 2551 destination (GSTN) context. As an alternative, it could be given as a 2552 "local" reference with the "file" style, or even using a partial reference 2553 with the "http" style. However, the way in which such a reference is 2554 interpreted is a matter for the receiving PINT Server and Executive System; 2555 it remains, in effect, an opaque reference. 2557 The Source Format value "ISF/ILSF" means that the format of the source is 2558 specified either in terms of the URI or that it is carried "in-line". Note 2559 that, for some data, the format either can be detected by inspection or, if 2560 all else fails, can be assumed from the URI (for example, by assuming that 2561 the file extension part of a URL indicates the data type). For an opaque 2562 reference, the Source Format is not available on the Internet, and so is not 2563 given. 2565 6.6. Parameter Mapping to PINT Extensions 2567 This section describes the way in which the parameters needed to specify a 2568 PSTN service request fully might be carried within a "PINT extended" message. 2569 There are other choices, and these are not precluded. However, in order to 2570 ensure that the Requesting User receives the service that they expect, it is 2571 necessary to have some shared understanding of the parameters passed and the 2572 behaviour expected of the PINT Server and its attendant Executive System. 2574 The Service Identifier can be sent as the userinfo element of the 2575 Request-URI. Thus, the first line of a PINT Invitation would be of the form: 2577 INVITE @. SIP/2.0 2579 The A Party for the Request-to-Talk and "Fax-back" variant of Request-to-Fax 2580 service can be held in the "To:" header field. In this case the "To:" header 2581 value will be different from the Request-URI. In the services where the A 2582 party is not specified, the "To:" field is free to repeat the value held in 2583 the Request-URI. This is the case for Request-to-Fax and 2584 Request-to-Hear-Content services. 2586 The B party is needed in all these milestone services, and can be held in 2587 the enclosed SDP sub-part, as the value of the "c=" field. 2589 The call format parameter can be held as part of the "m=" field value. It 2590 maps to the "transport protocol" element as described in section 3.4.2 of 2591 this document. 2593 The source format specifier is held in the "m=", as a type and optional 2594 sub-type. The latter is normally required for all services except 2595 Request-to-Talk. As shown earlier, the source format and source are not 2596 always required when generating requests for services. However, the inclusion 2597 in all requests of a source format specifier can make parsing the request 2598 simpler and allows for other services to be specified in the future, and so 2599 values are always given. The source format parameter is covered in section 2600 3.4.2 as the "media type" element. 2602 The source itself is identified by an "a=fmtp:" field value, where needed. 2603 With the exception of the Request-to-Talk service, all invitations will 2604 normally include such a field. From the perspective of the SDP extensions, 2605 it can be considered as qualifying the media sub-type, as if to say, 2606 for example, "when I say jpeg, what I mean is the following". 2608 In summary, the parameters needed by the different services are carried in 2609 fields as shown in the following table: 2611 Service Svc Param PINT/SIP or SDP field used Example value 2612 ------- --------- -------------------------- ------------- 2614 R2C 2615 ServiceID: R2C 2616 BParty: sip:123@p.com 2617 AParty: TN RFC2543 4567 2618 CallFormat: voice 2620 SourceFmt: audio 2622 (--- only "-" sub-type 2623 sub-field value used) --- 2624 Source: (--- No source specified) --- 2626 R2F 2627 ServiceID: R2F 2628 BParty: (--- SIP To: field not used) sip:R2F@pint.xxx.net 2629 AParty: TN RFCxxx +441213553 2630 CallFormat: fax 2632 SourceFmt: image 2634 jpeg 2636 Source: a=fmtp:jpeg 2639 R2FB 2640 ServiceID: R2FB 2641 BParty: sip:1-730-1234@p.com 2642 AParty: TN RFCxxx +441213553 2643 CallFormat: fax 2645 SourceFmt: image 2647 jpeg 2649 Source: a=fmtp:jpeg opr:1234 2652 R2HC 2653 ServiceID: R2HC 2654 BParty: (--- SIP To: field not used) sip:R2HC@pint.ita.il 2655 AParty: TN RFCxxx +441213554 2656 CallFormat: voice 2658 SourceFmt: text 2660 html 2662 Source: a=fmtp:html 2665 7. Open Issues and Draft State 2667 7.1. Open Issues 2669 Thre are no current technical open issues. 2671 7.2. Draft State 2673 Please note that changes are cumulative. 2675 Changes from version 00: 2677 * Removed References to Q763 parameters. 2678 It is difficult to see how these prameters could be passed to an Intelligent 2679 Network System, and in many potential configurations this information would 2680 not be accepted, as it did not come from a "trusted" source. 2681 * Removed references to ITU and other standardisation efforts. 2682 A PINT standards-track RFC cannot really refer to standards that are in 2683 progress. The set of IETF references are to documents that are on the 2684 Standards Track. Standardisation efforts in other organisations are subject 2685 to change and so these references are not appropriate. 2687 Changes from version 01 to previous interim version: 2689 * Corrected a few typos, orphaned internal references, and some of the 2690 examples. 2691 * Made a few corrections and added some comments on changes to be expected 2692 in the next draft. These were highlighted by **** before the affected 2693 paragraphs. 2694 * Removed references to the Telephony URL draft that has expired. It seems 2695 likely that the SIP draft will reach RFC status first. 2697 Changes from interim version to profile version 03: 2699 * removed previous change marks 2700 * New changes are indicated by *-*- in the text above the change 2701 * Corrected a few more typos, and re-visited the examples 2702 (thanks to Francois for the MIME comments!) 2703 * removed refs to out of date Internet Conference Architecture draft 2704 from "Introduction" 2705 * Corrected a few more typos, and re-visited the examples 2706 * added initial summary list for new PINT features 2707 in "PINT Protocol Architecture" 2708 * added a comment on the MIME version implied by PINT 1.0 2709 in "PINT Protocol Architecture" 2710 * added sub-section number for SDP description in "PINT Protocol 2711 Architecture" 2712 * added sub-section number for SIP description in "PINT Protocol 2713 Architecture" 2714 * removed reference to Security mechanisms in "SIP Operation in PINT" 2715 * added strictures as MUST and split into separate paras for clarity in 2716 "REQUIRED and OPTIONAL elements for PINT compliance" 2717 * added comment that PINT features may be useful for SIP/SDP in "REQUIRED 2718 and OPTIONAL elements for PINT compliance" 2719 * changed E.164 number -> N.P.A., and added local dialling plan number 2720 in " Network Type "TN" and Address Type "RFC2543" 2721 * added an introductory section on data object support in PINT & rewrote 2722 section in "Support for Data Objects within PINT" 2723 * added section on opaque references in "Support for Data Objects within 2724 PINT" 2725 * changed section number and reworked text in "Session Description 2726 support for included Data Objects" 2727 * removed ref to former (non-tagged) method of checking resolution type 2728 in "Session Description support for included Data Objects" 2729 * moved last part of section to the SIP description, leaving a ref. in 2730 "Session Description support for included Data Objects" 2731 * highlighted that attributes may appear as PINT URL parameters in SIP in 2732 "Attribute Tags to pass information into the Telephone Network" 2733 * moved para from end of "phone-context attribute" to main body of 2734 "Attribute Tags to pass information into the Telephone Network" 2735 * added sub-section added (by request) on "Presentation Restriction 2736 attribute" 2737 * Re-introduced sub-section on "CalledPartyAddress attributes parameters" 2738 (Q763 parameters), also by request 2739 * added comment on the general form of Q763 attributes to the original 2740 content of this section 2741 * added a comment that all PINT extensions can be covered by Strictures 2742 to "The "strict" attribute" 2743 * moved some orphaned text from "Session Description support for included 2744 Data Objects" into "Multi-part MIME" 2745 * removed sub-section on " PINT URLS within To: headers" and comments on 2746 "1-800-FLOWERS" style telephony URLs 2747 * removed references to wildcards in REGISTER messages within " REGISTER 2748 requests within PINT" 2749 * replaced example 4.8 with new examples 4.8 - 4.12 2750 * added section on "Limitations on Available Information and Request 2751 Timing for SUBSCRIBE" 2752 * added a few references that were missing 2753 * added "Collected ABNF" Appendix. 2755 Changes from profile version 3 to verion 4: 2757 * New changes are indicated by a -*-* mark on the line before the change 2758 * added a Security Considerations Section 2759 * really added the comment on PINT/SIP implying MIME 1.0 this time! 2760 * added ABNF definition for the use of PINT attributes as URL parameters 2761 * added ABNF definition of tsp URL parameter 2762 * added a statement that there are no current technical open issues 2763 * corrected boilerplate 2764 * added reference to SIP RFC number. 2766 Changes from profile version 4 to this version (indicated by -.-.) 2767 * In section 4.1, changed wording to emphasize that a "+1" number falls 2768 within the N.A.N.P. region. 2769 * Changed Ordering of Authors. 2770 * Changed incorrect reference to SIP in 3.4.4 - should be SDP 2771 * CHANGED! "strict:" SDP attribute to "require:" throughout 2772 * Corrected typos in 3.1 and 4.6 and 3.4.3.1, clarified text in 3.4.1 2773 * Changed title (repl. "profile" with more appropriate terms throughout) 2774 * CHANGED! SHOULD to MUST in 5.2 and also in 5.3 2775 * Added section on privacy implications of identifying the associated 2776 requst within SUBSCRIBE (section 5.1.4) 2777 * Added IANA Considerations Appendix 2778 * CHANGED! specification of Port value to "1" for PINT in 3.4.2 and ABNF 2779 * CHANGED! spec of "defaulted" media sub-type; uses "-" rather than empty 2780 ABNF CHANGES: 2781 * throughout, changed "|" to "/" as per RFC2234 (oops). 2782 * changed use of "<" and ">" throughout. these now imply a definition 2783 in another document (except for the initial connection-field 2784 definition that is merely copied to the PINT ABNF for completeness). 2785 * re-ordered rules to have refinements follow from dependent rules 2786 * added comments to show which rule names are redefinitions of SDP/SIP 2787 names. Where the redefinitions are not pure supersets, comment is 2788 preceded with "NOTE". 2789 * removed stray "media " from the pint-fmtp definition. 2790 * added space separators within PINT variant of fmtp attribute to 2791 deleniate the resolution items, if there's more than one. 2792 * changed definition of PINT variant of fmtp attribute to allow existing 2793 SDP attributes to be appended. Note that this allows zero or more sets 2794 of one or more attributes, with a semi-colon preceeding each set, and 2795 with spaces separating each attribute from its neighbours. 2796 * comma-separated values for require-header and strict-attribute. 2797 * added terminals for each of the tags used in attributes/parameters. 2798 * corrected mistaken ABNF definition of strict/require attribute 2799 - it should include just the field tags, not complete attributes! 2800 * changed the tag value of the strict attribute to "require" for 2801 consistency with the equivalent(ish) require-header, as per request. 2802 Note that they now share the same tag value ("require:"). 2803 * added strict-attribute to the list of PINT/SDP attributes (duh!) 2804 * added some extra rule names for common elements (for q763xx) 2805 * added the fmtp explicit source type tags (uri, spr, and opr) to the 2806 list of items that may be specified in a strict-attribute. For PINT, 2807 the expected behaviour on the part of a recipient (as mentioned in the 2808 body text) is that it should fail an Invitation including one of these 2809 constructs that it doesn't support. However, including these in a 2810 strict-attribute allows them to be used in the wider SIP/SDP context 2811 (e.g. as part of an OPTIONS message exchange). 2812 Changes from "protocol" version 00 to this version (indicated by -..-) 2813 * Security summary section 5.4 clarified and improved 2814 8. References 2815 [1] M. Handley, E. Schooler, H. Schulzrinne, & J. Rosenberg, 2816 "SIP: Session Initiation Protocol", RFC2543, 2817 Internet Engineering Task Force, March 1999. 2819 [2] M. Handley & V. Jacobsen, 2820 "SDP: Session Description Protocol", RFC2327, 2821 Internet Engineering Task Force, April 1998. 2822 [3] N. Freed & N. Borenstein, 2823 "Multipurpose Internet Mail Extensions (MIME) 2824 Part One: Format of Internet Message Bodies", 2825 RFC2045, November 1996. 2826 [4] N. Freed & N. Borenstein, 2827 "Multipurpose Internet Mail Extensions (MIME) 2828 Part Two: Media Types", 2829 RFC2046, November 1996. 2830 [5] The Unicode Consortium, 2831 "The Unicode Standard -- Version 2.0", 2832 Addison-Wesley, 1996. 2833 [6] ITU-T Study Group 2, 2834 "E.164 - The International Public Network Numbering Plan", 2835 ITU-T, June 1997. 2836 [7] H. Lu et al, 2837 "Toward the PSTN/Internet Inter-Networking--Pre-PINT Implementations", 2838 Informational RFC2458, Internet Engineering Task Force, Nov 1998. 2839 [8] ITU-T Study Group XI, 2840 "Q.763 - Formats and Codes for the ISDN User Part of SS No7" 2841 ITU-T, August 1994. 2842 [9] T. Berners-Lee, R. Fielding, & L. Masinter, 2843 "Uniform Resource Identifiers (URI): Generic Syntax", RFC2396, 2844 Internet Engineering Task Force, August 1998. 2845 [10] D. Crocker, 2846 "Standard for the format of ARPA Internet text messages",RFC822, 2847 Internet Engineering Task Force, August 1982. 2848 [11] ITU-T Study Group XI, 2849 "Q.1204 - IN Distributed Functional Plane Architecture", 2850 ITU-T, February 1994. 2851 [12] T. Dierks & C. Allen, 2852 "The TLS Protocol Version 1.0", RFC2246, 2853 Internet Engineering Task Force, January 1999. 2854 [13] S. Kent, R. Atkinson, 2855 "Security Architecture for the Internet Protocol", RFC2401, 2856 Internet Engineering Task Force, November 1998. 2857 [14] R. Housley, W. Ford, W. Polk & D. Solo, 2858 "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", 2859 RFC2459, Internet Engineering Task Force, January 1999. 2860 [15] D. Crocker & P. Overall, 2861 "Augmented BNF for Syntax Specifications: ABNF", RFC2234, 2862 Internet Engineering Task Force, November 1997. 2863 [16] D. Mills, "Network Time Protocol (version 3) specification and 2864 implementation", RFC1305, Internet Engineering Task Force, March 1992. 2865 [17] D. Eastlake, S. Crocker & J.Schiller, 2866 "Randomness Recommendations for Security", Informational RFC 1305, 2867 Internet Engineering Task Force, March 1992. 2869 9. Acknowledgements 2870 The authors wish to thank the members of the PINT working group for comments 2871 that were helpful to the preparation of this specification. Ian Elz's 2872 comments were extremely useful to our understanding of internal PSTN 2873 operations. The SUBSCRIBE and NOTIFY requests were first suggested by 2874 Henning Schulzrinne and Jonathan Rosenberg. 2876 Appendix A: Collected ABNF for PINT Extensions 2877 ;; --(ABNF is specified in RFC 2234 [15]) 2879 ;; --Variations on SDP definitions 2881 connection-field = ["c=" nettype space addrtype space 2882 connection-address CRLF] 2883 ; -- this is the original definition from SDP, included for completeness 2884 ; -- the following are PINT interpretations and modifications 2886 nettype = ("IN"/"TN") 2887 ; -- redefined as a superset of the SDP definition 2889 addrtype = (INAddrType / TNAddrType) 2890 ; -- redefined as a superset of the SDP definition 2892 INAddrType = ("IP4"/"IP6") 2893 ; -- this non-terminal added to hold original SDP address types 2895 TNAddrType = ("RFC2543"/OtherAddrType) 2897 OtherAddrType = () 2898 ; -- X-token is as defined in RFC2045 2900 addr = ( / / TNAddr) 2901 ; -- redefined as a superset of the original SDP definition 2902 ; -- FQDN and unicast address as specified in SDP 2904 TNAddr = (RFC2543Addr/OtherAddr) 2905 ; -- TNAddr defined only in context of nettype == "TN" 2907 RFC2543Addr = (INPAddr/LDPAddr) 2909 INPAddr = "+" 0*(("-" )/) 2910 ; -- POS-DIGIT and DIGIT as defined in SDP 2912 LDPAddr = 0*(("-" )/) 2914 OtherAddr = 1* 2915 ; -- OtherAdd defined in the context of OtherAddrType 2916 ; -- uric is as defined in RFC2396 2918 media-field = "m=" media port proto 2919 1*( fmt) 2920 ; -- NOTE redefined as subset/relaxation of original SDP definition 2921 ; -- space and CRLF as defined in SDP 2923 media = ("application"/"audio"/"image"/"text") 2924 ; -- NOTE redefined as a subset of the original SDP definition 2925 ; -- This could be any MIME discrete type; Only those listed are 2926 ; -- used in PINT 1.0 2927 port = ("0" / "1") 2928 ; -- NOTE redefined from the original SDP definition; 2929 ; -- 0 retains usual sdp meaning of "temporarily no media" 2930 ; -- (i.e. "line is on hold") 2931 ; -- (1 means there is media) 2933 proto = (INProto/TNProto) 2934 ; -- redefined as a superset of the original SDP definition 2936 INProto = 1* () 2937 ; -- this is the "classic" SDP protocol, defined if nettype == "IN" 2938 ; -- alpha-numeric is as defined in SDP 2940 TNProto = ("phone"/"fax"/"pager") 2941 ; -- this is the PINT protocol, defined if nettype == "TN" 2943 fmt = ( / "-") 2944 ; -- NOTE redefined as a subset of the original SDP definition 2945 ; -- subtype as defined in RFC2046, or "-". MUST be a subtype of type held 2946 ; -- in associated media sub-field or the special value "-". 2948 -.-. 2949 attribute-fields = *("a=" attribute-list ) 2950 ; -- redefined as a superset of the definition given in SDP 2951 ; -- CRLF is as defined in SDP 2953 attribute-list = 1(PINT-attribute / ) 2954 ; -- attribute is as defined in SDP 2956 -.-. 2957 PINT-attribute = (clir-attribute / q763-nature-attribute / 2958 q763plan-attribute / q763-INN-attribute / 2959 phone-context-attribute / 2960 pint-fmtp-attribute / strict-attribute) 2961 -.-. 2962 clir-attribute = clir-tag ":" ("true" / "false") 2964 -.-. 2965 clir-tag = "clir" 2967 -.-. 2968 q763-nature-attribute = Q763-nature-tag ":" q763-natures 2970 -.-. 2971 q763-nature-tag = "Q763-nature" 2973 -.-. 2974 q763-natures = ("1" / "2" / "3" / "4") 2976 -.-. 2977 q763-plan-attribute = Q763-plan-tag ":" q763-plans 2979 -.-. 2980 q763-plan-tag = "Q763-plan" 2981 -.-. 2982 q763-plans = ("1" / "2" / "3" / "4" / "5" / "6" / "7") 2983 ; -- of these, the meanings of 1, 3, and 4 are defined in the text 2985 -.-. 2986 q763-INN-attribute = Q763-INN-tag ":" q763-INNs 2988 -.-. 2989 q763-INN-tag = "Q763-INN" 2991 -.-. 2992 q763-INNs = ("0" / "1") 2994 -.-. 2995 phone-context-attribute = phone-context-tag ":" phone-context-ident 2996 -.-. 2997 phone-context-tag = "phone-context" 2999 phone-context-ident = network-prefix / private-prefix 3001 network-prefix = intl-network-prefix / local-network-prefix 3003 intl-network-prefix = "+" 1* 3005 local-network-prefix = 1* 3007 private-prefix = 1*excldigandplus 0* 3009 excldigandplus = (0x21-0x2d,0x2f,0x40-0x7d)) 3011 -.-. 3012 ; -- NOTE the following is redefined relative to the normal use in SDP 3013 pint-fmtp-attribute = "fmtp:" resolution 3014 *( resolution) 3015 ( ";" 1() *( )) 3016 ; -- subtype as defined in RFC2046. 3017 ; -- NOTE that this value MUST match a fmt on the ultimately preceeding 3018 ; -- media-field 3019 ; -- attribute is as defined in SDP 3021 -.-. 3022 resolution = (uri-ref / opaque-ref / sub-part-ref) 3024 -.-. 3025 uri-ref = uri-tag ":" 3026 ; -- URI-Reference defined in RFC2396 3027 -.-. 3028 uritag = "uri" 3030 -.-. 3031 opaque-ref = opr-tag ":" 0* 3033 -.-. 3034 opr-tag = "opr" 3035 -.-. 3036 sub-part-ref = spr-tag ":" 3037 ; -- Content-ID is as defined in RFC2046 and RFC822 3039 -.-. 3040 spr-tag = "spr" 3042 -.-. 3043 strict-attribute = "require:" att-tag-list 3045 -.-. 3046 att-tag-list = 1(PINT-att-tag-list / / 3047 pint-fmtp-tag-list) 3048 *("," 3049 (PINT-att-tag-list / / 3050 pint-fmtp-tag-list) 3051 ) 3052 ; -- att-field as defined in SDP 3054 -.-. 3055 PINT-att-tag-list = (phone-context-tag / clir-tag / 3056 q763-nature-tag / q763-plan-tag / 3057 q763-INN-tag) 3059 -.-. 3060 pint-fmtp-tag-list = (uri-tag / opr-tag / spr-tag) 3062 ;; --Variations on SIP definitions 3064 -.-. 3065 clir-parameter = clir-tag "=" ("true" / "false") 3067 -.-. 3068 q763-nature-parameter = Q763-nature-tag "=" Q763-natures 3070 -.-. 3071 q763plan-parameter = Q763-plan-tag "=" q763plans 3073 -.-. 3074 q763-INN-parameter = Q763-INN-tag "=" q763-INNs 3076 -.-. 3077 tsp-parameter = tsp-tag "=" 3078 ; -- hostname is as defined in SIP 3080 -.-. 3081 tsp-tag = "tsp" 3083 -.-. 3084 phone-context-parameter = phone-context-tag "=" phone-context-ident 3086 SIP-param = ( / / / 3087 / / ) 3088 ; -- the values in this list are all as defined in SIP 3089 PINT-param = ( clir-parameter / q763-nature-parameter / 3090 q763plan-parameter / q763-INN-parameter/ 3091 tsp-parameter / phone-context-parameter ) 3093 URL-parameter = (SIP-param / PINT-param) 3094 ; -- redefined SIP's URL-parameter to include ones defined in PINT 3096 -.-. 3097 Require-header = "require:" 1(required-extensions) 3098 *("," required-extensions) 3099 ; -- NOTE this is redefined as a subset of the SIP definition 3100 ; -- (from RFC2543/section 6.30) 3102 -.-. 3103 required-extensions = ("org.ietf.sip.subscribe" / 3104 "org.ietf.sdp.require") 3106 Appendix B: IANA Considerations 3108 There are three kinds of identifier used in PINT extensions that SHOULD 3109 be registered with IANA, if a new value is specified. These are: 3110 * Media Format sub-types, as described in section 3.4.2 of this document. 3111 * Private Attributes as mentioned in section 3.4.3 3112 * Private Phone Context values, as described in section 3.4.3.1. 3114 It should be noted that private Address Types (in section 3.4.1) have been 3115 explicitly excluded from this process, as they must be in the form of 3116 an X-Token. 3118 B.1. Media Format Sub-types 3119 Taking these in turn, the media format sub-types are used within the PINT 3120 extensions to SDP to specify the attribute line that holds the data source 3121 definitions. In normal use, the values in this field are sub-types of MIME 3122 discrete types[4]. If a value other than an IANA-registered sub-type is to 3123 be used, then it should either be an X-Token (i.e. start with "X-") or it 3124 should be registered with IANA. if the intention is to describe a new MIME 3125 sub-type, then the procedures specified in RFC 2048 should be used. It is 3126 ASSUMED that any new MIME sub-type would follow the syntactic rules for 3127 interpretation of associated PINT fmtp lines defined in this document. 3129 Note that, in keeping with the SDP description, such registrations SHOULD 3130 include the "proto" field values within which they are defined; however, it 3131 is appropriate to specify only that they can be used with "all values of 3132 TNProto". 3134 Conversely, if the intent is to define a new way of including data source 3135 definitions within PINT, then it will be necessary to specify, in the 3136 documentation supporting any such new "PINT Media Format Sub-type" 3137 registration, the syntax of the associated "fmtp" attribute line, as 3138 the identifier serves to indicate the interpretation that should be made 3139 of format specific attribute lines "tagged" with with such a sub-type. 3141 If the fmtp interpretation follows the PINT default, then it is adequate 3142 to mention this in the defining document rather than repeating the syntax 3143 definition given here (although, in this case, it is unclear why such a new 3144 registration would be required). As before, the Media Format sub-type SHOULD 3145 specify the values of "proto" field within which it is defined, but this can 3146 be "all values of TNProto". 3148 B.2. Private Attributes 3149 Any proprietary attribute lines that are added may be registered with IANA 3150 using the procedures mentioned in [2]; the mechanism is the same as that 3151 used in SDP. If the attribute is defined for use only within PINT, then it 3152 may be approapriate to mention this in the supporting documentation. Note 3153 that, in the PINT 1.0 specification covered here, there is no mechanism to 3154 add such freshly registered attribute lines to a "require:" clause. 3156 B.3. Private phone-contexts 3157 Within the session description used for PINT requests, a phone-context 3158 attribute may be used to specify the prefix or context within which an 3159 associated telephone-number (in a connextion line) should be interpreted. 3161 For "public" phone contexts the prefix to be used MUST start with either 3162 a DIGIT or a "+". Private phone contexts may be registered with IANA that 3163 do NOT start with either of these characters. Such a prefix may be useful 3164 to identify a private network, potentially with an associated numeric ID 3165 (see example 4 in section 3.4.3.1). In the example, the prefix acts as 3166 the context for X-acme.com's private network numbering plan. 3168 It is recommended that any private context to be registered have the general 3169 form of a token including a domain name, optionally followed by a digit string 3170 or other token. The appropriate form of the initial token name space will be 3171 similar to that used for private or vendor registrations for sub-types 3172 (e.g. vnd.acme.com). However, note that the registration will be used to 3173 specify a customer's private network numbering plan format rather than being 3174 used generally for all of their equipment vendor's customer's; thus, fbi.gov 3175 would be appropriate, but lucent.com would not (unless the private network 3176 were to be that used by Lucent internally). 3178 In addition, the supporting documentation MUST either declare that there is 3179 no associated token, or define the syntax by which that token can be parsed 3180 (e.g. vnd.fbi.gov 1*DIGIT). Note that the registration describes a 3181 format, not a value range; it is sufficient that the private context can be 3182 parsed, without the value being interpreted. 3184 In detail, the registration request should include: 3185 * Kind of registration (i.e. private phone-context attribute to be used 3186 within the service description of PINT service requests) 3187 * Contact details for the person responsible for the registration request 3188 (name, organisation, e-mail address, public telephone number) 3189 * Private Prefix initial token name (e.g. vnd.fbi.gov) 3190 * syntax for private context (e.g. "vnd.fbi.gov" 1*DIGIT, or 3191 "vnd.gtn.gov.uk") 3192 * Description of use (e.g. "This phone context declares an associated 3193 telephone number to be within the 'government telecommunications 3194 network'; the number is in an internal or private number plan form) 3195 * Network Type and Address Type with which this private context is 3196 associated; If the "normal" telephone types (as specified in this 3197 document) are used, then the values would be shown as: 3198 "nettype=TN" , addrtype="RFC2543Addr". If, however, this context were 3199 to be used with another address type, then a reference to that 3200 address type name and the syntax of that address value would be required. 3202 In short, this context is the telephone equivalent of a "Net 10" address 3203 space behind a NAT, and the initial name (and contact information) shows 3204 the context within which that address is valid. It also specifies the format 3205 for the network and address types (and address value syntax) with which this 3206 context is associated. 3208 Of course, IANA may refer the requested registration to the IESG or an 3209 appropriate IETF working group for review, and may require revisions to be 3210 made before the registration is accepted. 3212 Appendix C: Author's Addresses 3214 Scott Petrack 3215 MetaTel, Inc. 3216 284 North Ave. 3217 Weston, MA 02493 3218 scott.petrack@metatel.com 3219 +1 (781)-891-9000 3221 Lawrence Conroy 3222 Siemens Roke Manor Research 3223 Roke Manor 3224 Old Salisbury Lane 3225 Romsey, Hampshire 3226 U.K. SO51 0ZN 3227 lwc@roke.co.uk 3228 +44 (1794) 833666