idnits 2.17.1 draft-ietf-mmusic-sip-cc-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 10 instances of too long lines in the document, the longest one being 17 characters in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 48: '...here, the client MUST include the exte...' RFC 2119 keyword, line 80: '... SHOULD contain a Requested-By head...' RFC 2119 keyword, line 81: '...Also field. The Also header MUST only...' RFC 2119 keyword, line 86: '...the Also header MUST be completed, su...' RFC 2119 keyword, line 225: '... SHOULD return a 301 status ins...' (3 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 32 has weird spacing: '...bes the org.i...' == Line 46 has weird spacing: '...bes the org.i...' == Line 65 has weird spacing: '...": not appli...' == Line 168 has weird spacing: '...nd: The do-no...' == Line 188 has weird spacing: '...ment of tspec...' == (1 more instance...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 13, 1998) is 9540 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 688 looks like a reference -- Missing reference section? '2' on line 691 looks like a reference -- Missing reference section? '4' on line 699 looks like a reference -- Missing reference section? '5' on line 704 looks like a reference -- Missing reference section? '3' on line 695 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 8 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force MMUSIC WG 3 Internet Draft Schulzrinne/Rosenberg 4 draft-ietf-mmusic-sip-cc-00.txt Columbia U./Bell Laboratories 5 March 13, 1998 6 Expires: August 1, 1998 8 SIP Call Control Services 10 STATUS OF THIS MEMO 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as ``work in progress''. 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Distribution of this document is unlimited. 30 ABSTRACT 32 This document describes the org.ietf.sip.call extensions 33 to the Session Initiation Protocol (SIP). The document 34 also describes how standard telephony services can be 35 implemented in SIP. 37 1 Terminology 39 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 40 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 41 and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and 42 indicate requirement levels for compliant SIP implementations. 44 2 Introduction 46 This document describes the org.ietf.sip.call extensions to the 47 Session Initiation Protocol (SIP) [2]. When using the extensions 48 described here, the client MUST include the extension name in a 49 Require header. 51 3 Headers 53 type ACK BYE INV OPT REG 54 _________________________________________________________ 55 Accept-Location R - - o o - 56 Also R - - o o - 57 Also r - - o o - 58 Call-Disposition R - o o - - 59 Replaces R - - o o - 60 Replaces r - - o o - 61 Requested-By R - - o o - 62 Requested-By r - - o o - 64 Table 1: Summary of header fields. "o": optional, "m": mandatory, "- 65 ": not applicable, "R': request header, "r": response header, "g": 66 general header, "*": needed if message body is not empty. A numeric 67 value in the "type" column indicates the status code the header field 68 is used with. 70 3.1 Accept-Location 72 The Accept-Location request header allows the caller to provide 73 hints to proxy and redirect servers. It uses the same parameters as 74 the Location header (Section 3.4). 76 3.2 Also 78 The Also request and response header advises the recipient to issue 79 INVITE requests to the addresses listed. Each of these invitations 80 SHOULD contain a Requested-By header that contains the From field 81 of the message containing the Also field. The Also header MUST only 82 be processed by the calling or called user agent, not by any 83 intermediate proxy or redirect servers. 85 If a message contains both Also and Replaces, the invitations 86 requested in the Also header MUST be completed, successfully or not, 87 before the terminations requested in the Replaces header. 89 Also = "Also" ":" 1#( SIP-URL | URI ) [ comment ] 90 Example header: 92 Also: sip://jones@foo.com, sip://mueller@bar.edu 94 If A, B and C are end points, the following is a typical scenario: 96 A -> B: INVITE B SIP/2.0 97 Call-ID: 19971214T123503.33@A 98 Also: C 99 From: A 100 B -> A: SIP/2.0 200 OK 101 Call-ID: 19971214T123503.33@A 102 From: A 103 B -> C: INVITE C SIP/2.0 104 Call-ID: 19971214T123503.33@A 105 From: B 106 Requested-By: A 107 C -> B: SIP/2.0 200 OK 108 Call-ID: 19971214T123503.33@A 109 From: B 111 If G is a group address with members X through Z, a group invitation 112 may proceed as follows: 114 A -> G: INVITE G SIP/2.0 115 From: A 116 Call-ID: 19971214T124523.00@A 118 G -> A: SIP/2.0 200 OK 119 From: A 120 Call-ID: 19971214T124523.00@A 121 Also: X, Y, Z 123 A -> X: INVITE X SIP/2.0 124 From: A 125 Call-ID: 19971214T124523.00@A 126 Requested-By: G 128 A -> Y: INVITE Y SIP/2.0 129 From: A 130 Call-ID: 19971214T124523.00@A 131 Requested-By: G 133 A -> Z: INVITE Z SIP/2.0 134 From: A 135 Call-ID: 19971214T124523.00@A 136 Requested-By: G 138 The Also header makes it possible to create full meshes 139 (generalized "three-way" calling) and supports the 140 resolution of group addresses. Unlike the Location header, 141 which enumerates alternatives to be tried, the Also header 142 lists addresses to be all invited. 144 3.3 Call-Disposition 146 The Call-Disposition request header field allows the client to 147 indicate how the server is to handle the call. The following options 148 can be used singly or in combination: 150 all: If the user part of the SIP request address identifies a group 151 rather than an individual, the " all" feature indicates to a 152 proxy or redirect server that it should resolve the address to a 153 list of group members and return a 300 (Multiple Choices) 154 response. The list of group members is contained in an Also 155 header. 157 do-not-forward: The "do-not-forward" request prohibits proxies from 158 forwarding the call to another individual (e.g., the call is 159 personal or the caller does not want to be shunted to a 160 secretary if the line is busy.) 162 queue: If the called party is temporarily unreachable, e.g., because 163 it is in another call, the caller can indicate that it wants to 164 have its call queued rather than rejected immediately. If the 165 call is queued, the server returns "181 Queued" (see Section 166 4.1). A pending call be terminated by a SIP BYE request. 168 do-not-respond: The do-not-respond directive indicates to the callee 169 that it should not issue a response, informational or final. 170 This may be used to send invitations to multicast groups. 172 Maybe the combination of do-not-respond and all could be 173 used for group invitations to larger lists? 175 Call-Disposition = "Call-Disposition" ":" 1#( "all" | "do-not-forward" 176 | "queue" | "do-not-respond" ) 178 Example: 180 Call-Disposition: all, do-not-forward, queue 182 3.4 Location 184 This document adds extension parameters to the Location header. 186 extension-name = token 187 extension-value = *( token | quoted-string | LWS | extension-specials) 188 extension-specials = < any element of tspecials except <"> > 189 language-tag = < see [H3.10] > 190 priority-tag = "urgent" | "normal" | "non-urgent" 191 service-tag = "fax" | "IP" | "PSTN" | "ISDN" | "pager" 192 media-tag = Internet media type [ "/" subtype ] 193 feature-list = "voice-mail" | "attendant" | "permanent" 195 extension-attribute | "class" "=" ( "personal" | "business" ) 196 | "description" "=" quoted-string 197 | "duplex" "=" ( "full" | "half" | 198 "receive-only" | "send-only" ) 199 | "features" "=" 1# feature-list 200 | "language" "=" 1# language-tag 201 | "media" "=" 1# media-tag 202 | "mobility" "=" ( "fixed" | "mobile" ) 203 | "priority" "=" 1# priority-tag 204 | "service" "=" 1# service-tag 206 class: The class parameter indicates whether this terminal is found 207 in a residential or business setting. (A caller may defer a 208 personal call if only a business line is available, for 209 example.) 211 description: The description field further describes, as text, the 212 terminal. It is expected that the user interface will render 213 this text. 215 duplex: The duplex parameter lists whether the terminal can 216 simultaneously send and receive ("full"), alternate between 217 sending and receiving ("half"), can only receive ("receive- 218 only") or only send ("send-only"). Typically, a caller will 219 prefer a full-duplex terminal over a half-duplex terminal and 220 these over receive-only or send-only terminals. 222 features: The feature list enumerates additional features of this 223 address. The "permanent" flag indicates that this address is a 224 new, permanent address. When used for registration, the server 225 SHOULD return a 301 status instead of 302. 227 language: The language parameter lists, in order of preference, the 228 languages spoken by the person answering. This feature may be 229 used to have a caller automatically select the appropriate 230 attendant or customer service representative, without having to 231 declare its own language skills. 233 media: The media tag lists the media types supported by the terminal. 234 Media types can be the standard Internet media types ("audio", 235 "video", "text", "application"), optionally followed by a 236 subtype (e.g., "text/html"). In addition, the type 237 "application/email" is defined. 239 mobility: The mobility parameter indicates if the terminal is fixed 240 or mobile. In some locales, this may affect voice quality or 241 charges. 243 priority: The priority tag indicates the minimum priority level this 244 terminal is to be used for. It can be used for automatically 245 restricting the choice of terminals available to the user. 247 service: The service tag describes what service is being provided by 248 the terminal. 250 Attributes which are unknown should be omitted. New tags for class- 251 tag and service-tag can be registered with IANA. The media tag uses 252 Internet media types, e.g., audio, video, application/x-wb. This is 253 meant for indicating general communication capability, sufficient for 254 the caller to choose an appropriate address. 256 Location: sip://watson@worcester.bell-telephone.com ;q=0.7 257 ;service=IP,voice-mail 258 ;media=audio+video+application/x-wb ;duplex=full 259 Location: rtsp://tape.bell-telephone.com?watson482178 ;q=0.6 260 ;service=IP,voice-mail 261 ;media=audio+video ;duplex=full 262 Location: phone://1-415-555-1212 ;q=0.5 263 ;service=ISDN;mobility=fixed; 264 language=en,es,iw 265 Location: phone://1-800-555-1212 ;q=0.2 266 ;service=pager;mobility=mobile; 267 duplex=send-only;media=text; priority=urgent; 268 description="For emergencies only" 269 Location: mailto:watson@bell-telephone.com ;q=0.1 270 ;media=application/email 271 Location: http://www.bell-telephone.com/~watson ;q=0.1 272 ;service=text/html 274 A 301 or 302 response MAY contain additional information in human- 275 readable form, e.g., as Content-Type: text/html. It is up to the 276 server issuing the Location header to ensure consistency between the 277 content of the Location header and the response entity. 279 3.5 Replaces 281 The Replaces request and response header is analogous to the Also 282 header (Section 3.2, except that it asks the recipient to issue a 283 BYE to the addresses listed, with the same Call-ID as the request 284 containing the Replaces header. The special address "*" indicates 285 that the recipient should replace all existing legs of the call 286 within the Call-ID. If a message contains both Also and Replaces, 287 the invitations requested in the Also header MUST be completed, 288 successfully or not, before the terminations requested in the 289 Replaces header. 291 For example, with entities A, B and M (an MCU): 293 A -> B: INVITE B SIP/2.0 294 Call-ID: 19971214T123503.33@A 295 From: A 297 B -> A: SIP/2.0 200 OK 298 Call-ID: 19971214T123503.33@A 299 From: A 301 M -> B: INVITE B SIP/2.0 302 Call-ID: 19971214T123503.33@A 303 From: M 304 Replaces: * 306 B -> M: SIP/2.0 200 OK 307 Call-ID: 19971214T123503.33@A 308 From: M 310 B -> A: BYE A SIP/2.0 311 Call-ID: 19971214T123503.33@A 312 From: B 313 Requested-By: M 315 A -> B: SIP/2.0 200 OK 316 Call-ID: 19971214T123503.33@A 317 From: A 319 3.6 Requested-By 321 The Requested-By request header is only used in requests triggered 322 by Also or Replaces. It contains the URI of the entity that issued 323 the request containing the Also header. The URI is taken from the 324 From header of the request. For example, if A sends an invitation to 325 B containing Also: C, B issues an invitation to C with Requested- 326 By: A. 328 4 Status Code Definitions 330 This feature set defines one additional status code. 332 4.1 181 Queued 334 The called party was temporarily unavailable, but the caller 335 indicated via a "Call-Disposition: Queue" directive (Section 3.3) to 336 queue the call rather than reject it. When the callee becomes 337 available, it will return the appropriate final status response. The 338 reason phrase MAY give further details about the status of the call, 339 e.g., "5 calls queued; expected waiting time is 15 minutes". The 340 server may issue several 181 responses to update the caller about the 341 status of the queued call. 343 5 ISDN and Intelligent Network Services 345 SIP may be used to support a number of ISDN [4] and Intelligent 346 Network [5] telephony services, described below. Due to the 347 fundamental differences between Internet-based telephony and 348 conferencing as compared to public switched telephone network 349 (PSTN)-based services, service definitions cannot be precisely the 350 same. Where large differences beyond addressing and location of 351 implementation exist, this is indicated below. The term address 352 implies any SIP address. 354 This section is for information and illustration only. There are many 355 different ways of implementing services in SIP. Since SIP only 356 describes the behavior induced by messages, different means of 357 implementing services will interoperate. 359 5.1 Call Redirection and "Number"-Translation Services 361 Call transfer (TRA) enables a user to transfer an established (i.e., 362 active) call to a third party. SIP signals this via the Location 363 header in the BYE method. 365 Call forwarding (CF) permits the called user to forward particular 366 pre-selected calls to another address. Unlike telephony, the 367 choice of calls to be forwarded depends on program logic 368 contained in any of the SIP servers and can thus be made 369 dependent on time-of-day, subject of call, media types, urgency 370 or caller identity, rather than being restricted to matching 371 list entries. This forwarding service encompasses: 373 Call forwarding busy/don't answer (CFB/CFNR, SCF-BY/DA) allows the 374 called user to forward particular pre-selected calls if the 375 called user is busy or does not answer within a set time. 377 Selective call forwarding (SCF) permits the user to have her incoming 378 calls addressed to another network destination, no matter what 379 the called party status is, if the calling address is included 380 in, or excluded from, a screening list. The user's originating 381 service is unaffected. 383 Destination call routing (DCR) allows customers to specify the 384 routing of their incoming calls to destinations according to 386 - time of day, day of week, etc.; 388 - area of call origination; 390 - network address of caller; 392 - service attributes; 394 - priority (e.g., from input of a PIN or password); 396 - charge rates applicable for the destination; 398 - proportional routing of traffic. 400 In SIP, destination call routing is implemented by user agents, proxy 401 and redirect servers that implement custom call handling logic, with 402 parameters including, but not limited to the set listed above. Caller 403 preferences are expressed in the Accept-Location header, callee 404 preferences in the Location header. 406 Follow-me diversion (FMD) allows the service subscriber to remotely 407 control the redirection (diversion) of calls from his primary 408 network address to other locations. 410 In SIP, finding the current network-reachable location of a callee is 411 left to the location service and is outside the scope of this 412 specification. However, users may use the REGISTER method to 413 appraise their "home" SIP server of their new location. 415 Universal access number (UAN) allows a subscriber with several 416 network addresses to be reached with a single, unique address. 417 The subscriber may specify which incoming calls are to be routed 418 to which address. SIP offers this functionality through proxies 419 and redirection. 421 Universal personal telecommunications (UPT) is a mobility service 422 which enables subscribers to be reached with a unique personal 423 telecommunication number (PTN) across multiple networks at any 424 network access. The PTN will be translated to an appropriate 425 destination address for routing based on the capabilities 426 subscribed to by each service subscriber. A person may have 427 multiple PTNs, e.g., a business and private PTN. In SIP, a 428 host-independent address of the form user@domain serves as the 429 PTN, which is translated into one or more host-dependent 430 addresses. 432 5.2 Camp-on 434 Completion of calls to busy subscriber (CCBS) allows a calling user 435 encountering a busy destination to be informed when the busy 436 destination becomes free, without having to make a new call attempt. 437 SIP supports services close to CCBS by allowing a callee to indicate 438 a more opportune time to call back with the Retry-After header. 439 Also, calling and called user agents can easily record the URI of 440 outgoing and incoming calls, so that a user can re-try or return 441 calls with a single mouse click or automatically. Call-Disposition: 442 queue allows a caller to wait until the line becomes available. This 443 service is also known as a "camp-on" service. 445 5.3 Call Screening 447 Originating call screening (OCS) controls the ability of a node to 448 originate calls. In a fashion similar to closed user groups, a 449 firewall would have to be used to restrict the ability to initiate 450 SIP invitations outside a designated part of the network. In many 451 cases, gateways to the PSTN will require appropriate authentication. 453 5.4 Directed Call Pickup 455 Directed call pickup allows a station user to answer calls directed 456 to a specific address from any other address by providing the address 457 of the line to be answered. The rung station must permit pickup. If 458 the call has not been answered at the ringing station, regular call 459 pickup occurs. If the call has been answered already, an error is 460 generated. 462 5.5 Directed Call Pickup with Barge-In 464 Directed call pickup with barge-in establishes a 3-way call if the 465 call has been answered at the original destination. 467 5.6 Outgoing Call Routing 469 User-defined routing (UDR) allows a subscriber to specify how 470 outgoing calls, from the subscriber's location, shall be routed. SIP 471 cannot specify routing preferences; this is presumed to be handled by 472 a policy-based routing protocol, source routing or similar 473 mechanisms. However, the SIP Accept-Location header may be used by 474 proxies and redirect servers to route calls according to caller 475 preferences. 477 5.7 End-System Services 479 Some telephony services can be provided by the end system, without 480 involvement by SIP: 482 Abbreviated dialing allows users to reach local subscribers without 483 specifying the full address (domain or host name). For SIP, the 484 user application completes the address to be a fully qualified 485 domain name. 487 Call waiting (CW) allows the called party to receive a notification 488 that another party is trying to reach her while she is busy 489 talking to another calling party. 491 For SIP-based telephony, the called party can maintain several call 492 presences at the same time, limited by local resources. Thus, it is 493 up to the called party to decide whether to accept another call. The 494 separation of resource reservation and call control may lead to the 495 situation that the called party accepts the incoming call, but that 496 the network or system resource allocation fails. This cannot be 497 completely prevented, but if the likely resource bottleneck is at the 498 local system, the user agent may be able to determine whether there 499 are sufficient resources available or roughly track its own resource 500 consumption. 502 Consultation calling (COC) allows a subscriber to place a call on 503 hold, in order to initiate a new call for consultation. In 504 systems using SIP, consultation calling can be implemented as 505 two separate SIP calls, possibly with the temporary release of 506 reserved resources for the call being put on hold. 508 Customized ringing (CRG) allows the subscriber to allocate a 509 distinctive ringing to a list of calling parties. In a SIP-based 510 system, this feature is offered by the user application, based 511 on caller identification ( From header) provided by the SIP 512 INVITE request. 514 Malicious call identification (MCI) allows the service subscriber to 515 control the logging (making a record) of calls received that are 516 of a malicious nature. In SIP, by default, all calls identify 517 the calling party and the SIP servers that have forwarded the 518 call. In addition, calls may be authenticated using standard 519 HTTP methods or transport-layer security. A callee may decide 520 only to accept calls that are authenticated. 522 Multiway calling (MWC) allows the user to establish multiple, 523 simultaneous calls with other parties. For a SIP-based end 524 system, the considerations for consultation calling apply. 526 Terminating call screening (TCS) allows the subscriber to specify 527 that incoming calls either be restricted or allowed, according 528 to a screening list and/or by time of day or other parameters. 530 5.8 Billing Features 532 Billing features such as account card dialing , automatic alternative 533 billing , credit card calling (CCC) , reverse charging , freephone 534 (FPH) , premium rate (PRM) and split charging are supported through 535 authentication. However, mechanisms for indicating billing 536 preferences and capabilities have not yet been specified for SIP. 538 Advice of charge allows the user paying for a call to be informed of 539 usage-based charging information. Charges incurred by reserving 540 resources in the network are probably best indicated by a protocol 541 closely affiliated with the reservation protocol. Advice of charge 542 when using Internet-to-PSTN gateways through SIP appears feasible, 543 but is for further study. Desirable facilities include indication of 544 charges at call setup time, during the call and at the end of the 545 call 546 Closed user groups (CUGs) that restrict members to communicate only 547 within the group can be implemented using firewalls and SIP proxies. 549 5.9 User-to-User Signaling 551 User-to-user signaling is supported within SIP through the addition 552 of headers, with predefined header fields such as Subject or 553 Organization. 555 5.10 Operator Services 557 There are a number of services which involve three parties, for 558 example, a secretary dialing for boss, an auto-dialer handing a call 559 to a telemarketer, attended call transfer, operator services such as 560 person-to-person calls and full-mesh "multicast". 562 Operator services can be implemented in a number of ways, combining 563 Also, Replaces with either INVITE or BYE. The callee's end system 564 does not have to be cognizant of the fact that this an operator 565 service. The services make use of the Call-ID rules that stipulate 566 that a new INVITE for an existing Call-ID does not alert the user, 567 but is added silently. 569 Figure 1 shows the example of an autodialer connecting to a 570 prospective customer and, once the callee picks up, transfering the 571 call to the telemarketer. (This goes to show that SIP is morally 572 neutral.) 574 telemarketer 575 T ------------. n 576 ^ : ----> nth step; INVITE (Also:) 577 | : ....> nth step; BYE (Also:) 578 2(C) | : 4 3( 579 | : ( 580 | V 5 V 581 .................> 582 A C 583 -----------------> 584 auto dialer 1 customer 586 Figure 1: Telemarketer example 588 5.11 Multipoint Control Unit (MCU) Services 589 In the language of IN services, SIP supports: 591 Conferencing (CON) allows the user to communicate simultaneously with 592 multiple parties, which may also communicate among themselves. 593 SIP can initiate IP multicast conferences with any number of 594 participants, conferences where media are mixed by a conference 595 bridge (multipoint control unit or MCU) and, for exceptional 596 applications with a small number of participants, fully-meshed 597 conferences, where each participant sends and receives data to 598 all other participants. This is described in more detail in 599 Sections 5.11 and 5.12. 601 Conference calling add-on allows a user to add and drop participants 602 once the conference is active. Participants in the SIP session 603 accomplish this by sending INVITE and BYE requests to the 604 parties to be added and dropped. If A wants B to drop out of a 605 conference, it sends a BYE request with " Replaces: *". 607 Conference calling meet-me (MMC) allows the user to set up a 608 conference or multi-party call, indicating the date, time, 609 conference duration, conference media and other parameters. The 610 conference session description included in the SIP invitation 611 may indicate a time in the future. For multicast conferences, 612 participants do not have to connect using SIP at the actual time 613 of the conference; instead, they simply subscribe to the 614 multicast addresses listed in the announcement. For MCU-based 615 conferences, the session description may contain the address of 616 the MCU to be called at the time of the conference. 618 Some conferences use a multipoint control unit (MCU) to mix, convert 619 and replicate media streams. While this solution has scaling 620 problems, it is widely deployed in traditional telephony and ISDN 621 conferencing settings, as so-called conference bridges. In a MCU- 622 based conference, the conference initiator or any authorized member 623 invites a new participant and indicates the address of the MCU in the 624 Also header. The invitee then contacts the MCU using the same session 625 description and requests to be added to the call, just like a normal 626 two-party call. 628 Parties inviting others to a conference do not have to know that the 629 conference media is managed by an MCU. The inviting party A treats 630 the MCU M like another participant and includes it in the Also list. 631 The newly invited participant B invites the MCU, which in turn sends 632 a Replaces header with all participants. (See example in Section 633 3.5). Figure 2 shows the transition from a fully-meshed conference 634 (see below) to an MCU-based conference. 636 MCU MCU -----------, 637 1 ^ 2 | 638 Also:B / Replace:A | 639 / | 640 / 3 V | 641 A........B A. INVITE 651 xxxx> BYE 653 Figure 2: Transition from fully-meshed to MCU-based conference 655 Operator-assisted dial-out: The operator calls each participant, and 656 simply indicates the MCU in the Also list. The Call-ID and/or 657 the address used by the operator serves as the identifier to the 658 MCU. For example: 660 O -> A: INVITE A SIP/2.0 661 From: O 662 Also: conference176@M 664 A -> M: INVITE conference176@M 665 Requested-By: O 667 Meet-me: The leader and participants dial into their conference at 668 the scheduled time with an assigned conference identifier and 669 security code. 671 A -> M: INVITE conference189@M 672 From: A 674 5.12 Fully-Meshed Conferences 675 For very small conferences, such as adding a third party to a two- 676 party call, multicast may not always be appropriate or available. 677 Instead, when inviting a new participant, the caller asks the new 678 member to call the remaining members. The Call-ID for all 679 participants is the same. 681 6 Acknowledgements 683 Parameters of the terminal negotiation mechanism in the Location 684 header were influenced by Scott Petrack's CMA design. 686 7 Bibliography 688 [1] S. Bradner, "Key words for use in RFCs to indicate requirement 689 levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. 691 [2] M. Handley, H. Schulzrinne, and E. Schooler, "SIP: Session 692 initiation protocol," Internet Draft, Internet Engineering Task 693 Force, Nov. 1997. Work in progress. 695 [3] M. Handley and V. Jacobson, "SDP: Session description protocol," 696 Internet Draft, Internet Engineering Task Force, Mar. 1997. Work in 697 progress. 699 [4] International Telecommunication Union, "Integrated services 700 digital network (ISDN) service capabilities -- definition of 701 supplementary services," Recommendation I.250, Telecommunication 702 Standardization Sector of ITU, Geneva, Switzerland, 1993. 704 [5] International Telecommunication Union, "General recommendations 705 on telephone switching and signaling -- intelligent network: 706 Introduction to intelligent network capability set 1," Recommendation 707 Q.1211, Telecommunication Standardization Sector of ITU, Geneva, 708 Switzerland, Mar. 1993. 710 Table of Contents 712 1 Terminology ......................................... 1 713 2 Introduction ........................................ 1 714 3 Headers ............................................. 2 715 3.1 Accept-Location .................................... 2 716 3.2 Also ............................................... 2 717 3.3 Call-Disposition ................................... 4 718 3.4 Location ........................................... 5 719 3.5 Replaces ........................................... 7 720 3.6 Requested-By ....................................... 8 721 4 Status Code Definitions ............................. 8 722 4.1 181 Queued .......................................... 8 723 5 ISDN and Intelligent Network Services ............... 8 724 5.1 Call Redirection and "Number"-Translation Services 725 ................................................................ 9 726 5.2 Camp-on ............................................. 10 727 5.3 Call Screening ...................................... 10 728 5.4 Directed Call Pickup ................................ 11 729 5.5 Directed Call Pickup with Barge-In .................. 11 730 5.6 Outgoing Call Routing ............................... 11 731 5.7 End-System Services ................................. 11 732 5.8 Billing Features .................................... 12 733 5.9 User-to-User Signaling .............................. 13 734 5.10 Operator Services ................................... 13 735 5.11 Multipoint Control Unit (MCU) Services .............. 13 736 5.12 Fully-Meshed Conferences ............................ 15 737 6 Acknowledgements .................................... 16 738 7 Bibliography ........................................ 16