idnits 2.17.1 draft-ietf-pint-profile-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Found some kind of copyright notice around line 31 but it does not match any copyright boilerplate known by this tool. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 2225 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 21 instances of too long lines in the document, the longest one being 59 characters in excess of 72. ** There are 152 instances of lines with control characters in the document. == There are 25 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 11 has weird spacing: '...fts are worki...' == Line 13 has weird spacing: '...t other group...' == Line 17 has weird spacing: '...and may be ...' == Line 21 has weird spacing: '... please check...' == Line 22 has weird spacing: '...ntained in th...' == (16 more instances...) -- 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) -- Missing reference section? 'PC' on line 1707 looks like a reference -- Missing reference section? 'PS' on line 1710 looks like a reference -- Missing reference section? 'XS' on line 1711 looks like a reference -- Missing reference section? '11' on line 1901 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 9 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force PINT WG 2 INTERNET-DRAFT Scott Petrack 3 draft-ietf-pint-profile-00.txt Lawrence Conroy 4 7 August 1998 Expires: 7 February 1998 6 The PINT Profile of SIP and SDP: 7 a Protocol for IP Access to Telephone Call Services 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, and 13 its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference material 19 or to cite them other than as ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 Distribution of this document is unlimited. 29 Copyright Notice 31 Copyright (c) The Internet Society (1998). All Rights Reserved 33 Abstract 35 This document contains the specification of the PINT Profile 1.0, which 36 defines a protocol for invoking certain telephone services from an IP 37 network. These services include placing basic calls, sending and 38 receiving faxes, and receiving content over the telephone. The protocol 39 is specified as a set of enhancements and additions to the SIP 2.0 and 40 SDP 2.0 protocols. 42 This document is intended for the PSTN-Internet Interworking (PINT) 43 working group of the Internet Engineering Task Force. Comments 44 are solicited and should be addressed to the working group's mailing 45 list at pint@lists.research.bell-labs.com and/or the authors. 47 Contents 49 1. Introduction and Glossary 51 2. PINT Milestone Services 52 2.1 Request to Call 53 2.2 Request to Fax 54 2.3 Request to Hear Content 55 2.4 Relation between PINT Milestone Services and Standard 56 Telephone Services 58 3. PINT Functional and Protocol Architecture 59 3.1 PINT Functional Architecture 60 3.2 PINT Protocol Architecture 61 3.3 REQUIRED and OPTIONAL elements for PINT compliance 62 3.4 PINT profile of SDP 2.0 63 3.4.1 Network Type "TN" and Address Type "RFCxxxx" 64 3.4.2 Media Types, Transport Protocol parameters, format 65 parameters and format specific attributes for TN 66 connected terminals 67 3.4.3 Format attributes for included content data 68 3.4.4 Attribute Tags to pass information into the Telephone 69 Network 70 3.4.5 The "strict" attribute 71 3.5 PINT profile of SIP 2.0 72 3.5.1 Multi-part mime sending of data along with SIP request 73 3.5.2 Warning header 74 3.5.3 The STATUS request 75 3.5.5 PINT URLs within PINT requests 76 3.5.6 Telephone Network Parameters within PINT URLs 77 3.5.7 BYE requests in PINT 78 3.5.8 REGISTER requests in PINT 80 4. Examples of PINT Requests and Responses 81 4.1 A request from an anonymous user to receive a phone call from 82 a Call Centre 83 4.2 A request from a non anonymous user to receive a phone call 84 4.3 A request to get a fax back 85 4.4 A request to have information read out over the phone 86 4.5 A request to send a text page to a user's pager. The text is 87 included in the request. 88 4.6 A request to send an image as a fax to fax machine. 89 4.7 A request to read out over the phone two pieces of content in 90 sequence. 91 4.8 Interaction with a Proprietary IVR-based FaxBack System 93 5. Security Considerations 94 6. Deployment considerations 95 6.1 Web Front End to PINT Infrastructure 96 6.2 Redirects to Multiple Servers 97 6.3 Competing PINT gateways REGISTERing to offer the same service 98 6.4 Relations to Intelligent Network and Public Network Standards 99 6.4.1 ITU-T 100 6.4.2 ETSI 101 6.4.3 ANSI 102 6.4.4 Other Standards 103 6.5 Relation between PINT Milestone services and ITU-T Q.1231 104 6.5.1 PINT Services 105 6.5.1.1 Click-to-Dial-Back (CTDBC) 106 6.5.1.2 Click-to-Fax (CLTFA) 107 6.5.1.3 Click-to-Fax-Back (CLTFB) 108 6.5.1.4 (Internet-Initiated) Voice-Access-to-Content (VATCI) 109 6.5.1.5 PINT vs. ITU-T service descriptions 110 6.5.2 Parameters needed for PINT Services 111 6.5.2.1 Service Identifier 112 6.5.2.2 A and B parties 113 6.5.2.3 Other Service Parameters 114 6.5.2.4 Service Parameter Summary 115 6.5.3 Q.1231 Parameter Mapping within PINT 116 7. Open Issues 117 8. References 118 9. Acknowledgements 119 10.Author's Addresses 121 1. Introduction 123 The desire to invoke certain telephone call services from the 124 Internet has been identified by many different groups (users, public and 125 private network operators, call centre service providers, equipment 126 vendors, etc.). The generic scenario is as follows (when the invocation 127 is successful): 129 1. an IP host sends a request to a server on an IP network; 130 2. the server relays the request into a telephone network; 131 3. the telephone network performs the requested call service. 133 One example is a user sending a request to have a call placed to his/her 134 telephone. It may be that a customer wishes to get a call from the 135 support department of some business, or a user wishes to hear some 136 remote automatic weather service via recorded or synthesised speech. 137 Within a local environment such a request might result in the placement 138 of a call between employees over the internal PBX. 140 We use the term "PINT Service" to denote such a complete transaction, 141 starting with the sending a request from an IP client and including the 142 telephone call service. ("PINT" is short for "Phone-IP Interworking 143 Services"). A PINT service always involves the placement of a call 144 within some Telephone Network. The original meaning of the acronym 145 "PINT" was "PSTN-Internet Interworking", but the term has since been 146 broadened to allow services which involve any type of circuit-switched 147 telephone system, not just the "Public" Switched Telephone System. 148 Private PBXs, cellular phone networks, and the ISDN can all be used to 149 deliver PINT services. Also, the request for service might come from 150 within a private IP network that is disconnected from the whole Internet. 152 There is some overlap between PINT service requests and third-party call 153 control. The requirements for the PINT protocol were deliberately 154 restricted to providing the ability to invoke a small number of fixed 155 telephone call services. These "Milestone PINT services" are specified 156 in section 2. Great care has been taken, however, to develop a protocol 157 that fits into the emerging Internet Conference Architecture [], 158 so that future extensions to PINT could develop along with Internet 159 Conferencing. 161 Within the Internet Conference Architecture, establishing media 162 calls is done via a combination of protocols. SIP [ ] is used to 163 establish the association between the participants within the call 164 (this association between participants within the call is called a 165 "session"), and SDP [ ] is used to describe the media to be 166 exchanged within the session. The PINT protocol uses these two 167 protocols, providing some extensions and enhancements to 168 enable SIP clients and servers to become PINT clients and servers. 170 The underlying model of Internet Conference sessions is unchanged. The 171 PINT user who wishes to invoke a service within the phone system uses 172 SIP to invite a remote PINT server into a session. ("The user places a 173 SIP call"). The invitation contains an SDP description of the media 174 session that the user would like to take place. (This might be a 175 "sending a fax session" or a "telephone call session", etc.) Acceptance 176 of the invitation by the PINT server establishes a session between the 177 client and server, during which the requested media can be sent. In a 178 PINT session the media is transported over the phone system, while in a 179 SIP session the media is normally transported over an internet. 181 The particular requirements of PINT users lead to some new messages, 182 however. For example, the fact that a server accepts an invitation and a 183 session is established is no guarantee that the media will be 184 successfully transported, neither in vanilla SIP nor in PINT. For 185 example, a PINT server may accept to send a fax to telephone B, but it 186 may be that the fax transmission fails after part of the fax is sent. 187 Therefore, the PINT client needs to be able to receive information about 188 the status of the actual telephone call session that was invoked as a 189 result of the established PINT session. This requirement leads to a new 190 STATUS request and to some new Warning: messages. 192 We can summarise the relationship between PINT and SIP as follows: The 193 invitation sequence (INVITE-OK-ACK) establishes a Internet Session 194 between the PINT server and client. The request contains a description 195 of the "telephone network media transport session" requested. The PINT 196 server sends an OK to signal its agreement to establish a PINT session 197 with the client. The actual transportation of media over the phone 198 (a.k.a "the phone call") might happen hours or days after the 199 establishment of the PINT call. Similarly, the phone call 200 might complete long before any BYE is sent. As 201 long as no BYE is sent, then the PINT session exists, and the client may 202 request the STATUS of the session, or may even request to change a 203 session parameter. Of course, it may be impossible to change the session 204 parameters (for example, the fax may already have been totally or 205 partially sent). The client sends a BYE to signal its desire to end the 206 PINT call. Once the BYE is acknowledged, there is no 207 longer any PINT association between the PINT client and server. A 208 Warning: line is used within the response to the BYE to indicate the 209 status of the telephone-side media transport session. Finally, at any 210 point during the PINT session (and possibly even afterwards), a client 211 may send a STATUS message to the PINT server to retrieve information 212 about the telephone network session associated to the PINT request. 214 The enhancements and additions specified here are not intended to alter 215 the behaviour of baseline SIP or SDP in 216 any way. The milestone PINT services fit seamlessly into the 217 rest of the Internet Conference Architecture, and the PINT profile can 218 be used to extend the usual SIP/SDP services to the telephone world. 219 This is a great added benefit of using SIP/SDP as the protocol to invoke 220 the PINT services. Apart from integrating well into existing protocols 221 and architectures, and the advantages of reuse, this means that the 222 protocol specified here can handle a rather wider class of call services 223 than just the Milestone services. 225 Some of the enhancements specified here (such as the use of 226 multipart MIME) make sense in the context of a pure Internet Conference. 227 The PINT profile has been designed so that each enhancement is 228 independent of any other. SIP transactions that have nothing to do with 229 telephone call services and telephone sessions should be able to use 230 these enhancements. It is possible that these will become part of future 231 versions of SIP and SDP. 233 The rest of this document is organised as follows: Section 2 describes 234 the original PINT Milestone services precisely; section 3 specifies the 235 PINT functional and protocol architecture; section 4 specifies the new 236 tags and headers in the PINT 1.0 profile of SIP and SDP; section 5 237 contains some security considerations for PINT. The final section 238 contains some informative examples. 240 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 241 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 242 document are to be interpreted as described in RFC 2119. In addition, 243 the construct "MUST .... OR ...." implies that it is an absolute 244 requirement of this specification to implement one of the two 245 possibilities stated (represented by dots in the construct). An 246 implementation MUST be able to interoperate with another implementation 247 which chooses either of the two possibilities. 249 1.1 Glossary 251 Requestor - An Internet Host from which a request for service originates 253 PINT Service - A services invoked within a phone system in response to a 254 request received from an PINT client. 256 PINT Client - An Internet Host that sends requests for invocation a PINT 257 Service, in accordance with this profile. 259 PINT Server - An Internet Host that accepts requests for PINT Service 260 and dispatches them onwards towards a telephone network. 262 Executive System - A system which interfaces to a telephone network that 263 executes a PINT service, and to a PINT Server. It is not directly 264 associated with the Internet, and is represented by the PINT Server. 266 Requesting User - The initiator of a request for service. This role may 267 be distinct from that of the "party" to any telephone network call that 268 results from the request. 270 (Service Call) Party - A Person who is involved in a telephone network 271 call that results from the execution of a PINT service request, or a 272 telephone network-based resource that is involved (such as an automatic 273 Fax Sender or a Text-to-Speech Unit). 275 2. Milestone Services 277 2.1 Request to Call 279 A request is sent from an IP host which causes a phone call to be 280 made, connecting party A to some remote party B. 282 2.2 Request to Fax 284 A request is sent from an IP host that causes a fax to be sent to 285 fax machine B. The request MUST EITHER contain a pointer to the fax data 286 (which could reside in the IP network or in the Telephone Network), OR 287 the request itself contain fax data. The content of the fax MAY be 288 text or some other more general image data. The precise rendering of 289 such data in a suitable form for the remote fax is outside the scope of 290 PINT. 292 2.3 Request to Hear Content 294 A request is sent from an IP host which causes a phone call to be 295 made to user A. Then some sort of content is spoken out over this phone 296 call. The request MUST EITHER contain a URL pointing to the content, OR 297 alternatively contain the content itself. The content MAY be text or 298 some other more general application data. The precise rendering of the 299 content into speech over the phone is beyond the scope of this 300 specification. (Although certain aspects of this rendering, such as 301 language preference, can be expressed and are discussed in section 3). 303 2.4 Relation between PINT Milestone Services and "Standard" Telephone 304 Services 306 The above characterisations may seem to lack precision to those familiar 307 with various telephone service definitions (see for example [ ], [ ], 308 [ ]). This is because there are many different versions and variations 309 of each telephone call service described above. Consider as an example 310 what happens when a user requests to receive a call from 1-800-CALL-CTR 311 via the PINT "Request to Call" service. There may be thousands of agents 312 in the call centre, and there may be any number of sophisticated 313 algorithms and equipment which is used to decide exactly which agent 314 will return the call. Even once this choice is made, there may be many 315 different ways to set up the call. The agent's phone might ring first, 316 and only then the original user will be called. Or perhaps the user will 317 be called first, and will hear some horrible music or pre-recorded 318 message while the agent is located. 320 PINT 1.0 reflects a deliberate decision to avoid specifying too closely 321 the precise telephone-side service. Operational details of individual 322 events within the telephone network that executes the request are 323 outside the scope of PINT. Section 6.5.1 contains a description of the 324 relationship between ITU-T telephone service standards and the PINT Milestone services. 326 3. PINT Functional and Protocol Architecture 328 3.1 PINT functional architecture 330 Familiarity is assumed with SIP 2.0 [] and with SDP 2.0 []. 332 PINT clients and servers are be SIP clients and servers. 333 SIP is used to route the request over the IP network to the correct 334 PINT server in a secure and reliable manner, and to communicate the 335 status of outstanding requests. 337 A PINT system may use proxy servers and redirect servers for their usual 338 SIP purpose, but at some point there must be a PINT server with some 339 means of relaying received requests into a telephone 340 system, and also some means to receive acknowledgement of these relayed 341 requests. A PINT server with this capability is called a "PINT gateway". 342 A PINT gateway appears to a SIP system as a user agent server. 344 So the PINT system might appear to an individual PINT client as follows: 346 /\/\/\/\/\/\/\ /\/\/\/\/\/\/\/\ 347 ___________ \ __/___ ___\_ \ 348 | PINT | PINT \ PINT | PINT | |Exec| Telephone / 349 | client |<--------->| server |gatewy|===|Syst| Network \ 350 |_________| protocol / cloud |______| |____| Cloud / 351 \ \ / \ 352 /\/\/\/\/\/\/\ \/\/\/\/\/\/\/\/ 354 Figure 1: PINT Functional Architecture 356 The system of PINT servers is represented as a cloud to emphasise that 357 a single PINT request might pass through a series of location servers, 358 proxy servers, and redirect servers, before finally reaching the correct 359 PINT gateway which can actually process the request by passing it to the 360 Telephone Network Cloud. 362 The PINT 363 gateway might have a true telephone network interface (for example an 364 analogue, PRI, or SS7 interface supporting DTMF, Q.SIG or ISUP), or it 365 might be connected via some other protocol or API to an "Executive 366 System" which is capable of invoking services within the telephone 367 cloud). The distinction between the PINT gateway and the Executive 368 System is a logical one; a single server may fulfil both functions. 369 The communication between the PINT gateway and the Telephone 370 Network Cloud via the Executive System is outside the scope of PINT. 372 As an example, 373 in an IN (Intelligent Networking) -enabled system, this might be done 374 by means of an "Intelligent Peripheral" which is attached to both the 375 IP network and the IN network. In an office environment, it might be 376 accomplished by a server which is adjunct to the office PBX, connected 377 to both the office PINT server and the office PBX. 379 3.2 PINT protocol architecture 381 PINT uses SIP and SDP in combination to convey the required information 382 about requests and responses. 384 The SDP payload contains a description of the particular telephone call 385 service which the requestor wishes to occur in the PSTN. The information 386 contained in the session description includes such things as the TN 387 address (i.e. the "telephone number") of the terminal(s) that should 388 receive the call, an indication of the media type to be transported 389 (e.g. audio, text, image or application data), and an indication if the 390 information is to be transported over the TN via voice, fax, or pager 391 transport. An indication of the content to be sent to the remote 392 telephone terminal (if there is any) is also included. 394 One advantage of using SDP is that the pieces of information are 395 conveyed independently. For example, a request to send some text via 396 voice transport will be fulfilled by invoking some text-to-speech-over- 397 the-phone service, and a request to send text via fax will be fulfilled 398 by invoking some text-to-fax service. 400 The following is a list of PINT 1.0 enhancements and additions to SDP. 402 a. A new Network Type "TN" and address types "RFCxxxx" and "X-..." 403 (section 3.4.1) 404 b. New media types "text", "image", and "application", the 405 associated new protocol transport keywords "voice", "fax" and 406 "pager" and the associated format types and attribute tags 407 (section 3.4.2) 408 c. New Format Specific Attributes for included content data 409 (section 3.4.3) 410 d. New attribute tags, used to pass information to the TN (section 411 3.4.4) 412 e. A new attribute tag "strict", used by a client to indicate that 413 some attribute is required to be supported in the server 414 (section in 3.4.5) 416 SIP is used to route the request for telephone service from the PINT 417 client to the PINT gateway. The following is a complete list of PINT 418 enhancements and additions to SIP: 420 f. The multipart MIME payloads as specified (section 3.5.1) 421 g. The "Warning:" header as specified (section 3.5.2) 422 h. The STATUS request as specified (section 3.5.3) 423 i. Require: headers for PINT clients (section 3.5.4) 424 j. A format for PINT URLS within a PINT request (section 3.5.5) 425 k. PINT URLs (section 3.5.6) 426 l. The security mechanisms of section 5 for third party 427 authentication. 429 Section 3.5.7 contains remarks about how BYE requests are used within 430 PINT, and section 3.5.8 contains remarks about how REGISTER requests 431 are used within PINT. These do not change the behaviour of baseline 432 SIP in any way; they are included here for clarification of the 433 semantics when used with Telephone Network Sessions. 435 3.3 REQUIRED and OPTIONAL elements for PINT compliance 437 PINT 1.0 clients MUST support the TN network type and the RFCxxxx 438 address type. Servers MUST in addition support the STATUS method, 439 "Warning: headers, and the "strict" attribute. The other new protocol 440 elements are "conditionally mandatory". This means that each new PINT 441 construct enables a different function, and a client or server which 442 wishes to enable that particular function MUST do so by the construct 443 specified in this document. However, there is no single PINT service 444 that is required to be supported by all PINT clients or servers. For 445 example, one can build a PINT client and server which only supports the 446 Request-to-Call telephone call service, without support for the 447 other Milestone services. 449 In general, many optional features of SIP and SDP make sense as 450 specified in the PINT context. An example is the SDP a=lang: attribute, 451 which can be used to describe the preferred language of the callee. 452 Another example is the use of the t= parameter to indicate that the time 453 at which Telephone Call Service is to be invoked. Since the Session 454 Description within the PINT request describes exactly the "telephone 455 call session" to be invoked, this is simply the usual use of the t= 456 field. A third example are the quality attributes. Any SIP or SDP 457 option or facility is available to PINT clients and servers without 458 change. 460 3.4 PINT profile of SDP 2.0 462 PINT 1.0 adds to SDP the possibility to describe audio, fax, and pager 463 telephone sessions. It is deliberately designed to hide technical 464 details of the telephone network. The only network type defined for PINT 465 is the generic "TN" (Telephone Network). More precise tags such as 466 "ISDN," "GSM," are not allowed. Similarly, the transport protocols MUST 467 be one of "fax", "voice" and "pager"; there are no identifiers for the 468 various TN fax protocols. The actual fax protocol negotiation will take 469 place within the TN. The data to be transported is identified only as 470 text data, image data, or some more general application data. An 471 important example of transporting "application" data is the milestone 472 service "Voice Access to Web Content". In this case the data to be 473 transported is pointed to by a URI, the data type is application/URI, 474 and the transport protocol would be "voice." Some sort of speech- 475 synthesis facility, in the end speaking out to a Phone, will have to be 476 invoked to perform the service. 478 This section gives details of these new SDP keywords. 480 3.4.1 Network Type "TN" and Address Type "RFCxxxx" 482 The TN ("Telephone Network") network type is used to indicate that 483 the terminal is connected to a telephone network. 485 The address types allowed for network type TN are "RFCxxxx" (the "xxxx" 486 will be filled in by either the Telephony-URL RFC number or the SIP RFC 487 number) and private address types, which MUST begin with an "X-". 489 Address type RFCxxxx is a string conforming to the "telephone- 490 subscriber" BNF specified in RFCxxxx, [, section x.y.z] 492 Examples: 493 c= TN RFCxxxx +1-201-406-4090 494 c= TN RFCxxxx 12014064090 496 A telephone-subscriber string is of one of two types: global-phone- 497 number or local-phone-number. These are distinguished by the fact that a 498 global-phone-number begins with a "plus" sign "+". A global-phone-number 499 is by default to be interpreted as an internationally significant E.164 500 number, as defined by [ ]. A local-phone-number string is by default to 501 be interpreted as belonging to an unknown numbering plan, as defined by 502 [ ]. 504 These defaults may be changed by the use of the attributes defined in 505 section 3.4.5 below. 507 An implementation MAY use private addressing types, which can be useful 508 within a local domain. These address types MUST begin with an "X-", 509 and SHOULD contain a domain name after the X-, e.g. "X- 510 mytype.mydomain.com". An example of such a connection line is as 511 follows: 513 c= TN X-mytype.mydomain.com A*8-HELEN 515 Note that most dialable telephone numbers are writeable as local-phone- 516 numbers within address RFCxxxx; new address types should only be used 517 for formats which cannot be so written. 519 [??? Do we need an new address type which includes DTMF keys A, B, C and D???] 521 3.4.2 Media Types, Transport Protocol parameters, format parameters and 522 format specific attributes for TN connected terminals 524 In order to describe the media that can be transported to TN 525 terminals within TN sessions, PINT 1.0 specifies the use of some new 526 media types, transport protocol parameters, format parameters, and 527 format specific parameters. This specification only applies when used 528 with terminals connected via the "TN", although much of the semantic 529 carry over without change to IN connected terminals as well. 531 The media types within PINT 1.0 requests MUST be one of "audio", 532 "image", "text" and "application." Note that each of these is a well- 533 defined MIME type (see []). The port number for PINT terminals MUST be 534 0. The transport protocol keywords MUST be one of are "voice", "fax", 535 and "pager." Within each request, the allowed format parameters are 536 precisely the MIME sub-types of the MIME types that appear within the 537 media type within the request. Format Specific Attributes are used to 538 indicate the actual content to be transported to the remote terminal for 539 example, when the remote telephone terminal is a fax machine or pager). 541 Media type "audio" must only be used with transport protocol "voice." 542 There are no defined format parameters. This indicates a TN terminal 543 which wishes to receive an "plain old voice telephone call." As an 544 example, the following excerpt from a session description describes a 545 phone which is ready to receive an ordinary phone call at E.164 546 international phone number +12014064090: 548 c= TN RFCxxxx +12014064090 549 m= audio 0 voice 551 [???One could imagine a media description like "m= audio 0 fax wav" 552 which would mean to "play a wav file out to a fax machine," for example 553 via speech-to-text-to-fax. Do we need to mention this explicitly? 554 Similarly with "m= audio 0 pager wave" for playing out audio files to a 555 remote pager. These are not milestone services -- do we need to mention 556 them specifically now? We could just include text allowing any MIME sub- 557 type of the major type as an option] 559 Media Type "image" MUST be used with EITHER transport protocol "fax" OR 560 "pager". The allowed format parameters are any MIME subtype of MIME type 561 image (see []). The format specific attribute "a=fmtp: " MAY 562 be used to include a URI which points to the image data to be sent to 563 the remote TN terminal (see section 3.2.3 below). Alternatively, the 564 format specific attribute "a=fmtp: " MAY be used to 565 indicate that image data is included within the PINT request itself, 566 within a multipart MIME part. (see section 3.4.3 below). 568 When the protocol is "fax," the image is to be transported over the TN 569 to a remote fax machine. And when the protocol is "pager" the image is 570 to be transported over the TN to some remote pager machine. 572 [??As before, One could easily imagine a media description like "m= 573 image 0 fax voice" which would mean to "describe in voice the image," 574 for example via some sort of image recognition. Do we need this?] 576 Here is an example of the use of media type image to send a jpeg image 577 stored on the internet at http://www.acme.com/~sbp/pic1.jpeg to a fax 578 machine at phone number +1-201-406-4090: 580 c= TN RFCxxxx +1-201-406-4090 581 m= image 0 fax jpeg 582 a=fmtp:jpeg http://www.acme.com/~sbp/pic1.jpeg 584 Media Type "text" can be used with transport protocols "fax," 585 "voice," or "pager". The "voice" protocol indicates that the phone 586 system is to use some text-to-speech mechanism to read out the text to 587 the indicated phone terminal. The "fax" protocol indicates that the text 588 is to be printed out as is on a remote fax machine. The "pager" protocol 589 transports the text to a remote machine. (The PINT server may return a 590 "606 Not Acceptable" error if the content to be transmitted contains 591 unsupported characters, e.g. If the remote pager can receive only digits 592 and some text is sent) The allowed format parameters are any MIME 593 subtype of MIME type text (see [ ]). As with media type "image", the 594 format specific attribute tags ("a=fmtp: ) are used to 595 indicate the precise data to be sent over the Telephone Network to the 596 remote terminal. The can contain either a URI or a content-ID. 598 Media type "application" MAY be used with transport protocol 599 "fax," "voice," or "pager". In principle, any MIME subtype of type 600 "application" can be used as the format, but the main intent in to allow 601 media type application is to allow format parameter URI. This is used in 602 combination with an attribute tag "a=fmtp:URI " to indicate that 603 the URI written in the attribute tag points to some content on the 604 Internet which is to be sent via either "voice transport" or "fax 605 transport" to the remote TN terminal. This is the generic way that a 606 PINT request is made to fax/read-out the content pointed to by URI 607 to the TN terminal indicated in the connection (c= ) line. 609 Some PINT requests are to invoke telephone network sessions where 610 specific content is to be transported to the remote terminal. For 611 example, this happens when the request is for the Milestone Service 612 "Request-to-Fax" and Request-to-hear-Content. 614 If the PINT request is a request to transport data to a TN terminal, 615 then the media description contains a format parameter which must be a 616 MIME sub-type of the media type indicated in the start of the m= line. 617 It is allowed to include several format parameters in the media 618 description. This indicates alternative image formats of the same 619 content which are available on the internet for the server. 621 In order to point to the content on the IP network which is to be 622 sent, a format specific parameter is used: 624 a=fmtp: 626 The must be one of the MIME subtypes that appear in the m= media 627 description line. The is a string of URIs, each one of which 628 points to data of the specified MIME subtype. If more than one URI is 629 included in the attribute, they are to be space separated, and this 630 indicates that ALL the URIs are to be sent, serially, one after the 631 other. This can be used, for example, to send several different 632 unrelated URIs within a single fax transmission. 634 If there is more than one format in the m= line, this indicates that the 635 same information is available in different alternative formats. Each 636 format must have a single associated format specific attribute line. 637 Within a single media description, all the attribute lines 638 point to the same information to be sent over the TN, and that the 639 PINT server can use ANY ONE of the formats and attribute lines to 640 retrieve the data to be sent. The alternatives are listed in order of 641 preference, with the first alternative first. 643 If a single PINT request contain several media descriptions, this 644 is an indication to send several different pieces of content, each one 645 with a different format. Each media description describes a single piece 646 of content to be sent. They are to be sent serially, one after the 647 other, in the order of their appearance within the session description. 649 It is also possible to use the media type "application" with format 650 parameter "URI", with format specific attributes containing a string of 651 unrelated URIs: 653 c= TN RFCxxxx +1-201-406-4090 654 m= application 0 voice URI 655 a=fmtp:URI http:xxxxx http:yyyyyy ...... 657 This is a request to read out the content of a series of unrelated Web 658 Pages over the TN to the phone terminal at address +1-201-406-4090. 659 The URIs are sent serially, one after the other, in the order of their 660 appearance within the attribute line. 662 This scheme provides maximum simplicity in the usual cases of a request 663 for sending some single piece of data, but allows the flexibility to 664 store the same data in various alternative formats (say storing a 665 picture in some proprietary highly-compressed form and in some more 666 simple generally-understood form). It allows a single request to 667 be for sending multiple bits of content to the remote terminal. 669 Note that it may be more than one PINT request which results in the same 670 service. For example, the content might be reachable as media type 671 "text/plain" or more generically as media type application/URI. If the 672 requestor knows at request time that the data to be sent is of 673 type image or text, it is RECOMMENDED that the media description 674 indicate this rather than use the generic media type "application," such 675 as in "m= application 0 fax URI". The following two descriptions might 676 result in the same TN service, but the second is more precise 677 and if it is the desired service it is preferable to use it: 679 m=application 0 fax URI 680 a=fmtp:URI http://www.acme.com/pic1.tif 682 m=image 0 fax tif 683 a=fmtp:tif http://www.acme.com/pic1.tif 685 Note that these two descriptions are not truly equivalent. The first 686 description is a generic request to "fax me the indicated URI", and it 687 is not clear exactly what sort of translation will appear at the fax 688 machine. The second description is a more precise request to render the 689 tif picture on the remote fax machine. (It is of course true that it is 690 not specified exactly how the image/tif is to be rendered, but 691 the instruction to render media type image/tif gives more information 692 than the instruction to render media type application/URI). 694 3.4.3 Format attributes for included content data 696 In addition to pointing to the data on the internet, 697 it is possible to include the content data within the SIP 698 request itself. This is done by having the SIP payload be multipart 699 MIME. The first MIME part contains the SDP description of the telephone 700 call service to be executed. The other MIME parts contain the Content Data 701 to be transported. Within the SDP MIME part, format specific 702 attributes lines are used to indicate which other MIME part within the 703 request contains the content data. Instead of a URI, the format specific 704 attributes indicates the Content-ID of the MIME part of the request 705 which contains the actual data: 707 c= TN RFCxxxx +1-201-406-4090 708 m= text 0 fax plain 709 a=fmtp:plain 711 The parameter is the Content-ID of one of the MIME parts 712 inside the message. One can always distinguish a Content-ID 713 from a URI by the presence of a colon before the @ sign, and this can be 714 used to distinguish between included content and content which resides 715 elsewhere on the Internet. 717 For example, in a multipart message where the string "------next-------" 718 is the boundary, the first two parts might be as follows: 720 ------next------- 721 Content-Type: application/sdp 722 .... 723 c= TN RFCxxxx +1-201-406-4090 724 m= text 0 pager plain 725 a=fmtp:plain 17@mymessage.acme.com 727 ------next------- 728 Content-Type: text/plain 729 Content-ID: 17@mymessage.acme.com 731 This is the text that is to be paged to +1-201-406-4090. 733 ------next------- 735 PINT clients should be extremely careful when sending included data 736 within a PINT request. Such requests SHOULD be sent via TCP, to avoid 737 fragmentation and to transmit the data reliably. It is possible that the 738 PINT server is a proxy server that will replicate and fan out the 739 request, which could be disastrous if the request contains a large 740 amount of application data. PINT proxy servers should be careful not 741 to create many copies of a request with large amounts of data in it. 743 This mechanism is particularly useful when the request is to send a 744 short message to a Telephone Network Pager. The ability to indicate 745 different alternatives for the content to be transported is also 746 useful, even when the alternatives are included within the request. For 747 example, a request to send a short message to a pager might include the 748 message in unicode [ ] and an alternative version of the same content in 749 text/plain, should the PINT server or telephone network not be able to 750 process the unicode. 752 3.4.4 Attribute Tags to pass information into the Telephone Network 754 It may be desired to include within the PINT request service 755 parameters which can be understood only by some entity in the Telephone 756 Network Cloud. SDP attribute parameters are used for this purpose. They 757 MAY appear within a particular media description or outside of a media 758 description. These attributes may also appear within PINT URLS 759 (see section 3.5.6). This is necessary so that telephone terminals 760 which require the attributes to be defined can appear within the To: 761 line of a PINT request as well as within PINT session descriptions. 763 The purpose of these attributes is to allow the client to specify 764 extra context within which a particular telephone number is to be 765 interpreted. Although it is recognised that such attributes are 766 occasionally necessary, for reasons internal to the telephone networks 767 which carry out the PINT requests, the URLs appearing in the To: and 768 From: headers and within the Request-URI offer a 770 These attributes are often used in conjunction with the "strict" 771 attribute (section 3.4.5) and the "org.ietf.ping.strict" Require: tag 772 (section 3.5.4). 774 It is not possible to standardise every possible internal telephone 775 network parameter. PINT 1.0 attributes have been chosen for 776 specification because they are common enough that many different PINT 777 systems will want to use them, and therefore interoperability will be 778 increased by having a single specification. 780 3.4.4.1 ITU-T CalledPartyAddress attributes parameters 782 These attributes correspond to fields that appear within the ITU-T Q.763 783 "CalledPartyAddress" field [ ITU-T Q.763 ,section 3.9 ]. PINT clients 784 use these attributes in order to specify further parameters relating to 785 Terminal Addresses, in the case when the address indicates a 786 "local-phone-number." In the case that the PINT request contains a 787 reference to PSTN terminal, the parameters may be required to correctly 788 identify the remote terminal 790 The defined attributes are: 792 a=Q763-nature: - indicates the "nature of address indicator". 793 The value MAY be any number between 0 and 127. 794 The following values are specified: 796 "1" a subscriber number 797 "2" unknown 798 "3" a nationally significant number 799 "4" an internationally significant number 801 The values have been chosen to coincide with the values in Q.763. Note 802 that other values are possible, according to national rules or future 803 expansion of Q.763. 805 a=Q763-plan: - indicates the numbering plan to which the address 806 belongs. The value MAY be any number between 0 and 807 7. The following values are specified: 809 "1" Telephone numbering plan (ITU-T E.164) 810 "3" Data numbering plan (ITU-T X.121) 811 "4" Telex numbering plan (ITU-T F.69) 813 The values have been chosen to coincide with the values in Q.763. Note 814 that other values are possible, according to national rules or future 815 expansion of Q.763. 817 a=Q763-INN - indicates if routing to the Internal Network Number 818 is allowed. The value MUST be ONE of: 820 "0" routing to internal network number allowed 821 "1" routing to internal network number not 822 allowed 824 The values have been chosen to coincide with the values in Q.763. 826 Note that it is possible to use a local-phone-number and indicate via 827 attributes that the number is in fact an internationally significant 828 E.164 number. Normally this SHOULD NOT be done; an internationally 829 significant E.164 number is indicated by using a "global-phone-number" 830 for the address string. 832 3.4.4.2 The phone-context attribute 834 An additional attribute is specified to enable "remote local dialling". 835 This is the service that allows a PINT client to reach a number from 836 far outside the area or network which can usually reach the number. It 837 is useful when the sending or receiving address is only dialable within 838 some local context, which may be remote to the origin of the PINT 839 client. 841 For example, if Alice wanted to report a problem with her telephone, she 842 might then dial a "network wide" customer care number; within the 843 British Telecom network in the U.K., this is "152". Note that in this 844 case she doesn't dial any trunk prefix - this is the whole dialable 845 number. If dialled from another operator's network, it will not connect 846 to British Telecom's Engineering Enquiries service; dialling "+44 152" 847 will not normally succeed, as it's Network-Specific Service Number. 849 Within the telephone network, the "local context" is provided by the 850 physical connection between the subscriber's terminal and the central 851 office. An analogous association between the PINT client and the PINT 852 server which first receives the request may not exist, which is why it 853 may be necessary to supply this missing "telephone network context." 855 There are many reasons why extra context might be necessary to interpret 856 a given telephone number: 858 a. The telephone number might be reachable in many different ways, 859 such as via competing telephone service providers, and the PINT 860 client wishes to indicate its selection of service provider. 861 b. The telephone number might be reachable only from a limited 862 number of networks, such as an '800' freephone number. 863 c. The telephone number might be reachable only within a 864 single telephone network, such as the '152' customer service 865 number of BT. Similarly, the number might be an internal 866 corporate extension reachable only within the PBX. 868 However, as noted above, it should not usually be necessary to use SDP 869 attributes to specify the phone context. URLs such as 152@pint.bt.co.il 870 within the To: header and/or Request-URI, normally offer sufficient 871 context to resolve telephone numbers. 873 This attribute is defined as follows: 875 a=phone-context: 876 phone-context-identifier = network-prefix | private-prefix 878 network-prefix = intl-network-prefix | local-network-prefix 879 intl-network-prefix = "+" 1*DIGIT 880 local-network-prefix = 1*DIGIT 881 private-prefix = 884 Although not every phone-context can be specified, the local contexts 885 which correspond to dialable public telephone networks can be. An 886 intl-network-prefix and local-network-prefix MUST be a bona fide network 887 prefix, and a network-prefix which is an intl-network-prefix MUST begin 888 with an E.164 service code ("country code"). 890 It is possible to register new private-prefixes with IANA so as to 891 avoid confrontation. Prefixes which are not so registered MUST begin 892 with an "X-" to indicate their private, non-standard nature. 894 Example 1: 896 c= TN RFCxxxx 1-800-765-4321 897 a=phone-context:+972 899 This describes an terminal whose address in Israel (E.164 country code 900 972) is 1-800-765-4321. 902 Example 2: 904 c= TN RFCxxxx 1-800-765-4321 905 a=phone-context:+1 907 This describes an terminal whose address in North America (E.164 908 country code 1) is 1-800-765-4321. 910 The two telephone terminals described by these descriptions are 911 different; in fact they are located in different countries. 913 Example 3: 915 c=TN RFCxxxx *123 916 a=phone-context:+97252 918 This describes a terminal whose address when dialled from within the 919 network identified by +97252 is the string "*123". It so happens that 920 +97252 defines one of Israeli cell phone providers, and *123 reaches 921 customer service when dialled within that network. 923 Of course it may well be useful or necessary to use one of the Q.763 924 attribute parameters in combination with the phone-context attributes. 926 Example 4: 928 c= TN RFCxxxx 321 929 a=phone-context:X-acme.com 23 931 This might describe the telephone terminal which is at extension 321 932 of PBX number 23 within the acme.com private PBX network. It is expected 933 that such a description would be understandable by the acme.com PINT 934 server which receives the request. 936 Note that if the PINT server receiving the request is inside the 937 acme.com network, the same terminal might be addressable as follows: 939 c= TN RFCxxxx 7-23-321 941 (assuming that "7" is dialled in order to reach the private PBX network 942 from within acme.com) 944 Proprietary attribute "a=" lines, which by definition are not 945 interoperable, may be nonetheless useful when it is necessary to 946 transport some proprietary internal TN variables over the IP network. 947 We shall see an example of such usage in section 4. 949 3.4.5 The "strict" attribute 951 Unfortunately, according to the SIP specification, a PINT server is 952 allowed simply to ignore attribute parameters that it does not 953 understand. In order to force a client to fail a request if it does not 954 understand one of the PINT attributes, a client should use the "strict" 955 attribute (section 3.4.5), specified as follows: 957 a=strict: 959 where the attribute-list is a comma-separated list of attributes that 960 appear elsewhere in the session description. 962 In order to process the request successfully the PINT server must BOTH 963 understand the attribute AND ALSO fulfil the request implied by the 964 presence of the attribute, for each attribute appearing within the 965 attribute-list of the strict attribute. 967 If the server does not recognise the attribute listed, or cannot fulfil 968 the request implied by the attribute, the PINT server MUST fail the 969 request with (606 Not Acceptable), along with (a) suitable Warning: 970 line(s) explaining the problem. 972 The "strict" attribute may appear anywhere in the session description, 973 and any number of times, but it MUST appear before the use of the 974 attribute marked as strict. 976 Since the "strict" attribute is itself an attribute, the SIP spec allows 977 a server which does not understand the strict attribute to ignore it 978 also. In order to ensure that the PINT server will comply with the 979 "strict" attribute, a PINT clients should include a Require: header with 980 the tag "ietf.org.pint.strict" (section 3.5.4) 982 3.5 PINT profile of SIP 2.0 984 PINT requests are SIP requests; Many of the specifications within this 985 profile merely explain how to use existing SIP facilities for the 986 purposes of PINT. 988 3.5.1 multi-part mime sending of data along with SIP request 990 A PINT request can contain a payload which is multipart MIME. In this 991 case the first part MUST contain an SDP session description, which 992 includes at least one of the format specific attribute tags for 993 "included content data" specified above in section 3.2.4. All subsequent 994 parts contain content data which is to be transported in the requested 995 Telephone Call Service. It is allowed that within a single PINT request, 996 some of the data MAY be pointed to by a URI within the request, and some 997 of the data MAY be included within the request. 999 3.5.2 Warning header 1001 A PINT server MUST support the SIP "Warning:" header. 1002 It is used to signal mismatches between PINT clients and servers from 1003 different versions and with different supported features. (It is also 1004 used to signal the status of an ongoing session that is referred to 1005 within a retransmitted or STATUS request (see 3.5.3 below)). 1006 For example, suppose a client sends a PINT request to a 1007 server which understands PINT requests but which cannot provide the 1008 particular Telephone Call Service requested. Perhaps the PINT 1009 request is to send a jpeg picture to a particular TN fax machine, but 1010 the server cannot retrieve and/or translate jpeg pictures from the 1011 Internet into Fax transmissions. In such a case the server would fail 1012 the request and must include a Warning such as the following: 1014 Warning: 4xx pint.acme.com Incompatible Format: jpeg 1016 SIP servers which do not understand the PINT extensions at all are 1017 strongly encouraged to use the Warning: header to indicate that that 1018 PINT extensions are not understood. 1020 Note that the Warning: header may be used even if the 1021 response is not an error. In the above example, the request might have 1022 contained several alternative formats for the image to be faxed, and the 1023 server can return the above Warning: even in a successful response, to 1024 indicate that it did not understand the jpeg format, although it did 1025 understand one of the other alternatives and is processing the request 1026 using that alternative: 1028 Warning: 3xx pint.acme.com Incompatible Format: jpeg 1029 Warning: 502 pint.acme.com Using tif http://server/pics/a123.tif 1031 PINT defines a new family 5xx of Warning codes to be used to describe 1032 the status of media sessions. PINT 1.0 defines five such codes: 1034 500 Session scheduled for 1036 This indicates that the requested session has been successfully queued, 1037 but it has not yet begun. The is an optional part of the 1038 Warning Text and indicates the time at which the session is scheduled to 1039 begin. The HTTP-Date MUST be at the end of the Warning Text. A Server 1040 MUST NOT end the Warning Text with a valid HTTP-Date UNLESS this 1041 indicates the time at which the session will begin. 1043 501 Session Begun 1045 This indicates that the requested session has begun successfully and is 1046 proceeding normally. The is an optional part of the Warning 1047 Text and indicates the time at which the session began. A Server MUST 1048 NOT begin the Warning Text with a valid HTTP-Date UNLESS this indicates 1049 the time at which the session began. 1051 502 Session in Progress 1053 This indicates that the requested session has begun successfully, is 1054 proceeding normally, and has not yet terminated. 1056 503 Session Completed 1058 This indicates that the requested session completely normally. The 1059 is an optional part of the Warning Text and indicates the 1060 time at which the session ended. A Server MUST NOT begin the Warning 1061 Text with a valid HTTP-Date UNLESS this indicates the time at which the 1062 session ended. 1064 504 Sent XXX Page of YYY 1066 This warning can be included in the response to a fax session to 1067 indicate that XXX out of a total of YYY pages have been sent. The 1068 parameter is an optional part of the Warning text and 1069 indicates the numbers XXX and YYY in a machine readable, language- 1070 independent manner. It is allowed to include only one of the two 1071 numbers, in which case the period "." must be included before or after 1072 the number. A Server MUST NOT begin the Warning Text with a 1073 parameter UNLESS this is to indicate the number of pages sent. 1075 Fax-Prog = ( pages-sent "." total-pages | pages-sent "." | "." total-pages ) 1076 pages-sent = *digit 1077 total-pages = *digit 1079 Examples are as follows: 1081 Warning: 504 pint.acme.fr 2.5 2 pages sur 5 envoy'ees 1082 Warning: 504 pint.acme.com 2. 2 pages sent so far 1084 These warning codes can be used independently within a single response. 1085 For example, a 501 and 503 warning can be returned in a single response 1086 to indicate at which time the telephone session started and ended. 1087 Warning code 504 can be returned with various combinations of the other 1088 Warning codes. 1090 The Warning headers can be sent within STATUS requests (section 3.5.3) 1091 as well as within responses, if the original request contained a 1092 Location: header to indicate the presence of a PINT server which can 1093 receive STATUS requests. 1095 3.5.3 The STATUS request 1097 In PINT there is a requirement to propagate the status of the telephone 1098 network sessions described within the SDP payload. 1099 Warning headers are used for this purpose as well, as a Warning can be 1100 merely informational and is not required to indicate an error. PINT 1101 specifies a new method, STATUS, expressly for the purpose of requesting 1102 an update on the server's view of the status of an outstanding request 1103 or media session. 1105 If a STATUS request were required to come from the same client that made 1106 the original request, it would be possible to use client retransmission 1107 instead of a new method. But it is very desirable to allow such 1108 requests to come from other clients in the network. For example, one 1109 might request that a fax be sent, and then have someone else (e.g. a 1110 secretary) check if the fax actually got sent. 1112 The STATUS request is submitted by a client to determine the status 1113 of an outstanding request. The request payload must include an SDP 1114 description which is identical to the original description. It SHOULD 1115 NOT include whatever included Content was present in the original 1116 request, and a server MUST ignore whatever content is included within a 1117 STATUS request. The Call-ID is allowed to be different from that in the 1118 original Call to allow STATUS requests from third parties. 1120 The successful response to a STATUS request is the last cached response 1121 that the Server returned to a Request that has the same global 1122 session ID, along with one or more Warning: headers (see 3.3.5 below) 1123 to indicate the status of the ongoing or completed telephone call 1124 session. If there are no previously returned response within the 1125 server's cache, the server returns a "606 Not 1126 Acceptable" response with a Warning: header as follows: 1128 Warning: 4xx pint.acme.com Incompatible Session Description: Unknown Session ID. 1130 Note that within SIP, it is allowed that a client include within the 1131 request a "Location:" header to indicate the location of an associated 1132 SIP server. This is usually used to enable a callee to hang up calls or 1133 change the session description. A PINT client may use this facility to 1134 indicate the Location of an associated PINT server which 1135 is capable of receiving a STATUS request from the PINT server which 1136 serviced the client's original request. If a PINT client includes a 1137 Location: header within a request, the associated server indicated in 1138 the Location header SHOULD support receiving the STATUS request from the 1139 server to contain a Warning: line containing indication of 1140 the status of the telephone call service. This allows a client to 1141 receive ongoing status reports of a requested telephone call service 1142 without having to poll the server. 1144 Similarly, Warning: headers MAY be included within BYE requests to a 1145 server which had been previously indicated within a Location: header 1146 from a client (see 3.5.7 below). 1148 Thus in PINT, Warning headers: MAY be included in requests as well as 1149 responses. 1151 It is allowed to send a STATUS request about a particular Telephone 1152 Network Session after the Call has been destroyed via a 1153 BYE message. If the Server no longer has a record of the session, it 1154 returns "606 Not Acceptable", along with the appropriate Warning: header 1155 indicating that the SDP session ID is no longer valid. 1157 This allows a client to discover the status of a telephone call service 1158 long after the service has completed. For example, one might want to 1159 check the next day that the fax was indeed sent the previous night at 1160 1:00 AM. There is no minimum time that a server is required to 1161 retain status of any particular session. Under normal SIP rules, as long 1162 as no BYE has been sent, the PINT server is part of the PINT session, 1163 and it should retain status of the call. A server can return an 1164 Expires: header within any response to INVITE to indicate for how long 1165 it will cache the result. 1167 To summarise, the status Warning: lines can be included in any response, 1168 and can also be included with a STATUS or BYE request in the special 1169 case when these requests are being sent to a server which was 1170 indicated in the "Location:" line within a previous PINT request. 1172 [??? This is very close to Henning's and Jonathan's 1173 NOTIFY request. We should decide on a single name. The main differences 1174 are that STATUS can be client-->server or server-->client, and any old 1175 client can issue a STATUS request to get an update on what is going on 1176 with the session]. 1178 3.5.4 Require header for PINT 1180 PINT clients use the Require: header to signal to the PINT server that a 1181 certain PINT extension of SIP is required. (SIP ensures that a PINT 1182 server which does not understand the Require: 1183 org.ietf.pint.XXX header will return a 420 Bad Extension response, 1184 and list the unsupported option within an Unsupported: header) PINT 1.0 1185 defines three strings that can go into the Require header: 1187 org.ietf.pint.STATUS -- the server can respond to STATUS requests 1188 (section 3.5.3) 1190 org.ietf.pint.Warning -- the server can return the new PINT Warning 1191 headers to indicate the status of requests 1192 (section 3.5.2) 1194 org.ietf.pint.strict -- the PINT server (or the SDP parser associated 1195 to it) understands the "strict" attribute 1196 defined in (section 3.4.5) 1198 Example: org.ietf.pint.STATUS,org.ietf.pint.Warning 1200 [???? Should we define these tags a org.ietf.mmusic.sip tags??] 1202 The specification of separate tags for each feature allows a client to 1203 require individual PINT features independently. For example, a client 1204 may wish to receive a Warning if the server cannot understand one of 1205 several alternative image formats offered, but apart from this may have 1206 no need for the STATUS request. 1208 A client should only include a Require: header if it really wishes the 1209 Server to fail the request in case the option is not supported. If the 1210 client merely "desires" that the feature is available, but is willing to 1211 accept service from a Server without the PINT feature, the client should 1212 not include the Require: header. PINT servers MUST give Warnings for SIP 1213 headers and elements of the session description that they do not 1214 understand. 1216 3.5.5 PINT URLS within PINT requests 1218 URLs are used within the Request-URI and certain SIP headers (such as 1219 To: and From:). The Request-URI within a SIP request refers to the 1220 service or user that services the request. Normally the hostnames and 1221 domain names that appear in the PINT URLs are the internal affair of 1222 each individual PINT system. A client uses the appropriate SDP payload 1223 to indicate the particular service it wishes to invoke; it is not 1224 necessary to use a particular URL to identify the service, although 1225 there are several advantages to doing so: 1227 a. if the SDP payload is encrypted it may not be possible for the 1228 PINT system to use SDP information to route the request; 1229 b. doing so may speed up processing by helping to route requests 1230 for a particular service to a particular PINT gateway; 1231 c. It enables multiple competing PINT gateways to REGISTER with 1232 a single "broker" server (proxy or redirect) (see section 3.5.8) 1233 d. When the provider of the actual telephone network session is 1234 separate from the provider of the PINT system, it may be important to 1235 indicate the names of the two providers in a machine readable fashion, 1236 for example, to enable equal access to other operator's services. 1238 For these reasons, it is suggested that Request-URI for PINT services 1239 should be of one of the following two forms: 1241 @ 1242 %@ 1244 MAY be one of the following three strings: 1246 R2T (for Request To Call) 1247 R2F (for Request To Fax) 1248 R2HC (for Request To Hear Content) 1250 The is an identifier (domain name or IP) of a 1251 Pint Server. 1253 The is an identifier (domain name or IP) of 1254 a server that can provide service inside the Telephone System. 1256 It is customary for Telephone Network services to be identified by 1257 a number. It is RECOMMENDED that service providers use this number 1258 for the parameter. PINT implementations SHOULD NOT use a 1259 number as the parameter unless that number is in fact the 1260 identifier of some Telephone Network service within the domain of the 1261 Telephone Service Provider. This and future versions of this PINT 1262 specification SHALL NOT ever use a raw number as a service identifier. 1264 Thus, for example:- 1266 INVITE RTC@pint.pintservice.com SIP/2.0 1267 INVITE R2F%telco.com@pint.pintservice.com SIP/2.0 1268 INVITE R2HC%pbx23.mycom.com@pint.mycom.com SIP/2.0 1269 INVITE 13@pint.telco.com SIP/2.0 1271 Since such URLs are not strictly necessary for interoperability, 1272 they are only recommendations, and not mandatory. See section 3.5.8 1273 for some related considerations concerning registrations by 1274 competing PINT systems to a single PINT proxy server acting as a 1275 service broker. 1277 3.5.6 Telephony Network Parameters within PINT URLs 1279 Any legal SIP URL can appear as a PINT URL within the Request-URI or To: 1280 header of a PINT request. But if the address is a telephone address, we 1281 saw in section 3.4.4 we saw that it may be necessary to include 1282 more information in order to correctly identify the remote telephone 1283 terminal or service. PINT clients MAY include these attribute tags 1284 within PINT URLs if they are necessary or useful to complement the 1285 telephone number within the SIP URL. These attribute tags MUST be 1286 included as URL parameters as defined in [ ] (i.e. in the semi-colon 1287 separated manner). 1289 The following is an example of a PINT URL which contains extra attribute tags: 1291 sip:+97252288088@host.org;a=strict:Q763-nature,Q763-plan;a=Q763-nature:3;a=Q763-plan:2 1293 As we noted in section 3.4.4, these extra attribute parameters SHOULD 1294 NOT normally be needed within a URL, because there is a great deal of 1295 context available to the help the server interpret the phone number 1296 correctly. In particular, there is the SIP URL within the To: header, 1297 and there is also the Request-URI. In most cases this provides 1298 sufficient information for the telephone network. 1300 The SDP attributes defined in 3 above SHOULD ONLY be used when they are 1301 needed to supply necessary context to identify a telephone terminal. 1303 Note that the terminal with this SIP URL is the same as the one whose 1304 connection is defined by the following part of an SDP description: 1306 c= TN RFCxxxx +97252288088 1307 a=strict:Q763-nature,Q763-plan 1308 a=Q763-nature:3 1309 a=Q763-plan:2 1311 3.5.7 BYE requests in PINT 1313 The semantics of BYE requests within PINT requires some extra precision. 1315 The BYE request [ ] is used within Internet Conferences to indicate that 1316 the originating entity no longer wishes to be involved in the specified 1317 call. Normally, a BYE request is a request to terminate the call and 1318 the media session. Thus according to the usual SIP semantics, if a PINT 1319 client made a request have a telephone call made from telephone A to 1320 telephone B, a BYE request from the client, if accepted, should result 1321 in a termination of the phone call. 1323 Note that the Telephone Call might not have even started at the time 1324 when the BYE request is received. For example, if a request to fax is 1325 sent with a t= line indicating that the fax is to be sent tomorrow at 1326 04:00AM, the requestor might wish to cancel the request before the 1327 specified time. A second problem is that it may not be possible to 1328 terminate the media session on the telephone system side. For example, 1329 the fax call may be in progress when the BYE arrives, and perhaps it is 1330 just not possible to cancel a fax in session. A third problem is that 1331 the entire telephone-side service might be completed before the BYE is 1332 received. In the above Request-To-Fax example, the BYE might be sent the 1333 following morning, and the entire fax has been sent before the BYE was 1334 received. 1336 In the case where the telephone network cannot terminate the media 1337 session, or it has already completed when the BYE is received, the 1338 server MUST include a Warning: header to indicate the status of the 1339 telephone session. Even if the PINT server can cancel the Telephone 1340 Network session, it SHOULD include a Warning: message indicating that 1341 the Telephone Session has been cancelled. 1343 Examples of such Warnings: are 1345 Warning: 502 pint.acme.com Telephone Call is still in session: Hang 1346 up the Phone!!! 1348 Warning: 504 pint.acme.com 3.6 Fax Service sent 3 of 6 pages 1350 Warning: 503 pint.acme.com 04:03 EST 3-12-98 Fax Service Completed Successfully 1352 If the client knows that it wishes to send STATUS requests at some point 1353 in the future, it MUST NOT send a BYE request, since a BYE requests ends 1354 the PINT association between the two parties, and the server might clear 1355 all knowledge of the call upon receipt of a BYE. The PINT server may use 1356 the Expires: header within the response to the BYE to indicate for how 1357 long it will be able to answer future STATUS messages. The PINT server 1358 MUST keep the response to the BYE cached at least as long as indicated 1359 within a Expired: header, of course. 1361 It is possible that some other client may send a STATUS request about a 1362 particular PINT session even after the original PINT requestor sent a 1363 BYE and ended the session. This allows a third party to check up on the 1364 status of the transmission long after the PINT transaction is completed. 1365 There is just no guarantee that the PINT server will retain status of 1366 terminated PINT sessions (unless the PINT server indicated with an 1367 Expires: header that it will retain status for a period of time). 1369 If the original requesting PINT client included a Location: header in 1370 its request, Then the original responding PINT server may send a BYE 1371 request to this location, along with a Warning: header that includes the 1372 final status of the telephone call service. But a PINT server should be 1373 especially careful when sending such a BYE request. 1374 It may be that a PINT request was sent from 1375 a host, along with a Location header, but that the requesting host is 1376 shutdown when the telephone service is executed, so the host is not 1377 available at the Location: specified in the request to receive the PINT 1378 server's BYE. Normally a server would send a STATUS request to the 1379 server indicated within the Location: header, until such time as it is 1380 certain that a BYE request can be received. 1382 Note that the above scenarios make sense with ordinary Internet 1383 multimedia sessions, not just with telephone network sessions. 1384 The intent of these semantics for BYE requests between PINT 1385 clients and servers is to be consistent with their meaning in 1386 ordinary Internet Conferences. 1388 [???What happens in an ordinary SIP audio call? is it REQUIRED that the 1389 RTP stop transmitting when the BYE is sent and acknowledged? 1390 Since the SIP spec speaks about BYE as meaning the requestor is about 1391 to "hang-up the call", I assumed that this is correct. 1392 Or maybe the RTP can go on forever, it's just that after the SIP BYE, 1393 the RTP transmission is no longer within the context of a session.] 1395 3.5.8 REGISTER requests within PINT 1397 A PINT gateway is a SIP user agent server, and user agent services 1398 use the REGISTER request to tell a proxy or redirect server that 1399 it is available to "receive calls" -- i.e. to service requests. 1400 In the case of PINT, the Server is registering the service 1401 that is accessible via itself rather than a user registering presence at 1402 a particular SIP Server. 1404 There may be competing PINT servers which can offer the same 1405 PINT service trying to register at a single PINT server. The PINT 1406 server might act as a "broker" among the various PINT gateways which 1407 can fulfil a request. A format for PINT URLs was specified in section 1408 3.5.5 that enables independent PINT systems to REGISTER an offer to 1409 provide the same service. The registrar can apply its own mechanisms and 1410 policies to decide what to respond to INVITEs from 1411 clients seeking service. (See section 6.3 for some possible deployment 1412 options) There is no change between SIP and PINT REGISTER semantics or syntax. 1414 Of course, the information in the PINT URLs within the REGISTER request 1415 may not be sufficient to completely define the service that a gateway 1416 can offer. The use of SIP and SDP within PINT REGISTER requests to 1417 enable a gateway to specify general services it can offer is the subject 1418 of future study. 1420 [??? The obvious solution is to use wildcards (say *, !, etc.) and 1421 comma separated multiple parameters within the 1422 SDP descriptions in the REGISTER request to indicate phone numbers, 1423 attributes, etc. which can be serviced from the registering PINT gateway. 1424 Do we need to do this in PINT 1.0??? I fear we do???] 1426 4. Examples of PINT Requests and Responses 1428 [???examples need to include some complete transactions, including responses, 1429 not just requests!!] 1431 4.1 A request to a call centre from an anonymous user to receive a phone 1432 call about a Sale on Ironing Boards 1434 C->S: INVITE marketing@pint.mailorder.com SIP/2.0 1435 Via: SIP/2.0/UDP 169.130.12.5 1436 From: anon-1827631872@chinet.net 1437 To: 1-800-IRON-YES 1438 Call-ID: 19971205T234505.56.78@chinet.net 1439 Subject: Sale on Ironing Boards 1440 Content-type: application/sdp 1441 Content-Length: ... 1443 v=0 1444 o=- 53655765 2353687637 IN IP4 128.3.4.5 1445 i=Ironing Board Promotion 1446 c= TN RFCxxxx +1-201-406-4090 1447 m=audio 0 voice 1449 In this example, the context which is required to interpret the To: 1450 address as a telephone number is not given explicitly; it is implicitly 1451 known to the marketing@pint.mailorder.com server. But the telephone of 1452 the person who wishes to receive the call is explicitly identified as an 1453 internationally significant E.164 number within the North American 1454 numbering plan (because of the "+1" within the c= line). 1456 4.2 A request from a non anonymous customer (John Jones) to receive a 1457 phone call from a particular sales agent (Mary James) concerning the 1458 defective ironing board that was purchased: 1460 C->S: INVITE marketing@pint.mailorder.com SIP/2.0 1461 Via: SIP/2.0/UDP 169.130.12.5 1462 From: john.jones.3@chinet.net 1463 To: mary.james@mailorder.com 1464 Call-ID: 19971205T234505.56.79@chinet.net 1465 Subject: Defective Ironing Board - want refund 1466 Content-type: application/sdp 1467 Content-Length: ... 1469 v=0 1470 o=- 53655765 2353687637 IN IP4 128.3.4.5 1471 c= GSTN E163 +1-201-406-4090 1472 m=audio 0 voice 1474 (The To: line might include the Mary James's phone number instead of a 1475 email-like address.) 1477 Note that such a telephone call service could be 1478 implemented on the phone side with different details. For example, it 1479 might be that first the agent's phone rings, and then the customer's 1480 phone rings, or it might be that first the customer's phone rings and he 1481 hears silly music until the agent comes on line. If necessary, such 1482 service parameter details might be indicated in "a=" attribute lines 1483 within the session description. The specification of such attribute 1484 lines for service consistency is beyond the scope of the PINT 1.0 1485 specifications. 1487 4.3 A request from the same user to get a fax back on how to assemble 1488 the Ironing Board 1490 C->S: INVITE faxback@pint.mailorder.com SIP/2.0 1491 Via: SIP/2.0/UDP 169.130.12.5 1492 From: john.jones.3@chinet.net 1493 To: 1-800-FAXBACK 1494 Call-ID: 19971205T234505.66.79@chinet.net 1495 Content-type: application/sdp 1496 Content-Length: ... 1498 v=0 1499 o=- 53655768 2353687637 IN IP4 128.3.4.5 1500 c= TN RFCxxxx 1-201-406-4091 1501 a=Q763-nature:3 1502 m=application 0 fax URI 1503 a=fmtp:URI http://localstore/Products/IroningBoards/2344.html 1505 In this example, the fax to be sent is stored on some local 1506 server (localstore), whose name may be only resolvable, or which may 1507 only be reachable, from within the IP network on which the PINT server 1508 sits. The phone number to be dialled is a "local phone number" as well. 1509 The Q763-nature was added to further identify the number as a nationally 1510 significant number. There is no "phone-context" attribute, so the 1511 context (in this case, for which nation the number is "nationally 1512 significant") must be supplied by the faxback@pint.mailorder.com PINT 1513 server. If the server which receives does not understand the number, it 1514 should fail the request with and include a "Network Address Not 1515 Understood" warning. Note that no "strict" attribute was used here, 1516 since it is very likely that the request can be serviced even by a 1517 server which does not support the "strict" attribute. 1519 4.4 A request from same user to have that same information read out 1520 over the phone 1522 C->S: INVITE faxback@pint.mailorder.com SIP/2.0 1523 Via: SIP/2.0/UDP 169.130.12.5 1524 From: john.jones.3@chinet.net 1525 To: 1-800-FAXBACK 1526 Call-ID: 19971205T234505.66.79@chinet.net 1527 Content-type: application/sdp 1528 Content-Length: ... 1530 v=0 1531 o=- 53655768 2353687637 IN IP4 128.3.4.5 1532 c= TN RFCxxxx +1-201-406-4090 1533 m=application 0 voice URI 1534 a=fmtp:URI http://localstore/Products/IroningBoards/2344.html 1536 4.5 A request to send a text page to a friend's pager. The text to be 1537 paged out is included in the request. 1539 C->S: INVITE pages@pint.herpager.com SIP/2.0 1540 Via: SIP/2.0/UDP 169.130.12.5 1541 From: scott.petrack@chinet.net 1542 To: text@pint.herpager.com 1543 Call-ID: 19974505.66.79@chinet.net 1544 Content-Type: multipart/mixed; boundary=--next 1546 --next 1547 Content-Type: application/sdp 1548 Content-Length: ... 1549 v=0 1550 o=- 53655768 2353687637 IN IP4 128.3.4.5 1551 c= TN RFCxxxx +972-9-956-1867 1552 m=text 0 pager plain 1553 a=fmtp:plain 2@53655768 1555 --next 1556 Content-Type: text/plain 1557 Content-ID: 2@53655768 1558 Content-Length: ... 1560 Hi Joe! Please call me asap at 555-1234. 1562 --next 1564 4.6 A request to send an image as a fax to phone number +972-9-956-1867; 1566 C->S: INVITE faxserver@pint.vocaltec.com SIP/2.0 1567 Via: SIP/2.0/UDP 169.130.12.5 1568 From: scott.petrack@chinet.net 1569 To: faxserver@pint.vocaltec.com 1570 Call-ID: 19971205T234505.66.79@chinet.net 1571 Content-type: application/sdp 1572 Content-Length: ... 1574 v=0 1575 o=- 53655768 2353687637 IN IP4 128.3.4.5 1576 c= TN RFCxxxx +972-9-956-1867 1577 m=image 0 fax tif gif 1578 a=fmtp:tif http://petrack/images/tif/picture1.tif 1579 a=fmtp:gif http://petrack/images/gif/picture1.gif 1581 The image is available as tif or as jpeg. The tif is the preferred 1582 format. Note that the http server where the pictures reside is local, 1583 and the PINT server is also local (because it can resolve machine 1584 name "petrack") 1586 4.7 A request to read out over the phone two pieces of content in 1587 sequence. First some included text is read out by text-to-speech. Then 1588 some text which is stored at some URI on the internet is read out. 1590 C->S: 1591 INVITE switchboard@pint.acme.com SIP/2.0 1592 Via: SIP/2.0/UDP 169.130.12.5 1593 From: scott.petrack@chinet.net 1594 To: voice_server@pint.acme.com 1595 Call-ID: 19974505.66.79@chinet.net 1596 Content-Type: multipart/mixed; boundary=next 1598 --next 1599 Content-Type: application/sdp 1600 Content-Length: ... 1601 v=0 1602 o=- 53655768 2353687637 IN IP4 128.3.4.5 1603 c= TN RFCxxxx +1-201-406-4091 1604 m=text 0 voice plain 1605 a=fmtp:plain 2@53655768 1606 m=text 0 voice plain 1607 a=fmtp:plain http://www.mymachine.com/texts/mytext.doc 1609 --next 1610 Content-Type: text/plain 1611 Content-ID: 2@53655768 1612 Content-Length: ... 1614 Hello!! I am about to read out to you some text stored on my 1615 Web Site. Let me know how it sounds over acme.com's new speech synthesis 1616 server. 1617 --next 1619 4.8 Interaction with a Proprietary IVR-based FaxBack System 1621 This example is intended to show how PINT systems can be "bolted on" to 1622 existing Telephone System servers, such as "Intelligent Peripherals". 1623 We consider an IVR-based (i.e. DTMF-driven) fax back system. Users 1624 normally call up the system from a Fax machine, type in some DTMF digits 1625 to identify the fax they want to receive, and then hit the "Receive" 1626 button on their fax machines. The FaxBack system retrieves the fax from 1627 storage and sends it out to the machine. 1629 The faxes are stored on some "Intelligent Peripheral" inside the 1630 Telephone Network. The server might be owned by some Telephone Service 1631 Operator, which runs a FaxBack service for many business customers. The 1632 faxes are identified by some customer code and the document code of the 1633 fax. At present customers call in from a fax machine and send DTMF tones 1634 to indicate the document code they wish to receive. Unfortunately the 1635 documents are not identified by URIs (the server is not quite 1636 "intelligent" enough to understand a URI...). It is desired to use 1637 identifiers that are identical to the current customer code and document 1638 code identifiers that customers now use when they dial in for the 1639 faxback service. Here is one way to accomplish this, using a proprietary 1640 "format" code to indicate the format of the fax to be sent. 1642 C->S: INVITE ivrfax@pint.operator.net SIP/2.0 1643 Via: SIP/2.0/UDP 169.130.12.5 1644 From: scott.petrack@chinet.net 1645 To: faxes@pint.vocaltec.com 1646 Call-ID: 19971205T234505.66.79@chinet.net 1647 Content-type: application/sdp 1648 Content-Length: ... 1650 v=0 1651 o=- 53655768 2353687637 IN IP4 128.3.4.5 1652 c= GSTN E163 +972-9-956-1867 1653 m=application 0 fax X-ivr.operator.net 1654 a=fmtp:X-ivr.operator.net 35.1234 1656 The operator has defined X-ivr.operator.net as a proprietary MIME sub- 1657 type of MIME type application. This MIME sub-type is defined as a 1658 concatenation of the customer code, followed by a period, followed by 1659 the DTMF code of the fax to be transported. It is of course possible to 1660 register the MIME sub-type with IANA, if there is a desire to have 1661 interoperability of this form of identification among different vendors. 1663 5. Security Considerations 1665 [??? There is some preliminary text, including some of the 1666 "responsibility" stuff of Steve. will get to it after the deadline 1667 I'm afraid] 1669 [??? It seems to me that SIP security mechanisms seem adequate 1670 to the task, except that decent text needs to be written on such 1671 topics as how to use those mechanisms to avoid fraud, trace malicious/ 1672 nuisance requests, etc. Some mention must be made as well of third party 1673 authorisation, such as when a corporate PBX allows person A to make 1674 long distance calls, but not person B] 1676 [??? The basic mechanisms are to be able to both digitally 1677 sign and encrypt payloads. Certificates will be used. The certificates 1678 contain the identity of the certificate authority, and this can be used 1679 as a back end service to authorise the execution of the PINT service. 1681 [???lwc -- Security considerations for REGISTER: 1682 For example, what's to stop any provider from registering as 1683 "R2T%att.com"? It should be possible to require authentication 1684 authentication of the request, it is indeed 1685 possible for someone to want to register themselves as "R2T%att.com" 1686 or even to override all 1687 other registrations for "R2T". (by attempting such a registration with a 1688 "zero time" Expiry header).] 1690 6. Deployment considerations and the Relationship PINT to IN 1692 6.1 Web Front End to PINT Infrastructure 1694 In practice, there are not (currently) many PINT Clients. It is likely 1695 that some other protocol will be used to communicate a Requesting User's 1696 requirements. Due to the high numbers of available Web Browsers and 1697 servers it seems likely that some PINT systems will use HTML/HTTP as a 1698 "front end". In this scenario, HTTP will be used over a connection from 1699 the Requesting User's Web Browser (WC) to an Intermediate Web Server 1700 (WS). This will be closely associated with a PINT Client (using some 1701 unspecified mechanism to transfer the data from the Web Server to the 1702 PINT Client). The PINT Client will represent the Requesting User to the 1703 PINT Server, and thus to the Executive System that carries out the 1704 required action. 1706 [WC]------[WS] 1707 [PC] 1708 \ 1709 \ 1710 [PS] 1711 [XS] 1713 6.2 Redirects to Multiple Servers 1715 It is quite possible that a given PINT Server is associated with an 1716 Executive System (or systems) that can connect to the GSTN at different 1717 places. If there is a chain of PINT Servers, then equally each of these 1718 Servers may be able to route PINT requests to Executive Systems that 1719 connect at specific points to the GSTN. The result of this is that there 1720 may be more than one PINT Server or Executive System that can deal with 1721 a given request. The mechanisms by which the choice on where to deliver 1722 a request are outside the scope of this document. 1724 However, there do seem to be two approaches. Either a Server that acts 1725 as a proxy or redirect will select the appropriate server itself and 1726 will cause the request to be sent on accordingly, or a list of possible 1727 Locations will be returned to the Requesting User from which they can 1728 select their choice. 1730 In the SIP document, the implication is that, if a proxy cannot resolve 1731 to a single unique match for a request destination, then a response 1732 containing a list of the choices should be returned to the Requesting 1733 User for selection. This is not too likely a scenario within the normal 1734 use of SIP. However, within PINT, such ambiguity may be quite common; it 1735 implies that there are a number of possible providers of a given service. 1737 6.3 Competing PINT gateways REGISTERing to offer the same service 1739 With PINT, the registration is not for an individual but instead for a 1740 service that can be handled by a service provider. Thus, one can 1741 envisage a registration by the PINT Server of the domain telcoA.com of 1742 its ability to support the service R2T as "R2T@telcoA.com", sent to an 1743 intermediary server that acts as registrar for the "broker.telcos.com" 1744 domain from "R2T@pint.telcoA.com" as follows: 1746 REGISTER sip:@broker.telcos.com SIP/2.0 1747 To:sip:R2T@pint.telcoA.com 1748 From:R2T@pint.telcoA.com 1749 ... 1751 This is the standard SIP registration service. 1753 However, what happens if there are a number of different Service 1754 Providers, all of whom support the "R2T" service? Suppose there is a 1755 PINT system at domain "broker.com". 1756 PINT clients requesting a Request to Talk service from broker.com might 1757 be very willing to be redirected or proxied to any one of the various 1758 service providers which had previously registered with the registrar. 1759 And PINT servers might be interested in 1760 providing service for requests that did not specify the service provider 1761 explicitly, as well as those requests that were directed "at them". 1763 To enable such service, PINT servers would REGISTER at the broker PINT 1764 server registrations of the form: 1766 REGISTER sip:host@broker.com SIP/2.0 1767 To:sip:R2T@broker.com 1768 From:sip:R2T@pint.telcoA.com 1770 [??? if sip:R2T is a valid URL, I would rather that this appeared in 1771 the To: line] 1773 When several such REGISTER messages appear at the registrar, each 1774 differing only in the URL in the From: line, the registrar has many 1775 possibilities, e.g.: 1777 (i) it overwrites the prior registration for "R2T@broker.telcos.com" 1778 when the next comes in; 1779 (ii) it rejects the subsequent registration for "R2T@broker.telcos.com"; 1780 (iii) it maintains all such registrations. 1781 In this last case, on receiving an Invitation for the "general" service, 1782 either: 1783 (iii.1) it passes on the invitation to all registered service 1784 providers, returning a collated response with all acceptances, 1785 using multiple Location: headers, 1786 or 1787 (iii.2) it silently selects one of the registrations (using, for 1788 example, a "round robin" approach) and routes the Invitation and 1789 response onwards without further comment. 1790 (iv) may choose to not allow registrations for the "general" 1791 service, rejecting all such REGISTER requests. 1793 6.4 Relation to Intelligent Network and Public Network Standards 1795 The PINT profile for SIP and SDP is used to pass requests to Executive 1796 Systems, where the requests can be serviced. In the particular case when 1797 the Executive Systems are attached to Intelligent Network (I.N.) systems 1798 or other Public Network systems operation with these requires 1799 development work on protocols and functions to be carried 1800 within the GSTN (specifically within the I.N. systems). There are 1801 several groups responsible for developing standards on the operation 1802 (within the GSTN) of associated I.N. functions and protocols. PINT 1803 systems and GSTN systems operating as specified by other groups may well 1804 be part of the same overall system used to provide services, so it is 1805 useful to provide an overview of the relevant Telecommunications 1806 standards. 1808 6.4.1 ITU-T 1809 The International Telecommunications Union - Telecommunications 1810 standardisation sector (usually known as ITU-T) has a significant group 1811 working on the development of the Intelligent Network recommendations. In 1812 particular, Study Group 11 has responsibility for this task, and within 1813 it work is being carried out into the development of a new Distributed 1814 Functional Plane architecture (by SG11.4), and into new extensions to 1815 Intelligent Network Application Part (INAP) protocol to be used between 1816 units in an Intelligent Network configuration (SG11.22). 1818 Their current plan is for Internet requests to be supported in the 1819 Recommendations that are part of the "Capability Set 4" (IN-CS4) series. 1820 Work on IN-CS4 is intended to be complete by December 1999, and it seems 1821 likely that the profile proposed in this document can be used to deliver 1822 PINT requests into such a system. Assuming that work on the Internet 1823 Protocols and this profile will be complete before the CS4 development 1824 in the ITU-T, it can be fed into the work of those ITU-T groups, so 1825 helping compatibility. Note that this is an ITU-T problem, not one for 1826 the Internet community, but it is important to be aware of the 1827 standardisation context and how they may be used. 1829 6.4.2 ETSI 1830 ETSI (European Telecommunications Standards Institute) is the body with 1831 responsibility (within Europe) for taking ITU-T specifications and 1832 producing profiles that allow a high degree of interoperation of 1833 Telecommunications Networks. They have produced profiles for IN-CS1 and 1834 IN-CS2 INAP protocols (called "ETSI Core INAP"). The ETSI NA6 group has 1835 started working on Next-generation I.N. systems & extensions to Core- 1836 INAP for Internet support, and has produced contributions to the ITU-T 1837 work to ensure alignment of their efforts. 1839 6.4.3 ANSI 1840 The Telecommunications Standards body with particular interest in North 1841 America is ANSI (American National Standards Institute), and, within 1842 that body, the T1S1 group is concerned with Intelligent Network systems. 1843 On the "Support for Internet" question, there has been a trend for ideas 1844 from this body to be introduced into the appropriate ITU-T study groups. 1845 Thus, although there does not appear to be a separate development being 1846 carried out within ANSI, this is simply due to the fact that the ideas 1847 are passed directly on to ITU-T and influence the ITU-T documents in 1848 that way. 1850 6.4.4 Other Standards 1851 There are other groups working on related areas. For example, there are 1852 proposals within the IETF for development of Protocol Mapping gateways 1853 between the IP networks and networks carrying Signalling System Number 7 1854 (SS#7) messages, as are commonly used within Telecommunications 1855 Networks. In principle, protocol mapping can be to deliver a service 1856 request as well. This would appear to perform a similar task to that 1857 presented with the PINT profile. 1859 However, the degree of coupling between the states 1860 within the SS#7 network and that within the Internet-based Requestors is 1861 much greater when using direct protocol mapping. The end result may be 1862 the same, but the means by which that result is achieved differs. The 1863 thrust of the PINT profile is to deliver the "intent" of a customer's 1864 request towards an Executive System on the GSTN, whilst the other 1865 approach ties the lower level semantics (or even the syntax) of the 1866 request to that used on the GSTN. 1868 PINT fits telephone-network-based multimedia conference set-up into the 1869 larger context of general multimedia conference set-up, rather than into 1870 the context of telephone network protocols. 1872 PINT is designed to deliver requests without the use of direct protocol 1873 mapping to Intelligent Network Application Part (INAP) 1874 messages. It could equally be used where the Executive System was not 1875 associated with an SS#7 network. This allows implementations to be 1876 developed relatively easily; an SS#7 network is not required to 1877 implement or deploy PINT. Also, it makes PINT development and 1878 standardisation orthogonal to any Intelligent Network standardisation; 1879 development of protocol mappings between IP networks and GSTN 1880 Telecommunications Signalling Networks are intimately dependent on the 1881 GSTN signalling standards. 1883 6.5 Relation between PINT Milestone services and ITU-T Q.1231 1885 [[[??? Q.1231 is a *draft* document. If we include this section, 1886 it must say that details may change] 1888 There are services descriptions made in the ITU-T which are similar to 1889 the PINT milestone services, and the relationship between the two 1890 descriptions is discussed here. After this, a description is given of 1891 the parameters that will be transferred from a Requestor to the eventual 1892 PINT Server that is associated with an Executive System that performs 1893 the ITU-T service. Finally, an example of the way in which these 1894 parameters might be included in messages fitting the PINT profiles for 1895 SIP and SDP is given. 1897 6.5.1 PINT Services 1899 The ITU-T Intelligent Network Outline Service Definitions for Capability 1900 Set 3 (the next development phase in the Intelligent Network) are 1901 included in the ITU-T draft document Q.1231 [11]. This document includes 1902 descriptions of four services initially identified by the PINT Working 1903 Group and that are taken as "benchmarks" for the PINT profiles of SIP 1904 and SDP. These services are: Click-to-Dial-Back, Click-to-Fax, Click-to- 1905 Fax-Back and (Internet-Initiated) Voice-Access-to-Content. 1907 Within the ITU-T definitions below, note that the word "click" should 1908 not be taken literally. It is rather used to point out that initiation 1909 of the related services takes place on the Internet, where point and 1910 click are the most prevalent user actions. In other words, a service 1911 request could originate from any type of IP-based platforms. There is no 1912 implication that these services must be implemented by a device within 1913 the PSTN or the Internet running a Web server. 1915 The common denominator of the PINT services is that they combine the 1916 Internet and PSTN services in such a way that the Internet is used for 1917 non-voice interactions, while the voice (and fax) are carried entirely 1918 over the PSTN. 1920 6.5.1.1 Click-to-Dial-Back (CTDBC) 1922 With this service, a user requests (through an IP host) that the PSTN 1923 call be established between another party and himself or herself. An 1924 important pre-requisite for using this service is that the user has 1925 simultaneous access to both the PSTN and Internet. 1927 6.5.1.2 Click-to-Fax (CLTFA) 1929 With this service, a user at an IP host requests that a fax be sent to a 1930 particular fax number. In particular this service is especially meaningful when the fax is to be sent to someone who has only a fax 1931 machine (but no access to the Internet). 1933 6.5.1.3 Click-to-Fax-Back (CLTFB) 1935 With this service, a user at an IP host can request that a fax be sent 1936 to him or her. 1938 6.5.1.4 (Internet-Initiated) Voice-Access-to-Content (VATCI) 1940 With this service, a user at an IP host requests that certain 1941 information on the Internet be accessed (and delivered) in an audio form 1942 over the PSTN, using the telephone as an informational appliance. 1944 6.5.1.5 PINT vs. ITU-T service descriptions 1946 Within this profile, the service definitions have been specified in a 1947 more precise way, whilst still reflecting the services as described in 1948 the Draft Q.1231 document. Thus, Click-to-Dial-Back as described in the 1949 ITU-T document is a special case of the more general two-party Request- 1950 to-Talk service mentioned earlier in this profile, the Click-to-Fax and 1951 Click-to-Fax-Back are both cases of a Request-to-Fax, and the 1952 (Internet-Initiated) Voice-Access-To-Content ITU-T definition is called 1953 Request-to-Hear-Content. 1955 Within the ITU-T service descriptions there is an important difference 1956 between the Click-to-Fax-Back and Click-to-Fax service. In the "Fax" 1957 case the source document is sent 1958 from "the Internet" towards the PSTN. With the "Fax-Back" case, the 1959 source document is stored within "the PSTN" (and the Requesting User is 1960 implied to be the same as the destination party for the resulting 1961 service PSTN call). 1963 Also, the ITU-T Click-to-Dial-Back description given above implies that 1964 the Requesting User (as defined earlier in this document) is one of the 1965 parties to the resulting service PSTN call. We have chosen to use a more 1966 general description for the Request-to-Talk definition shown in section 1967 2 of this profile; the Click-to-Dial-Back description is a pure subset 1968 of the Request-to-Talk service, in which the Requesting User role is 1969 shared by the same person as one of the parties to the PSTN call. 1971 6.5.2 Parameters needed for PINT Services 1973 This section describes how parameters specified by ITU-T Q.1231 can be 1974 carried within PINT requests. 1976 6.5.2.1 Service Identifier 1978 When a Requesting User asks for a service to be performed, they will, of 1979 course, has to specify which service in some way. This can be done 1980 within the URLs within the To: header and the Request-URI (see ) 1982 6.5.2.2 A and B parties 1984 With the "Request-to-Talk" service, they will also need to specify the A 1985 and B parties they want to be engaged in the resulting service call. The 1986 A party could identify, for example, the Call Centre from which they 1987 want a call back, whilst the B party is their telephone number (i.e. who 1988 the Call Centre agent is to call). 1990 With the "Request-to-Fax-Back" service, they will also have specify two 1991 parties. As before, the B party is the telephone number of the fax 1992 machine to which they want a fax to be sent. However, within Q.1231 the 1993 A party identifies the "document context" for the PSTN-based document 1994 store from which a particular document is to be retrieved; the analogy 1995 here is to a PSTN user dialling a particular telephone number and then 1996 entering the document number to be returned using "touch tone" digits. 1997 The telephone number they dial is that of the document store or A party, 1998 with the "touch tone" digits selecting the document within that store. 2000 The "Request-to-Fax" and "Request-to-Hear-Content" services require the 2001 B party to be specified (respectively the telephone number of the 2002 destination Fax machine or the telephone to which spoken content is to 2003 be delivered), but the A party is a Telephone Network based resource 2004 (either a Fax or speech transcoder/sender), and is implicit; the 2005 Requesting User does not (and cannot) specify it. 2007 6.5.2.3 Other Service Parameters 2009 In terms of the extra parameters to the request, the services again 2010 differ. The "Request-to-Talk" service needs only the A and B parties. 2011 Also it is convenient to assert that the resulting service call will 2012 carry voice, as the Executive System within the destination GSTN may be 2013 able to check that assertion against the A and B party numbers specified 2014 and may treat the call differently. 2016 The "Request-to-Fax-Back" service needs to specify the Document Store 2017 number and the Fax machine number to which the information is to be 2018 delivered. It is convenient to assert that the call will carry Fax data, 2019 as the destination Executive System may be able to check that assertion 2020 against the document store number and that of the destination Fax 2021 machine. 2023 In addition, the document number may also need to be sent. This 2024 parameter is an opaque reference that is carried through the Internet 2025 but has significance only within the GSTN. The document store number and 2026 document number together uniquely specify the actual content to be 2027 faxed. 2029 With the "Request-to-Fax" and "Request-to-Hear-Content" services, the 2030 source information to be transcoded is held on the Internet. That means 2031 either that this information is carried along with the request itself, 2032 or that a reference to the source of this information is given. In 2033 addition, it is convenient to assert that the service call will carry 2034 fax or voice, and, where possible, to specify the format for the source 2035 information. 2037 6.5.2.4 Service Parameter Summary 2039 The following table summarises the information needed in order to 2040 specify fully the intent of a service request. Note that it excludes any 2041 other parameters (such as authentication or authorisation tokens, or 2042 Expires: or CallId: headers) that may be used in a request. 2044 Service ServiceID AParty BParty CallFmt Source SourceFmt 2045 ------- --------- ------ ------ ------- ------ ------- 2046 R2T x x x voice - - 2047 R2F x - x fax URI/IL ISF/ILSF 2048 R2FB x x x fax OR - 2049 R2HC x - x voice URI/IL ISF/ILSF 2051 In this table, "x" means that the parameter is required, whilst "-" 2052 means that the parameter is not required. 2054 The Call Format parameter values "voice" or "fax" indicate the kind of 2055 service call that results. 2057 The Source "URI/IL" implies either that the data is either an Internet 2058 source reference (a Universal Resource Identifier, or URI) or is carried 2059 "in-line" with the message. The Source indicator "OR" means that that 2060 the value passed is an Opaque Reference that should be carried along 2061 with the rest of the message but is to be interpreted only within the 2062 destination (GSTN) context. As an alternative, it could be given as a 2063 "local" reference with the "file" style, or even using a partial 2064 reference with the "http" style. However, the way in which such a 2065 reference is interpreted is a matter for the receiving PINT Server and 2066 Executive System; it remains, in effect, an opaque reference. 2068 The Source Format value "ISF/ILSF" means that the format of the source 2069 is specified either in terms of the URI or that it is carried "in-line". 2070 Note that, for some data, the format either can be detected by 2071 inspection or, if all else fails, can be assumed from the URI (for 2072 example, by assuming that the file extension part of a URL indicates the 2073 data type). For an opaque reference, the Source Format is not available 2074 on the Internet, and so is not given. 2076 6.5.3 Parameter Mapping to PINT Profile 2078 This section describes the way in which the parameters needed to specify 2079 a Q.1231 request fully might be carried within a PINT profile message. 2080 There are other choices, and these are not precluded. However, in 2081 order to ensure that the Requesting User receives the service that they 2082 expect, it is necessary to have some shared understanding of the 2083 parameters passed and the behaviour expected of the PINT Server and its 2084 attendant Executive System. 2086 The Service Identifier can be sent as the userinfo element of the 2087 Request-URI. Thus, the first line of a PINT Invitation would be of the 2088 form: INVITE @. SIP/2.0 2090 The A Party for the Request-To-Talk and Request-To-Fax-Back service can 2091 be held in the "To:" header field. In this case the "To:" header value 2092 will be different from the Request-URI. In the services where the A party 2093 is not specified, the "To:" field is free to repeat the value held 2094 in the Request-URI. This is the case for "Request-to-Fax" and "Request- 2095 to-Hear-Content" services. 2097 The B party is needed in all these milestone services, and can be held 2098 in the enclosed SDP sub-part, as the value of the "c=" field. 2100 The call format parameter can be held as part of the "m=" field value. 2101 It maps to the "transport protocol" element as described in section 2102 3.4.2 of this document. 2104 The source format specifier is held in the "m=", as a type and optional 2105 sub-type. The latter is required for all services except "Request-to- 2106 Talk". As shown earlier, the source format and source are not always 2107 required when generating requests for services. However, the inclusion 2108 in all requests of a source format specifier can make parsing the 2109 request simpler and allows for other services to be specified in the 2110 future, and so values are always given. The source format parameter is 2111 covered in section 3.4.2 as the "media type" element. 2113 The source itself is identified by an "a=fmtp:" field value, where 2114 needed. With the exception of the "Request-to-Talk" service, all 2115 invitations will include such a field. From the perspective of the SDP 2116 profile, it can be considered as qualifying the media sub-type, as if to 2117 say, for example, "when I say jpeg, what I mean is the following". 2119 In summary, the parameters needed by the different services are carried 2120 in fields as shown in the following table: 2122 Service Svc Param PINT/SIP or SDP field used Example value 2123 ------- --------- -------------------------- ------------- 2124 R2T 2125 ServiceID: R2T 2126 BParty: sip:123@p.com 2127 AParty: TN RFCxxxx 4567 2128 CallFormat: voice 2130 SourceFmt: audio 2132 (--- No media sub-type 2133 sub-field value used) --- 2134 Source: (--- No source specified) --- 2136 R2F 2137 ServiceID: R2F 2138 BParty: (--- ) sip:R2F@pint.xxx.net 2139 AParty: TN RFCxxx +441213553 2140 CallFormat: fax 2142 SourceFmt: image 2144 jpeg 2146 Source: a=fmtp:jpeg 2149 R2FB 2150 ServiceID: R2FB 2151 BParty: sip:1-730-1234@p.com 2152 AParty: TN RFCxxx +441213553 2153 CallFormat: fax 2155 SourceFmt: image 2157 X-OR 2159 Source: a=fmtp:X-OR 1234 2162 R2HC 2163 ServiceID: R2HC 2164 BParty: (--- SIP To: field not used) sip:R2HC@pint.ita.il 2165 AParty: TN RFCxxx +441213554 2166 CallFormat: voice 2168 SourceFmt: text 2170 html 2172 Source: a=fmtp:html 2175 7. Open Issues 2177 [All open issues are marked in the text above within square brackets and 2178 three question marks ???] 2180 [[??? lwc - Other Points to consider: 2181 (i) Who makes the decision on the PINT Server or Executive System that is 2182 offered any Invitation (where there is a possible choice)? 2183 (ii) What's the ->policy<- for that choice?, 2184 and: 2185 i) is it required to be auditable (i.e. one can prove that this policy 2186 has been carried out)? 2187 ii) is it required to be "fair" (and, if so, who decides what's "fair")? 2188 iii) Who or what sets policy for the decision?]]] 2190 8. References 2192 9. The authors wish to thank the members of the PINT working group for 2193 comments that were helpful to the preparation of this specification. In 2194 particular, Ian Elz's remarks about internal telephone network 2195 parameters was instrumental in the specification of section 3.5.6. 2197 10. Author's Addresses: 2199 Scott Petrack 2200 VocalTec Communications Ltd. 2201 1 Maskit Street 2202 Herzeliya 2203 46733 Israel 2204 petrack@vocaltec.com 2206 Lawrence Conroy 2207 Roke Manor Research 2208 lwc@roke.co.uk