--- 1/draft-ietf-mmusic-sip-cc-00.txt 2006-02-05 00:29:54.000000000 +0100 +++ 2/draft-ietf-mmusic-sip-cc-01.txt 2006-02-05 00:29:54.000000000 +0100 @@ -1,737 +1,1564 @@ - 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 +draft-ietf-mmusic-sip-cc-01.txt Columbia U./Bell Laboratories +June 17, 1999 +Expires: December, 1999 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. + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + 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''. + 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). + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt - Distribution of this document is unlimited. + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. - ABSTRACT +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. + This document describes a set of extensions to SIP which allow for + various call control services. Example services include blind + transfer, transfer with consultation, multi-party calls, bridged + conferences, and ad-hoc conferencing. The services are supported in a + fully distributed manner, so that they can be provided without a + central conference server. However, a SIP proxy can act as a + conference server to provide these services. For the various services + described here, we overview the requirements for the service, and + specify the protocol functions needed to support it. We then define a + basic set of SIP primitives which can be used to construct these + services, and others. 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 - described here, the client MUST include the extension name in a - Require header. + The Session Initiation Protocol (SIP) [2] is a signaling protocol + used for the initiation of multimedia sessions. SIP also defines + mechanisms for termination of sessions using the BYE method. However, + SIP has less support for signaling of services that take place during + the call itself. These kinds of services can be broken into several + classes: -3 Headers + Session Control Services These services relate to the media session. + Examples include floor and chair control (which controls who can + send/receive data in the session), hold, and mute. - 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 - + Call Control Services These services relate to participant + management. These services are all built on the basic blocks of + adding and removing users from a call. Examples include transfer + (the simultaneous removal and addition of a member from a call), + multi-party calling, call bridging, and ad-hoc bridged + conferences. - 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. + This document describes extensions to SIP for providing call control + services. The services are supported in a fully distributed manner, + so that they can be provided without a central conference server. + However, a SIP proxy can act as a conference server to provide these + services. Our aim is to provide a general set of tools which can be + used to construct, at a minimum, a core set of services, but be + potentially useful as building blocks for future services. To + accomplish this goal, we begin by overviewing the requirements for + each of the core services. This includes its basic functional + requirements and its security requirements. Then, we overview the + technical issues in providing these services, and outline the basic + primitives that we have concluded are needed. The next section + formally defines these primitives through new headers and UA + behavior. -3.1 Accept-Location +3 Services - 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). + We overview the services which we desire to support at a minimum. For + each, we define the requirements for the service, with a particular + focus on security. Security is a primary concern for many of these + services. As such, the following general principles apply: -3.2 Also + o Parties involved in some service should be able to + cyryptographically verify the identity of the other parties in + the service - 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. + o Parties involved in some service should have a choice about + their participation in the service - 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. + o Parties involved in some service should know what the service + being invoked is - Also = "Also" ":" 1#( SIP-URL | URI ) [ comment ] - Example header: + These three basic requirements are a natural consequence of an + architecture where endpoints are assumed to be intelligent. Note, + however, that just because the protocol provides information and + gives choices, does not mean all implementations need to take + advantage of this. Thin and dumb endpoints can choose not to provide + information to the end users, and can choose not to provide choices + to them. This has the advantage of enabling one common protocol for + smart and dumb endpoints alike. - Also: sip://jones@foo.com, sip://mueller@bar.edu +3.1 Blind Transfer - If A, B and C are end points, the following is a typical scenario: + In the blind transfer service, two parties are in an existing call. + One party, the transferring party , wishes to terminate the call with + the other party the transferred pary , and at the same time, transfer + them to another party, the transferred-to party - 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 + ---------------- + -> | Transferred-to | + / | party | + / ---------------- + / + / + -------------- ---------------- + | Transferred |<------------------------| Transferring | + | party | | party | + -------------- ---------------- - If G is a group address with members X through Z, a group invitation - may proceed as follows: + Figure 1: Transfer Service - A -> G: INVITE G SIP/2.0 - From: A - Call-ID: 19971214T124523.00@A + Some of the requirements for this service include: - G -> A: SIP/2.0 200 OK - From: A - Call-ID: 19971214T124523.00@A - Also: X, Y, Z + o The original call terminates regardless of whether the + transfer succeeds or not. - A -> X: INVITE X SIP/2.0 - From: A - Call-ID: 19971214T124523.00@A - Requested-By: G + o The transferring party does not know whether the transfer + succeeds or not. - A -> Y: INVITE Y SIP/2.0 - From: A - Call-ID: 19971214T124523.00@A - Requested-By: G - A -> Z: INVITE Z SIP/2.0 - From: A - Call-ID: 19971214T124523.00@A - Requested-By: G + o The transferred party should be able to know that they are + being transferred - 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. + o The transferred party should be able to know to whom they are + being transferred -3.3 Call-Disposition + o The transferred party should be able to decide whether to + accept or reject the transfer - 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: + o If the transferred party rejects the transfer, the call with + the transferring party still terminates - 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. + o The transferred party should be able to verify that they are + being transferred by the transferring party - 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.) + o The transferred-to party should know that they are being + transferred-to - 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. + o The transferred-to party should be able to know the identity + of the transferring party - 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. + o The transferred-to party should be able to accept or reject + the transferred call just like any other call - Maybe the combination of do-not-respond and all could be - used for group invitations to larger lists? +3.2 Transfer and Hold - Call-Disposition = "Call-Disposition" ":" 1#( "all" | "do-not-forward" - | "queue" | "do-not-respond" ) + This service is a variation on blind transfer. The difference is that + the transferring party does not leave the call with the transferred + party. If the service is successful, the transferred party is + involved in two calls - one with the transferring party, and one with + the transferred to party. Many of the requirements are similar. The + requirements for the service are: - Example: + o The call between the transferring and transferred parties + remains active, regardless of the status of the new call + between the transferred and transferred-to parties. - Call-Disposition: all, do-not-forward, queue + o The transferring party does not know whether the transfer + succeeds or not. -3.4 Location + o The transferred party should be able to know that they are + being transferred + o The transferred party should be able to know to whom they are + being transferred - This document adds extension parameters to the Location header. + o The transferred party should be able to decide whether to + accept or reject the transfer - 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" + o If the transferred party rejects the transfer, the call with + the transferring party remains unchanged - 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 + o The transferred party should be able to verify that they are + being transferred by the transferring party - 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.) + o The transferred-to party should know that they are being + transferred-to - description: The description field further describes, as text, the - terminal. It is expected that the user interface will render - this text. + o The transferred-to party should be able to know the identity + of the transferring party - duplex: The duplex parameter lists whether the terminal can - 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. + o The transferred-to party should be able to accept or reject + the transferred call just like any other call - 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. + o The transferred-to party should not be able to ascertain, + through signaling messages, that the transferring party is + still communicating with the transferred party. In other + words, blind transfer and transfer and hold appear identical + to the transferred-to party. - 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. +3.3 Transfer with Consultation - 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. + This service is similar to blind transfer. However, the transferring + party first contacts the transferred-to party to approve the transfer + through multimedia communication. Pending approval, the transferring + party then simultaneosly disconnects from the transferred-to and + transferred parties, and connects the transferred and transferred-to + parties. The transferring and transferred parties stay connected if, + for some reason, the transfer fails. - mobility: The mobility parameter indicates if the terminal is fixed - or mobile. In some locales, this may affect voice quality or - charges. + The requirements for this service are more complex. They include: - 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. + o The transferring party should not need to know ahead of time + that they will transfer the call to the transferred-to party. + In other words, it should not be neccesary to know ahead of + time that the consultation call (between the transferring and + transferred-to parties) is for the purposes of a transfer. - service: The service tag describes what service is being provided by - the terminal. + o The transferred party should be able to know that they are + being transferred + o The transferred party should be able to know to whom they are + being transferred - 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. + o The transferred party should be able to decide whether to + accept or reject the transfer - 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 - ;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 + o The transferred party should be able to verify that they are + being transferred by the transferring party - 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. + o The transferred-to party should know that they are being + transferred-to -3.5 Replaces + o The transferred-to party should be able to know the identity + of the transferring party - 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. + o The transferred-to party should be able to know that the + transferred party is being transferred as a result of the + consultation call in progress with the transferring party. - For example, with entities A, B and M (an MCU): + o The transferred-to party should be able to accept or reject + the transferred call just like any other call - A -> B: INVITE B SIP/2.0 - Call-ID: 19971214T123503.33@A - From: A + o If the transferred-to party accepts the transfer, the + transferring party should be able to know this - B -> A: SIP/2.0 200 OK - Call-ID: 19971214T123503.33@A - From: A + o If the transferred-to party rejects the transfer, the + transferring party should be able to know this - M -> B: INVITE B SIP/2.0 - Call-ID: 19971214T123503.33@A - From: M - Replaces: * + o The call between the transferring and transferred-to party + terminates at the same time as the call between the + transferring and transferred party, should the transfer be + successful - B -> M: SIP/2.0 200 OK - Call-ID: 19971214T123503.33@A - From: M + This service is harder to implement. To be done in a distributed + manner requires that information on the success of the call between + transferred and transferred-to parties is communicated back to the + transferring party. - B -> A: BYE A SIP/2.0 - Call-ID: 19971214T123503.33@A - From: B - Requested-By: M +3.4 Multi-party Conferencing - A -> B: SIP/2.0 200 OK - Call-ID: 19971214T123503.33@A - From: A + Multiparty conferencing allows multiple participants to + simultaneously exchange media so that each party hears media from + every other one. There are many flavors of this service. -3.6 Requested-By +3.4.1 Loosely Coupled Multicast Conference - 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. + In this flavor, there is a very large conference, for which multicast + is being used to distribute the media. The conference is large enough + so that there is not a direct signaling relationship between all + parties. Session participants simply join the multicast group, and + learn about each other through RTCP [3]. This kind of conference + model is often referred to as a loosely coupled conference -4 Status Code Definitions + The main requirement is to be able to invite another participant to + join in this conference. In fact, this kind of conference is readily + supported by baseline SIP, as it was the initial application for it. + The only new requirement is that the called party needs some way to + know that there will not be an actual SIP session - no BYE will ever + arrive (nor should one be sent). The INVITE delivers the session + invitation, and thats it. Relying on session parameters for this is + undesirable, since it leads to a dependency between SIP behavior and + the specific session type. Furthermore, it may not be possible to + ascertain from the media session whether an actual SIP session is + needed. - This feature set defines one additional status code. +3.4.2 Distributed Full Mesh -4.1 181 Queued + In this conference model, each participant has a SIP signaling + session open with each other participant. The media session may be + multi-unicast or multicast. To support these conferences, the + signaling must provide support for: - 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. + o Transitioning gracefully from a normal two-party call to a + conference without knowing apriori this will happen -5 ISDN and Intelligent Network Services + o Adding parties to the conference - 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. + o Leaving the conference - This section is for information and illustration only. There are many - different ways of implementing services in SIP. Since SIP only - describes the behavior induced by messages, different means of - implementing services will interoperate. + The requirements for the service are: -5.1 Call Redirection and "Number"-Translation Services + o Any member of an existing conference can add another party to + the conference. - 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. + o The new party should know they are being asked to join an + existing conference. - 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: + o The new party should be able to accept or reject the + invitation to join the existing call. - 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. + o If the new party rejects the invitation to the conference, no + other participant should have received any messages which + indicates they were ever asked to join the conference - 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. + o The new party should be able to know, within the limits of + synchronization of state across participants, the current set + of participants in the call before they decide whether to + reject or accept the invitation. - Destination call routing (DCR) allows customers to specify the - routing of their incoming calls to destinations according to + o Each participant in the call should learn that a new party is + being added. - - time of day, day of week, etc.; + o Each participant in the call should be able to + cryptographically verify that the new party has been invited + by a specific participant. - - area of call origination; + o Each participant in the call should be able to decide whether + to accept or reject the new participant. - - network address of caller; + o If any existing participant in the call rejects the new + participant, the new participant is not added to the call at + all. - - service attributes; + o The inviting party can learn the success or failure of the + addition of the new party. - - priority (e.g., from input of a PIN or password); + o Each participant should be able to know whether the new party + was successfully added or not. - - charge rates applicable for the destination; + o Any participant should be able to leave the conference at any + time. - - proportional routing of traffic. + o Each participant should know within a short period of time + when some other participant has left - 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 - preferences are expressed in the Accept-Location header, callee - preferences in the Location header. + o A participant who leaves the conference should have its SIP + signaling relationship terminated with all other participants. - Follow-me diversion (FMD) allows the service subscriber to remotely - control the redirection (diversion) of calls from his primary - network address to other locations. + o It must be possible for two participants to simultaneously add + a new party to the conference. - 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. + o It must be possible for a participant to add another to the + conference while some other participant leaves the conference. - 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. + o The existence of the conference does not depend on the + presence of any single user in the conference. - 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. + o The conference terminates when the last two parties terminate + their signaling relationships. -5.2 Camp-on + It is important to note that this kind of conference does not require + the use of a centralized conference controller. - 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. +3.4.3 Dial-in Bridge + Another conferencing application is the "dial-up bridge". In this + scenario, a media bridge is used, and this device also acts as a + centralized signaling server. Users join the conference by "dialing- + in", which means they try and initiate a SIP session with the + conference bridge directly. Participants do not maintain a signaling + session with each other. Rather, each participant maintains a single + SIP session with the conference bridge. -5.3 Call Screening + The requirements for this kind of conference are: - 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 - cases, gateways to the PSTN will require appropriate authentication. + o It should not be neccesary for a participant to know apriori + that they are contacting a dial-up bridge - it should take + place as a regular SIP call. -5.4 Directed Call Pickup + o Participants should be able to join the conference at any time + by dialing in. - 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. + o Participants should be able to invite another participant to + join the conference call. -5.5 Directed Call Pickup with Barge-In + o Participants should still be able to learn, through some + means, the identity of the other participants in the call. - Directed call pickup with barge-in establishes a 3-way call if the - call has been answered at the original destination. + o Participants should be able to leave the conference at any + time. -5.6 Outgoing Call Routing + o When a participant leaves or joins, this information should be + propagated to all other conference participants through some + means besides tones or announcements in the media stream. - 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. + o It must be possible for the conference bridge to authenticate + the identity of participants. -5.7 End-System Services +3.4.4 Ad-hoc Bridge - Some telephony services can be provided by the end system, without - involvement by SIP: + This service is not so much another conferencing model, as a + transition mechanism between conferencing models. A conference starts + out as a fully distributed mesh. These conferences become unwieldy as + this number of participants approaches tens to hundreds. Someone in + the conference then decides to transition the call to a conference + bridge. The bring a conference bridge into the call, and then + instruct each participant to drop their signaling relationships with + the other participants in favor of a single signaling relationship + with the bridge. After the transition is complete, the conference + runs similar to the dial-in bridge case. However, there are some + distinctions. In the dialup conference, any participant can join in + without being invited if they know a conference code of some sort. In + the ad-hoc bridge case, participants must still be actively invited. - 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. + The requirements for this service are: - 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. + o The transition must be at the behest of one of the + participants. - 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 - are sufficient resources available or roughly track its own resource - consumption. + o Any participant can cause the transition to take place. - 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. + o It is not necessary for the protocol to detect and resolve + simultaneous transitions. It is assumed that the persons in + the conference would coordinate this themselves. - 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. + o The conference should continue to be operable during the + transition - 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. + o Participants should be informed of the transition, but it must + be possible for the perception to be that there has been no + change. - 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. + o It should be possible for some participants to accept the + transition, and appear through the bridge, and for others to + remain in full mesh. - 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. + o Participants should be able to leave the conference at any + time, including the transition period. -5.8 Billing Features + o Participants should be able to invite others to the + conference, even during the transition period. The mechanism + for inviting them should not depend on the fact that a + transition is taking place. - 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. +3.4.5 Conference out of Consultation - 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 - Closed user groups (CUGs) that restrict members to communicate only - within the group can be implemented using firewalls and SIP proxies. + In this service, a user A has a call in progress with B, and a + separate call in progress with C. These calls are unrelated, with + different Call-ID's. From this double call scenario, the conference + out of consultation service allows the calls to be merged, resulting + in a single, full-mesh conference, as described above. -5.9 User-to-User Signaling + The requirements for this service are: - User-to-user signaling is supported within SIP through the addition - of headers, with predefined header fields such as Subject or - Organization. + o Only participant A can invoke the service -5.10 Operator Services + o It must not be neccesary for A to know that he will merge the + two calls before any or either of them is made - 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". + o It must not be neccesary for A to have been the initiator of + the calls that are being merged + o It must be possible to merge an arbitrary number of calls - 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. + o The participants being merged must be informed that the + merging is taking place - 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.) + o A participant must be able to reject the merge, in which case + they are disconnected with all parties - telemarketer - T ------------. n - ^ : ----> nth step; INVITE (Also:) - | : ....> nth step; BYE (Also:) - 2(C) | : 4 3( - | : ( - | V 5 V - .................> - A C + o A participant must be able to verify that A was the party that + initiated the merge. + +4 Discussion of Implementation Options + + This section discusses some of the technical issues in designing a + protocol mechanism to support the above requirements. + +4.1 Transfer + + For the discussion which follows, we assume the transferring party is + A, the transferred party is B, and the transferred-to party is C. + + The nature of the transfer service is that the transferred party (B) + must be informed about the transfer and accept it before C (the + transferred-to party) is contacted. This implies that the messaging + flow for the service must consist of a message from A to B, and then + B to C. + + The message from A to B must simultaneously disconnect A and B, and + alert B about the transfer. This is most readily accomplished by + including some kind of header in the BYE message which indicates that + B should initiate a call to C. This header is the Also header, which + is described in greater detail in section 5.1. It contains the + address of a participant, along with a signed token. This token is + the signature over the sender of the message (the From field), the + address in the Also header, and the Call-ID. Since C needs to know + that he is being contacted as a result of a transfer, the INVITE from + B to C must contain some kind of header indicating that it was A who + asked for the transfer. This header needs to contain A's name along + with the authorization token from the Also header. This token allows + C to verify that A requested the transfer to C for this particular + call. This header is the Requested-By header, described in greater + detail in section 5.3. + + Therefore, the basic transfer messaging flow is simple. A sends a BYE + to B, containing an Also header listing C. The BYE causes A and B to + be disconnected. User B is alerted about the transfer. If accepted, B + sends an INVITE to C, including a Requested-By header in the INVITE. + +4.2 Full mesh conferences + + We assume the conference starts as a standard two party call in SIP. + One of the parties wishes to add a third to the conference. Based on + the requirements, the new party needs to first be asked if they wish + to join the conference. This implies that messaging begins with the + inviting party (party A) sending a message to the new participant + (party B). This message must contain a list of the other + participants. If the invitation is acceptable to B, B can begin to + join the conference. To join the conference, a signaling relationship + must be established between B and all other participants. This can be + done by having existing participants contact B, or B contacting + existing participants. Since B has the list of participants in the + initial INVITE from A, the most efficient approach is to have B + contact each participant directly. + + Thus, in the simplest scenario, A (who is in a call with C), sends an + INVITE to B. This INVITE contains an Also header, indicating C. B + sends an INVITE to C, containing a Requested-By header naming A. C + accepts, and then B sends a 200 OK to A. Now, there is a signaling + relationship between all parties. Adding additional parties is done + in a similar fashion. + + On the surface, this simple mechanism appears sufficient. However, it + is not. Consider the following problematic cases (assume A,B, and C + are already in a conference): + + o While A is adding D, B adds E. Since A did not tell D about E + (as it didn't know about E), D may not know of E's existence. + This results in a partially connected conference. + + o While A is adding D, B sends a BYE to the group. If this BYE + is sent by B before the INVITE from D arrives at B, B should + respond to the INVITE with an error. As far as B is concerned, + the INVITE has failed, and it responds with an error to A. + What should A do now? It cannot tell whether the add party + failed because someone left the group, or because someone + refused to add that party. In one case, the add should be + tried again, and in the other, it should not. Even worse, + should B accept the call from D, a partially disconnected + conference will occur. + + o What happens if a transfer takes place at the same time as an + add party? + + o A participant leaves the conference, but fails to send a BYE + to all the other participants (either on purpose or by + accident). The result is a partially disconnected conference. + + The problems can all be categorized as difficulties in synchronizing + a distributed database. The database, in this case, is the set of + participants. This database is replicated at each participant. The + database is dynamic, with each participant owning the entry in the + database corresponding to itself. As changes occur, everyone must be + quickly synchronized to achieve a consistent view of the conference + participants. + +4.2.1 Approach I: Caretaker + + In this approach, the party (A) that invites another (D) to the + conference is its caretaker. When A adds D, it informs D of the other + participants it knows about. D then sends an INVITE to each of these + in turn, establishing a signaling relationship. Should the + participant list (at A) change during the time D is being addded + (until a 200 OK arrives from D), A makes note of these changes, and + then propagates them to D. + + The difficulty with this approach is there is no easy way for A to + know when it can cease being caretaker for D. Lets say A invited D, + and told it to contact B and C, which it did. After receiving the 200 + OK from D, A receives an INVITE from E, a new party added by B. Now, + does A need to inform D about E? If B had invited E after knowing + about D, A does not have to inform E, but if B invited E before + knowing about D, A does have to inform D. + + Furthermore, should the caretaker itself leave the conference, the + mechanism ceases to work. As a result, we don not believe this + approach is viable. + +4.2.2 Approach II: Flooding + + We make the following important observation: + + synchronization of the set of participants in a fully + meshed multiparty conference is similar to the problem of + database synchronization in link state routing protocols, + like OSPF. + + Based on this, we can develop mechanisms for SIP based on the same + synchronization, flooding, and adjacency notions in OSPF. We further + observe that this approach has already been used as the basis for + existing conferencing mechanisms [4]. + + To solve the first problem above, we introduce additional semantics + and behavior into the Also header. When A invites D into the + conference, the INVITE includes an Also header listing B and C. This + prompts D to send an INVITE to both B and C. In OSPF terminology, + this effectively establishes an adjacency between D and B, and D and + C. These INVITEs contain Also headers as well, listing the set of + participants the D believes is in the call. + + When B and C receive this INVITE, they compare the set of + participants in the Also header with the set of participants they + believe are in the call. Note that this is effectively the same + operation as database synchronization in OSPF. The result is three + sets for each pair (assume B below): + + S1: S1 is BD - the intersection of the set of participants B and D + both believe to be in the conference. + + S2: S2 is B - BD - the set of participants B believes to be in the + conference, but D is not aware of + + S3: S3 is D - BD - the set of participants D has been asked to + contact, which are not known to B + + First consider S2. There are only two ways this inconsistency can + happen. The first way is that B has learned of a new participant + before A issued the add party to D. The second is that A has learned + the party has left the call before the INVITE from D arrives at B. + Unfortunately, the desired behavior is different in each case. If B + is correct, and a new party has joined, B should return the address + of the party in the 200 OK to the INVITE from D. This would prompt D, + in turn, to add those parties. On the other hand, if B is wrong, and + the party has left the conference, B should say nothing in the 200 OK + about this participant. + + To enable these differing cases, we can add two additional pieces of + information to the addresses in the Also header. These are the + participant state (either active or inactive), and the version + number. When a participant receives a BYE from another, they mark + that participant as inactive, and hold onto the state for a short + duration (time TBD). This member is included in Also headers as other + participants, but they are marked as inactive. Based on this, in the + case above, B can ascertain the right behavior. + + The version number satisfies a different need. What happens if the + participant that left, comes back because they are re-INVITEd? In + this case, some of the participants will think this participant is + inactive, and others will consider them active. To determine which + piece of state is correct, the version number increments each time + the state changes. The version with the highest value is always the + most recent. (TBD: who sets this? Can't always be the originator). + This is identical to the use of sequence numbers in LSA's in OSPF. + + Consider now the set S3. When B receives the INVITE, this represents + the set of users D claims is in the conference, but B does not know + about. Since B keeps a cache of users who have left the conference, B + can be sure these are new participants that it has not learned of + yet. B should then send an INVITE to these users to establish + signaling relationships with them. As with other INVITEs' the Also + field contains B's perspective on the set of conference participants. + This is effectively the same process as flooding of new LSA's in + OSPF. + + TBD: How is requested-by handled in these various cases? + + We believe the flooding approach to be robust and well-proven from + many other protocols. + +4.3 Dial-up Bridges + + Dial up bridges are easily supported. We model them as virtual users. + When a user wants to join a dial-up conference, they send an INVITE + to the conference bridge. The bridge answers the call, and + establishes a point to point signaling relationship with the new + participant. The bridge performs the mixing locally, and sends the + mixed stream to each participant separately. As far as each + participant is concerned, they have a single signaling relationship + with one other entity - the conference server. + + Fortunately, this does not prohibit each party from learning the + identity of the others in the call. The bridge is effectively an RTP + mixer. As such, it can use contributing sources (CSRC) in the RTP and + RTCP packets to identify the other participants in the call. + + A user leaves the conference by hanging up with the bridge, as they + would hang up with any other user in a normal two party call. + + An important issue is how conferences are identified. In the + telephone network, there is usual a dial-in number and a passcode + that the participant must know. In SIP, there are many more + possibilities: + + o The conference is identified by a single URL - + sip:conference332@conferences.com, for example. A user sends + an INVITE to this address. The bridge identifies the + conference by looking at the URI in the Request-URI. + + o There is a single URI for each bridge - + sip:bridge3@conferences.com. The specific conference is + identified by a passcode sent as the password in the URI: + sip:bridge3:9987097@conferences.com. + + o The conference is identified by a single URL, as in the first + case. However, participants must also have a passcode. When + the server receives an INVITE for this URI, it responds with a + 401 demanding digest authorization. The shared secret used for + authenticating the caller is the passcode. + + o The conference is identified by a single URL, as in the first + case. The server is programmed with the public keys of those + participants allowed to join. When a participant tries to join + the conference by sending an INVITE to its address, the server + uses PGP authentication to verify the user is one of those + permitted. This allows for tight, per user controls on + conference participation. + + Some have suggested identifying the conference by Call-ID. We do not + believe this is the right approach. The Call-ID represents a SIP + signaling relationship shared among two or more users. Since, in the + conference bridge case, each user has a separate signaling + relationship with the bridge, using a common Call-ID is not + appropriate. + + Note that, based on this description, dial-in conferences are readily + supported in baseline SIP without any extensions. However, the + situation is more complex when a participant wishes to add another to + the conference. + + We believe it is essential that the act of adding a party to a + bridged conference is no different than the act of adding a party to + a fully meshed one. Consider a bridged conference with participants + A, B, and C. Each has a signaling relationship with the bridge, X. A + wishes to bring D into the conference. Using the same mechanisms as + for fully meshed conferences, A sends an INVITE to D, with the Also + header indicating X. D then sends an INVITE to X, which accepts. The + result is that D has a signaling relationship with the bridge, but is + still maintaining its signaling relationship with A. + + To resolve this, the bridge needs to step up and instruct D to + effectively abandon its signaling relationship with A (and vice a + versa). This does not mean the bridge wants A to send an BYE to D. + Rather, the bridge wants another one call leg to subsume another. For + D, this means that the D-X call leg should subsume the D-A call leg. + To accomplish this, the bridge sends an INVITE to D with a header + called Replaces. Replaces indicates that the call leg the INVITE + arrived on is subsuming the one identified in the header. The + Replaces contains the address of A. The request must also be + authenticated, since the Replaces header presents a powerful DOS + attack. Users should accept an INVITE with a Replaces header only + after either requesting confirmation from the user, or if the request + is signed by an authorized bridging service. + +4.4 Conference out of Consultation + + In this service, A is in a call with B, and separately, A is in a + call with C. These are two separate calls, and thus have identical + Call-IDs. Transitioning to a full mesh multiparty conference is + relatively straightforward. A can simply send an INVITE to B, with an + Also listing C. As far as B is concerned, the process is a normal add + party. + + The only difference is that the Call-ID is different in both calls. + Thus, the INVITE to C from B would not appear to be for the same + call. To resolve this, A must effectively change the Call-ID with B, + and then perform an add party. The change in Call-ID is accomplished + by having A send an INVITE to B (using the Call-ID from the A-C + call), with a Replaces header containing the A-B Call-ID and A's + address. The Replaces header has the same semantic here as in the + bridged conference case above. The call leg identified in the + Replaces header is subsumed by the call-leg of the INVITE. + + Once this transition has taken place, A can send an INVITE to B, + containing Also:C, as discussed above. + + If the calls being connected are multi-party calls, the situation is + more complex. (TBD: does this mechanism work for bridging two full + mesh calls?) + +4.5 Ad-hoc conference bridging + + To support an ad-hoc conference bridge, the following operations must + take place: + + o One of the parties in the call must contact a bridge, + informing it of the set of participants + + o The bridge must contact those participants, and cause them to + replace their signaling relationship with the other parties + with the relationship with the bridge + + To support the first, the initiator sends a message to the bridge, + containing the list of participants. We use an INVITE method for + this, and the participants are listed in the Also headers. It is not + clear if this is the right approach. The semantics of INVITE with + Also are not the same here. The bridge is not being asked to join the + call, rather, its being asked to take over the the signaling and + media connectivity for the call. For this reason, it might be + appropriate to define a new method to indicate this, or perhaps a new + header or parameter to Also. + + Once the bridge has been contacted with the list of participants, it + must send an INVITE to each (using the same Call-ID as the current + call) to establish a relationship with them. This call leg must + eventually replace the call legs the user has with all the other + users. However, the user should not subsume a call leg with some + other user until the bridge has succesfully contacted that other + user. + + For this to work, the initial INVITE with each user is treated as a + normal add-party. The Also list contains those users the bridge knows + about (initially, those the initiator told the bridge about). As far + as the contacted user is concerned, a normal add party is taking + place. The response is (under normal cases) a 200 OK containing those + additional parties the contacted user knows about. This way, if a + user was in the process of an add party while someone else + transitioned to a bridge, the bridge can learn about the new party. + Should the user add parties after being contacted by the bridge, the + user will tell the new party about the bridge. This allows the bridge + to learn about all users that come (and go) during the transition + period. + + Once the bridge has completed contacting all participants in the + party, it attempts to subsume the various call legs into its own call + leg. To do this, it sends another INVITE to each participant, listing + those call legs which must be subsumed. In the case where a + participant has added another user after the response to the bridges + initial INVITE was sent, but before the the "subsuming INVITE" + arrives, things still work. The new party will be informed about the + bridge, contact the bridge, and the bridge accepts. The bridge can + then send another INVITE to each user subsuming this particular new + call leg. + +4.6 Transfers to Multiparty Conferences + + This situation is more complex than normal transfers. We first + consider the case of a full mesh signaling relatioship. Assume A, B, + and C are already in a call. A wishes to transfer both B and C to Z. + + Extending the mechanism for a single party call is the ideal choice. + In this case, A would ask B to contact Z, and A would ask C to + contact Z. Everything works fine so long as (1) both B and C perform + the transfer (i.e., both contact Z), and (2) Z accepts both B and C's + invitations. However, if these assumptions fail to hold, the + resulting transfer will only partially complete. For example, it is + possible that only A gets transferred to Z. + + Whether this behavior is acceptable or not is a good question. We + believe that since the blind transfer mechanism has no guarantees on + success (the transferring party disconnects in either case), this + behavior is acceptable. + + Another issue that arises for multiparty conference transfers is a + flooding effect at the transferred-to party. If a large number of + participants where transferred, Z would receive, in rapid succession, + an INVITE from each. To facilitate a usable application, Z should not + really prompt the user about accepting each of these parties. Rather, + it should accept them all if it accepts the first. So, we therefore + have the rule: if a user accepts a transfer, it must accept all other + parties which have been transferred. + + The specific mechanism is the same for multiparty conferences. A + sends a BYE to B and C containing an Also header listing Z. B and C + send a 200 OK to the BYE, and then send an INVITE to Z. This INVITE + contains a Requested-By header listing A. When Z gets the first of + these, it alerts the user and accepts the call. (TBD: should these + triggered INVITEs contain Also's? Probably. But, in this case, Z is + going to get the first INVITE with lots of Also's. Many of these (but + perhaps not all) will eventually contact Z directly. So, should Z + send an INVITE to those in the Also headers it doesn't know about + already? Perhaps it should wait a while to see who contacts it first. + As an alternative, the BYE from A can contain Z's address, PLUS those + it send the BYE to. As a result, the INVITE from B or C to Z would + only contain those users in the Also which Z did not list in the BYE. + What is the right approach here?) + +5 Header Syntax + + This section defines the syntax for the three new headers defined + here - Also, Replaces, and Requested-By. + +5.1 Also + + The Also header is used to list other participants in a call. It is a + request and response header, and contains a list of SIP URI's, along + with some special parameters. + + Also = ``Also'' ``:'' 1#Also-Values + Also-Values = name-addr [parameters] + parameters = 1*parameter + parameter = ``;'' (status-param | version-param | crypto-param) + status-param = ``status'' ``='' (``active'' | ``inactive'') + version-param = ``version'' ``='' 1*3digit + crypto-param = ``token'' ``='' token + + The crypto-param is a token which is copied into the Requested-By + header for requests that are "triggered" as a result of an Also + header. The token is a signature over the URI of the entity + generating the Also header, the address in the Also header itself, + and the Call-ID. See section 6.1 for details on its computation. + +5.2 Replaces + + The Replaces header is used to indicate that the call leg identified + in the header is to be subsumed by the one initiated by this INVITE. + It is a request header only, valid only in INVITE messages. The + syntax is: + + Replaces = ``Replaces'' ``:'' 1#Replaces-Values + Replaces-Values= SIP-URI [call-id-param] + call-id-param = ``;'' ``call-id'' ``='' token + + When the call-id parameter is not present, it is presumed to be the + same as the Call-ID of the INVITE itself. + +5.3 Requested-By + + The Requested-By header is a request header only. It identifies the + participant who asked the UAC to send the request. The syntax is: + + Requested-By = ``Requested-By'' ``:'' name-addr [req-params] + req-params = ``;'' token-param + token-param = ``token'' ``='' token + +6 Also and Requested-By Header Semantics + + This section overviews the detailed semantics associated with the + Also and Requested-By headers. + +6.1 Sending an Untriggered INVITE + + When a UAC sends an INVITE containing an Also header, without having + been asked by some other UAC to do so, it is called an untriggered + INVITE. Untriggered INVITEs are sent when a user wishes to add + another user to a call, or to perform a transfer and hold service. + Other uses may exist. + + An untriggered INVITE MUST NOT contain a Requested-By header. This + header is used to determine whether an INVITE is triggered or not. + + When a UAC sends an untriggered INVITE containing an Also header, it + implies that the UAC wishes the recipient to send an INVITE to those + parties listed in the Also headers. If sent to a party not already in + the call, the INVITE effects an add party operation. If sent to a + party already in a call, it affects a transfer and hold operation. To + ensure fully connected conferences, it is RECOMMENDED that a UAC + include a URI for each participant it is aware of. + + Each element in the Also list should additionally contain a status + and a version parameter. If the UAC believes the participant is no + longer in the call, the status parameter is set to inactive, + otherwise its active. The version parameter contains the version of + the status for each participant that the UAC is currently aware of. + + The Also header SHOULD contain a token parameter for each URI listed. + This parameter is computed in the following fashion: + + 1. Initialize a string to the value of the Call-ID. + + 2. Append the URI from the Also, not including any + displaynames, but otherwise including all URI parameters. + Also append the Also parameters status and version. + + 3. Append the URI that will be included in the From field of + the INVITE. + + 4. Append the URI that will be included in the To field of the + INVITE. + + 5. Compute a signature over this field, using a XXX hash and + encryption using XXX. + + 6. The signature is then base64 encoded. The result is the + token. + + The response to the INVITE is a non-200 value if the UAS failed to + establish a call leg with all the participants listed in the Also + fields, or if the UAS was unwilling or unable to execute the request. + + A 200 OK response means that the UAS successfully established the + call with those participants which have not already left the call. In + other words, if A sends an untriggered INVITE to B, containing C in + the Also header, B will send an INVITE to C. If C has left the call + (a fact which A did not know yet), C will respond with a specific + error code indicating this. In this fashion, B will know that it may + still respond with a 200 OK to A should all other call legs become + established. Furthermore, if other participants have joined the call + since A sent the INVITE to B, B may have established call legs to + them as well. The triggered INVITE will fail if B fails to establish + a call leg with those participants, even if they are not listed in + the Also header. + + Thus, a UAC SHOULD NOT treat a 200 OK to an untriggered INVITE as an + indication that a call leg was established with all (and only) the + participants listed in the Also header. + +6.2 Receiving an Untriggered INVITE + + A UAS can determine whether or not an INVITE was triggered or + untriggered based on the presence of the Requested-By header. + Presence of this header means that the INVITE was triggered, and its + absence implies untriggered. + + If the UAS receiving the INVITE is not currently in the call + identified by the Call-ID, the UAS is being invited to join an + existing call as a new member. The UAS SHOULD alert the user and ask + for confirmation. + + If the UAS receiving the INVITE is currently in a call identified by + the Call-ID, the UAS is being transferred and held. The UAS SHOULD + alert the user and ask for confirmation. + +6.2.1 New Call + + The UAS SHOULD send a 100 Trying response. If the transfer or add + party request is not acceptable to the user, a 6XX response SHOULD be + sent to the UAC. If the transfer/add-party is acceptable, the UAS + MUST NOT respond definitively at this point. + + Instead, the UA formulates an INVITE for each participant listed in + the Also header. Each INVITE MUST also contain a Requested-By header. + This header is formed by attaching the URI in the From field in the + INVITE to the Requested-By header. The token from the element in the + Also field is copied to the token parameter in the Requested-By + header. The URI for the Also field is copied into the To field of the + INVITE. The remaining fields are initialized as they would be for any + other INVITE sent by this UA. The INVITE's generated by the UA are + called triggered INVITEs. + + The UA also formulates an internal participant list. This list + contains a set of URIs for each user, and for each, a version and + status parameter. This list is initialized to the set contained in + the Also header in the INVITE. This list is also placed into the Also + headers of each triggered INVITE. The token in the Also field is + generated as described in section 6.1. Note that this is NOT the same + token received for this Also element in the untriggered INVITE. It is + regenerated with the UA as the originator. + + Each triggered INVITE is then sent. The INVITEs MAY be sent in + parallel, or MAY be sent sequentially, or MAY be sent in any + groupings deemed appropriate. However, for sake of low latencies, + sending the triggered INVITEs all at once is RECOMMENDED. + + If the UA receives a response to any of these INVITEs that is not 200 + or 6XX (Not in Call), the UA determines that it was not successfully + added to the call. It MUST send a BYE to those participants which: + + o responded to a triggered INVITE with a 200 + + o have not yet responded + + o sent it a triggered INVITE for the same call + + The latter case occurs when another party in the call (who has + received an INVITE from the UA) adds a new party as well. This new + party is informed of the UA, and sends it a triggered INVITE. + + The UA MUST then respond to the original untriggered INVITE with an + error code (TBD: what code?). + + If a response to a triggered INVITE is a 200, this response may + contain additional Also headers. These headers contain additional + participants that the recipient of the triggered INVITE knew about, + but the UA did not. The 200 may also contain updated status on + participants the UA knew about. + + The UA uses this list to update its own list of participants. New + users learned about from the 200 OK are added to the list. Users + listed in the 200 OK, which are known to the UA, but whose version + number in the 200 OK is higher, are updated. + + If the resulting update generates new active members, the UA MUST + generate additional triggered INVITEs for them. The generation of + these triggered INVITEs is identical to the above process, with an + important difference. The URI in the Requested-By field is copied + from the To field in the 200 OK. 200 responses to these triggered + INVITEs may cause further triggered invites. + + If the resulting update causes members to move from active to + inactive, the UA should not send them a triggered INVITE if it has + not already done so. + + If the response to a triggered INVITE is a 6xx (not in call), the UA + changes the status of that member to inactive, and increments the + version number (TBD: should this be an increment? Perhaps the 6xx + should contain the new version number). + + Once responses have been received to all triggered INVITEs, all of + which were either 200 or 6xx, the UA responds to the original INVITE + (TBD: should this contain an Also list?). The UA is now in the call. + +6.2.2 Existing Call + + When a UA receives an INVITE containing an Also field, but no + Requested-By field, the INVITE is to transfer/hold the UA. + + If the originator of the INVITE is not already in the call, the + INVITE is ignored. A 200 OK response is sent, however. (Transfers can + only take place from parties already in the call). Those users in the + Also header, who are already in the call, are ignored. If there are + no remaining users from the Also list, the INVITE is ignored. + + The UA then generates triggered INVITEs to the remaining UA's in the + Also list. The behavior from this point forward is identical to + processing triggered INVITE responses in the previous section. + +6.3 Receiving a Triggered INVITE + + When a UA receives an INVITE containing a Requested-By header, it has + received a triggered INVITE. If the INVITE is for a new call, the UA + has just been transferred-to. If the INVITE is for an existing call, + the UA is being informed of a new party in this call. + +6.3.1 New Call + + The UA has just been transferred-to. The Requested-By header contains + the address of the transferring party. The UA SHOULD verify that the + token in the Requested-By header is valid. This will verify that the + transferring party is, in fact the one listed, and that this party + did, in fact, transfer the user listed in the From field. If the + token is not verified, the UAS SHOULD respond with a 4xx code, and + SHOULD NOT alert the user. + + If the token is verified, the UA SHOULD alert the user, and ask for + confirmation. If the user rejects the transfer-to, the UAS SHOULD + send a 6xx response. + + In either case, the UA MUST remember that it rejected the transfer + for this Call-ID. Subsequent triggered INVITEs for the same call MUST + be responded to with the same error response code. The UA MUST cache + its rejection of this transfer (identified by the Call-ID and URI of + the transferring party) for at least XX minutes. (TBD - what happens + if a very old INVITE arrives after the cache expires, and the user + accepts this time - we get a partial disconnect). The UA SHOULD alert + the user if it receives a triggered INVITE with a different user + listed in the Requested-By header, and MAY respond differently to + this transfer. + + If the INVITE is acceptable, the UA sends a 200 OK. Processing of + subsequent triggered INVITEs (one will likely come from each + participant in the call) follows the rules below for an existing + call. + +6.3.2 Existing Call + + When a UA receives a triggered INVITE for an existing call, the + INVITE is an attempt to inform the participant of new members for + that call. + + The UA SHOULD first verify the token. It does so by computing the + hash of the Call-ID, To address, Requested-By address, and From + address. This is compared to the decrypted value of the token using + the public key of the user listed in the Requested-By. If the two + match, the token is verified. + + If the token is not verified, the INVITE is rejected with a 4xx + response. If the token is verified, the UA checks to see if the user + listed in the Requested-By is an active call participant. If they are + not, the INVITE is rejected with a 4xx response (TBD: is there a case + where the UA might not know about this participant yet?). If the user + is a participant, the INVITE is accepted. The user SHOULD NOT be + alerted. + + The list of users in the Also header is then examined. If this list + contains users already known to the UA, the local list of + participants is updated if the version number is higher. If the list + contains users not known to the UA, they are added to the local list + of participants. + + The UA then computes a difference set between its updated list and + the list in the Also header. This set includes any users in its local + list and not in the Also list. The set also includes users in both + lists, but whose version is higher in the local list. This set is + included in the Also header in the 200 OK to the INVITE. The token in + the 200 OK is generated as described in 6.1. + + The UA then computes a second difference set between its updated list + and the list in the Also header. This set includes any users in the + Also list not in its local list. The set also includes users in both + lists, but whose version is higher than in the local list. The active + users from this set are then sent triggered INVITEs. The Requested-By + and Also fields in these triggered INVITEs are computed as described + above. The inactive users in this set are then sent triggered BYE's. + The Requested-By and Also fields in the triggered BYEs are computed + in the same fashion as triggered INVITEs, except a triggered BYE + contains no Also fields. + +6.4 Sending an untriggered BYE + + A UA MAY send a BYE, containing Also headers, at any time. This BYE + simulataneously terminates a call leg with the recipient, and causes + the recipient to attempt to set up a call leg to the parties listed + in the Also header. Unlike the INVITE, the BYE response is sent + immediately, without first adding the various parties. Sending an + untriggered BYE is equivalent to a blind transfer. + + The Also headers in the untriggered BYE MUST contain tokens. These + tokens are generated in the same way described in section 6.1. + +6.5 Receiving an untriggered BYE + + If the BYE corresponds to an existing call leg, the UA sends a 200 OK + to the BYE. If it does not, it sends a 481. + + The UA then generates triggered INVITEs to all participants listed in + the Also field. Generation of the triggered INVITEs, and processing + of their responses, is done in the same fashion as described in + section 6.1. The difference is, of course, that no additional + response is sent to the BYE. + +6.6 Receiving a triggered BYE + + If the BYE doesn't correspond to an existing call leg, the UA sends a + 481. The UA then validates the token in the Requested-By header. If + it is validated, a 200 OK is sent to the BYE, and the call-leg is + torn down. + +7 Replaces header semantics + + The Replaces header is used to allow one call leg to subsume another. + The new call leg is identified by the combination of To, From, and + Call-ID in the INVITE carrying the Replaces header. Replaces is a + request header only, and MUST appear only in INVITEs. A UAS receiving + a Replaces header in a non-INVITE request MUST respond with a 4xx + status code. + + The request containing a Replaces header SHOULD be authenticated. + + The Replaces header contains a list of call-legs, identified by the + URI of the remote party and a Call-ID. If any of these are not valid + call-legs as known to the UAS, the INVITE MUST be responded to with a + 4xx status code. Otherwise, the UAS "abandons" each call leg listed - + acting as if it had never been established. No BYE is sent. A 200 OK + is then sent to the client. + + If a BYE additionally contains Also headers, the UAS MUST first + generate the triggered INVITEs implied by the Also headers. Only if + all triggered INVITEs succeed should the UAS act on the Replaces + header. + +8 Example Call Flows + + This section illustrates some example call flows. Messages are of the + form: + + INV B Also:C,D + BYE A Also:Y + + Where INV implies an INVITE request, and BYE a BYE request. The + letter after the method is the Request URI. Also:C,D implies that + URI's C and D were in the Also header. + +8.1 Basic Transfer + + Figure 2 exemplifies the basic transfer in a two party call. A first + sets up a call to B, and then transfers B to C. + +8.2 Basic Add Party + + Figure 3 exemplifies the basic add party. A and B are already in a + call. A adds C to the call. + +8.3 Add Party during Add Party + + In this example (Figure 4), A and B are in a call. A adds another + party, C, while B adds a different party, D. In the example, B adds D + before learning about C. + +A B C + INV -----------------> - auto dialer 1 customer - Figure 1: Telemarketer example + 200 OK +<---------------- -5.11 Multipoint Control Unit (MCU) Services - In the language of IN services, SIP supports: + ACK +-----------------> - 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. + BYE B Also:C +------------------> - 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: *". + 200 OK +<------------------ INV C ReqBy:A + ---------------------> - 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. + 200 OK + <--------------------- - 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. + ACK + ---------------------> - 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. + Figure 2: Transfer Message Flow - MCU MCU -----------, - 1 ^ 2 | - Also:B / Replace:A | - / | - / 3 V | - A........B A. INVITE - xxxx> BYE + Having received an INVITE from C, D doesn't bother to INVITE C. Both + D and C then OK their respective INVITEs. - Figure 2: Transition from fully-meshed to MCU-based conference +8.4 Party leaves during add party - 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: + In this example (Figure 5), a three party call is in place between A, - O -> A: INVITE A SIP/2.0 - From: O - Also: conference176@M +A B C - A -> M: INVITE conference176@M - Requested-By: O + INV C Also:B +----------------------------------> + INV B Also:C ReqBy:A + <------------------- + 200 OK + --------------------> + ACK + <-------------------- + 200 OK +<----------------------------------- + ACK +-----------------------------------> - Meet-me: The leader and participants dial into their conference at - the scheduled time with an assigned conference identifier and - security code. + Figure 3: Add Party Message Flow - A -> M: INVITE conference189@M - From: A + B and C. A adds another user, D, and shortly thereafer, C leaves the + call. -5.12 Fully-Meshed Conferences - 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. + Since D learns from B that C has left the call, D does not bother to + contact C, and responds right away to the add party. The result is + now a three party call with A,B, and D. -6 Acknowledgements +9 A note on multicast media - Parameters of the terminal negotiation mechanism in the Location - header were influenced by Scott Petrack's CMA design. + Another useful service, which we have not discussed so far, is to + transition a conference from distributing media through multi-unicast + to distribution through multicast. In fact, this is not a SIP issue + at all. However, we discuss it here for completeness. -7 Bibliography + Assume a call between A, B, and C. Media is being distributed through + multi-unicast. At some point, A decides its appropriate to transition + to multicast. It should send a re-INVITE to B and C, containing an + updated SDP with a multicast group (allocated by A by some means, + perhaps MADCAP [5]. If the transition to multicast is acceptable, + both B and C respond with a 200 OK. No SDP is needed in the response, + as per [2]. + + If B and C decide to switch to multicast, it is in their interest + (but not required) to send a re-INVITE to the other participants they + +A B C D + + INV C Also:B +----------------------------------> + INV D Also:A + ---------------------------------> + INV B Also:A ReqBy:A + <---------------- + 200 OK Also:D + -----------------> + INV A Also:A,B +<-------------------------------------------------- + 200 OK Also:C +---------------------------------------------------> + INV D Also:A,B ReqBy:B + ------------------> + 200 OK + <------------------ + ACK + -------------------> + 200 OK + <----------------------------------- + ACK + -----------------------------------> + 200 OK + <----------------- + ACK + ------------------> + + Figure 4: Add Party During Add Party Message Flow + + know about, containing the SDP describing the multicast session. The + result is that some or all of the sessions on the call-legs + transition to multicast. If not all have transitioned, the user may + still need to send some packets unicast. + + There is no capability for determining the codec parameters for the + multicast session based on the intersection of the capabilities of + each participant. The model for multicast media distribution in a + tightly coupled conference is identical to that for loosely coupled + sessions. The initiator of the multicast session chooses a codec, and + that is what is used. Note, however, that in the case where the + +A B C D + + INV D Also:B,C +--------------------------------------------------> + BYE B + <----------------- + BYE A +<-------------------------------- + 200 OK + -----------------> + 200 OK +--------------------------------> + INV B Also:A,B,C ReqBy:A + <----------------------------------- + 200 OK Also:C;status=inactive + -----------------------------------> + ACK + <----------------------------------- + 200 OK +<-------------------------------------------------- + ACK +--------------------------------------------------> + + Figure 5: Party Leaves During Add Message Flow + + sessions start as multi-unicast, the originator will know the + capabilities of all the other parties, and thus can intelligently + choose the codecs for the session. + +10 Security Considerations + + Security issues are addressed throughout this document. + + The call control mechanisms have serious security issues. An INVITE + with an Also cause the recipient to add or drop other parties, + possibly without user interaction. This implies that authorization of + the requests is critical. + +11 Open Issues + + There are many, many open issues: + + 1. How to do this with shared secrets rather than public keys? + + 2. If the transferred-to party in a transfer accepts some, but + not all (or rejects some, but not all) of the INVITEs for + it, we end up with a partially disconnected conference. + + 3. Should we use a session timer to refresh things and + periodically re-flood the participant list, in an attempt + to keep things synchronized? + + 4. The version/status concept is still very vague. Does it + work? Is it needed? + + 5. Conference out of consultation for multi-party calls - not + clear the Replaces mechanism works here. + +12 Acknowledgements + + The authors would like to especially thank Jonathan Lennox for his + many insightful comments and contributions to this work. + +13 Bibliography [1] S. Bradner, "Key words for use in RFCs to indicate requirement - levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. + levels," Request for Comments (Best Current Practice) 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. + [2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: + session initiation protocol," Request for Comments (Proposed + Standard) 2543, Internet Engineering Task Force, Mar. 1999. - [3] M. Handley and V. Jacobson, "SDP: Session description protocol," - Internet Draft, Internet Engineering Task Force, Mar. 1997. Work in - progress. + [3] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: a + transport protocol for real-time applications," Request for Comments + (Proposed Standard) 1889, Internet Engineering Task Force, Jan. 1996. - [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. + [4] C. Elliott, "A 'sticky' conference control protocol," vol. 5, pp. + 97--119, 1994. - [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. + [5] S. Hanna, B. Patel, and M. Shah, "Multicast address dynamic + client allocation protocol (MADCAP)," Internet Draft, Internet + Engineering Task Force, May 1999. Work in progress. + + Full Copyright Statement + + Copyright (c) The Internet Society (1999). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 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 - 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 + 2 Introduction ........................................ 2 + 3 Services ............................................ 2 + 3.1 Blind Transfer ...................................... 3 + 3.2 Transfer and Hold ................................... 4 + 3.3 Transfer with Consultation .......................... 5 + 3.4 Multi-party Conferencing ............................ 6 + 3.4.1 Loosely Coupled Multicast Conference ................ 6 + 3.4.2 Distributed Full Mesh ............................... 7 + 3.4.3 Dial-in Bridge ...................................... 8 + 3.4.4 Ad-hoc Bridge ....................................... 9 + 3.4.5 Conference out of Consultation ...................... 10 + 4 Discussion of Implementation Options ................ 11 + 4.1 Transfer ............................................ 11 + 4.2 Full mesh conferences ............................... 12 + 4.2.1 Approach I: Caretaker ............................... 13 + 4.2.2 Approach II: Flooding ............................... 13 + 4.3 Dial-up Bridges ..................................... 15 + 4.4 Conference out of Consultation ...................... 17 + 4.5 Ad-hoc conference bridging .......................... 17 + 4.6 Transfers to Multiparty Conferences ................. 18 + 5 Header Syntax ....................................... 19 + 5.1 Also ................................................ 19 + 5.2 Replaces ............................................ 20 + 5.3 Requested-By ........................................ 20 + 6 Also and Requested-By Header Semantics .............. 20 + 6.1 Sending an Untriggered INVITE ....................... 20 + 6.2 Receiving an Untriggered INVITE ..................... 22 + 6.2.1 New Call ............................................ 22 + 6.2.2 Existing Call ....................................... 24 + 6.3 Receiving a Triggered INVITE ........................ 24 + 6.3.1 New Call ............................................ 24 + 6.3.2 Existing Call ....................................... 25 + 6.4 Sending an untriggered BYE .......................... 26 + 6.5 Receiving an untriggered BYE ........................ 26 + 6.6 Receiving a triggered BYE ........................... 26 + 7 Replaces header semantics ........................... 26 + 8 Example Call Flows .................................. 27 + 8.1 Basic Transfer ...................................... 27 + 8.2 Basic Add Party ..................................... 27 + 8.3 Add Party during Add Party .......................... 27 + 8.4 Party leaves during add party ....................... 28 + 9 A note on multicast media ........................... 29 + 10 Security Considerations ............................. 31 + 11 Open Issues ......................................... 31 + 12 Acknowledgements .................................... 32 + 13 Bibliography ........................................ 32