WO2007034091A1

WO2007034091A1 - Recording method relating to a communication service, associated terminal and server

Info

Publication number: WO2007034091A1
Application number: PCT/FR2006/002177
Authority: WO
Inventors: Jean-François JESTIN; Eric Debeau
Original assignee: France Telecom
Priority date: 2005-09-26
Filing date: 2006-09-22
Publication date: 2007-03-29

Abstract

The invention concerns a method for recording a user (1) relating to a communication service, the user being provided with a terminal (2) adapted to communicate with a communication system (9). The invention is characterized in that it consists in transmitting, from the terminal, a recording request (10, 18) to a signaling server (3) of the communication system, the recording request including an identifier of the user (id); authenticating the user, to the signaling server, based on the user identifier; transmitting to the terminal, from the signaling server, a message accepting the recording (17, 24) when the user has been authenticated, said message including configuration data concerning the user.

Description

METHOD OF RECORDING IN RELATION TO A COMMUNICATION SERVICE TERMINAL AND SERVER

The present invention relates to access to communication services using terminals.

It includes, but is not limited to, access to voice and / or video services. More generally, it covers any service whose access requires a registration procedure.

Currently, access to such services, such as voice and / or video services using the Internet Protocol (IP) and commonly referred to as V ² OlP services, is done in two independent and successive phases.

The first phase consists of a configuration of the terminal used for access to the service. This configuration can be manual: it requires the intervention of a technician or the user of the terminal and poses obvious problems of terminal management and human error. Alternatively, the configuration can be automatic. It relies on standard download protocols, such as FTP ("File Transfer Protocol"), HTTP ("HyperText Transport Protocol"), SlP ("Session Initiation Protocol") or TFTP ("Trivial File Transfer Protocol"). ). It then requires the exchange of numerous messages between the terminal and a configuration server, in order to authenticate the user of the terminal and update its configuration.

An example of such an automatic configuration phase is, for example, described in the document "A Framework for Session Initiation Protocol User Agent Profile Delivery; draft-ietf-sipping-config-framework-06.txt", published in February 2005, by the IETF organization ("Internet Engineering Task Force").

The second phase consists of a registration with the service to which access is requested. This recording requires the exchange of messages between the terminal and a signaling server, in order to authenticate the user of the terminal and regularly convey information related to the user of the terminal. Thus, the access of a user to a service type V ² OlP for example requires the establishment of a large number of preliminary operations, some of which, such as authentication, are also redundant.

An object of the present invention is to simplify access to a communication service.

Another object of the invention is to reduce the signaling relating to the configuration and the recording to a communication service, such as a service type V ² OlP.

The invention thus proposes a method of registering a user with respect to a communication service, the user being provided with a terminal capable of communicating with a communication system. The method comprises the following steps:

transmitting, from the terminal, a registration request to a signaling server of the communication system, the registration request including an identifier of the user;

- authenticate the user, to the signaling server, from the identifier of the user; and

transmitting to the terminal, from the signaling server, a message accepting the registration when the user has been authenticated, said message including configuration information relating to the user.

Thus, the registration of the user with the service is accompanied by the transmission to the terminal of this user, configuration information. The configuration and registration operations are therefore coordinated, which simplifies access to the service while limiting the communication resources and signaling necessary for their implementation. In particular, only one authentication procedure can be performed in order to access the service. This authentication can be explicit or implicit. The configuration information transmitted to the terminal, in the acceptance message of the record, may depend on a state of prior configuration of the user. They may for example include an update of this configuration state. Alternatively, this configuration information may include a pointer to configuration parameters stored on a configuration server of the communication system.

The invention also proposes a terminal capable of communicating with a communication system and of being used by a user who may require a recording in relation to a communication service. The terminal comprises: means for transmitting a registration request to a signaling server of the communication system, the registration request including an identifier of the user; and

means for receiving, from the signaling server, a message accepting the record when the user has been authenticated, said message including configuration information relating to the user.

The invention further proposes a computer program product comprising code instructions for implementing the following steps, when it is loaded and executed on a terminal able to communicate with a communication system and to be used by a user. likely to require a registration for a communication service:

- Send a registration request to a signaling server of the communication system, the registration request including an identifier of the user; and

receiving, from the signaling server, a message accepting the record when the user has been authenticated, said message including configuration information relating to the user.

