One document matched: draft-patel-dispatch-cpc-oli-parameter-01.xml
<?xml version="1.0" encoding="UTF-8"?>
<!-- <!DOCTYPE rfc SYSTEM "rfc2629.dtd">-->
<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="no" ?>
<rfc category="std" docName="draft-patel-dispatch-cpc-oli-parameter-01.txt"
ipr="trust200811">
<front>
<title abbrev="CPC and OLI URI Parameters">Uniform Resource Identifier
(URI) Parameters for indicating the Calling Party's Catagory and
Originating Line Identity</title>
<author fullname="Milan Patel" initials="M." surname="Patel">
<organization>Nortel</organization>
<address>
<postal>
<street>Maidenhead Office Park, Westacott Way</street>
<city> Maidenhead</city>
<region>Berkshire, UK</region>
</postal>
<email>milanpa@nortel.com</email>
</address>
</author>
<author fullname="Roland Jesske" initials="R." surname="Jesske">
<organization>Deutsche Telekom</organization>
<address>
<postal>
<street>Heinrich-Hertz-Strasse 3-7</street>
<city>Darmstadt, 64307</city>
<region>Germany</region>
</postal>
<email>r.jesske@telekom.de</email>
</address>
</author>
<author fullname="Martin Dolly" initials="M." surname="Dolly">
<organization>AT&T</organization>
<address>
<postal>
<street>200 Laurel Ave</street>
<city>Middletown, NJ,</city>
<region>US</region>
</postal>
<email>mdolly@att.com</email>
</address>
</author>
<date month="October" year="2009" />
<area>RAI</area>
<workgroup>DISPATCH Working Group</workgroup>
<keyword>CPC</keyword>
<keyword>OLI</keyword>
<keyword>Session Initiation Protocol</keyword>
<abstract>
<t>This document defines two new URI parameters to describe the calling
party's category and toll class of service originating line information
which are parameters also used in SS7 ISUP and other telephony
signalling protocols. The intended use of these URI parameters is for
the tel URI and SIP URI address schemes.</t>
</abstract>
</front>
<middle>
<!-- Introduction -->
<section anchor="sec-intro" title="Introduction">
<t>SS7 ISUP<xref target="ITU-ISUP" /> defines a Calling Party's Category
(CPC) parameter that characterizes the station used to originate a call
and carries other important state that can describe the originating
party. One example of such information is the call may originate from a
payphone; such information can be used by the network to handle the call
in a specific way. When telephone numbers are contained in URIs, such as
the tel URI <xref target="RFC3966" /> or equivalent SIP URI, it may be
desirable to communicate any CPC associated with that telephone number
or, in the context of a call, the party calling from it. This document
proposes a method of carrying CPC data in SIP messages.</t>
<t>In some networks (including North America), the Originating Line
Information (OLI) parameter defined in ANSI ISUP <xref
target="ANSI-ISUP"> </xref> is used to carry information related to the
calling party and the class of service for a call. Legacy multifrequency
(MF) signalling networks carry this information in the ANI II Digits
<eref
target="http://www.nanpa.com/number_resource_info/ani_ii_assignments.html" />.
The call can originate from a multitude of devices or stations. For
example, a coin operated phone or a phone located inside a prison can be
used to originate a call. In such cases, it can be desirable to handle
calls originating from such stations in a specific manner, or to
restrict certain services to the calling party. This document proposes a
method of carrying OLI data in SIP messages.<t>Other use cases may exist
where is it useful to transfer information about the endpoint even when
interworking with the PSTN does not occur. In such cases, the calling
party's catagory or originating line identity can be added when the
calling party is identified by either a tel URI or a SIP URI.</t></t>
<t />
</section>
<!-- Terminology-->
<section anchor="sec-conv" title="Terminology">
<t>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 RFC 2119 <xref
target="RFC2119" />.</t>
</section>
<!--Parameter Definition-->
<section anchor="sec-def" title="Parameter Definitions">
<t>The Calling Party's Category (CPC) and the Originating Line
Information (OLI) are represented as URI parameters for the tel URI
scheme and the SIP URI representation of telephone numbers. The ABNF
<xref target="RFC5234" /> syntax is as follows. The 'par' production is
defined in RFC 3966 <xref target="RFC3966" />. The "/=" syntax indicates
an extension of the production on the left-hand side:<list
style="hanging">
<t>par /= cpc / oli</t>
<t>cpc = cpc-tag "=" cpc-value</t>
<t>oli = oli-tag "=" oli-value</t>
<t>cpc-tag = "cpc"</t>
<t>oli-tag = "isup-oli"</t>
<t>cpc-value = 8*8BIT / "ordinary" / "test" / "operator" /
"payphone" / "unknown" / genvalue</t>
<t>oli-value = 8*8BIT / "hotel" / "prison" / "cellular" /
"cellular-roaming" / genvalue</t>
<t>genvalue = 1*(alphanum / "-" / "." )</t>
</list></t>
<t>The semantics of these CPC and OLI values are described below:<list
style="hanging">
<t>ordinary: The caller has been identified, and has no special
features.</t>
<t>test: This is a test call that has been originated as part of a
maintenance procedure.</t>
<t>operator: The call was generated by an operator position.</t>
<t>payphone: The calling station is a payphone.</t>
<t>unknown: The CPC could not be ascertained.</t>
<t>hotel: The calling station is in a hotel or motel.</t>
<t>prison: The calling station is in a prison.</t>
<t>cellular: The calling station is a radio-telephone operating in
its home network.</t>
<t>cellular-roaming: The calling station is a radio-telephone
roaming in another network.</t>
</list></t>
<t>The 8 bit values are assigned by ITU-T/ANSI <xref
target="ITU-ISUP" /><xref target="ANSI-ISUP" /> and for the OLI, are
binary equivalaents of the decimal codes used in the II digits of the
ANI sequence for in-band signalling system <eref
target="http://www.nanpa.com/number_resource_info/ani_ii_assignments.html" />.</t>
<t>The "cpc" and "isup-oli" URI parameters are optional parameters. At
the most, one "cpc" and/or one "isup-oli" parameter may be included in a
URI of the calling party. In SIP the calling party is generally
identified by the identity given in the From header field, or
alternatively, in the P-Asserted-Identity header field if this is used.
Usage is discussed in the following sections of this document.</t>
<t>An example of the syntax of the "cpc" parameter is given
below:<t>From:
<tel:+17005554141;cpc=payphone>;tag=1928301774</t></t>
<t>Alternatively, the tel URI may be included in the P-Asserted-Identity
header field <xref target="RFC3325" />:<t>P-Asserted-Identity: <tel:
+17005554141;cpc=payphone></t></t>
<t>The "isup-oli" URI parameter usage is given in the following example,
which uses the SIP URI representation of telephone numbers: <t>From:
<sip:
+1700554141@example.com;isup-oli=00011101>;tag=1928301774</t><t>The
"isup-oli" parameter with value 00011101 indicates that the device that
the call is initiated from is located within a prison. An "isup-oli"
with value "prison" is equally valid.</t></t>
<t>For the case where a call is originared by a SIP UA where the caller
is identified by a SIP URI that does not contain a telephone number,
"isup-oli" URI parameter usage is given in the following example, which
uses the SIP URI representation of telephone numbers:
<t>P-Asserted-Identity: <sip:
alice@example.com;isup-oli=cellular></t><t>The "isup-oli" parameter
with value "cellular" indicates that the device that the call is
initiated from is a mobile device operating in its home cellular
network.</t></t>
</section>
<!-- Usage-->
<section anchor="sec-usage" title="Usage">
<t>The CPC and OLI are generally useful only when describing the
originator of a telephone call or the station from where a telephone
call is originated. Therefore, when this parameter is used in an
application such as SIP, it is recommended that the parameter be applied
to URIs that characterize the originator of a call (such as a SIP URI or
tel URI in the P-Asserted-Identity header field or the From header field
of a SIP message). Note that many Calling Party's Category values from
the PSTN are intentionally excluded from the "cpc" parameter as they are
either meaningless outside of the PSTN or can be represented using
another existing concept. For example, the language of an operator can
be expressed more richly using the Accept-Language header in SIP than in
the "cpc" parameter. Similarly the priority of a call is a
characteristic of the call and not the calling party.</t>
<t>It is anticipated that "cpc" and "isup-oli" URI parameters will be
used primarily by gateways that interwork ISUP or ANI II networks with
SIP networks. However, scenarios where interworking with the PSTN does
not occur are not precluded. Various SIP network intermediaries might
consult the CPC or OLI information as they make routing decisions,
although no specific behavior is prescribed in this document. While no
specific mapping of the various ISUP parameters that contain CPC or OLI
data is offered in this document, creating such a mapping would be
trivial.</t>
<t>While the CPC and OLI could be conveyed using the ISUP tunneling
mechanism described in RFC 3372 <xref target="RFC3372" />, this
technique is widely regarded by the implementation community as overkill
for the problem of conveying CPC and OLI information. For example, the
"cpc" and "isup-oli" parameters provides a convenient way for SIP
intermediaries to make routing decisions based on the CPC and OLI
information without having to implement an ISUP parser. The "cpc" and
"isup-oli" URI parameters provide a simple, convenient form of CPC and
OLI interoperability of SIP with ISUP and ANI II, which is otherwise
poorly addressed in RFC 3372<xref target="RFC3372" />. Indeed when a SIP
intermediary makes routing decisions for a call where both the
originating and the terminating gateways natively use ANI II, the ISUP
tunneling approach is especially unattractive, requiring each of the
three devices to perform a translation into an otherwise unneeded PSTN
protocol.</t>
<t>If the "cpc" URI parameter is not present, consumers of the CPC
information should treat the URI as if it specified a CPC of "ordinary".
If the "isup-oli" URI parameter is not present, consumers of the OLI
information should treat the URI as if no OLI information is provided.
If a SIP intermediary does not support the "cpc" or "isup-oli" URI
parameters and receives a SIP message where the calling party URI in the
From or P-Asserted-header fields includes a "cpc" or "isup-oli" URI
parameter, then the SIP intermediary silently ignores the URI parameter
in accordance with RFC 3261<xref target="RFC3261" />.</t>
<t>At most, one instance of the "cpc" parameter and/or one instance of
the "isup-oli" parameter can be associated with a particular URI within
a SIP request. It is recommended that the "cpc" and "oli" URI parameters
are associated with URIs included in the P-Asserted-Identity header
field. Where the P-Asserted-Identity header field is not supported or
included, another header field used to carry a URI to characterize the
originator of a call may be used. One example of such a header field is
the From header field. The following section discusses further the
motivation behind this recommendation. </t>
</section>
<!-- Security Considerations -->
<section anchor="sec-security" title="Security Considerations">
<t>There are three potential risks specific to the information provided
by the Calling Party's Category or Originating Line Identity:<t>-
leakage of potentially private information; </t><t>- the threat of
tampering with the CPC or OLI to add false CPC or OLI values; and
</t><t>- the threat of tampering with the CPC or OLI to remove actual
CPC or OLI values.</t></t>
<t>The information contained in the "cpc" or "isup-oli" parameter may be
of a private nature, and it may not be appropriate for this value to be
revealed to the destination user (typically it would not be so revealed
in the PSTN). However, the calling party's category is often
discoverable or easily guessable from the calling party's phone number.
For that reason it is unlikely that this information is significantly
more privacy sensitive than the telephone number itself. The same
techniques used to provide complete or partial telephone number privacy
in SIP are appropriate to apply to the "cpc" and "isup-oli" parameters
as well. For more information about privacy issues in SIP see RFC
3323<xref target="RFC3323" />. The mechanism described in RFC 3325 <xref
target="RFC3325" /> may also be relevant for maintaining partial privacy
or the CPC or OLI within a trusted administrative domain or federation
of domains as described in RFC 3324<xref target="RFC3324" />.</t>
<t>Making a call with a falsified CPC or OLI (i.e. "operator") could
allow the caller to gain access to resources or information not
otherwise available. Likewise removing an "undesirable" CPC or OLI value
(ex: prison or hotel) could allow the caller to bypass various
restrictions in the telephone network. For that reason, agents which
expect CPC or OLI values SHOULD take care to insure the integrity and
authenticity of the "cpc" or "isup-oli" URI parameter. The RECOMMENDED
mechanism to protect the entire calling party address along with the
"cpc" or "isup-oli" URI parameter is the SIP Identity mechanism <xref
target="RFC4474"> </xref> . Alternatively, agents within an
administrative domain or federation of domains MAY use the mechanism
described in RFC 3325<xref target="RFC3325" /> to place the "cpc" or
"isup-oli" URI parameter in a P-Asserted-Identity header field. When
such mechanism is used, the "cpc" or "isup-oli" URI parameter is added
by a network entity or SIP intermediary if knowledge of the calling
party's category or originating line identity (class of service) is
known.</t>
<t>When the end-device, acting as a UAC originating a call, is not
trusted, the value of a "cpc" or "isup-oli" URI parameter included by
the UAC may be removed or modified by a trusted network entity. If a
request containing CPC or OLI is sent towards a non-trusted entity, this
information should be removed. </t>
<t>The SIP Identity mechanism provides a signature over the URI in the
From header field of a SIP request. It can sign a SIP URI or a tel URI
alone or a tel URI embedded in a SIP or SIPS URI, but it provides
stronger protection against tampering when the tel URI is embedded in a
SIP or SIPS URI. Because there is no direct correlation between a tel
URI and an Internet domain, the receiver can use a list of domains from
which it will trust CPC or OLI information, or a list of root
certificates which are associated with trusting CPC or OLI
information.</t>
<t>Otherwise, this mechanism adds no new security considerations to
those discussed in RFC 3261<xref target="RFC3261" />.</t>
</section>
<!--IANA COnsiderations-->
<section anchor="sec:IANA" title="IANA Considerations">
<t>This document extends the registry of URI parameters for the Tel URI
and SIP URI as defined RFC 3969<xref target="RFC3969" /> and RFC
5341<xref target="RFC5341" />. Two new URI parameters for the Tel URI
and SIP URI schemes are defined in this document as follows:</t>
<t>Parameter Name: cpc, isup-oli</t>
<t>Predefined Values: Yes</t>
<t>Reference: This document</t>
</section>
<!-- Contributors and Acknowledgements -->
<section anchor="sec-acks" title="Acknowledgements">
<t>The original version of this document was written by Jon Peterson as
a result of spliiting the appendix from draft-ietf-sip-privacy-04 and
subsequently authored by Rohan Mahy.</t>
<t>This document is based on draft-mahy-iptel-cpc-06.</t>
</section>
</middle>
<back>
<references title="Normative References">
<!--Key words for use in RFCs to Indicate Requirement Levels-->
<?rfc include="reference.RFC.2119"?>
<!--The tel URI for Telephone Numbers-->
<?rfc include="reference.RFC.3966"?>
<!--ABNF-->
<?rfc include="reference.RFC.5234"?>
<!--IANA tel URI parameter-->
<?rfc include="reference.RFC.3969"?>
<!--IANA SIP URI parameter-->
<?rfc include="reference.RFC.5341"?>
<!--SIP-->
<?rfc include="reference.RFC.3261"?>
<reference anchor="ITU-ISUP" target="http://www.itu.int">
<front>
<title>Recommendation Q.763: Signalling System No. 7: ISDN user part
formats and codes</title>
<author>
<organization abbrev="ITU-T">International Telecommunications
Union</organization>
</author>
<date month="December" year="1999" />
<seriesInfo name="ITU-T" value="Q.763" />
</front>
</reference>
</references>
<references title="Informative References">
<!-- -->
<!--Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)-->
<?rfc include="reference.RFC.4474"?>
<reference anchor="ANSI-ISUP" target="http://www.ansi.org">
<front>
<title>ANSI T1.113-2000, Signaling System No. 7, ISDN User
Part</title>
<author>
<organization abbrev="ANSI">American National Standards
Institute</organization>
</author>
<date year="2000" />
<seriesInfo name="ANSI" value="T1.113" />
</front>
</reference>
<!-- Private extensions to SIP for asserted identity within trusted networks-->
<?rfc include="reference.RFC.3325"?>
<!-- SIP-T-->
<?rfc include="reference.RFC.3372"?>
<!--A Privacy Mechanism for SIP-->
<?rfc include="reference.RFC.3323"?>
<!--Short Term Requirements for Network Asserted Identity-->
<?rfc include="reference.RFC.3324"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 21:35:45 |