FR3111496A1 - Methods and servers for managing the services of an additional terminal in a SIP core network - Google Patents

Abstract

Methods and servers for managing the services of an additional terminal in a SIP core network A method for registering an additional terminal comprises a step (E30) of receiving a registration request from a client of voice over IP. It searches (E35) for an IP address known to the operator in this request and creates (E40) a context (CTX) comprising an address representing the address of the voice over IP client and at least one public identity associated with an account voice over IP in a SIP core network. This context (CTX) is used by a process for managing outgoing calls to access a service using a service profile of an account associated with said public identity. It is also used by a process for managing incoming services to redirect to the voice over IP client, an incoming service sent to said public identity in said network. Fig. 3

Description

Methods and servers for managing the services of an additional terminal in a SIP core network

The present invention is in the field of telecommunications and more particularly in the field of VoIP services (telephony, videophony, RCS, SMSoIP, etc.) based on a fixed or mobile SIP (Session Initiation Protocol) network core, for example of the standardized architecture type 3GPP IMS (in English IP Multimedia Subsystem) or even of architecture of the NGN (in English Next Generation Network) type.

It relates more particularly to methods and servers for allowing a so-called “additional” terminal to access voice over IP services in such networks. An additional terminal is for example a voice assistant such as the Alexa (registered trademark) and Google Home (registered trademark) products offered respectively by the companies Amazon (registered trademark) and Google LLC (registered trademark).

In the present application, the term "additional terminal" is more generally used to refer to any terminal which shares its public identity IMPU (in English IP Multimedia Public Identity) with a nominal terminal and which does not have a SIM card (in English Subscriber Identity Module) or eSIM. (embedded SIM in English).

The invention relates in particular to a mechanism for registering an additional terminal in the network, and then allowing it to access and/or receive voice over IP services.

Two main methods are known for registering and authenticating a terminal in a SIP network.

In a mobile network, the SIP identifiers (in English credentials) are stored in the SIM or eSIM card and the mobile IMS core network uses an EAP-AKA (Extensible Authentication Protocol - Authentication and Key Agreement) authentication mode based on the derivation of the information contained in the SIM/eSIM card. This mechanism is relatively simple.

On the other hand, fixed terminals do not have a SIM/eSIM card. They cannot therefore register and authenticate themselves according to the EAP-AKA mechanism and must download a configuration file including in particular the public identity of the IMPU terminal, the private identity of the IMPI terminal (in English IP Multimedia Private Identity) and the SIP password to allow its authentication. Authentication of these terminals is based on the Digest RFC 2917 method. This mechanism is more complicated, in particular because it requires downloading the configuration file.

The integration of an additional terminal can be done in a fixed or mobile network. If it is chosen to integrate the additional terminal into a mobile network, the IMS core must support both EAP-AKA authentication for registering the nominal mobile terminal and Digest mode for the voice assistant which does not include no SIM/eSIM card.

This recording mechanism and the management of these recordings in the operator's information system are complex. Registration information must be created by the real-time information system for each additional terminal detected. This information must be added to the VoIP account in the VoIP core network database, then be delivered to the VoIP stack attached to the additional terminal, all in a secure way… In addition, the VoIP SIP core network must be configured to authorize the registration and process the communication services of several terminals sharing the same IMPU public identity (activation of the standardized 3GPP Shared IMPU mode).

The invention aims in particular to offer a simplified mechanism for registering these additional terminals, this mechanism being secure and easy to integrate into fixed or mobile networks.

More specifically, and according to a first aspect, the invention relates to a method for registering an additional terminal implemented by a registration server, this method comprising:
- a step of receiving a registration request from a SIP client capable of registering in a SIP core network of an operator, to activate at least one service for the additional terminal in this network ;
- a step of searching for at least one IP address known to the operator in said registration request;
- a step of creating a context comprising at least one contact address representing the address of the SIP client and at least one public identity associated with an account managed by the operator in this network and associated with this IP address, this account that can be used to provide at least one service to said additional terminal and
a step of sending a response intended for said SIP client so that the latter determines the services from which the additional terminal can benefit.

Correlatively, the invention relates to a recording server comprising:
- A module for receiving a registration request from a SIP client capable of registering in an operator's SIP core network, to activate at least one service for an additional terminal in this network;
- A search module for at least one IP address known to the operator in said registration request;
- a module for creating a context comprising at least one contact address representing the address of the SIP client and at least one public identity associated with an account managed by the operator in this network and associated with this IP address, this account that can be used to provide at least one service to said additional terminal and
a module for sending a response intended for said SIP client so that the latter determines the services from which the additional terminal can benefit.

Thus, and remarkably, the invention proposes a registration mechanism in which the additional terminal is ultimately not technically registered in the operator's SIP core network but in the registration server and benefits from the voice over IP of a nominal terminal registered in the SIP core of the operator with which it is associated.

In a particular mode of implementation of the invention, the SIP client is a voice over IP client capable of activating at least one voice over IP service for the additional terminal and the account managed by the operator is an account of voice over IP of the nominal terminal.

The invention proposes to discover the IMPU public identity of this nominal terminal by analyzing the IP addresses contained in the registration requests sent to register the additional terminal in the SIP registration server.

Once this identifier has been identified, the invention proposes not to continue registering the additional terminal in the SIP core network, to allow the additional terminal to benefit from all or part of the services offered by the voice over IP account of the nominal terminal and to respond positively to the registration request so that the SIP client on which the additional terminal is based considers itself duly registered.

Management of the fictitious registration of the additional terminal and of all the services is essentially based on the context created by the registration server.

The invention is remarkable in that this registration mechanism is completely independent of the SIP core network.

A difficulty solved by the invention is to discover the public identity IMPU of the nominal terminal then to implicitly authenticate the additional terminal on the basis of an IP address allocated by the operator to the access point used by the additional terminal. The invention proposes to analyze all the IP addresses contained in the registration request and to check whether they are known to the operator and attached to a voice over IP account.

Such an IP address may in particular be an address assigned to an Internet access point which provides access to the additional terminal or else an address assigned to network equipment implementing an NAPT function.

In one embodiment, the registration request is a SIP REGISTER request and the IP addresses are looked up in the source IP address fields of the IP packet, or Instance-ID, Via, or Contact of this request.

