| VIPR WG | M. Petit-Huguenin |
| Internet-Draft | Stonyfish |
| Intended status: Standards Track | October 04, 2011 |
| Expires: April 06, 2012 |
Verification Involving PSTN Reachability (VIPR) enabled SIP Intermediaries
draft-petithuguenin-vipr-sip-intermediaries-01
This document presents some of the problems created by SIP intermediaries inside a VIPR federation.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on April 06, 2012.
Copyright (c) 2011 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document may not be modified, and derivative works of it may not be created, except to format it for publication as an RFC or to translate it into languages other than English.
The [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:
(For all the diagrams in this document, "--->" means a [RELOAD] transaction, "~~~~>" a PSTN transaction, ":::>" a [PVP] transaction and "===>" a [SIP] transaction).
DomainA RELOAD DomainB
| | Store |
| |<-----------|
: : :
| SETUP | |
|~~~~~~~~~~~~~~~~~~~~~~~~~>|
: : :
| | DISC |
|<~~~~~~~~~~~~~~~~~~~~~~~~~|
: : :
| Fetch | |
|------------>| |
| ValExchange | |
|:::::::::::::::::::::::::>|
: : :
| INVITE | |
|=========================>|
| | |
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 SIP Forum. An example of the interactions are depicted in the following diagram:
DomainA GatewayA RELOAD DomainB
| | | Store |
| | |<-----------|
: : : :
| INVITE | | |
|============>| SETUP | |
| |~~~~~~~~~~~~~~~~~~~~~~~~~>|
: : : :
| | | DISC |
| BYE |<~~~~~~~~~~~~~~~~~~~~~~~~~|
|<============| | |
: : : :
| Fetch | | |
|-------------------------->| |
| ValExchange | | |
|:::::::::::::::::::::::::::::::::::::::>|
: : : :
| INVITE | | |
|=======================================>|
| | | |
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.
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:
DomainA Provider RELOAD DomainB
| | | Store |
| | |<-----------|
: : : :
| INVITE SIPconnect | | |
|==================>| SETUP | |
| |~~~~~~~~~~~~~~~~~~~~~~~~~>|
: : : :
| | | DISC |
| BYE |<~~~~~~~~~~~~~~~~~~~~~~~~~|
|<==================| | |
: : : :
| Fetch | | |
|-------------------------------->| |
| ValExchange | | |
|:::::::::::::::::::::::::::::::::::::::::::::>|
: : : :
| INVITE SIPbeyond | | |
|=============================================>|
| | | |
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:
DomainA ProviderX RELOAD ProviderY DomainB
| | | | Store |
| | |<--------------------------|
: : : : :
| INVITE SIPc | | | |
|=============>| SETUP | | |
| |~~~~~~~~~~~~~~~~~~~~~~~~~~>| INVITE SIPc |
| | | |============>|
: : : : :
| | | | BYE |
| | | DISC |<============|
| BYE |<~~~~~~~~~~~~~~~~~~~~~~~~~~| |
|<=============| | | |
: : : : :
| Fetch | | | |
|--------------------------->| | |
| ValExchange | | | |
|:::::::::::::::::::::::::::::::::::::::::::::::::::::::>|
: : : : :
| INVITE SIPb | | | |
|=======================================================>|
| | | | |
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:
DomainA ProviderX RELOAD ProviderY DomainB
| | | | Store |
| | |<--------------------------|
: : : : :
| INVITE SIPc | | | |
|=============>| INVITE SIPc | | |
| |==========================>| INVITE SIPc |
| | | |============>|
: : : : :
| | | | BYE |
| | | BYE |<============|
| BYE |<==========================| |
|<=============| | | |
: : : : :
| Fetch | | | |
|--------------------------->| | |
| ValExchange | | | |
|:::::::::::::::::::::::::::::::::::::::::::::::::::::::>|
: : : : :
| INVITE SIPb | | | |
|=======================================================>|
| | | | |
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.
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:
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.
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:
DomainA ProviderX RELOAD ProviderY DomainB
| | | | Store |
| | |<--------------------------|
: : : : :
| INVITE SIPc | | | |
|=============>| SETUP | | |
| |~~~~~~~~~~~~~~~~~~~~~~~~~~>| INVITE SIPc |
| | | |============>|
: : : : :
| | | | BYE |
| | | DISC |<============|
| BYE |<~~~~~~~~~~~~~~~~~~~~~~~~~~| |
|<=============| | | |
: : : : :
| | Fetch | | |
| |------------>| | |
| | ValExchange | | |
| |::::::::::::::::::::::::::::::::::::::::>|
: : : : :
| Fetch | | | |
|--------------------------->| | |
| ValExchange | | | |
|:::::::::::::::::::::::::::::::::::::::::::::::::::::::>|
: : : : :
| INVITE SIPb | | | |
|=======================================================>|
| | | | |
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.
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:
DomainA ProviderX RELOAD ProviderY DomainB
| | | Store | |
| | |<------------| |
| | | | Store |
| | |<--------------------------|
: : : : :
| INVITE SIPc | | | |
|=============>| SETUP | | |
| |~~~~~~~~~~~~~~~~~~~~~~~~~~>| INVITE SIPc |
| | | |============>|
: : : : :
| | | | BYE |
| | | DISC |<============|
| BYE |<~~~~~~~~~~~~~~~~~~~~~~~~~~| |
|<=============| | | |
: : : : :
| Fetch | | | |
|--------------------------->| | |
| ValExchange | | | |
|:::::::::::::::::::::::::::::::::::::::::>| |
| ValExchange | | | |
|:::::::::::::::::::::::::::::::::::::::::::::::::::::::>|
: : : : :
| INVITE SIPb | | | |
|=======================================================>|
| | | | |
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.
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.
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 [RFC2119].
TBD
TBD
This document was written with the xml2rfc tool described in [RFC2629].
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [VIPR-FRAMEWORK] | Petit-Huguenin, M., Jennings, C. and J.R. Rosenberg, "Verification Involving PSTN Reachability (VIPR): Framework", Internet-Draft draft-petithuguenin-vipr-framework-00, October 2011. |
| [RFC2629] | Rose, M.T., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. |
| [RELOAD] | Jennings, C, Lowekamp, B, Rescorla, E, Baset, S and H Schulzrinne, "REsource LOcation And Discovery (RELOAD) Base Protocol", Internet-Draft draft-ietf-p2psip-base-18, August 2011. |
| [PVP] | Rosenberg, J, Jennings, C and M Petit-Huguenin, "The Public Switched Telephone Network (PSTN) Validation Protocol (PVP)", Internet-Draft draft-petithuguenin-vipr-pvp-01, June 2011. |
| [SIP] | 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. |
This section must be removed before publication as an RFC.