One document matched: draft-petithuguenin-vipr-sip-intermediaries-00.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-00" 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>
<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>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 22:31:40 |