One document matched: draft-petithuguenin-vipr-sip-intermediaries-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<rfc category="std" docName="draft-petithuguenin-vipr-sip-intermediaries-01" ipr="noModificationTrust200902">
<front>
<title abbrev="VIPR SIP Intermediaries">Verification Involving PSTN Reachability (VIPR) enabled SIP Intermediaries</title>
<author fullname="Marc Petit-Huguenin" initials="M." surname="Petit-Huguenin">
<organization>Stonyfish</organization>
<address>
<email>marc@stonyfish.com</email>
</address>
</author>
<date day="4" month="October" year="2011"/>
<area>RAI</area>
<workgroup>VIPR WG</workgroup>
<abstract>
<t>This document presents some of the problems created by SIP intermediaries inside a VIPR federation.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
The <xref target="VIPR-FRAMEWORK"/> specification assumes that a VIPR domain has a direct connection with the PSTN.
An example of the interactions between VIPR domains following this specification are depicted in the following diagram:
</t>
<t>(For all the diagrams in this document, "--->" means a <xref target="RELOAD"/> transaction, "~~~~>" a PSTN transaction, ":::>" a <xref target="PVP"/> transaction and "===>" a <xref target="SIP"/> transaction).</t>
<figure>
<artwork><![CDATA[
DomainA RELOAD DomainB
| | Store |
| |<-----------|
: : :
| SETUP | |
|~~~~~~~~~~~~~~~~~~~~~~~~~>|
: : :
| | DISC |
|<~~~~~~~~~~~~~~~~~~~~~~~~~|
: : :
| Fetch | |
|------------>| |
| ValExchange | |
|:::::::::::::::::::::::::>|
: : :
| INVITE | |
|=========================>|
| | |
]]></artwork>
</figure>
<t>
Even if a VIPR domain has a direct access to the PSTN, it is generally not economical to have one PSTN connection for each VIPR server, so the PSTN gateway is generally on a different physical box, so it can be shared inside the domain.
The communication protocol with the PSTN gateway is generally SIP, probably using the SIPconnect profile defined by the <eref target="http://www.sipforum.org/">SIP Forum</eref>.
An example of the interactions are depicted in the following diagram:
</t>
<figure>
<artwork><![CDATA[
DomainA GatewayA RELOAD DomainB
| | | Store |
| | |<-----------|
: : : :
| INVITE | | |
|============>| SETUP | |
| |~~~~~~~~~~~~~~~~~~~~~~~~~>|
: : : :
| | | DISC |
| BYE |<~~~~~~~~~~~~~~~~~~~~~~~~~|
|<============| | |
: : : :
| Fetch | | |
|-------------------------->| |
| ValExchange | | |
|:::::::::::::::::::::::::::::::::::::::>|
: : : :
| INVITE | | |
|=======================================>|
| | | |
]]></artwork>
</figure>
<t>
One important thing to consider here is that the SIP profile used between the call agent and the PSTN gateway inside the VIPR domain is completely different from the SIP profile used between the VIPR domains A and B subsequently to the PVP validation.
The second SIP profile will use wideband audio, video, realtime text and other features that are not possible when going through the PSTN.
For the remaining of the discussion, we will call this SIP profile SIPbeyond, in reference to the book "SIP Beyond VoIP" by Henry Sinnreich, Alan B. Johnston and Robert J. Sparks.
</t>
<t>
The VIPR specifications does not prevent to move the PSTN gateway outside the VIPR domain, for example by using SIP trunking.
In this case the SIP connection to the provider still use the SIPconnect profile, and the direct route used subsequently to the validation still use the SIPbeyond profile.
Because of this, VIPR still work the same way as before, as depicted in the following diagram:
</t>
<figure>
<artwork><![CDATA[
DomainA Provider RELOAD DomainB
| | | Store |
| | |<-----------|
: : : :
| INVITE SIPconnect | | |
|==================>| SETUP | |
| |~~~~~~~~~~~~~~~~~~~~~~~~~>|
: : : :
| | | DISC |
| BYE |<~~~~~~~~~~~~~~~~~~~~~~~~~|
|<==================| | |
: : : :
| Fetch | | |
|-------------------------------->| |
| ValExchange | | |
|:::::::::::::::::::::::::::::::::::::::::::::>|
: : : :
| INVITE SIPbeyond | | |
|=============================================>|
| | | |
]]></artwork>
</figure>
<t>
Obviously what is true for outgoing calls is also true for incoming call and a VIPR domain can also receive incoming PSTN calls from an internal PSTN gateway or, as depicted in the following diagram, from an external PSTN gateway located in a provider:
</t>
<figure>
<artwork><![CDATA[
DomainA ProviderX RELOAD ProviderY DomainB
| | | | Store |
| | |<--------------------------|
: : : : :
| INVITE SIPc | | | |
|=============>| SETUP | | |
| |~~~~~~~~~~~~~~~~~~~~~~~~~~>| INVITE SIPc |
| | | |============>|
: : : : :
| | | | BYE |
| | | DISC |<============|
| BYE |<~~~~~~~~~~~~~~~~~~~~~~~~~~| |
|<=============| | | |
: : : : :
| Fetch | | | |
|--------------------------->| | |
| ValExchange | | | |
|:::::::::::::::::::::::::::::::::::::::::::::::::::::::>|
: : : : :
| INVITE SIPb | | | |
|=======================================================>|
| | | | |
]]></artwork>
</figure>
<t>
In this configuration, it is important to consider that the two providers can have some peering arrangement between them that will shortcut the PSTN, without either of the two VIPR domains knowing it.
The probability of a short-cut is even higher if the two providers are in fact the same provider.
Even a VIPR domain that is using only a direct connection to the PSTN cannot assume that a call is really going through the PSTN, as the PSTN provider itself can choose to use VoIP to route the calls behind the PSTN gateways.
The following diagram depicts what happen when the two providers use peering:
</t>
<figure>
<artwork><![CDATA[
DomainA ProviderX RELOAD ProviderY DomainB
| | | | Store |
| | |<--------------------------|
: : : : :
| INVITE SIPc | | | |
|=============>| INVITE SIPc | | |
| |==========================>| INVITE SIPc |
| | | |============>|
: : : : :
| | | | BYE |
| | | BYE |<============|
| BYE |<==========================| |
|<=============| | | |
: : : : :
| Fetch | | | |
|--------------------------->| | |
| ValExchange | | | |
|:::::::::::::::::::::::::::::::::::::::::::::::::::::::>|
: : : : :
| INVITE SIPb | | | |
|=======================================================>|
| | | | |
]]></artwork>
</figure>
<t>
So at this point, we have to admit the reality that there is no guarantee that a call made to a PSTN gateway or to a provider will necessarily been routed over the PSTN, and that we will have to assume that in any cases the call will have the same properties than if it was fully routed over the PSTN.
Without this assumption, the premises of VIPR no longer hold.
</t>
<t>
Going further, there is also nothing that prevent the providers to use VIPR as a replacement for their peering arrangement.
The main problem with this is that these providers will not be able to do much more than toll bypass, as the SIP profile used to connect to and from their servers, SIPconnect, does not support any of the features that VIPR is supposed to enable.
But because no recommendations will ever prevent these providers to do this, this document should try its best to accommodate a VIPR federation that include them by:
</t>
<t>
<list style="numbers">
<t>guaranteeing that providers using VIPR for toll bypassing will not impede the VIPR federation,</t>
<t>providing a way for providers to fully participate in the VIPR federation by enabling them to establish SIP connections supporting the enhanced features promised by VIPR.</t>
</list>
</t>
<section title="Problems Created by Providers using VIPR as Toll Bypass">
<t>
The problem with providers using VIPR for the sole purpose of toll bypass is that it creates the possibility that more than one VIPR domain claim ownership of a specific phone number.
The assumption in the VIPR specification is that, although multiple VIPR domains can claim the ownership of a number, only one of them is the rightful owner of this number.
Now that we demonstrated that there was nothing preventing one or more levels of VIPR domains between the user of the phone number and the PSTN, this assumption no longer holds.
The consequences of this reality is that there will be one Originating VCR generated for each VIPR domain in the outgoing call path, and there will be one Terminating VCR generated for each VIPR domain in the incoming call path.
<vspace blankLines="100"/>
</t>
<section title="Multiple VIPR Domains in the Outgoing Call Path">
<t>The problem with multiple VIPR domains in the outgoing call path is that multiple originating VCR will be generated, each one triggering a PVP transaction, as depicted in the following diagram:</t>
<figure>
<artwork><![CDATA[
DomainA ProviderX RELOAD ProviderY DomainB
| | | | Store |
| | |<--------------------------|
: : : : :
| INVITE SIPc | | | |
|=============>| SETUP | | |
| |~~~~~~~~~~~~~~~~~~~~~~~~~~>| INVITE SIPc |
| | | |============>|
: : : : :
| | | | BYE |
| | | DISC |<============|
| BYE |<~~~~~~~~~~~~~~~~~~~~~~~~~~| |
|<=============| | | |
: : : : :
| | Fetch | | |
| |------------>| | |
| | ValExchange | | |
| |::::::::::::::::::::::::::::::::::::::::>|
: : : : :
| Fetch | | | |
|--------------------------->| | |
| ValExchange | | | |
|:::::::::::::::::::::::::::::::::::::::::::::::::::::::>|
: : : : :
| INVITE SIPb | | | |
|=======================================================>|
| | | | |
]]></artwork>
</figure>
<t>
The assumption that only one PVP transaction will succeed is not true in this case, as both DomainA and ProviderX have the information to validate PVP transaction.
Depending on the implementation of VIPR on the DomainB domain, either the first of the two PVP transaction will succeed, or both will succeed.
If only the DomainA PVP transaction succeeds then enhanced SIP will use the direct route from DomainA to DomainB, with a fallback to the PSTN if this route fails.
If only the ProviderX PVP transaction succeeds, then toll bypass will be used, but the next call will trigger a new originating VCR that after a successful PVP transaction will create a direct enhanced SIP route between DomainA and DomainB.
if both succeeds, then the enhanced SIP will use the direct route from DomainA to DomainB, with a fallback to toll bypass if this route fails.
</t>
</section>
<section title="Multiple VIPR Domains in the Incoming Call Path">
<t>
The problem with multiple VIPR domains in the incoming call path is that multiple terminating VCR will be generated, each one matching a VIPR-REGISTRATION in the RELOAD overlay.
Each PVP transaction created for each VIPR-REGISTRATION has a chance to succeed, as depicted in the following diagram:
</t>
<figure>
<artwork><![CDATA[
DomainA ProviderX RELOAD ProviderY DomainB
| | | Store | |
| | |<------------| |
| | | | Store |
| | |<--------------------------|
: : : : :
| INVITE SIPc | | | |
|=============>| SETUP | | |
| |~~~~~~~~~~~~~~~~~~~~~~~~~~>| INVITE SIPc |
| | | |============>|
: : : : :
| | | | BYE |
| | | DISC |<============|
| BYE |<~~~~~~~~~~~~~~~~~~~~~~~~~~| |
|<=============| | | |
: : : : :
| Fetch | | | |
|--------------------------->| | |
| ValExchange | | | |
|:::::::::::::::::::::::::::::::::::::::::>| |
| ValExchange | | | |
|:::::::::::::::::::::::::::::::::::::::::::::::::::::::>|
: : : : :
| INVITE SIPb | | | |
|=======================================================>|
| | | | |
]]></artwork>
</figure>
<t>Here also more than one PVP transaction will succeed, but this time the originating VIPR domain will receive multiple SIP enhanced routes, without any guidance on which one to use for subsequent calls.</t>
</section>
</section>
<section title="Problems Created by Providers not Using Enhanced SIP">
<t>
In all the diagrams above, the connection to the provider of the PSTN gateway use a SIP profile that does not support enhanced SIP features, like video, wideband audio, realtime text, etc...
Because of this limitation, even if a provider wants to do the right thing, it cannot provide to its customers a SIP route supporting this features.
To be able to participate fully into a VIPR federation, a provider will need to know the enhanced features supported by the endpoint in order to provide SIP routes that can use these features.
</t>
</section>
</section>
<section title="Terminology">
<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"/>.</t>
</section>
<section title="Security Considerations">
<t>TBD</t>
</section>
<section title="IANA Considerations">
<t>TBD</t>
</section>
<section title="Acknowledgements">
<t>This document was written with the xml2rfc tool described in <xref target="RFC2629"/>.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate Requirement Levels</title>
<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>
<date month="March" year="1997"/>
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
<list>
<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
RFC 2119.
</t>
</list>
</t>
<t>
Note that the force of these words is modified by the requirement
level of the document in which they are used.
</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<format octets="4723" target="http://www.rfc-editor.org/rfc/rfc2119.txt" type="TXT"/>
<format octets="17491" target="http://xml.resource.org/public/rfc/html/rfc2119.html" type="HTML"/>
<format octets="5777" target="http://xml.resource.org/public/rfc/xml/rfc2119.xml" type="XML"/>
</reference>
<reference anchor="VIPR-FRAMEWORK">
<front>
<title>Verification Involving PSTN Reachability (VIPR): Framework</title>
<author fullname="Marc Petit-Huguenin" initials="M." surname="Petit-Huguenin">
<organization/>
</author>
<author fullname="Cullen Jennings" initials="C." surname="Jennings">
<organization/>
</author>
<author fullname="Jonathan Rosenberg" initials="J.R." surname="Rosenberg">
<organization/>
</author>
<date day="4" month="October" year="2011"/>
<area>RAI</area>
<workgroup>VIPR WG</workgroup>
<abstract>
<t>
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-petithuguenin-vipr-framework-00"/>
<format target="http://www.ietf.org/internet-drafts/draft-petithuguenin-vipr-framework-00.txt" type="TXT"/>
</reference>
</references>
<references title="Informative References">
<reference anchor="RFC2629">
<front>
<title>Writing I-Ds and RFCs using XML</title>
<author fullname="Marshall T. Rose" initials="M.T." surname="Rose">
<organization>Invisible Worlds, Inc.</organization>
<address>
<postal>
<street>660 York Street</street>
<city>San Francisco</city>
<region>CA</region>
<code>94110</code>
<country>US</country>
</postal>
<phone>+1 415 695 3975</phone>
<email>mrose@not.invisible.net</email>
<uri>http://invisible.net/</uri>
</address>
</author>
<date month="June" year="1999"/>
<area>General</area>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>XML</keyword>
<keyword>Extensible Markup Language</keyword>
<abstract>
<t>This memo presents a technique for using XML
(Extensible Markup Language)
as a source format for documents in the Internet-Drafts (I-Ds) and
Request for Comments (RFC) series.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2629"/>
<format octets="48677" target="http://www.rfc-editor.org/rfc/rfc2629.txt" type="TXT"/>
<format octets="71741" target="http://xml.resource.org/public/rfc/html/rfc2629.html" type="HTML"/>
<format octets="53481" target="http://xml.resource.org/public/rfc/xml/rfc2629.xml" type="XML"/>
</reference>
<reference anchor="RELOAD">
<front>
<title>REsource LOcation And Discovery (RELOAD) Base Protocol</title>
<author fullname="Cullen Jennings" initials="C" surname="Jennings">
<organization/>
</author>
<author fullname="Bruce Lowekamp" initials="B" surname="Lowekamp">
<organization/>
</author>
<author fullname="Eric Rescorla" initials="E" surname="Rescorla">
<organization/>
</author>
<author fullname="Salman Baset" initials="S" surname="Baset">
<organization/>
</author>
<author fullname="Henning Schulzrinne" initials="H" surname="Schulzrinne">
<organization/>
</author>
<date day="4" month="August" year="2011"/>
<abstract>
<t>This specification defines REsource LOcation And Discovery (RELOAD), a peer-to-peer (P2P) signaling protocol for use on the Internet. A P2P signaling protocol provides its clients with an abstract storage and messaging service between a set of cooperating peers that form the overlay network. RELOAD is designed to support a P2P Session Initiation Protocol (P2PSIP) network, but can be utilized by other applications with similar requirements by defining new usages that specify the kinds of data that must be stored for a particular application. RELOAD defines a security model based on a certificate enrollment service that provides unique identities. NAT traversal is a fundamental service of the protocol. RELOAD also allows access from "client" nodes that do not need to route traffic or store data for others.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-p2psip-base-18"/>
<format target="http://www.ietf.org/internet-drafts/draft-ietf-p2psip-base-18.txt" type="TXT"/>
</reference>
<reference anchor="PVP">
<front>
<title>The Public Switched Telephone Network (PSTN) Validation Protocol (PVP)</title>
<author fullname="Jonathan Rosenberg" initials="J" surname="Rosenberg">
<organization/>
</author>
<author fullname="Cullen Jennings" initials="C" surname="Jennings">
<organization/>
</author>
<author fullname="Marc Petit-Huguenin" initials="M" surname="Petit-Huguenin">
<organization/>
</author>
<date day="14" month="June" year="2011"/>
<abstract>
<t>One of the main challenges in inter-domain federation of Session Initiation Protocol (SIP) calls is that many domains continue to utilize phone numbers, and not email-style SIP URI. Consequently, a mechanism is needed that enables secure mappings from phone numbers to domains. The main technical challenge in doing this securely is to verify that the domain in question truly is the "owner" of the phone number. This specification defines the PSTN Validation Protocol (PVP), which can be used by a domain to verify this ownership by means of a forward routability check in the PSTN.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-petithuguenin-vipr-pvp-01"/>
<format target="http://www.ietf.org/internet-drafts/draft-petithuguenin-vipr-pvp-01.txt" type="TXT"/>
</reference>
<reference anchor="SIP">
<front>
<title>SIP: Session Initiation Protocol</title>
<author fullname="J. Rosenberg" initials="J." surname="Rosenberg">
<organization/>
</author>
<author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne">
<organization/>
</author>
<author fullname="G. Camarillo" initials="G." surname="Camarillo">
<organization/>
</author>
<author fullname="A. Johnston" initials="A." surname="Johnston">
<organization/>
</author>
<author fullname="J. Peterson" initials="J." surname="Peterson">
<organization/>
</author>
<author fullname="R. Sparks" initials="R." surname="Sparks">
<organization/>
</author>
<author fullname="M. Handley" initials="M." surname="Handley">
<organization/>
</author>
<author fullname="E. Schooler" initials="E." surname="Schooler">
<organization/>
</author>
<date month="June" year="2002"/>
<abstract>
<t>This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3261"/>
<format octets="647976" target="http://www.rfc-editor.org/rfc/rfc3261.txt" type="TXT"/>
</reference>
</references>
<section title="Release notes">
<t>This section must be removed before publication as an RFC.</t>
<section title="Modifications between draft-petithuguenin-vipr-sip-intermediaries-00 and draft-petithuguenin-vipr-sip-intermediaries-01">
<t>
<list style="symbols">
<t>Added introduction text for the problems created by provider VIPR domains.</t>
</list>
</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 22:23:12 |