One document matched: draft-hancock-sip-interconnect-guidelines-00.txt
Speermint D. Hancock
Internet-Draft D. Malas
Intended status: Informational CableLabs
Expires: September 6, 2009 March 5, 2009
draft-hancock-sip-interconnect-guidelines-00
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 September 6, 2009.
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 September 6, 2009 [Page 1]
Internet-Draft SIP Interconnect Guidelines March 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
3. Reference Architecture . . . . . . . . . . . . . . . . . . . . 6
4. General Procedures . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Extension Negotiation . . . . . . . . . . . . . . . . . . 8
4.2. Public User Identities . . . . . . . . . . . . . . . . . . 8
4.2.1. Identifying the Called User . . . . . . . . . . . . . 8
4.2.2. Identifying the Calling User . . . . . . . . . . . . . 9
4.3. Trust Domain and Asserted Identities . . . . . . . . . . . 10
4.4. IPv4/6 Interworking . . . . . . . . . . . . . . . . . . . 10
4.5. Fault Isolation and Recovery . . . . . . . . . . . . . . . 10
4.5.1. Interface Failure Detection . . . . . . . . . . . . . 10
4.5.2. Overload Control . . . . . . . . . . . . . . . . . . . 10
4.5.3. Session Timer . . . . . . . . . . . . . . . . . . . . 11
5. Call Features . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Session Establishment . . . . . . . . . . . . . . . . . . 12
5.1.1. SDP Requirements . . . . . . . . . . . . . . . . . . . 12
5.1.2. Offer/Answer, Ringback Tone, and Early Media . . . . . 12
5.2. Calling Name and Number Deliver (with Privacy) . . . . . . 16
5.3. Call Forwarding . . . . . . . . . . . . . . . . . . . . . 17
5.4. Call Transfer . . . . . . . . . . . . . . . . . . . . . . 17
5.4.1. Call-Transfer Using REFER/Replaces . . . . . . . . . . 17
5.4.2. Call-Transfer Using 3PCC . . . . . . . . . . . . . . . 18
5.5. 3-way Conference . . . . . . . . . . . . . . . . . . . . . 18
5.6. Auto Recall/Callback . . . . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
9. Normative References . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
Hancock & Malas Expires September 6, 2009 [Page 2]
Internet-Draft SIP Interconnect Guidelines March 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
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 Caller ID with Privacy
o Early media
o Local Number Portability
Hancock & Malas Expires September 6, 2009 [Page 3]
Internet-Draft SIP Interconnect Guidelines March 2009
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
o SIP RTP Loopback
Hancock & Malas Expires September 6, 2009 [Page 4]
Internet-Draft SIP Interconnect Guidelines March 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
[I-D.ietf-speermint-terminology].
Hancock & Malas Expires September 6, 2009 [Page 5]
Internet-Draft SIP Interconnect Guidelines March 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. When the DBE is not deployed, media is exchanged
directly between the SIP user agents (UA).
+------+
| 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 September 6, 2009 [Page 6]
Internet-Draft SIP Interconnect Guidelines March 2009
Figure 1: Peering Architecture
Hancock & Malas Expires September 6, 2009 [Page 7]
Internet-Draft SIP Interconnect Guidelines March 2009
4. General Procedures
4.1. Extension Negotiation
It is recommended that the originating SF or 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. Therefore, a dialog-
initiating SIP request to a peer network SHOULD NOT include the
Require header unless both networks agree that the extension(s)
identified in the Require header are supported (and required) for all
call-scenarios between those peers. A dialog-initiating SIP request
to a peer network SHOULD include a Supported identifying all the
extensions supported by the sending network. Once a dialog has been
established (whether early or final), one or more of the supported
extensions can then be required by including the extension(s) in the
Require header.
A peer network SHOULD list all supported SIP requests in the Allow
header of dialog-initiating requests.
4.2. Public User Identities
Users are identified at the peering interface by their Public User
Identity. A SIP entity involved in session peering 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, SIP
entities involved in session peering MUST
o identify the called user in the Request URI of the request,
o identify the called user 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
Hancock & Malas Expires September 6, 2009 [Page 8]
Internet-Draft SIP Interconnect Guidelines March 2009
* 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").
On receiving a dialog-initiating request from a peer network, SIP
entities involved in session peering 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,
o retrieve the LNP data for the called number based on the "npdi"
and "rn" parameters contained in the SIP URI in the Request URI as
defined in [RFC4694], and
o identify the routing number based on the contents of the "rn"
parameter as follows:
* if "rn" contains the global form of the routing number as
indicated by a leading "+" character followed by the country-
code followed by the national number (e.g., "rn=+16132220000"),
then use that as the routing number; or
* if "rn" contains a 10-digit national number within the North
American numbering plan (e.g., "rn=6132220000"), then assume
the context of the local number is within the North American
number plan (essentially prepend "+1" to make it global), and
use that as the routing number.
4.2.2. Identifying the Calling User
When sending or receiving a dialog-initiating request, SIP entities
involved in session peering 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.
Hancock & Malas Expires September 6, 2009 [Page 9]
Internet-Draft SIP Interconnect Guidelines March 2009
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
A network can 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 network fails to receive a response to an
OPTIONS request, then it will consider that non-responding ingress
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, a network MAY impose limits on the number of
simultaneous calls, and the incoming call rate it will accept from a
peer. On receiving a dialog-initiating request that exceeds such
limits, the receiving network MUST respond with a 503 (Service
Unavailable) response. A network receiving a dialog-initiating
request MUST limit the use of the 503 (Service Unavailable) responses
to reporting overload at the ingress SF or SBE, and MUST NOT use this
response to report overload or other failures internal to the
network.
Hancock & Malas Expires September 6, 2009 [Page 10]
Internet-Draft SIP Interconnect Guidelines March 2009
On receiving a 503 (Service Unavailable) response from a peer
network, the receiving network 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 network 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
originating user agent. Specifically, on receiving a 503 (Service
Unavailable) response to a dialog-initiating request that was sent to
a peer network, the originating network 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 or aggravate the same overload condition).
4.5.3. Session Timer
SIP entities involved in session peering SHOULD support Session Timer
as defined in [RFC4028].
Hancock & Malas Expires September 6, 2009 [Page 11]
Internet-Draft SIP Interconnect Guidelines March 2009
5. Call Features
5.1. Session Establishment
5.1.1. SDP Requirements
SIP entities involved in session peering MUST support the SDP
requirements defined in [RFC4566]. A SIP entity involved in session
peering MUST include only one media (m=) descriptor in an SDP offer
to a peer network. If a SIP entity involved in session peering
receives an SDP offer containing multiple media descriptors, it
SHOULD act on the first audio descriptor with a non-zero port.
5.1.1.1. Hold
A SIP entity involved in session peering 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. A SIP entity involved in session peering that wishes to 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). A network that wants to place
a media stream "on hold" SHOULD locally mute the media stream.
A SIP entity involved in session peering 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". A SIP entity involved
in session peering 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. A SIP entity involved in session
peering 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.1.2. Offer/Answer, Ringback Tone, and Early Media
5.1.2.1. Basic Call Setup
This section describes the procedures at the peering interface
required to establish a 2-way session for a basic voice call. 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.
During the establishment of a basic 2-way call, the originating
network MUST NOT indicate support of PRACK [RFC3262] (i.e., must not
include the option-tag "100rel"in the Require or Supported header of
Hancock & Malas Expires September 6, 2009 [Page 12]
Internet-Draft SIP Interconnect Guidelines March 2009
the initial INVITE).
SIP entities involved in session peering MUST support the SDP offer/
answer procedures specified in [RFC3264]. The originating network
MUST include an SDP offer in the initial INVITE. The terminating
network MUST include an SDP answer in the final 200 (OK) response to
the INVITE. The terminating network MAY also include an SDP body in
a provisional 18x response to the INVITE. The SDP contained in a 18x
provisional response can be considered a "preview" of the actual SDP
answer to be sent in the 200 (OK) to INVITE. The originating network
can act on this "preview" SDP to establish an early media session, as
described in section 5.1.2.2. The terminating network 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
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.
SIP entities involved in session peering 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.
SIP entities involved in session peering that advertise support for
different but overlapping sets of codecs in their SDP MUST negotiate
a common codec during the SDP offer/answer exchange.
5.1.2.2. 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.
SIP entities involved in session peering MUST use the following
procedures to control whether the originating line applies local
ringback tone or establishes an early media session while waiting for
Hancock & Malas Expires September 6, 2009 [Page 13]
Internet-Draft SIP Interconnect Guidelines March 2009
the call to be answered:
o The terminating network 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.
o The originating network 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) 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.2.3. 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
Hancock & Malas Expires September 6, 2009 [Page 14]
Internet-Draft SIP Interconnect Guidelines March 2009
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 in 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 three different mechanisms for supporting multiple
terminating media endpoints before answer, within the confines of
this requirement.
5.1.2.3.1. Media Anchor
In this case the media is relayed through a DBE in the target
network. This masks the fact that the target endpoint is changing,
so that from the originating network's perspective there is only one
target media endpoint which can be described by a single SDP. The
target network can still control whether the originating network
applies local ringback tone or establishes an early media session as
described in section 5.1.2.2.
5.1.2.3.2. Early Answer
In this case the early-media issue is bypassed by answering the call
early to establish a regular (not early) media session. Even though
the called user has not actually answered the call, the target
network sends a final 200 (OK) response to the INVITE to establish a
regular media session with the first media endpoint. The target
network can then initiate additional SDP offer/answer exchanges (say,
using re-INVITE or UPDATE [RFC3311]) to connect additional media
endpoints. This option is not sufficiently general for all cases,
but works for those scenarios where a session must be connected with
a series of target endpoints before the called user answers the call
(or when the called user doesn't answer the call), and it is possible
to generate an answer with the first target endpoint in order to
establish a normal session (say, on no-answer timeout when call is
redirected to voice-mail).
Hancock & Malas Expires September 6, 2009 [Page 15]
Internet-Draft SIP Interconnect Guidelines March 2009
5.1.2.3.3. Forking the INVITE
The mechanism described here applies when the previous two mechanisms
do not work; i.e., when the media is not being relayed through a
target DBE, and the use-case does not allow the call to be answered
early.
For each target media endpoint that requires an early media session
to be established with the originating user agent, the target network
MUST signal the attributes of the target media endpoint to the
originating network within the SDP of a 183 (Progressing) response.
The target network MUST ensure that 18x responses containing
different SDP copies are not sent within the same dialog. The target
network 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 network MUST honor the most recently received 18x
response to INVITE, based on the procedures defined in section
5.1.2.2.
5.2. Calling Name and Number Deliver (with Privacy)
The originating network 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
network MUST include a Privacy header containing the value "id" as
specified in [RFC3323] and [RFC3325]. In addition, the originating
network 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.
Hancock & Malas Expires September 6, 2009 [Page 16]
Internet-Draft SIP Interconnect Guidelines March 2009
5.3. Call Forwarding
A SIP entity involved in session peering MUST support the following
call-forwarding procedures:
o The forwarding network MAY remain in the signaling path of the
forwarded call in order to support separate billing of forward-
from and forward-to legs. This is accomplished by
* remaining in the signaling path as a proxy or B2BUA, or
* 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
o MUST support the History header as defined in [RFC4244] to detect
call-forwarding loops.
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. SIP entities
involved in session peering 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
SIP entities involved in session peering 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 ssp-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:
Hancock & Malas Expires September 6, 2009 [Page 17]
Internet-Draft SIP Interconnect Guidelines March 2009
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
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, as described in [RFC3603].
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.
SIP SFs involved in session peering SHOULD support receiving a GRUU
[I-D.ietf-sip-gruu] in the Refer-To header.
5.4.2. Call-Transfer Using 3PCC
SIP entities involved in session peering 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
Hancock & Malas Expires September 6, 2009 [Page 18]
Internet-Draft SIP Interconnect Guidelines March 2009
of hold as described in section 5.1.1.1. When conference mixing is
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
SIP entities involved in session peering that support Auto Recall/
Callback MUST support the dialog-event package as defined in
[RFC4235] as the mechanism to detect when the target user becomes
available in the peer network.
Hancock & Malas Expires September 6, 2009 [Page 19]
Internet-Draft SIP Interconnect Guidelines March 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 September 6, 2009 [Page 20]
Internet-Draft SIP Interconnect Guidelines March 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 September 6, 2009 [Page 21]
Internet-Draft SIP Interconnect Guidelines March 2009
8. IANA Considerations
This draft contains no IANA considerations.
Hancock & Malas Expires September 6, 2009 [Page 22]
Internet-Draft SIP Interconnect Guidelines March 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-terminology]
Malas, D. and D. Meyer, "SPEERMINT Terminology",
draft-ietf-speermint-terminology-17 (work in progress),
November 2008.
[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.
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of
Provisional Responses in Session Initiation Protocol
(SIP)", RFC 3262, 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.
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP)
UPDATE Method", RFC 3311, October 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.
[RFC3603] Marshall, W. and F. Andreasen, "Private Session Initiation
Protocol (SIP) Proxy-to-Proxy Extensions for Supporting
Hancock & Malas Expires September 6, 2009 [Page 23]
Internet-Draft SIP Interconnect Guidelines March 2009
the PacketCable Distributed Call Signaling Architecture",
RFC 3603, October 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.
[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.
[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.
Hancock & Malas Expires September 6, 2009 [Page 24]
Internet-Draft SIP Interconnect Guidelines March 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 September 6, 2009 [Page 25]
| PAFTECH AB 2003-2026 | 2026-04-23 09:09:45 |