Hang up. If ▇▇▇▇▇ wants to call a service (that is, where the remote end is not a subscriber), she does it the same way but uses its service identity instead of a subscriber. Even though IMS is (here) seen as an evolution of telephony, there are important contributions from data communication seen in many places of IMS. An IMS enabled device can in general handle several IMS calls to many subscribers and network services at the same time. It is similar to how a computer can handle multiple network connections to one or several other computers. The precise behavior is application-specific, but it should be remembered that just because one IMS call is active, it does not imply that other calls cannot be handled. IMS users are reachable on the IMS networks with their Public User Identities, that takes the form of an Uniform Resource Identifier (URI). Two types of URI are supported: • A SIP URI (as defined in RFC3261), like sip:▇▇▇▇▇@▇▇▇.▇▇▇▇▇▇▇.▇▇▇. Such URIs are suitable for use from the Internet. • A TEL URI (as defined in RFC3966), like tel:+▇▇▇▇▇▇▇▇▇▇. This format enables an IMS terminal to be reachable in traditional telephone networks. The operator allocates one or more public user identities for use within a subscription. When the device is switched on and connects to the IMS network, the device and the network engage in a process called IMS registration to make the user reachable under some of the identities. It is possible to be reachable using several public user identities at the same time. For example, if a SIP identity works on the Internet, and the TEL identity on the telephone network, it makes sense to have them both registered at the same time to be equally reachable from both worlds. The operator usually makes sure that in such case, if the user wants to be reachable on one of them, it implies also being reachable from the other. Services in traditional telephony, like conferencing or supplementary service self administration, are accessed using special phone numbers. A similar situation holds in IMS where a service is accessed using a Public Service Identity. If ▇▇▇▇▇ wants to take part in a conference, she dials into the conference using its public service identity. The conference server arranges for her participation. The identity is formatted as a SIP URI.
Appears in 1 contract
Hang up. If ▇▇▇▇▇ wants to call a service (that is, where the remote end is not a subscriber), she does it the same way but uses its service identity instead of a subscriber. Even though IMS is (here) seen as an evolution of telephony, there are important contributions from data communication seen in many places of IMS. An IMS enabled device can in general handle several IMS calls to many subscribers and network services at the same time. It is similar to how a computer can handle multiple network connections to one or several other computers. The precise behavior is application-specific, but it should be remembered that just because one IMS call is active, it does not imply that other calls cannot be handled. IMS users are reachable For many years, phone numbers have been used to identify subscribers and their devices. In fixed networks, the number indicated the line to the subscriber. In mobile telephony, the SIM card has a similar role and is used to authorize access to the network. In these systems, the phone number relates more to the device rather than the subscriber. In IMS, identities focus on the IMS networks with their Public User Identitiessubscriber to make a unique identification. A subscriber can share an identity across multiple devices, that takes the form of and other factors decide which device handles an Uniform Resource Identifier (incoming call. The user identity is an operator specified string formatted as a SIP URI). Two types of URI are supported: • A SIP URI (sip:user@domain If the subscriber has a telephone number it can be formatted as defined in RFC3261), like sip:▇▇▇▇▇@▇▇▇.▇▇▇▇▇▇▇.▇▇▇. Such URIs are suitable for use from the Internet. • A a TEL URI (and used as defined in RFC3966), like tel:+▇▇▇▇▇▇▇▇▇▇. This format enables an IMS terminal to be reachable in traditional telephone networks. The operator allocates one or more public a user identities for use within a subscription. When the device is switched on and connects to the IMS network, the device and the network engage in a process called IMS registration to make the user reachable under some of the identities. It is possible to be reachable using several public user identities at the same time. For example, if a SIP identity works on the Internet, and the TEL identity on the telephone network, it makes sense to have them both registered at the same time to be equally reachable from both worlds. The operator usually makes sure that in such case, if the user wants to be reachable on one of them, it implies also being reachable from the other. identity: • tel:number Services in traditional telephony, like conferencing or supplementary service self administration, are accessed using special phone numbers. A similar situation holds in IMS where a service is accessed using a Public Service IdentityIdentity (PSI). If ▇▇▇▇▇ wants to take part in a conference, she dials into the conference using its public service identityPSI. The conference server arranges for her participation. The identity A PSI is formatted as a SIP URIURI (like the user identity). The transition from single-media in voice telephony, to multi-media formats in IMS, means that the subscriber devices need the capability to handle such media. This is made possible since the phone has evolved from being a single-purpose device into a multi-purpose device. The devices can now also differ in their capabilities. In a network connecting only single purpose devices like traditional voice, it is assumed that all devices share that voice capability, regardless of their model and manufacturer. The network operator decides the standard to use such that all devices handle voice the same. If they don't they will not operate together. All devices are equivalent in terms of voice interoperability, and they have been developed for that purpose. When ▇▇▇▇▇ calls Bob, she does not care about Bob's phone model, the brand or other particular characteristics; only that she can talk to him. For ▇▇▇▇▇ to call Bob, their devices need to be the same in this respect. It creates symmetry of equivalence in capabilities between the endpoints in the context of the call made. Before IMS, the equivalence could be assumed to hold for voice and was trivial, but with IMS it is a problem that needs to be solved. The devices on the IMS vary in the multi-media capabilities and data formats they are capable of handling. For example, suppose a mobile phone and a PDA can do instant messaging. Then they are equivalent because they have that particular capability in common. Suppose further that the phone can do high quality voice communication, or that the PDA can stream live video from its high resolution built-in camera. If these capabilities are not met, there is no equivalence and it is meaningless to try to set up the calls. A shared symmetrical view of IMS devices cannot be assumed from just their presence on the network. It is crucial to decide whether they are equivalent when making an IMS call so that the multimedia exchange can work between the endpoints in the way intended. Internet and IMS standards use a notation that allows an IMS device to be marked as having certain capabilities. The set of common markers for a pair of devices describes the shared capabilities. If an IMS call requires a certain capability and its marker is in the common set, then there is equivalence. Advantages with this approach are that it will work regardless of device characteristics, and that new markers can be added for devices with new capabilities. A marker in a common set shows that capability can be used regardless of its semantics. The scheme of computing capabilities works not only for devices with a fixed set of built-in capabilities. It can also work for devices with a changeable set as well. Hardware related capabilities can change with plug-in accessories. Software related capabilities can change with downloadable applications. This latter approach is made possible with the IMS application model that the JSR 281 assumes. When writing an IMS application in JSR 281, it is fundamental to indicate its complete set of capabilities, the application capabilities, in the correct way. This is necessary for an IMS call to be routed through the IMS network to the right IMS application on the right device of the called subscriber. The application capabilities follow from the application program and are known at development time. When writing the application, the developer records the capabilities to be installed together with the application onto the end user device. The capabilities are of two types, basic and composed, described next. Basic capabilities are known in the IMSAPI. The IMS application gets them as a result of interacting with certain interfaces to IMS functionalities. Basic capabilities are of two subtypes: • Media capabilities, caused from using media interfaces. • Event capabilities, caused from using Subscription and Publication interfaces with event packages. The notation of capabilities, in relation to the Registry description, are described further below. Composed capabilities are capabilities that originate in the application, and are unknown to the IMSAPI. They can be composed of basic capabilities and other functionality. 3GPP has defined a framework to cover capabilities used in standardized network-based services. If a device implements a client for such a service, the capability is indicated in an IMS Communication Service Identifier (ICSI). The ICSI is defined in the service standard. The following is an example of an ICSI that may be defined by 3GPP for use in Multimedia Telephony standard: • urn:urn-xxx:3gpp-service.ims.icsi.mmtel The network operator manages the services, and an end user is allowed access to the service according to the subscription. Examples of services that can be coded as ICSIs are instant messaging, conferencing, Push-to-Talk Over Cellular (PoC). One of the strengths of IMS, and a prime purpose of the JSR 281, is to allow developers to write new IMS based applications, and have end users download and install them into their devices. These IMS applications have not undergone a standardization process, and have new capabilities not seen on the network before. This can for example be peer-to-peer games, or a new application of an existing network service, or some combination. To indicate such altogether new application capabilities, the IMS Application Reference Identifier (IARI) is used. The chess game could have an IARI that looks something like: • urn:IMSAPI:com.myCompany.chess An IMS application can support several ICSIs and IARIs at any given time. This section discusses the effect of using various combinations. Having multiple ICSIs has a straightforward use case where the IMS application is a client towards several standardized network communication services. An application that realizes several IARIs, might seem less logical considering the explanation above, but is useful in the following scenario. Suppose two IMS applications are developed, and are given IARI1 and IARI2, respectively. The applications become successful and well known. Then a third application is developed that adds a new functionality, while still supports both old applications. The third application gets, in addition to its IARI3, IARI1 and IARI2 as well. This enables backward compatibility. An IMS application can have any combination of ICSI and IARI. If it has no ICSI and no IARI, it means that no particular network services are used and the application adds no extra capability in itself. Such an application builds only on standardized media capabilities, or on standardized capabilities for a service not part of the ICSI/IARI framework. Examples are a streaming media player, a peer-to-peer chat application, or an application building on a standard outside the 3GPP application reference. If it has ICSI and no IARI, the application realizes a client for the service according to the standard, a default application. If it has no ICSI but an IARI, the application realizes its new logic without using any particular network service. Many peer-to-peer applications, like games, would be in this category. If it has both ICSI and IARI, the application makes use of standardized network service to create a new capability. ICSI and IARI are represented as Universal Resources Names (URN). URNs consists of a name space, and a name space specific string. The owner of the name space has control over allowed ▇▇▇▇. For ICSI, the standardisation organization is the name space owner and it has defined the ICSI URN. For IARI, the URNs are issued from any valid name space owner. The process of how to allocate an IARI is outside the scope of this specification.
Appears in 1 contract