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-00 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 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. Normative References . . . . . . . . . . . . . . . . . . . 7 6.2. Informative References . . . . . . . . . . . . . . . . . . 7 Appendix A. Release notes . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 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. 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. Petit-Huguenin Expires April 6, 2012 [Page 7] Internet-Draft VIPR SIP Intermediaries October 2011 [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 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] Appendix A. Release notes This section must be removed before publication as an RFC. Author's Address Marc Petit-Huguenin Stonyfish Email: marc@stonyfish.com Petit-Huguenin Expires April 6, 2012 [Page 8]