Speermint D. Hancock Internet-Draft D. Malas Intended status: Informational CableLabs Expires: April 29, 2010 October 26, 2009 draft-hancock-sip-interconnect-guidelines-02 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 29, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Hancock & Malas Expires April 29, 2010 [Page 1] Internet-Draft SIP Interconnect Guidelines October 2009 Abstract As Session Initiation Protocol (SIP) peering becomes more widely accepted by service providers the need to define an interconnect guideline becomes of greater value. This document takes into consideration the SIP and commonly used SIP extensions, and it defines a fundamental set of requirements for SIP Service Providers (SSPs) to implement within their signaling functions (SFs) or Signaling Path Border Elements (SBEs) for peering. Hancock & Malas Expires April 29, 2010 [Page 2] Internet-Draft SIP Interconnect Guidelines October 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 7 3. Reference Architecture . . . . . . . . . . . . . . . . . . . . 8 4. General Procedures . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Extension Negotiation . . . . . . . . . . . . . . . . . . 10 4.2. Public User Identities . . . . . . . . . . . . . . . . . . 10 4.2.1. Identifying the Called User . . . . . . . . . . . . . 10 4.2.2. Identifying the Calling User . . . . . . . . . . . . . 11 4.3. Trust Domain and Asserted Identities . . . . . . . . . . . 11 4.4. IPv4/6 Interworking . . . . . . . . . . . . . . . . . . . 11 4.5. Fault Isolation and Recovery . . . . . . . . . . . . . . . 11 4.5.1. Interface Failure Detection . . . . . . . . . . . . . 11 4.5.2. Overload Control . . . . . . . . . . . . . . . . . . . 12 4.5.3. Session Timer . . . . . . . . . . . . . . . . . . . . 12 5. Call Features . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1. Session Establishment . . . . . . . . . . . . . . . . . . 13 5.1.1. SDP Requirements . . . . . . . . . . . . . . . . . . . 13 5.1.2. Basic Call Setup . . . . . . . . . . . . . . . . . . . 13 5.1.3. Ringback Tone vs. Early Media . . . . . . . . . . . . 14 5.1.4. Early-Media with Multiple Terminating Endpoints . . . 15 5.1.5. Establishing calls using 3PCC . . . . . . . . . . . . 16 5.1.6. Hold . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.2. Calling Name and Number Deliver (with Privacy) . . . . . . 17 5.3. Call Forwarding . . . . . . . . . . . . . . . . . . . . . 17 5.3.1. Detecting Call Forwarding Loops . . . . . . . . . . . 18 5.4. Call Transfer . . . . . . . . . . . . . . . . . . . . . . 19 5.4.1. Call-Transfer Using REFER/Replaces . . . . . . . . . . 19 5.4.2. Call-Transfer Using 3PCC . . . . . . . . . . . . . . . 20 5.5. 3-way Conference . . . . . . . . . . . . . . . . . . . . . 20 5.6. Auto Recall/Callback . . . . . . . . . . . . . . . . . . . 21 5.6.1. Originating SBE Sends INVITE to Target . . . . . . . . 21 5.6.2. Originating SBE Sends SUBSCRIBE to Target . . . . . . 21 5.6.3. Target Sends NOTIFY to Originating SBE . . . . . . . . 22 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 9. Normative References . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 Hancock & Malas Expires April 29, 2010 [Page 3] Internet-Draft SIP Interconnect Guidelines October 2009 1. Introduction In the SIP Service Provider (SSP) industry every SSP has their own SIP requirements. Whether they defined it themselves or a vendor's equipment capabilities defined it for them, they have one. When two SSPs approach one another to establish a peering relationship, one of the first pieces of information they exchange is their respective SIP requirements or profiles. (For the purposes of this draft, we will call it a SIP profile.) After exchanging SIP profiles, each SSP will likely go back to their lab and spend an extended period of time attempting to comply with the other SSP's SIP profile, either by requesting their vendor to implement or change capabilities, by developing "interworking profiles" for manipulating SIP messages at their SF or SBE, or by arguing defiantly that their approach is correct. While this may seem like a simple and manageable task when establishing a single peering relationsip, it can become extremely burdensome as the number of peering relationships increase to four, five, and beyond. The overwhelming sentiment is that there is a need to establish a minimum set of requirements an SSP can implement within their SF or SBE to peer with any other SSP. While this may seem like an arduous task, there is a belief that a fundamental set of requirements could be established as a baseline guideline to establish peering with any SSP. After the peering is established, the two SSPs may agree on additional SIP parameters or extensions that expand the capabilities for many different purposes. Over time, this document may be extended or updated as necessary to maintain consistency with the widely adopted new use of SIP functionality in the industry. This document provides an interconnect guideline to address potential SIP interworking issues for peering SIP-based networks. 1.1. Scope This document describes the SIP interconnect procedures between two SIP-based networks for both peering SIP Service Providers networks and peering Enterprise networks. The document focuses on the interworking procedures required to support basic telephone service, including the following capabilities: o On-net to on-net calls o Multi-media Hancock & Malas Expires April 29, 2010 [Page 4] Internet-Draft SIP Interconnect Guidelines October 2009 * Voice * Video * Real-time text o Caller ID with Privacy o Early media o Local Number Portability o Call hold/conf/xfer o Call forwarding o Auto Recall/Callback o Problem Isolation - Inter-network keep-alives Interworking procedures in support of the following capabilities are not addressed: o Calls to/from PSTN o Operator calls o 0+,0-, busy-line-verify o Emergency calls o Transmission loss plan o Operational capabilities o Accounting o Electronic Surveillance o Quality-of-Service o Authentication and Security o Voice, FAX, DTMF-relay o RTCP VoIP Metrics Hancock & Malas Expires April 29, 2010 [Page 5] Internet-Draft SIP Interconnect Guidelines October 2009 o SIP RTP Loopback Hancock & Malas Expires April 29, 2010 [Page 6] Internet-Draft SIP Interconnect Guidelines October 2009 2. Terminology 2.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. This draft also uses terms defined in [RFC5486]. Hancock & Malas Expires April 29, 2010 [Page 7] Internet-Draft SIP Interconnect Guidelines October 2009 3. Reference Architecture Figure 1 shows the peering relationship between two SSPs; SSP-A and SSP-B. The Signaling Path Border Element (SBE) serves as the egress/ ingress point for SIP signaling into each peers network. The SBE may act as a proxy or a Back-to-Back User Agent (B2BUA). The optional Data Path Border Element (DBE) serves as a media relay at the peering interface for media interworking, topology hiding and IPv4/6 interworking. +------+ | DNS, | +---------->| Db, |<---------+ | | etc | | | +------+ | | | ------|-------- -------|------- / v \ / v \ | +--LUF-+ | | +--LUF-+ | | | | | | | | | | | | | | | | | | | | | | | | | | +------+ | | +------+ | | | | | | +--LRF-+ | | +--LRF-+ | | | | | | | | | | | | | | | | | | | | | | | | | | +------+ | | +------+ | | | | | | | | | | +---SF--+ +---SF--+ | | | | | | | | | SBE | | SBE | | | Originating | | | | Target | | +---SF--+ +---SF--+ | | SSP | | SSP | | +---MF--+ +---MF--+ | | | | | | | | | DBE | | DBE | | | | | | | | | +---MF--+ +---MF--+ | \ / \ / --------------- --------------- Hancock & Malas Expires April 29, 2010 [Page 8] Internet-Draft SIP Interconnect Guidelines October 2009 Figure 1: Peering Architecture This document places requirements on the following two entities in the Peering architecture: o the SBE in support of the SIP/SDP interface between two peering networks o the DBE in support of the RTP/RTCP interface between peering networks Based on the definition of the SBE in the peering architecure document [I-D.ietf-speermint-architecture], it's not entirely correct to make the SBE responsible for meeting all the SIP signaling requirements at the peering interface. For example, the SBE can play the role of a firewall or a SIP proxy that is largely transparent to the SIP messages crossing the interface. In reality, the responsiblity for supporting this interface belongs to all the SIP entities in the SIP signaling chain, including the SBE plus the SIP proxies and UAs inside the network. Furthermore, when this network is serving as a transit network, the SIP signaling chain can extend into another network. To resolve this issue, this document extends the definition of the SBE slightly so that when it is specified as the target entity of a normative requirement on the SIP/SDP peering interface, the SBE represents all the SIP entities in the SIP signaling chain that can effect the SIP/SDP peering interface. Likewise, the DBE can act as a media relay (performing no media encode/decode) that is transparent to the RTP/RTCP packets exchanged with the peer network. Therefore, this document extends the definition of the DBE so that when it is specified as the target entity of a normative requirement on the RTP/RTCP interface, it represents the media endpoint in the peering network that terminates the RTP/RTCP stream. Hancock & Malas Expires April 29, 2010 [Page 9] Internet-Draft SIP Interconnect Guidelines October 2009 4. General Procedures 4.1. Extension Negotiation It is RECOMMENDED that originating SBEs facing other peer networks be configured in such a way that they do not require any SIP extensions to be supported by the other end. The SBE MUST identify all supported SIP extensions in the Supported header. The SBE MAY support configuration controls to disable certain extensions based on bilateral agreement between peer networks. For example, the SBE could be configured to remove '100rel' from the Supported header in order to disable the use of reliable provisionable response (PRACK). When sending a dialog-initialing request to a peer network, the SBE MUST identify all supported SIP requests in the Allow header field. 4.2. Public User Identities Users are identified at the peering interface by their Public User Identity. An SBE MUST encode Public User Identities as a SIP URI of the telephone-subscriber syntax form of a Tel URI as indicated by the "user=phone" parameter (see Section 19.1.6 of [RFC3261]), where the user part of the SIP URI contains a global Tel URI as defined in [RFC3966]. Example: sip:+13035551212@examplessp.com;user=phone 4.2.1. Identifying the Called User When sending a dialog-initiating request to a peer network, the SBE MUST : o identify the called user in the Request-URI of the request, using the telephone-subscriber syntax form of the SIP URI as described above in section 4.2; and o if Local Number Portability (LNP) information for the called number was obtained, then * include the LNP data in SIP URI in the Request-URI using the Tel URI "npdi" and "rn" parameters as defined in [RFC4694], and * if the called number is ported, then identify the routing number using the global form of the "rn" parameter, which is indicated by a leading "+" character followed by the country- code followed by the national number (e.g., "rn=+16132220000"). Hancock & Malas Expires April 29, 2010 [Page 10] Internet-Draft SIP Interconnect Guidelines October 2009 On receiving a dialog-initiating request from a peer network, the SBE MUST: o identify the called user based on the contents in the Request-URI, where the Request URI contains a SIP URI as described above in section 4.2, and o obtain the LNP data for the called number based on the presence and contents of the "npdi" and "rn" parameters contained in the SIP URI of the Request-URI as defined in [RFC4694]. 4.2.2. Identifying the Calling User When sending or receiving a dialog-initiating request, the SBE MUST: o identify the calling user in the P-Asserted-Identity header using the telephone-subscriber syntax form of the SIP URI as described above in section 4.2; and o if calling name display is supported, then include the calling name display information in the P-Asserted-Identity header as described in section 5.2. 4.3. Trust Domain and Asserted Identities In a peering relationship, both originating and terminating networks are in the same trust domain. Therefore, per [RFC3325], the terminating network MUST trust an originating peer network to populate the P-Asserted-Identity header in an incoming INVITE request with the Public User Identity of the originating user. Furthermore, the originating network MUST trust the terminating network to honor the privacy wishes of the originator as indicated in the Privacy header. 4.4. IPv4/6 Interworking It is the responsibility of the IPv6 network to perform the IPv4/IPv6 interworking function when interworking with an IPv4 network. 4.5. Fault Isolation and Recovery 4.5.1. Interface Failure Detection An SBE MAY periodically send an OPTIONS request with Max-forwards set to '0' to detect the availability of a peer's ingress point. The ping rate is based on bi-lateral agreement (typically every 5 seconds). If the sending SBE fails to receive a response to an OPTIONS request, then it will consider that non-responding ingress Hancock & Malas Expires April 29, 2010 [Page 11] Internet-Draft SIP Interconnect Guidelines October 2009 point into the peer network to have failed, and will refrain from routing new requests to it. In the meantime, it will continue to send periodic OPTIONS pings to the failed ingress point in order to detect when it has been restored and is available for service. Note: A possible enhancement to the OPTIONS ping is to declare a well-known SIP URI in the look-up function (LUF) that could be used to test the health of each ingress SF or SBE in a peer network. For example, SIP INVITE (with no SDP) to sip:999999999@examplessp.com would respond with a 200 OK (again no SDP), followed by a BYE/200 OK. 4.5.2. Overload Control SIP does not currently provide an explicit overload control mechanism. However, an SSP may want to impose limits on the number of simultaneous calls, and the incoming call rate it will accept from a peer SSP. On receiving a dialog-initiating request that exceeds such limits, the receiving SBE MUST respond with a 503 (Service Unavailable) response. An SBE receiving a dialog-initiating request from a peer MUST limit the use of the 503 (Service Unavailable) response to reporting overload at the ingress signaling point, and MUST NOT use this response to report overload or other failures internal to the network. On receiving a 503 (Service Unavailable) response from a peer network, the receiving SBE MUST limit the scope of the response to the call on which it was received (i.e., a 503 response has no affect on the routing of subsequent calls to the peer). Also, the receiving SBE MUST attempt to consume the 503 (Service Unavailable) response from a peer as close to the egress signaling point as possible, and avoid propagating the response back toward the source of the request. Specifically, on receiving a 503 (Service Unavailable) response to a dialog-initiating request that was sent to a peer network, the SBE MUST: o terminate the current transaction, o ignore the Retry-After header if one is present, and o attempt to route the call via an alternate peering interface (i.e. do not attempt to route the call via the same peering interface since it may encouter and aggravate the same overload condition). 4.5.3. Session Timer The SBE SHOULD support Session Timer as defined in [RFC4028]. Hancock & Malas Expires April 29, 2010 [Page 12] Internet-Draft SIP Interconnect Guidelines October 2009 5. Call Features 5.1. Session Establishment 5.1.1. SDP Requirements The SBE MUST support the SDP requirements defined in [RFC4566]. The SBE MUST include only one media (m=) descriptor per desired media stream in an SDP offer to a peer network. If an SBE receives an SDP offer containing multiple media descriptors, it MUST act on the media descriptors and include all of them in the same order in the response, including non-zero ports and zero ports for the offered media according to its capabilities as specified in [RFC3264] An Offer/Answer Model with SDP. The SBE MUST NOT reject an offered session because it offers more media than the SBE can handle. 5.1.2. Basic Call Setup This section describes the procedures at the peering interface required to establish a 2-way session for a basic voice call between two users. In this case it is assumed that no originating or terminating features are applied (no call blocking, forwarding, etc.), and that the called line is available to accept the call. Also, this section describes the session establishment procedures when tha call is initiated by the originating SIP User Agent itself, and not via a 3rd party in support of features like click-to-call. Two-way call establishment using 3PCC is covered in section Section 5.1.5. The SBE MUST support the SDP offer/answer procedures specified in [RFC3264]. The originating SBE MUST include an SDP offer in the initial INVITE. The terminating SBE MUST include an SDP answer in the first reliable response to INVITE (typically the final 200 (OK) response to the INVITE). The terminating SBE MAY also include an SDP body in a non-reliable provisional 18x response to the INVITE. The SDP contained in a non-reliable 18x provisional response can be considered a "preview" of the actual SDP answer to be sent in the 200 (OK) to INVITE. The originating SBE can act on this "preview" SDP to establish an early media session, as described in section Section 5.1.3. The terminating SBE MUST ensure that the "preview" SDP matches the actual SDP answer contained in the 200 (OK) response to INVITE. Note: an SDP offer/answer exchange occurs within the context of a single dialog. Therefore, the requirement for matching SDPs in the provisional and final responses to INVITE applies only when the Hancock & Malas Expires April 29, 2010 [Page 13] Internet-Draft SIP Interconnect Guidelines October 2009 provisional and final response are in the same dialog. If the provisional and final response are on different dialogs (say, when the INVITE is forked), the requirement for matching SDPs does not apply. The SBE MUST always set the SDP mode attribute in the initial offer/ answer to "a=sendrecv". Note: Setting the mode to "a=sendrecv" on the initial SDP offer/ answer exchange avoids an additional SDP offer/answer exchange to update the mode to send-receive after the call is answered. This should help mitigate the problem of voice-clipping on answer. A peered originating and terminating SBE that advertise support for different but overlapping sets of codecs in the SDP offer/answer exchange for a given call MUST negotiate a common codec for the call. 5.1.3. Ringback Tone vs. Early Media During the call setup phase, while the originating network is waiting for the terminating network to answer the call, the originating line is either playing local ringback tone to the calling user or connected to a receive-only or bi-directional early-media session with the terminating network. For example, early media can be supplied by the terminating endpoint (e.g., custom ringback tone) while waiting for answer. During session establishment, an SBE MUST use the following procedures to control whether the originating line applies local ringback tone or establishes an early media session while waiting for the call to be answered: o The terminaing SBE MUST send the following provisional response to a call-initiating INVITE: * a 180 (Alerting) response containing no SDP if the call scenario requires the originating network to apply local ringback tone, * a 183 (Progressing) response containing SDP that describes the terminating media endpoint if the call scenario requires the originating network to establish an early-media session with the terminating media endpoint, * the provisional response sent for other call scenarios is not specified, as long as the response is not one of those specified above. Hancock & Malas Expires April 29, 2010 [Page 14] Internet-Draft SIP Interconnect Guidelines October 2009 o The originating SBE MUST perform the following action on receipt of a provisional response to a call-initiating INVITE: * on receiving a 180 (Alerting) response containing no SDP, apply local ringback tone, * on receiving a 180 (Alerting) or 183 (Progressing) response containing SDP, establish an early media session with the media endpoint described by the SDP, * on receiving any other provisional response (with or without SDP) do nothing (e.g., continue to apply local ringback tone if it was already being applied when response was received) 5.1.4. Early-Media with Multiple Terminating Endpoints There are some call scenarios that require media sessions to be established (serially) between the originating user agent and one or more intermediate media endpoints before the call is connected to the final target called user agent. For example, the terminating network can insert a media server in the call to interact with the calling user in some way (e.g., to collect a blocking-override PIN) before offering the call to the called user. Another case occurs when the called user fails to answer within an allotted time and the call is redirected to voice-mail, or forwarded to another user via Call Forwarding Don't Answer (CFDA). These different cases can be combined in the same call. For each terminating media endpoint that is associated with a call before the call is answered, the terminating network must decide whether to establish an early media session or apply ringback tone at the originating user agent. For example, consider the case where the called user has call blocking with PIN override, and CFDA. First, an early-media session is established with the call-blocking server to collect the PIN, next the originating user agent is instructed to play local ring-back tone while waiting for the called user to answer, and finally an early media session is established with the forward-to party to play custom ringback tone. [RFC3261] mandates that the SDP included unreliable provisional 18x responses to INVITE within the context of a dialog must match the SDP-answer included in the final 200 (OK) response to INVITE. The following sections describe two different mechanisms for supporting multiple terminating media endpoints before answer, within the confines of this requirement. Hancock & Malas Expires April 29, 2010 [Page 15] Internet-Draft SIP Interconnect Guidelines October 2009 5.1.4.1. Forking the INVITE For each terminating media endpoint that requires an early media session to be established with the originating media endpoint, the terminating SBE MUST signal the attributes of the terminating media endpoint to the originating SBE within the SDP of a 183 (Progressing) response. The terminating SBE MUST ensure that 18x responses containing different SDP copies are not sent within the same dialog. The terminating SBE does this by specifying a different To: tag for each provisional response that contains a unique SDP, as if the INVITE had been sequentially forked. The originating SBE MUST honor the most recently received 18x response to INVITE, based on the procedures defined in section 5.1.2.2. 5.1.4.2. Redirecting the INVITE As an alternative to sequentially forking the INVITE, the terminating entity can redirect the originating entity to the next endpoint in the series by sending a 302 (Moved Temporarily) response containing a Contact header field that identifies the next endpoint. The resulting INVITE from the originating SBE is sent as a dialog- initiating request, and can therefore establish a new early-media session with the next endpoint in the series. The use of this procedure is based on bilateral agreement between peering operators. On receiving a 302 (Moved Temporarily) response to an INVITE request, and if this mechanism is enabled based on local policy, the originating SBE MUST send a new dialog-initiating INVITE with a Request-URI set to the value returned in the Contact header field of the 302 (Moved Temporarily) response, as described in [RFC3261]. 5.1.5. Establishing calls using 3PCC Section Section 5.1.2 describes the procedures that are used to establish basic two-way call when the call is initiated directly by the originating user's endpoint. However, an SSP may support features such as click-to-call, where the call is initiated by a 3rd party such as an Applicaion Server on bahalf of the originating user. To support such features, the SBE MUST support the 3PCC procedures described in [RFC3725]. 5.1.6. Hold An SBE that wishes to place a media stream "on hold" MUST offer an updated SDP to its peer network with an attribute of "a=inactive" or "a=sendonly" in the media description block. An SBE that wishes to Hancock & Malas Expires April 29, 2010 [Page 16] Internet-Draft SIP Interconnect Guidelines October 2009 place a media stream "on hold" MUST NOT set the connection information of the SDP to a null IP address (for example, it MUST NOT set the 'c=' connection line to c=IN IP4 0.0.0.0). An SBE that wants to place a media stream "on hold" SHOULD locally mute the media stream. An SBE that receives an SDP offer with an attribute of "a=inactive" in the media block MUST place the media stream "on hold", and MUST answer with an updated SDP containing a media attribute of "a=inactive". An SBE that receives an SDP offer with an attribute of "a=inactive" in the media block MUST NOT set the connection data of the answer SDP to c=0.0.0.0. An SBE operating in IPv4 that receives an SDP offer with no directionality attributes but connection data set to c=IN IP4 0.0.0.0 SHOULD place the media stream "on hold". 5.2. Calling Name and Number Deliver (with Privacy) An originating SBE MUST provide the calling name and number of the originating user in the P-Asserted-Identity header of dialog- initiating requests. (The mechanism for obtaining the calling name is out-of-scope of this document.) The calling number is contained in the telephone-subscriber syntax form of the SIP URI, containing an E.164 number as described in section 4.2. The calling name is contained in the display-name component of the P-Asserted-Identity header. If the originating user wants to remain anonymous, the originating SBE MUST include a Privacy header containing the value "id" as specified in [RFC3323] and [RFC3325]. In addition, the originating SBE SHOULD obscure the identity of the originating user in other headers as follows: o Set the identity information in the 'From' header to "Anonymous sip:anonymous@anonymous.invalid", o Set the display-name in the To header to "Anonymous" (since the To display-name selected by the originating user could provide a hint to the originating user's identity). o Obscure any information from the Call-ID and Contact headers, such as the originating FQDN, that could provide a hint to the originating user's identity. 5.3. Call Forwarding If an SSP offers call-forwarding services to its users, then the forwarding SBE MAY remain in the signaling path of the forwarded call in order to support separate billing of forward-from and forward-to Hancock & Malas Expires April 29, 2010 [Page 17] Internet-Draft SIP Interconnect Guidelines October 2009 legs. This is accomplished by o remaining in the signaling path as a proxy or B2BUA, or o by responding to the initial INVITE with a 302 (Moved Temporarily) response with a Contact header containing a private URI that points back to the forwarding network MUST support the History-Info header as defined in [RFC4244] to detect call-forwarding loops. 5.3.1. Detecting Call Forwarding Loops A call forwarding loop is defined to be the scenario that occurs when a targeted subscriber for a call forwards the call to another destination. If the forwarded-to destination also has call forwarding configured, the call can forward back (directly or indirectly) to the original targeted subscriber. When a loop is detected, the network that performs the detection rejects the call. An SBE MUST detect call forwarding loops. An SBE MUST support a configurable limit on the number of times an individual call may be subject to forwarding. If the number of forwarding attempts for a single call exceeds this limit, the SBE MUST reject the call. An SBE SHOULD detect call forwarding loops and limit the number times a call is forwarded by supporting the History-Info header field as defined in [RFC4244], and by analysing the History-Info entries as described in this section. However, these mechanisms alone may not be sufficient to detect loops when calls are forwarded to networks not supporting these mechanisms. Therefore an SBE MAY support additional loop prevention and forwarding limit detection methods as long as the requirements of forwarding limit restriction and loop detection are met. If the SBE supports the prevention of forwarding loops via analysis of the History-Info header present in the INVITE then it MUST compare the forward-to address with the set of targeted-to URI (hi-targeted- to-uri) entries from the History-Info header. If there is a match then a loop has occurred. If no History-Info header is present then it is not possible to perform loop detection via this mechanism. If an SBE supports the prevention of forwarding loops by enforcing a maximum number of forwarding attempts, then it MUST calculate the number of forwarding attempts by counting the number of entries in the History-Info header that were added due to call forwarding (i.e., entries containing a nested Reason header which includes a protocol- cause parameter and a reason-text parameter that indicate the call was forwarded as defined below). If no History-Info header is Hancock & Malas Expires April 29, 2010 [Page 18] Internet-Draft SIP Interconnect Guidelines October 2009 present then it is not possible to determine the number of forwarding attempts via this mechanism. [RFC4458] defines the mapping between the forwarding conditions and the coding of the protocol-cause parameter in the Reason header. An SBE MUST populate the Reason header with a protocol-cause value of "486" and a reason-text value of "CFBL" when the forwarding condition is Call Forwarding Busy Line (CFBL). The SBE MUST populate the Reason header with a protocol-cause value of "408" and a reason-text value of "CFDA" when the forwarding condition is Call Forwarding Don't Answer (CFDA). The SBE MUST populate the Reason header with a protocol-cause value of "302" and a reason-text value of "CFV/SCF" when the forwarding ondition is Caff Forwarding Valriable (CFV) or Selective Call Forwarding (SCF). 5.4. Call Transfer A user in a peered call can perform the various forms of call- transfer (consultive transfer, blind transfer). Call-transfer can be supported in one of two ways; either using the REFER request [RFC3515] and Replaces header [RFC3891], or by manipulating the call legs using 3rd Party Call Control (3PCC) techniques. SBEs that support call transfer MUST support the 3PCC option, and MAY support the REFER/Replaces option. If a network supports both options, then the option that is used when interworking with a specific peer is based on locally configured data that indicates the capabilities of that peer. 5.4.1. Call-Transfer Using REFER/Replaces SBEs that support call-transfer using the procedures described in this section MUST support the SIP REFER extension described in [RFC3515], and the SIP Replaces extension described in [RFC3891]. Furthermore, [RFC3515] requires support of the SIP Event Notification extension described in [RFC3265]. To describe the basic transfer call-flow, consider the case where user-A in SSP-A is in an active call with user-B in peered sSSP-B, and user-A decides to transfer user-B to user-C. User-C could be located anywhere in the global network; for example in SSP-A, SSP-B, another peered network, a non-peering IP network, or the PSTN. Here are the basic steps to complete the transfer using REFER/Replaces: o User-A puts user-B on hold (sends re-INVITE with SDP "a=inactive" as described in 5.1.1.1) o User-A initiates a basic 2-way call to user-C Hancock & Malas Expires April 29, 2010 [Page 19] Internet-Draft SIP Interconnect Guidelines October 2009 o User-A sends an in-dialog REFER to user-B containing a Refer-To header. The Refer-To header instructs user-B to send an INVITE to user-C with an imbedded Replaces header identifying the A-to-C dialog. * If SSP-A is not required to remain in the signaling path of the transferred call, then it identifies user-C directly in the Refer-To header, * If SSP-A is required to remain in the signaling path of the transferred call (say to generate events for proper billing of the call), then it identifies a private URL pointing to itself in the Refer-To header. The private URL contains a "hostport" that identifies SSP-A, and contains a "userinfo" string that is generated by SSP-A. This "userinfo" string either contains or points to information required by SSP-A to establish the transfer-to leg of the call. o User-B sends an INVITE containing the Replaces header specified in step-3 to the address contained in the Refer-To header (i.e., the INVITE is routed to user-C either directly from ssp-B, or indirectly via SSP-A using the private URL) o User-B sends Notify requests within the original A-to-B dialog, informing user-A of the progress of the B-to-C call o At some point user-A drops out of both dialogs (e.g., drops out of A-to-C dialog on receiving BYE from user-C). At this point users B and C are active in a 2-way call. SBEs SHOULD support receiving a GRUU [I-D.ietf-sip-gruu] in the Refer-To header. 5.4.2. Call-Transfer Using 3PCC SBEs that support call-transfer using 3PCC techniques MUST act as a B2BUA, and manipulate the call legs using INVITE and re-INVITE requests. It is RECOMMENDED that such techniques follow the guidance presented in [RFC3725]. 5.5. 3-way Conference The media mixing for 3-way conference calls may be performed by the user agent of the conference control party, or by a conference bridge application server in the peer network serving the conference control party. When mixing is done by the user agent, there are no specific requirements placed on the peering interface other than the support of hold as described in section 5.1.1.1. When conference mixing is Hancock & Malas Expires April 29, 2010 [Page 20] Internet-Draft SIP Interconnect Guidelines October 2009 performed by a network-based server, users are added to the conference using procedures similar to those described for call transfer in section 5.4. 5.6. Auto Recall/Callback When a user invokes AC or AR, and the user targeted by the recall/ callback feature belongs to a peer network, the originating SBE first attempts to establish a basic 2-way call with the target user. If the call completes normally (e.g., the target user answers) then the feature is complete. If the terminating SBE responds with an indication that the target user is busy, then the originating SBE subscribes to the dialog-event package as defined in [RFC4235] of the target user, as a mechanism to detect when the target user becomes available. When the terminating SBE subsequently notifies the originating SBE that the target user is available, the originating SBE re-attempts to establish a 2-way call to the target user. 5.6.1. Originating SBE Sends INVITE to Target When a user invokes an AR or AC call, the originating SBE MUST follow the procedures given for a basic call as described in Section 5.1.2, and attempt to establish a 2-way call with the target user. In addition, the originating SBE MUST add a Call-Info header field to the INVITE with a purpose of "answer_if_not_busy". If the originating SBE receives a 200-OK response to INVITE, then the AC/AR feature is considered complete, and the remainder of the call is handled like a normal 2-way call. If the originating SBE receives a 486-Busy-Here or 600-Busy-Everywhere response to the INVITE, then it MUST follow the AC/AR procedures as defined below. If the terminating SBE receives an inbound INVITE with a Call-Info header field declaring purpose= answer_if_not_busy, then the terminating SBE MUST ignore any active Call-Forwarding-Busy-Line (CFBL) service for the target user, not forward the call if the target is busy, and instead handle the call as if CFBL was not active (e.g., offer the call using the call-waiting feature). 5.6.2. Originating SBE Sends SUBSCRIBE to Target On receiving a 486-Busy-Here or 600-Busy-Everywhere response to an AC/AR INVITE request, the originating SBE MUST establish a subscription to the dialog event package of the target endpoint, by sending a SUBSCRIBE request containing an Event header field set to "dialog" to the terminating SBE. The originating SBE MUST populate the SUBSCRIBE Request-URI with the URI returned in the Contact header field of the INVITE response, if that URI is a GRUU. Otherwise, the originating SBE MUST populate the Request-URI with the identity of Hancock & Malas Expires April 29, 2010 [Page 21] Internet-Draft SIP Interconnect Guidelines October 2009 the target callback/recall user. 5.6.3. Target Sends NOTIFY to Originating SBE On receiving the SUBSCRIBE to the dialog event package, the terminating SBE MUST notify the originating SBE of the dialog state of the target user endpoint as described in [RFC4235]. Upon receiving a NOTIFY message of "target is idle", the originating SBE MUST first cancel the dialog-event subscription by sending a SUBSCRIBE message with an Expires header containing the value "0". Once the subscription is cancelled, the originating SBE MUST send a new INVITE request to establish a call with the target user. If the originating SBE receives a 486-Busy-Here or 600-Busy-Everywhere response to the INVITE, then it MUST automatically re-subscribe to the dialog event package of the target user. (Note, a "busy" response could be returned in this case as a result of a race condition, where the target endpoint sends a NOTIFY of "target is idle", and then becomes busy in a new call before the subsequent INVITE is received). Hancock & Malas Expires April 29, 2010 [Page 22] Internet-Draft SIP Interconnect Guidelines October 2009 6. Security Considerations This draft contains no new security considerations that have not already been defined in SIP and the specified SIP extensions in this draft. Hancock & Malas Expires April 29, 2010 [Page 23] Internet-Draft SIP Interconnect Guidelines October 2009 7. Acknowledgements The authors of this draft wish to thank Tom Creighton, Jack Burton, Matt Cannon, Robert Diande, Jean-Francois Mule, and Kevin Johns for their contributions to this draft. Hancock & Malas Expires April 29, 2010 [Page 24] Internet-Draft SIP Interconnect Guidelines October 2009 8. IANA Considerations This draft contains no IANA considerations. Hancock & Malas Expires April 29, 2010 [Page 25] Internet-Draft SIP Interconnect Guidelines October 2009 9. Normative References [I-D.ietf-sip-gruu] Rosenberg, J., "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", draft-ietf-sip-gruu-15 (work in progress), October 2007. [I-D.ietf-speermint-architecture] Penno, R. and S. Khan, "SPEERMINT Peering Architecture", draft-ietf-speermint-architecture-08 (work in progress), March 2009. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3261] 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. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002. [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002. [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003. [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004. [RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, September 2004. Hancock & Malas Expires April 29, 2010 [Page 26] Internet-Draft SIP Interconnect Guidelines October 2009 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004. [RFC4028] Donovan, S. and J. Rosenberg, "Session Timers in the Session Initiation Protocol (SIP)", RFC 4028, April 2005. [RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", RFC 4235, November 2005. [RFC4244] Barnes, M., "An Extension to the Session Initiation Protocol (SIP) for Request History Information", RFC 4244, November 2005. [RFC4458] Jennings, C., Audet, F., and J. Elwell, "Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and Interactive Voice Response (IVR)", RFC 4458, April 2006. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [RFC4694] Yu, J., "Number Portability Parameters for the "tel" URI", RFC 4694, October 2006. [RFC5486] Malas, D. and D. Meyer, "Session Peering for Multimedia Interconnect (SPEERMINT) Terminology", RFC 5486, March 2009. Hancock & Malas Expires April 29, 2010 [Page 27] Internet-Draft SIP Interconnect Guidelines October 2009 Authors' Addresses David Hancock CableLabs 858 Coal Creek Circle Louisville, CO 80027 USA Email: d.hancock@cablelabs.com Daryl Malas CableLabs 858 Coal Creek Circle Louisville, CO 80027 USA Email: d.malas@cablelabs.com Hancock & Malas Expires April 29, 2010 [Page 28]