Internet Engineering Task Force J. Elwell Internet Draft Siemens draft-elwell-sipping-identity-interworking-00.txt Alcatel Expires: November 2003 May 2003 User identification in a SIP/QSIG environment Status of this Memo This document is an Internet-Draft and is NOT offered in accordance with Section 10 of RFC2026, and the author does not provide the IETF with any rights other than to publish as an Internet-Draft. 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 other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document examines means of identifying or naming users of telephony services within an enterprise. Numeric names (numbers) are used in traditional Private Integrated Services Networks (PISNs) using QSIG as the network signalling protocol. They are also used for external communication, e.g., with a public Integrated Services Digital Network (ISDN). Names need not be numeric in Internet Protocol (IP) networks employing signalling protocols such as the Session Initiation Protocol (SIP). This document therefore looks at naming schemes that are appropriate within enterprise IP networks, in particular enterprise IP networks employing SIP as the signalling protocol. It also investigates naming schemes that are appropriate in a mixed QSIG/SIP enterprise network and the treatment of names at an interworking point. It details the use of names not only for selecting a user to participate in a call, but also as a means of identifying a user in a call to other users in that call. ENUM and private ENUM-like services are also examined. Elwell et alia Expires - November 2003 [Page 1] Interworking between SIP and QSIG May 2003 This document is a product of the authors' activities in ECMA (www.ecma.ch) on interoperability of QSIG with IP networks. 1 Introduction....................................................3 2 Definitions.....................................................3 2.1 External definitions..........................................3 2.2 Other definitions.............................................4 2.2.1 Gateway.....................................................4 2.2.2 Identifier..................................................4 2.2.3 Identification domain.......................................4 2.2.4 Identification number.......................................4 2.2.5 IP network..................................................4 2.2.6 Number......................................................4 2.2.7 Numbering domain............................................4 2.2.8 PISN number.................................................4 2.2.9 Privacy.....................................................4 2.2.10 Private Integrated Service Network (PISN)..................4 2.2.11 Selection number...........................................5 2.2.12 SIP network................................................5 2.2.13 Sub-domain.................................................5 2.2.14 Trust domain...............................................5 3 Acronyms........................................................5 4 Background and architecture.....................................5 5 The meaning of a name...........................................6 5.1 Names and users...............................................6 5.2 Numeric and non-numeric names.................................7 5.3 Context of a name.............................................7 5.4 Allocation of names...........................................7 5.5 Naming schemes in circuit-switched networks...................7 5.6 Naming schemes in IP networks.................................9 5.7 Universal Communications Identifier (UCI).....................9 6 Signalling protocols...........................................10 7 Overview of naming, numbering and addressing in QSIG...........10 7.1 Numbers as a means of identifying entities...................10 7.2 Numbering plans..............................................11 7.3 Use of numbers in QSIG.......................................12 8 Overview of identification in SIP..............................12 8.1 URIs as a means of identifying entities......................12 8.1.1 SIP URI....................................................13 8.1.2 Telephone URI..............................................14 8.1.3 Display name...............................................14 8.2 Use of URIs in SIP...........................................14 9 Comparison of numbers and non-numeric names for use in SIP.....16 9.1 Numbers in SIP...............................................16 9.2 Non-numeric names in SIP.....................................17 9.3 Summary......................................................17 10 Interworking scenarios........................................17 11 Interworking functions........................................18 11.1 Converting PISN numbers to URIs.............................18 Elwell et alia Expires - November 2003 [Page 2] Interworking between SIP and QSIG May 2003 11.1.1 Selection and identification numbers......................18 11.1.2 Choice of URI scheme......................................18 11.1.3 Choice of host............................................19 11.1.4 Mapping the number to a URI userinfo field................19 11.2 Converting URIs to PISN numbers.............................19 11.2.1 Selection and identification numbers......................19 11.2.2 Support of different URI schemes..........................19 11.2.3 Use of the host field.....................................20 11.2.4 Mapping the URI userinfo field to a PISN number...........20 12 Use of ENUM...................................................20 13 Asserted identity and privacy in SIP..........................21 13.1 Overview of asserted identity RFC...........................21 13.2 Overview of general privacy RFC.............................22 13.3 Applicability to QSIG-SIP interworking......................23 13.3.1 Trust within the enterprise network.......................23 13.4 Trust outside the enterprise network........................24 14 Conclusions...................................................25 15 References....................................................26 Annex A û Mapping between QSIG information elements and SIP P- Asserted-Identity and Privacy headers............................28 1 Introduction This document examines means of identifying or naming users of telephony services within an enterprise. Numeric names (numbers) are used in traditional Private Integrated Services Networks (PISNs) using QSIG as the network signalling protocol. They are also used for external communication, e.g., with a public Integrated Services Digital Network (ISDN). Names need not be numeric in Internet Protocol (IP) networks employing signalling protocols such as the Session Initiation Protocol (SIP). This document therefore looks at naming schemes that are appropriate within enterprise IP networks, in particular enterprise IP networks employing SIP as the signalling protocol. It also investigates naming schemes that are appropriate in a mixed QSIG/SIP enterprise network and the treatment of names at an interworking point. It details the use of names not only for selecting a user to participate in a call, but also as a means of identifying a user in a call to other users in that call. ENUM and private ENUM-like services are also examined. 2 Definitions For the purposes of this document, the following definitions apply. 2.1 External definitions This document uses the following terms defined in other documents: Elwell et alia Expires - November 2003 [Page 3] Interworking between SIP and QSIG May 2003 - Universal Resource Identifier [9] Additionally the definitions in [1] and [13] apply as appropriate. 2.2 Other definitions 2.2.1 Gateway An entity that performs interworking between a PISN using QSIG and an IP network using SIP. 2.2.2 Identifier A name by which the user of a network is known. 2.2.3 Identification domain A set of identifiers controlled by a single administration. 2.2.4 Identification number A number used to identify an existing party in a call (e.g., the calling party). 2.2.5 IP network A network, unless otherwise stated an enterprise network, offering connectionless packet-mode services based on the Internet Protocol (IP) as the network layer protocol. 2.2.6 Number An identifier comprising a numeric string. 2.2.7 Numbering domain An identification domain in which identifiers are numbers. 2.2.8 PISN number A number identifying an entity in a PISN. 2.2.9 Privacy The withholding of a user's identity from other users in a call in compliance with the wishes of that user. 2.2.10 Private Integrated Service Network (PISN) Elwell et alia Expires - November 2003 [Page 4] Interworking between SIP and QSIG May 2003 A private switched circuit network. 2.2.11 Selection number A number used as the basis for routing a call to a destination (i.e., identifying the intended party in a call). 2.2.12 SIP network An IP network using SIP for the establishment of real-time communication sessions (calls). 2.2.13 Sub-domain Part of a numbering domain in which all numbers share the same leading digits. 2.2.14 Trust domain A collection of network nodes between which there is either direct or transitive trust in the authenticity of identifiers and the respecting of privacy requirements. 3 Acronyms DNS Domain Name System IP Internet Protocol ISDN Integrated Services Digital Network PISN Private Integrated Services Network SIP Session Initiation Protocol URI Universal Resource Identifier WWW World-Wide Web 4 Background and architecture Since the 1980s, the traditional way of providing voice services (including fax and modem services) in an enterprise has been through the use of a Private Integrated Services Network (PISN) employing circuit-switched technology. Users of a PISN are identified by numbers (telephone numbers). If a user has been assigned a number, a second user can submit that number to the network in order to establish a call to the first user. Management of assigned numbers for a given network is conducted within a framework known as a numbering plan. This identification technique is similar to that employed in (public) Integrated Services Digital Networks (ISDNs), where the numbering plan is E.164 [17]. Elwell et alia Expires - November 2003 [Page 5] Interworking between SIP and QSIG May 2003 [2] describes numbering and addressing in a PISN. It describes the use of E.164 and private numbering plans in a PISN and defines a method of structuring private numbering plans. It also specifies various forms of number that can be used for identifying parties. In the late 1990s, a trend of convergence between voice networks and data networks began, whereby the Internet Protocol (IP) started to be used to carry voice traffic (including associated signalling) alongside traditional data traffic. Identification in IP networks is based upon the Domain Name System (DNS) [8], "Internet names" (see section 6.2) and Universal Resource Identifiers (URIs), and this principle is therefore applicable also to voice traffic in IP networks. Because of the large investment by many enterprises in traditional telecommunication networks (PISNs), evolution towards the use of IP networks for voice is often planned to take place over a number of years. This means that PISNs and IP networks carrying voice traffic frequently need to co-exist within the same enterprise, and smooth interworking between the two environments is necessary. This therefore means that the different methods of identification in the two types of network need to be understood and overcome. This document investigates this issue, with particular focus on the identification schemes supported by the QSIG protocol in PISNs and SIP in IP networks. Work has been done in ETSI on naming [6]. The focus of that work was public telephony rather than enterprise networks. 5 The meaning of a name The term "name" is commonly applied to the identity of an entity in a telecommunication network, and the term "naming" is applied to the technique of identifying entities by name. This is in contrast to the terms "address" and "addressing", which are commonly applied to the location at which an entity is to be found and the technique of identifying such locations. The general distinction between a name and an address is that a name can remain with an entity even when that entity is mobile and moves between different addresses. 5.1 Names and users A name is often used to identify a human user, but it can also be used to identify other resources, e.g., a group of users or an automaton. For the purposes of this document a name is considered to be associated with a user. A user can have more than one name, either to reflect different roles of that user (e.g., business and private) or to reflect different networks in which the user has a presence. Elwell et alia Expires - November 2003 [Page 6] Interworking between SIP and QSIG May 2003 Even within a single network a user can have more than one name for the same role, different names being used for different services. For example a name used for email might also be used for certain other services within the IP network, e.g., for voice or multimedia communications with other users in that or other IP networks. However, an alternative name (in the form of a telephone number) is likely to be required for voice communication outside the IP environment, e.g., involving a public ISDN or PSTN. In order for a user to establish a communication session with a second user, the first user submits to his local network the name of the second user. It is the task of that network, in conjunction with other networks if necessary, to locate the user associated with that name and establish communication with that user. 5.2 Numeric and non-numeric names A name can comprise a string of digits (0 to 9), in which case it is a numeric name, otherwise known as a number. Numbers are used in legacy circuit-switched networks, and therefore there are compatibility advantages in using numbers in IP networks. Also numbers are suitable for submission by a human user to a network by means of a device with a limited set of keys, e.g., a conventional telephone. However, a non-numeric name can have a close correspondence with the everyday name of a user, and can therefore be easier to remember or guess. 5.3 Context of a name Ideally a name should be globally unique so that it has meaning anywhere in the world on a network that supports that type of name. Such a name is said to be fully qualified. Sometimes, particularly on legacy systems, names are used that are meaningful only within a local context, e.g., within a given network or a given geographic region. A local name generally needs to be combined with additional information to produce a fully qualified name. 5.4 Allocation of names Within a given context, names might be allocated to users on an arbitrary basis. However, this is not always the case. In some contexts names are allocated in accordance with some structure, e.g., organisational, geographic or based on network topology. This makes routing easier but at the expense of lack of flexibility to accommodate long term or short term mobility. 5.5 Naming schemes in circuit-switched networks Elwell et alia Expires - November 2003 [Page 7] Interworking between SIP and QSIG May 2003 Naming schemes in circuit-switched networks (including PISNs, public ISDNs, PSTNs, cellular wireless networks, etc.) are invariably based on numbers. Historically a number represented an address rather than a name, but with the advent of features such as number portability, terminal mobility and user mobility, there has been a gradual evolution over the last two decades towards a number representing a name rather than an address. This is completely true in cellular wireless networks and is generally the case in modern PISNs. For the purposes of this document a number is assumed to be used as a name rather than an address. The numbering plan defined in [17] ("E.164") is the basis for numbering in all carrier networks and is also applicable to all entities in enterprise networks that need to be directly reachable from carrier networks. An international (fully qualified) E.164 number begins with a country code and is meaningful world-wide (globally unique). By contrast a partial E.164 number lacks some of the leading digits and is meaningful only within a particular region or network. For example, an E.164 number that lacks the country code (a national number) is meaningful only within the country concerned. Because they begin with a country code, E.164 numbers reflect network topology at the international level. Depending on country they may also reflect network topology at the national level or below. Within a PISN a private numbering plan can be used to provide a more convenient method of naming (e.g., shorter and/or more easily remembered numbers). An entity in a PISN in which a private numbering plan is used will often have two names: an E.164 number and a private number. However, entities that do not need to be directly reachable by name from outside the PISN can manage with only a private number and no E.164 number. A complete private number is meaningful throughout the domain of the private network (e.g., throughout the PISN) but is not globally unique. A private numbering plan can but need not reflect network topology. The imposition of a topology has implications for user mobility. A partial private number lacks one or more leading digits and is meaningful only within a region of the PISN. PISNs and other circuit-switched networks often also support an alpha-numeric name for display purposes. Such a display name complements the number and is not a replacement for the number, since it is not necessarily unique within the context in which the number is unique. The display name cannot be used directly as the means of identifying a user with whom communication is to be established, i.e., it cannot be used as the basis for routing. However, directory services might provide a means of translating a display name to a number. Display names are not discussed further in this document. Elwell et alia Expires - November 2003 [Page 8] Interworking between SIP and QSIG May 2003 5.6 Naming schemes in IP networks The DNS system provides a method of naming hosts in an IP network and a method of translating a domain name into the IP address of the host concerned. Public DNS servers are deployed in the public Internet and are open to queries from any source. In contrast, private DNS servers are deployed in a closed network (e.g., an enterprise network) for the purpose of resolving domain names within that network and are open to queries only from within that network. However, the DNS system alone is not sufficient for identifying users, and therefore a name of the form: user@domain is generally adopted for applications requiring the identification of users (e.g., email, telephony). The term "internet name" is used in [6] for this form of name, and this term is also used in the present document. The domain field is the domain name identifying a host where the user field can be interpreted. The domain field should be fully qualified so that it is globally unique, and this therefore makes the internet name globally unique. 5.7 Universal Communications Identifier (UCI) [5] proposes a Universal Communications Identifier (UCI) that would provide a single unique identifier (name) for a user of communication services. The UCI comprises three parts: a non-unique alpha-numeric part representing the user's real name or alias, a unique numeric part based on E.164, and a set of flags indicating, for example, a business user. The alpha-numeric part has some similarities to the display name that often accompanies internet addresses (e.g., in front of email addresses or SIP URIs). The numeric part would identify the user's Personal User Agent (PUA), which would perform actions on the user's behalf to facilitate the sending, management and reception of communications. In this respect the numeric part is similar to the address-of-record URI in SIP (see 9.2) and the PUA performs a similar role to a SIP proxy. A UCI namespace needs to be established within the E.164 scheme, and this must be done in such a way that UCI numbers can be dialled from countries that do not participate in UCI. To establish a call, as a minimum the unique numeric part needs to be submitted. Compared with internet names this has the advantage that it can be entered even at the simplest of terminals, but has the disadvantage that it is less memorable than an alpha-numeric name. At present UCI is of interest as a possible future development but does not at present have an impact on QSIG/SIP environments. It is not considered further in this document. Elwell et alia Expires - November 2003 [Page 9] Interworking between SIP and QSIG May 2003 6 Signalling protocols The internationally-standardized network signalling protocol for PISNs is QSIG, as specified in [1], [4] and other ECMA Standards. QSIG uses numbers for naming and provides support for the forms of number specified in [2]. The use of IP networks to carry voice and multimedia traffic has led to the development of new signalling protocols to support voice and multimedia communications in this environment. One such protocol, known as "H.323", is specified in [18] and other recommendations. Another such protocol, is the Session Initiation Protocol (SIP), specified by IETF in [13] and other RFCs. Both H.323 and SIP are being deployed in enterprise networks. The process of evolution means that QSIG-based PISNs and H.323/SIP-based IP networks frequently need to co-exist within the same enterprise, and smooth interworking between the protocols concerned is necessary. Various protocols employed in IP networks use URIs [9] for identifying specific resources. A URI always begins with a scheme identifier (e.g., http:). The framework specified in [9] is quite flexible and the fields that follow the scheme identifier depend on the particular scheme. Some schemes accommodate internet names, e.g., the mailto: scheme for email. In addition to the scheme identifier and internet name, such URIs can contain other information (e.g., parameters). SIP uses URIs for identifying users. The SIP URI [13] accommodates an internet name. However, other URI schemes can be used in SIP, including the telephone URI [10], which accommodates a number. H.323 can use numbers as the means of identifying users, but it can also use alpha-numeric names and URIs. The capability of using non-numeric names, in particular internet names, in SIP and H.323 can lead to difficulties interworking with PISNs, where numbers are used to identify users. The remainder of this document examines the implications of this in more detail, focusing on the use of QSIG as the signalling protocol in PISNs and SIP in IP networks. However, much of what is said concerning SIP is also applicable to H.323, which is not considered further in this document. 7 Overview of naming, numbering and addressing in QSIG 7.1 Numbers as a means of identifying entities The main method of identifying entities in QSIG is by means of PISN numbers. A PISN number can identify any entity that can be the target destination of a call, e.g.: Elwell et alia Expires - November 2003 [Page 10] Interworking between SIP and QSIG May 2003 - an individual user (who may be mobile or may be tied to a particular access); - a particular network access; - a particular service; - a predefined group of users or group of network accesses. When used to identify an individual user, service, etc., a number can be regarded as a name, but when used to identify a particular network access it can be regarded as an address. However, [2] does not make this distinction. NOTE 1. In fact [2] uses the term address for the combination of number and subaddress. Subaddresses are not considered further in this document. Typically a number is used to identify a user. Because of Wireless Terminal Mobility (WTM) or Personal User Mobility (PUM), a number identifying a user is not necessarily associated with a particular access, although in the case of non-mobile users this association will exist. NOTE 2. For non-mobile users this association can change on an infrequent basis, e.g., when the user moves permanently to a different office. A number is referred to as a selection number when used as the basis for routing a call to a destination (i.e., identifying the intended party in a call). A number is referred to as an identification number when identifying an existing party in a call (e.g., the calling party). 7.2 Numbering plans Management of assigned numbers for a given network is conducted within a framework known as a numbering plan. A PISN employs one or more numbering plans and each PISN number belongs to a numbering plan. [2] allows PISNs to use the E.164 numbering plan. It also defines structured private numbering plans (PNPs) for use in PISNs. NOTE. [2] also permits the use of DCC (data country code) and ICD (international code designator) numbering plans within a PISN. These are mainly for use with Asynchronous Transfer Mode (ATM) and are not discussed further in this document. Elwell et alia Expires - November 2003 [Page 11] Interworking between SIP and QSIG May 2003 For both E.164 and PNPs, numbers can be complete or partial. A partial number lacks some of the leading digits and is therefore significant only within a particular sub-domain. In the case of E.164, for example, an international number has global significance (i.e., it is fully qualified) whereas a national number lacks a country code and has significance only within the country concerned. In the case of a PNP, a complete number has significance within the numbering domain of the PNP (e.g., the enterprise) and a regional number has significance only within a certain part of that numbering domain. Therefore a number must be qualified by a separate Numbering Plan Identification (NPI, identifying the numbering plan to which it belongs) and a separate Type Of Number (TON, indicating the completeness of the number). Alternatively, the numbering plan and completeness of the number can be implicit in the number itself, e.g., by the use of prefix digits. An implicit number is indicated by a special value in the NPI. 7.3 Use of numbers in QSIG QSIG uses numbers for the following purposes: - in the Called party number information element for identifying the intended destination of a call (i.e., a selection number); - in the Calling party number and Connected number information elements for identifying the calling and connected (answering) party respectively; - in various remote operations for identifying parties involved in supplementary services or additional network features, e.g., transferred-to party, diverted-to party, diverted-from party. QSIG also has a name supplementary service [3] that provides additional identification information (typically a name) for a party in the form of a character string. The name is conveyed in dedicated remote operations during call establishment and also in certain operations of other supplementary services. 8 Overview of identification in SIP 8.1 URIs as a means of identifying entities SIP uses URIs to identify entities participating in communication sessions. Although [13] defines the SIP scheme (and the secure equivalent SIPS) specifically for use within SIP, any form of URI can Elwell et alia Expires - November 2003 [Page 12] Interworking between SIP and QSIG May 2003 in principle be used, including the telephone URI scheme defined in [10]. All SIP implementations must support SIP URIs. In contrast to identifiers in QSIG, URIs are virtually never used to identify physical addresses. The SIP routing process provides translation from URI (as it appears in the SIP Request-URI field) to IP address. 8.1.1 SIP URI A SIP URI is of the form: sip:userinfo:password@host:port;uri-parameters?headers The use of password is deprecated (for security reasons) and port, uri-parameters and most headers are not of relevance to the present discussion. Therefore for the purposes of this document a SIP URI is of the form: sip:userinfo@host or sip:userinfo@host;uri-parameters where host is a domain name or IP address and userinfo is a particular resource at the host being addressed. NOTE. userinfo@host is effectively an internet name (user@domain). The userinfo field can be numeric or non-numeric, and in the numeric case it can be (but need not be) a telephone number. A telephone number can be a global E.164 number (beginning with "+") or a local number. Examples: sip:john@ecma.ch sip:1234@ecma.ch sip:+43-2109-8765@ecma.ch The only parameter of relevance to this document is the user= parameter with value phone. This parameter is used to distinguish telephone numbers in the user-info field from other values that happen to look like telephone numbers, for example: sip:1234@ecma.ch;user=phone sip:+43-2109-8765@ecma.ch;user=phone Elwell et alia Expires - November 2003 [Page 13] Interworking between SIP and QSIG May 2003 8.1.2 Telephone URI The telephone URI is currently defined in [10]. However, a revised version of [10] is in preparation [19], and the information below relates to this draft revised edition. A telephone URI is of the form: tel:telephone-subscriber;uri-parameters where telephone-subscriber is a global E.164 number (beginning with "+") or a local number. Examples: tel:1234 tel:+43-2109-8765 The significance of a local number depends on the numbering domain. However, the phone-context parameter can provide additional information, e.g.. tel:1234;phone-context=+411234 tel:1234;phone-context=ecma.ch The first example indicates that telephone number 1234 is to be interpreted within context +411234, i.e., within the context of all E.164 numbers beginning with +411234 The second example indicates that telephone number 1234 is to be interpreted within the context of domain name ecma.ch The draft revised edition of [10] requires the use of global E.164 numbers except for numbers that cannot be represented that way (e.g., numbers from private numbering plans, emergency numbers, directory assistance numbers, etc.). 8.1.3 Display name In addition, a URI can be accompanied by a display name in some cases. Example: "John" 8.2 Use of URIs in SIP SIP uses URIs for the following purposes: - in the Request-URI for routing a request; Elwell et alia Expires - November 2003 [Page 14] Interworking between SIP and QSIG May 2003 - in the To header, for indicating the logical recipient of a request (unlike the Request-URI, the URI in the To header is not changed by proxies) (NOTE 1); - in the From header, for indicating the initiator or a request (NOTE 1); - in the Contact header, for indicating the contact point for further requests in a dialog or for indicating a new target in a 3xx response (NOTE 1); - in the Reply-To header, for indicating the address for replies using a new request outside the scope of the current dialog (e.g., a new INVITE request); - in the Route header, for identifying a proxy for routing a request through; - in the Record-Route header, for identifying a proxy involved in a request so that further requests in the same dialog can be forced through that proxy; - in the P-Asserted-Identity header for conveying party identification information between trusted SIP entities (NOTE 2); - in the P-Preferred-Identity header for a UA to convey to its proxy the particular identity (out of several valid identities) by which the user is to be known for the purposes of the present call (NOTE 2); - in the Refer-to header in the REFER method. NOTE 1. URIs in these headers can include a display name. NOTE 2. The P-Asserted-Identity and P-Preferred-Identity headers are defined in [16]. In addition, new headers to be defined in new RFCs might include URIs. A distinction should be made between address-of-record URIs (e.g., in Request-URI, To header and From header) and contact URIs (e.g., the first use above of Contact header). An address-of-record URI identifies a user whereas contact URIs identify a device. The process of registering using the SIP REGISTER method temporarily binds an address-of-record URI to a contact URI for a device. Therefore a contact header is somewhere between a name and an address and is not considered further in this document. Elwell et alia Expires - November 2003 [Page 15] Interworking between SIP and QSIG May 2003 9 Comparison of numbers and non-numeric names for use in SIP Through various forms of URI, SIP can use both numbers and non- numeric names for identification. This is in contrast to QSIG, where only numbers are used. 9.1 Numbers in SIP The use of numbers for identification in SIP has the advantage of compatibility with legacy systems, including PISNs, PSTNs and public ISDNs. Normally, the only means available to a user on a legacy network for making a call to another user is by submitting (dialling) the number of the called user. If the calling user is not aware of the number of the called user, he can look it up in a directory (electronic or otherwise) and then submit it (or cause it to be submitted automatically). Routing by name or URI is not possible on legacy networks. Therefore a user in a SIP network must have a number in order to be reachable from a legacy network. Likewise, a number must be used in order to reach a user in a legacy network from a SIP network. A disadvantage of using numbers in SIP is the use of different numbering plans and types of number, leading to the need to insert leading digits to produce a fully qualified number and the need to deal with prefix digits or other characters (e.g., "+" in front of an international E.164 number). Numbers can be placed in the userinfo field of a SIP URI or in a telephone URI. The use of number-based URIs in SIP networks facilitates interworking with legacy networks and also permits the use of SIP phones with just a traditional telephone keypad. There are also likely to be performance advantages based on being able to route on leading digits without the need to interrogate large databases. However, the host field of a SIP URI is generally non-numeric, which makes interworking with a SIP URI somewhat less simple. On the other hand, even the telephone URI requires a context parameter if the number is not fully qualified, and this too can make interworking less simple. Whichever URI scheme is used, there are still issues to be considered concerning whether the number is fully qualified or partial. In general a fully qualified number is to be preferred, although there may be situations in which partial numbers can be of benefit (e.g., a URI submitted from a phone to its local proxy). Care has to be taken not to send a partial number outside its domain. The phone-context parameter in the telephone URI can be a way of defining the context of a number, but still care must be taken not to send a URI outside the domain where the value in phone-context is meaningful. Elwell et alia Expires - November 2003 [Page 16] Interworking between SIP and QSIG May 2003 9.2 Non-numeric names in SIP As stated in 6.3, a non-numeric name can have a close correspondence with the everyday name of a user, and can therefore be easier to remember or guess. Since non-numeric names are routinely used for certain services (e.g., email), the use of the same name for telephony can be advantageous. SIP URIs (without user=phone) contain internet names in which the userinfo part is not limited to numeric digits and in general will contain alphabetic characters. For this reason a SIP URI can convey meaningful names of users, services, etc.. Email addresses are often remembered if the user part is in a conventional form (e.g., firstName.lastName) and the host part is a recognisable company domain name (e.g., MyOwnCompany.com). Similarly, well-chosen SIP URIs can be more easily remembered, particularly if they are similar to email addresses. For example: sip:john@ecma.ch mailto:john@ecma.ch For these reasons, some enterprises will be keen to move away from numbering and fully exploit the advantages of internet names in URIs, but there are difficulties to be overcome, particular when interworking with circuit-switched networks. Also there might be performance penalties. 9.3 Summary Although the use of numbers as the basis for identification in SIP in URIs is likely to be quite common in the short to medium term, URIs not based on numbers (e.g., based on the user's everyday name) are likely to be introduced in parallel, with users having more than one identifier (aliases), e.g., a number and an alpha-based SIP URI. Different identifiers might be used for different services, e.g., internet names for services other than telephony and perhaps for telephony within the IP network and numbers for interworking with circuit-switched networks. 10 Interworking scenarios Each network has one or more identification domains. A PISN typically forms part of the global numbering domain for E.164 numbers and also has its own numbering domain for private numbering. Where a PISN has more than one numbering domain, some users may have a number in more than one numbering domain, e.g., an E.164 number and a private number. There may or may not be an algorithmic means of Elwell et alia Expires - November 2003 [Page 17] Interworking between SIP and QSIG May 2003 mapping between a user's number in one numbering domain and a user's number in another numbering domain. In a SIP network using SIP URIs for identification, the identification domain is the set of identifiers served by a particular host. In a QSIG-SIP interworking environment, two basic scenarios are identifiable: 1. A common numbering / identification domain spans the QSIG and SIP networks. In other words, a common numbering plan exists and numbers can be passed between the two networks. The boundary between the two networks may correspond to a sub-domain boundary, and therefore it may be necessary to convert numbers to a higher level before crossing the boundary. Also it may be necessary to add/remove prefix digits if one network uses implicit numbering or if both networks use implicit numbering with different prefixes. 2. The networks belong to different numbering / identification domains. In this case, identifiers received from one network need to be mapped or translated to identifiers suitable for sending to the other network. Mapping may be algorithmic (e.g., insertion and/or removal of digits) or on an individual identifier basis by table look-up. If an identifier has no corresponding identifier in the other network it cannot be passed. In a given situation, both scenarios can co-exist, e.g., one for private numbers and the other for E.164 numbers. 11 Interworking functions 11.1 Converting PISN numbers to URIs 11.1.1 Selection and identification numbers Considerations differ slightly according to whether the PISN number is a selection number (Called party number information element) or an identification number. 11.1.2 Choice of URI scheme A PISN number could be converted to a SIP URI, a telephone URI or some other URI. It is important that the scheme chosen is understood by at least the first proxy. A SIP URI will always be understood, but other schemes such as telephone URIs will not necessarily be supported. Use of a SIP URI is assumed below. Elwell et alia Expires - November 2003 [Page 18] Interworking between SIP and QSIG May 2003 11.1.3 Choice of host If a SIP URI is chosen, it is necessary to provide a value for the host portion of the URI. For a selection number (QSIG Called party number information element) the host needs to be a domain that can interpret the userinfo, which will be derived from the PISN number. There may be a single domain for accessing all numbers, or it may be necessary to select the domain according to the number. The former is easier for the gateway but places more burden on proxies. There may be different domains for E.164 and PNP numbers. For an identification number it must be the domain to which the gateway belongs. 11.1.4 Mapping the number to a URI userinfo field An E.164 international number could be placed directly as a global number in the userinfo field of a SIP URI. An E.164 national or subscriber number would first need to be converted to an international number. For preference, a PNP number should be converted to an E.164 international number and treated as above. Where this is not feasible, a PNP number could be placed directly in the userinfo field as a local number, provided the domain concerned recognises such numbers. It may require converting the PNP number to a higher level (e.g., a complete number) and/or the addition of prefix digits. An implicit number might need to be analysed. For example, if prefix digits indicate a public network number, it could be converted to an international E.164 number and treated as above. If crossing an identification domain boundary, each PNP number will require mapping to a userinfo value either algorithmically or by table look-up. In the latter case userinfo values need not be limited to telephone numbers û they could be non-numeric names. In each of the above cases where a telephone number is placed in the userinfo field, parameter user=phone should be included in the SIP URI. 11.2 Converting URIs to PISN numbers 11.2.1 Selection and identification numbers Considerations differ slightly according to whether the PISN number to be generated is a selection number (derived from the To header or the Request-URI) or an identification number. 11.2.2 Support of different URI schemes Elwell et alia Expires - November 2003 [Page 19] Interworking between SIP and QSIG May 2003 The gateway may support only a single URI scheme, in which case this would probably need to be SIP URIs, or may support more than one, including, for example, telephone URIs. Support of SIP URIs is assumed below. 11.2.3 Use of the host field For a selection number, the host field should identify the gatewayÆs domain û otherwise the call should not have been routed to this gateway. For an identification number, other domains might be indicated. The ability to convert URIs from other domains cannot be assumed, unless the userinfo field contains a global E.164 number. 11.2.4 Mapping the URI userinfo field to a PISN number If the userinfo field contains a telephone number, it may be possible to use this directly as a PISN number or it may be necessary to carry out some conversion, e.g., addition of prefix digits. If crossing an identification domain boundary, it may be possible to map userinfo values to PISN numbers algorithmically or by table look- up. In the latter case userinfo values need not be limited to telephone numbers û they could be non-numeric names. 12 Use of ENUM [11] ("ENUM") specifies a method of mapping E.164 numbers to URIs. Basically a domain name is created by reversing the full international E.164 number, placing a dot between each digit, and appending ".e164.arpa". This gives a domain name that can be used to perform a DNS look-up. The result is a limited set of URIs that can be used as potential contacts for the number concerned. This can include, of course, SIP URIs and telephone URIs. [11] is applicable only to E.164 numbers. It is a centralized service based on the "e164.arpa" root, and therefore for a given E.164 number there is only one logical place in the Internet where authoritative records can be obtained. ENUM therefore is a useful means of converting fully qualified E.164 numbers to SIP URIs and could be used by gateways when handling calls from QSIG to SIP where the QSIG Called party number information element contains an E.164 number. Although simple conversion to a SIP or telephony URI can be done without the aid of ENUM, the use of ENUM can add value, e.g., by selectively choosing the host part of the URI. Elwell et alia Expires - November 2003 [Page 20] Interworking between SIP and QSIG May 2003 A replacement for [11] is currently in a fairly advanced state of drafting [12]. The replacement allows the use of an ENUM-like private service where the suffix is something other than ".e164.arpa" (e.g., ".e164.MyOwnCompany.com"). This could be a useful means of resolving private numbers to SIP URIs. Normally it would require fully qualified private numbers. It could also handle DDI numbers, e.g., by first converting them to fully qualified private numbers. Although simple conversion to a SIP or telephony URI can be done without the aid of a private ENUM-like service, the use such a service can add value, e.g., by selectively choosing the host part of the URI or by providing a non-numeric userinfo part. Useful information on the relationship between ENUM and SIP is contained in [7]. Depending on country, an enterprise can operate a public ENUM service at level 2 (level 0 being international and level 1 being national) for resolving certain numbers from the national numbering plan, e.g., numbers for a city or numbers relating to the enterprise itself. Such a service is available to the general public and insecure, and therefore it might be inappropriate as a means of making available detailed information on routing within the enterprise. However, internally, an enterprise could operate a closed ENUM service for resolving internal numbers (private or E.164). A split DNS could offer both, effectively with a firewall between the two. There has been some discussion in ENUM circles of providing a reverse ENUM service that translates an internet name to a number. This would potentially be of use to a QSIG-SIP gateway but nothing is yet standardized. 13 Asserted identity and privacy in SIP The IETF has published two RFCs on identity and privacythat have the potential to provide better solutions to the problem of mapping to and from the QSIG Calling party number and Connected number information elements. This clause contains an overview of the two RFCs and describes how they can be used to enhance QSIG- SIP interworking. Detailed mapping scenarios are described in Annex A. 13.1 Overview of asserted identity RFC Asserted identity is specified in informational [16] and provides headers for conveying identity information between trusted entities. It is based on requirements in informational [15]. Elwell et alia Expires - November 2003 [Page 21] Interworking between SIP and QSIG May 2003 The document introduces two new "P-headers" (preliminary, private or proprietary headers), P-Asserted-Identity and P-Preferred-Identity. The reason for making them P-headers is that they are intended only as a preliminary solution or a solution aimed at specific applications, and are regarded as not fitting into the main SIP- Internet architecture. Because it defines only P-headers, the RFC is informational, not standards track. There is work in progress in the IETF to produce a new standards track RFC that relies on cryptography rather than trust, and the use of this in enterprise networks should be investigated when the work matures. Although [16] is sometimes viewed as a short term solution, there is also a body of opinion that says that solutions based on [16] may be appropriate even in the long term in appropriate trusted environments (e.g., enterprise networks). The P-Asserted-Identity header contains (name-addr / addr-spec) for the party whose identity is asserted. This is implicitly the party from whom the message is sent, e.g., the calling party in the case of an INVITE request. The header is generated by a proxy that is able to authenticate the user (by some means outside the scope of the RFC, e.g., SIP Digest Authentication) and forwarded between trusted entities. It may be forwarded to untrusted entities (normally only to UAs), but must not be forwarded to untrusted entities if the user has requested privacy by means of the Privacy header (see 14.2). However, an additional value "id" is introduced to the Privacy header to indicate that the asserted-id is private. The P-Preferred-Identity header is for an untrusted UA to provide a "hint" to its (trusted) proxy as to which of several identities it wishes to be known by for the purposes of the current call. The proxy may take account of this and forward this identity (assuming it is able to authenticate it) in a P-Asserted-Identity header or replace it. 13.2 Overview of general privacy RFC [14] defines a Privacy header that can be inserted by a UA (or a proxy acting in accordance with user instructions) and can specify one or more of the following types of privacy: - "header" û removal of identifying information from all headers that the UA cannot deal with (e.g., Contact, Via); - "session" û removal of identifying information in SDP bodies (i.e., session IP addresses); - "user" û application of privacy measures that would normally be performed at the UA (e.g., making the From header anonymous); Elwell et alia Expires - November 2003 [Page 22] Interworking between SIP and QSIG May 2003 - "none" û no privacy, overriding any pre-existing agreement for a proxy to provide privacy; - "critical" û the privacy services requested are critical and if they cannot be provided the request should be rejected. In addition, the asserted identity RFC adds "id" (asserted-id privacy). The Privacy header is acted upon by a "privacy service", typically collocated with a proxy. 13.3 Applicability to QSIG-SIP interworking 13.3.1 Trust within the enterprise network Enterprise networks are often suitable environments for treatment as trusted domains from the point of view of identity and privacy. This is indeed the case in a conventional QSIG network, since each node trusts any identity provided by another node. Also a node sending an identity that requires privacy can trust a node to which it is sent not to disclose that identity to untrusted entities, in particular to users who are not entitled to receive that information. Trust is transitive, in that it operates through transit nodes. If the enterprise network is SIP-based, it is often quite reasonable for all SIP entities to be regarded as part of a trust domain where: - all proxies trust each other; - all UAs trust their proxies; and - trust is transitive. In general a proxy will not trust its UAs, although it might trust certain UAs, e.g., gateways. Within a trust domain, all entities must conform to a certain set of specifications, which the asserted identity RFC calls "Spec(T)". For a given trust domain, Spec(T) will specify, among other things, the security mechanisms used for communication between SIP entities and the means of authenticating users. Very large enterprise networks might comprise more than one trust domain. If the enterprise network contains both SIP and QSIG, with interworking between the two by means of gateways, it would be quite Elwell et alia Expires - November 2003 [Page 23] Interworking between SIP and QSIG May 2003 reasonable for a single trust domain to embrace both parts of the network. This would allow: - identities from the QSIG network to be passed to the SIP network and trusted by entities in the SIP network; - identities from the SIP network to be passed to the QSIG network; - privacy indications associated with identities from the QSIG network to be honoured by the SIP network; and - privacy indications associated with identities from the SIP network to be honoured by the QSIG network. In this case, the QSIG-SIP gateway will trust the nearest proxy and vice versa. Conversely, the lack of a single trust domain covering the SIP and QSIG networks means the following: - identities from the QSIG network can be passed to the SIP network (if privacy is not required) but SIP entities will not be able to trust these identities (unless a separate means of authentication is available); - identities from the SIP network should not be passed to the QSIG network unless the gateway has separate means of authenticating them; - identities marked as private from the QSIG network should not be passed to the SIP network; - identities marked as private from the SIP network will not be passed to the gateway. To achieve this, the QSIG-SIP gateway should not trust the nearest proxy and the nearest proxy should not trust the QSIG-SIP gateway. This scenario is perhaps less likely within an enterprise network than the single trust domain described earlier, although it could apply in very large enterprise networks. 13.4 Trust outside the enterprise network When an enterprise network interworks with a carrier ISDN network, it is normally the case that the enterprise network trusts the carrier network but not vice versa. An enterprise network will normally trust an identity provided by a carrier network (this is true for a QSIG network). Also an enterprise network may or may not trust a carrier network to honour any privacy associated with identities provided to the carrier network. On the other hand, a carrier network will not Elwell et alia Expires - November 2003 [Page 24] Interworking between SIP and QSIG May 2003 normally trust an identity provided by an enterprise network, and although in the case of ISDN it may deliver such an identity to the destination user, it will mark it as user-provided. In this case it might also deliver the identity of the access, which it can guarantee. A carrier network will not normally deliver an identity for which privacy is required to an enterprise network. These considerations apply more or less independently of whether the enterprise network is circuit-switched (QSIG) or SIP. When an enterprise network interworks with a carrier SIP network, considerations might be different. It the carrier network is the public Internet, it is unlikely that the enterprise network will trust identities received from that carrier network and it is unlikely that the enterprise network will be prepared to submit identities subject to privacy to that carrier network. On the other hand, if the carrier SIP network is administered to a standard comparable with that of carrier ISDN networks, then the enterprise network might be prepared to trust it to the same degree as a carrier ISDN network. It is a matter for the entity that interworks directly with a carrier SIP network to determine the degree of trust. If the QSIG network interworks directly with a trusted or untrusted carrier SIP network (i.e., the gateway communicates with a proxy in the carrier network), then it should behave as it would when interworking with an enterprise SIP network within or outside gateway's trust domain respectively. If the QSIG network interworks via an enterprise SIP network with a carrier SIP network, it is a matter for a proxy in the enterprise SIP network to take necessary steps to protect the enterprise network from the carrier network. This includes preventing untrusted identities from the carrier network penetrating into the enterprise network and preventing disclosure of private identities to the carrier network. If there is a single trust domain within the enterprise network, the QSIG-SIP gateway can behave as normal for this situation and rely on the SIP network to provide the necessary protection from the carrier network. In other words the principle of transitive trust applies. 14 Conclusions Numbers can be used in SIP for identifying users, by encapsulation within SIP or telephone URIs. This is likely to be common practice in the short to medium term, because of the need to interworking with legacy networks, including QSIG. However, non-numeric names (internet names) are likely to be introduced in parallel, with users having Elwell et alia Expires - November 2003 [Page 25] Interworking between SIP and QSIG May 2003 more than one name. Different names might be used for different services, e.g., internet names for services other than telephony and perhaps for telephony within the IP network and numbers for interworking with circuit-switched networks. The use of numbers simplifies interworking with QSIG, particularly if the two networks are part of the same identification domain. The use of non-numeric names in the SIP network necessarily means that there will be a domain boundary between the SIP network and the QSIG network and therefore mapping will be required. e.g., by table look- up. A private ENUM-like service might be a convenient way of providing mapping from numbers to SIP URIs at an interworking point. 15 References [1] ECMA-143 "Private Integrated Services Network - Circuit-mode Bearer Services - Inter-Exchange Signalling Procedures and Protocol" (International Standard ISO/IEC 11572) [2] ECMA-155 "Private Integrated Services Network (PISN) - Addressing" (International Standard ISO/IEC 11571) [3] ECMA-164 "Private Integrated Services Network (PISN) - Inter- Exchange Signalling Protocol û Name Identification Supplementary Services" (International Standard ISO/IEC 13868) [4] ECMA-165 "Private Integrated Services Network - Generic Functional Protocol for the Support of Supplementary Services - Inter-Exchange Signalling Procedures and Protocol" (International Standard ISO/IEC 11582) [5] ETSI EG 201 940 "Human Factors (HF); User identification solutions in converging networks" (2001-04) [6] ETSI TR 101 326 "Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON); The procedure for determining IP addresses for routeing packets on interconnected IP networks that support public telephony" (2002-02) [7] J. Peterson, H. Liu, J. Yu, B. Campbell, "Using ENUM for SIP applications", draft-ietf-sipping-e164-02 (work in progress) [8] P. Mockapetris, "Domain Names û Concepts and Facilities", IETF RFC 1034 [9] T. Berners-Lee, R. Fielding, U. C. Irvine, L Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", IETF RFC 2396 Elwell et alia Expires - November 2003 [Page 26] Interworking between SIP and QSIG May 2003 [10] A. Vaha-Sipila, "URLs for Telephone Calls", IETF RFC 2806 [11] P. Faltstrom, "E.164 number and DNS", IETF RFC 2916 [12] P. Faltstrom, M. Mealling, "The E.164 to URI DDDS application (ENUM)", draft-ietf-enum-rfc2916bis-03 (work in progress) [13] J. Rosenberg, H. Schulzrinne, et al., "SIP: Session initiation protocol", RFC 3261. [14] J. Peterson, "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323 [15] M. Watson, "Short Term Requirements for Network Asserted Identity", IETF RFC 3324 [16] C. Jennings, J. Peterson, M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325 [17] ITU-T Recommendation E.164, "The International Public Telecommunication Numbering Plan", (1997-05). [18] ITU-T recommendation H.323, "Packet-Based Multimedia Communications Systems", (2000-11) [19] H. Schulzrinne, A. Vaha-Sipila, "The tel URI for Telephone Calls", draft-antti-rfc2806bis-08 (work in progress) Elwell et alia Expires - November 2003 [Page 27] Interworking between SIP and QSIG May 2003 Annex A û Mapping between QSIG information elements and SIP P-Asserted- Identity and Privacy headers A.1 Mapping QSIG Calling party number information element to SIP elements Without the asserted identity RFC, SIP provides only the From header as a suitable vehicle for conveying information from the QSIG Calling party number information element. The From header is normally provided by a UAC and passed unchanged through proxies to the UAS. Mapping the Calling party number to the From header has two problems: 1. Even if a downstream proxy is aware that the identity is subject to privacy, it cannot remove it before passing on to an untrusted entity, except by behaving as a back-to-back UA. 2. A downstream proxy (beyond the first proxy) is not aware of whether the UAC is a trusted entity and therefore cannot rely on the accuracy of the information in From. Within a trusted domain, the P-Asserted-Identity header gets around these problems. If the gateway trusts the nearest proxy, the identity should be placed in a P-Asserted-Identity header and if presentation is restricted a Privacy header should be included with priv-value = "id". If the gateway does not trust the nearest proxy it may still include a P-Asserted-Identity header, but only if the presentation is not restricted. If presentation is restricted the gateway should include a Privacy header with priv-value = "id". NOTE. In this case the proxy will probably not trust the gateway and will ignore (and not pass on) the P-Asserted-Identity header. An alternative would be to use the P-Preferred-Identity header instead, but it is unlikely that the proxy will have a means of validating the identity, so likewise this is likely to be ignored (and not passed on). There does not seem to be a case for using the P-Preferred-Identity header. Regardless of trust, the gateway should incorporate the identity in the From header if presentation is not restricted and include an anonymous value in the From header if presentation is restricted. If presentation is restricted, the gateway may use the Privacy header to request other types of privacy, e.g., "header" or "session". For example, "header" privacy would hide the gateway's identity in the Contact header, and "session" privacy would hide the gateway's IP address in SDP. The need for this is lessened by the fact that Elwell et alia Expires - November 2003 [Page 28] Interworking between SIP and QSIG May 2003 gateway identities do not reveal the identity of the user in the QSIG network, although they might reveal the identity of the QSIG network. However, to honour such privacy requests requires the presence of special equipment (e.g., back-to-back UAs) in the local SIP network. A.2..Mapping QSIG Connected number information element to SIP elements The asserted identity RFC provides the only means at present for conveying information derived from the QSIG Connected number information element. Note that the Contact header should identify the gateway rather than the connected party. If the gateway trusts the nearest proxy, the identity should be placed in a P-Asserted-Identity header and if presentation is restricted a Privacy header should be included with priv-value = "id". If the gateway does not trust the nearest proxy it may still include a P-Asserted-Identity header, but only if the presentation is not restricted. If presentation is restricted the gateway should include a Privacy header with priv-value = "id". NOTE. In this case the proxy will probably not trust the gateway and will ignore (and not pass on) the P-Asserted-Identity header. An alternative would be to use the P-Preferred-Identity header instead, but it is unlikely that the proxy will have a means of validating the identity, so likewise this is likely to be ignored (and not passed on). There does not seem to be a case for using the P-Preferred-Identity header. A.3Mapping SIP elements to QSIG Calling party number information element Without the asserted identity RFC, SIP provides only the From header as a suitable source of information for populating the QSIG Calling party number information element. Use of the From header has two problems: 1. It cannot be trusted, since it comes from the UAC, which normally is untrusted. 2. It can contain an anonymous value if privacy is required. Within a trusted domain, the P-Asserted-Identity header, in conjunction with the Privacy header, gets around these problems. If the gateway trusts the nearest proxy and a P-Asserted-Identity header is present, the gateway should use information from that header to derive the QSIG Calling party number information element. If a Privacy header is also present with priv-value = "id", the presentation indicator should be set to presentation restricted. Elwell et alia Expires - November 2003 [Page 29] Interworking between SIP and QSIG May 2003 Within an enterprise network, it will normally be the case that the gateway trusts the nearest proxy. However, if the gateway does not trust the nearest proxy, it should not make use of the P-Asserted-Identity header, if present. Depending on the presence of a Privacy header with priv-value = "id", the presentation indication should be set to either "not available due to interworking" or "presentation restricted", in either case with no number. This leaves the difficult question of whether to make use of the From header at all for cases where no P-Asserted-Identity header is received. Logic dictates that it should not be used, because it comes from an untrusted source and a QSIG network assumes that information in the Calling party number information element can be trusted. NOTE. The ability to set the screening indicator to "user provided, not screened" would appear to indicate that it is generally acceptable to put untrusted numbers in the information element, provided this value of the screening indicator is used. However, this value of the screening indicator normally means that the number has been supplied by a PBX or enterprise network to a public ISDN and the public ISDN has been unable to screen the number. Such numbers tend to be trusted in enterprise networks for caller display purposes, since they don't normally come from end user equipment. Identities in the SIP From header, however, come from end user equipment and are much more likely to be falsified. Therefore deriving a number from the From header and marking it "user provided, not screened" may cause an undue level of trust to be given to the number in the QSIG network. However, until implementation of the P-Asserted-Identity header (or the long term alternative) becomes common, the From header will often be the only means of populating the Calling party number information element. Some administrations may be prepared to accept this risk in order to obtain the benefits of caller display. Therefore gateways should be allowed to use the From header in the absence of more reliable information. This should be a configurable option. Where this option applies, the presence of display name "Anonymous" should be used to set the presentation indicator to "presentation restricted". Otherwise, if no number can be derived from the contents of the From header, the presentation indicator should be set to "not available due to interworking". The screening indicator should be set to "user provided, not screened" A.4..Mapping SIP elements to QSIG Connected number information element The asserted identity RFC provides the only suitable source of information at present for populating the QSIG Connected number information element. Elwell et alia Expires - November 2003 [Page 30] Interworking between SIP and QSIG May 2003 If the gateway trusts the nearest proxy and a P-Asserted-Identity header is present, the gateway should use information from that header to derive the QSIG Connected number information element. If a Privacy header is also present with priv-value = "id", the presentation indicator should be set to presentation restricted. Within an enterprise network, it will normally be the case that the gateway trusts the nearest proxy. However, if the gateway does not trust the nearest proxy, it should not make use of the P-Asserted-Identity header, if present. Depending on the presence of a Privacy header with priv-value = "id", the presentation indication should be set to either "not available due to interworking" or "presentation restricted", in either case with no number. Elwell et alia Expires - November 2003 [Page 31]