Internet DRAFT - draft-berg-ieprep-sip-isup-gap-analysis
draft-berg-ieprep-sip-isup-gap-analysis
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]