The invention also proposes a signaling server in a communication system, the signaling server being arranged to authorize the registration of a user with respect to a service of - A - communication, the user being provided with a terminal capable of communicating with a communication system, the signaling server comprising:

means for receiving, from the terminal, a registration request including an identifier of the user; means for authenticating the user from the user's identifier; and

means for transmitting to the terminal an acceptance message of the recording when the user has been authenticated, said message including configuration information relating to the user. The invention further provides a computer program product comprising code instructions for performing the following steps, when loaded and executed on a signaling server in a communication system, the signaling server being arranged to authorizing the registration of a user with respect to a communication service, the user being provided with a terminal capable of communicating with a communication system:

receiving, from the terminal, a registration request including an identifier of the user;

- authenticate the user from the user's identifier; and - transmitting to the terminal a message accepting the registration when the user has been authenticated, said message including configuration information relating to the user.

Other features and advantages of the present invention will become apparent in the following description of nonlimiting exemplary embodiments, with reference to the appended drawings, in which:

FIG. 1 is a diagram showing an exemplary system architecture in which the invention can be implemented;

FIG. 2 is a diagram illustrating messages exchanged in the context of a first embodiment of the invention; FIG. 3 is a diagram illustrating messages exchanged in the context of a second embodiment of the invention. FIG. 1 shows a user 1 of a terminal 2 capable of communicating with a communication system 9. The terminal 2 and the communication system 9 can use any technologies and communication protocols. For example, an IP type network protocol could be used. The communication system 9 may for example comprise a fixed access network according to one of the technologies xDSL ("x Digital Subscriber One"), RTC ("Switched Telephone Network"), HFC ("Hybrid Fiber Coax") or FTTH ( "Fiber to the home"), or a mobile access network according to one of the GSM technologies ("Global System for Mobile Communications"), GPRS ("General Packet Radio Service"), UMTS ("Universal Mobile Telecommunications System") ) or WLAN ("Wireless Local Area Network").

The communication system 9 is also able to offer the user 1, access to a communication service, such as a voice and / or video service. In this case, the terminal 2 must also support the implementation of such a service. In the context of such a communication service, the terminal 2 may thus be required to exchange voice or multimedia data with another terminal 7 for example.

In what follows, it is assumed that it is sought to give the user 1, via its terminal 2, access to a V ² service OlP offered by the communication system 9. It is also made to assumption that the terminal 2 as well as the communication system 9 use the signaling protocol

Session Initiation Protocol (SIP) as described in the RFC specification

3261 (Request for Comment 3261), published in June 2002 by the IETF. Of course, other protocols may also be considered, alternatively or complementary.

The communication system 9 comprises a signaling server 3 which supports the SIP protocol in the example described. This server is used to implement the configuration of the terminal 2 and the registration to the targeted service V ² OlP. It is further connected to two databases 4 and 5, respectively containing authentication and configuration information for users. FIG. 2 shows an example of the messages exchanged in the system of FIG. 1 for access to the targeted V ² OlP service. The terminal 2 first transmits to the signaling server 3, a registration request (message 10), in order to allow the access of the user 1 to the service V ² OlP referred to. Note that, in the case where the terminal 2 does not initially have an IP address and / or the address of the signaling server 3, they can be acquired by a conventional procedure involving a server 6 using DHCP ("Dynamic Host Configuration Protocol"). This procedure involves an exchange of messages between the terminal 2 and the DHCP server 6, possibly relayed by different nodes of the communication system 9. The registration request 10 can then include the acquired IP address and be transmitted to the signaling server 3 However, it is also conceivable that the terminal 2 has a permanent IP address and / or that it knows statically or by any other means, the address of the signaling server 3, making this address acquisition procedure unnecessary. IP and / or discovery of the address of the signaling server 3.

The registration request 10 includes an identifier of the user 1 (denoted "id" in FIG. 2). This identifier can be of any type: it can for example be a telephone number of the user 1. The fact of using a user identifier rather than a terminal identifier is advantageous because it allows to to ensure nomadic access to the targeted V ² OlP service, that is to say from any terminal, belonging or not to the user concerned.

Upon receipt of the registration request 10, an authentication procedure of the user 1 is initiated. In the example illustrated in FIG. 2, the signaling server 3 is able to obtain authentication information relating to the user 1. To do this, it can for example query the database 4. The latter contains a correspondence between user identifiers and authentication information. The signaling server 3 can then indicate to the database 4, the identifier of the user 1 that it has received (message 11), and obtain in response, the authentication information relating to the user 1 (message 12). The authentication information in question can be of any kind, such as a password for example.

