Internet Engineering Task Force PINT WG INTERNET-DRAFT Scott Petrack draft-ietf-pint-profile-01.txt Lawrence Conroy 18 November 1998 Expires: 18 May 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 1.1 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 traditional 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 telephone network 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 SUBSCRIBE and NOTIFY requests 3.5.4 The "Require:" header for PINT 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 Parameters needed for PINT Services 6.4.1 Service Identifier 6.4.2 A and B parties 6.4.3 Other Service Parameters 6.4.4 Service Parameter Summary 6.5 Parameter Mapping to PINT Profile 7. Open Issues 8. References 9. Acknowledgements 10.Authors' 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 center 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. As examples, consider a user who wishes 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 "PSTN/Internet Interworking (PINT) Service" to denote such a complete transaction, starting with the sending of a request from an IP client and including the telephone call itself. PINT services are distinguished by the fact that they always involve two separate networks: an IP network to request the placement of a call, and a telephone network to execute the actual call. It is understood that Intelligent Network systems, private PBXs, cellular phone networks, and the ISDN can all be used to deliver PINT services. Also, the request for service might come from within a private IP network that is disconnected from the whole Internet. The requirements for the PINT protocol were deliberately restricted to providing the ability to invoke a small number of fixed telephone call services. These "Milestone PINT services" are specified in section 2. Great care has been taken, however, to develop a protocol that fits into the emerging Internet conference architecture [1], 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 [2] 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 [3] is used to describe the media to be exchanged within the session. The PINT protocol uses these two protocols together, providing some extensions and enhancements to enable SIP clients and servers to become PINT clients and servers. A PINT user who wishes to invoke a service within the telephone network uses SIP to invite a remote PINT server into a session. The invitation contains an SDP description of the media session that the user would like to take place. This might be a "sending a fax session" or a "telephone call session", for example. Acceptance of the invitation by the PINT server establishes a session between the client and server, in the context of 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. When used to invoke a PINT service, SIP establishes an association between a requesting PINT client and the PINT server which is responsible for invoking the service within the telephone network. These two entities are not the same entities as the telephone network entities involved in the telephone network service. The SIP messages carry within their SDP payloads a description of the telephone network media session. Note that the fact that a PINT server accepts an invitation and a session is established is no guarantee that the media will be successfully transported. The particular requirements of PINT users lead to some new messages. When PINT server agrees to send a fax to telephone B, it may be that the fax transmission fails after part of the fax is sent. Therefore, the PINT client may wish to receive information about the status of the actual telephone call session that was invoked as a result of the established PINT session. Two new requests, SUBSCRIBE and NOTIFY, are added here to vanilla SIP to allow this. The enhancements and additions specified here are not intended to alter the behaviour of baseline SIP or SDP in any way. The purpose of the PINT profile is to extend the usual SIP/SDP services to the telephone world. Apart from integrating well into existing protocols and architectures, and the advantages of reuse, this means that the protocol specified here can handle a rather wider class of call services than just the Milestone services. The rest of this document is organised as follows: Section 2 describes the original PINT Milestone services; 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 above phrase). 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 of a PINT Service, in accordance with this profile. PINT Gateway - 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. PINT Milestone Services The original motivation for defining this protocol was the desire to invoke the following three telephone network services from within an IP network: 2.1 Request to Call A request is sent from an IP host 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 details of the fax transmission are not accessible to the IP network, but remain entirely within the telephone network. The PINT Request to Fax service does not involve "Fax over IP": the IP network is only used to send the request that a certain fax be sent. Of course, it is possible that the resulting telephone network fax call happens to use a real-time IP fax solution, but this is completely transparent to the PINT transaction. 2.3 Request to Hear Content A request is sent from an IP host which causes a phone call to be made to user A, and for some sort of content to be spoken out. The request MUST EITHER contain a URL pointing to the content, OR include the content itself. The content MAY be text OR some other more general application data. The details of the content transmission are not accessible to the IP network, but remain entirely within the telephone network. 2.4 Relation between PINT milestone services and traditional telephone services There are many different versions and variations of each telephone call service invoked by a PINT request. Consider as an example what happens when a user requests to call 1-800-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. And once this choice is made, there may be many different ways to set up the call: the agent's phone might ring first, and only then the original user will be called; or perhaps the user might be called first, and hear some horrible music or pre-recorded message while the agent is located. Similarly, when a PINT request causes a fax to be sent, there are hundreds of fax protocol details to be negotiated, as well as transmission details within the telephone networks used. PINT requests do not specify too precisely the exact telephone-side service. Operational details of individual events within the telephone network that executes the request are outside the scope of PINT. This does not preclude certain high-level details of the telephone network session from being expressed within a PINT request. For example, it is possible to express a language preference for the Request-to-Hear-Content Service. If a particular PINT system wishes to allow requests to contain details of the telephone-network-side service, it uses the SDP attribute mechanism (see section 3.4.2). 3. PINT Functional and Protocol Architecture 3.1 PINT Functional Architecture Familiarity is assumed with SIP 2.0 [2] and with SDP 2.0 [3]. PINT clients and servers are 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 SDP is used to describe the telephone network session which is to be invoked or whose status is to be returned. A PINT system uses SIP proxy servers and redirect servers for their usual purpose, but at some point there must be a PINT server with the means to relay received requests into a telephone system and 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. Notice that a PINT gateway appears to the PINT infrastructure as if it represents a "user", while in fact it really represents an entire telephone network infrastructure which can provide a set of telephone network services. 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, 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. As an example, within an I.N. (Intelligent Network) system, the PINT gateway might appear to be an "Intelligent Peripheral" to the Telephone Network. In an office environment, it might be a server adjunct to the office PBX, connected to both the office LAN and the office PBX. The Executive System which lies beyond the PINT gateway is outside the scope of PINT. 3.2 PINT Protocol Architecture This section explains how SIP and SDP work in combination to convey the information necessary to invoke telephone network sessions. The SDP payload contains a description of the particular telephone network session which the requestor wishes to occur in the PSTN. This information includes such things as the telephone network address (i.e. the "telephone number") of the terminal(s) involved in 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 telephone network 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. SDP is flexibile enough to convey these parameters 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", 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 telephone network (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 3.4.5) f. New wildcard characters which allow a PINT gateway to register a range of service parameters (such as a range of telephone numbers that it can connect to, or a set of protocols that it can receive) (section 3.5.8). 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: g. The multipart MIME payloads (section 3.5.1) h. Mandatory support for "Warning:" headers (section 3.5.2) i. The SUBSCRIBE and NOTIFY request (section 3.5.3) j. Require: headers (section 3.5.4) k. A format for PINT URLS within a PINT request (section 3.5.5) l. Telephone Network Parameters within PINT URLs (section 3.5.6) m. Use of SDP payloads within REGISTER requests (section 3.5.7) n. Security mechanisms for third party authentication (section 5). Section 3.5.8 contains remarks about how BYE requests are used within PINT. This does not add anything to baseline SIP; it is included here for clarification of the semantics when used with telephone network sessions. 3.3 REQUIRED and OPTIONAL elements for PINT compliance Only the TN network type and the RFCxxxx address type are MANDATORY for PINT 1.0 clients and servers. Each of other new PINT constructs 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. For example, building a PINT client and server that provide only the Request-to-Call telephone call service, without support for the other Milestone services, is allowed. The "Require:" headers and the "strict" attribute provide a mechanism which can be used by clients and servers to signal their need and/or ability to support specific "new" PINT protocol elements. It should be noted that many optional features of SIP and SDP make sense as specified in the PINT context. One example is the SDP a=lang: attribute, which can 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 the PINT service is to be invoked. This is the normal 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 the underlying technical details and complexity of the telephone network. The only network type defined for PINT is the generic "TN" (Telephone Network). More precise tags such as "ISDN", "GSM", are not defined. Similarly, the transport protocols are designated simply as "fax", "voice", and "pager"; there are no more specific identifiers for the various telephone network voice, fax, or pager protocols. Similarly, the data to be transported is identified only as a MIME type, such as "text" data, "image" data, or some more general "application" data, etc. 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, speaking out to a Phone, will have to be invoked to perform this service. This section gives details of the 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 [6] RFC number or the SIP [2] 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 (this is specified in the SIP [2] or Telephony URL [6] RFC)]. Note that this BNF is not identical to the BNF which defines the "phone-number" within the "p=" field of SDP. 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 preceeding a global-phone-number with a "plus" sign ("+"). A global-phone-number is by default to be interpreted as an internationally significant E.164 number, as defined by [7]. 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 where "X-mytype.mydomain.com" identifies this private adress type, and "A*8-HELEN" is the number in this format. 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. 3.4.2 Media Types, Transport Protocol parameters, format parameters and format specific attributes for telephone network connected terminals To describe the media session that can be transported to telephone network terminals within telephone network 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 telephone network, although much of the semantic carry over without change to I.N. 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 [4]). The port number for PINT terminals MUST be 0. The allowed transport protocol keywords are "voice", "fax", and "pager". SDP format parameters and format specific attribute parameters are used to specify the content to be transported within the telephone network session: The format parameter must be a MIME sub-type of the media type indicated in the start of the m= line. Several format parameters may be included in a single "m=" line. This indicates alternative image formats of the same content which are available on the Internet to be used in this service. Format specific attributes are used to indicate the actual content to be transported to the remote terminal. When the data to be transmitted is pointed to by some URI, the syntax is as follows: a=fmtp:<fmt> <URIs> (See section 3.4.3 for the scenario in which the data to be transmitted is included within the request body). The <fmt> must match one 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. 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. Example: a=fmtp:tif http://www.tifserver.com/xxx.tif Each format within a media description has associated with it a single format specific attribute line. Within a single media description, all the attribute lines point to the same information to be sent over the telephone network. The PINT server can use ANY ONE of these formats and attribute lines to retrieve the data to be sent. The alternatives are listed in order of preference, with the primary preference first. If a single PINT request contains 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. These are to be sent serially, (one after the other), in the order of their appearance within the session description. The rest of this section lists the allowed transport protocols for each media type, and gives examples of the use of format parameters and format specific attribute parameters for sending content. Transport protocol "voice" MUST be used when the media type is "audio". If there is no transport protocol format parameter, this indicates a telephone network terminal which wishes to receive a "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 The allowed format parameters are any MIME subtype of MIME type audio (see [4]). The format specific attribute "a=fmtp:<fmt> <URIs>" MAY be used to include a URI which points to the audio data to be sent to the remote telephone network terminal (see section 3.2.3 below). As an example, the following excerpt from a session description describes a phone to which a certain ".wav" file can be played: c=TN RFCxxxx +12014064090 m=audio 0 voice wav a=fmtp:wav http://myserver/mymessage.wav Note: the notation is chosen to mimic usual SDP usage ([3]): m=audio <port> RTP/AVP 3 a=fmtp:3 <mycodec initialization parameters> Thus the URI is used as the "wav initialization parameters". 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 [4]). 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 fax machine or pager (see section 3.2.3 below). 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 allowed format parameters are any MIME subtype of MIME type text (see [4]). A given PINT gateway is not required to support any particular MIME sub-type. (A SIP error message with an appropriate Warning: header MUST be sent from a gateway which cannot support a requested MIME type). The format specific attribute tags ("a=fmtp:<fmt> <params>") are used to indicate the actual text to be sent over the Telephone Network to the remote terminal. 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 of using the media type "application" is to allow the associated format parameter "URI". This is used in combination with an attribute tag "a=fmtp:URI <URIs>" to point to some content on the Internet which is to be sent, via either "voice transport" or "fax transport", to the remote telephone network terminal. This is the generic way that a PINT request is made to fax or read-out some content pointed to by <URI> to the telephone network terminal indicated in the connection (c= ) line. An example is as follows: 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 (xxxx and then yyyy) over the telephone network to the phone terminal at address +1-201-406-4090. The two URIs are sent serially in the order of their appearance within the attribute line. This scheme is simple 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 as well as in some more simple generally-understood form). It also allows a single request to be used for sending multiple bits of content to the remote terminal. Using SDP to describe the session also allows the indication of things like a future date for the session, a language preference, etc. Note that different PINT requests might result in a similar service. For example, the following two descriptions might result in the same telephone network service: 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 Although it is possible that the same telephone-network service will result from these two requests, they 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 provides more information than the instruction to render media type application/URI. Using SDP in this way gives the client the flexibility to choose among more precise service descriptions, which the PINT gateway may not be able to fulfil, and less precise descriptions, which give the PINT gateway and telephone network more flexibility and control over the actual service invoked. It is not specified what happens should the content pointed to turn out to be of a different media type than the one indicated in the session description (just as it is not specified what happens in an ordinary internet audio session when a audio codec different from the one indicated in the session description is used). The media type "application" and sub-type "URI" are available to allow the PINT gateway to discover the actual media type during the content transfer. It is preferable to include the specific media type within the request, if it is available. 3.4.3 Format attributes for included content data As an alternative to pointing to the data via a URI, it is possible to include the content data within the SIP request itself. This is done by using multipart MIME for the SIP payload. The first MIME part contains the SDP description of the telephone network session to be executed. The other MIME parts contain the Content Data to be transported. Format specific attribute lines within the session description are used to indicate which other MIME part within the request contains the content data. Instead of a URI, the format-specific attribute indicates the Content-ID of the MIME part of the request that 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------- The ability to indicate different alternatives for the content to be transported is 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 [5] 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. 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. If the client does not know the actual location of the PINT gateway, and is using the SIP location services to find it, and the included data makes the PINT request likely to be transported in several IP datagrams, it is RECOMMENDED that the initial PINT request not include the data. It is possible to send a second modified request once the true location of the PINT gateway be known (although usually it should be possible to have the gateway retrieve the content via ftp or http). 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 that 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. 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: and From: headers and/or Request-URI, normally offer sufficient context to resolve telephone numbers. If the client wishes the request to fail if the attributes are not supported, these attributes should be used in conjunction with the "strict" attribute (section 3.4.5) and the "Require:org.ietf.ping.strict" header. (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 The phone-context attribute An 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; and dialling "+44 152" will not normally succeed. Such numbers are called Network-Specific Service Numbers. 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". 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> 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 examples 1 and 2 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 the Israeli cell phone providers, and *123 reaches customer service when dialled within that network. It may well be useful or necessary to use the SDP "strict" parameter in conjunction with the phone-context attribute. 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 telephone network variables over the IP network. We shall see an example of such usage in section 4. 3.4.5 The "strict" attribute 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 server 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 suitable Warning: lines 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 specification allows a server which does not understand the strict attribute to ignore it. In order to ensure that the PINT server will comply with the "strict" attribute, a PINT client 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 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. As discussed earlier, 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 so that it can signal lack of support for individual PINT features. As an example, suppose the PINT request is to send a jpeg picture to a fax machine, but the server cannot retrieve and/or translate jpeg pictures from the Internet into fax transmissions. In such a case the server fails the request and includes 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 implement Warning: headers to indicate that PINT extensions are not understood. Also, Warning: headers may be included within NOTIFY requests if it is necessary to notify the client about some condition concerning the invocation of the PINT service (see 3.5.3) 3.5.3 SUBSCRIBE and NOTIFY requests After a request is sent to invoke some telephone network session, it may be desired to see the status of the request or session. The request might come before, during, or after the session actually begins or ends. The request may also come from someone other than the original requestor. PINT systems use two methods, SUBSCRIBE and NOTIFY, to enable a client to receive the server's view of the status of sessions and of outstanding requests. The SUBSCRIBE request indicates that the client wishes to receive information about the status of a session. The request identifies the session of interest by including the original session description along with the request. Since the request may come from a user other than the original requesting user, the request may constitute a new call, so the Call-ID cannot be used. The request MUST NOT include whatever content was present in the original request, and a server MUST ignore whatever content is included within a SUBSCRIBE request. The request MUST contain a "Contact:" header, specifying the PINT server to which such information should be sent. It also MUST contain an Expires: header, which indicates for how long the requesting client wishes to receive notification of the session status. A value of 0 within the Expires: header indicates a desire to receive one single immediate response (i.e. the request expires immediately). We refer to the period of time before the expiration of the SUBSCRIBE request as the "subscription period". A successful response to the SUBSCRIBE request includes the session description, according to the server. Normally this will be identical to the last cached response that the server returned to any request concerning the same SDP global session id (see [SDP, RFC2327, section 6, page 8]). The t= line may be altered to indicate the actual start or stop time, however. The server might add an i= line to the session description to indicate such information as how many fax pages were sent. It is allowed to send a SUBSCRIBE request after the telephone network session has terminated. This allows, for example, checking up "the morning after" to see if the fax was successfully transmitted. But a PINT gateway is only required to keep state about a call for as long as it indicated previously in a Expires: header within the response to the SUBSCRIBE or within its BYE message (see section 3.5.7). If the Server no longer has a record of the session to which a client has SUBSCRIBEd, it returns "606 Not Acceptable", along with the appropriate Warning: header indicating that the SDP session ID is no longer valid. This means that a client which knows that it will want information about the status of a session after the session terminates SHOULD send a SUBSCRIBE request before the session terminates. During the subscription period, the server indicates any change in the status of the session to the client by sending a NOTIFY request to the server listed in the Contact: header within the original SUBSCRIBE method. The request contains the modified session description. For example, the server may be able to indicate a more accurate start or stop time. The server may include a Warning: header to describe some problem with the invocation of the service, and may indicate within an i= line some information about the telephone network session itself. Example: NOTIFY sip:petrack@pager.com SIP/2.0 To:sip:petrack@pager.com From:sip:R2F.pint.com@service.com Warning: xxx fax aborted, will try every 10 minutes for the next hour. Content-Type:application/sdp c=... i=3 pages of 5 sent t=... 3.5.4 The "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. PINT 1.0 defines two strings that can go into the Require header: org.ietf.sip.subscribe -- the server can fulfill SUBSCRIBE requests (section 3.5.3) org.ietf.sdp.strict -- the PINT server (or the SDP parser associated to it) understands the "strict" attribute defined in (section 3.4.5) Example: Require:org.ietf.sip.subscribe,org.ietf.sdp.strict A client should only include a Require: header where it truly requires the server to fail the request if the option is not supported. 3.5.5 PINT URLS within PINT requests Normally the hostnames and domain names that appear in 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. A PINT URL is used in two different ways within PINT requests: within the Request-URI, and within the To: and From: headers. Each use requires clarification in order to ensure smooth interworking with the Telephone Network serviced by the PINT infrastructure: 3.5.5.1 PINT URLS within Request-URIs There are some occasions when it may be useful, however, to indicate service information within the URL in a standardized way: a. it may not be possible to use SDP information to route the request if it is encrypted; b. it allows implementation which make use of I.N. "service indicators"; c. It enables multiple competing PINT gateways to REGISTER with a single "broker" server (proxy or redirect) (see section 3.5.8) For these reasons, the following conventions for URLs are to be used in PINT requests: 1. The user portion of a sip URL indicate the service to be requested. At present the following services are defined: R2C (for Request-to-Call) R2F (for Request-to-Fax) R2HC (for Request-to-Hear-Content) 2. The host portion of a sip URL contains the domain name of the PINT service provider. 3. A new url-parameter is defined to be "tsp" (for "telephone service provider"). This can be used to indicate the actual telephone network provider to be used to fulfil the PINT request. Thus, for example:- INVITE sip:R2C@pint.pintservice.com SIP/2.0 INVITE sip:R2F@pint.pintservice.com;tsp=telco.com SIP/2.0 INVITE sip:R2HC@pint.mycom.com;tsp=pbx23.mycom.com SIP/2.0 INVITE sip:13@pint.telco.com SIP/2.0 The user portions "R2C", "R2F", and "R2HC" are reserved for the PINT milestone services. Other user portions MUST be used in case the requested service is not one of the Milestone services. See section 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.5.2 PINT URLs within "To:" headers [??? The "To:" header often includes the phone number of the one of the parties of the PINT service. If the PINT URL in this "To:" header indicates an internationally significant E.164 number, then the interpretation of this number requires no further information. But it is perfectly legal for this URL to include alpha-numerics (such as "1-800-FLOWERS"), and in this case the PINT gateway which services the request may indeed require extra information ] 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 indicated in section 3.4.4 that it may be necessary to include more information in order correctly to identify the remote telephone terminal or service. PINT clients MAY include these attribute tags within PINT URLs if they are necessary or a useful complement to the telephone number within the SIP URL. These attribute tags MUST be included as URL parameters as defined in [2] (i.e. in the semi-colon separated manner). The following is an example of a PINT URL which contains extra attribute tags: sip:152@bt.co.uk;a=strict:phone-context;a=phone-context:+44 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. In this example, 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 3.5.7 REGISTER requests within PINT A PINT gateway is a SIP user agent server. User agent servers use the REGISTER request to tell a proxy or redirect server that it is available to "receive calls" -- i.e. to service requests. Thus a PINT gateway registers with a proxy or redirect server the service that is accessible via itself, while in SIP, a user registering his/her 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?] 3.5.8 BYE Requests in PINT The semantics of BYE requests within PINT requires some extra precision. One issue concerns conferences which "cannot be left", and the other concerns keeping call state after the BYE. The BYE request [2] is normally used to indicate that the originating entity no longer wishes to be involved in the specified call. The request terminates the call and the media session. Applying this model to PINT, if a PINT client makes a request to invoke a telephone call from A to B, a BYE request from the client, if accepted, should result in a termination of the phone call. A question arises when 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. Even if the call has started, 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 the fax in session. Another possibility 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. It is too late to send the BYE. In the case where the telephone network cannot terminate the call, the server MUST return a "606 Not Acceptable" response to the BYE, along with a session description which indicates the telephone network session which is causing the problem. Therefore, in PINT, a "Not Acceptable" response can be returned to INVITE or BYE requests. It indicates that some aspect of the session description makes the request unacceptable. By allowing a server to return it to BYE requests, we are not changing its semantics, just enlarging its use. A combination of Warning: headers and i= lines within the session description can be used to indicate the precise nature of the problem. Example: SIP/2.0 606 Not Acceptable From: ... To: ....... ..... Warning: 399 pint.mycom.com Fax in progress, service can not be aborted Content-Type: application/sdp Content-Length: 50 v=0 i=3 of 5 pages sent OK c=TN RFCxxxx +12014064090 m=image 0 fax tif a=fmtp:tif http://tifsRus.com/yyyyyy.tif Note that the server may return an updated session description within a successful response to a BYE as well. This can be used, for example, to indicate the actual start times and stop times of the telephone session, or how many pages were sent in the fax transmission. The second issue concerns how long must a server keep call state after receiving a BYE. A question arises because other clients might still which to send queries about the telephone network session which was the subject of the PINT transaction. Ordinary SIP semantics have three important implications for this situation: 1. A BYE indicates that the requesting client will clear out all call state as soon as it receives a successful response. A client SHOULD NOT send a SUBSCRIBE request after it has sent a BYE. 2. A server may return an Expires: header within a successful response to a BYE request. This indicates for how long the server will retain session state about the telephone network session. At any point during this time, a client may send a SUBSCRIBE request to the server to learn about the session state. 3. PINT servers which send BYE to a URL listed in the Contact: header of a client request need to be especially careful not to clear session state until after the successful response to the BYE is received. For example, it may be that the requesting client host is turned off when the telephone service is executed (and is therefore not available at the location previously specified in the Contact: attribute) to receive the PINT server's BYE. 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. C->S: INVITE sip:R2C@pint.mailorder.com SIP/2.0 Via: SIP/2.0/UDP 169.130.12.5 From: sip:anon-1827631872@chinet.net To: sip:+1-201-456-7890@iron.org;user=phone Call-ID: 19971205T234505.56.78@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 R2C@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 sip:marketing@pint.mailorder.com SIP/2.0 Via: SIP/2.0/UDP 169.130.12.5 From: sip:john.jones.3@chinet.net To: sip:mary.james@mailorder.com Call-ID: 19971205T234505.56.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= TN RFCxxxx +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. An implementation which cannot accept email-like URLs in the "To:" header must fail the request with a 606 Not Acceptable. Note that the sending PINT client "knows" that the PINT Gateway contacted with the "marketing@pint.mailorder.com" Request-URI is capable of processing the client request as expected. (see 3.5.5.1 for a discussion on this). Note also 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 sip:faxback@pint.mailorder.com SIP/2.0 Via: SIP/2.0/UDP 169.130.12.5 From: sip:john.jones.3@chinet.net To: sip:1-800-FAXBACK@steam.edu;user=phone;phone-context=+1 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 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. 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 sip:faxback@pint.mailorder.com SIP/2.0 Via: SIP/2.0/UDP 169.130.12.5 From: john.jones.3@chinet.net To: sip:1-800-FAXBACK@steam.edu;user=phone;phone-context=+1 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 sip:R2F@pint.pager.com SIP/2.0 Via: SIP/2.0/UDP 169.130.12.5 From: scott.petrack@chinet.net To: sip:R2F@pint.pager.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 sip:faxserver@pint.vocaltec.com SIP/2.0 Via: SIP/2.0/UDP 169.130.12.5 From: scott.petrack@chinet.net To: sip: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 sip:R2HC@pint.acme.com SIP/2.0 Via: SIP/2.0/UDP 169.130.12.5 From: scott.petrack@chinet.net To: sip:R2HC@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 network special resources, 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 the phone number of the fax server, 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 customer code and document code they wish to receive. Unfortunately the documents are not identified by URIs (the fax machines the customers use are not quite "intelligent" enough to send 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 sip:ivrfax@pint.operator.net SIP/2.0 Via: SIP/2.0/UDP 169.130.12.5 From: scott.petrack@chinet.net To: sip:+97252123456;user=phone 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=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. As an alternative, the telephone number shown in the To: header might be replaced by a SIP alias, as long as this is understood by the Gateway and can be translated as necessary. 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 "R2C%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 "R2C%att.com" or even to override all other registrations for "R2C". (by attempting such a registration with a "zero time" Expiry header).] 6. Deployment considerations and the Relationship PINT to I.N. (Informative) 6.1 Web Front End to PINT Infrastructure It is possible that some other protocol may 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. Equally, if there is a chain of PINT Servers, then each of these intermediate or proxy servers (PP) 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. [WC]------[WS] [WC]------[WS] [PC] [PC] \ \ \ \ [PS] [PP] .........[XS]......... / \ : : / \ [PS] [PS] [XS] [XS] 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 SIP, 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 R2C as "R2C@telcoA.com", sent to an intermediary server that acts as registrar for the "broker.telcos.com" domain from "R2C@pint.telcoA.com" as follows: REGISTER sip:registrar@broker.telcos.com SIP/2.0 To:sip:R2C@pint.telcoA.com From:R2C@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 "R2C" service? Suppose there is a PINT system at domain "broker.com". PINT clients requesting a Request-to-Call 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:registrar@broker.com SIP/2.0 To:sip:R2C@broker.com From:sip:R2C@pint.telcoA.com 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 "R2C@broker.telcos.com" when the next comes in; (ii) it rejects the subsequent registration for "R2C@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. As an alternative to all of the above approaches, it: (iv) may choose to not allow registrations for the "general" service, rejecting all such REGISTER requests. The algorithm by which such a choice is made will be implementation-dependent, and is outside the scope of PINT. Where a behaviour is to be defined by requesting users, then some sort of call processing language might be used to allow those clients, as a pre-service operation, to download the behaviour they expect to the server making such decisions. This, however, is a topic for other protocols, not for PINT. 6.4 Parameters needed for invoking traditional PSTN Services within PINT This section describes how parameters needed to specify certain traditional PSTN services can be carried within PINT requests. 6.4.1 Service Identifier When a Requesting User asks for a service to be performed, he or she will, of course, have to specify which service in some way. This can be done within the URLs within the To: header and the Request-URI (see ) 6.4.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). 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. With the "Fax-Back" variant of the Request-to-Fax service, (i.e. where the content to be delivered resides on the GSTN) 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 this variant 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. 6.4.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. 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. The PSTN-based content or "Fax-Back" variant of the Request-to-Fax 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. 6.4.4 Service Parameter Summary The following table summarises the information needed in order to specify fully the intent of a PSTN 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 ------- --------- ------ ------ ------- ------ ------- R2C x x x voice - - R2F x - x fax URI/IL ISF/ILSF R2FB x x x fax OR - R2HC x - x voice URI/IL ISF/ILSF In this table, "x" means that the parameter is required, whilst "-" means that the parameter is not required. The Services listed are Request to Talk (R2C), Request to Fax (R2F), the PSTN-based content or "Fax-back" Variant of Request-to-Fax (R2FB), and Request-to-Hear-Content (R2HC). The Call Format parameter values "voice" or "fax" indicate the kind of service call that results. The Source Indicator "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 Parameter Mapping to PINT Profile This section describes the way in which the parameters needed to specify a PSTN service 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 "Fax-back" variant of Request-to-Fax service can be held in the "To:" header field. In this case the "To:" header value will be different from the Request-URI. 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 ------- --------- -------------------------- ------------- R2C ServiceID: <SIP Request-URI userinfo> R2C 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 ???] 8. References [1] M. Handley, J. Crowcroft, C. Bormann, and J. Ott, "The internet multimedia conferencing architecture", Internet Draft, Internet Engineering Task Force, July 1997. Work in progress. [2] M. Handley, E. Schooler, and H. Schulzrinne, "SIP: Session Initiation Protocol", Internet Draft, Internet Engineering Task Force, Nov 1998. Work in progress. [3] M. Handley and V. Jacobsen, "SDP: Session Description Protocol", RFC2327, Internet Engineering Task Force, April 1998. [4] N. Freed & N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC2046, November 1996. [5] The Unicode Consortium, "The Unicode Standard -- Version 2.0", Addison-Wesley, 1996. [6] A. Vaha-Sipila, "URLs for telephony", Internet Draft, Internet Engineering Task Force, Feb. 1998. Work in progress. [7] ITU-T Study Group 2, "E.164 - International Telecommunications Number Plan", ITU-T SG2 Report 8 of the period 1997-2000, August 1997. Work in progress. [8] H. Lu et al, "Toward the PSTN/Internet Inter-Networking--Pre-PINT Implementations", Informational RFC2458, Internet Engineering Task Force, Nov 1998. 9. The authors wish to thank the members of the PINT working group for comments that were helpful to the preparation of this specification. Ian Elz's comments were extremely useful to our understanding of internal PSTN operations. The SUBSCRIBE and NOTIFY requests were first suggested by Henning Schulzrinne and Jonathan Rosenberg. 10. Author's Addresses: Scott Petrack VocalTec Communications Ltd. 1 Maskit Street Herzeliya 46733 Israel petrack@vocaltec.com Lawrence Conroy Roke Manor Research Roke Manor Old Salisbury Lane Romsey, Hampshire U.K. SO51 0ZN lwc@roke.co.uk
Datatracker
Report a datatracker bug
draft-ietf-pint-profile-01
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 |