Internet Engineering Task Force Dennis Berg INTERNET DRAFT DynCorp draft-berg-ieprep-sip-isup-gap-analysis-00 Expires: December 2002 June 23, 2002 ISUP<>SIP Gap Analysis for IEPREP Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet Drafts. 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 in other than as "work in progress." The list of current Internet-Drafts can be accessed a http://www.ietf.org/ietf/lid-abstracts.text. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Copyright (c) Internet Society 2002. All rights reserved. Reproduction or translation of the complete documents, but not of extracts, including this notice, if freely permitted. Abstract This document begins a gap analysis of SIP-ISUP mapping from the perspective of ieprep. Draft-ietf-sipping-isup-02 does not address mapping/translation for two ISUP IAM parameters of specific interest to ieprep: the mandatory Calling Party's Category and the optional Precedence parameters. On the assumption that both of these parameters should be mapped/translated in SIP-ISUP interworking, this ID begins with the proposal for a new SIP Resource-Priority header in work in progress in ieprep. Several variations on the proposed new header are formulated and assessed for use in mapping/translating the two IAM parameters. The ID concludes that either a single header with namespace differentiation of instances or two distinct headers would meet the needs of ieprep. It is recommended that this choice be made and reflected into draft-ietf-sipping-isup-02. Berg Expires - December 2002 [page 1] Internet-Draft SIP-ISUP Gap Analysis for ieprep June 2002 Table of Contents 1. Introduction.......................................3 2. ISUP-SIP Mapping and Translation...................3 2.1 SIP INVITE to ISUP IAM Mapping....................4 2.2 ISUP IAM Mapping to SIP INVITE....................4 2.3 Mandatory IAM Parameter of CPC....................5 2.4 Optional IAM Parameter of Precedence..............6 3. Candidates for IAM CPC and Precedence Parameter to SIP Mapping/Translation...................................6 4. Option 1 - One Header, Separate Namespaces.........7 4.1 Session-Type Header Syntax........................7 4.2 Session-Type Header Semantics.....................7 4.3 Mapping CPC and Precedence Parameters to Session Type Header................................................7 5. Option 2 - Two Headers.............................9 6. Option 3 - One Header, Same Namespace..............9 6. Conclusions - One Header, Same Namespace..........10 8. References........................................10 9. Acknowledgements.. ...............................10 10. Author's Address.................................10 Berg Expires - December 2002 [page 2] Internet-Draft SIP-ISUP Gap Analysis for ieprep June 2002 1. Introduction [1] presents a scheme for SIP-ISUP mapping and translation. The ieprep WG has an interest in ensuring that [1] takes into account the needs of internet emergency preparedness is specifying the SIP-ISUP mapping/translation. This ID begins a gap analysis of SIP-ISUP mapping from the perspective of ieprep. It first reviews [1] with attention to its position on mapping/translation for two ISUP IAM parameters of specific interest to ieprep: the mandatory Calling Party's Category and the optional Precedence parameters. In both cases, [1] does not support a mapping/translation. On the assumption that both of these parameters should be mapped/translated in SIP-ISUP interworking, this ID begins with the proposal for a new SIP Resource-Priority header in [4] and [5]. Several variations on the proposed new header are formulated and assessed for use in mapping/translating the two IAM parameters. The ID concludes that a choice should be made between the alternatives found viable and that this choice should be reflected into [1]. 2. ISUP-SIP Mapping and Translation [1] works within the following three categories: - Mapping of ISUP parameters into SIP headers - Translation between ISUP parameters and SIP headers - Encapsulation of entire ISUP IAM within a SIP message body To facilitate "SIP bridging" There cannot be interworking of SIP and ISUP without some translation, and translation cannot occur unless the requisite mapping has been made. The question is "What amount of mapping/translation is sufficient?" Consider the two cases: ISUP to SIP. What level of mapping/translation should occur and to what extent can the remainder of the ISUP information to left to encapsulation? SIP to ISUP. How much mapping/translation should occur and to what extent can the remainder of the ISUP parameters be left or the MGC to populate based upon local policy and defaults? [1] states the following general policy on ISUP to SIP mapping: Mapping/translation should be performed to the extent that having ISUP parameters mapped/translated to SIP headers allows for more efficient processing of SIP messages by SIP nodes than otherwise would occur if the SIP nodes had to parse the encapsulated IAM: "This mapping should occur so that SIP endpoints that are not capable of parsing the encapsulated ISUP message can have the information available in the SIP headers." Berg Expires - December 2002 [page 3] Internet-Draft SIP-ISUP Gap Analysis for ieprep June 2002 2.1 SIP INVITE to ISUP IAM Mapping For the INVITE to IAM mapping, [1] cites the five mandatory IAM parameters and 29 optional parameters, and takes the position concerning the optional parameters that "each of these parameters need not be translated in order to achieve the goals of SIP-ISUP mapping". No position is stated on whether there is a need to translate all of the IAM mandatory parameters, but concerning the five mandatory parameters, the document offers the following: 1. Called Party Number (CPN) - gives procedures for determining the CPN from the parameters present in the SIP INVITE 2. Nature of Connection Indicator (NCI) - states that "gateways should use default values for mandatory ISUP parameters that are not derived from translation or encapsulation (such as NCI..."(6.2.1.1) 3. Forward Call Indicators (FCI) - states position that SIP<-> ISUP should not be considered a case of interworking, because SIP networks are intended to be at least as feature-rich as ISUP networks 4. Calling Party's Category (CPC) - nothing stated 5. Transmission Medium Requirement (TMR) or User Service Information (USI) or both (ISUP-variant dependent) - states that "gateways should use default values for mandatory ISUP parameters that are not derived from translation or encapsulation (such as ...TMR..."(6.2.1.1). It should be noted that [1] either fails to recommend the default values or assumes that these values will be left to local policy. The NCI parameter is used to provide information on the circuit specified in the CIC parameter. For SIP to ISUP, nothing in the SIP INVITE should bear on this value; the MGC generating the IAM would populate this parameter based upon its knowledge of the PSTN circuit in the next leg of the call path (but are there any transmission characteristics of the IP network that would bear upon whether and how the MGC should specify satellite circuits or continuity checks?) Mapping/translation of the TMR parameter is for further study. The CPC parameter is the only mandatory IAM parameter for which no comment or guidance is given. Concerning optional IAM parameters, [1], as noted, recognizes that not all optional parameters need to be mapped and translated. The document recommends that "immediate usefulness" can be derived from translating the following: - Calling Party's Number (CIN) - mapped to the "From" SIP header - Transit Network Selection (TNS) - mapped to a CIC in the Request URI (states that this parameter should be used when the CPN is in international format) Berg Expires - December 2002 [page 4] Internet-Draft SIP-ISUP Gap Analysis for ieprep June 2002 - Carrier Identification Parameter (CIP, in ANSI networks) mapped to a CIC in the Request-URI (states that this parameter should be used only when the CPN is not in international format) - Original Called Number (OCN) - nothing stated - Generic Digits (variant: Generic Address Parameter - GAP) - populated from the tel URL The optional IAM parameter "precedence" is not explicitly addressed, but implicitly is included in a category of "not immediately useful" for translation. 2.2. ISUP IAM to SIP INVITE Mapping [1] treats the case of IAM to INVITE mapping similarly: 1. Called Party Number (CPN) - gives procedures for mapping the CPN To several possible INVITE parameters 2. Nature of Connection Indicator (NCI) - nothing stated. 3. Forward Call Indicators (FCI) - nothing stated 4. Calling Party's Category (CPC) - nothing stated 5. Transmission Medium Requirement (TMR) - nothing stated Concerning optional IAM parameters, [1] specifies only one mapping: - Calling Party's Number (CIN) - mapped to the "From" SIP header 2.3 Mandatory IAM Parameter of CPC Just as it is not necessary to translate all ISUP IAM optional parameters into SIP headers, it may not be necessary to map and translate all of the mandatory parameters in the ISUP IAM. What makes sense as a mandatory parameter in an ISDN network may not make sense as a mandatory parameter in a SIP IP-based network. One of the mandatory ISUP parameters that fails to receive notice in [1], the IAM CPC, is Used for the Government Emergency Telecommunications Service (GETS) to carry the classmark of an National Security Emergency Preparedness NSEP)call, i.e., the classmark qualifying the call for GETS features. This value of the CPC is typically referred to as the "HPC Codepoint", and distinguishes the call from the normal call, which has a CPC value of "ordinary subscriber". Encapsulation is sufficient to preserve GETS in the terminating PSTN network in a case of SIP bridging. And, as noted, the CPC's status as a mandatory ISUP IAM parameter is not sufficient reason to map and translate it into a SIP header. However, if a SIP network is to differentiate GETS sessions and provide these sessions with any special treatment, the CPC should be mapped to a SIP header. Furthermore, if SIP networks provide an enhanced level of service for NSEP calls originated in those networks, translation of the NSEP session identifier from SIP to the IAM CPC would establish an interworking in which the NSEP session originating in the SIP network could receive GETS in an ISUP network. Berg Expires - December 2002 [page 5] Internet-Draft SIP-ISUP Gap Analysis for ieprep June 2002 This ID does not argue the case for providing unique service to NSEP calls in SIP networks, but instead relies upon [2] and [3] to establish this position. If their conclusions are accepted, then an INVITE-IAM mapping/translation of the CPC parameter is required. 2.4. Optional IAM Parameter of Precedence The precedence parameter traditionally has been used in defense networks in conjunction with a preemption service. However, as GETS is extended to wireless networks to create a Wireless Priority Service WPS), five priority levels are being introduced for use in providing priority access to radio resources. Thus WPS requires a means to transfer the priority level of a WPS call through both wireless and wwireline public networks. Currently the wireless industry is considering use of the precedence parameter for this purpose. If this solution were adopted, then the value of mapping and translating the precedence parameter between SIP and ISUP would need to be considered for the same type of reasons as those for translating the NSEP value of the CPC for GETS. Apart from the possible use of the precedence parameter for WPS, however, certain private networks of the US Government employ the precedence parameter. To support the migration of such networks to IP technology, specification of an analogous parameter for either completely IP-based private networks or interworking IP-based and circuit-switched networks could be considered. In a SIP-ISUP interworking scenario, the choice between mapping/ translating and encapsulating depends upon the need for applying priority levels in the SIP network. This ID does not argue the case for providing unique service to calls in respect to precedence level in SIP networks, but instead relies upon [2] and [3] and [4] to establish this position. If their conclusions are accepted, then an INVITE-IAM mapping/translation of the precedence parameter is required. 2. Candidates for IAM CPC and Precedence Parameter to SIP Mapping/ Translation A candidate target SIP header has been proposed in [5] and [6]. These IDs proposes a new SIP header that would identify a session's priority in respect to the assignment of resources. A question, however, is whether or not one SIP header can serve as the mapping/translation target of both the IAM mandatory CPC and the IAM optional precedence parameters. There are three basic options for adapting the resource-priority header as a mapping target for CPC and precedence parameters: Berg Expires - December 2002 [page 6] Internet-Draft SIP-ISUP Gap Analysis for ieprep June 2002 - Option 1: Map each of the two IAM parameters to a separate namespace" using one header - Option 2: Map each of the two IAM parameters to a separate SIP header - Option 3: Map the values of both of the two IAM parameters to a single "namespace" using one header. 4. Option 1 - One Header, Separate Namespaces The name of the header in the single header option should be adjusted to align more closely with the CPC name. The CPC header contains information on the caller, which then transitively flows to the call type. I.e., a call from a person performing NSEP functions is an NSEP call. The norm is a call from an "ordinary subscriber". Since the same originator may select a number of different call types and the real interest is on the call type, the proposal here is to focus on the type of session and use the name "session-type". Additionally, the header name has been changed to leave neutral the issue of what type of special treatment the network might be afforded to a session of a specific type. The originally proposed name "resource-priority" takes a position on the type-specific treatment. 4.1 Session-Type Header Syntax The syntax for the session-type general header is adapted from [5] with minor terminology variation: Session-Type _ "Session-Type" HCOLON Session-value Value _ namespace "." type namespace _ alphanum / "-" type _ alphanum / "-" The specification of the header, but not the header itself, adds an element to specify the ordering of the types: ordination _ alphanum / ">", "," 4.2 Session-Type Header Semantics For further study. 4.3. Mapping CPC and Precedence Parameters to Session-Type Header In Option 1, the CPC mapping/translation would take the following form: - namespace: calling_party_category - type: unknown, ordinary, nsep - ordination: nsep,ordinary,unknown Note that the ordination does not prioritize the several session types, leaving this to policy. Berg Expires - December 2002 [page 7] Internet-Draft SIP-ISUP Gap Analysis for ieprep June 2002 This namespace maps to, and would allow translation of, the ISUP IAM Calling Party's Category (CPC): Calling party's category unknown = unknown Ordinary calling subscriber = ordinary National Security & Emergency Preparedness Call = NSEP Other currently defined CPC values might also be included, after review of their currency and appropriateness: Emergency service call in progress = emergencyinprogress High-priority call indication = highpriority Spare = spare1 - spare16 Network-specific use = network1 - network16 Reserved for expansion = reserved1 In the case of the precedence parameter, Option 1 mapping/translation has some complexities. The ISUP IAM precedence parameter contains two octets, with octet 1 carrying five precedence levels plus information for a "look ahead for busy" (LFB) attribute. Octet 2 is titled Multilevel Precedence and Preemption " (MLPP) and contains just one specified value "Defense Switched Network", with the remaining values being spare. Thus there are four parameters in this umbrella parameter, while the session-type header has only two parameters. This complexity results in several alternatives, even assuming that the LFB parameter does not require translation, but would be passed through encapsulation in a SIP-ISUP bridging situation: a) - namespace: precedence - type: priority1, priority2, priority3, priority4, priority 5 - ordination: priority1>priority2>priority3>priority4>priority5 b) - namespace: mlpp - type: flash-override, flash, immediate, priority, routine - ordination: flash-override>flash>immediate>priority>routine c) - namespace: mlpp_dsn - type: flash-override, flash, immediate, priority, routine - ordination: flash-override>flash>immediate>priority>routine There appears to be no reason to adopt b) rather than c). If ISUP were to specify additional values for the MLPP octet of the precedence parameter, additional "mlpp_x" namespaces could be adopted. The more interesting choice is between a) and c) because it brings in the protocol/policy issue. If only one instantiation of a five-level precedence is allowed, for policy or technical reasons, then a) should be the choice. If, as apparently envisioned by the IAM precedence parameter, multiple "services" might each use a five-level priority set, then b) should be the choice. Berg Expires - December 2002 [page 8] Internet-Draft SIP-ISUP Gap Analysis for ieprep June 2002 5. Option 2 - Two Headers Option two simply uses two different headers. The header used for mapping/translating the precedence parameter is similar to c) in Option 1. In this case, however, the header would have its name changed to simply "precedence" and the "ordination" element would always require a prioritization: Precedence _ "Precedence" HCOLON precedence-value Value _ namespace "." type namespace _ alphanum / "-" type _ alphanum / "-" ordination _ alphanum / ">" The header used for mapping/translating the IAM CPC would retain the name "session-type", but be simplified be deleting the "namespace" element and one of the "ordination" values: Session-Type _ "Session-Type" HCOLON Session-value Value _ type type _ alphanum / "-" ordination _ alphanum / "," Session-Type would be a set of the unordered types: {unknown,ordinary, NSEP,etc.} 6. Option 3 - One Header, Same Namespace [5] proposes an option which attempts to combine the needs of mapping/ translating the NSEP value of the CPC with the five priority levels of the precedence parameter. This ID takes the position that if such an approach is pursued, then the resource-priority header does not require differentiating domains by a "namespace" element. Instead, the header syntax should be the same as option 2 above: - precedence - "precedence" HCOLON precedence-value - value - type - type - alphanum / "-" - ordination - alphanum / ">" Precedence would be a set of the unordered types: {priority1>priority2>priority3>priority4>priority5>priority6}. The mapping/translation for SIP-ISUP would then be: - priority1: CPC value of "NSEP Call" - priority2: precedence value of flash override/dsn - priority3: precedence value of flash/dsn - priority4: precedence value of immediate/dsn - priority5: precedence value of priority/dsn - priority6: precedence value of routine/dsn Berg Expires - December 2002 [page 9] Internet-Draft SIP-ISUP Gap Analysis for ieprep June 2002 This set of precedence values, however, does not contain a separate priority level for "ordinary subscriber" and "unknown". These two values could be mapped/translated to priority6, or, to accommodate these two CPC values, the precedence set could be expanded: - priority7: CPC value of "ordinary subscriber" - priority8: CPC value of "unknown" Such an expansion is subject to the objection: why should these two CPC categories be lower than "routine/dsn"? This anomaly results from the fact that this approach attempts to unify two previously separate domains: the "public" network and a "private, dsn" network. Also, the anomaly highlights a problem for the candidate WPS option of attempting to reuse the precedence parameter to carry WPS priority levels. In the WPS scheme for using the precedence parameter to carry the priority level of a session, the priority levels are a second element of information in addition to the "NSEP Call" information. Thus, the "NSEP Call" identifier and the priority level are related like "namespace.type". From this point of view, the priority levels 2-5 would all be higher than the priority level for either "ordinary subscriber" or "unknown". For the dsn use of priority levels 2-6, however, the priority level of "routine" means the same thing as "ordinary subscriber" and so both should have the same priority level. 7. Conclusion Option 3, a single header and single namespace, should be discarded. The choice between options 1 and 2 depends upon whether a single header type, with multiple namespaces and multiple instances of the header for one communication session is preferred over providing the same information in two distinct header types, one of which, the Session-Type mapping the IAM CPC, would not allow for multiple domains (i.e., namespaces). >From the perspective of accommodating the GETS/WPS need, either would suffice. Option 1 would require two instances of the same header: - session_type: calling_party_category.nsep - session_type: nsep.type Option 2 would require two headers: - session_type: nsep - precedence: nsep.type >From the perspective of accommodating the DSN need, again either would suffice. Option 1 would require two instances of the same header: - session_type: calling_party_category.ordinary - session_type: dsn.type Berg Expires - December 2002 [page 10] Internet-Draft SIP-ISUP Gap Analysis for ieprep June 2002 Option 2 would require two distinct headers: - session_type: ordinary - precedence: dsn.type It is recommended that a decision be made between Options 1 and 2 and this position reflected into [1]. 8. References [1] Camarillo, G., and Roach, A., and Peterson, J., and Ong, L., "ISUP to SIP Mapping", draft-ietf-sipping-isup-02, 31 May 2002 [2] Carlberg, Ken, and Brown, Ian, "Framework for Support IEPS in IP Telephony", draft-ietf-ieprep-freamwowrk-00 (work in progress) May 14, 2002 [3] Folts, Hal, and Beard, Cory, "Requirements for Emergency Telecommunications Capabilities in the Internet", draft-ietf-ieprep- requirements-00 (work in progress) June, 2002 [4] Pierce, Mike, and Choi, Don, "Examples of Provision of Preferential Treatment of Voice over IP", draft-pierce-sipping-pref- treat-examples-00 (work in progress) April, 2002 [5] Polk, James, and Schulzrinne, Hennig, "SIP Communications Resource Priority Header", draft-polk-sipping-resource-01 (work in progress) March 2, 2002 [6] Schulzrinne, Hennig, "Requirements for Resource Priority Mechanisms for the Session Initiation Protocol", draft-schulzrinne ieprep-resource-req-01 (work in progress) April 21, 2002 9. Acknowledgements Janet Gunn provided support for this draft. 10. Author's Address Dennis Berg, Sr. Manager, Engineering DynCorp Systems and Solutions 15000 Conference Center Drive Chantilly, VA 20151 Email: dennis.berg@dyncorp.com 10. Copyright "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this Berg Expires - December 2002 [page 10] Internet-Draft SIP-ISUP Gap Analysis for ieprep June 2002 document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided as an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OR MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Berg Expires - December 2002 [page 11]