The authentication can then continue for example according to the procedure provided for in the SIP protocol and described in particular in section 22.4 of the aforementioned RFC 3261, which itself refers to RFC 2617, "HTTP authentication: Basic and Digest Access Authentication". , published in June 1999 by NETF. According to this procedure, a message 13 is transmitted to the terminal 2, from the signaling server 3. This message 13 is a challenge message in the sense of the aforementioned RFCs. It triggers a response message 14 from the terminal 2. The response message 14 contains an authentication information derived from the value of the challenge message and a secret shared by the user 1 of the terminal 2 and the server 3. The secret is for example a password of the user 1, also obtained by the signaling server 3 from the database 4, using the above-mentioned message 12. The signaling server 3 also calculates an authentication information derived from the value of the challenge message and the shared secret with the user 1. Then, a consistency check between the authentication information respectively transmitted by the terminal 2 and calculated by the signaling server 3 is performed, for example at the server 3. In case of equality between the two authentication information, it is considered that the user is authenticated. In the opposite case, it is not and no registration takes place relative to the user 1 for the targeted service V ² OlP.

Note that the authentication procedure just described is advantageous because it avoids a clear transmission of the secret related to the user, such as his password, which limits the possibility of fraud by a passive attacker listening to the communication link between the terminal 2 and the signaling server 3. However, many other authentication methods can also be used. For example, a basic method in which the terminal 2 clearly transmits the password of the user 1 to the signaling server 3 is also possible, despite the risks it presents in terms of security. Furthermore, the signaling server 3 is able to obtain configuration information relating to the user 1. To do this, it can for example query the database 5. The latter contains a correspondence between user identifiers and configuration information. The signaling server 3 can then indicate to the database 5, the identifier of the user 1 that it has previously obtained (message 15), and obtain in response the configuration information relating to the user 1

(message 16). The configuration information in question may be diverse. They may for example depend on the type of terminal 2 used by the user 1.

When the user 1 has been authenticated, in accordance with the steps described above, the signaling server 3 transmits to the terminal 2 a message accepting the registration (message 17). If, on the other hand, the user 1 has not been successfully authenticated, no registration acceptance message is transmitted to the terminal 2, in order to limit access to the V ² OlP service targeted only to the users. allowed.

This registration acceptance message includes at least some of the configuration information returned to the signaling server 3 in the message 16. For example, when the user 1 has never accessed the targeted service V ² OlP, the The registration acceptance message may include all of the configuration information returned to the signaling server 3 in the message 16 and allowing access to that service.

Conversely, when the user 1 already has configuration information that allows him to access the service V ² OlP referred to, for example in the form of a configuration file stored at the terminal 2, the information of configuration included in the message 17 may then comprise only a sub-part of the configuration information necessary to access this service, as they are transmitted to the signaling server 3 in the message 16. For example, the configuration information transmitted in the message 17 of acceptance of the recording may comprise a simple update of the configuration file of which has the user 1. This update may consist of an indication of the differences between the configuration information provided to the server 3 and the content of the configuration file available to the user 1.

For this purpose, the configuration state of the user 1 can be transmitted to the signaling server 3, so that the latter can compare it with the configuration to be adopted. The configuration state information may advantageously be transmitted to the signaling server 3 in the message 14 and / or in the initial message 10, and include for example all the contents of the configuration file available to the user 1, or only an excerpt or version of this file. This mode of operation will be detailed in the embodiment illustrated in FIG.

2.

In an alternative embodiment of the invention, described with reference to FIGS. 1 and 2, the configuration to be adopted is not transmitted to the terminal 2 directly from the signaling server 3, but it is transmitted via of a configuration server 8. In this case, the configuration information transmitted by the signaling server 3 to the terminal 2 simply allows the latter to download the configuration parameters, that is to say the configuration to adopt, from the configuration server 8. This information may include for example a pointer to the configuration parameters to download, such as a URL ("Uniform Resource Locator"). Upon receipt of this information, the terminal 2 is then able to download the configuration parameters from the configuration server 8. Thus, according to the operating mode described above, the configuration and registration to the service V ² OlP target are realized in a coordinated way. The resources to implement these operations are shared, thanks to the use of a single signaling server for example. In addition, the number of messages exchanged to perform these operations is limited, especially since only one authentication procedure is required and some registration-related messages incorporate configuration information. It is noted that the steps described above can be implemented to allow the first registration of the user to the service.

