Internet DRAFT - draft-petithuguenin-vipr-sip-intermediaries
draft-petithuguenin-vipr-sip-intermediaries
VIPR WG M. Petit-Huguenin
Internet-Draft Stonyfish
Intended status: Standards Track October 4, 2011
Expires: April 6, 2012
Verification Involving PSTN Reachability (VIPR) enabled SIP
Intermediaries
draft-petithuguenin-vipr-sip-intermediaries-01
Abstract
This document presents some of the problems created by SIP
intermediaries inside a VIPR federation.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. 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.
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 6, 2012.
Copyright Notice
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
Petit-Huguenin Expires April 6, 2012 [Page 1]
Internet-Draft VIPR SIP Intermediaries October 2011
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Problems Created by Providers using VIPR as Toll Bypass . 7
1.1.1. Multiple VIPR Domains in the Outgoing Call Path . . . 8
1.1.2. Multiple VIPR Domains in the Incoming Call Path . . . 9
1.2. Problems Created by Providers not Using Enhanced SIP . . . 9
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 10
3. Security Considerations . . . . . . . . . . . . . . . . . . . 10
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Normative References . . . . . . . . . . . . . . . . . . . 10
6.2. Informative References . . . . . . . . . . . . . . . . . . 10
Appendix A. Release notes . . . . . . . . . . . . . . . . . . . . 11
A.1. Modifications between
draft-petithuguenin-vipr-sip-intermediaries-00 and
draft-petithuguenin-vipr-sip-intermediaries-01 . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
Petit-Huguenin Expires April 6, 2012 [Page 2]
Internet-Draft VIPR SIP Intermediaries October 2011
1. Introduction
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 [1]. An example of the interactions
are depicted in the following diagram:
Petit-Huguenin Expires April 6, 2012 [Page 3]
Internet-Draft VIPR SIP Intermediaries October 2011
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:
Petit-Huguenin Expires April 6, 2012 [Page 4]
Internet-Draft VIPR SIP Intermediaries October 2011
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 | | | |
|=======================================================>|
| | | | |
Petit-Huguenin Expires April 6, 2012 [Page 5]
Internet-Draft VIPR SIP Intermediaries October 2011
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:
Petit-Huguenin Expires April 6, 2012 [Page 6]
Internet-Draft VIPR SIP Intermediaries October 2011
1. guaranteeing that providers using VIPR for toll bypassing will
not impede the VIPR federation,
2. 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.
1.1. Problems Created by Providers using VIPR as Toll Bypass
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.
Petit-Huguenin Expires April 6, 2012 [Page 7]
Internet-Draft VIPR SIP Intermediaries October 2011
1.1.1. Multiple VIPR Domains in the Outgoing 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.
Petit-Huguenin Expires April 6, 2012 [Page 8]
Internet-Draft VIPR SIP Intermediaries October 2011
1.1.2. Multiple VIPR Domains in the Incoming Call Path
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.
1.2. Problems Created by Providers not Using Enhanced SIP
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
Petit-Huguenin Expires April 6, 2012 [Page 9]
Internet-Draft VIPR SIP Intermediaries October 2011
provider will need to know the enhanced features supported by the
endpoint in order to provide SIP routes that can use these features.
2. Terminology
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].
3. Security Considerations
TBD
4. IANA Considerations
TBD
5. Acknowledgements
This document was written with the xml2rfc tool described in
[RFC2629].
6. References
6.1. Normative References
[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. Rosenberg,
"Verification Involving PSTN Reachability (VIPR):
Framework", draft-petithuguenin-vipr-framework-00 (work in
progress), October 2011.
6.2. Informative References
[RFC2629] Rose, M., "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", draft-ietf-p2psip-base-18 (work in
Petit-Huguenin Expires April 6, 2012 [Page 10]
Internet-Draft VIPR SIP Intermediaries October 2011
progress), August 2011.
[PVP] Rosenberg, J., Jennings, C., and M. Petit-Huguenin, "The
Public Switched Telephone Network (PSTN) Validation
Protocol (PVP)", draft-petithuguenin-vipr-pvp-01 (work in
progress), 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.
URIs
[1] <http://www.sipforum.org/>
Appendix A. Release notes
This section must be removed before publication as an RFC.
A.1. Modifications between
draft-petithuguenin-vipr-sip-intermediaries-00 and
draft-petithuguenin-vipr-sip-intermediaries-01
o Added introduction text for the problems created by provider VIPR
domains.
Author's Address
Marc Petit-Huguenin
Stonyfish
Email: marc@stonyfish.com
Petit-Huguenin Expires April 6, 2012 [Page 11]