In one embodiment, said at least one service usable by said additional terminal is explicitly recorded in said context and/or specified in said response.

The invention thus allows a very detailed mechanism for managing the services offered to the additional terminal.

In one embodiment, a duration of use of at least one service by said additional terminal is explicitly recorded in said context and/or specified in said response. This duration can for example be sent in an Expires parameter of the response to encourage the SIP client to send a new registration request before the expiry of this duration. This is a fictitious mechanism since the additional terminal is not registered in the core SIP network but it advantageously allows the operator to dynamically manage the contexts used by the invention.

In one embodiment of the invention, the response to the registration request generated by the registration server is negative if the latter determines that the brand and/or type of the additional terminal is not authorized. This brand information and/or type of additional terminal can be managed directly by the registration server or be obtained from the registration server from an identity server of the operator.

This additional terminal brand and/or type information allows the registration server to inform the additional terminal that it does not have authorization to access the services and therefore that it should not re-solicit the registration server, which translates into a reduction in its load and potentially in that of the operator's identity server.

This additional terminal brand and/or type information preconfigured in or obtained by the registration server allows the registration server to refuse the registration request, for example on the basis of a mask of the MAC address of these equipment and/or on the User Agent value of the additional terminal. The registration server can thus refuse or authorize the registration request sent by an additional terminal by checking whether the information contained in the Instance-ID and/or User Agent field of the registration request is compatible with that preconfigured in or obtained from the registration server.

According to a second aspect, the invention relates to a method for managing a request sent by an additional terminal to access a service in a SIP core network, this method comprising:
- A step of receiving a request for access to a service sent by a SIP client wrongly considering to be registered in said network;
- A step to check whether at least one item of information contained in the request for access to a service is recorded in a context in association with a public identity associated with a voice over IP account managed by an operator of said network;
- A step of sending a request to an entity of the SIP core network to establish said service for the SIP client using a service profile of this account.

Correlatively, the invention relates to a server for managing at least one request sent by an additional terminal to access a service in a SIP core network, this server comprising:
- A module for receiving a request for access to a service sent by a SIP client wrongly considering to be registered in said network;
- a module for checking whether at least one item of information contained in the request is recorded in a context in association with a public identity associated with an account managed by a network operator;
- a module for sending a request to an entity of the SIP core network to establish the service for the voice over IP client by using a service profile of this account.

According to the invention, the SIP client is not technically registered in the network. It is registered in the registration server. It is also said to be fictitiously registered in the network.

In one embodiment, the context is intended to be used to trigger, in the SIP core network, the establishment of a call between the SIP client, here a voice over IP client and a recipient, the request for access to a service being a SIP INVITE call setup request

The request to access a service can also be a SIP MESSAGE, SUBSCRIBE, OPTIONS, PUBLISH, REFER, or INFO request.