V ² OlP referred to, that is to say while this user has never accessed this service. They can also be implemented for successive recordings of the same user to the targeted V ² OlP service. It is indeed possible to transmit to the signaling server, from the terminal of the user in question, periodic registration requests for example.

In this case, each of the recordings made for this user can be accompanied by an update of his configuration state, according to the principles described above.

FIG. 3 shows a second embodiment of the invention, in which the authentication procedure is implicit, and not explicit, as in the case of FIG. 2. According to this embodiment, in addition to an identifier of the user 1 (id), an identifier of the communication medium used by the terminal 2 (id | _oc) is incorporated in the registration request sent by the terminal 2 to the signaling server 3 (message 8). This mode of operation is particularly suitable in cases where there is an association between the user 1 and the terminal 2 and where the terminal is fixed and therefore uses the same communication medium over a long period of time. As an illustration, if the terminal 2 communicates with the communication system 9 via an ADSL line ("Asymmetric Digital Subscriber Line"), an identifier of said ADSL line may be transmitted in the registration request.

The incorporation of the identifier of the communication medium into the registration request can be made directly by the terminal 2 if it knows this identifier. In the opposite case, the identifier in question can be obtained using an access signaling server (not shown in FIG. 3) and the DHCP server 6. Thus, the registration request transmitted by the terminal 2 (message 18) is first received by the access signaling server. The corresponding message 18 comprises the IP address of the terminal 2, which has been allocated to it by the DHCP server 6. On reception of the registration request, the access signaling server interrogates a database (not represented) which contains the IP address association - identifier of the communication medium (idι_oc) _> this association having been performed when the IP address is issued by the DHCP server 6. The access signaling server can then retransmit the signaling server 3, the registration request received from the terminal 2, after having incorporated the identifier of the communication medium obtained. As a variant, the identifier of the communication medium could of course be transmitted to the signaling server 3 independently of the registration request.

Subsequently, the signaling server 3 queries the database

4 by indicating the identifier of the received communication medium (message 19). The database 4 then returns to the signaling server 3, the user identifier (message 20) that it stores in correspondence with said identifier of the communication medium.

The signaling server 3 then compares the user identifier included in the registration request with that returned by the database 4. In case of identity between these identifiers, the signaling server 3 can then decide that the user 1 is correctly authenticated. Otherwise, user 1 is not authenticated. This embodiment makes it possible to avoid the transmission of authentication messages, such as the challenge and response messages 13 and 14 used in the embodiment illustrated in FIG. 2, and thus further reduces the signaling necessary for the authentication. registration to the V ² service concerned.

Subsequently, the operations implemented are similar to those described with reference to FIG. 1. In particular, the configuration server 3 obtains, from the database 5, configuration information relating to the user 1 of the terminal 2 (message 22), in response to a query of this database 5 using the user's identifier (message 21).

When the user 1 has been authenticated according to the principles described above, the signaling server 3 transmits to the terminal 2, a message accepting the registration (message 24), which includes configuration information relating to this user. and obtained previously from the database 5. For this purpose, various variants of implementation are possible, as has been indicated in the embodiment described with reference to Figure 2.

In the example illustrated in FIG. 3, it is assumed that the user 1 has, before issuing the registration request, a configuration status, for example materialized by a configuration file stored on the terminal 2. A hash function is applied to this configuration file, in order to obtain a hashcode of limited size, which is transmitted by the terminal 2 to the signaling server 3. Any known hash function can be used for this purpose. The hash code is advantageously transmitted using the message 18 which carries the registration request, in order to avoid the transmission of an additional message.

After receiving the configuration information received from the database 5 (message 22), the signaling server 3 can calculate a hash code by applying the same hash function as the terminal 2 to this configuration information. A comparison of the hash codes at the signaling server 3 (step 23) can then make it possible to determine whether the configuration state stored at the terminal 2 corresponds to the configuration information relating to the user 1 and stored in the database. data 5.

If so, this means that user 1 already has up-to-date configuration information, so that no change in his configuration state is needed to access the intended V ² OlP service. Conversely, if the comparison reveals a difference between the two hash codes, an update of the configuration file stored at the terminal 2 is necessary. Appropriate configuration information is then transmitted to the terminal 2 in the message 24 of acceptance of the recording. This configuration information may consist of a new up-to-date configuration file, as stored at the database level 5. It may also include only the differences between the configuration information stored on either side, in order to limit the amount of data exchanged between the signaling server 3 and the terminal 2.

