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