One document matched: draft-hancock-sip-interconnect-guidelines-01.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC4566 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4566.xml'>
<!ENTITY RFC3261 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml'>
<!ENTITY RFC3265 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3265.xml'>
<!ENTITY RFC3311 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3311.xml'>
<!ENTITY RFC3323 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3323.xml'>
<!ENTITY RFC3325 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3325.xml'>
<!ENTITY RFC3515 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3515.xml'>
<!ENTITY RFC3891 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3891.xml'>
<!ENTITY RFC3966 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3966.xml'>
<!ENTITY RFC4694 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4694.xml'>
<!ENTITY RFC3264 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3264.xml'>
<!ENTITY RFC4244 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4244.xml'>
<!ENTITY RFC4235 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4235.xml'>
<!ENTITY RFC2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY RFC4028 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4028.xml'>
<!ENTITY RFC3725 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3725.xml'>
<!ENTITY RFC5486 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5486.xml'>
<!ENTITY I-D.ietf-sip-gruu PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-sip-gruu-15.xml'>
]>
<rfc category="info" docName="draft-hancock-sip-interconnect-guidelines-01" ipr="trust200902">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title abbrev="SIP Interconnect Guidelines">
</title>
<author initials='D.H.' surname="Hancock" fullname='David Hancock'>
<organization>CableLabs</organization>
<address>
<postal>
<street>858 Coal Creek Circle</street>
<city>Louisville</city> <region>CO</region>
<code>80027</code>
<country>USA</country>
</postal>
<email>d.hancock@cablelabs.com</email>
</address>
</author>
<author initials='D.M.' surname="Malas" fullname='Daryl Malas'>
<organization>CableLabs</organization>
<address>
<postal>
<street>858 Coal Creek Circle</street>
<city>Louisville</city> <region>CO</region>
<code>80027</code>
<country>USA</country>
</postal>
<email>d.malas@cablelabs.com</email>
</address>
</author>
<date month="July" year="2009"/>
<area>Real-time Applications and Interfaces</area>
<workgroup>Speermint</workgroup>
<abstract>
<t>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.
</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="Introduction">
<t>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.
</t>
<t>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.
</t>
<t>
This document provides an interconnect guideline to address potential SIP interworking issues for peering SIP-based networks.
</t>
<section title="Scope" anchor="Scope">
<t>
The document focuses on the interworking procedures required to support basic telephone service,
including the following capabilities:
<list style="symbols">
<t>
On-net to on-net calls
</t>
<t>
Caller ID with Privacy
</t>
<t>
Early media
</t>
<t>
Local Number Portability
</t>
<t>
Call hold/conf/xfer
</t>
<t>
Call forwarding
</t>
<t>
Auto Recall/Callback
</t>
<t>
Problem Isolation - Inter-network keep-alives
</t>
</list>
<!-- TIP: This inserts new lines -->
<vspace blankLines='1' />
Interworking procedures in support of the following capabilities are not addressed:
<list style="symbols">
<t>
Calls to/from PSTN
</t>
<t>
Operator calls
</t>
<t>
0+,0-, busy-line-verify
</t>
<t>
Emergency calls
</t>
<t>
Transmission loss plan
</t>
<t>
Operational capabilities
</t>
<t>
Accounting
</t>
<t>
Electronic Surveillance
</t>
<t>
Quality-of-Service
</t>
<t>
Authentication and Security
</t>
<t>
Voice, FAX, DTMF-relay
</t>
<t>
RTCP VoIP Metrics
</t>
<t>
SIP RTP Loopback
</t>
</list>
</t>
</section>
</section>
<section title="Terminology" anchor="Terminology">
<section title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
<t>This draft also uses terms defined in <xref target="RFC5486">
</xref>.
</t>
</section>
</section>
<section title="Reference Architecture" anchor="ReferenceArchitecture">
<t>
<xref target="PeeringArchitecture"/> 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).
<figure title="Peering Architecture" anchor="PeeringArchitecture">
<artwork>
<![CDATA[
+------+
| 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--+ |
\ / \ /
--------------- ---------------
]]>
</artwork>
</figure>
</t>
</section>
<section title="General Procedures" anchor="GeneralProcedures">
<t>
</t>
<section title="Extension Negotiation" anchor="ExtensionNegotiation">
<t>
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. Therefore, when sending a dialog-initiating
SIP request to a peer network, the SBE SHOULD NOT include a 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. Furthermore, on sending a dialog initiating request to a peer network, the SBE MUST ensure that
all the SIP extensions identified in the Supported header field are supported by the sending UA (i.e. the SBE can
modify the Supported header field received from the sending UA as long as the resulting set of extensions are
supported by the sending UA). 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.
<vspace blankLines='1' />
When sending a dialog-initialing request to a peer network, the SBE SHOULD ensure that all the SIP requests
identified in the Allow header field are supported by the sending UA.
</t>
</section>
<section title="Public User Identities" anchor="PublicUserIdentities">
<t>
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 <xref target="RFC3261">
</xref>), where the user part of the SIP URI contains a global Tel URI as defined in
<xref target="RFC3966"></xref>.
<vspace blankLines='1' />
Example:
<vspace blankLines='1' />
sip:+13035551212@examplessp.com;user=phone
</t>
<section title="Identifying the Called User" anchor="IdentifyingtheCalledUser">
<t>
When sending a dialog-initiating request to a peer network, SIP entities
involved in session peering MUST
<list style="symbols">
<t>
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
</t>
<t>
if Local Number Portability (LNP) information for the called number
was obtained, then
<list style="symbols">
<t>
include the LNP data in SIP URI in the Request-URI using the Tel URI
"npdi" and "rn" parameters as defined in <xref target="RFC4694"></xref>, and
</t>
<t>
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").
</t>
</list>
</t>
</list>
<vspace blankLines='1' />
On receiving a dialog-initiating request from a peer network, SIP entities involved in
session peering MUST:
<list style="symbols">
<t>
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
</t>
<t>
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 <xref target="RFC4694">
</xref>.
</t>
</list>
</t>
</section>
<!--
end 4.2.1 Identifying Called User
-->
<section title="Identifying the Calling User" anchor="IdentifyingtheCallingUser">
<t>
When sending or receiving a dialog-initiating request, SIP entities involved
in session peering MUST:
<list style="symbols">
<t>
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
</t>
<t>
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.
</t>
</list>
</t>
</section>
<!--
end 4.2.2 Identifying Calling User
-->
</section>
<!--
end 4.2 Public User Identities
-->
<section title="Trust Domain and Asserted Identities" anchor="TrustDomainandAssertedIdentities">
<t>
In a peering relationship, both originating and terminating networks are in the
same trust domain. Therefore, per <xref target="RFC3325"></xref>, 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.
</t>
</section>
<!--
end 4.3 Trust Domain and Asserted Identities
-->
<!--
<section title="Dummy" anchor="Dummy">
<t>
</t>
</section>
-->
<section title="IPv4/6 Interworking" anchor="IPv4/6Interworking">
<t>
It is the responsibility of the IPv6 network to perform the IPv4/IPv6
interworking function when interworking with an IPv4 network.
</t>
</section>
<!--
end 4.4 IPv4/6 Interworking
-->
<section title="Fault Isolation and Recovery" anchor="FaultIsolationandRecovery">
<t>
</t>
<section title="Interface Failure Detection" anchor="InterfaceFailureDetection">
<t>
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.
<vspace blankLines='1' />
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.
</t>
</section>
<section title="Overload Control" anchor="OverloadControl">
<t>
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.
<vspace blankLines='1' />
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:
<list style="symbols">
<t>
terminate the current transaction,
</t>
<t>
ignore the Retry-After header if one is present,
and
</t>
<t>
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).
</t>
</list>
</t>
</section>
<section title="Session Timer" anchor="SessionTimer">
<t>
SIP entities involved in session peering SHOULD support Session Timer
as defined in <xref target="RFC4028"></xref>.
</t>
</section>
</section>
<!--
end 4.5 Fault Isolation and recovery
-->
</section>
<!--
end 4 General Procedures
-->
<section title="Call Features" anchor="CallFeatures">
<t>
</t>
<section title="Session Establishment" anchor="SessionEstablishment">
<t>
</t>
<section title="SDP Requirements" anchor="SDPRequirements">
<t>
SIP entities involved in session peering MUST support the SDP
requirements defined in <xref target="RFC4566"></xref>. 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.
</t>
<section title="Hold" anchor="Hold">
<t>
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.
<vspace blankLines='1' />
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".
</t>
</section>
</section>
<section title="Offer/Answer, Ringback Tone, and Early Media" anchor="OfferAnswer">
<t>
</t>
<section title="Basic Call Setup" anchor="BasicCallSetup">
<t>
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, it is assumed that session establishment is initiated by
the originating User Agent itself, and not via a 3rd party using 3PCC techniques.
<vspace blankLines='1' />
SIP entities involved in session peering MUST support the SDP offer/answer
procedures specified in <xref target="RFC3264"></xref>. 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.
<vspace blankLines='1' />
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.
<vspace blankLines='1' />
SIP entities involved in session peering MUST always set the SDP mode attribute
in the initial offer/answer to "a=sendrecv".
<vspace blankLines='1' />
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.
<vspace blankLines='1' />
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.
</t>
</section>
<section title="Ringback Tone vs. Early Media" anchor="RingbackTonevsEarlyMedia">
<t>
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.
<vspace blankLines='1' />
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 the call to be answered:
<list style="symbols">
<t>
The terminating network MUST send the following provisional response
to a call-initiating INVITE:
<list style="symbols">
<t>
a 180 (Alerting) response containing no SDP if the call scenario
requires the originating network to apply local ringback tone,
</t>
<t>
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,
</t>
<t>
the provisional response sent for other call scenarios is not
specified, as long as the response is not one of those specified
above.
</t>
</list>
</t>
<t>
The originating network MUST perform the following action on receipt of
a provisional response to a call-initiating INVITE:
<list style="symbols">
<t>
on receiving a 180 (Alerting) response containing no SDP, apply
local ringback tone,
</t>
<t>
on receiving a 180 (Alerting) or 183 (Progressing) containing SDP,
establish an early media session with the media endpoint described
by the SDP,
</t>
<t>
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)
</t>
</list>
</t>
</list>
</t>
</section>
<section title="Early-Media with Multiple Terminating Endpoints" anchor="Early-MediawithMultipleTerminatingEndpoints">
<t>
<vspace blankLines='1' />
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.
<vspace blankLines='1' />
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.
<vspace blankLines='1' />
<xref target="RFC3261"></xref> 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.
<vspace blankLines='1' />
</t>
<section title="Media Anchor" anchor="MediaAnchor">
<t>
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.
<vspace blankLines='1' />
The disadvantage of the media-
anchor mechainsm is that it prevents direct end-to-end
codec negotiation between the calling and called endpoints (e.g., would block their ability
to negotiate a superior codec for the call).
</t>
</section>
<section title="Early Answer" anchor="Early Answer">
<t>
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 <xref target="RFC3311">
</xref>) 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).
</t>
</section>
<section title="Forking the INVITE" anchor="ForkingtheINVITE">
<t>
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.
<vspace blankLines='1' />
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.
<vspace blankLines='1' />
The originating network MUST honor the most recently received 18x response
to INVITE, based on the procedures defined in section 5.1.2.2.
</t>
</section>
</section>
</section>
</section>
<section title="Calling Name and Number Deliver (with Privacy)" anchor="CallingNameandNumber">
<t>
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.
<vspace blankLines='1' />
If the originating user wants to remain anonymous, the originating network MUST
include a Privacy header containing the value "id" as specified in <xref target="RFC3323">
</xref> and <xref target="RFC3325">
</xref>. In addition, the originating network SHOULD obscure the identity of the
originating user in other headers as follows:
<list style="symbols">
<t>
Set the identity information in the 'From' header to "Anonymous SIP:anonymous@anonymous.invalid",
</t>
<t>
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).
</t>
<t>
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.
</t>
</list>
</t>
</section>
<section title="Call Forwarding" anchor="CallForwarding">
<t>
A SIP entity involved in session peering MUST support the following call-forwarding procedures:
<list style="symbols">
<t>
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
<list style="symbols">
<t>
remaining in the signaling path as a proxy or B2BUA, or
</t>
<t>
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
</t>
</list>
</t>
<t>
MUST support the History header as defined in <xref target="RFC4244">
</xref> to detect call-forwarding loops.
</t>
</list>
</t>
</section>
<section title="Call Transfer" anchor="CallTransfer">
<t>
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 <xref target="RFC3515">
</xref> and Replaces header <xref target="RFC3891"></xref>,
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.
</t>
<section title="Call-Transfer Using REFER/Replaces" anchor="Call-TransferUsingREFER/Replaces">
<t>
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 <xref target="RFC3515"></xref>, and the SIP Replaces extension described in
<xref target="RFC3891"></xref>.
Furthermore, <xref target="RFC3515"></xref> requires support of the SIP Event Notification extension
described in <xref target="RFC3265"></xref>.
<vspace blankLines='1' />
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:
<list style="symbols">
<t>
User-A puts user-B on hold (sends re-INVITE with SDP "a=inactive" as described
in 5.1.1.1)
</t>
<t>
User-A initiates a basic 2-way call to user-C
</t>
<t>
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.
<list style="symbols">
<t>
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,
</t>
<t>
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.
</t>
</list>
</t>
<t>
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)
</t>
<t>
User-B sends Notify requests within the original A-to-B dialog, informing
user-A of the progress of the B-to-C call
</t>
<t>
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.
</t>
</list>
SIP SFs involved in session peering SHOULD support receiving a GRUU <xref target="I-D.ietf-sip-gruu">
</xref>
in the Refer-To header.
</t>
</section>
<section title="Call-Transfer Using 3PCC" anchor="Call-TransferUsing3PCC">
<t>
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 <xref target="RFC3725">
</xref>.
</t>
</section>
</section>
<section title="3-way Conference" anchor="3-wayConference">
<t>
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
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.
</t>
</section>
<section title="Auto Recall/Callback" anchor="AutoRecall/Callback">
<t>
SIP entities involved in session peering that support Auto Recall/Callback MUST support the
dialog-event package as defined in <xref target="RFC4235">
</xref> as the mechanism to detect when the target
user becomes available in the peer network.
</t>
</section>
</section>
<section title="Security Considerations" anchor="SecurityConsiderations">
<t>This draft contains no new security considerations that have not already been defined in SIP and the specified
SIP extensions in this draft.
</t>
</section>
<section title="Acknowledgements" anchor="Acknowledgements">
<t>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.
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This draft contains no IANA considerations.</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC4566;
&RFC3261;
&RFC3265;
&RFC3311;
&RFC3323;
&RFC3325;
&RFC3515;
&RFC3891;
&RFC3966;
&RFC4694;
&RFC4244;
&RFC4235;
&RFC2119;
&RFC4028;
&RFC3264;
&RFC3725;
&RFC5486;
&I-D.ietf-sip-gruu;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:21:16 |