Internet Engineering Task Force MMUSIC WG Internet Draft Schulzrinne/Rosenberg draft-ietf-mmusic-sip-cc-00.txt Columbia U./Bell Laboratories March 13, 1998 Expires: August 1, 1998 SIP Call Control 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), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. ABSTRACT This document describes the org.ietf.sip.call extensions to the Session Initiation Protocol (SIP). The document also describes how standard telephony services can be implemented in SIP. 1 Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and indicate requirement levels for compliant SIP implementations. 2 Introduction This document describes the org.ietf.sip.call extensions to the Session Initiation Protocol (SIP) [2]. When using the extensions Schulzrinne/Rosenberg [Page 1]
Internet Draft SIP Call Control March 13, 1998 described here, the client MUST include the extension name in a Require header. 3 Headers type ACK BYE INV OPT REG _________________________________________________________ Accept-Location R - - o o - Also R - - o o - Also r - - o o - Call-Disposition R - o o - - Replaces R - - o o - Replaces r - - o o - Requested-By R - - o o - Requested-By r - - o o - Table 1: Summary of header fields. "o": optional, "m": mandatory, "- ": not applicable, "R': request header, "r": response header, "g": general header, "*": needed if message body is not empty. A numeric value in the "type" column indicates the status code the header field is used with. 3.1 Accept-Location The Accept-Location request header allows the caller to provide hints to proxy and redirect servers. It uses the same parameters as the Location header (Section 3.4). 3.2 Also The Also request and response header advises the recipient to issue INVITE requests to the addresses listed. Each of these invitations SHOULD contain a Requested-By header that contains the From field of the message containing the Also field. The Also header MUST only be processed by the calling or called user agent, not by any intermediate proxy or redirect servers. If a message contains both Also and Replaces, the invitations requested in the Also header MUST be completed, successfully or not, before the terminations requested in the Replaces header. Also = "Also" ":" 1#( SIP-URL | URI ) [ comment ] Schulzrinne/Rosenberg [Page 2]
Internet Draft SIP Call Control March 13, 1998 Example header: Also: sip://jones@foo.com, sip://mueller@bar.edu If A, B and C are end points, the following is a typical scenario: A -> B: INVITE B SIP/2.0 Call-ID: 19971214T123503.33@A Also: C From: A B -> A: SIP/2.0 200 OK Call-ID: 19971214T123503.33@A From: A B -> C: INVITE C SIP/2.0 Call-ID: 19971214T123503.33@A From: B Requested-By: A C -> B: SIP/2.0 200 OK Call-ID: 19971214T123503.33@A From: B If G is a group address with members X through Z, a group invitation may proceed as follows: A -> G: INVITE G SIP/2.0 From: A Call-ID: 19971214T124523.00@A G -> A: SIP/2.0 200 OK From: A Call-ID: 19971214T124523.00@A Also: X, Y, Z A -> X: INVITE X SIP/2.0 From: A Call-ID: 19971214T124523.00@A Requested-By: G A -> Y: INVITE Y SIP/2.0 From: A Call-ID: 19971214T124523.00@A Requested-By: G Schulzrinne/Rosenberg [Page 3]
Internet Draft SIP Call Control March 13, 1998 A -> Z: INVITE Z SIP/2.0 From: A Call-ID: 19971214T124523.00@A Requested-By: G The Also header makes it possible to create full meshes (generalized "three-way" calling) and supports the resolution of group addresses. Unlike the Location header, which enumerates alternatives to be tried, the Also header lists addresses to be all invited. 3.3 Call-Disposition The Call-Disposition request header field allows the client to indicate how the server is to handle the call. The following options can be used singly or in combination: all: If the user part of the SIP request address identifies a group rather than an individual, the " all" feature indicates to a proxy or redirect server that it should resolve the address to a list of group members and return a 300 (Multiple Choices) response. The list of group members is contained in an Also header. do-not-forward: The "do-not-forward" request prohibits proxies from forwarding the call to another individual (e.g., the call is personal or the caller does not want to be shunted to a secretary if the line is busy.) queue: If the called party is temporarily unreachable, e.g., because it is in another call, the caller can indicate that it wants to have its call queued rather than rejected immediately. If the call is queued, the server returns "181 Queued" (see Section 4.1). A pending call be terminated by a SIP BYE request. do-not-respond: The do-not-respond directive indicates to the callee that it should not issue a response, informational or final. This may be used to send invitations to multicast groups. Maybe the combination of do-not-respond and all could be used for group invitations to larger lists? Call-Disposition = "Call-Disposition" ":" 1#( "all" | "do-not-forward" Schulzrinne/Rosenberg [Page 4]
Internet Draft SIP Call Control March 13, 1998 | "queue" | "do-not-respond" ) Example: Call-Disposition: all, do-not-forward, queue 3.4 Location This document adds extension parameters to the Location header. extension-name = token extension-value = *( token | quoted-string | LWS | extension-specials) extension-specials = < any element of tspecials except <"> > language-tag = < see [H3.10] > priority-tag = "urgent" | "normal" | "non-urgent" service-tag = "fax" | "IP" | "PSTN" | "ISDN" | "pager" media-tag = Internet media type [ "/" subtype ] feature-list = "voice-mail" | "attendant" | "permanent" extension-attribute | "class" "=" ( "personal" | "business" ) | "description" "=" quoted-string | "duplex" "=" ( "full" | "half" | "receive-only" | "send-only" ) | "features" "=" 1# feature-list | "language" "=" 1# language-tag | "media" "=" 1# media-tag | "mobility" "=" ( "fixed" | "mobile" ) | "priority" "=" 1# priority-tag | "service" "=" 1# service-tag class: The class parameter indicates whether this terminal is found in a residential or business setting. (A caller may defer a personal call if only a business line is available, for example.) description: The description field further describes, as text, the terminal. It is expected that the user interface will render this text. duplex: The duplex parameter lists whether the terminal can Schulzrinne/Rosenberg [Page 5]
Internet Draft SIP Call Control March 13, 1998 simultaneously send and receive ("full"), alternate between sending and receiving ("half"), can only receive ("receive- only") or only send ("send-only"). Typically, a caller will prefer a full-duplex terminal over a half-duplex terminal and these over receive-only or send-only terminals. features: The feature list enumerates additional features of this address. The "permanent" flag indicates that this address is a new, permanent address. When used for registration, the server SHOULD return a 301 status instead of 302. language: The language parameter lists, in order of preference, the languages spoken by the person answering. This feature may be used to have a caller automatically select the appropriate attendant or customer service representative, without having to declare its own language skills. media: The media tag lists the media types supported by the terminal. Media types can be the standard Internet media types ("audio", "video", "text", "application"), optionally followed by a subtype (e.g., "text/html"). In addition, the type "application/email" is defined. mobility: The mobility parameter indicates if the terminal is fixed or mobile. In some locales, this may affect voice quality or charges. priority: The priority tag indicates the minimum priority level this terminal is to be used for. It can be used for automatically restricting the choice of terminals available to the user. service: The service tag describes what service is being provided by the terminal. Attributes which are unknown should be omitted. New tags for class- tag and service-tag can be registered with IANA. The media tag uses Internet media types, e.g., audio, video, application/x-wb. This is meant for indicating general communication capability, sufficient for the caller to choose an appropriate address. Location: sip://watson@worcester.bell-telephone.com ;q=0.7 ;service=IP,voice-mail ;media=audio+video+application/x-wb ;duplex=full Location: rtsp://tape.bell-telephone.com?watson482178 ;q=0.6 ;service=IP,voice-mail ;media=audio+video ;duplex=full Location: phone://1-415-555-1212 ;q=0.5 Schulzrinne/Rosenberg [Page 6]
Internet Draft SIP Call Control March 13, 1998 ;service=ISDN;mobility=fixed; language=en,es,iw Location: phone://1-800-555-1212 ;q=0.2 ;service=pager;mobility=mobile; duplex=send-only;media=text; priority=urgent; description="For emergencies only" Location: mailto:watson@bell-telephone.com ;q=0.1 ;media=application/email Location: http://www.bell-telephone.com/~watson ;q=0.1 ;service=text/html A 301 or 302 response MAY contain additional information in human- readable form, e.g., as Content-Type: text/html. It is up to the server issuing the Location header to ensure consistency between the content of the Location header and the response entity. 3.5 Replaces The Replaces request and response header is analogous to the Also header (Section 3.2, except that it asks the recipient to issue a BYE to the addresses listed, with the same Call-ID as the request containing the Replaces header. The special address "*" indicates that the recipient should replace all existing legs of the call within the Call-ID. If a message contains both Also and Replaces, the invitations requested in the Also header MUST be completed, successfully or not, before the terminations requested in the Replaces header. For example, with entities A, B and M (an MCU): A -> B: INVITE B SIP/2.0 Call-ID: 19971214T123503.33@A From: A B -> A: SIP/2.0 200 OK Call-ID: 19971214T123503.33@A From: A M -> B: INVITE B SIP/2.0 Call-ID: 19971214T123503.33@A From: M Replaces: * B -> M: SIP/2.0 200 OK Call-ID: 19971214T123503.33@A Schulzrinne/Rosenberg [Page 7]
Internet Draft SIP Call Control March 13, 1998 From: M B -> A: BYE A SIP/2.0 Call-ID: 19971214T123503.33@A From: B Requested-By: M A -> B: SIP/2.0 200 OK Call-ID: 19971214T123503.33@A From: A 3.6 Requested-By The Requested-By request header is only used in requests triggered by Also or Replaces. It contains the URI of the entity that issued the request containing the Also header. The URI is taken from the From header of the request. For example, if A sends an invitation to B containing Also: C, B issues an invitation to C with Requested- By: A. 4 Status Code Definitions This feature set defines one additional status code. 4.1 181 Queued The called party was temporarily unavailable, but the caller indicated via a "Call-Disposition: Queue" directive (Section 3.3) to queue the call rather than reject it. When the callee becomes available, it will return the appropriate final status response. The reason phrase MAY give further details about the status of the call, e.g., "5 calls queued; expected waiting time is 15 minutes". The server may issue several 181 responses to update the caller about the status of the queued call. 5 ISDN and Intelligent Network Services SIP may be used to support a number of ISDN [4] and Intelligent Network [5] telephony services, described below. Due to the fundamental differences between Internet-based telephony and conferencing as compared to public switched telephone network (PSTN)-based services, service definitions cannot be precisely the same. Where large differences beyond addressing and location of implementation exist, this is indicated below. The term address implies any SIP address. This section is for information and illustration only. There are many Schulzrinne/Rosenberg [Page 8]
Internet Draft SIP Call Control March 13, 1998 different ways of implementing services in SIP. Since SIP only describes the behavior induced by messages, different means of implementing services will interoperate. 5.1 Call Redirection and "Number"-Translation Services Call transfer (TRA) enables a user to transfer an established (i.e., active) call to a third party. SIP signals this via the Location header in the BYE method. Call forwarding (CF) permits the called user to forward particular pre-selected calls to another address. Unlike telephony, the choice of calls to be forwarded depends on program logic contained in any of the SIP servers and can thus be made dependent on time-of-day, subject of call, media types, urgency or caller identity, rather than being restricted to matching list entries. This forwarding service encompasses: Call forwarding busy/don't answer (CFB/CFNR, SCF-BY/DA) allows the called user to forward particular pre-selected calls if the called user is busy or does not answer within a set time. Selective call forwarding (SCF) permits the user to have her incoming calls addressed to another network destination, no matter what the called party status is, if the calling address is included in, or excluded from, a screening list. The user's originating service is unaffected. Destination call routing (DCR) allows customers to specify the routing of their incoming calls to destinations according to - time of day, day of week, etc.; - area of call origination; - network address of caller; - service attributes; - priority (e.g., from input of a PIN or password); - charge rates applicable for the destination; - proportional routing of traffic. In SIP, destination call routing is implemented by user agents, proxy and redirect servers that implement custom call handling logic, with parameters including, but not limited to the set listed above. Caller Schulzrinne/Rosenberg [Page 9]
Internet Draft SIP Call Control March 13, 1998 preferences are expressed in the Accept-Location header, callee preferences in the Location header. Follow-me diversion (FMD) allows the service subscriber to remotely control the redirection (diversion) of calls from his primary network address to other locations. In SIP, finding the current network-reachable location of a callee is left to the location service and is outside the scope of this specification. However, users may use the REGISTER method to appraise their "home" SIP server of their new location. Universal access number (UAN) allows a subscriber with several network addresses to be reached with a single, unique address. The subscriber may specify which incoming calls are to be routed to which address. SIP offers this functionality through proxies and redirection. Universal personal telecommunications (UPT) is a mobility service which enables subscribers to be reached with a unique personal telecommunication number (PTN) across multiple networks at any network access. The PTN will be translated to an appropriate destination address for routing based on the capabilities subscribed to by each service subscriber. A person may have multiple PTNs, e.g., a business and private PTN. In SIP, a host-independent address of the form user@domain serves as the PTN, which is translated into one or more host-dependent addresses. 5.2 Camp-on Completion of calls to busy subscriber (CCBS) allows a calling user encountering a busy destination to be informed when the busy destination becomes free, without having to make a new call attempt. SIP supports services close to CCBS by allowing a callee to indicate a more opportune time to call back with the Retry-After header. Also, calling and called user agents can easily record the URI of outgoing and incoming calls, so that a user can re-try or return calls with a single mouse click or automatically. Call-Disposition: queue allows a caller to wait until the line becomes available. This service is also known as a "camp-on" service. 5.3 Call Screening Originating call screening (OCS) controls the ability of a node to originate calls. In a fashion similar to closed user groups, a firewall would have to be used to restrict the ability to initiate SIP invitations outside a designated part of the network. In many Schulzrinne/Rosenberg [Page 10]
Internet Draft SIP Call Control March 13, 1998 cases, gateways to the PSTN will require appropriate authentication. 5.4 Directed Call Pickup Directed call pickup allows a station user to answer calls directed to a specific address from any other address by providing the address of the line to be answered. The rung station must permit pickup. If the call has not been answered at the ringing station, regular call pickup occurs. If the call has been answered already, an error is generated. 5.5 Directed Call Pickup with Barge-In Directed call pickup with barge-in establishes a 3-way call if the call has been answered at the original destination. 5.6 Outgoing Call Routing User-defined routing (UDR) allows a subscriber to specify how outgoing calls, from the subscriber's location, shall be routed. SIP cannot specify routing preferences; this is presumed to be handled by a policy-based routing protocol, source routing or similar mechanisms. However, the SIP Accept-Location header may be used by proxies and redirect servers to route calls according to caller preferences. 5.7 End-System Services Some telephony services can be provided by the end system, without involvement by SIP: Abbreviated dialing allows users to reach local subscribers without specifying the full address (domain or host name). For SIP, the user application completes the address to be a fully qualified domain name. Call waiting (CW) allows the called party to receive a notification that another party is trying to reach her while she is busy talking to another calling party. For SIP-based telephony, the called party can maintain several call presences at the same time, limited by local resources. Thus, it is up to the called party to decide whether to accept another call. The separation of resource reservation and call control may lead to the situation that the called party accepts the incoming call, but that the network or system resource allocation fails. This cannot be completely prevented, but if the likely resource bottleneck is at the local system, the user agent may be able to determine whether there Schulzrinne/Rosenberg [Page 11]
Internet Draft SIP Call Control March 13, 1998 are sufficient resources available or roughly track its own resource consumption. Consultation calling (COC) allows a subscriber to place a call on hold, in order to initiate a new call for consultation. In systems using SIP, consultation calling can be implemented as two separate SIP calls, possibly with the temporary release of reserved resources for the call being put on hold. Customized ringing (CRG) allows the subscriber to allocate a distinctive ringing to a list of calling parties. In a SIP-based system, this feature is offered by the user application, based on caller identification ( From header) provided by the SIP INVITE request. Malicious call identification (MCI) allows the service subscriber to control the logging (making a record) of calls received that are of a malicious nature. In SIP, by default, all calls identify the calling party and the SIP servers that have forwarded the call. In addition, calls may be authenticated using standard HTTP methods or transport-layer security. A callee may decide only to accept calls that are authenticated. Multiway calling (MWC) allows the user to establish multiple, simultaneous calls with other parties. For a SIP-based end system, the considerations for consultation calling apply. Terminating call screening (TCS) allows the subscriber to specify that incoming calls either be restricted or allowed, according to a screening list and/or by time of day or other parameters. 5.8 Billing Features Billing features such as account card dialing , automatic alternative billing , credit card calling (CCC) , reverse charging , freephone (FPH) , premium rate (PRM) and split charging are supported through authentication. However, mechanisms for indicating billing preferences and capabilities have not yet been specified for SIP. Advice of charge allows the user paying for a call to be informed of usage-based charging information. Charges incurred by reserving resources in the network are probably best indicated by a protocol closely affiliated with the reservation protocol. Advice of charge when using Internet-to-PSTN gateways through SIP appears feasible, but is for further study. Desirable facilities include indication of charges at call setup time, during the call and at the end of the call Schulzrinne/Rosenberg [Page 12]
Internet Draft SIP Call Control March 13, 1998 Closed user groups (CUGs) that restrict members to communicate only within the group can be implemented using firewalls and SIP proxies. 5.9 User-to-User Signaling User-to-user signaling is supported within SIP through the addition of headers, with predefined header fields such as Subject or Organization. 5.10 Operator Services There are a number of services which involve three parties, for example, a secretary dialing for boss, an auto-dialer handing a call to a telemarketer, attended call transfer, operator services such as person-to-person calls and full-mesh "multicast". Operator services can be implemented in a number of ways, combining Also, Replaces with either INVITE or BYE. The callee's end system does not have to be cognizant of the fact that this an operator service. The services make use of the Call-ID rules that stipulate that a new INVITE for an existing Call-ID does not alert the user, but is added silently. Figure 1 shows the example of an autodialer connecting to a prospective customer and, once the callee picks up, transfering the call to the telemarketer. (This goes to show that SIP is morally neutral.) telemarketer T ------------. n ^ : ----> nth step; INVITE (Also:) | : ....> nth step; BYE (Also:) 2(C) | : 4 3( | : ( | V 5 V .................> A C -----------------> auto dialer 1 customer Figure 1: Telemarketer example 5.11 Multipoint Control Unit (MCU) Services Schulzrinne/Rosenberg [Page 13]
Internet Draft SIP Call Control March 13, 1998 In the language of IN services, SIP supports: Conferencing (CON) allows the user to communicate simultaneously with multiple parties, which may also communicate among themselves. SIP can initiate IP multicast conferences with any number of participants, conferences where media are mixed by a conference bridge (multipoint control unit or MCU) and, for exceptional applications with a small number of participants, fully-meshed conferences, where each participant sends and receives data to all other participants. This is described in more detail in Sections 5.11 and 5.12. Conference calling add-on allows a user to add and drop participants once the conference is active. Participants in the SIP session accomplish this by sending INVITE and BYE requests to the parties to be added and dropped. If A wants B to drop out of a conference, it sends a BYE request with " Replaces: *". Conference calling meet-me (MMC) allows the user to set up a conference or multi-party call, indicating the date, time, conference duration, conference media and other parameters. The conference session description included in the SIP invitation may indicate a time in the future. For multicast conferences, participants do not have to connect using SIP at the actual time of the conference; instead, they simply subscribe to the multicast addresses listed in the announcement. For MCU-based conferences, the session description may contain the address of the MCU to be called at the time of the conference. Some conferences use a multipoint control unit (MCU) to mix, convert and replicate media streams. While this solution has scaling problems, it is widely deployed in traditional telephony and ISDN conferencing settings, as so-called conference bridges. In a MCU- based conference, the conference initiator or any authorized member invites a new participant and indicates the address of the MCU in the Also header. The invitee then contacts the MCU using the same session description and requests to be added to the call, just like a normal two-party call. Parties inviting others to a conference do not have to know that the conference media is managed by an MCU. The inviting party A treats the MCU M like another participant and includes it in the Also list. The newly invited participant B invites the MCU, which in turn sends a Replaces header with all participants. (See example in Section 3.5). Figure 2 shows the transition from a fully-meshed conference (see below) to an MCU-based conference. Schulzrinne/Rosenberg [Page 14]
Internet Draft SIP Call Control March 13, 1998 MCU MCU -----------, 1 ^ 2 | Also:B / Replace:A | / | / 3 V | A........B A.<xxxxx.B | : : : : : ^ : ^ | : : : : : x : x 4| Replace: A,B : :: : : 6 x: x 5 | : :: : : :x x | : : : : : : x x | : : : : : : x x | D........C D........C <------' ----> INVITE xxxx> BYE Figure 2: Transition from fully-meshed to MCU-based conference Operator-assisted dial-out: The operator calls each participant, and simply indicates the MCU in the Also list. The Call-ID and/or the address used by the operator serves as the identifier to the MCU. For example: O -> A: INVITE A SIP/2.0 From: O Also: conference176@M A -> M: INVITE conference176@M Requested-By: O Meet-me: The leader and participants dial into their conference at the scheduled time with an assigned conference identifier and security code. A -> M: INVITE conference189@M From: A 5.12 Fully-Meshed Conferences Schulzrinne/Rosenberg [Page 15]
Internet Draft SIP Call Control March 13, 1998 For very small conferences, such as adding a third party to a two- party call, multicast may not always be appropriate or available. Instead, when inviting a new participant, the caller asks the new member to call the remaining members. The Call-ID for all participants is the same. 6 Acknowledgements Parameters of the terminal negotiation mechanism in the Location header were influenced by Scott Petrack's CMA design. 7 Bibliography [1] S. Bradner, "Key words for use in RFCs to indicate requirement levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. [2] M. Handley, H. Schulzrinne, and E. Schooler, "SIP: Session initiation protocol," Internet Draft, Internet Engineering Task Force, Nov. 1997. Work in progress. [3] M. Handley and V. Jacobson, "SDP: Session description protocol," Internet Draft, Internet Engineering Task Force, Mar. 1997. Work in progress. [4] International Telecommunication Union, "Integrated services digital network (ISDN) service capabilities -- definition of supplementary services," Recommendation I.250, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, 1993. [5] International Telecommunication Union, "General recommendations on telephone switching and signaling -- intelligent network: Introduction to intelligent network capability set 1," Recommendation Q.1211, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, Mar. 1993. Table of Contents 1 Terminology ......................................... 1 2 Introduction ........................................ 1 3 Headers ............................................. 2 3.1 Accept-Location .................................... 2 3.2 Also ............................................... 2 3.3 Call-Disposition ................................... 4 Schulzrinne/Rosenberg [Page 16]
Internet Draft SIP Call Control March 13, 1998 3.4 Location ........................................... 5 3.5 Replaces ........................................... 7 3.6 Requested-By ....................................... 8 4 Status Code Definitions ............................. 8 4.1 181 Queued .......................................... 8 5 ISDN and Intelligent Network Services ............... 8 5.1 Call Redirection and "Number"-Translation Services ................................................................ 9 5.2 Camp-on ............................................. 10 5.3 Call Screening ...................................... 10 5.4 Directed Call Pickup ................................ 11 5.5 Directed Call Pickup with Barge-In .................. 11 5.6 Outgoing Call Routing ............................... 11 5.7 End-System Services ................................. 11 5.8 Billing Features .................................... 12 5.9 User-to-User Signaling .............................. 13 5.10 Operator Services ................................... 13 5.11 Multipoint Control Unit (MCU) Services .............. 13 5.12 Fully-Meshed Conferences ............................ 15 6 Acknowledgements .................................... 16 7 Bibliography ........................................ 16 Schulzrinne/Rosenberg [Page 17]