Thus and in a very remarkable way, the management of the request for access to a service is based on the OOTB mode (in English (Out Of The Blue) standardized by 3GPP. This operating mode allows a certified server (in English "trusted") by checking, for example, their IP address to access a service on behalf of a user with a VoIP subscription without being registered themselves.

For example, the invention proposes to use the OOTB mode for the management of outgoing calls in particular, to allow a certified server to make outgoing calls on behalf of a user having a VoIP subscription without being himself checked in.

This mode of operation is for example used by the voice mail servers to offer a call-back telephone service for the applicant or for a Click To Call telephone service.

As described later, the information contained in the request and sought in the context is:
- an IP address; and or
- information contained in a FROM and/or Preferred ID field of the request.

In a particular embodiment, the server for managing requests for access to a service can, as does the registration server, check whether the IP addresses contained in a request for access to a service are known to the operator and associated with a voice over IP account in the network, and when this is the case, create or update a context so as to dynamically manage a new IP address which has just been dynamically assigned to the point of port that provides connectivity to the additional terminal.

In one embodiment, the context further comprises the IP address obtained by the registration server and used to identify the account and this context is in particular intended to be used to manage the incoming services intended for the additional terminal.

Consequently, according to a third aspect, the invention relates to a method for managing an incoming service directed to an additional terminal of a nominal terminal, this method being implemented by an incoming service management server and comprising:
- a prior step of recording an identity assigned to said server as secondary called identity of the nominal terminal in a telephone application server to trigger a mechanism for redirecting a service directed to said nominal terminal to said management of incoming services;
- A step of receiving a service establishment request from said telephone application server;
- a step for verifying whether said service establishment request includes a public identity IMPU included in one of its fields and associated in a context with a contact address representing the address of a SIP client;
- A step of transferring said service establishment request to the contact address so that it is routed to said SIP client.

Correlatively, the invention relates to a server for managing incoming services directed to at least one additional terminal of a nominal terminal, this server comprising:
- a module for receiving a service establishment request from a telephone application server, this telephone server comprising at least one record of an identity assigned to said server as the secondary called identity of the nominal terminal to trigger a mechanism for redirecting a service directed to said nominal terminal to said incoming service management server;
- a module for checking whether said service establishment request includes a public identity IMPU included in one of its fields and associated in a context with a contact address representing the address of a SIP client;
- A module for transferring the service establishment request to the contact address so that it is routed to said SIP client.

Thus, and remarkably, the invention proposes to rely on the redirection mechanisms known to those skilled in the art to manage incoming services, for example incoming calls, directed to the additional terminal.

These redirection mechanisms can for example consist of simultaneous or sequential forwarding services (“forking”) programmed in the telephone application servers to manage the multi-terminal services.

In one embodiment of the invention, the context further comprises at least one service item of information defining at least one right of access to a service for at least one type of additional terminal. This service information can be managed directly by the registration server or obtained from the registration server from a carrier identity server.

This service information allows the service access request management server not to solicit the core VoIP network for an unauthorized service.

This service information obtained by the registration server and recorded in the context includes, for example, the brand or type of equipment authorized to access a particular service, for example on the basis of a mask of the MAC address of these equipment or information from the SIP client (User Agent) attached to the additional terminal. The server for managing requests for access to a service can thus refuse or authorize access to a service requested by an additional terminal by checking whether the information contained in the Instance-ID and/or User Agent field of the request for access to a service are compatible with those recorded in the context of the additional terminal.

The invention also relates to a SIP proxy server comprising a registration server, a service access request management server and an incoming service management server as mentioned above.

Each of the methods mentioned above can be implemented by a computer program.

Consequently, the invention also relates to a computer program on a recording medium, this program being capable of being implemented in a device or more generally in a computer. This program includes instructions allowing the implementation of at least one method described above.

This program may use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in partially compiled form, or in any other desirable form.

The invention also relates to an information medium or a recording medium readable by a computer, and comprising instructions of a computer program as mentioned above.

The information or recording medium can be any entity or device capable of storing programs. For example, the media may comprise a storage medium, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or even a magnetic recording medium, for example a floppy disk or a disk. hard, or flash memory.

On the other hand, the information or recording medium may be a transmissible medium such as an electrical or optical signal, which may be routed via an electrical or optical cable, by radio link, by wireless optical link or by other ways.

The program according to the invention can in particular be downloaded from an Internet-type network.

Alternatively, the information or recording medium may be an integrated circuit in which a program is incorporated, the circuit being adapted to execute or to be used in the execution of one of the methods as described previously.

Other characteristics and advantages of the present invention will become apparent from the description given below, with reference to the appended drawings which illustrate an example of embodiment devoid of any limiting character. In the figures:

FIG. 1 represents a proxy server in accordance with the invention in its environment.

FIG. 2 represents the proxy server of FIG. 1;

FIG. 3 represents in the form of a flowchart the main steps of a recording method in accordance with a particular embodiment of the invention;

FIG. 4 represents a context that can be used in a particular embodiment;

FIG. 5 represents in the form of a flowchart the main steps for managing a request for access to a service in accordance with one embodiment of the invention;

FIG. 6 represents in the form of a flowchart the main steps for managing an incoming service in accordance with one embodiment of the invention;

FIG. 7A represents the functional architecture of a recording server in accordance with one embodiment of the invention;

FIG. 7B represents the functional architecture of a server for managing requests for access to a service in accordance with one embodiment of the invention;

FIG. 7C represents the functional architecture of an incoming service management server in accordance with one embodiment of the invention; And

FIG. 8 represents the hardware architecture of these servers in accordance with one embodiment of the invention.

Detailed description of particular embodiments

We will now consider the case of a user having a nominal terminal TN and at least one additional terminal TA. This additional terminal TA does not include a SIM/eSIM card.

FIG. 1 represents a proxy server 100 in accordance with the invention in its environment.

It is assumed that the nominal terminal TN is registered in a core SIP network NCS _OP of an operator OP and that it benefits from voice over IP services. The telephone number of this VoIP line is called NUM _TN .

In the embodiment described here, the SIP core NCS _OP network is an IMS network. As a variant, this network is an NGN network.

In the embodiment described here, the additional terminal TA is under the coverage of an access point AP which defines a wireless local area network WLAN.

An address translation device NAPT (Network Address Port Translation) known to those skilled in the art, and integrated into the access point AP, establishes a correspondence between the private IPV4 addresses of the WLAN network and a public IPV4 address assigned via the network to the WAN (Wide Area Network) interface of the access point.

If the access point which provides access to the additional terminal is assigned an IPV6 address on its WAN interface by the operator, the access point allocates to the terminals connected to its LAN an IPV6 address bearing the same prefix as that of its WAN interface, the terminals completing the value of the IPV6 address with, for example, their own MAC address. These IPV6 addresses assigned to the access point and to the terminals connected to the LAN are therefore known to the operator.

In FIG. 1, an N _AMZ network managed by an AMZ entity providing the additional terminal TA has been represented. This network N _AMZ is interconnected by an Internet connection to a network N _OP managed by the operator OP, itself interconnected to the core network NCS _OP of core SIP.

In the embodiment described here, the N _AMZ network comprises an _AMZ SW web server interconnected to an _AMZ BD database, an _AMZ VoIP SIP (User Agent) client and an _AMZ SBC (Session Border Controller) controller. The web server SW _AMZ administered by the entity AMZ manages a plurality of additional terminals, including the additional terminal TA.

In the embodiment described here, the SIP VoIP client _AMZ is a voice over IP client.

In the embodiment described here, the SW _AMZ web server includes a WebRTC gateway configured to process signaling streams and media streams.

In the embodiment described here, the operator's network N _OP comprises an SBC _OP controller configured to communicate with the SBC _AMZ controller of the N _AMZ network, the proxy server 100 in accordance with the invention and an identity manager GI _OP (Enabler Identity). SBC _AMZ and SBC _OP are configured to establish a secure TLS tunnel.

We note below:
- @SW _AMZ the IP address of the SW _AMZ web server; it is recorded in a memory of the additional terminal TA
- @VoIPAMZ the address of the SIP VoIP _AMZ client attached to the additional terminal TA;
- @SBC _AMZ the address of the SBC _AMZ controller;
- @SBC _OP the address of the SBC _OP controller; And
- @100, the address of the proxy server 100 in accordance with the invention _.

Note that this architecture is independent of the SIP core network NCS _OP to which the user's nominal voice over IP terminal TN is connected.

FIG. 2 represents the proxy server 100 in a particular embodiment of the invention.

In the embodiment described here, the proxy server 100 includes:
a server SRV _REG configured to create a context CTX following a request for registration in the core SIP network NCS _OP sent by the SIP VoIP client _AMZ attached to the additional terminal TA;
- A server SRV _AS configured to manage requests for access to a service sent by the additional terminal TA using the context CTX;
- A server SRV _IC configured to manage the incoming services intended for the additional terminal TA using the context CTX; And
- the CTX context.

In the embodiment described here, the server SRV _REG plays the role of a SIP Registrar server but it does not register the SIP VoIP client _AMZ attached to the additional terminal TA in the SIP core network NCS _OP .

In the embodiment described here, the server SRV _AS for managing requests for access to a service is a B2BUA server (in English Back To Back User Agent) configured to send a call in OOTB mode (in English Out Of The Blue ) following an outgoing call request sent by the additional terminal TA.

In the embodiment described here, the incoming service management server SRV _IC is a B2BUA server or a proxy server capable of querying the database of the registration server SRV _REG .

FIG. 3 represents in the form of a flowchart the main steps of a method for registering the additional terminal TA, in accordance with a particular embodiment of the invention.

During a step E05, the additional terminal TA sends an HTTPS RACT activation request to the Web server SW _AMZ to register in the SIP core network NCS _OP so as to be able to subsequently access services, in particular send and receive voice over IP calls.

This request comprises a source address @IP _SOURCE supplied by the address translation device NAPT (IPV4) and the unique identifier ID _TA of the additional terminal TA. The source address @IP _SOURCE is a public IPV4 address corresponding to a public WAN address of the access point AP.

On receipt of this request, the server SW _AMZ interrogates (step E10) the database BD _AMZ to verify that the additional terminal TA is a terminal known to the entity AMZ and authorized by the latter to use services, for example of telephony.

If such is the case, the SW _AMZ server requests via a Web API, during a step E15, the activation of a service, at the level of the SIP VoIP _AMZ client. In the embodiment described here, it will be assumed that the activation concerns the activation of a voice over IP service.

This activation request includes the source address @IP _SOURCE .

During a step E20, the SIP VoIP _AMZ client of the N _AMZ network sends a SIP REGISTER request (registration request within the meaning of the invention) to the edge entity SBC _AMZ of the N _AMZ network. This request includes:
- any RURI, FROM and TO fields;
- a Contact field and a Via field comprising the @VoIP _AMZ address of the SIP VoIP _AMZ customer; And
- an Instance-ID field comprising the source address @IP _SOURCE .

In the embodiment described here, the transport protocol used between the _AMZ VoIP client and the _AMZ SBC controller is the UDP protocol.

During a step E25, the edge entity SBC _AMZ of the network NAMZ encapsulates the SIP REGISTER request in the secure TLS tunnel created with the controller SBC _OP of the operator network N _OP . The Contact and Via fields are changed to include the @SBC _AMZ address of the SBC _AMZ controller.

During a step E30, the SBC _OP controller of the operator network N _OP decrypts the message and transfers the SIP REGISTER request to the registration server SRV _REG of the proxy server 100. For this, the SBC _OP controller adds the address @ 100 of this server 100 in the Route header of the message. The Contact and Via fields are modified to include the SBC _NOP @address of the SBC _OP controller.

The transport protocol used between the SBC controller _OP and the proxy server 100 can for example be the UDP, TCP, STCP protocol, etc.

During a step E35, the registration server SRV _REG of the device 100 searches in the SIP REGISTER message for the IP address of the access point AP which offers connectivity to the additional terminal TA.

In the example described here, this address is the @IP _SOURCE address contained in the Instance-ID field. But in other configurations this address could be in another field of the SIP REGISTER message, for example in the SIP Via field or in the SIP Contact field. This address could also be the source IP address of the IP packet containing the SIP REGISTER message, typically in the case where the SIP VoIP client _AMZ attached to the terminal TA is directly integrated into the additional terminal TA.

Consequently, during step E35, the Registrar proxy server 100 searches for all the IP addresses of the SIP REGISTER message, and, for each of these IP addresses, the Registrar proxy server 100 queries the identity manager GI _OP to obtain any information concerning a voice over IP service attached to this IP address.

This is the case if this IP address (IPV4) or if the prefix of this IP address (IPV6) has been assigned to an access point and if this service exists.

In the embodiment described here, the proxy server Registrar 100 queries the identity manager GI _OP via an API.

More specifically, in the embodiment described here, when the identity manager GI _OP receives an IP address, it queries its DB _GI database to check whether this IP address (or prefix in IPV6) has been assigned by the operator OP and if a voice over IP service managed by the operator OP is attached to this IP address, and returns in its response 200 OK, the public identity IMPU associated with this voice over IP account. In addition, the identity manager GI _OP could provide additional service information such as for example a maximum number of additional authorized terminals, the brands and/or type of additional authorized terminals and which can be found in fields of the SIP protocol such as such as the SIP User Agent, the Instance-ID, etc., VoIP service information such as the authorization of usable outgoing and/or incoming calls, the maximum number of simultaneous calls authorized for additional terminals, the authorization of access to emergency services, authorization of access to value-added services, authorization of access to national and/or international landline and/or mobile correspondents, support for the videophone service, support messaging services of the RCS type (in English Rich Communication Suite), SMSoIP… this information can be used by the Proxy server 100 and limiting the interactions of the proxy server 100 to the strict minimum with the NCS _OP VoIP core.

In the embodiment described here, the nominal terminal TN benefits from voice over IP services, one of these public identities IMPU is the telephone number NUM _TN of the associated VoIP line. The home terminal TN does not need to be registered in the NCS _OP network. In particular, it can be switched off or out of radio coverage.

During a step E40, the registration server SRV _REG of the proxy server 100 creates a context CTX comprising:
- the address included in the Contact field of the SIP REGISTER message received in step E30. This address is that of the SBC _OP controller, but it is representative of the @VoIP _AMZ address of the SIP VoIP _AMZ client attached to the terminal TA;
- all the IP addresses of the SIP REGISTER message and associated with an account in the GI _OP identity manager and for each of them the IMPU public identities associated with this voice over IP account, including necessarily the telephone number NUM _TN of the VoIP line of the nominal terminal TN
- optionally, service information.

An example CTX context is shown in Figure 4 . In this example, it is considered that the only IP address of the SIP REGISTER message and associated with a voice over IP account is the address @IP _SOURCE of the access point AP and that the only public identity IMPU associated with a voice over account IP is the NUM _TN telephone number of the VoIP line of the nominal TN terminal.

In an embodiment described here, the registration server SRV _REG itself determines the services associated with this voice over IP account from which the additional terminal TA can benefit, and it explicitly registers these services in the context CTX. The registration server SRV _REG can for example authorize the additional terminal to send calls and/or to receive calls.

In another embodiment, the registration server SRV _REG determines the services associated with this voice over IP account from which the additional terminal TA can benefit based on the service information returned by the identity manager GI _OP.

During a step E45, the registration server SRV _REG of the proxy server 100 sends a 200 OK response to the controller SBC _OP . This response is intended for the SIP VoIP _AMZ client attached to the additional terminal TA and it includes information enabling the SIP VoIP _AMZ client attached to the additional terminal TA to determine the services from which the additional terminal TA can benefit. In the embodiment described here, by default, the additional terminal TA is authorized to send and receive voice over IP calls.

In one embodiment, the services usable by the additional terminal are explicitly specified in the SIP response.

In one embodiment of the invention, the services are granted by the registration server for a determined duration, this duration being recorded in the CTX context as represented in FIG.

In this embodiment, this duration can be sent in an Expires parameter of the 200 OK response to prompt the SIP VoIP _AMZ client attached to the additional terminal TA to send a new registration request before the expiry of this duration.

In the embodiment described here, the 200 OK response also includes a P-Associated-URI field including all the public identities IMPU obtained in step E35. This is not mandatory and it may not be interpretable by the SIP VoIP _AMZ client attached to the terminal TA if the latter does not conform to the IMS.

The 200 OK response is routed (steps E50 and E55) to the SIP VoIP _AMZ client attached to the additional terminal TA of the N _AMZ network via the TLS tunnel established between the controllers SBC _OP and SBC _AMZ .

The SIP VoIP client _AMZ attached to the additional terminal TA is then seen as registered in the heart of the VoIP network of the operator OP but it is not so from a technical point of view.

The SIP VoIP _AMZ client attached to the additional terminal TA records in the BD _AMZ database the fact that the additional terminal TA is fictitiously registered in the core VoIP network as well as the remaining duration Expires of this fictitious registration if it is present in the response 200 OK.

If this SIP VoIP _AMZ client attached to the additional terminal TA complies with the IMS, it can also memorize the public identities IMPU of the P-Associated-URI field, including the telephone number NUM _TN if this field is present in the response 200 OK. As a reminder, the first information present in this P-Associated-URI field is considered to be the default public identity. This information can also allow him to select a preferred public identity from among the plurality returned during outgoing calls by inserting it into the SIP FROM and/or P-Preferred-Id field. Furthermore, this information can be provided to the additional terminal TA if the latter can restore this information to its user, the choice of the public identity IMPU used for the call then being made by the user of the additional terminal TA.

Otherwise, the SIP VoIP _AMZ client ignores the P-Associated-URI header of the SIP 200 OK message.

During a step E60, the SIP VoIP client _AMZ attached to the additional terminal TA confirms the activation of the service to the Web server SW _AMZ .

During a step E65, the server SW _AMZ confirms the activation of the service to the additional terminal TA. It optionally provides the public identity IMPU of the VoIP line.

FIG. 5 represents in the form of a flowchart the main steps for managing a request for access to a service transmitted by the additional terminal TA in accordance with one embodiment of the invention.

In the embodiment described here, this request is a request to establish an outgoing call.

During a step F05, a user of the additional terminal TA asks, by a voice command, to call the called number NUM _CALLED . A call setup REA request is transmitted in HTTPS POST to the SW _AMZ Web server. It comprises the source address @IP _SOURCE of the access point AP and the voice command including the number NUM _CALLED .

During a step F10, the web server SW _AMZ applies a voice recognition algorithm to recognize the call command for the number NUM _CALLED , and interrogates the database BD _AMZ to determine whether the additional terminal TA is fictitiously registered in the SIP core network. This second condition is verified from the current Expires value recorded in the BD _AMZ database.

If this is the case, during a step F15, the Web server SW _AMZ uses an API of the SIP VoIP client _AMZ attached to the additional terminal TA to request the establishment of an outgoing voice over IP call to the number NUM _CALLED , using in the SDP offer (in English Session Description Protocol) the codecs supported by the WebRTC gateway of the SW _AMZ Web server and a listening IP address @IP _WRTC .

During a step F20, the SIP VoIP client _AMZ attached to the additional terminal TA generates a SIP INVITE message (call setup request within the meaning of the invention) comprising:
- in the RURI and TO fields the number called NUM _CALLED ;
- in the FROM field:
i/ a random “random” value if the SIP VoIP _AMZ client does not support the SIP P-Associated-URI header received in the 200 OK response at step E55; either
ii/ the or one of the telephone numbers of the VoIP line of the nominal terminal NUM _TN , if the SIP VoIP client _AMZ attached to the additional terminal TA supports this SIP header P-Associated-URI;
- in the CONTACT, VIA fields, the @VoIP _AMZ address of the SIP VoIP _AMZ client attached to the additional terminal TA, the Instance-ID parameter being valued by the source address @IP _SOURCE of the HTTPS call establishment request REA;
- in the SDP field, the information provided by the WebRTC gateway of the SW _AMZ Web server; And
- in the ROUTE field, the @SBC _AMZ address of the SBC _AMZ controller of the N _AMZ network.

Optionally, if the SIP VoIP _AMZ client attached to the additional terminal TA supports the SIP P-Associated-URI header and if the user of the terminal TA does not wish to present the public identity IMPU by default to his called party, the P-Preferred-ID field can be used by valuing it with one of the IMPU public identities present in the P-Associated-URI field received in the 200 OK REGISTER response.

In the embodiment described here, the SIP INVITE message is routed to the SBC _AMZ controller according to an unsecured transport protocol, for example UDP, TCP or STCP.

During a step F25, the SIP INVITE message is modified by the SBC _AMZ controller:
- the @IP _SDP address of the SDP generated by the WebRTC gateway is replaced by the @SBC _AMZ address of the SBC _AMZ controller;
- in the CONTACT, VIA fields, the @VoIP _AMZ address is replaced by the @SBC _AMZ address of the SBC _AMZ controller, the Instance-ID parameter is unchanged;
- in the ROUTE field, the @SBC _AMZ address is replaced by the @SBC _OP address of the SBC _OP controller of the N _OP network of the OP operator.

The SIP INVITE message is sent in the TLS tunnel to the SBC _OP controller.

During a step F30, the SIP INVITE message is modified by the SBC controller _OP :
- the @SBC _AMZ address of the SBC _AMZ controller is replaced by the @SBC _OP address of the SBC _OP controller in the SDP parameter;
- in the CONTACT, VIA fields, the @SBC _AMZ address of the SBC _AMZ controller is replaced by the @SBC _OP address of the SBC _OP controller, the Instance-ID parameter is unchanged;
- in the ROUTE field, the @SBC _OP address of the SBC _OP controller is replaced by the address @100 of the SRV _AS server for managing requests for access to a service included in the proxy server 100.

The SIP INVITE message is routed to the server SRV _AS for managing requests for access to a service. In the embodiment described here, the message is transported by an insecure transport protocol, for example UDP, TCP, STCP.

During a step F35, the server SRV _AS for managing requests for access to a service of the proxy server 100 checks whether an IP address contained in the SIP INVITE message is registered in a CTX context created by the SIP Registrar server ( step E40). This address can be for example the source IP address of the IP packet containing the SIP INVITE message, an address included in the SIP Via field or in the SIP Contact field or in the Instance-Id parameter. If the SRV _AS server finds a CTX context comprising an IP address in the SIP INVITE message, it authorizes the outgoing call. Otherwise, it returns a 403 Forbidden or 480 Calling Party not Registered SIP response to the _AMZ VoIP SIP client.

Alternatively or additionally, the server SRV _AS of the proxy server 100 checks whether a public identity IMPU contained in the SIP INVITE message at the level of the SIP FROM and/or P-Preferred-ID fields is registered in a CTX context created by the server SIP Registrar (step E40).

If the server SRV _AS for managing requests for access to a service integrated into the proxy server 100 authorizes the outgoing call, during a step F40 it modifies the SIP INVITE message:
- if the FROM field includes a random value (this is the case if the SIP VoIP _AMZ client has not interpreted the SIP P-Associated-URI header received in step E55), this value is replaced by the number telephone NUM _TN associated with the VoIP line assigned to the nominal terminal TN and stored in the context CTX;
- at least one PAI-certified calling identity (P-Asserted-ID) is added, corresponding to the public identity IMPU contained in the FROM field and certified;
- in the CONTACT field, the address @SBC _OP of the SBC _OP controller is replaced by the address @100 of the proxy server 100;
- in the ROUTE field, the address @100 of the proxy server is replaced by the IP address of the I-CSCF (Interrogating Call Session Control Function) entity of the NCS _OP network and the "orig" parameter is added so that the incoming call is processed in OOTB mode as if it were an outgoing call sent by the nominal terminal TN.

The SIP INVITE message is routed to the I-CSCF entity of the NCS _OP network.

In a known manner, when the I-CSCF detects the presence of the "orig" parameter in the ROUTE field of the SIP INVITE message, after having verified that the proxy server 100 is an authorized device, it understands that it must process the call in OOTB mode. He must therefore find the VoIP service profile of the account associated with the certified public identity IMPU present in the certified calling identity PAI of the SIP INVITE message, that is to say at the nominal terminal TN and not at that of the number called NUM _CALLED of the RURI or TO field.

This treatment is known to those skilled in the art. The I-CSCF consults the HSS database via the DIAMETER protocol by sending it an LIR (Location Information Request) message with the telephone number NUM _TN included in the PAI (P-Asserted-ID) parameter of the SIP INVITE message as a parameter. .

The HSS database returns to the I-CSCF the address of the S-CSCF supporting this IMS subscriber.

The S-CSCF entity has the profile of the service account associated with the public identity NUM _TN , in other words with the nominal terminal TN.

The S-CSCF modifies the SIP INVITE message. Especially :
- a P-Served-User header is added and valued with the public identity NUM _TN with the parameter Session = Orig;
- a ROUTE field is added and populated by the @TAS address of the TAS server

The S-CSCF sends the SIP INVITE message to the telephone application server TAS (Telephony Application Server in English), the P-Served-User parameter of this message being valued with the NUM _TN number and the Session=Orig parameter so that -ci runs Originating services.

If the number called NUM _CALLED is not barred via the Originating service, the SIP INVITE message is routed in the classic way to the recipient NUM _CALLED .

The VoIP _AMZ voice over IP client attached to the additional terminal TA receives a temporary SIP code 180 Ringing. It notifies the Web server SW _AMZ which in turn notifies the additional terminal TA and the latter generates a return ringtone.

The media stream is transmitted in secure mode via the SRTP protocol when this traffic borrows the public Internet IP network then in non-secure mode via the RTP protocol when this traffic borrows the N _AMZ network.

In the embodiment described above, the service accessed by the additional terminal TA is a voice over IP call request and the request is an INVITE request.

The invention applies in the same way to access other services. Simply search for the information (IP address and/or information contained in a FROM and/or P-Preferred-ID field) in the MESSAGE, INFO, SUBSCRIBE, OPTIONS, REFER, PUBLISH request sent by the SIP client to request the access to this service.

FIG. 6 represents in the form of a flowchart the main steps for managing an incoming service directed to an additional terminal TA in accordance with one embodiment of the invention.

In the embodiment described here, this method is implemented by the incoming service management server SRV _IC included in the proxy device 100.

It is assumed that an identity NUM ₁₀₀ assigned to the incoming service management server SRV _IC has been previously registered as the secondary called number of the terminal TN in the telephone application server TAS of the core SIP network NCS _OP so that that the telephone application server TAS triggers, when it detects an incoming service directed to the home terminal TN, a mechanism for redirecting this service to the server SRV _IC for managing incoming services.

In the embodiment described here, the incoming service is a voice over IP call and the redirection mechanism is simultaneous or sequential call forwarding of this call to the server SRV _IC .

This recording can be made for all the nominal terminals TN or be made only for the nominal terminals TN associated with a public identity IMPU registered in a context CTX. For example, this registration can be performed by the registration server SRV _REG .

Thus, going back to the example described in FIG. 3 of the fictitious recording of the additional terminal TA, when at step E35, the recording server SRV _REG obtains, from the database BD _GI of the manager of identities GI _OP the telephone number NUM _TN of the VoIP line associated with the nominal terminal TN, it registers the identity NUM ₁₀₀ of the server SRV _IC for managing incoming services as a secondary called number of the terminal TN in the telephone application server TAS.

Thus, and in a known manner, when an incoming call intended for the public identity IMPU of the nominal terminal TN contained in the SIP RURI and TO headers of a SIP INVITE message is presented to a SIP core NCS _OP network, the server The telephone application TAS directs this call to the nominal terminal TN, then simultaneously or sequentially to the server SRV _IC for managing incoming services. Such a mechanism is known to those skilled in the art as “forking”.

More specifically, and in a manner known to those skilled in the art, the telephone application server TAS generates an outgoing call of the call forwarding type with:
- the execution of Originating services. The TAS server checks in particular that the identity NUM ₁₀₀ of the SRV _IC server is indeed authorized by the Outgoing Call Barring service:
- generation of an outgoing SIP INVITE message in which:
- The RURI and TO fields include the identity NUM ₁₀₀ of the server SRV _IC for managing incoming services;
- the FROM and PAI fields include the FROM & PAI information of the SIP INVITE message received by the TAS;
- the CONTACT field contains the @TAS address of the TAS telephone application server;
- a DIVERSION and/or HISTORY INFO redirection field includes the public identity IMPU NUM _TN of the called VoIP line, the cause of forwarding parameter being set to FollowMe, and the forwarding counter being set to 1.

This INVITE message is received by the incoming service management server SRV _IC included in the proxy device 100 during a step G05.

During a step G10, the incoming service management server SRV _IC looks for:
- if the SIP INVITE message includes a DIVERSION or HISTORY INFO redirection SIP header; and when it does
- if a CTX context created by the registration server SRV _REG (as described with reference to FIG. 3) includes the public identity IMPU included in this redirection field DIVERSION or HISTORY INFO, in this case the public identity NUM _TN .

If this double condition is not satisfied, the SRV _IC server responds with a SIP error code, for example 404 Not Found or 480 Temporarily Unavailable or 403 Forbidden.

If no context is found, the SRV _IC server responds with a SIP error code, for example 404 Not Found or 480 Temporarily Unavailable or 403 Forbidden.

If a CTX context is found, during a step G15, the server SRV _IC modifies the INVITE message:
- in the RURI field, the identity NUM ₁₀₀ of the server SRV _IC is replaced by the @SBC _OP address of Contact included in the CTX context, representative of the @VoIP _AMZ address of the SIP VoIP _AMZ client attached to the additional terminal TA ; And
- in the TO field, the identity NUM ₁₀₀ of the server SRV _IC is replaced by the public identity IMPU NUM _TN contained in the SIP redirection DIVERSION or HISTORY-INFO field. This is a public identity IMPU of the P-Associated-URI field of the SIP 200 OK message generated by the registration server SRV _REG in step E45.

The DIVERSION and/or HISTORY INFO redirect SIP field can be removed.

The modified SIP message is routed to the SIP VoIP _AMZ client attached to the additional terminal TA via the SBC _OP controller of the operator, the TLS tunnel and the SBC _AMZ controller of the N _AMZ network.

The latter notifies the SW _AMZ web server of the incoming call. The SBC _AMZ server searches the BD _AMZ database for the unique identifier ID _TA of the additional terminal TA associated with the public identity IMPU NUM _TN contained in the TO of the SIP INVITE message, then notifies the incoming call to the additional terminal YOUR.

In the embodiment described previously, the server SRV _REG , the server SRV _AS for managing requests for access to a service and the server SRV _IC for managing incoming calls are integrated into a proxy server 100.

As a variant, the server SRV _REG , the server SRV _AS for managing requests for access to a service and the server SRV _IC for managing incoming calls can be separate equipment which shares the context CTX.

FIG. 7A represents the functional architecture of the registration server SRV _REG in a particular embodiment. It comprises :
- A module ME30 for receiving a registration request from a SIP client capable of registering in an operator's SIP core network to activate at least one service for an additional terminal;
- A search module ME35 for at least one IP address known to the operator in this registration request;
- a module ME40 for creating a context comprising at least one contact address representing the address of the SIP client attached to the additional terminal TA and at least one public identity associated with an account managed by the operator in said network, this account that can be used to provide at least one service to the additional terminal and
a module ME45 for sending a response intended for said SIP client attached to the additional terminal TA so that the latter determines the services from which the additional terminal can benefit.

FIG. 7B represents the functional architecture of the server SRV _AS for managing at least one request for access to a service sent by an additional terminal TA to access a service in a SIP core network, in a particular embodiment . This server comprising:
- A module MF30 for receiving a request for access to a service sent by a SIP client and wrongly considering to be registered in this network;
- a module MF35 to check whether at least one item of information contained in the request is recorded in a context in association with a public identity associated with an account managed by this operator in the network, this information possibly being an IP address and/or information contained in a FROM and/or P-Preferred-ID field of the request;
- A module MF40 for sending a request to an entity of the SIP core network to establish said service for the SIP client attached to the additional terminal TA using a service profile of this account.

FIG. 7C represents the functional architecture of the server SRV _IC for managing incoming services intended for an additional terminal of a nominal terminal in a particular embodiment. This server includes:
- a module MG05 for receiving a service establishment request from a telephone application server, this telephone server comprising at least one record of an identity assigned to said server as the secondary called number of the nominal terminal to trigger a mechanism for redirecting a service intended for said nominal terminal to said incoming service management server;
- a module MG10 to check whether said service establishment request includes a public identity IMPU included in one of its fields and associated in a context with a contact address representing the address of a SIP client;
- A module MG15 for transferring the service establishment request to the contact address so that it is routed to said SIP client attached to the additional terminal TA.

Each of these servers can have the hardware architecture of a computer as represented in FIG .

This computer ORD comprises in particular a processor 10, a random access memory of the RAM type 11, a read only memory of the ROM type 12, a rewritable non-volatile memory of the Flash type 14 and means of communication 13.

The ROM 12 constitutes a support in accordance with a particular embodiment of the invention. This memory comprises a computer program PG in accordance with a particular embodiment of the invention, which when it is executed by the processor 10, implements one or more of the methods of recording, managing outgoing calls or management of incoming calls according to the invention and described above with reference to Figures 3, 5 and 6.

In the embodiment described here, the memory 14 of the computer ORD includes a context CTX as described above, in particular with reference to Figure 4.

In the example of Figure 1, the NAPT address translation device is integrated into the AP module: it establishes a correspondence between the private IPV4 addresses of the WLAN network and a public IPV4 address assigned by the network to the WAN interface . The address translation function can also be implemented in CGN (Carrier Grade NAT) type network equipment.

Claims (15)

Method for registering an additional terminal (TA) implemented by a registration server (SRV _REG ), this method comprising:
- a step (E30) of receiving a registration request from a SIP client (VoIP _AMZ ) capable of registering in a network (NCS _OP ) of a SIP core of an operator (OP), for activating at least one service for the additional terminal (TA) in said network;
- a step (E35) of searching for at least one IP address known to the operator (OP) in said registration request;
- a step (E40) for creating a context (CTX) comprising at least one contact address (@SBC _OP ) representative of the address (@VoIP _AMZ ) of the SIP client (VoIP _AMZ ) and at least one public identity (NUM _TN ) associated with an account managed by the operator in said network (NCS _OP ) and associated with said IP address, this account being able to be used to provide at least one service to said additional terminal (TA) and
- A step (E45) of sending a response intended for said SIP client (VoIP _AMZ ) so that the latter determines the services from which the additional terminal (TA) can benefit. Registration method according to claim 1, in which said context (CTX) further includes said address obtained during said search step (E35) and associated with said account. Recording method according to Claim 1 or 2, in which the said context (CTX) further includes at least one piece of service information defining at least one right of access to a service for at least one type of additional terminal (TA). Recording method according to any one of Claims 1 to 3, in which the said context (CTX) is intended to be used for:
- triggering (F40), in said SIP core network (NCS _OP ), the establishment of a service for the SIP client (VoIP _AMZ ) using a service profile of an account associated with said public identity (NUM _TN ) and/or for
- redirect (G15) to said SIP client (VoIP _AMZ ), a service directed to said public identity (NUM _TN ) in said SIP core network (NCS _OP ). Registration method according to any one of Claims 1 to 4, in which the said registration request is a SIP REGISTER request and in that the said at least IP address sought (E35) in the said registration request is included in a field Source IP of the IP packet or Instance-ID, Via, or Contact of said request. Recording method according to any one of Claims 1 to 5, in which the said at least one service usable by the said additional terminal (TA) is explicitly recorded in the said context (CTX) and/or specified in the said response. Recording method according to any one of Claims 1 to 6, in which a duration of use of said at least one service by said additional terminal (TA) is explicitly recorded in said context (CTX) and/or specified in said response. Method for managing a request (REA) sent by an additional terminal (TA) to access a service in a SIP core network (NCS _OP ), this method comprising:
- A step (F30) of receiving a request for access to a service sent by a SIP client (VoIP _AMZ ) wrongly considering to be registered in said network (NCS _OP );
- a step (F35) to check whether at least one piece of information contained in the request for access to a service is recorded in a context (CTX) in association with a public identity (NUM _TN ) associated with an account managed by an operator of said network (NCS _OP );
- A step (F40) of sending a request to a SIP core network entity (NCS _OP ) to establish said service for said SIP client (VoIP _AMZ ) using a service profile of said account. Management method according to claim 8 wherein said at least one item of information is:
- an IP address; and or
- information contained in a FROM and/or P-Preferred-ID field of said request. Method for managing an incoming service directed to an additional terminal (TA) of a nominal terminal (TN), this method being implemented by a server (SRV _IC ) for managing incoming services and comprising:
- a prior step of recording an identity (NUM ₁₀₀ ) assigned to said server (SRV _IC ) as a secondary called identity of the nominal terminal (TN) in a telephone application server (TAS) to trigger a redirection of a service directed to said nominal terminal (TN) to said server (SRV _IC ) for managing incoming services;
- a step (G05) of receiving a service establishment request from said telephone application server (TAS);
- a step (G10) to check whether said service establishment request includes a public identity IMPU (NUM _TN ) included in one of its fields and associated in a context (CTX) with a representative contact address (@SBC _OP ) the address (@VoIP _AMZ ) of a SIP client (VoIP _AMZ );
- A step (G15) of transferring said service establishment request to the contact address so that it is routed to said SIP client (VoIP _AMZ ). Registration server (SRV _REG ) comprising:
- a module (ME30) for receiving a registration request from a SIP client (VoIP _AMZ ) capable of registering in a network (NCS _OP ) of an operator's (OP) SIP core, for activating at least one service for an additional terminal (TA) in said network;
- a module (ME35) for searching for at least one IP address known to the operator (OP) in said registration request;
- a module (ME40) for creating a context (CTX) comprising at least one contact address (@SBC _OP ) representative of the address (@VoIP _AMZ ) of the SIP client (VoIP _AMZ ) and at least one public identity (NUM _TN ) associated with an account managed by the operator in said network (NCS _OP ) and associated with said IP address, this account being able to be used to provide at least one service to said additional terminal (TA) and
- A module (ME45) for sending a response intended for said SIP client (VoIP _AMZ ) so that the latter determines the services from which the additional terminal (TA) can benefit. Server (SRV _AS ) for managing at least one request sent by an additional terminal (TA) to access a service in a SIP core network (NCS _OP ), this server comprising:
- A module (M30) for receiving a request for access to a service sent by a SIP client (VoIP _AMZ ) wrongly considering to be registered in said network (NCS _OP );
- a module (MF35) for checking whether at least one item of information contained in said request is recorded in a context (CTX) in association with a public identity (NUM _TN ) associated with an account managed by an operator (OP) of said network (NCS _PO );
- A module (MF40) for sending a request to a SIP core network entity (NCS _OP ) to establish said service for said SIP client (VoIP _AMZ ) using a service profile of said account. Server (SRV _IC ) for managing incoming services directed to at least one additional terminal (TA) of a nominal terminal (TN), this server comprising:
- a module (MG05) for receiving a service establishment request from a telephone application server (TAS), said telephone server (TAS) comprising at least one record of an identity (NUM ₁₀₀ ) assigned to said server (SRV _IC ) as secondary called identity of the nominal terminal (TN) to trigger a mechanism for redirecting a service directed to said nominal terminal (TN) to said server (SRV _IC ) for managing incoming services ;
- a module (G10) for checking whether said service establishment request includes a public identity IMPU (NUM _TN ) included in one of its fields and associated in a context (CTX) with a representative contact address (@SBC _OP ) the address (@VoIP _AMZ ) of a SIP client (VoIP _AMZ );
- A module (MG15) for transferring the service establishment request to the contact address so that it is routed to said SIP client (VoIP _AMZ ). SIP proxy server (100) comprising a registration server (SRV_REG) according to claim 11, a server (SRV_AS) for managing a request for access to a service according to claim 12 and a server (SRV_CI) for managing incoming services according to claim 13. Computer program (PG) comprising instructions configured to implement the steps of a method according to any one of claims 1 to 10 when executed by a computer (ORD).