The use of hash codes that has just been described with reference to FIG. 3 can of course apply to the embodiment described above with reference to FIG. 2. It will be noted that, in the embodiment described with reference to FIG. 3 also, the configuration and the registration with the targeted V ² OlP service are carried out in a coordinated manner, using shared resources and using limited signaling.

Note further that the operations performed by the terminal 2 on the one hand and by the signaling server 3 on the other hand can advantageously be implemented using respective computer programs containing appropriate code instructions.

Claims

1. A method of registering a user (1) with respect to a communication service, the user being provided with a terminal (2) able to communicate with a communication system (9), the method comprising the following steps :

transmitting, from the terminal, a registration request (10; 18) to a signaling server (3) of the communication system, the registration request including an identifier of the user (id);

transmitting to the terminal, from the signaling server, a message accepting the registration (17; 24) when the user has been authenticated, said message including configuration information relating to the user.

2. Method according to claim 1, wherein the authentication of the user (1) comprises obtaining, at the signaling server (3), a first authentication information relating to the user from the user. identifier of the user (id) and a comparison, to the signaling server, of a second authentication information relating to the user transmitted to the signaling server from the terminal (2) with information derived from said first information authentication.

The method according to claim 2, wherein the second authentication information relating to the user (1) is transmitted to the signaling server (3) from the terminal (2) in a message (14) further including information a user-defined configuration state, and wherein the user-related configuration information transmitted to the terminal is determined based on said user-state configuration information.

4. The method of claim 1, wherein an identifier of a communication medium (idι.oc) used by the terminal (2) is further incorporated into the registration request (18), and in which the authentication of the user (1) comprises obtaining, by the signaling server (3), a user identifier (id) corresponding to said identifier of the communication medium (id | _oc) and a comparison of the identifier of the user obtained with the identifier of the user included in the registration request.

A method according to any one of the preceding claims, wherein the registration request (10; 18) includes configuration state information relating to the user, and wherein the configuration information relating to the user (1), transmitted to the terminal, are determined according to said configuration state information relating to the user.

The method of claim 3 or 5, wherein the configuration state information relating to the user (1) comprises a hash of a file including a configuration state relating to the user.

The method of any one of claims 3, 5 or 6, wherein said user-related configuration information transmitted to the terminal (2) includes updating the configuration state relating to the user, with respect to said user-related configuration status information transmitted to the signaling server (3).

The method of any of the preceding claims, wherein said user-related configuration information (1) transmitted to the terminal (2) includes a pointer to configuration parameters stored on a configuration server (8). ) of the communication system (9).

9. Terminal (2) capable of communicating with a communication system (9) and being used by a user (1) who may require a recording relating to a communication service, comprising: means for transmitting a registration request (10; 18) to a signaling server (3) of the communication system, the registration request including an identifier of the user (id); and

means for receiving, from the signaling server, a message accepting the registration (17; 24) when the user has been authenticated, said message including configuration information relating to the user.

A computer program product comprising code instructions for performing the following steps, when loaded and executed on a terminal (2) capable of communicating with a communication system (9) and for use by a user (1) who may require a registration for a communication service:

- transmit a registration request to a signaling server (3) of the communication system, the registration request (10; 18) including a user identifier (id); and

receiving, from the signaling server, an acceptance message (17; 24) of the record when the user has been authenticated, said message including configuration information relating to the user.

11. Signaling server (3) in a communication system (9), the signaling server being arranged to authorize the registration of a user (1) relative to a communication service, the user being provided with a terminal (2) adapted to communicate with a communication system, the signaling server comprising: means for receiving, from the terminal, a registration request (10; 18) including a user identifier (id);

means for authenticating the user from the user's identifier; and

means for transmitting to the terminal an acceptance message (17; 24) of the record when the user has been authenticated, said message including configuration information about the user.

A computer program product comprising code instructions for performing the following steps, when loaded and executed on a signaling server (3) in a communication system (9), the signaling server being arranged to authorize the registration of a user (1) with respect to a communication service, the user being provided with a terminal (2) capable of communicating with a communication system: - receiving, from the terminal, a request for a recording (10; 18) including an identifier of the user (id);

- authenticate the user from the user's identifier; and

transmitting to the terminal an acceptance message (17; 24) of the registration when the user has been authenticated, said message including configuration information relating to the user.