From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3725.txt | 1739 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1739 insertions(+) create mode 100644 doc/rfc/rfc3725.txt (limited to 'doc/rfc/rfc3725.txt') diff --git a/doc/rfc/rfc3725.txt b/doc/rfc/rfc3725.txt new file mode 100644 index 0000000..8ee02db --- /dev/null +++ b/doc/rfc/rfc3725.txt @@ -0,0 +1,1739 @@ + + + + + + +Network Working Group J. Rosenberg +Request for Comments: 3725 dynamicsoft +BCP: 85 J. Peterson +Category: Best Current Practice Neustar + H. Schulzrinne + Columbia University + G. Camarillo + Ericsson + April 2004 + + + Best Current Practices for Third Party Call Control (3pcc) + in the Session Initiation Protocol (SIP) + +Status of this Memo + + This document specifies an Internet Best Current Practices for the + Internet Community, and requests discussion and suggestions for + improvements. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2004). All Rights Reserved. + +Abstract + + Third party call control refers to the ability of one entity to + create a call in which communication is actually between other + parties. Third party call control is possible using the mechanisms + specified within the Session Initiation Protocol (SIP). However, + there are several possible approaches, each with different benefits + and drawbacks. This document discusses best current practices for + the usage of SIP for third party call control. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3 + 4. 3pcc Call Establishment . . . . . . . . . . . . . . . . . . 3 + 4.1. Flow I . . . . . . . . . . . . . . . . . . . . . . . . 4 + 4.2. Flow II. . . . . . . . . . . . . . . . . . . . . . . . 5 + 4.3. Flow III . . . . . . . . . . . . . . . . . . . . . . . 7 + 4.4. Flow IV. . . . . . . . . . . . . . . . . . . . . . . . 8 + 5. Recommendations . . . . . . . . . . . . . . . . . . . . . . 9 + 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 10 + 7. Continued Processing . . . . . . . . . . . . . . . . . . . . 11 + 8. 3pcc and Early Media . . . . . . . . . . . . . . . . . . . . 13 + + + +Rosenberg, et al. Best Current Practice [Page 1] + +RFC 3725 SIP 3pcc April 2004 + + + 9. Third Party Call Control and SDP Preconditions . . . . . . . 16 + 9.1. Controller Initiates . . . . . . . . . . . . . . . . . 16 + 9.2. Party A Initiates. . . . . . . . . . . . . . . . . . . 18 + 10. Example Call Flows . . . . . . . . . . . . . . . . . . . . . 21 + 10.1. Click-to-Dial. . . . . . . . . . . . . . . . . . . . . 21 + 10.2. Mid-Call Announcement Capability . . . . . . . . . . . 23 + 11. Implementation Recommendations . . . . . . . . . . . . . . . 25 + 12. Security Considerations. . . . . . . . . . . . . . . . . . . 26 + 12.1. Authorization and Authentication . . . . . . . . . . . 26 + 12.2. End-to-End Encryption and Integrity. . . . . . . . . . 27 + 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 + 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 + 14.1. Normative References . . . . . . . . . . . . . . . . . 28 + 14.2. Informative References . . . . . . . . . . . . . . . . 29 + 15. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 30 + 16. Full Copyright Statement . . . . . . . . . . . . . . . . . . 31 + +1. Introduction + + In the traditional telephony context, third party call control allows + one entity (which we call the controller) to set up and manage a + communications relationship between two or more other parties. Third + party call control (referred to as 3pcc) is often used for operator + services (where an operator creates a call that connects two + participants together) and conferencing. + + Similarly, many SIP services are possible through third party call + control. These include the traditional ones on the PSTN, but also + new ones such as click-to-dial. Click-to-dial allows a user to click + on a web page when they wish to speak to a customer service + representative. The web server then creates a call between the user + and a customer service representative. The call can be between two + phones, a phone and an IP host, or two IP hosts. + + Third party call control is possible using only the mechanisms + specified within RFC 3261 [1]. Indeed, many different call flows are + possible, each of which will work with SIP compliant user agents. + However, there are benefits and drawbacks to each of these flows. + The usage of third party call control also becomes more complex when + aspects of the call utilize SIP extensions or optional features of + SIP. In particular, the usage of RFC 3312 [2] (used for coupling of + signaling to resource reservation) with third party call control is + non-trivial, and is discussed in Section 9. Similarly, the usage of + early media (where session data is exchanged before the call is + accepted) with third party call control is not trivial; both of them + specify the way in which user agents generate and respond to SDP, and + it is not clear how to do both at the same time. This is discussed + further in Section 8. + + + +Rosenberg, et al. Best Current Practice [Page 2] + +RFC 3725 SIP 3pcc April 2004 + + + This document serves as a best current practice for implementing + third party call control without usage of any extensions specifically + designed for that purpose. Section 4 presents the known call flows + that can be used to achieve third party call control, and provides + guidelines on their usage. Section 9 discusses the interactions of + RFC 3312 [2] with third party call control. Section 8 discusses the + interactions of early media with third party call control. Section + 10 provides example applications that make usage of the flows + recommended here. + +2. 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 [3] and + indicate requirement levels for compliant implementations. + +3. Definitions + + The following terms are used throughout this document: + + 3pcc: Third Party Call Control, which refers to the general ability + to manipulate calls between other parties. + + Controller: A controller is a SIP User Agent that wishes to create a + session between two other user agents. + +4. 3pcc Call Establishment + + The primary primitive operation of third party call control is the + establishment of a session between participants A and B. + Establishment of this session is orchestrated by a third party, + referred to as the controller. + + This section documents three call flows that the controller can + utilize in order to provide this primitive operation. + + + + + + + + + + + + + + + +Rosenberg, et al. Best Current Practice [Page 3] + +RFC 3725 SIP 3pcc April 2004 + + +4.1. Flow I + + + A Controller B + |(1) INVITE no SDP | | + |<------------------| | + |(2) 200 offer1 | | + |------------------>| | + | |(3) INVITE offer1 | + | |------------------>| + | |(4) 200 OK answer1 | + | |<------------------| + | |(5) ACK | + | |------------------>| + |(6) ACK answer1 | | + |<------------------| | + |(7) RTP | | + |.......................................| + + Figure 1 + + The call flow for Flow I is shown in Figure 1. The controller first + sends an INVITE A (1). This INVITE has no session description. A's + phone rings, and A answers. This results in a 200 OK (2) that + contains an offer [4]. The controller needs to send its answer in + the ACK, as mandated by [1]. To obtain the answer, it sends the + offer it got from A (offer1) in an INVITE to B (3). B's phone rings. + When B answers, the 200 OK (4) contains the answer to this offer, + answer1. The controller sends an ACK to B (5), and then passes + answer1 to A in an ACK sent to it (6). Because the offer was + generated by A, and the answer generated by B, the actual media + session is between A and B. Therefore, media flows between them (7). + + This flow is simple, requires no manipulation of the SDP by the + controller, and works for any media types supported by both + endpoints. However, it has a serious timeout problem. User B may + not answer the call immediately. The result is that the controller + cannot send the ACK to A right away. This causes A to retransmit the + 200 OK response periodically. As specified in RFC 3261 Section + 13.3.1.4, the 200 OK will be retransmitted for 64*T1 seconds. If an + ACK does not arrive by then, the call is considered to have failed. + This limits the applicability of this flow to scenarios where the + controller knows that B will answer the INVITE immediately. + + + + + + + + +Rosenberg, et al. Best Current Practice [Page 4] + +RFC 3725 SIP 3pcc April 2004 + + +4.2. Flow II + + A Controller B + |(1) INVITE bh sdp1 | | + |<------------------| | + |(2) 200 sdp2 | | + |------------------>| | + | |(3) INVITE sdp2 | + | |------------------>| + |(4) ACK | | + |<------------------| | + | |(5) 200 OK sdp3 | + | |<------------------| + | |(6) ACK | + | |------------------>| + |(7) INVITE sdp3 | | + |<------------------| | + |(8) 200 OK sdp2 | | + |------------------>| | + |(9) ACK | | + |<------------------| | + |(10) RTP | | + |.......................................| + + Figure 2 + + An alternative flow, Flow II, is shown in Figure 2. The controller + first sends an INVITE to user A (1). This is a standard INVITE, + containing an offer (sdp1) with a single audio media line, one codec, + a random port number (but not zero), and a connection address of + 0.0.0.0. This creates an initial media stream that is "black holed", + since no media (or RTCP packets [8]) will flow from A. The INVITE + causes A's phone to ring. + + + Note that the usage of 0.0.0.0, though recommended by RFC 3264, + has numerous drawbacks. It is anticipated that a future + specification will recommend usage of a domain within the .invalid + DNS top level domain instead of the 0.0.0.0 IP address. As a + result, implementors are encouraged to track such developments + once they arise. + + When A answers (2), the 200 OK contains an answer, sdp2, with a valid + address in the connection line. The controller sends an ACK (4). It + then generates a second INVITE (3). This INVITE is addressed to user + B, and it contains sdp2 as the offer to B. Note that the role of sdp2 + has changed. In the 200 OK (message 2), it was an answer, but in the + INVITE, it is an offer. Fortunately, all valid answers are valid + + + +Rosenberg, et al. Best Current Practice [Page 5] + +RFC 3725 SIP 3pcc April 2004 + + + initial offers. This INVITE causes B's phone to ring. When it + answers, it generates a 200 OK (5) with an answer, sdp3. The + controller then generates an ACK (6). Next, it sends a re-INVITE to + A (7) containing sdp3 as the offer. Once again, there has been a + reversal of roles. sdp3 was an answer, and now it is an offer. + Fortunately, an answer to an answer recast as an offer is, in turn, a + valid offer. This re-INVITE generates a 200 OK (8) with sdp2, + assuming that A doesn't decide to change any aspects of the session + as a result of this re-INVITE. This 200 OK is ACKed (9), and then + media can flow from A to B. Media from B to A could already start + flowing once message 5 was sent. + + This flow has the advantage that all final responses are immediately + ACKed. It therefore does not suffer from the timeout and message + inefficiency problems of flow 1. However, it too has troubles. + First off, it requires that the controller know the media types to be + used for the call (since it must generate a "blackhole" SDP, which + requires media lines). Secondly, the first INVITE to A (1) contains + media with a 0.0.0.0 connection address. The controller expects that + the response contains a valid, non-zero connection address for A. + However, experience has shown that many UAs respond to an offer of a + 0.0.0.0 connection address with an answer containing a 0.0.0.0 + connection address. The offer-answer specification [4] explicitly + tells implementors not to do this, but at the time of publication of + this document, many implementations still did. If A should respond + with a 0.0.0.0 connection address in sdp2, the flow will not work. + + However, the most serious flaw in this flow is the assumption that + the 200 OK to the re-INVITE (message 8) contains the same SDP as in + message 2. This may not be the case. If it is not, the controller + needs to re-INVITE B with that SDP (say, sdp4), which may result in + getting a different SDP, sdp5, in the 200 OK from B. Then, the + controller needs to re-INVITE A again, and so on. The result is an + infinite loop of re-INVITEs. It is possible to break this cycle by + having very smart UAs which can return the same SDP whenever + possible, or really smart controllers that can analyze the SDP to + determine if a re-INVITE is really needed. However, we wish to keep + this mechanism simple, and avoid SDP awareness in the controller. As + a result, this flow is not really workable. It is therefore NOT + RECOMMENDED. + + + + + + + + + + + +Rosenberg, et al. Best Current Practice [Page 6] + +RFC 3725 SIP 3pcc April 2004 + + +4.3. Flow III + + A Controller B + |(1) INVITE no SDP | | + |<---------------------| | + |(2) 200 offer1 | | + |--------------------->| | + |(3) ACK answer1 (bh) | | + |<---------------------| | + | |(4) INVITE no SDP | + | |--------------------->| + | |(5) 200 OK offer2 | + | |<---------------------| + |(6) INVITE offer2' | | + |<---------------------| | + |(7) 200 answer2' | | + |--------------------->| | + | |(8) ACK answer2 | + | |--------------------->| + |(9) ACK | | + |<---------------------| | + |(10) RTP | | + |.............................................| + + Figure 3 + + A third flow, Flow III, is shown in Figure 3. + + First, the controller sends an INVITE (1) to user A without any SDP + (which is good, since it means that the controller doesn't need to + assume anything about the media composition of the session). A's + phone rings. When A answers, a 200 OK is generated (2) containing + its offer, offer1. The controller generates an immediate ACK + containing an answer (3). This answer is a "black hole" SDP, with + its connection address equal to 0.0.0.0. + + The controller then sends an INVITE to B without SDP (4). This + causes B's phone to ring. When they answer, a 200 OK is sent, + containing their offer, offer2 (5). This SDP is used to create a + re-INVITE back to A (6). That re-INVITE is based on offer2, but may + need to be reorganized to match up media lines, or to trim media + lines. For example, if offer1 contained an audio and a video line, + in that order, but offer2 contained just an audio line, the + controller would need to add a video line to the offer (setting its + port to zero) to create offer2'. Since this is a re-INVITE, it + should complete quickly in the general case. That's good, since user + B is retransmitting their 200 OK, waiting for an ACK. The SDP in the + + + + +Rosenberg, et al. Best Current Practice [Page 7] + +RFC 3725 SIP 3pcc April 2004 + + + 200 OK (7) from A, answer2', may also need to be reorganized or + trimmed before sending it an the ACK to B (8) as answer2. Finally, + an ACK is sent to A (9), and then media can flow. + + This flow has many benefits. First, it will usually operate without + any spurious retransmissions or timeouts (although this may still + happen if a re-INVITE is not responded to quickly). Secondly, it + does not require the controller to guess the media that will be used + by the participants. + + There are some drawbacks. The controller does need to perform SDP + manipulations. Specifically, it must take some SDP, and generate + another SDP which has the same media composition, but has connection + addresses equal to 0.0.0.0. This is needed for message 3. Secondly, + it may need to reorder and trim SDP X, so that its media lines match + up with those in some other SDP, Y. Thirdly, the offer from B + (offer2) may have no codecs or media streams in common with the offer + from A (offer 1). The controller will need to detect this condition, + and terminate the call. Finally, the flow is far more complicated + than the simple and elegant Flow I (Figure 1). + +4.4. Flow IV + + A Controller B + |(1) INVITE offer1 | | + |no media | | + |<---------------------| | + |(2) 200 answer1 | | + |no media | | + |--------------------->| | + |(3) ACK | | + |<---------------------| | + | |(4) INVITE no SDP | + | |--------------------->| + | |(5) 200 OK offer2 | + | |<---------------------| + |(6) INVITE offer2' | | + |<---------------------| | + |(7) 200 answer2' | | + |--------------------->| | + | |(8) ACK answer2 | + | |--------------------->| + |(9) ACK | | + |<---------------------| | + |(10) RTP | | + |.............................................| + + Figure 4 + + + +Rosenberg, et al. Best Current Practice [Page 8] + +RFC 3725 SIP 3pcc April 2004 + + + Flow IV shows a variation on Flow III that reduces its complexity. + The actual message flow is identical, but the SDP placement and + construction differs. The initial INVITE (1) contains SDP with no + media at all, meaning that there are no m lines. This is valid, and + implies that the media makeup of the session will be established + later through a re-INVITE [4]. Once the INVITE is received, user A + is alerted. When they answer the call, the 200 OK (2) has an answer + with no media either. This is acknowledged by the controller (3). + The flow from this point onwards is identical to Flow III. However, + the manipulations required to convert offer2 to offer2', and answer2' + to answer2, are much simpler. Indeed, no media manipulations are + needed at all. The only change that is needed is to modify the + origin lines, so that the origin line in offer2' is valid based on + the value in offer1 (validity requires that the version increments by + one, and that the other parameters remain unchanged). + + There are some limitations associated with this flow. First, user A + will be alerted without any media having been established yet. This + means that user A will not be able to reject or accept the call based + on its media composition. Secondly, both A and B will end up + answering the call (i.e., generating a 200 OK) before it is known + whether there is compatible media. If there is no media in common, + the call can be terminated later with a BYE. However, the users will + have already been alerted, resulting in user annoyance and possibly + resulting in billing events. + +5. Recommendations + + Flow I (Figure 1) represents the simplest and the most efficient + flow. This flow SHOULD be used by a controller if it knows with + certainty that user B is actually an automata that will answer the + call immediately. This is the case for devices such as media + servers, conferencing servers, and messaging servers, for example. + Since we expect a great deal of third party call control to be to + automata, special casing in this scenario is reasonable. + + For calls to unknown entities, or to entities known to represent + people, it is RECOMMENDED that Flow IV (Figure 4) be used for third + party call control. Flow III MAY be used instead, but it provides no + additional benefits over Flow IV. However, Flow II SHOULD NOT be + used, because of the potential for infinite ping-ponging of re- + INVITEs. + + Several of these flows use a "black hole" connection address of + 0.0.0.0. This is an IPv4 address with the property that packets sent + to it will never leave the host which sent them; they are just + + + + + +Rosenberg, et al. Best Current Practice [Page 9] + +RFC 3725 SIP 3pcc April 2004 + + + discarded. Those flows are therefore specific to IPv4. For other + network or address types, an address with an equivalent property + SHOULD be used. + + In most cases, including the recommended flows, user A will hear + silence while the call to B completes. This may not always be ideal. + It can be remedied by connecting the caller to a music-on-hold source + while the call to B occurs. + +6. Error Handling + + There are numerous error cases which merit discussion. + + With all of the call flows in Section 4, one call is established to + A, and then the controller attempts to establish a call to B. + However, this call attempt may fail, for any number of reasons. User + B might be busy (resulting in a 486 response to the INVITE), there + may not be any media in common, the request may time out, and so on. + If the call attempt to B should fail, it is RECOMMENDED that the + controller send a BYE to A. This BYE SHOULD include a Reason header + [5] which carries the status code from the error response. This will + inform A of the precise reason for the failure. The information is + important from a user interface perspective. For example, if A was + calling from a black phone, and B generated a 486, the BYE will + contain a Reason code of 486, and this could be used to generate a + local busy signal so that A knows that B is busy. + + A Controller B + |(1) INVITE offer1 | | + |no media | | + |<---------------------| | + |(2) 200 answer1 | | + |no media | | + |--------------------->| | + |(3) ACK | | + |<---------------------| | + | |(4) INVITE no SDP | + | |--------------------->| + | |(5) 180 | + | |<---------------------| + |(6) INVITE offer2 | | + |--------------------->| | + |(7) 491 | | + |<---------------------| | + |(8) ACK | | + |--------------------->| | + + Figure 5 + + + +Rosenberg, et al. Best Current Practice [Page 10] + +RFC 3725 SIP 3pcc April 2004 + + + Another error condition worth discussion is shown in Figure 5. After + the controller establishes the dialog with A (messages 1-3) it + attempts to contact B (message 4). Contacting B may take some time. + During that interval, A could possibly attempt a re-INVITE, providing + an updated offer. However, the controller cannot pass this offer on + to B, since it has an INVITE transaction pending with it. As a + result, the controller needs to reject the request. It is + RECOMMENDED that a 491 response be used. The situation here is + similar to the glare condition described in [1], and thus the same + error handling is sensible. However, A is likely to retry its + request (as a result of the 491), and this may occur before the + exchange with B is completed. In that case, the controller would + respond with another 491. + +7. Continued Processing + + Once the calls are established, both participants believe they are in + a single point-to-point call. However, they are exchanging media + directly with each other, rather than with the controller. The + controller is involved in two dialogs, yet sees no media. + + Since the controller is still a central point for signaling, it now + has complete control over the call. If it receives a BYE from one of + the participants, it can create a new BYE and hang up with the other + participant. This is shown in Figure 6. + + A Controller B + |(1) BYE | | + |------------------>| | + |(2) 200 OK | | + |<------------------| | + | |(3) BYE | + | |------------------>| + | |(4) 200 OK | + | |<------------------| + + Figure 6 + + Similarly, if it receives a re-INVITE from one of the participants, + it can forward it to the other participant. Depending on which flow + was used, this may require some manipulation on the SDP before + passing it on. + + However, the controller need not "proxy" the SIP messages received + from one of the parties. Since it is a Back-to-Back User Agent + (B2BUA), it can invoke any signaling mechanism on each dialog, as it + sees fit. For example, if the controller receives a BYE from A, it + can generate a new INVITE to a third party, C, and connect B to that + + + +Rosenberg, et al. Best Current Practice [Page 11] + +RFC 3725 SIP 3pcc April 2004 + + + participant instead. A call flow for this is shown in Figure 7, + assuming the case where C represents an end user, not an automata. + Note that it is just Flow IV. + + A Controller B C + |(1) BYE | | | + |--------------->| | | + |(2) 200 OK | | | + |<---------------| | | + | |(3) INV no media| | + | |-------------------------------->| + | |(4) 200 no media| | + | |<--------------------------------| + | |(5) ACK | | + | |-------------------------------->| + | |(6) INV no SDP | | + | |--------------->| | + | |(7) 200 offer3 | | + | |<---------------| | + | |(8) INV offer3' | | + | |-------------------------------->| + | |(9) 200 answer3'| | + | |<--------------------------------| + | |(10) ACK | | + | |-------------------------------->| + | |(11) ACK answer3| | + | |--------------->| | + | | |(12) RTP | + | | |................| + + Figure 7 + + From here, new parties can be added, removed, transferred, and so on, + as the controller sees fit. In many cases, the controller will be + required to modify the SDP exchanged between the participants in + order to affect these changes. In particular, the version number in + the SDP will need to be changed by the controller in certain cases. + If the controller should issue an SDP offer on its own (for example, + to place a call on hold), it will need to increment the version + number in the SDP offer. The other participant in the call will not + know that the controller has done this, and any subsequent offer it + generates will have the wrong version number as far as its peer is + concerned. As a result, the controller will be required to modify + the version number in SDP messages to match what the recipient is + expecting. + + + + + + +Rosenberg, et al. Best Current Practice [Page 12] + +RFC 3725 SIP 3pcc April 2004 + + + It is important to point out that the call need not have been + established by the controller in order for the processing of this + section to be used. Rather, the controller could have acted as a + B2BUA during a call established by A towards B (or vice versa). + + +8. 3pcc and Early Media + + Early media represents the condition where the session is established + (as a result of the completion of an offer/answer exchange), yet the + call itself has not been accepted. This is usually used to convey + tones or announcements regarding progress of the call. Handling of + early media in a third party call is straightforward. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Rosenberg, et al. Best Current Practice [Page 13] + +RFC 3725 SIP 3pcc April 2004 + + + A Controller B + | | | + |(1) INVITE offer1 | | + |no media | | + |<---------------------| | + | | | + | | | + | | | + | | | + | | | + |(2) 200 answer1 | | + |no media | | + |--------------------->| | + |(3) ACK | | + |<---------------------| | + | |(4) INVITE no SDP | + | |--------------------->| + | | | + | |(5) 183 offer2 | + | |<---------------------| + |(6) INVITE offer2' | | + |<---------------------| | + |(7) 200 answer2' | | + |--------------------->| | + |(8) ACK | | + |<---------------------| | + | |(9) PRACK answer2 | + | |--------------------->| + | |(10) 200 PRACK | + | |<---------------------| + |(11) RTP | | + |.............................................| + | | | + | |(12) 200 OK | + | |<---------------------| + | |(13) ACK | + | |--------------------->| + + Figure 8 + + Figure 8 shows the case where user B generates early media before + answering the call. The flow is almost identical to Flow IV from + Figure 4. The only difference is that user B generates a reliable + provisional response (5) [6] instead of a final response, and answer2 + is carried in a PRACK (9) instead of an ACK. When party B finally + does accept the call (12), there is no change in the session state, + and therefore, no signaling needs to be done with user A. The + controller simply ACKs the 200 OK (13) to confirm the dialog. + + + +Rosenberg, et al. Best Current Practice [Page 14] + +RFC 3725 SIP 3pcc April 2004 + + + A Controller B + | | | + |(1) INVITE offer1 | | + |no media | | + |<---------------------| | + | | | + |ring | | + | | | + |(2) 183 answer1 | | + |no media | | + |--------------------->| | + |(3) PRACK | | + |<---------------------| | + |(4) 200 PRACK | | + |--------------------->| | + | |(5) INVITE no SDP | + | |--------------------->| + | | |ring + | | | + | | |answer + | | | + | |(6) 200 OK offer2 | + | |<---------------------| + |(7) UPDATE offer2' | | + |<---------------------| | + | | | + |(8) 200 answer2' | | + |--------------------->| | + | |(9) ACK answer2 | + | |--------------------->| + |(10) RTP | | + |.............................................| + | | | + |answer | | + | | | + |(11) 200 OK | | + |--------------------->| | + |(12) ACK | | + |<---------------------| | + + Figure 9 + + The case where user A generates early media is more complicated, and + is shown in Figure 9. The flow is based on Flow IV. The controller + sends an INVITE to user A (1), with an offer containing no media + streams. User A generates a reliable provisional response (2) + containing an answer with no media streams. The controller PRACKs + this provisional response (3). Now, the controller sends an INVITE + + + +Rosenberg, et al. Best Current Practice [Page 15] + +RFC 3725 SIP 3pcc April 2004 + + + without SDP to user B (5). User B's phone rings, and they answer, + resulting in a 200 OK (6) with an offer, offer2. The controller now + needs to update the session parameters with user A. However, since + the call has not been answered, it cannot use a re-INVITE. Rather, + it uses a SIP UPDATE request (7) [7], passing the offer (after + modifying it to get the origin field correct). User A generates its + answer in the 200 OK to the UPDATE (8). This answer is passed to + user B in the ACK (9). When user A finally answers (11), there is no + change in session state, so the controller simply ACKs the 200 OK + (12). + + Note that it is likely that there will be clipping of media in this + call flow. User A is likely a PSTN gateway, and has generated a + provisional response because of early media from the PSTN side. The + PSTN will deliver this media even though the gateway does not have + anywhere to send it, since the initial offer from the controller had + no media streams. When user B answers, media can begin to flow. + However, any media sent to the gateway from the PSTN up to that point + will be lost. + +9. Third Party Call Control and SDP Preconditions + + A SIP extension has been specified that allows for the coupling of + signaling and resource reservation [2]. This specification relies on + exchanges of session descriptions before completion of the call + setup. These flows are initiated when certain SDP parameters are + passed in the initial INVITE. As a result, the interaction of this + mechanism with third party call control is not obvious, and worth + detailing. + +9.1. Controller Initiates + + In one usage scenario, the controller wishes to make use of + preconditions in order to avoid the call failure scenarios documented + in Section 4.4. Specifically, the controller can use preconditions in + order to guarantee that neither party is alerted unless there is a + common set of media and codecs. It can also provide both parties + with information on the media composition of the call before they + decide to accept it. + + + + + + + + + + + + +Rosenberg, et al. Best Current Practice [Page 16] + +RFC 3725 SIP 3pcc April 2004 + + + User A Controller Customer Service + (User B) + | | | + |(1) INVITE no SDP | | + |require precon | | + |<------------------| | + |(2) 183 offer1 | | + |optional precon | | + |------------------>| | + | | | + | |(3) INVITE offer1 | + | |------------------>| + | | | + | | | + | | | + | |(4) 200 OK answer1 | + | |no precon | + | |<------------------| + | |(5) ACK | + | |------------------>| + |(6) PRACK answer1 | | + |<------------------| | + | | | + | | | + |(7) 200 PRACK | | + |------------------>| | + | | | + | | | + |(8) 200 INVITE | | + |------------------>| | + |(9) ACK | | + |<------------------| | + + + Figure 10 + + The flow for this scenario is shown in Figure 10. In this example, + we assume that user B is an automata or agent of some sort which will + answer the call immediately. Therefore, the flow is based on Flow I. + The controller sends an INVITE to user A containing no SDP, but with + a Require header indicating that preconditions are required. This + specific scenario (an INVITE without an offer, but with a Require + header indicating preconditions) is not described in [2]. It is + RECOMMENDED that the UAS respond with an offer in a 1xx including the + media streams it wishes to use for the call, and for each, list all + preconditions it supports as optional. Of course, the user is not + alerted at this time. The controller takes this offer and passes it + to user B (3). User B does not support preconditions, or does, but + + + +Rosenberg, et al. Best Current Practice [Page 17] + +RFC 3725 SIP 3pcc April 2004 + + + is not interested in them. Therefore, when it answers the call, the + 200 OK contains an answer without any preconditions listed (4). This + answer is passed to user A in the PRACK (6). At this point, user A + knows that there are no preconditions actually in use for the call, + and therefore, it can alert the user. When the call is answered, + user A sends a 200 OK to the controller (8) and the call is complete. + + In the event that the offer generated by user A was not acceptable to + user B (because of non-overlapping codecs or media, for example), + user B would immediately reject the INVITE (message 3). The + controller would then CANCEL the request to user A. In this + situation, neither user A nor user B would have been alerted, + achieving the desired effect. It is interesting to note that this + property is achieved using preconditions even though it doesn't + matter what specific types of preconditions are supported by user A. + + It is also entirely possible that user B does actually desire + preconditions. In that case, it might generate a 1xx of its own with + an answer containing preconditions. That answer would still be + passed to user A, and both parties would proceed with whatever + measures are necessary to meet the preconditions. Neither user would + be alerted until the preconditions were met. + +9.2. Party A Initiates + + In Section 9.1, the controller requested the use of preconditions to + achieve a specific goal. It is also possible that the controller + doesn't care (or perhaps doesn't even know) about preconditions, but + one of the participants in the call does care. A call flow for this + case is shown in Figure 11. + + A Controller B + |(1) INVITE offer1 | | + |no media | | + |<---------------------| | + |(2) 183 answer1 | | + |no media | | + |--------------------->| | + |(3) PRACK | | + |<---------------------| | + |(4) 200 OK | | + |--------------------->| | + | |(5) INVITE no SDP | + | |--------------------->| + | |(6) 183 offer2 | + | |des=sendrecv | + | |conf=recv | + | |cur=none | + + + +Rosenberg, et al. Best Current Practice [Page 18] + +RFC 3725 SIP 3pcc April 2004 + + + | |<---------------------| + |(7) UPDATE offer2' | | + |des=sendrecv | | + |conf=recv | | + |cur=none | | + |<---------------------| | + |(8) 200 UPDATE | | + |answer2' | | + |des=sendrecv | | + |conf=recv | | + |cur=none | | + |--------------------->| | + | |(9) PRACK answer2 | + | |des=sendrecv | + | |conf=recv | + | |cur=none | + | |--------------------->| + | |(10) 200 PRACK | + | |<---------------------| + |(11) reservation | | + |-------------------------------------------->| + |(12) reservation | | + |<--------------------------------------------| + |(13) UPDATE offer3 | | + |des=sendrecv | | + |conf=recv | | + |cur=recv | | + |--------------------->| | + | |(14) UPDATE offer3' | + | |des=sendrecv | + | |conf=recv | + | |cur=recv | + | |--------------------->| + | |(15) 200 UPDATE | + | |answer3' | + | |des=sendrecv | + | |conf=recv | + | |cur=send | + | |<---------------------| + |(16) 200 UPDATE | | + |answer3 | | + |des=sendrecv | | + |conf=recv | | + |cur=send | | + |<---------------------| | + | | | + | |(17) UPDATE offer4 | + | |des=sendrecv | + + + +Rosenberg, et al. Best Current Practice [Page 19] + +RFC 3725 SIP 3pcc April 2004 + + + | |conf=recv | + | |cur=sendrecv | + | |<---------------------| + |(18) UPDATE offer4' | | + |des=sendrecv | | + |conf=recv | | + |cur=sendrecv | | + |<---------------------| | + | | | + |(19) 200 UPDATE | | + |answer4' | | + |des=sendrecv | | + |conf=recv | | + |cur=sendrecv | | + |--------------------->| | + | |(20) 200 UPDATE | + | |answer4 | + | |des=sendrecv | + | |conf=recv | + | |cur=sendrecv | + | |--------------------->| + |(21) 180 INVITE | | + |--------------------->| | + | |(22) 180 INVITE | + | |<---------------------| + | | | + |(23) 200 INVITE | | + |--------------------->| | + |(24) ACK | | + |<---------------------| | + | | | + | |(25) 200 INVITE | + | |<---------------------| + | |(26) ACK | + | |--------------------->| + + Figure 11 + + The controller follows Flow IV; it has no specific requirements for + support of the preconditions specification [2]. Therefore, it sends + an INVITE (1) with SDP that contains no media lines. User A is + interested in supporting preconditions, and does not want to ring its + phone until resources are reserved. Since there are no media streams + in the INVITE, it can't reserve resources for media streams, and + therefore it can't ring the phone until they are conveyed in a + subsequent offer and then reserved. Therefore, it generates a 183 + with the answer, and doesn't alert the user (2). The controller + PRACKs this (3) and A responds to the PRACK (4). + + + +Rosenberg, et al. Best Current Practice [Page 20] + +RFC 3725 SIP 3pcc April 2004 + + + At this point, the controller attempts to bring B into the call. It + sends B an INVITE without SDP (5). B is interested in having + preconditions for this call. Therefore, it generates its offer in a + 183 that contains the appropriate SDP attributes (6). The controller + passes this offer to A in an UPDATE request (7). The controller uses + UPDATE because the call has not been answered yet, and therefore, it + cannot use a re-INVITE. User A sees that its peer is capable of + supporting preconditions. Since it desires preconditions for the + call, it generates an answer in the 200 OK (8) to the UPDATE. This + answer, in turn, is passed to B in the PRACK for the provisional + response (9). Now, both sides perform resource reservation. User A + succeeds first, and passes an updated session description in an + UPDATE request (13). The controller simply passes this to A (after + the manipulation of the origin field, as required in Flow IV) in an + UPDATE (14), and the answer (15) is passed back to A (16). The same + flow happens, but from B to A, when B's reservation succeeds (17-20). + Since the preconditions have been met, both sides ring (21 and 22), + and then both answer (23 and 25), completing the call. + + What is important about this flow is that the controller doesn't know + anything about preconditions. It merely passes the SDP back and + forth as needed. The trick is the usage of UPDATE and PRACK to pass + the SDP when needed. That determination is made entirely based on + the offer/answer rules described in [6] and [7], and is independent + of preconditions. + +10. Example Call Flows + +10.1. Click-to-Dial + + The first application of this capability we discuss is click-to-dial. + In this service, a user is browsing the web page of an e-commerce + site, and would like to speak to a customer service representative. + The user clicks on a link, and a call is placed to a customer service + representative. When the representative picks up, the phone on the + user's desk rings. When the user pick up, the customer service + representative is there, ready to talk to the user. + + + + + + + + + + + + + + +Rosenberg, et al. Best Current Practice [Page 21] + +RFC 3725 SIP 3pcc April 2004 + + +Customer Service Controller User's Phone User's Browser + | |(1) HTTP POST | | + | |<--------------------------------------| + | |(2) HTTP 200 OK | | + | |-------------------------------------->| + |(3) INVITE offer1 | | | + |no media | | | + |<------------------| | | + |(4) 200 answer1 | | | + |no media | | | + |------------------>| | | + |(5) ACK | | | + |<------------------| | | + | |(6) INVITE no SDP | | + | |------------------>| | + | |(7) 200 OK offer2 | | + | |<------------------| | + |(8) INVITE offer2' | | | + |<------------------| | | + |(9) 200 answer2' | | | + |------------------>| | | + | |(10) ACK answer2 | | + | |------------------>| | + |(11) ACK | | | + |<------------------| | | + |(12) RTP | | | + |.......................................| | + + Figure 12 + + The call flow for this service is given in Figure 12. It is + identical to that of Figure 4, with the exception that the service is + triggered through an HTTP POST request when the user clicks on the + link. Normally, this POST request would contain neither the number + of the user or of the customer service representative. The user's + number would typically be obtained by the web application from back- + end databases, since the user would have presumably logged into the + site, giving the server the needed context. The customer service + number would typically be obtained through provisioning. Thus, the + HTTP POST is actually providing the server nothing more than an + indication that a call is desired. + + We note that this service can be provided through other mechanisms, + namely PINT [9]. However, there are numerous differences between the + way in which the service is provided by PINT, and the way in which it + is provided here: + + + + + +Rosenberg, et al. Best Current Practice [Page 22] + +RFC 3725 SIP 3pcc April 2004 + + + o The PINT solution enables calls only between two PSTN endpoints. + The solution described here allows calls between PSTN phones + (through SIP enabled gateways) and native IP phones. + + o When used for calls between two PSTN phones, the solution here may + result in a portion of the call being routed over the Internet. + In PINT, the call is always routed only over the PSTN. This may + result in better quality calls with the PINT solution, depending + on the codec in use and QoS capabilities of the network routing + the Internet portion of the call. + + o The PINT solution requires extensions to SIP (PINT is an extension + to SIP), whereas the solution described here is done with baseline + SIP. + + o The PINT solution allows the controller (acting as a PINT client) + to "step out" once the call is established. The solution + described here requires the controller to maintain call state for + the entire duration of the call. + +10.2. Mid-Call Announcement Capability + + The third party call control mechanism described here can also be + used to enable mid-call announcements. Consider a service for pre- + paid calling cards. Once the pre-paid call is established, the + system needs to set a timer to fire when they run out of minutes. + When this timer fires, we would like the user to hear an announcement + which tells them to enter a credit card to continue. Once they enter + the credit card info, more money is added to the pre-paid card, and + the user is reconnected to the destination party. + + We consider here the usage of third party call control just for + playing the mid-call dialog to collect the credit card information. + + + + + + + + + + + + + + + + + + +Rosenberg, et al. Best Current Practice [Page 23] + +RFC 3725 SIP 3pcc April 2004 + + + Pre-Paid User Controller Called Party Media Server + | |(1) INV SDP c=bh | | + | |------------------>| | + | |(2) 200 answer1 | | + | |<------------------| | + | |(3) ACK | | + | |------------------>| | + |(4) INV no SDP | | | + |<------------------| | | + |(5) 200 offer2 | | | + |------------------>| | | + | |(6) INV offer2 | | + | |-------------------------------------->| + | |(7) 200 answer2 | | + | |<--------------------------------------| + |(8) ACK answer2 | | | + |<------------------| | | + | |(9) ACK | | + | |-------------------------------------->| + |(10) RTP | | | + |...........................................................| + | |(11) BYE | | + | |-------------------------------------->| + | |(12) 200 OK | | + | |<--------------------------------------| + | |(13) INV no SDP | | + | |------------------>| | + | |(14) 200 offer3 | | + | |<------------------| | + |(15) INV offer3' | | | + |<------------------| | | + |(16) 200 answer3' | | | + |------------------>| | | + | |(17) ACK answer3' | | + | |------------------>| | + |(18) ACK | | | + |<------------------| | | + |(19) RTP | | | + |.......................................| | + + Figure 13 + + We assume the call is set up so that the controller is in the call as + a B2BUA. When the timer fires, we wish to connect the caller to a + media server. The flow for this is shown in Figure 13. When the + timer expires, the controller places the called party with a + connection address of 0.0.0.0 (1). This effectively "disconnects" + the called party. The controller then sends an INVITE without SDP to + + + +Rosenberg, et al. Best Current Practice [Page 24] + +RFC 3725 SIP 3pcc April 2004 + + + the pre-paid caller (4). The offer returned from the caller (5) is + used in an INVITE to the media server which will be collecting digits + (6). This is an instantiation of Flow I. This flow can only be used + here because the media server is an automata, and will answer the + INVITE immediately. If the controller was connecting the pre-paid + user with another end user, Flow III would need to be used. The + media server returns an immediate 200 OK (7) with an answer, which is + passed to the caller in an ACK (8). The result is that the media + server and the pre-paid caller have their media streams connected. + + The media server plays an announcement, and prompts the user to enter + a credit card number. After collecting the number, the card number + is validated. The media server then passes the card number to the + controller (using some means outside the scope of this + specification), and then hangs up the call (11). + + After hanging up with the media server, the controller reconnects the + user to the original called party. To do this, the controller sends + an INVITE without SDP to the called party (13). The 200 OK (14) + contains an offer, offer3. The controller modifies the SDP (as is + done in Flow III), and passes the offer in an INVITE to the pre-paid + user (15). The pre-paid user generates an answer in a 200 OK (16) + which the controller passes to user B in the ACK (17). At this + point, the caller and called party are reconnected. + +11. Implementation Recommendations + + Most of the work involved in supporting third party call control is + within the controller. A standard SIP UA should be controllable + using the mechanisms described here. However, third party call + control relies on a few features that might not be implemented. As + such, we RECOMMEND that implementors of user agent servers support + the following: + + o Offers and answers that contain a connection line with an address + of 0.0.0.0. + + o Re-INVITE requests that change the port to which media should be + sent + + o Re-INVITEs that change the connection address + + o Re-INVITEs that add a media stream + + o Re-INVITEs that remove a media stream (setting its port to zero) + + o Re-INVITEs that add a codec amongst the set in a media stream + + + + +Rosenberg, et al. Best Current Practice [Page 25] + +RFC 3725 SIP 3pcc April 2004 + + + o SDP Connection address of zero + + o Initial INVITE requests with a connection address of zero + + o Initial INVITE requests with no SDP + + o Initial INVITE requests with SDP but no media lines + + o Re-INVITEs with no SDP + + o The UPDATE method [7] + + o Reliability of provisional responses [6] + + o Integration of resource management and SIP [2]. + +12. Security Considerations + +12.1. Authorization and Authentication + + In most uses of SIP INVITE, whether or not a call is accepted is + based on a decision made by a human when presented information about + the call, such as the identity of the caller. In other cases, + automata answer the calls, and whether or not they do so may depend + on the particular application to which SIP is applied. For example, + if a caller makes a SIP call to a voice portal service, the call may + be rejected unless the caller has previously signed up (perhaps via a + web site). In other cases, call handling policies are made based on + automated scripts, such as those described by the Call Processing + Language [11]. Frequently, those decisions are also made based on + the identity of the caller. + + These authorization mechanisms would be applied to normal first party + calls and third party calls, as these two are indistinguishable. As + a result, it is important for these authorization policies to + continue to operate correctly for third party calls. Of course, + third party calls introduce a new party - the one initiating the + third party call. Do the authorization policies apply based on the + identity of that third party, or do they apply based on the + participants in the call? Ideally, the participants would be able to + know the identities of both other parties, and have authorization + policies be based on those, as appropriate. However, this is not + possible using existing mechanisms. As a result, the next best thing + is for the INVITE requests to contain the identity of the third + party. Ultimately, this is the user who is requesting communication, + and it makes sense for call authorization policies to be based on + that identity. + + + + +Rosenberg, et al. Best Current Practice [Page 26] + +RFC 3725 SIP 3pcc April 2004 + + + This requires, in turn, that the controller authenticate itself as + that third party. This can be challenging, and the appropriate + mechanism depends on the specific application scenario. + + In one common scenario, the controller is acting on behalf of one of + the participants in the call. A typical example is click-to-dial, + where the controller and the customer service representative are run + by the same administrative domain. Indeed, for the purposes of + identification, the controller can legitimately claim to be the + customer service representative. In this scenario, it would be + appropriate for the INVITE to the end user to contain a From field + identifying the customer service rep, and authenticate the request + using S/MIME (see RFC 3261 [1], Section 23) signed by the key of the + customer service rep (which is held by the controller). + + This requires the controller to actually have credentials with which + it can authenticate itself as the customer support representative. + In many other cases, the controller is representing one of the + participants, but does not possess their credentials. Unfortunately, + there are currently no standardized mechanisms that allow a user to + delegate credentials to the controller in a way that limits their + usage to specific third party call control operations. In the + absence of such a mechanisms, the best that can be done is to use the + display name in the From field to indicate the identity of the user + on whose behalf the call is being made. It is RECOMMENDED that the + display name be set to "[controller] on behalf of [user]", where user + and controller are textual identities of the user and controller, + respectively. In this case, the URI in the From field would identify + the controller. + + In other situations, there is no real relationship between the + controller and the participants in the call. In these situations, + ideally the controller would have a means to assert that the call is + from a particular identity (which could be one of the participants, + or even a third party, depending on the application), and to validate + that assertion with a signature using the key of the controller. + +12.2. End-to-End Encryption and Integrity + + With third party call control, the controller is actually one of the + participants as far as the SIP dialog is concerned. Therefore, + encryption and integrity of the SIP messages, as provided by S/MIME, + will occur between participants and the controller, rather than + directly between participants. + + However, integrity, authenticity and confidentiality of the media + sessions can be provided through a controller. End-to-end media + security is based on the exchange of keying material within SDP [10]. + + + +Rosenberg, et al. Best Current Practice [Page 27] + +RFC 3725 SIP 3pcc April 2004 + + + The proper operation of these mechanisms with third party call + control depends on the controller behaving properly. So long as it + is not attempting to explicitly disable these mechanisms, the + protocols will properly operate between the participants, resulting + in a secure media session that even the controller cannot eavesdrop + or modify. Since third party call control is based on a model of + trust between the users and the controller, it is reasonable to + assume it is operating in a well-behaved manner. However, there is + no cryptographic means that can prevent the controller from + interfering with the initial exchanges of keying materials. As a + result, it is trivially possibly for the controller to insert itself + as an intermediary on the media exchange, if it should so desire. + +13. Acknowledgements + + The authors would like to thank Paul Kyzivat, Rohan Mahy, Eric + Rescorla, Allison Mankin and Sriram Parameswar for their comments. + +14. References + +14.1. Normative References + + [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., + Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: + Session Initiation Protocol", RFC 3261, June 2002. + + [2] Camarillo, G., Ed., Marshall, W., Ed. and J. Rosenberg, + "Integration of Resource Management and Session Initiation + Protocol (SIP)", RFC 3312, October 2002. + + [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with + Session Description Protocol (SDP)", RFC 3264, June 2002. + + [5] Schulzrinne, H., Oran, D. and G. Camarillo, "The Reason Header + Field for the Session Initiation Protocol (SIP)", RFC 3326, + December 2002. + + [6] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional + Responses in Session Initiation Protocol (SIP)", RFC 3262, June + 2002. + + [7] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE + Method", RFC 3311, October 2002. + + + + + +Rosenberg, et al. Best Current Practice [Page 28] + +RFC 3725 SIP 3pcc April 2004 + + +14.2. Informative References + + [8] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, + "RTP: A Transport Protocol for Real-Time Applications", RFC + 3550, July 2003. + + [9] Petrack, S. and L. Conroy, "The PINT Service Protocol: + Extensions to SIP and SDP for IP Access to Telephone Call + Services", RFC 2848, June 2000. + + [10] Andreasen, F., Baugher, M. and D. Wing, "SDP Security + Descriptions for Media Streams", Work in Progress, October 2003. + + [11] Lennox, J., Wu, X. and H. Schulzrinne, "CPL: A Language for User + Control of Internet Telephony Services", Work in Progress, + August 2003. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Rosenberg, et al. Best Current Practice [Page 29] + +RFC 3725 SIP 3pcc April 2004 + + +15. Authors' Addresses + + Jonathan Rosenberg + dynamicsoft + 600 Lanidex Plaza + Parsippany, NJ 07054 + US + + Phone: +1 973 952-5000 + EMail: jdrosen@dynamicsoft.com + URI: http://www.jdrosen.net + + + Jon Peterson + Neustar + 1800 Sutter Street + Suite 570 + Concord, CA 94520 + US + + Phone: +1 925 363-8720 + EMail: jon.peterson@neustar.biz + URI: http://www.neustar.biz + + + Henning Schulzrinne + Columbia University + M/S 0401 + 1214 Amsterdam Ave. + New York, NY 10027 + US + + EMail: schulzrinne@cs.columbia.edu + URI: http://www.cs.columbia.edu/~hgs + + + Gonzalo Camarillo + Ericsson + Hirsalantie 11 + Jorvas 02420 + Finland + + EMail: Gonzalo.Camarillo@ericsson.com + + + + + + + + +Rosenberg, et al. Best Current Practice [Page 30] + +RFC 3725 SIP 3pcc April 2004 + + +16. Full Copyright Statement + + Copyright (C) The Internet Society (2004). This document is subject + to the rights, licenses and restrictions contained in BCP 78 and + except as set forth therein, the authors retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE + REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE + INTERNET ENGINEERING TASK FORCE DISCLAIM 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. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed + to pertain to the implementation or use of the technology + described in this document or the extent to which any license + under such rights might or might not be available; nor does it + represent that it has made any independent effort to identify any + such rights. Information on the procedures with respect to + rights in RFC documents can be found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use + of such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository + at http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention + any copyrights, patents or patent applications, or other + proprietary rights that may cover technology that may be required + to implement this standard. Please address the information to the + IETF at ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + +Rosenberg, et al. Best Current Practice [Page 31] + -- cgit v1.2.3