Internet Engineering Task Force PINT WG INTERNET-DRAFT Scott Petrack draft-ietf-pint-profile-00.txt Lawrence Conroy 7 August 1998 Expires: 7 February 1998 The PINT Profile of SIP and SDP: a Protocol for IP Access to Telephone Call Services Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. Copyright Notice Copyright (c) The Internet Society (1998). All Rights Reserved Abstract This document contains the specification of the PINT Profile 1.0, which defines a protocol for invoking certain telephone services from an IP network. These services include placing basic calls, sending and receiving faxes, and receiving content over the telephone. The protocol is specified as a set of enhancements and additions to the SIP 2.0 and SDP 2.0 protocols. This document is intended for the PSTN-Internet Interworking (PINT) working group of the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at pint@lists.research.bell-labs.com and/or the authors. Contents 1. Introduction and Glossary 2. PINT Milestone Services 2.1 Request to Call 2.2 Request to Fax 2.3 Request to Hear Content 2.4 Relation between PINT Milestone Services and Standard Telephone Services 3. PINT Functional and Protocol Architecture 3.1 PINT Functional Architecture 3.2 PINT Protocol Architecture 3.3 REQUIRED and OPTIONAL elements for PINT compliance 3.4 PINT profile of SDP 2.0 3.4.1 Network Type "TN" and Address Type "RFCxxxx" 3.4.2 Media Types, Transport Protocol parameters, format parameters and format specific attributes for TN connected terminals 3.4.3 Format attributes for included content data 3.4.4 Attribute Tags to pass information into the Telephone Network 3.4.5 The "strict" attribute 3.5 PINT profile of SIP 2.0 3.5.1 Multi-part mime sending of data along with SIP request 3.5.2 Warning header 3.5.3 The STATUS request 3.5.5 PINT URLs within PINT requests 3.5.6 Telephone Network Parameters within PINT URLs 3.5.7 BYE requests in PINT 3.5.8 REGISTER requests in PINT 4. Examples of PINT Requests and Responses 4.1 A request from an anonymous user to receive a phone call from a Call Centre 4.2 A request from a non anonymous user to receive a phone call 4.3 A request to get a fax back 4.4 A request to have information read out over the phone 4.5 A request to send a text page to a user's pager. The text is included in the request. 4.6 A request to send an image as a fax to fax machine. 4.7 A request to read out over the phone two pieces of content in sequence. 4.8 Interaction with a Proprietary IVR-based FaxBack System 5. Security Considerations 6. Deployment considerations 6.1 Web Front End to PINT Infrastructure 6.2 Redirects to Multiple Servers 6.3 Competing PINT gateways REGISTERing to offer the same service 6.4 Relations to Intelligent Network and Public Network Standards 6.4.1 ITU-T 6.4.2 ETSI 6.4.3 ANSI 6.4.4 Other Standards 6.5 Relation between PINT Milestone services and ITU-T Q.1231 6.5.1 PINT Services 6.5.1.1 Click-to-Dial-Back (CTDBC) 6.5.1.2 Click-to-Fax (CLTFA) 6.5.1.3 Click-to-Fax-Back (CLTFB) 6.5.1.4 (Internet-Initiated) Voice-Access-to-Content (VATCI) 6.5.1.5 PINT vs. ITU-T service descriptions 6.5.2 Parameters needed for PINT Services 6.5.2.1 Service Identifier 6.5.2.2 A and B parties 6.5.2.3 Other Service Parameters 6.5.2.4 Service Parameter Summary 6.5.3 Q.1231 Parameter Mapping within PINT 7. Open Issues 8. References 9. Acknowledgements 10.Author's Addresses 1. Introduction The desire to invoke certain telephone call services from the Internet has been identified by many different groups (users, public and private network operators, call centre service providers, equipment vendors, etc.). The generic scenario is as follows (when the invocation is successful): 1. an IP host sends a request to a server on an IP network; 2. the server relays the request into a telephone network; 3. the telephone network performs the requested call service. One example is a user sending a request to have a call placed to his/her telephone. It may be that a customer wishes to get a call from the support department of some business, or a user wishes to hear some remote automatic weather service via recorded or synthesised speech. Within a local environment such a request might result in the placement of a call between employees over the internal PBX. We use the term "PINT Service" to denote such a complete transaction, starting with the sending a request from an IP client and including the telephone call service. ("PINT" is short for "Phone-IP Interworking Services"). A PINT service always involves the placement of a call within some Telephone Network. The original meaning of the acronym "PINT" was "PSTN-Internet Interworking", but the term has since been broadened to allow services which involve any type of circuit-switched telephone system, not just the "Public" Switched Telephone System. Private PBXs, cellular phone networks, and the ISDN can all be used to deliver PINT services. Also, the request for service might come from within a private IP network that is disconnected from the whole Internet. There is some overlap between PINT service requests and third-party call control. The requirements for the PINT protocol were deliberately restricted to providing the ability to invoke a small number of fixed telephone call services. These "Milestone PINT services" are specified in section 2. Great care has been taken, however, to develop a protocol that fits into the emerging Internet Conference Architecture [], so that future extensions to PINT could develop along with Internet Conferencing. Within the Internet Conference Architecture, establishing media calls is done via a combination of protocols. SIP [ ] is used to establish the association between the participants within the call (this association between participants within the call is called a "session"), and SDP [ ] is used to describe the media to be exchanged within the session. The PINT protocol uses these two protocols, providing some extensions and enhancements to enable SIP clients and servers to become PINT clients and servers. The underlying model of Internet Conference sessions is unchanged. The PINT user who wishes to invoke a service within the phone system uses SIP to invite a remote PINT server into a session. ("The user places a SIP call"). The invitation contains an SDP description of the media session that the user would like to take place. (This might be a "sending a fax session" or a "telephone call session", etc.) Acceptance of the invitation by the PINT server establishes a session between the client and server, during which the requested media can be sent. In a PINT session the media is transported over the phone system, while in a SIP session the media is normally transported over an internet. The particular requirements of PINT users lead to some new messages, however. For example, the fact that a server accepts an invitation and a session is established is no guarantee that the media will be successfully transported, neither in vanilla SIP nor in PINT. For example, a PINT server may accept to send a fax to telephone B, but it may be that the fax transmission fails after part of the fax is sent. Therefore, the PINT client needs to be able to receive information about the status of the actual telephone call session that was invoked as a result of the established PINT session. This requirement leads to a new STATUS request and to some new Warning: messages. We can summarise the relationship between PINT and SIP as follows: The invitation sequence (INVITE-OK-ACK) establishes a Internet Session between the PINT server and client. The request contains a description of the "telephone network media transport session" requested. The PINT server sends an OK to signal its agreement to establish a PINT session with the client. The actual transportation of media over the phone (a.k.a "the phone call") might happen hours or days after the establishment of the PINT call. Similarly, the phone call might complete long before any BYE is sent. As long as no BYE is sent, then the PINT session exists, and the client may request the STATUS of the session, or may even request to change a session parameter. Of course, it may be impossible to change the session parameters (for example, the fax may already have been totally or partially sent). The client sends a BYE to signal its desire to end the PINT call. Once the BYE is acknowledged, there is no longer any PINT association between the PINT client and server. A Warning: line is used within the response to the BYE to indicate the status of the telephone-side media transport session. Finally, at any point during the PINT session (and possibly even afterwards), a client may send a STATUS message to the PINT server to retrieve information about the telephone network session associated to the PINT request. The enhancements and additions specified here are not intended to alter the behaviour of baseline SIP or SDP in any way. The milestone PINT services fit seamlessly into the rest of the Internet Conference Architecture, and the PINT profile can be used to extend the usual SIP/SDP services to the telephone world. This is a great added benefit of using SIP/SDP as the protocol to invoke the PINT services. Apart from integrating well into existing protocols and architectures, and the advantages of reuse, this means that the protocol specified here can handle a rather wider class of call services than just the Milestone services. Some of the enhancements specified here (such as the use of multipart MIME) make sense in the context of a pure Internet Conference. The PINT profile has been designed so that each enhancement is independent of any other. SIP transactions that have nothing to do with telephone call services and telephone sessions should be able to use these enhancements. It is possible that these will become part of future versions of SIP and SDP. The rest of this document is organised as follows: Section 2 describes the original PINT Milestone services precisely; section 3 specifies the PINT functional and protocol architecture; section 4 specifies the new tags and headers in the PINT 1.0 profile of SIP and SDP; section 5 contains some security considerations for PINT. The final section contains some informative examples. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. In addition, the construct "MUST .... OR ...." implies that it is an absolute requirement of this specification to implement one of the two possibilities stated (represented by dots in the construct). An implementation MUST be able to interoperate with another implementation which chooses either of the two possibilities. 1.1 Glossary Requestor - An Internet Host from which a request for service originates PINT Service - A services invoked within a phone system in response to a request received from an PINT client. PINT Client - An Internet Host that sends requests for invocation a PINT Service, in accordance with this profile. PINT Server - An Internet Host that accepts requests for PINT Service and dispatches them onwards towards a telephone network. Executive System - A system which interfaces to a telephone network that executes a PINT service, and to a PINT Server. It is not directly associated with the Internet, and is represented by the PINT Server. Requesting User - The initiator of a request for service. This role may be distinct from that of the "party" to any telephone network call that results from the request. (Service Call) Party - A Person who is involved in a telephone network call that results from the execution of a PINT service request, or a telephone network-based resource that is involved (such as an automatic Fax Sender or a Text-to-Speech Unit). 2. Milestone Services 2.1 Request to Call A request is sent from an IP host which causes a phone call to be made, connecting party A to some remote party B. 2.2 Request to Fax A request is sent from an IP host that causes a fax to be sent to fax machine B. The request MUST EITHER contain a pointer to the fax data (which could reside in the IP network or in the Telephone Network), OR the request itself contain fax data. The content of the fax MAY be text or some other more general image data. The precise rendering of such data in a suitable form for the remote fax is outside the scope of PINT. 2.3 Request to Hear Content A request is sent from an IP host which causes a phone call to be made to user A. Then some sort of content is spoken out over this phone call. The request MUST EITHER contain a URL pointing to the content, OR alternatively contain the content itself. The content MAY be text or some other more general application data. The precise rendering of the content into speech over the phone is beyond the scope of this specification. (Although certain aspects of this rendering, such as language preference, can be expressed and are discussed in section 3). 2.4 Relation between PINT Milestone Services and "Standard" Telephone Services The above characterisations may seem to lack precision to those familiar with various telephone service definitions (see for example [ ], [ ], [ ]). This is because there are many different versions and variations of each telephone call service described above. Consider as an example what happens when a user requests to receive a call from 1-800-CALL-CTR via the PINT "Request to Call" service. There may be thousands of agents in the call centre, and there may be any number of sophisticated algorithms and equipment which is used to decide exactly which agent will return the call. Even once this choice is made, there may be many different ways to set up the call. The agent's phone might ring first, and only then the original user will be called. Or perhaps the user will be called first, and will hear some horrible music or pre-recorded message while the agent is located. PINT 1.0 reflects a deliberate decision to avoid specifying too closely the precise telephone-side service. Operational details of individual events within the telephone network that executes the request are outside the scope of PINT. Section 6.5.1 contains a description of the relationship between ITU-T telephone service standards and the PINT Milestone services. 3. PINT Functional and Protocol Architecture 3.1 PINT functional architecture Familiarity is assumed with SIP 2.0 [] and with SDP 2.0 []. PINT clients and servers are be SIP clients and servers. SIP is used to route the request over the IP network to the correct PINT server in a secure and reliable manner, and to communicate the status of outstanding requests. A PINT system may use proxy servers and redirect servers for their usual SIP purpose, but at some point there must be a PINT server with some means of relaying received requests into a telephone system, and also some means to receive acknowledgement of these relayed requests. A PINT server with this capability is called a "PINT gateway". A PINT gateway appears to a SIP system as a user agent server. So the PINT system might appear to an individual PINT client as follows: /\/\/\/\/\/\/\ /\/\/\/\/\/\/\/\ ___________ \ __/___ ___\_ \ | PINT | PINT \ PINT | PINT | |Exec| Telephone / | client |<--------->| server |gatewy|===|Syst| Network \ |_________| protocol / cloud |______| |____| Cloud / \ \ / \ /\/\/\/\/\/\/\ \/\/\/\/\/\/\/\/ Figure 1: PINT Functional Architecture The system of PINT servers is represented as a cloud to emphasise that a single PINT request might pass through a series of location servers, proxy servers, and redirect servers, before finally reaching the correct PINT gateway which can actually process the request by passing it to the Telephone Network Cloud. The PINT gateway might have a true telephone network interface (for example an analogue, PRI, or SS7 interface supporting DTMF, Q.SIG or ISUP), or it might be connected via some other protocol or API to an "Executive System" which is capable of invoking services within the telephone cloud). The distinction between the PINT gateway and the Executive System is a logical one; a single server may fulfil both functions. The communication between the PINT gateway and the Telephone Network Cloud via the Executive System is outside the scope of PINT. As an example, in an IN (Intelligent Networking) -enabled system, this might be done by means of an "Intelligent Peripheral" which is attached to both the IP network and the IN network. In an office environment, it might be accomplished by a server which is adjunct to the office PBX, connected to both the office PINT server and the office PBX. 3.2 PINT protocol architecture PINT uses SIP and SDP in combination to convey the required information about requests and responses. The SDP payload contains a description of the particular telephone call service which the requestor wishes to occur in the PSTN. The information contained in the session description includes such things as the TN address (i.e. the "telephone number") of the terminal(s) that should receive the call, an indication of the media type to be transported (e.g. audio, text, image or application data), and an indication if the information is to be transported over the TN via voice, fax, or pager transport. An indication of the content to be sent to the remote telephone terminal (if there is any) is also included. One advantage of using SDP is that the pieces of information are conveyed independently. For example, a request to send some text via voice transport will be fulfilled by invoking some text-to-speech-over- the-phone service, and a request to send text via fax will be fulfilled by invoking some text-to-fax service. The following is a list of PINT 1.0 enhancements and additions to SDP. a. A new Network Type "TN" and address types "RFCxxxx" and "X-..." (section 3.4.1) b. New media types "text", "image", and "application", the associated new protocol transport keywords "voice", "fax" and "pager" and the associated format types and attribute tags (section 3.4.2) c. New Format Specific Attributes for included content data (section 3.4.3) d. New attribute tags, used to pass information to the TN (section 3.4.4) e. A new attribute tag "strict", used by a client to indicate that some attribute is required to be supported in the server (section in 3.4.5) SIP is used to route the request for telephone service from the PINT client to the PINT gateway. The following is a complete list of PINT enhancements and additions to SIP: f. The multipart MIME payloads as specified (section 3.5.1) g. The "Warning:" header as specified (section 3.5.2) h. The STATUS request as specified (section 3.5.3) i. Require: headers for PINT clients (section 3.5.4) j. A format for PINT URLS within a PINT request (section 3.5.5) k. PINT URLs (section 3.5.6) l. The security mechanisms of section 5 for third party authentication. Section 3.5.7 contains remarks about how BYE requests are used within PINT, and section 3.5.8 contains remarks about how REGISTER requests are used within PINT. These do not change the behaviour of baseline SIP in any way; they are included here for clarification of the semantics when used with Telephone Network Sessions. 3.3 REQUIRED and OPTIONAL elements for PINT compliance PINT 1.0 clients MUST support the TN network type and the RFCxxxx address type. Servers MUST in addition support the STATUS method, "Warning: headers, and the "strict" attribute. The other new protocol elements are "conditionally mandatory". This means that each new PINT construct enables a different function, and a client or server which wishes to enable that particular function MUST do so by the construct specified in this document. However, there is no single PINT service that is required to be supported by all PINT clients or servers. For example, one can build a PINT client and server which only supports the Request-to-Call telephone call service, without support for the other Milestone services. In general, many optional features of SIP and SDP make sense as specified in the PINT context. An example is the SDP a=lang: attribute, which can be used to describe the preferred language of the callee. Another example is the use of the t= parameter to indicate that the time at which Telephone Call Service is to be invoked. Since the Session Description within the PINT request describes exactly the "telephone call session" to be invoked, this is simply the usual use of the t= field. A third example are the quality attributes. Any SIP or SDP option or facility is available to PINT clients and servers without change. 3.4 PINT profile of SDP 2.0 PINT 1.0 adds to SDP the possibility to describe audio, fax, and pager telephone sessions. It is deliberately designed to hide technical details of the telephone network. The only network type defined for PINT is the generic "TN" (Telephone Network). More precise tags such as "ISDN," "GSM," are not allowed. Similarly, the transport protocols MUST be one of "fax", "voice" and "pager"; there are no identifiers for the various TN fax protocols. The actual fax protocol negotiation will take place within the TN. The data to be transported is identified only as text data, image data, or some more general application data. An important example of transporting "application" data is the milestone service "Voice Access to Web Content". In this case the data to be transported is pointed to by a URI, the data type is application/URI, and the transport protocol would be "voice." Some sort of speech- synthesis facility, in the end speaking out to a Phone, will have to be invoked to perform the service. This section gives details of these new SDP keywords. 3.4.1 Network Type "TN" and Address Type "RFCxxxx" The TN ("Telephone Network") network type is used to indicate that the terminal is connected to a telephone network. The address types allowed for network type TN are "RFCxxxx" (the "xxxx" will be filled in by either the Telephony-URL RFC number or the SIP RFC number) and private address types, which MUST begin with an "X-". Address type RFCxxxx is a string conforming to the "telephone- subscriber" BNF specified in RFCxxxx, [, section x.y.z] Examples: c= TN RFCxxxx +1-201-406-4090 c= TN RFCxxxx 12014064090 A telephone-subscriber string is of one of two types: global-phone- number or local-phone-number. These are distinguished by the fact that a global-phone-number begins with a "plus" sign "+". A global-phone-number is by default to be interpreted as an internationally significant E.164 number, as defined by [ ]. A local-phone-number string is by default to be interpreted as belonging to an unknown numbering plan, as defined by [ ]. These defaults may be changed by the use of the attributes defined in section 3.4.5 below. An implementation MAY use private addressing types, which can be useful within a local domain. These address types MUST begin with an "X-", and SHOULD contain a domain name after the X-, e.g. "X- mytype.mydomain.com". An example of such a connection line is as follows: c= TN X-mytype.mydomain.com A*8-HELEN Note that most dialable telephone numbers are writeable as local-phone- numbers within address RFCxxxx; new address types should only be used for formats which cannot be so written. [??? Do we need an new address type which includes DTMF keys A, B, C and D???] 3.4.2 Media Types, Transport Protocol parameters, format parameters and format specific attributes for TN connected terminals In order to describe the media that can be transported to TN terminals within TN sessions, PINT 1.0 specifies the use of some new media types, transport protocol parameters, format parameters, and format specific parameters. This specification only applies when used with terminals connected via the "TN", although much of the semantic carry over without change to IN connected terminals as well. The media types within PINT 1.0 requests MUST be one of "audio", "image", "text" and "application." Note that each of these is a well- defined MIME type (see []). The port number for PINT terminals MUST be 0. The transport protocol keywords MUST be one of are "voice", "fax", and "pager." Within each request, the allowed format parameters are precisely the MIME sub-types of the MIME types that appear within the media type within the request. Format Specific Attributes are used to indicate the actual content to be transported to the remote terminal for example, when the remote telephone terminal is a fax machine or pager). Media type "audio" must only be used with transport protocol "voice." There are no defined format parameters. This indicates a TN terminal which wishes to receive an "plain old voice telephone call." As an example, the following excerpt from a session description describes a phone which is ready to receive an ordinary phone call at E.164 international phone number +12014064090: c= TN RFCxxxx +12014064090 m= audio 0 voice [???One could imagine a media description like "m= audio 0 fax wav" which would mean to "play a wav file out to a fax machine," for example via speech-to-text-to-fax. Do we need to mention this explicitly? Similarly with "m= audio 0 pager wave" for playing out audio files to a remote pager. These are not milestone services -- do we need to mention them specifically now? We could just include text allowing any MIME sub- type of the major type as an option] Media Type "image" MUST be used with EITHER transport protocol "fax" OR "pager". The allowed format parameters are any MIME subtype of MIME type image (see []). The format specific attribute "a=fmtp:<fmt> <URIs>" MAY be used to include a URI which points to the image data to be sent to the remote TN terminal (see section 3.2.3 below). Alternatively, the format specific attribute "a=fmtp:<fmt> <Content-ID>" MAY be used to indicate that image data is included within the PINT request itself, within a multipart MIME part. (see section 3.4.3 below). When the protocol is "fax," the image is to be transported over the TN to a remote fax machine. And when the protocol is "pager" the image is to be transported over the TN to some remote pager machine. [??As before, One could easily imagine a media description like "m= image 0 fax voice" which would mean to "describe in voice the image," for example via some sort of image recognition. Do we need this?] Here is an example of the use of media type image to send a jpeg image stored on the internet at http://www.acme.com/~sbp/pic1.jpeg to a fax machine at phone number +1-201-406-4090: c= TN RFCxxxx +1-201-406-4090 m= image 0 fax jpeg a=fmtp:jpeg http://www.acme.com/~sbp/pic1.jpeg Media Type "text" can be used with transport protocols "fax," "voice," or "pager". The "voice" protocol indicates that the phone system is to use some text-to-speech mechanism to read out the text to the indicated phone terminal. The "fax" protocol indicates that the text is to be printed out as is on a remote fax machine. The "pager" protocol transports the text to a remote machine. (The PINT server may return a "606 Not Acceptable" error if the content to be transmitted contains unsupported characters, e.g. If the remote pager can receive only digits and some text is sent) The allowed format parameters are any MIME subtype of MIME type text (see [ ]). As with media type "image", the format specific attribute tags ("a=fmtp:<fmt> <params>) are used to indicate the precise data to be sent over the Telephone Network to the remote terminal. The <params> can contain either a URI or a content-ID. Media type "application" MAY be used with transport protocol "fax," "voice," or "pager". In principle, any MIME subtype of type "application" can be used as the format, but the main intent in to allow media type application is to allow format parameter URI. This is used in combination with an attribute tag "a=fmtp:URI <URI>" to indicate that the URI written in the attribute tag points to some content on the Internet which is to be sent via either "voice transport" or "fax transport" to the remote TN terminal. This is the generic way that a PINT request is made to fax/read-out the content pointed to by URI <URI> to the TN terminal indicated in the connection (c= ) line. Some PINT requests are to invoke telephone network sessions where specific content is to be transported to the remote terminal. For example, this happens when the request is for the Milestone Service "Request-to-Fax" and Request-to-hear-Content. If the PINT request is a request to transport data to a TN terminal, then the media description contains a format parameter which must be a MIME sub-type of the media type indicated in the start of the m= line. It is allowed to include several format parameters in the media description. This indicates alternative image formats of the same content which are available on the internet for the server. In order to point to the content on the IP network which is to be sent, a format specific parameter is used: a=fmtp:<fmt> <URIs> The <fmt> must be one of the MIME subtypes that appear in the m= media description line. The <URIs> is a string of URIs, each one of which points to data of the specified MIME subtype. If more than one URI is included in the attribute, they are to be space separated, and this indicates that ALL the URIs are to be sent, serially, one after the other. This can be used, for example, to send several different unrelated URIs within a single fax transmission. If there is more than one format in the m= line, this indicates that the same information is available in different alternative formats. Each format must have a single associated format specific attribute line. Within a single media description, all the attribute lines point to the same information to be sent over the TN, and that the PINT server can use ANY ONE of the formats and attribute lines to retrieve the data to be sent. The alternatives are listed in order of preference, with the first alternative first. If a single PINT request contain several media descriptions, this is an indication to send several different pieces of content, each one with a different format. Each media description describes a single piece of content to be sent. They are to be sent serially, one after the other, in the order of their appearance within the session description. It is also possible to use the media type "application" with format parameter "URI", with format specific attributes containing a string of unrelated URIs: c= TN RFCxxxx +1-201-406-4090 m= application 0 voice URI a=fmtp:URI http:xxxxx http:yyyyyy ...... This is a request to read out the content of a series of unrelated Web Pages over the TN to the phone terminal at address +1-201-406-4090. The URIs are sent serially, one after the other, in the order of their appearance within the attribute line. This scheme provides maximum simplicity in the usual cases of a request for sending some single piece of data, but allows the flexibility to store the same data in various alternative formats (say storing a picture in some proprietary highly-compressed form and in some more simple generally-understood form). It allows a single request to be for sending multiple bits of content to the remote terminal. Note that it may be more than one PINT request which results in the same service. For example, the content might be reachable as media type "text/plain" or more generically as media type application/URI. If the requestor knows at request time that the data to be sent is of type image or text, it is RECOMMENDED that the media description indicate this rather than use the generic media type "application," such as in "m= application 0 fax URI". The following two descriptions might result in the same TN service, but the second is more precise and if it is the desired service it is preferable to use it: m=application 0 fax URI a=fmtp:URI http://www.acme.com/pic1.tif m=image 0 fax tif a=fmtp:tif http://www.acme.com/pic1.tif Note that these two descriptions are not truly equivalent. The first description is a generic request to "fax me the indicated URI", and it is not clear exactly what sort of translation will appear at the fax machine. The second description is a more precise request to render the tif picture on the remote fax machine. (It is of course true that it is not specified exactly how the image/tif is to be rendered, but the instruction to render media type image/tif gives more information than the instruction to render media type application/URI). 3.4.3 Format attributes for included content data In addition to pointing to the data on the internet, it is possible to include the content data within the SIP request itself. This is done by having the SIP payload be multipart MIME. The first MIME part contains the SDP description of the telephone call service to be executed. The other MIME parts contain the Content Data to be transported. Within the SDP MIME part, format specific attributes lines are used to indicate which other MIME part within the request contains the content data. Instead of a URI, the format specific attributes indicates the Content-ID of the MIME part of the request which contains the actual data: c= TN RFCxxxx +1-201-406-4090 m= text 0 fax plain a=fmtp:plain <Content-ID> The <Content-ID> parameter is the Content-ID of one of the MIME parts inside the message. One can always distinguish a Content-ID from a URI by the presence of a colon before the @ sign, and this can be used to distinguish between included content and content which resides elsewhere on the Internet. For example, in a multipart message where the string "------next-------" is the boundary, the first two parts might be as follows: ------next------- Content-Type: application/sdp .... c= TN RFCxxxx +1-201-406-4090 m= text 0 pager plain a=fmtp:plain 17@mymessage.acme.com ------next------- Content-Type: text/plain Content-ID: 17@mymessage.acme.com This is the text that is to be paged to +1-201-406-4090. ------next------- PINT clients should be extremely careful when sending included data within a PINT request. Such requests SHOULD be sent via TCP, to avoid fragmentation and to transmit the data reliably. It is possible that the PINT server is a proxy server that will replicate and fan out the request, which could be disastrous if the request contains a large amount of application data. PINT proxy servers should be careful not to create many copies of a request with large amounts of data in it. This mechanism is particularly useful when the request is to send a short message to a Telephone Network Pager. The ability to indicate different alternatives for the content to be transported is also useful, even when the alternatives are included within the request. For example, a request to send a short message to a pager might include the message in unicode [ ] and an alternative version of the same content in text/plain, should the PINT server or telephone network not be able to process the unicode. 3.4.4 Attribute Tags to pass information into the Telephone Network It may be desired to include within the PINT request service parameters which can be understood only by some entity in the Telephone Network Cloud. SDP attribute parameters are used for this purpose. They MAY appear within a particular media description or outside of a media description. These attributes may also appear within PINT URLS (see section 3.5.6). This is necessary so that telephone terminals which require the attributes to be defined can appear within the To: line of a PINT request as well as within PINT session descriptions. The purpose of these attributes is to allow the client to specify extra context within which a particular telephone number is to be interpreted. Although it is recognised that such attributes are occasionally necessary, for reasons internal to the telephone networks which carry out the PINT requests, the URLs appearing in the To: and From: headers and within the Request-URI offer a These attributes are often used in conjunction with the "strict" attribute (section 3.4.5) and the "org.ietf.ping.strict" Require: tag (section 3.5.4). It is not possible to standardise every possible internal telephone network parameter. PINT 1.0 attributes have been chosen for specification because they are common enough that many different PINT systems will want to use them, and therefore interoperability will be increased by having a single specification. 3.4.4.1 ITU-T CalledPartyAddress attributes parameters These attributes correspond to fields that appear within the ITU-T Q.763 "CalledPartyAddress" field [ ITU-T Q.763 ,section 3.9 ]. PINT clients use these attributes in order to specify further parameters relating to Terminal Addresses, in the case when the address indicates a "local-phone-number." In the case that the PINT request contains a reference to PSTN terminal, the parameters may be required to correctly identify the remote terminal The defined attributes are: a=Q763-nature: - indicates the "nature of address indicator". The value MAY be any number between 0 and 127. The following values are specified: "1" a subscriber number "2" unknown "3" a nationally significant number "4" an internationally significant number The values have been chosen to coincide with the values in Q.763. Note that other values are possible, according to national rules or future expansion of Q.763. a=Q763-plan: - indicates the numbering plan to which the address belongs. The value MAY be any number between 0 and 7. The following values are specified: "1" Telephone numbering plan (ITU-T E.164) "3" Data numbering plan (ITU-T X.121) "4" Telex numbering plan (ITU-T F.69) The values have been chosen to coincide with the values in Q.763. Note that other values are possible, according to national rules or future expansion of Q.763. a=Q763-INN - indicates if routing to the Internal Network Number is allowed. The value MUST be ONE of: "0" routing to internal network number allowed "1" routing to internal network number not allowed The values have been chosen to coincide with the values in Q.763. Note that it is possible to use a local-phone-number and indicate via attributes that the number is in fact an internationally significant E.164 number. Normally this SHOULD NOT be done; an internationally significant E.164 number is indicated by using a "global-phone-number" for the address string. 3.4.4.2 The phone-context attribute An additional attribute is specified to enable "remote local dialling". This is the service that allows a PINT client to reach a number from far outside the area or network which can usually reach the number. It is useful when the sending or receiving address is only dialable within some local context, which may be remote to the origin of the PINT client. For example, if Alice wanted to report a problem with her telephone, she might then dial a "network wide" customer care number; within the British Telecom network in the U.K., this is "152". Note that in this case she doesn't dial any trunk prefix - this is the whole dialable number. If dialled from another operator's network, it will not connect to British Telecom's Engineering Enquiries service; dialling "+44 152" will not normally succeed, as it's Network-Specific Service Number. Within the telephone network, the "local context" is provided by the physical connection between the subscriber's terminal and the central office. An analogous association between the PINT client and the PINT server which first receives the request may not exist, which is why it may be necessary to supply this missing "telephone network context." There are many reasons why extra context might be necessary to interpret a given telephone number: a. The telephone number might be reachable in many different ways, such as via competing telephone service providers, and the PINT client wishes to indicate its selection of service provider. b. The telephone number might be reachable only from a limited number of networks, such as an '800' freephone number. c. The telephone number might be reachable only within a single telephone network, such as the '152' customer service number of BT. Similarly, the number might be an internal corporate extension reachable only within the PBX. However, as noted above, it should not usually be necessary to use SDP attributes to specify the phone context. URLs such as 152@pint.bt.co.il within the To: header and/or Request-URI, normally offer sufficient context to resolve telephone numbers. This attribute is defined as follows: a=phone-context: <phone-context-identifier> phone-context-identifier = network-prefix | private-prefix network-prefix = intl-network-prefix | local-network-prefix intl-network-prefix = "+" 1*DIGIT local-network-prefix = 1*DIGIT private-prefix = <need BNF for a string which is not intl- network-prefix or local-network-prefix> Although not every phone-context can be specified, the local contexts which correspond to dialable public telephone networks can be. An intl-network-prefix and local-network-prefix MUST be a bona fide network prefix, and a network-prefix which is an intl-network-prefix MUST begin with an E.164 service code ("country code"). It is possible to register new private-prefixes with IANA so as to avoid confrontation. Prefixes which are not so registered MUST begin with an "X-" to indicate their private, non-standard nature. Example 1: c= TN RFCxxxx 1-800-765-4321 a=phone-context:+972 This describes an terminal whose address in Israel (E.164 country code 972) is 1-800-765-4321. Example 2: c= TN RFCxxxx 1-800-765-4321 a=phone-context:+1 This describes an terminal whose address in North America (E.164 country code 1) is 1-800-765-4321. The two telephone terminals described by these descriptions are different; in fact they are located in different countries. Example 3: c=TN RFCxxxx *123 a=phone-context:+97252 This describes a terminal whose address when dialled from within the network identified by +97252 is the string "*123". It so happens that +97252 defines one of Israeli cell phone providers, and *123 reaches customer service when dialled within that network. Of course it may well be useful or necessary to use one of the Q.763 attribute parameters in combination with the phone-context attributes. Example 4: c= TN RFCxxxx 321 a=phone-context:X-acme.com 23 This might describe the telephone terminal which is at extension 321 of PBX number 23 within the acme.com private PBX network. It is expected that such a description would be understandable by the acme.com PINT server which receives the request. Note that if the PINT server receiving the request is inside the acme.com network, the same terminal might be addressable as follows: c= TN RFCxxxx 7-23-321 (assuming that "7" is dialled in order to reach the private PBX network from within acme.com) Proprietary attribute "a=" lines, which by definition are not interoperable, may be nonetheless useful when it is necessary to transport some proprietary internal TN variables over the IP network. We shall see an example of such usage in section 4. 3.4.5 The "strict" attribute Unfortunately, according to the SIP specification, a PINT server is allowed simply to ignore attribute parameters that it does not understand. In order to force a client to fail a request if it does not understand one of the PINT attributes, a client should use the "strict" attribute (section 3.4.5), specified as follows: a=strict:<attribute-list> where the attribute-list is a comma-separated list of attributes that appear elsewhere in the session description. In order to process the request successfully the PINT server must BOTH understand the attribute AND ALSO fulfil the request implied by the presence of the attribute, for each attribute appearing within the attribute-list of the strict attribute. If the server does not recognise the attribute listed, or cannot fulfil the request implied by the attribute, the PINT server MUST fail the request with (606 Not Acceptable), along with (a) suitable Warning: line(s) explaining the problem. The "strict" attribute may appear anywhere in the session description, and any number of times, but it MUST appear before the use of the attribute marked as strict. Since the "strict" attribute is itself an attribute, the SIP spec allows a server which does not understand the strict attribute to ignore it also. In order to ensure that the PINT server will comply with the "strict" attribute, a PINT clients should include a Require: header with the tag "ietf.org.pint.strict" (section 3.5.4) 3.5 PINT profile of SIP 2.0 PINT requests are SIP requests; Many of the specifications within this profile merely explain how to use existing SIP facilities for the purposes of PINT. 3.5.1 multi-part mime sending of data along with SIP request A PINT request can contain a payload which is multipart MIME. In this case the first part MUST contain an SDP session description, which includes at least one of the format specific attribute tags for "included content data" specified above in section 3.2.4. All subsequent parts contain content data which is to be transported in the requested Telephone Call Service. It is allowed that within a single PINT request, some of the data MAY be pointed to by a URI within the request, and some of the data MAY be included within the request. 3.5.2 Warning header A PINT server MUST support the SIP "Warning:" header. It is used to signal mismatches between PINT clients and servers from different versions and with different supported features. (It is also used to signal the status of an ongoing session that is referred to within a retransmitted or STATUS request (see 3.5.3 below)). For example, suppose a client sends a PINT request to a server which understands PINT requests but which cannot provide the particular Telephone Call Service requested. Perhaps the PINT request is to send a jpeg picture to a particular TN fax machine, but the server cannot retrieve and/or translate jpeg pictures from the Internet into Fax transmissions. In such a case the server would fail the request and must include a Warning such as the following: Warning: 4xx pint.acme.com Incompatible Format: jpeg SIP servers which do not understand the PINT extensions at all are strongly encouraged to use the Warning: header to indicate that that PINT extensions are not understood. Note that the Warning: header may be used even if the response is not an error. In the above example, the request might have contained several alternative formats for the image to be faxed, and the server can return the above Warning: even in a successful response, to indicate that it did not understand the jpeg format, although it did understand one of the other alternatives and is processing the request using that alternative: Warning: 3xx pint.acme.com Incompatible Format: jpeg Warning: 502 pint.acme.com Using tif http://server/pics/a123.tif PINT defines a new family 5xx of Warning codes to be used to describe the status of media sessions. PINT 1.0 defines five such codes: 500 Session scheduled for <HTTP-Date> This indicates that the requested session has been successfully queued, but it has not yet begun. The <HTTP-Date> is an optional part of the Warning Text and indicates the time at which the session is scheduled to begin. The HTTP-Date MUST be at the end of the Warning Text. A Server MUST NOT end the Warning Text with a valid HTTP-Date UNLESS this indicates the time at which the session will begin. 501 <HTTP-Date> Session Begun This indicates that the requested session has begun successfully and is proceeding normally. The <HTTP-Date> is an optional part of the Warning Text and indicates the time at which the session began. A Server MUST NOT begin the Warning Text with a valid HTTP-Date UNLESS this indicates the time at which the session began. 502 Session in Progress This indicates that the requested session has begun successfully, is proceeding normally, and has not yet terminated. 503 <HTTP-Date> Session Completed This indicates that the requested session completely normally. The <HTTP-Date> is an optional part of the Warning Text and indicates the time at which the session ended. A Server MUST NOT begin the Warning Text with a valid HTTP-Date UNLESS this indicates the time at which the session ended. 504 <Fax-Prog> Sent XXX Page of YYY This warning can be included in the response to a fax session to indicate that XXX out of a total of YYY pages have been sent. The <Fax-Prog> parameter is an optional part of the Warning text and indicates the numbers XXX and YYY in a machine readable, language- independent manner. It is allowed to include only one of the two numbers, in which case the period "." must be included before or after the number. A Server MUST NOT begin the Warning Text with a <Fax-Prog> parameter UNLESS this is to indicate the number of pages sent. Fax-Prog = ( pages-sent "." total-pages | pages-sent "." | "." total-pages ) pages-sent = *digit total-pages = *digit Examples are as follows: Warning: 504 pint.acme.fr 2.5 2 pages sur 5 envoy'ees Warning: 504 pint.acme.com 2. 2 pages sent so far These warning codes can be used independently within a single response. For example, a 501 and 503 warning can be returned in a single response to indicate at which time the telephone session started and ended. Warning code 504 can be returned with various combinations of the other Warning codes. The Warning headers can be sent within STATUS requests (section 3.5.3) as well as within responses, if the original request contained a Location: header to indicate the presence of a PINT server which can receive STATUS requests. 3.5.3 The STATUS request In PINT there is a requirement to propagate the status of the telephone network sessions described within the SDP payload. Warning headers are used for this purpose as well, as a Warning can be merely informational and is not required to indicate an error. PINT specifies a new method, STATUS, expressly for the purpose of requesting an update on the server's view of the status of an outstanding request or media session. If a STATUS request were required to come from the same client that made the original request, it would be possible to use client retransmission instead of a new method. But it is very desirable to allow such requests to come from other clients in the network. For example, one might request that a fax be sent, and then have someone else (e.g. a secretary) check if the fax actually got sent. The STATUS request is submitted by a client to determine the status of an outstanding request. The request payload must include an SDP description which is identical to the original description. It SHOULD NOT include whatever included Content was present in the original request, and a server MUST ignore whatever content is included within a STATUS request. The Call-ID is allowed to be different from that in the original Call to allow STATUS requests from third parties. The successful response to a STATUS request is the last cached response that the Server returned to a Request that has the same global session ID, along with one or more Warning: headers (see 3.3.5 below) to indicate the status of the ongoing or completed telephone call session. If there are no previously returned response within the server's cache, the server returns a "606 Not Acceptable" response with a Warning: header as follows: Warning: 4xx pint.acme.com Incompatible Session Description: Unknown Session ID. Note that within SIP, it is allowed that a client include within the request a "Location:" header to indicate the location of an associated SIP server. This is usually used to enable a callee to hang up calls or change the session description. A PINT client may use this facility to indicate the Location of an associated PINT server which is capable of receiving a STATUS request from the PINT server which serviced the client's original request. If a PINT client includes a Location: header within a request, the associated server indicated in the Location header SHOULD support receiving the STATUS request from the server to contain a Warning: line containing indication of the status of the telephone call service. This allows a client to receive ongoing status reports of a requested telephone call service without having to poll the server. Similarly, Warning: headers MAY be included within BYE requests to a server which had been previously indicated within a Location: header from a client (see 3.5.7 below). Thus in PINT, Warning headers: MAY be included in requests as well as responses. It is allowed to send a STATUS request about a particular Telephone Network Session after the Call has been destroyed via a BYE message. If the Server no longer has a record of the session, it returns "606 Not Acceptable", along with the appropriate Warning: header indicating that the SDP session ID is no longer valid. This allows a client to discover the status of a telephone call service long after the service has completed. For example, one might want to check the next day that the fax was indeed sent the previous night at 1:00 AM. There is no minimum time that a server is required to retain status of any particular session. Under normal SIP rules, as long as no BYE has been sent, the PINT server is part of the PINT session, and it should retain status of the call. A server can return an Expires: header within any response to INVITE to indicate for how long it will cache the result. To summarise, the status Warning: lines can be included in any response, and can also be included with a STATUS or BYE request in the special case when these requests are being sent to a server which was indicated in the "Location:" line within a previous PINT request. [??? This is very close to Henning's and Jonathan's NOTIFY request. We should decide on a single name. The main differences are that STATUS can be client-->server or server-->client, and any old client can issue a STATUS request to get an update on what is going on with the session]. 3.5.4 Require header for PINT PINT clients use the Require: header to signal to the PINT server that a certain PINT extension of SIP is required. (SIP ensures that a PINT server which does not understand the Require: org.ietf.pint.XXX header will return a 420 Bad Extension response, and list the unsupported option within an Unsupported: header) PINT 1.0 defines three strings that can go into the Require header: org.ietf.pint.STATUS -- the server can respond to STATUS requests (section 3.5.3) org.ietf.pint.Warning -- the server can return the new PINT Warning headers to indicate the status of requests (section 3.5.2) org.ietf.pint.strict -- the PINT server (or the SDP parser associated to it) understands the "strict" attribute defined in (section 3.4.5) Example: org.ietf.pint.STATUS,org.ietf.pint.Warning [???? Should we define these tags a org.ietf.mmusic.sip tags??] The specification of separate tags for each feature allows a client to require individual PINT features independently. For example, a client may wish to receive a Warning if the server cannot understand one of several alternative image formats offered, but apart from this may have no need for the STATUS request. A client should only include a Require: header if it really wishes the Server to fail the request in case the option is not supported. If the client merely "desires" that the feature is available, but is willing to accept service from a Server without the PINT feature, the client should not include the Require: header. PINT servers MUST give Warnings for SIP headers and elements of the session description that they do not understand. 3.5.5 PINT URLS within PINT requests URLs are used within the Request-URI and certain SIP headers (such as To: and From:). The Request-URI within a SIP request refers to the service or user that services the request. Normally the hostnames and domain names that appear in the PINT URLs are the internal affair of each individual PINT system. A client uses the appropriate SDP payload to indicate the particular service it wishes to invoke; it is not necessary to use a particular URL to identify the service, although there are several advantages to doing so: a. if the SDP payload is encrypted it may not be possible for the PINT system to use SDP information to route the request; b. doing so may speed up processing by helping to route requests for a particular service to a particular PINT gateway; c. It enables multiple competing PINT gateways to REGISTER with a single "broker" server (proxy or redirect) (see section 3.5.8) d. When the provider of the actual telephone network session is separate from the provider of the PINT system, it may be important to indicate the names of the two providers in a machine readable fashion, for example, to enable equal access to other operator's services. For these reasons, it is suggested that Request-URI for PINT services should be of one of the following two forms: <service>@<Pint Service Provider> <service>%<Telephone Service Provider>@<Pint Service Provider> <service> MAY be one of the following three strings: R2T (for Request To Call) R2F (for Request To Fax) R2HC (for Request To Hear Content) The <Pint Service Provider> is an identifier (domain name or IP) of a Pint Server. The <Telephone Service Provider> is an identifier (domain name or IP) of a server that can provide service inside the Telephone System. It is customary for Telephone Network services to be identified by a number. It is RECOMMENDED that service providers use this number for the <service> parameter. PINT implementations SHOULD NOT use a number as the <service> parameter unless that number is in fact the identifier of some Telephone Network service within the domain of the Telephone Service Provider. This and future versions of this PINT specification SHALL NOT ever use a raw number as a service identifier. Thus, for example:- INVITE RTC@pint.pintservice.com SIP/2.0 INVITE R2F%telco.com@pint.pintservice.com SIP/2.0 INVITE R2HC%pbx23.mycom.com@pint.mycom.com SIP/2.0 INVITE 13@pint.telco.com SIP/2.0 Since such URLs are not strictly necessary for interoperability, they are only recommendations, and not mandatory. See section 3.5.8 for some related considerations concerning registrations by competing PINT systems to a single PINT proxy server acting as a service broker. 3.5.6 Telephony Network Parameters within PINT URLs Any legal SIP URL can appear as a PINT URL within the Request-URI or To: header of a PINT request. But if the address is a telephone address, we saw in section 3.4.4 we saw that it may be necessary to include more information in order to correctly identify the remote telephone terminal or service. PINT clients MAY include these attribute tags within PINT URLs if they are necessary or useful to complement the telephone number within the SIP URL. These attribute tags MUST be included as URL parameters as defined in [ ] (i.e. in the semi-colon separated manner). The following is an example of a PINT URL which contains extra attribute tags: sip:+97252288088@host.org;a=strict:Q763-nature,Q763-plan;a=Q763-nature:3;a=Q763-plan:2 As we noted in section 3.4.4, these extra attribute parameters SHOULD NOT normally be needed within a URL, because there is a great deal of context available to the help the server interpret the phone number correctly. In particular, there is the SIP URL within the To: header, and there is also the Request-URI. In most cases this provides sufficient information for the telephone network. The SDP attributes defined in 3 above SHOULD ONLY be used when they are needed to supply necessary context to identify a telephone terminal. Note that the terminal with this SIP URL is the same as the one whose connection is defined by the following part of an SDP description: c= TN RFCxxxx +97252288088 a=strict:Q763-nature,Q763-plan a=Q763-nature:3 a=Q763-plan:2 3.5.7 BYE requests in PINT The semantics of BYE requests within PINT requires some extra precision. The BYE request [ ] is used within Internet Conferences to indicate that the originating entity no longer wishes to be involved in the specified call. Normally, a BYE request is a request to terminate the call and the media session. Thus according to the usual SIP semantics, if a PINT client made a request have a telephone call made from telephone A to telephone B, a BYE request from the client, if accepted, should result in a termination of the phone call. Note that the Telephone Call might not have even started at the time when the BYE request is received. For example, if a request to fax is sent with a t= line indicating that the fax is to be sent tomorrow at 04:00AM, the requestor might wish to cancel the request before the specified time. A second problem is that it may not be possible to terminate the media session on the telephone system side. For example, the fax call may be in progress when the BYE arrives, and perhaps it is just not possible to cancel a fax in session. A third problem is that the entire telephone-side service might be completed before the BYE is received. In the above Request-To-Fax example, the BYE might be sent the following morning, and the entire fax has been sent before the BYE was received. In the case where the telephone network cannot terminate the media session, or it has already completed when the BYE is received, the server MUST include a Warning: header to indicate the status of the telephone session. Even if the PINT server can cancel the Telephone Network session, it SHOULD include a Warning: message indicating that the Telephone Session has been cancelled. Examples of such Warnings: are Warning: 502 pint.acme.com Telephone Call is still in session: Hang up the Phone!!! Warning: 504 pint.acme.com 3.6 Fax Service sent 3 of 6 pages Warning: 503 pint.acme.com 04:03 EST 3-12-98 Fax Service Completed Successfully If the client knows that it wishes to send STATUS requests at some point in the future, it MUST NOT send a BYE request, since a BYE requests ends the PINT association between the two parties, and the server might clear all knowledge of the call upon receipt of a BYE. The PINT server may use the Expires: header within the response to the BYE to indicate for how long it will be able to answer future STATUS messages. The PINT server MUST keep the response to the BYE cached at least as long as indicated within a Expired: header, of course. It is possible that some other client may send a STATUS request about a particular PINT session even after the original PINT requestor sent a BYE and ended the session. This allows a third party to check up on the status of the transmission long after the PINT transaction is completed. There is just no guarantee that the PINT server will retain status of terminated PINT sessions (unless the PINT server indicated with an Expires: header that it will retain status for a period of time). If the original requesting PINT client included a Location: header in its request, Then the original responding PINT server may send a BYE request to this location, along with a Warning: header that includes the final status of the telephone call service. But a PINT server should be especially careful when sending such a BYE request. It may be that a PINT request was sent from a host, along with a Location header, but that the requesting host is shutdown when the telephone service is executed, so the host is not available at the Location: specified in the request to receive the PINT server's BYE. Normally a server would send a STATUS request to the server indicated within the Location: header, until such time as it is certain that a BYE request can be received. Note that the above scenarios make sense with ordinary Internet multimedia sessions, not just with telephone network sessions. The intent of these semantics for BYE requests between PINT clients and servers is to be consistent with their meaning in ordinary Internet Conferences. [???What happens in an ordinary SIP audio call? is it REQUIRED that the RTP stop transmitting when the BYE is sent and acknowledged? Since the SIP spec speaks about BYE as meaning the requestor is about to "hang-up the call", I assumed that this is correct. Or maybe the RTP can go on forever, it's just that after the SIP BYE, the RTP transmission is no longer within the context of a session.] 3.5.8 REGISTER requests within PINT A PINT gateway is a SIP user agent server, and user agent services use the REGISTER request to tell a proxy or redirect server that it is available to "receive calls" -- i.e. to service requests. In the case of PINT, the Server is registering the service that is accessible via itself rather than a user registering presence at a particular SIP Server. There may be competing PINT servers which can offer the same PINT service trying to register at a single PINT server. The PINT server might act as a "broker" among the various PINT gateways which can fulfil a request. A format for PINT URLs was specified in section 3.5.5 that enables independent PINT systems to REGISTER an offer to provide the same service. The registrar can apply its own mechanisms and policies to decide what to respond to INVITEs from clients seeking service. (See section 6.3 for some possible deployment options) There is no change between SIP and PINT REGISTER semantics or syntax. Of course, the information in the PINT URLs within the REGISTER request may not be sufficient to completely define the service that a gateway can offer. The use of SIP and SDP within PINT REGISTER requests to enable a gateway to specify general services it can offer is the subject of future study. [??? The obvious solution is to use wildcards (say *, !, etc.) and comma separated multiple parameters within the SDP descriptions in the REGISTER request to indicate phone numbers, attributes, etc. which can be serviced from the registering PINT gateway. Do we need to do this in PINT 1.0??? I fear we do???] 4. Examples of PINT Requests and Responses [???examples need to include some complete transactions, including responses, not just requests!!] 4.1 A request to a call centre from an anonymous user to receive a phone call about a Sale on Ironing Boards C->S: INVITE marketing@pint.mailorder.com SIP/2.0 Via: SIP/2.0/UDP 169.130.12.5 From: anon-1827631872@chinet.net To: 1-800-IRON-YES Call-ID: 19971205T234505.56.78@chinet.net Subject: Sale on Ironing Boards Content-type: application/sdp Content-Length: ... v=0 o=- 53655765 2353687637 IN IP4 128.3.4.5 i=Ironing Board Promotion c= TN RFCxxxx +1-201-406-4090 m=audio 0 voice In this example, the context which is required to interpret the To: address as a telephone number is not given explicitly; it is implicitly known to the marketing@pint.mailorder.com server. But the telephone of the person who wishes to receive the call is explicitly identified as an internationally significant E.164 number within the North American numbering plan (because of the "+1" within the c= line). 4.2 A request from a non anonymous customer (John Jones) to receive a phone call from a particular sales agent (Mary James) concerning the defective ironing board that was purchased: C->S: INVITE marketing@pint.mailorder.com SIP/2.0 Via: SIP/2.0/UDP 169.130.12.5 From: john.jones.3@chinet.net To: mary.james@mailorder.com Call-ID: 19971205T234505.56.79@chinet.net Subject: Defective Ironing Board - want refund Content-type: application/sdp Content-Length: ... v=0 o=- 53655765 2353687637 IN IP4 128.3.4.5 c= GSTN E163 +1-201-406-4090 m=audio 0 voice (The To: line might include the Mary James's phone number instead of a email-like address.) Note that such a telephone call service could be implemented on the phone side with different details. For example, it might be that first the agent's phone rings, and then the customer's phone rings, or it might be that first the customer's phone rings and he hears silly music until the agent comes on line. If necessary, such service parameter details might be indicated in "a=" attribute lines within the session description. The specification of such attribute lines for service consistency is beyond the scope of the PINT 1.0 specifications. 4.3 A request from the same user to get a fax back on how to assemble the Ironing Board C->S: INVITE faxback@pint.mailorder.com SIP/2.0 Via: SIP/2.0/UDP 169.130.12.5 From: john.jones.3@chinet.net To: 1-800-FAXBACK Call-ID: 19971205T234505.66.79@chinet.net Content-type: application/sdp Content-Length: ... v=0 o=- 53655768 2353687637 IN IP4 128.3.4.5 c= TN RFCxxxx 1-201-406-4091 a=Q763-nature:3 m=application 0 fax URI a=fmtp:URI http://localstore/Products/IroningBoards/2344.html In this example, the fax to be sent is stored on some local server (localstore), whose name may be only resolvable, or which may only be reachable, from within the IP network on which the PINT server sits. The phone number to be dialled is a "local phone number" as well. The Q763-nature was added to further identify the number as a nationally significant number. There is no "phone-context" attribute, so the context (in this case, for which nation the number is "nationally significant") must be supplied by the faxback@pint.mailorder.com PINT server. If the server which receives does not understand the number, it should fail the request with and include a "Network Address Not Understood" warning. Note that no "strict" attribute was used here, since it is very likely that the request can be serviced even by a server which does not support the "strict" attribute. 4.4 A request from same user to have that same information read out over the phone C->S: INVITE faxback@pint.mailorder.com SIP/2.0 Via: SIP/2.0/UDP 169.130.12.5 From: john.jones.3@chinet.net To: 1-800-FAXBACK Call-ID: 19971205T234505.66.79@chinet.net Content-type: application/sdp Content-Length: ... v=0 o=- 53655768 2353687637 IN IP4 128.3.4.5 c= TN RFCxxxx +1-201-406-4090 m=application 0 voice URI a=fmtp:URI http://localstore/Products/IroningBoards/2344.html 4.5 A request to send a text page to a friend's pager. The text to be paged out is included in the request. C->S: INVITE pages@pint.herpager.com SIP/2.0 Via: SIP/2.0/UDP 169.130.12.5 From: scott.petrack@chinet.net To: text@pint.herpager.com Call-ID: 19974505.66.79@chinet.net Content-Type: multipart/mixed; boundary=--next --next Content-Type: application/sdp Content-Length: ... v=0 o=- 53655768 2353687637 IN IP4 128.3.4.5 c= TN RFCxxxx +972-9-956-1867 m=text 0 pager plain a=fmtp:plain 2@53655768 --next Content-Type: text/plain Content-ID: 2@53655768 Content-Length: ... Hi Joe! Please call me asap at 555-1234. --next 4.6 A request to send an image as a fax to phone number +972-9-956-1867; C->S: INVITE faxserver@pint.vocaltec.com SIP/2.0 Via: SIP/2.0/UDP 169.130.12.5 From: scott.petrack@chinet.net To: faxserver@pint.vocaltec.com Call-ID: 19971205T234505.66.79@chinet.net Content-type: application/sdp Content-Length: ... v=0 o=- 53655768 2353687637 IN IP4 128.3.4.5 c= TN RFCxxxx +972-9-956-1867 m=image 0 fax tif gif a=fmtp:tif http://petrack/images/tif/picture1.tif a=fmtp:gif http://petrack/images/gif/picture1.gif The image is available as tif or as jpeg. The tif is the preferred format. Note that the http server where the pictures reside is local, and the PINT server is also local (because it can resolve machine name "petrack") 4.7 A request to read out over the phone two pieces of content in sequence. First some included text is read out by text-to-speech. Then some text which is stored at some URI on the internet is read out. C->S: INVITE switchboard@pint.acme.com SIP/2.0 Via: SIP/2.0/UDP 169.130.12.5 From: scott.petrack@chinet.net To: voice_server@pint.acme.com Call-ID: 19974505.66.79@chinet.net Content-Type: multipart/mixed; boundary=next --next Content-Type: application/sdp Content-Length: ... v=0 o=- 53655768 2353687637 IN IP4 128.3.4.5 c= TN RFCxxxx +1-201-406-4091 m=text 0 voice plain a=fmtp:plain 2@53655768 m=text 0 voice plain a=fmtp:plain http://www.mymachine.com/texts/mytext.doc --next Content-Type: text/plain Content-ID: 2@53655768 Content-Length: ... Hello!! I am about to read out to you some text stored on my Web Site. Let me know how it sounds over acme.com's new speech synthesis server. --next 4.8 Interaction with a Proprietary IVR-based FaxBack System This example is intended to show how PINT systems can be "bolted on" to existing Telephone System servers, such as "Intelligent Peripherals". We consider an IVR-based (i.e. DTMF-driven) fax back system. Users normally call up the system from a Fax machine, type in some DTMF digits to identify the fax they want to receive, and then hit the "Receive" button on their fax machines. The FaxBack system retrieves the fax from storage and sends it out to the machine. The faxes are stored on some "Intelligent Peripheral" inside the Telephone Network. The server might be owned by some Telephone Service Operator, which runs a FaxBack service for many business customers. The faxes are identified by some customer code and the document code of the fax. At present customers call in from a fax machine and send DTMF tones to indicate the document code they wish to receive. Unfortunately the documents are not identified by URIs (the server is not quite "intelligent" enough to understand a URI...). It is desired to use identifiers that are identical to the current customer code and document code identifiers that customers now use when they dial in for the faxback service. Here is one way to accomplish this, using a proprietary "format" code to indicate the format of the fax to be sent. C->S: INVITE ivrfax@pint.operator.net SIP/2.0 Via: SIP/2.0/UDP 169.130.12.5 From: scott.petrack@chinet.net To: faxes@pint.vocaltec.com Call-ID: 19971205T234505.66.79@chinet.net Content-type: application/sdp Content-Length: ... v=0 o=- 53655768 2353687637 IN IP4 128.3.4.5 c= GSTN E163 +972-9-956-1867 m=application 0 fax X-ivr.operator.net a=fmtp:X-ivr.operator.net 35.1234 The operator has defined X-ivr.operator.net as a proprietary MIME sub- type of MIME type application. This MIME sub-type is defined as a concatenation of the customer code, followed by a period, followed by the DTMF code of the fax to be transported. It is of course possible to register the MIME sub-type with IANA, if there is a desire to have interoperability of this form of identification among different vendors. 5. Security Considerations [??? There is some preliminary text, including some of the "responsibility" stuff of Steve. will get to it after the deadline I'm afraid] [??? It seems to me that SIP security mechanisms seem adequate to the task, except that decent text needs to be written on such topics as how to use those mechanisms to avoid fraud, trace malicious/ nuisance requests, etc. Some mention must be made as well of third party authorisation, such as when a corporate PBX allows person A to make long distance calls, but not person B] [??? The basic mechanisms are to be able to both digitally sign and encrypt payloads. Certificates will be used. The certificates contain the identity of the certificate authority, and this can be used as a back end service to authorise the execution of the PINT service. [???lwc -- Security considerations for REGISTER: For example, what's to stop any provider from registering as "R2T%att.com"? It should be possible to require authentication authentication of the request, it is indeed possible for someone to want to register themselves as "R2T%att.com" or even to override all other registrations for "R2T". (by attempting such a registration with a "zero time" Expiry header).] 6. Deployment considerations and the Relationship PINT to IN 6.1 Web Front End to PINT Infrastructure In practice, there are not (currently) many PINT Clients. It is likely that some other protocol will be used to communicate a Requesting User's requirements. Due to the high numbers of available Web Browsers and servers it seems likely that some PINT systems will use HTML/HTTP as a "front end". In this scenario, HTTP will be used over a connection from the Requesting User's Web Browser (WC) to an Intermediate Web Server (WS). This will be closely associated with a PINT Client (using some unspecified mechanism to transfer the data from the Web Server to the PINT Client). The PINT Client will represent the Requesting User to the PINT Server, and thus to the Executive System that carries out the required action. [WC]------[WS] [PC] \ \ [PS] [XS] 6.2 Redirects to Multiple Servers It is quite possible that a given PINT Server is associated with an Executive System (or systems) that can connect to the GSTN at different places. If there is a chain of PINT Servers, then equally each of these Servers may be able to route PINT requests to Executive Systems that connect at specific points to the GSTN. The result of this is that there may be more than one PINT Server or Executive System that can deal with a given request. The mechanisms by which the choice on where to deliver a request are outside the scope of this document. However, there do seem to be two approaches. Either a Server that acts as a proxy or redirect will select the appropriate server itself and will cause the request to be sent on accordingly, or a list of possible Locations will be returned to the Requesting User from which they can select their choice. In the SIP document, the implication is that, if a proxy cannot resolve to a single unique match for a request destination, then a response containing a list of the choices should be returned to the Requesting User for selection. This is not too likely a scenario within the normal use of SIP. However, within PINT, such ambiguity may be quite common; it implies that there are a number of possible providers of a given service. 6.3 Competing PINT gateways REGISTERing to offer the same service With PINT, the registration is not for an individual but instead for a service that can be handled by a service provider. Thus, one can envisage a registration by the PINT Server of the domain telcoA.com of its ability to support the service R2T as "R2T@telcoA.com", sent to an intermediary server that acts as registrar for the "broker.telcos.com" domain from "R2T@pint.telcoA.com" as follows: REGISTER sip:@broker.telcos.com SIP/2.0 To:sip:R2T@pint.telcoA.com From:R2T@pint.telcoA.com ... This is the standard SIP registration service. However, what happens if there are a number of different Service Providers, all of whom support the "R2T" service? Suppose there is a PINT system at domain "broker.com". PINT clients requesting a Request to Talk service from broker.com might be very willing to be redirected or proxied to any one of the various service providers which had previously registered with the registrar. And PINT servers might be interested in providing service for requests that did not specify the service provider explicitly, as well as those requests that were directed "at them". To enable such service, PINT servers would REGISTER at the broker PINT server registrations of the form: REGISTER sip:host@broker.com SIP/2.0 To:sip:R2T@broker.com From:sip:R2T@pint.telcoA.com [??? if sip:R2T is a valid URL, I would rather that this appeared in the To: line] When several such REGISTER messages appear at the registrar, each differing only in the URL in the From: line, the registrar has many possibilities, e.g.: (i) it overwrites the prior registration for "R2T@broker.telcos.com" when the next comes in; (ii) it rejects the subsequent registration for "R2T@broker.telcos.com"; (iii) it maintains all such registrations. In this last case, on receiving an Invitation for the "general" service, either: (iii.1) it passes on the invitation to all registered service providers, returning a collated response with all acceptances, using multiple Location: headers, or (iii.2) it silently selects one of the registrations (using, for example, a "round robin" approach) and routes the Invitation and response onwards without further comment. (iv) may choose to not allow registrations for the "general" service, rejecting all such REGISTER requests. 6.4 Relation to Intelligent Network and Public Network Standards The PINT profile for SIP and SDP is used to pass requests to Executive Systems, where the requests can be serviced. In the particular case when the Executive Systems are attached to Intelligent Network (I.N.) systems or other Public Network systems operation with these requires development work on protocols and functions to be carried within the GSTN (specifically within the I.N. systems). There are several groups responsible for developing standards on the operation (within the GSTN) of associated I.N. functions and protocols. PINT systems and GSTN systems operating as specified by other groups may well be part of the same overall system used to provide services, so it is useful to provide an overview of the relevant Telecommunications standards. 6.4.1 ITU-T The International Telecommunications Union - Telecommunications standardisation sector (usually known as ITU-T) has a significant group working on the development of the Intelligent Network recommendations. In particular, Study Group 11 has responsibility for this task, and within it work is being carried out into the development of a new Distributed Functional Plane architecture (by SG11.4), and into new extensions to Intelligent Network Application Part (INAP) protocol to be used between units in an Intelligent Network configuration (SG11.22). Their current plan is for Internet requests to be supported in the Recommendations that are part of the "Capability Set 4" (IN-CS4) series. Work on IN-CS4 is intended to be complete by December 1999, and it seems likely that the profile proposed in this document can be used to deliver PINT requests into such a system. Assuming that work on the Internet Protocols and this profile will be complete before the CS4 development in the ITU-T, it can be fed into the work of those ITU-T groups, so helping compatibility. Note that this is an ITU-T problem, not one for the Internet community, but it is important to be aware of the standardisation context and how they may be used. 6.4.2 ETSI ETSI (European Telecommunications Standards Institute) is the body with responsibility (within Europe) for taking ITU-T specifications and producing profiles that allow a high degree of interoperation of Telecommunications Networks. They have produced profiles for IN-CS1 and IN-CS2 INAP protocols (called "ETSI Core INAP"). The ETSI NA6 group has started working on Next-generation I.N. systems & extensions to Core- INAP for Internet support, and has produced contributions to the ITU-T work to ensure alignment of their efforts. 6.4.3 ANSI The Telecommunications Standards body with particular interest in North America is ANSI (American National Standards Institute), and, within that body, the T1S1 group is concerned with Intelligent Network systems. On the "Support for Internet" question, there has been a trend for ideas from this body to be introduced into the appropriate ITU-T study groups. Thus, although there does not appear to be a separate development being carried out within ANSI, this is simply due to the fact that the ideas are passed directly on to ITU-T and influence the ITU-T documents in that way. 6.4.4 Other Standards There are other groups working on related areas. For example, there are proposals within the IETF for development of Protocol Mapping gateways between the IP networks and networks carrying Signalling System Number 7 (SS#7) messages, as are commonly used within Telecommunications Networks. In principle, protocol mapping can be to deliver a service request as well. This would appear to perform a similar task to that presented with the PINT profile. However, the degree of coupling between the states within the SS#7 network and that within the Internet-based Requestors is much greater when using direct protocol mapping. The end result may be the same, but the means by which that result is achieved differs. The thrust of the PINT profile is to deliver the "intent" of a customer's request towards an Executive System on the GSTN, whilst the other approach ties the lower level semantics (or even the syntax) of the request to that used on the GSTN. PINT fits telephone-network-based multimedia conference set-up into the larger context of general multimedia conference set-up, rather than into the context of telephone network protocols. PINT is designed to deliver requests without the use of direct protocol mapping to Intelligent Network Application Part (INAP) messages. It could equally be used where the Executive System was not associated with an SS#7 network. This allows implementations to be developed relatively easily; an SS#7 network is not required to implement or deploy PINT. Also, it makes PINT development and standardisation orthogonal to any Intelligent Network standardisation; development of protocol mappings between IP networks and GSTN Telecommunications Signalling Networks are intimately dependent on the GSTN signalling standards. 6.5 Relation between PINT Milestone services and ITU-T Q.1231 [[[??? Q.1231 is a *draft* document. If we include this section, it must say that details may change] There are services descriptions made in the ITU-T which are similar to the PINT milestone services, and the relationship between the two descriptions is discussed here. After this, a description is given of the parameters that will be transferred from a Requestor to the eventual PINT Server that is associated with an Executive System that performs the ITU-T service. Finally, an example of the way in which these parameters might be included in messages fitting the PINT profiles for SIP and SDP is given. 6.5.1 PINT Services The ITU-T Intelligent Network Outline Service Definitions for Capability Set 3 (the next development phase in the Intelligent Network) are included in the ITU-T draft document Q.1231 [11]. This document includes descriptions of four services initially identified by the PINT Working Group and that are taken as "benchmarks" for the PINT profiles of SIP and SDP. These services are: Click-to-Dial-Back, Click-to-Fax, Click-to- Fax-Back and (Internet-Initiated) Voice-Access-to-Content. Within the ITU-T definitions below, note that the word "click" should not be taken literally. It is rather used to point out that initiation of the related services takes place on the Internet, where point and click are the most prevalent user actions. In other words, a service request could originate from any type of IP-based platforms. There is no implication that these services must be implemented by a device within the PSTN or the Internet running a Web server. The common denominator of the PINT services is that they combine the Internet and PSTN services in such a way that the Internet is used for non-voice interactions, while the voice (and fax) are carried entirely over the PSTN. 6.5.1.1 Click-to-Dial-Back (CTDBC) With this service, a user requests (through an IP host) that the PSTN call be established between another party and himself or herself. An important pre-requisite for using this service is that the user has simultaneous access to both the PSTN and Internet. 6.5.1.2 Click-to-Fax (CLTFA) With this service, a user at an IP host requests that a fax be sent to a particular fax number. In particular this service is especially meaningful when the fax is to be sent to someone who has only a fax machine (but no access to the Internet). 6.5.1.3 Click-to-Fax-Back (CLTFB) With this service, a user at an IP host can request that a fax be sent to him or her. 6.5.1.4 (Internet-Initiated) Voice-Access-to-Content (VATCI) With this service, a user at an IP host requests that certain information on the Internet be accessed (and delivered) in an audio form over the PSTN, using the telephone as an informational appliance. 6.5.1.5 PINT vs. ITU-T service descriptions Within this profile, the service definitions have been specified in a more precise way, whilst still reflecting the services as described in the Draft Q.1231 document. Thus, Click-to-Dial-Back as described in the ITU-T document is a special case of the more general two-party Request- to-Talk service mentioned earlier in this profile, the Click-to-Fax and Click-to-Fax-Back are both cases of a Request-to-Fax, and the (Internet-Initiated) Voice-Access-To-Content ITU-T definition is called Request-to-Hear-Content. Within the ITU-T service descriptions there is an important difference between the Click-to-Fax-Back and Click-to-Fax service. In the "Fax" case the source document is sent from "the Internet" towards the PSTN. With the "Fax-Back" case, the source document is stored within "the PSTN" (and the Requesting User is implied to be the same as the destination party for the resulting service PSTN call). Also, the ITU-T Click-to-Dial-Back description given above implies that the Requesting User (as defined earlier in this document) is one of the parties to the resulting service PSTN call. We have chosen to use a more general description for the Request-to-Talk definition shown in section 2 of this profile; the Click-to-Dial-Back description is a pure subset of the Request-to-Talk service, in which the Requesting User role is shared by the same person as one of the parties to the PSTN call. 6.5.2 Parameters needed for PINT Services This section describes how parameters specified by ITU-T Q.1231 can be carried within PINT requests. 6.5.2.1 Service Identifier When a Requesting User asks for a service to be performed, they will, of course, has to specify which service in some way. This can be done within the URLs within the To: header and the Request-URI (see ) 6.5.2.2 A and B parties With the "Request-to-Talk" service, they will also need to specify the A and B parties they want to be engaged in the resulting service call. The A party could identify, for example, the Call Centre from which they want a call back, whilst the B party is their telephone number (i.e. who the Call Centre agent is to call). With the "Request-to-Fax-Back" service, they will also have specify two parties. As before, the B party is the telephone number of the fax machine to which they want a fax to be sent. However, within Q.1231 the A party identifies the "document context" for the PSTN-based document store from which a particular document is to be retrieved; the analogy here is to a PSTN user dialling a particular telephone number and then entering the document number to be returned using "touch tone" digits. The telephone number they dial is that of the document store or A party, with the "touch tone" digits selecting the document within that store. The "Request-to-Fax" and "Request-to-Hear-Content" services require the B party to be specified (respectively the telephone number of the destination Fax machine or the telephone to which spoken content is to be delivered), but the A party is a Telephone Network based resource (either a Fax or speech transcoder/sender), and is implicit; the Requesting User does not (and cannot) specify it. 6.5.2.3 Other Service Parameters In terms of the extra parameters to the request, the services again differ. The "Request-to-Talk" service needs only the A and B parties. Also it is convenient to assert that the resulting service call will carry voice, as the Executive System within the destination GSTN may be able to check that assertion against the A and B party numbers specified and may treat the call differently. The "Request-to-Fax-Back" service needs to specify the Document Store number and the Fax machine number to which the information is to be delivered. It is convenient to assert that the call will carry Fax data, as the destination Executive System may be able to check that assertion against the document store number and that of the destination Fax machine. In addition, the document number may also need to be sent. This parameter is an opaque reference that is carried through the Internet but has significance only within the GSTN. The document store number and document number together uniquely specify the actual content to be faxed. With the "Request-to-Fax" and "Request-to-Hear-Content" services, the source information to be transcoded is held on the Internet. That means either that this information is carried along with the request itself, or that a reference to the source of this information is given. In addition, it is convenient to assert that the service call will carry fax or voice, and, where possible, to specify the format for the source information. 6.5.2.4 Service Parameter Summary The following table summarises the information needed in order to specify fully the intent of a service request. Note that it excludes any other parameters (such as authentication or authorisation tokens, or Expires: or CallId: headers) that may be used in a request. Service ServiceID AParty BParty CallFmt Source SourceFmt ------- --------- ------ ------ ------- ------ ------- R2T x x x voice - - R2F x - x fax URI/IL ISF/ILSF R2FB x x x fax OR - R2HC x - x voice URI/IL ISF/ILSF In this table, "x" means that the parameter is required, whilst "-" means that the parameter is not required. The Call Format parameter values "voice" or "fax" indicate the kind of service call that results. The Source "URI/IL" implies either that the data is either an Internet source reference (a Universal Resource Identifier, or URI) or is carried "in-line" with the message. The Source indicator "OR" means that that the value passed is an Opaque Reference that should be carried along with the rest of the message but is to be interpreted only within the destination (GSTN) context. As an alternative, it could be given as a "local" reference with the "file" style, or even using a partial reference with the "http" style. However, the way in which such a reference is interpreted is a matter for the receiving PINT Server and Executive System; it remains, in effect, an opaque reference. The Source Format value "ISF/ILSF" means that the format of the source is specified either in terms of the URI or that it is carried "in-line". Note that, for some data, the format either can be detected by inspection or, if all else fails, can be assumed from the URI (for example, by assuming that the file extension part of a URL indicates the data type). For an opaque reference, the Source Format is not available on the Internet, and so is not given. 6.5.3 Parameter Mapping to PINT Profile This section describes the way in which the parameters needed to specify a Q.1231 request fully might be carried within a PINT profile message. There are other choices, and these are not precluded. However, in order to ensure that the Requesting User receives the service that they expect, it is necessary to have some shared understanding of the parameters passed and the behaviour expected of the PINT Server and its attendant Executive System. The Service Identifier can be sent as the userinfo element of the Request-URI. Thus, the first line of a PINT Invitation would be of the form: INVITE <serviceID>@<pint-server>.<domain> SIP/2.0 The A Party for the Request-To-Talk and Request-To-Fax-Back service can be held in the "To:" header field. In this case the "To:" header value will be different from the Request-URI. In the services where the A party is not specified, the "To:" field is free to repeat the value held in the Request-URI. This is the case for "Request-to-Fax" and "Request- to-Hear-Content" services. The B party is needed in all these milestone services, and can be held in the enclosed SDP sub-part, as the value of the "c=" field. The call format parameter can be held as part of the "m=" field value. It maps to the "transport protocol" element as described in section 3.4.2 of this document. The source format specifier is held in the "m=", as a type and optional sub-type. The latter is required for all services except "Request-to- Talk". As shown earlier, the source format and source are not always required when generating requests for services. However, the inclusion in all requests of a source format specifier can make parsing the request simpler and allows for other services to be specified in the future, and so values are always given. The source format parameter is covered in section 3.4.2 as the "media type" element. The source itself is identified by an "a=fmtp:" field value, where needed. With the exception of the "Request-to-Talk" service, all invitations will include such a field. From the perspective of the SDP profile, it can be considered as qualifying the media sub-type, as if to say, for example, "when I say jpeg, what I mean is the following". In summary, the parameters needed by the different services are carried in fields as shown in the following table: Service Svc Param PINT/SIP or SDP field used Example value ------- --------- -------------------------- ------------- R2T ServiceID: <SIP Request-URI userinfo> R2T BParty: <SIP To: field> sip:123@p.com AParty: <SDP c= field> TN RFCxxxx 4567 CallFormat: <SDP transport protocol sub-field of m= field> voice SourceFmt: <SDP media type sub-field of m= field> audio (--- No media sub-type sub-field value used) --- Source: (--- No source specified) --- R2F ServiceID: <SIP Request-URI userinfo> R2F BParty: (--- ) sip:R2F@pint.xxx.net AParty: <SDP c= field> TN RFCxxx +441213553 CallFormat: <SDP transport protocol sub-field of m= field> fax SourceFmt: <SDP media type sub-field of m= field> image <SDP media sub-type sub-field of m= field> jpeg Source: <SDP a=fmtp: field qualifying preceding m= field> a=fmtp:jpeg <URI> R2FB ServiceID: <SIP Request-URI userinfo> R2FB BParty: <SIP To: field> sip:1-730-1234@p.com AParty: <SDP c= field> TN RFCxxx +441213553 CallFormat: <SDP transport protocol sub-field of m= field> fax SourceFmt: <SDP media type sub-field of m= field> image <SDP media sub-type sub-field of m= field> X-OR Source: <SDP a=fmtp: field qualifying preceding m= field> a=fmtp:X-OR 1234 R2HC ServiceID: <SIP Request-URI userinfo> R2HC BParty: (--- SIP To: field not used) sip:R2HC@pint.ita.il AParty: <SDP c= field> TN RFCxxx +441213554 CallFormat: <SDP transport protocol sub-field of m= field> voice SourceFmt: <SDP media type sub-field of m= field> text <SDP media sub-type sub-field of m= field> html Source: <SDP a=fmtp: field qualifying preceding m= field> a=fmtp:html <URI> 7. Open Issues [All open issues are marked in the text above within square brackets and three question marks ???] [[??? lwc - Other Points to consider: (i) Who makes the decision on the PINT Server or Executive System that is offered any Invitation (where there is a possible choice)? (ii) What's the ->policy<- for that choice?, and: i) is it required to be auditable (i.e. one can prove that this policy has been carried out)? ii) is it required to be "fair" (and, if so, who decides what's "fair")? iii) Who or what sets policy for the decision?]]] 8. References 9. The authors wish to thank the members of the PINT working group for comments that were helpful to the preparation of this specification. In particular, Ian Elz's remarks about internal telephone network parameters was instrumental in the specification of section 3.5.6. 10. Author's Addresses: Scott Petrack VocalTec Communications Ltd. 1 Maskit Street Herzeliya 46733 Israel petrack@vocaltec.com Lawrence Conroy Roke Manor Research lwc@roke.co.uk
Datatracker
Report a datatracker bug
draft-ietf-pint-profile-00
Internet-Draft
| Document | Document type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Author | |||
| RFC stream |
|
||
| Other formats | |||
| Additional resources | Mailing list discussion |