WO2021260290A1 - Procedes et serveurs de gestion des services d'un terminal additionnel dans un reseau de coeur sip - Google Patents

Procedes et serveurs de gestion des services d'un terminal additionnel dans un reseau de coeur sip Download PDF

Info

Publication number
WO2021260290A1
WO2021260290A1 PCT/FR2021/051061 FR2021051061W WO2021260290A1 WO 2021260290 A1 WO2021260290 A1 WO 2021260290A1 FR 2021051061 W FR2021051061 W FR 2021051061W WO 2021260290 A1 WO2021260290 A1 WO 2021260290A1
Authority
WO
WIPO (PCT)
Prior art keywords
terminal
service
voipamz
server
sip
Prior art date
Application number
PCT/FR2021/051061
Other languages
English (en)
Inventor
Bertrand Bouvet
Original Assignee
Orange
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange filed Critical Orange
Publication of WO2021260290A1 publication Critical patent/WO2021260290A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1073—Registration or de-registration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1045—Proxies, e.g. for session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/12—Setup of transport tunnels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/11—Allocation or use of connection identifiers

Definitions

  • the present invention is in the field of telecommunications and more particularly in the field of VoIP services (telephony, Video telephony, RCS, SMSoIP, etc.) based on a fixed or SIP (Session Initiation Protocol) core network.
  • mobile for example of standardized 3GPP IMS (IP Multimedia Subsystem) architecture type or even NGN (Next Generation Network) type architecture.
  • 3GPP IMS IP Multimedia Subsystem
  • NGN Next Generation Network
  • 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).
  • one more generally calls “additional terminal” any terminal which shares its public identity IMPU (in English IP Multimedia Public Identity) with a nominal terminal and which does not have or does not use a SIM card (in English Subscriber Identity Module) or eSIM (in English embedded SIM) to register in the network.
  • IMPU in English IP Multimedia Public Identity
  • SIM card in English Subscriber Identity Module
  • eSIM in English embedded SIM
  • 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.
  • 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 derivation of the information contained in the SIM / eSIM card.
  • EAP-AKA Extensible Authentication Protocol - Authentication and Key Agreement
  • 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 authentication EAP-AKA for registration of the nominal mobile terminal and Digest mode for the voice assistant which does not include a SIM / eSIM card.
  • This recording mechanism and the management of these records 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, and then delivered to the VoIP stack attached to the additional terminal, all in a secure manner ...
  • the VoIP SIP core network must be configured to authorize the registration and process the communication services of several terminals sharing the same public IMPU identity (activation of the standardized 3GPP Shared IMPU mode).
  • the invention aims in particular to provide a simplified mechanism for registering these additional terminals, this mechanism being secure and easy to integrate into fixed or mobile networks.
  • the invention relates to a method for registering an additional terminal implemented by a registration server, said additional terminal being a terminal which shares its public identity with a nominal terminal, this process comprising:
  • a step of creating a context comprising at least one contact address representative of the address of the SIP client and at least one public identity associated with an account of said nominal terminal managed by the operator in this network and associated with this address IP, this account being able to be used to provide at least one service to said additional terminal;
  • the invention relates to a recording server comprising:
  • a module for creating a context comprising at least one contact address representative of the address of the SIP client and at least one public identity associated with an account of said nominal terminal managed by the operator in this network and associated with this address IP, this account being able to be used to provide at least one service to said additional terminal;
  • 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 account of voice over IP of a nominal terminal registered in the SIP core of the operator to which it is associated.
  • 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 a user account. voice over IP of the nominal terminal.
  • the invention proposes to discover the public identity IMPU of this home terminal by analyzing the IP addresses contained in the registration requests sent to register the additional terminal in the SIP registration server.
  • 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. nominal terminal and respond positively to the registration request so that the SIP client on which the additional terminal is based considers itself duly registered.
  • the 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 home terminal and 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 can 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 a NAPT function.
  • the registration request is a SIP REGISTER request and the IP addresses are searched for in the source IP address fields of the IP packet, or Instance-ID, Via, or Contact of this request.
  • 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 fine mechanism for managing the services offered to the additional terminal.
  • a duration of use of the 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 expiration of this duration.
  • 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 and / or type of additional terminal information can be managed directly by the registration server or be obtained from the registration server from an identity server of the operator.
  • This brand and / or type of additional terminal information allows the registration server to inform the additional terminal that it does not have authorization to access the services and therefore that it must not re-request the registration server which results in a reduction in its load and potentially that of the operator's identity server.
  • This brand and / or type of additional terminal 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 the value of the User Agent 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 those preconfigured in or obtained from the recording server.
  • the invention relates to a method for managing a request sent by an additional terminal to access a service in a SIP core network, said additional terminal being a terminal which shares its public identity with a nominal terminal, this process comprising:
  • 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, said additional terminal being a terminal which shares its public identity with a nominal terminal, this server comprising:
  • the SIP client is not technically registered in the network. It is registered in the registration server. It is also said that it is fictitiously registered in the network.
  • 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 request for establishment of a SIP INVITE call
  • the request for access to a service can also in particular be a SIP MESSAGE, SUBSCRIBE, OPTIONS, PUBLISH, REFER, or INFO request.
  • the management of the request for access to a service is based on the standardized OOTB (Out Of The Blue) mode of 3GPP.
  • This operating mode allows a certified server (in English “Trusted”) by controlling, for example, its IP address to access a service on behalf of a user with a VoIP subscription without being registered himself.
  • 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 operating mode is for example used by voice mail servers to offer a reminder telephone service for the depositor or for a Click To Call telephone service.
  • the information contained in the request and sought in the context is:
  • the server for managing requests for access to a service can, like the registration server, check whether the IP addresses contained in a request for access to a service are known to the user. 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 'access that offers connectivity to the additional terminal.
  • 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.
  • the invention relates to a method for managing an incoming service directed to an additional terminal of a nominal terminal, said additional terminal being a terminal which shares its public identity with said nominal terminal, this method being implemented by an incoming service management server and comprising:
  • a step 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 representative of the address of a SIP client attached to the additional terminal;
  • the invention relates to a management server for incoming services directed to at least one additional terminal of a nominal terminal, said additional terminal being a terminal which shares its public identity with said 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 a called secondary identity of the nominal terminal to trigger a mechanism for redirecting a service directed to said home 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 representative of the address of a SIP client attached to the additional terminal;
  • the invention proposes to rely on the redirection mechanisms known to those skilled in the art to manage the incoming services, for example the incoming calls, directed to the additional terminal.
  • redirection mechanisms can for example be constituted by the simultaneous or sequential forwarding services (in English "forking") programmed in the telephone application servers to manage the multi-terminal services.
  • 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 recording server or obtained from the recording server from an operator identity server.
  • This service information enables the service access request management server not to solicit the VoIP core 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 server for managing requests for access to a service and a server for managing incoming services as mentioned above.
  • 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 can 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 a partially compiled form, or in any other. desirable shape.
  • 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 the programs.
  • the media can include a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or else a magnetic recording means, for example a floppy disk or a disk. hard, or flash memory.
  • the information or recording medium can be a transmissible medium such as an electrical or optical signal, which can 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.
  • the information or recording medium can 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 above.
  • FIG. 1 represents a proxy server according to the invention in its environment.
  • Figure 2 shows the proxy server of Figure 1
  • FIG. 3 represents in flowchart form the main steps of a recording method in accordance with a particular embodiment of the invention
  • FIG. 4 represents a context which can be used in a particular embodiment
  • FIG. 5 represents in flowchart form the main steps of 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 of management of an incoming service in accordance with one embodiment of the invention
  • FIG. 7A represents the functional architecture of a recording server according to 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 according to one embodiment of the invention.
  • FIG. 8 represents the hardware architecture of these servers in accordance with one embodiment of the invention.
  • This additional TA terminal does not include or use a SIM / eSIM card.
  • FIG. 1 represents a proxy server 100 in accordance with the invention in its environment.
  • NUMTN The telephone number of this VoIP line is called NUMTN.
  • the SIP core NCSOP network is an IMS network.
  • this network is an NGN network.
  • the additional terminal TA is under the coverage of an access point AP which defines a wireless local area network WLAN.
  • a NAPT (Network Address Port Translation) address translation device 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 an allocated public IPV4 address. via the network to the WAN (Wide Area Network) interface of the access point.
  • WAN Wide Area Network
  • 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 on its LAN, an IPV6 address bearing the same prefix as that of its WAN interface, the terminals supplementing the value of the IPV6 address with, for example, their own MAC address.
  • IPV6 addresses assigned to the access point and to the terminals connected to the LAN are therefore known to the operator.
  • FIG. 1 shows a NAMZ network managed by an AMZ entity providing the additional terminal TA.
  • This NAMZ network is interconnected by an Internet link to a NOP network managed by the operator OP, itself interconnected to the NCSOP core network of SIP core.
  • the NAMZ network includes a SWAMZ web server interconnected to a BDAMZ database, a VOIPAMZ SIP (User Agent) client and a SBCAMZ (Session Border Controller).
  • the SWAMZ web server administered by the AMZ entity manages a plurality of additional terminals, including the additional terminal TA.
  • This VOIPAMZ SIP client is able to register in the NCSOP SIP core network of an operator to activate at least one service for the additional terminal in said network.
  • the VOIPAMZ SIP client is a voice over IP client.
  • the VOIPAMZ SIP client is able to register in the NCSOP network to activate the voice over IP service for the additional terminal TA.
  • the SWAMZ web server includes a WebRTC gateway configured to process signaling streams and media streams.
  • the operator's NOP network comprises an SBCOP controller configured to communicate with the SBCAMZ controller of the NAMZ network, the proxy server 100 in accordance with the invention and a GIOP (in English Enabler) identity manager. Identity).
  • the SBCAMZ and SBCOP controllers are configured to establish a secure TLS tunnel.
  • FIG. 2 represents the proxy server 100 in a particular embodiment of the invention.
  • the proxy server 100 comprises:
  • an SRVREG server configured to create a CTX context following a registration request in the SIP core NCSOP network sent by the VOIPAMZ SIP client attached to the additional terminal TA;
  • an SRVAS server configured to manage requests for access to a service sent by the additional terminal TA using the CTX context
  • an SRVic server configured to manage the incoming services intended for the additional terminal TA using the CTX context
  • the SRVREG server plays the role of a SIP Registrar server but it does not register the SIP VOIPAMZ client attached to the additional terminal TA in the SIP core NCSOP network.
  • the SRVAS server for managing requests for access to a service is a B2BUA (Back To Back User Agent) server configured to send a call in OOTB (Out Of The Blue) mode. following an outgoing call request sent by the additional terminal TA.
  • B2BUA Back To Back User Agent
  • the incoming service management SRVic server is a B2BUA server or a proxy server capable of interrogating the database of the SRVREG registration server.
  • 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.
  • the additional terminal TA sends an HTTPS RACT activation request to the SWAMZ web server to register in the SIP core NCSOP network so that it can subsequently access services, in particular send and receive messages. voice over IP calls.
  • This request includes a source address @ IPSOUR ⁇ supplied by the NAPT address translation device (IPV4) and the unique identifier IDTA of the additional terminal TA.
  • the source address @ IPSOUR ⁇ is a public IPV4 address corresponding to a public WAN address of the access point AP.
  • the SWAMZ server interrogates (step E10) the BDAMZ database 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 telephony. .
  • the SWAMZ server requests via a Web API, during a step E15, the activation of a service, at the level of the VOIPAMZ SIP client.
  • the activation relates to the activation of a voice over IP service.
  • This activation request includes the source address @ IPSOUR ⁇ .
  • the SIP VOIPAMZ client of the NAMZ network sends a SIP REGISTER request (registration request within the meaning of the invention) to the SBCAMZ edge entity of the NAMZ network.
  • This request includes:
  • the transport protocol used between the VOIPAMZ client and the SBCAMZ controller is the UDP protocol.
  • the edge entity SBCAMZ of the NAMZ network encapsulates the SIP REGISTER request in the secure TLS tunnel created with the SBCOP controller of the NOP operator network.
  • the Contact and Via fields are modified to include the @SBCAMZ address of the SBCAMZ controller.
  • the SBCOP controller of the NOP operator network decrypts the message and transfers the SIP REGISTER request to the SRVREG registration server of the proxy server 100. For this, the SBCOP controller adds the @ 100 address of this server 100 in the Route header of the message.
  • the Contact and Via fields are modified to include the @ SBCNOP address of the SBCOP controller.
  • the transport protocol used between the SBCOP controller and the proxy server 100 can for example be the UDP, TCP, STCP ...
  • the registration server SRVREG 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.
  • this address is the @IPSOURCE 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 VOIPAMZ client attached to the terminal TA is directly integrated into the additional terminal TA.
  • the proxy server Registrar 100 searches for all the IP addresses of the SIP REGISTER message, and, for each of these IP addresses, the proxy server Registrar 100 queries the GIOP identity manager to obtain the any information concerning a voice over IP service, attached to this IP address.
  • IPV4 IP address
  • IPV6 IP address
  • the Registrar proxy server 100 queries the GIOP identity manager via an API.
  • the GIOP identity manager when it receives an IP address, it queries its BDGI database to check whether this IP address (or prefix in IPV6) has been allocated 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 200 OK response, the public identity IMPU associated with this voice over IP account.
  • the GIOP identity manager could provide additional service information such as, for example, a maximum number of additional terminals authorized, the brands and / or type of additional terminals authorized and which can be found in fields of the SIP protocol such as the SIP User Agent, Instance-ID, ..., VoIP service information such as the authorization of outgoing and / or incoming calls that can be used, the maximum number of simultaneous calls authorized for the additional terminals, the authorization access to emergency services, authorization of access to value-added services, authorization of access to national and / or international fixed and / or mobile correspondents, support for the videophone service, support for RCS (Rich Communication) type messaging services Continued), SMSoIP ... this information can be used by the Proxy server 100 and limiting the interactions of the proxy server 100 with the NCSOP VoIP core to the strict minimum.
  • SIP protocol such as the SIP User Agent, Instance-ID, ...
  • VoIP service information such as the authorization of outgoing and / or incoming calls that can be used, the maximum number of simultaneous calls authorized for the additional terminals
  • the nominal terminal TN benefits from voice over IP services, one of these public identities IMPU is the telephone number NUMTN of the associated VoIP line.
  • the nominal TN terminal does not need to be registered in the NCSOP network. In particular, it can be off or out of radio coverage.
  • the registration server SRVREG of the proxy server 100 creates a CTX context comprising:
  • This address is that of the SBCOP controller, but it is representative of the @VOIPAMZ address of the SIP VOIPAMZ client attached to the TA terminal;
  • CTX context An example of a CTX context is represented in FIG. 4.
  • the only IP address of the SIP REGISTER message and associated with a voice over IP account is the @ IPSOUR ⁇ address of the access point AP and that the only public identity IMPU associated with a voice over IP account is the telephone number NUMTN of the VoIP line of the nominal terminal TN.
  • the registration server SRVREG 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 CTX context.
  • the SRVREG registration server can for example authorize the additional terminal to make and / or receive calls.
  • the registration server SRVREG determines the services associated with this voice over IP account from which the additional terminal TA can benefit on the basis of the service information returned by the identity manager GIOP.
  • the registration server SRVREG of the proxy server 100 sends a 200 OK response to the SBCOP controller.
  • This response is intended for the SIP VOIPAMZ client attached to the additional terminal TA and it comprises information allowing the SIP VOIPAMZ client attached to the additional terminal TA to determine the services from which the additional terminal TA can benefit.
  • the additional terminal TA is authorized to send and receive voice over IP calls.
  • the services usable by the additional terminal are explicitly specified in the SIP response.
  • the services are granted by the recording server for a determined duration, this duration being recorded in the CTX context as represented in FIG. 4.
  • this duration can be sent in an Expires parameter of the 200 OK response to encourage the SIP VOIPAMZ client attached to the additional terminal TA to send a new registration request before the expiration of this duration.
  • the 200 OK response also includes a P-Associated-URI field comprising all of the public identities IMPU obtained in step E35. This is not mandatory and it may not be interpretable by the VOIPAMZ SIP client attached to the TA terminal if the latter does not comply with the IMS.
  • the 200 OK response is routed (steps E50 and E55) to the SIP VOIPAMZ client attached to the additional terminal TA of the NAMZ network via the TLS tunnel established between the SBCOP and SBCAMZ controllers.
  • the VOIPAMZ SIP client 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 from a technical point of view.
  • the VOIPAMZ SIP client attached to the additional terminal TA records in the BDAMZ database the fact that the additional terminal TA is fictitiously registered at the core of the VoIP network as well as the remaining duration Expires of this fictitious registration if this is present in the response. 200 OK.
  • this VOIPAMZ SIP client attached to the additional terminal TA can also store the IMPU public identities of the P-Associated-URI field, including the telephone number NUMTN if this field is present in the 200 OK response.
  • the first information present in this P-Associated-URI field is considered to be the default public identity.
  • This information can also enable it to select a preferred public identity from among the plurality returned during outgoing calls by inserting it in the SIP FROM and / or P-Preferred-Id field.
  • this information can be supplied 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.
  • the VOIPAMZ SIP client ignores the P-Associated-URI header of the SIP 200 OK message.
  • the SIP VOIPAMZ client attached to the additional terminal TA confirms the activation of the service to the SWAMZ Web server.
  • the SWAMZ server confirms the activation of the service to the additional terminal TA. It optionally provides the public IMPU identity of the VoIP line.
  • FIG. 5 represents in the form of a flowchart the main steps of managing a request for access to a service sent by the additional terminal TA in accordance with one embodiment of the invention.
  • this request is a request to set up an outgoing call.
  • a user of the additional terminal TA requests, by a voice command, to call the number called NUMCALLED.
  • a REA call establishment request is sent in HTTPS POST to the SWAMZ web server. It includes the source address @ IPSOUR ⁇ of the access point AP and the voice command including the NUMCALLED number.
  • the SWAMZ Web server applies a voice recognition algorithm to recognize the call command of the NUMCALLED number, and interrogates the BDAMZ database to determine whether the additional terminal TA is fictitiously registered in the network of SIP core. This second condition is verified from the current value Expires recorded in the BDAMZ database.
  • the SWAMZ Web server uses an API of the VOIPAMZ SIP client attached to the additional terminal TA to request the establishment of an outgoing voice over IP call to the NUMCALLED number, by using in the SDP (Session Description Protocol) offer the codes supported by the WebRTC gateway of the SWAMZ Web server and a listening IP address @IPWRTC.
  • SDP Session Description Protocol
  • the VOIPAMZ SIP client attached to the additional terminal TA generates a SIP INVITE message (call establishment request within the meaning of the invention) comprising:
  • the field P-Preferred-ID 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.
  • the SIP INVITE message is routed to the SBCAMZ controller according to an unsecured transport protocol, for example UDP, TCP or STCP.
  • an unsecured transport protocol for example UDP, TCP or STCP.
  • the SIP INVITE message is modified by the SBCAMZ controller:
  • the @VOIPAMZ address is replaced by the @SBCAMZ address of the SBCAMZ controller, the Instance-ID parameter is unchanged;
  • the @SBCAMZ address is replaced by the @SBCOP address of the SBCOP controller of the NOP network of the OP operator.
  • the SIP INVITE message is sent in the TLS tunnel to the SBCOP controller.
  • the SIP INVITE message is modified by the SBCOP controller:
  • the @SBCAMZ address of the SBCAMZ controller is replaced by the @SBCOP address of the SBCOP controller, the Instance-ID parameter is unchanged;
  • the @SBCOP address of the SBCOP controller is replaced by the @ 100 address of the SRVAS server for managing requests for access to a service included in the proxy server 100.
  • the SIP INVITE message is routed to the SRVAS server for managing requests for access to a service.
  • the message is transported by an unsecured transport protocol, for example UDP, TCP, STCP.
  • the SRVAS server 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 SRVAS server finds a CTX context with an IP address in the SIP INVITE message, it authorizes the outgoing call. Otherwise, it sends a 403 Forbidden or 480 Calling Party not Registered SIP response to the VOIPAMZ SIP client.
  • the SRVAS server of the proxy server 100 checks whether an IMPU public identity contained in the SIP INVITE message at the level of the SIP FROM and / or P-Preferred-ID fields is recorded in a CTX context created by the SIP server Registrar (step E40).
  • the SRVAS server 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:
  • this value is replaced by the number of NUMTN telephone associated with the VoIP line assigned to the nominal TN terminal and stored in the CTX context;
  • At least one certified calling identity PAI (P-Asserted-ID) is added, corresponding to the public identity IMPU contained in the FROM field and certified;
  • the @SBCOP address of the SBCOP controller is replaced by the @ 100 address proxy server 100;
  • 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 NCSOP network and the "orig" parameter is added so that the incoming call is treated in OOTB mode as if it were an outgoing call sent by the home terminal TN.
  • I-CSCF Interrogating Call Session Control Function
  • the SIP INVITE message is routed to the I-CSCF entity of the NCSOP network.
  • 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. It 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 that of the number. called NUMCALLED of the RURI or TO field.
  • the I-CSCF consults the HSS database via the DIAMETER protocol by sending it an LIR (Location Information Request) message with the telephone number NUMTN as parameter included in the PAI (P-Asserted-ID) parameter of the SIP INVITE message.
  • LIR Location Information Request
  • 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 NUMTN, in other words with the nominal terminal TN.
  • the S-CSCF modifies the SIP INVITE message. Specifically :
  • the SIP INVITE message is routed in a conventional manner to the NUMCALLED recipient.
  • the VOIPAMZ voice over IP client attached to the additional terminal TA receives a provisional SIP code 180 Ringing. It notifies the SWAMZ Web server which in turn notifies the additional terminal TA and the latter generates a ringing return.
  • the media stream is transmitted in secure mode via the SRTP protocol when this traffic borrows the public Internet IP network and then in unsecured mode via the RTP protocol when this traffic borrows the NAMZ network.
  • the service accessed by the additional terminal TA is a request for a voice over IP call and the request is an INVITE request.
  • the invention applies in the same way to access other services. All you have to do is find 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 of management of an incoming service directed to an additional terminal TA in accordance with one embodiment of the invention.
  • this method is implemented by the incoming service management server SRVic included in the proxy device 100.
  • a NUMioo identity assigned to the incoming services management SRVic server has been previously registered as the secondary called number of the TN terminal in the TAS telephone application server of the SIP core NCSOP network so that the server TAS telephone application triggers, when it detects an incoming service directed to the nominal terminal TN, a mechanism for redirecting this service to the SRVic server for managing the incoming services.
  • the incoming service is a voice over IP call and the redirection mechanism is a simultaneous or sequential call forwarding of this call to the SRVic server.
  • This registration can be done for all TN nominal terminals or can only be done for TN nominal terminals associated with a public identity IMPU registered in a CTX context.
  • this recording can be done by the SRVREG recording server.
  • the registration server SRVREG obtains, from the database BDGI of the identity manager GIOP the telephone number NUMTN of the VoIP line associated with the nominal terminal TN, it records the NUMioo identity of the SRVic server for managing the incoming services as the secondary called number of the terminal TN in the telephone application server TAS.
  • the TAS telephone application server generates an outgoing call of the call forwarding type with:
  • the TAS server checks in particular that the NUMioo identity of the SRVic server is authorized by the Outgoing Call Barring service: - generation of an outgoing SIP INVITE message in which:
  • the RURI and TO fields include the NUMioo identity of the SRVic server for managing the incoming services;
  • the FROM and PAI fields contain 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
  • DIVERSION and / or HISTORY INFO redirection field includes the public identity IMPU NUMTN of the called VoIP line, the cause of return parameter being set to FollowMe, and the forwarding counter being set to 1.
  • This INVITE message is received by the incoming service management server SRVic included in the proxy device 100 during a step G05.
  • the incoming service management SRVic server searches for:
  • a CTX context created by the registration server SRVREG includes the public identity IMPU included in this DIVERSION or HISTORY INFO redirection field, in this case the public identity NUMTN.
  • the SRVic server responds with a SIP error code, for example 404 Not Found or 480 Temporarily Unavailable or 403 Forbidden.
  • the SRVic server responds with a SIP error code, for example 404 Not Found or 480 Temporarily Unavailable or 403 Forbidden.
  • the SRVic server modifies the INVITE message:
  • the NUMioo identity of the SRVic server is replaced by the @SBCOP Contact address included in the CTX context, representative of the @VOIPAMZ address of the VOIPAMZ SIP client attached to the additional terminal TA;
  • the NUMioo identity of the SRVic server is replaced by the public identity IMPU NUMTN contained in the SIP redirection field DIVERSION or HISTORY-INFO.
  • This is an IMPU public identity of the P-Associated-URI field of the SIP 200 OK message generated by the registration server SRVREG in step E45.
  • DIVERSION and / or HISTORY INFO redirection SIP field can be deleted.
  • the modified SIP message is routed to the VOIPAMZ SIP client attached to the additional terminal TA via the operator's SBCOP controller, the TLS tunnel and the SBCAMZ controller of the NAMZ network.
  • the latter notifies the SWAMZ web server of the incoming call.
  • the SBCAMZ server searches the BDAMZ database for the unique identifier IDTA of the additional terminal TA associated with the public identity IMPU NUMTN contained in the TO of the SIP INVITE message, then notifies the incoming call to the additional terminal TA.
  • the SRVREG server, the SRVAS server for managing requests for access to a service and the SRVic server for managing incoming calls are integrated into a proxy server 100.
  • the SRVREG server, the SRVAS server for managing requests for access to a service and the SRVic server for managing incoming calls can be separate devices which share the CTX context.
  • FIG. 7A represents the functional architecture of the recording server SRVREG in a particular embodiment. It comprises :
  • a module ME30 for 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 an additional terminal;
  • a module ME35 for searching 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 representative of 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 SRVAS server 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:
  • an MF30 module for receiving a request for access to a service sent by a SIP client and mistakenly considering being registered in this network
  • an MF35 module 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 item of information possibly being an IP address and / or information contained in a FROM and / or P-Preferred-ID field of the request;
  • an MF40 module 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 SRVic server for managing the incoming services intended directed to an additional terminal of a nominal terminal in a particular embodiment.
  • This server includes:
  • a MG05 module for receiving a service establishment request from a telephone application server, this telephone server comprising at least one recording of a identity assigned to said server as secondary called number of the home terminal to trigger a mechanism for redirecting a service intended for said home terminal to said incoming service management server;
  • 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 shown in Figure 8.
  • This computer ORD comprises in particular a processor 10, a random access memory of the RAM 11 type, a read-only memory of the ROM type 12, a rewritable non-volatile memory of the Flash type 14 and communication means 13.
  • Read-only memory 12 constitutes a medium 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 for recording, managing outgoing calls or for managing incoming calls in accordance with the invention and described above with reference to FIGS. 3, 5 and 6.
  • the memory 14 of the computer ORD comprises a CTX context as described previously, in particular with reference to FIG. 4.
  • the NAPT address translation device is integrated in 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Telephonic Communication Services (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Un procédé d'enregistrement d'un terminal additionnel, ledit terminal additionnel étant un terminal qui partage son identité publique avec un terminal nominal, comporte une étape (E30) de réception d'une requête d'enregistrement en provenance d'un client SIP attaché au terminal additionnel. Il recherche (E35) une adresse IP connue de l'opérateur dans cette requête et crée (E40) un contexte (CTX) comportant une adresse représentative de l'adresse du client SIP et au moins une identité publique associée à un compte du terminal nominal dans un réseau de cœur SIP. Ce contexte (CTX) est utilisé par un procédé de gestion des appels sortants pour accéder à un service en utilisant un profil de service d'un compte associé à ladite identité publique. Il est aussi utilisé par un procédé de gestion des services entrants pour rediriger jusqu'au client de voix sur IP, un service entrant émis vers ladite identité publique dans ledit réseau.

Description

Description
Titre de l'invention : Procédés et serveurs de gestion des services d'un terminal additionnel dans un réseau de cœur SIP
Technique antérieure
La présente invention se situe dans le domaine des télécommunications et plus particulièrement dans le domaine des services VoIP (téléphonie, Visiophonie, RCS, SMSoIP,...) s'appuyant sur un cœur de réseau SIP (en anglais Session Initiation Protocol) fixe ou mobile, par exemple de type architecture standardisée 3GPP IMS (en anglais IP Multimedia Subsystem) ou bien encore d'architecture de type NGN (en anglais Next Génération Network).
Elle vise plus particulièrement des procédés et serveurs pour permettre à un terminal dit « additionnel » d'accéder à des services de voix sur IP dans de tels réseaux. Un terminal additionnel est par exemple un assistant vocal tel que les produits Alexa (marque déposée) et Google Home (marque déposée) proposés respectivement par les sociétés Amazon (marque déposée) et Google LLC (marque déposée).
Dans la présente demande, on appelle plus généralement « terminal additionnel » tout terminal qui partage son identité publique IMPU (en anglais IP Multimedia Public Identity) avec un terminal nominal et qui ne possède pas ou n'utilise pas de carte SIM (en anglais Subscriber Identity Module) ou eSIM (en anglais embedded SIM) pour s'enregistrer dans le réseau.
L'invention vise en particulier un mécanisme pour enregistrer un terminal additionnel dans le réseau, et lui permettre ensuite d'accéder à et/ou recevoir des services de voix sur IP.
On connaît principalement deux méthodes pour enregistrer et authentifier un terminal dans un réseau SIP.
Dans un réseau mobile, les identifiants SIP (en anglais credentials) sont stockés dans la carte SIM ou eSIM et le réseau cœur IMS mobile utilise un mode d'authentification EAP-AKA (en anglais Extensible Authentication Protocol - Authentification and Key Agreement) basé sur la dérivation des informations contenues dans la carte SIM/eSIM. Ce mécanisme est relativement simple.
En revanche, les terminaux fixes n'ont pas de carte SIM/eSIM. Ils ne peuvent donc pas s'enregistrer et s'authentifier selon le mécanisme EAP-AKA et doivent télécharger un fichier de configuration comportant notamment l'identité publique du terminal l'IMPU, l'identité privée du terminal IMPI (en anglais IP Multimedia Private Identity) et le mot de passe SIP pour permettre son authentification. L'authentification de ces terminaux est basée sur la méthode Digest RFC 2917. Ce mécanisme est plus compliqué, notamment parce qu'il nécessite le téléchargement du fichier de configuration.
L'intégration d'un terminal additionnel peut se faire en réseau fixe ou mobile. S'il est choisi d'intégrer le terminal additionnel dans un réseau mobile, le cœur IMS doit supporter à la fois l'authentification EAP-AKA pour l'enregistrement du terminal nominal mobile et le mode Digest pour l'assistant vocal qui ne comporte pas de carte SIM/eSIM.
Ce mécanisme d'enregistrement et la gestion de ces enregistrements dans le système d'information de l'opérateur sont complexes. Des informations d'enregistrement doivent être créées par le système d'information en temps réel pour chaque terminal additionnel détecté. Ces informations doivent être ajoutées au compte VoIP dans la base de données du cœur de réseau VoIP, puis être délivrées à la pile VoIP attachée au terminal additionnel, le tout de manière sécurisée... En outre, le cœur de réseau VoIP SIP doit être configuré pour autoriser l'enregistrement et traiter les services de communication de plusieurs terminaux partageant la même identité publique IMPU (activation du mode standardisée 3GPP Shared IMPU).
L'invention vise notamment à offrir un mécanisme simplifié d'enregistrement de ces terminaux additionnels, ce mécanisme étant sécurisé et facile à intégrer dans les réseaux fixes ou mobiles.
Exposé de l'invention
Plus précisément, et selon un premier aspect, l'invention concerne un procédé d'enregistrement d'un terminal additionnel mis en œuvre par un serveur d'enregistrement, ledit terminal additionnel étant un terminal qui partage son identité publique avec un terminal nominal, ce procédé comportant :
- une étape de réception d'une requête d'enregistrement d'en provenance d'un client SIP attaché au terminal additionnel et apte à s'enregistrer dans un réseau de cœur SIP d'un opérateur, pour activer au moins un service pour le terminal additionnel dans ce réseau ;
- une étape de recherche d'au moins une adresse IP connue de l'opérateur dans ladite requête d'enregistrement ;
- une étape de création d'un contexte comportant au moins une adresse de contact représentative de l'adresse du client SIP et au moins une identité publique associée à un compte dudit terminal nominal géré par l'opérateur dans ce réseau et associé à cette adresse IP, ce compte pouvant être utilisé pour fournir au moins un service audit terminal additionnel ;
- une étape de détermination d'au moins un service dont ledit terminal additionnel peut bénéficier ; et
- une étape d'envoi d'une réponse destinée audit client SIP et comportant des informations obtenues par le serveur d'enregistrement lors de ladite étape de détermination pour que ledit client SIP détermine les services dont le terminal additionnel peut bénéficier.
Corrélativement, l'invention concerne un serveur d'enregistrement comportant :
- un module de réception d'une requête d'enregistrement en provenance d'un client SIP apte à s'enregistrer dans un réseau de cœur SIP d'un opérateur, pour activer dans ledit réseau au moins un service pour un terminal additionnel auquel ledit client SIP est attaché, ledit terminal additionnel étant un terminal qui partage son identité publique avec un terminal nominal;
- un module de recherche d'au moins une adresse IP connue de l'opérateur dans ladite requête d'enregistrement ;
- un module de création d'un contexte comportant au moins une adresse de contact représentative de l'adresse du client SIP et au moins une identité publique associée à un compte dudit terminal nominal géré par l'opérateur dans ce réseau et associé à cette adresse IP, ce compte pouvant être utilisé pour fournir au moins un service audit terminal additionnel ;
- un module de détermination d'au moins un service dont ledit terminal additionnel peut bénéficier ;et
- un module d'envoi d'une réponse destinée audit client SIP et comportant des informations obtenues par le serveur d'enregistrement lors de ladite étape de détermination pour que ledit client SIP détermine les services dont le terminal additionnel peut bénéficier.
Ainsi, et de façon remarquable, l'invention propose un mécanisme d'enregistrement dans lequel le terminal additionnel n'est finalement pas techniquement enregistré dans le réseau de cœur SIP de l'opérateur mais dans le serveur d'enregistrement et bénéficie du compte de voix sur IP d'un terminal nominal enregistré dans le cœur SIP de l'opérateur auquel il est associé.
Dans un mode particulier de mise en œuvre de l'invention, le client SIP est un client de voix sur IP apte à activer au moins un service de voix sur IP pour le terminal additionnel et le compte géré par l'opérateur est un compte de voix sur IP du terminal nominal.
L'invention propose de découvrir l'identité publique IMPU de ce terminal nominal en analysant les adresses IP contenues dans les requêtes d'enregistrement émises pour enregistrer le terminal additionnel dans le serveur d'enregistrement SIP.
Dès lors que cet identifiant a été identifié, l'invention propose de ne pas poursuivre l'enregistrement du terminal additionnel dans le réseau de cœur SIP, de faire bénéficier au terminal additionnel de tout ou partie des services offerts par le compte de voix sur IP du terminal nominal et de répondre positivement à la requête d'enregistrement pour que le client SIP sur lequel s'appuie le terminal additionnel se considère dûment enregistré.
La gestion de l'enregistrement fictif du terminal additionnel et de tous les services s'appuie essentiellement sur le contexte créé par le serveur d'enregistrement.
L'invention est remarquable en ce que ce mécanisme d'enregistrement est totalement indépendant du réseau de cœur SIP.
Une difficulté résolue par l'invention est de découvrir l'identité publique IMPU du terminal nominal puis d'authentifier implicitement le terminal additionnel sur la base d'une adresse IP allouée par l'opérateur au point d'accès utilisé par le terminal additionnel. L'invention propose d'analyser toutes les adresses IP contenues dans la requête d'enregistrement et de vérifier si elles sont connues de l'opérateur et attachées à un compte de voix sur IP. Une telle adresse IP peut en particulier être une adresse attribuée à un point d'accès Internet qui fournit l'accès au terminal additionnel ou bien une adresse attribuée à un équipement réseau implémentant une fonction NAPT.
Dans un mode de réalisation, la requête d'enregistrement est une requête SIP REGISTER et les adresses IP sont recherchées dans les champs adresse IP source du paquet IP, ou Instance-ID, Via, ou Contact de cette requête.
Dans un mode de réalisation, ledit au moins un service utilisable par ledit terminal additionnel est explicitement enregistré dans ledit contexte et/ou précisé dans ladite réponse.
L'invention permet ainsi un mécanisme très fin de gestion des services offerts au terminal additionnel.
Dans un mode de réalisation, une durée d'utilisation du au moins un service par ledit terminal additionnel est explicitement enregistrée dans ledit contexte et/ou précisée dans ladite réponse. Cette durée peut par exemple être envoyée dans un paramètre Expires de la réponse pour inciter le client SIP à envoyer une nouvelle requête d'enregistrement avant l'expiration de cette durée. Il s'agit d'un mécanisme fictif puisque le terminal additionnel n'est pas enregistré en cœur de réseau SIP mais il permet avantageusement à l'opérateur de gérer dynamiquement les contextes utilisés par l'invention.
Dans un mode de réalisation de l'invention, la réponse à la requête d'enregistrement générée par le serveur d'enregistrement est négative si ce dernier détermine que la marque et/ou le type du terminal additionnel n'est pas autorisée. Ces informations de marque et/ou type de terminal additionnel peuvent être gérées directement par le serveur d'enregistrement ou être obtenues du serveur d'enregistrement à partir d'un serveur d'identités de l'opérateur.
Ces informations de marque et/ou type de terminal additionnel permettent au serveur d'enregistrement d'informer le terminal additionnel qu'il n'a pas l'autorisation d'accès aux services et donc qu'il ne doit pas re-solliciter le serveur d'enregistrement ce qui se traduit par une diminution de sa charge et potentiellement de celle du serveur d'identités de l'opérateur.
Ces informations de marque et/ou type de terminal additionnel préconfigurées dans ou obtenues par le serveur d'enregistrement permettent au serveur d'enregistrement de refuser la requête d'enregistrement par exemple sur la base d'un masque de l'adresse MAC de ces équipements et/ou sur la valeur du User Agent du terminal additionnel. Le serveur d'enregistrement peut ainsi refuser ou autoriser la requête d'enregistrement émise par un terminal additionnel en vérifiant si les informations contenues dans le champ Instance-ID et/ou User Agent de la requête d'enregistrement sont compatibles avec celles préconfigurées dans ou obtenues du serveur d'enregistrement.
Selon un deuxième aspect, l'invention concerne un procédé de gestion d'une demande émise par un terminal additionnel pour accéder à un service dans un réseau de cœur SIP, ledit terminal additionnel étant un terminal qui partage son identité publique avec un terminal nominal, ce procédé comportant :
- une étape de réception d'une requête d'accès à un service émise par un client SIP attaché audit terminal additionnel, ledit client SIP n'étant pas enregistré dans ledit réseau ;
- une étape pour vérifier si au moins une information contenue dans la requête d'accès à un service et représentative de l'adresse dudit client SIP est enregistrée dans un contexte en association avec une identité publique associée à un compte du dit terminal nominal géré par un opérateur dudit réseau ;
- une étape d'envoi d'une requête à une entité du réseau de cœur SIP pour établir ledit service pour le client SIP en utilisant un profil de service de ce compte.
Corrélativement, l'invention concerne un serveur de gestion d'au moins une demande émise par un terminal additionnel pour accéder à un service dans un réseau de cœur SIP, ledit terminal additionnel étant un terminal qui partage son identité publique avec un terminal nominal, ce serveur comportant :
- un module de réception d'une requête d'accès à un service émise par un client SIP attaché audit terminal additionnel, ledit client SIP n'étant pas enregistré dans ledit réseau ;
- un module pour vérifier si au moins une information contenue dans la requête et représentative de l'adresse dudit client SIP est enregistrée dans un contexte en association avec une identité publique associée à un compte dudit terminal nominal géré par un opérateur du réseau ;
- un module d'envoi d'une requête à une entité du réseau de cœur SIP pour établir le service pour le client de voix sur IP en utilisant un profil de service de ce compte.
Conformément à l'invention, le client SIP n'est pas techniquement enregistré dans le réseau. Il est enregistré dans le serveur d'enregistrement. On dit également qu'il est enregistré fictivement dans le réseau.
Dans un mode de réalisation, le contexte est destiné à être utilisé pour déclencher, dans le réseau de cœur SIP, l'établissement d'un appel entre le client SIP, ici un client de voix sur IP et un destinataire, la requête d'accès à un service étant une requête d'établissement d'appel SIP INVITE
La requête d'accès à un service peut aussi notamment être une requête SIP MESSAGE, SUBSCRIBE, OPTIONS, PUBLISH, REFER, ou INFO.
Ainsi et de façon très remarquable, la gestion de la demande d'accès à un service s'appuie sur le mode OOTB (en anglais (Out Of The Blue) standardisé du 3GPP. Ce mode de fonctionnement permet à un serveur certifié (en anglais « trusted ») par contrôle par exemple de son adresse IP d'accéder à un service pour le compte d'un utilisateur disposant d'une souscription VoIP sans être lui-même enregistré.
Par exemple, l'invention propose d'utiliser le mode OOTB pour la gestion des appels sortants notamment, pour permettre à un serveur certifié de passer des appels sortants pour le compte d'un utilisateur disposant d'une souscription VoIP sans être lui-même enregistré.
Ce mode de fonctionnement est par exemple utilisé par les serveurs de messagerie vocale pour offrir un service téléphonique de rappel du déposant ou pour un service téléphonique Click To Call. Comme décrit ultérieurement, l'information contenue dans la requête et recherchée dans le contexte est :
- une adresse IP ; et/ou
- une information contenue dans un champ FROM et/ou Preferred ID de la requête.
Dans un mode particulier de réalisation, le serveur de gestion des demandes d'accès à un service peut, comme le fait le serveur d'enregistrement, vérifier si les adresses IP contenues dans une requête d'accès à un service sont connues de l'opérateur et associées à un compte de voix sur IP dans le réseau, et lorsque c'est le cas, créer ou mettre à jour un contexte de sorte à gérer dynamiquement une nouvelle adresse IP qui vient tout juste d'être attribuée dynamiquement au point d'accès qui offre la connectivité au terminal additionnel.
Dans un mode de réalisation, le contexte comporte en outre l'adresse IP obtenue par le serveur d'enregistrement et utilisée pour identifier le compte et ce contexte est notamment destiné à être utilisé pour gérer les services entrants destinés au terminal additionnel.
Par conséquent, selon un troisième aspect, l'invention concerne un procédé de gestion d'un service entrant dirigé vers un terminal additionnel d'un terminal nominal, ledit terminal additionnel étant un terminal qui partage son identité publique avec ledit terminal nominal, ce procédé étant mis en œuvre par un serveur de gestion des services entrants et comportant :
- une étape préalable d'enregistrement d'une identité attribuée audit serveur en tant qu'identité appelée secondaire du terminal nominal dans un serveur d'application téléphonique pour déclencher un mécanisme de redirection d'un service dirigé vers ledit terminal nominal vers ledit serveur de gestion des services entrants ;
- une étape de réception d'une requête d'établissement de service en provenance dudit serveur d'application téléphonique ;
- une étape pour vérifier si ladite requête d'établissement de service comporte une identité publique IMPU comprise dans un de ses champs et associée dans un contexte à une adresse de contact représentative de l'adresse d'un client SIP attaché au terminal additionnel;
- une étape de transfert de ladite requête d'établissement de service vers l'adresse de contact pour qu'elle soit acheminée jusqu'au dit client SIP.
Corrélativement, l'invention concerne un serveur de gestion des services entrants dirigés vers au moins un terminal additionnel d'un terminal nominal, ledit terminal additionnel étant un terminal qui partage son identité publique avec ledit terminal nominal, ce serveur comportant :
- un module de réception d'une requête d'établissement de service en provenance d'un serveur d'application téléphonique, ce serveur téléphonique comportant au moins un enregistrement d'une identité attribuée audit serveur en tant qu'identité appelée secondaire du terminal nominal pour déclencher un mécanisme de redirection d'un service dirigé vers ledit terminal nominal vers ledit serveur de gestion des services entrants ;
- un module pour vérifier si ladite requête d'établissement de service comporte une identité publique IMPU comprise dans un de ses champs et associée dans un contexte à une adresse de contact représentative de l'adresse d'un client SIP attaché au terminal additionnel;
- un module de transfert de la requête d'établissement de service vers l'adresse de contact pour qu'elle soit acheminée jusqu'au dit client SIP .
Ainsi, et de façon remarquable, l'invention propose de s'appuyer sur les mécanismes de redirection connus de l'homme du métier pour gérer les services entrants, par exemple les appels entrants, dirigés vers le terminal additionnel.
Ces mécanismes de redirection peuvent par exemple être constitués par les services de renvoi simultanés ou séquentiels (en anglais « forking ») programmés dans les serveurs d'application téléphoniques pour gérer les services multi-terminaux.
Dans un mode de réalisation de l'invention, le contexte comporte en outre au moins une information de service définissant au moins un droit d'accès à un service pour au moins un type de terminal additionnel. Ces informations de service peuvent être gérées directement par le serveur d'enregistrement ou obtenues du serveur d'enregistrement à partir d'un serveur d'identités de l'opérateur.
Ces informations de service permettent au serveur de gestion des demandes d'accès à un service de ne pas solliciter le cœur de réseau VoIP pour un service non autorisé.
Ces informations de service obtenues par le serveur d'enregistrement et enregistrées dans le contexte comportent par exemple la marque ou le type des équipements autorisés à accéder à un service particulier, par exemple sur la base d'un masque de l'adresse MAC de ces équipements ou des informations du client SIP (User Agent) attaché au terminal additionnel. Le serveur de gestion des demandes d'accès à un service peut ainsi refuser ou autoriser l'accès à un service demandé par un terminal additionnel en vérifiant si les informations contenues dans le champ Instance-ID et/ou User Agent de la requête d'accès à un service sont compatibles avec celles enregistrées dans le contexte du terminal additionnel.
L'invention vise également un serveur proxy SIP comportant un serveur d'enregistrement, un serveur de gestion des demandes d'accès à un service et un serveur de gestion des services entrants tels que mentionnés ci-dessus.
Chacun des procédés mentionnés ci-dessus peut être mis en œuvre par un programme d'ordinateur.
Par conséquent, l'invention vise également un programme d'ordinateur sur un support d'enregistrement, ce programme étant susceptible d'être mis en œuvre dans un dispositif ou plus généralement dans un ordinateur. Ce programme comporte des instructions permettant la mise en œuvre d'au moins un procédé décrit ci-dessus. Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
L'invention vise aussi un support d'information ou un support d'enregistrement lisibles par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus.
Le support d'information ou d'enregistrement peut être n'importe quelle entité ou dispositif capable de stocker les programmes. Par exemple, les supports peuvent comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy dise) ou un disque dur, ou une mémoire flash.
D'autre part, le support d'information ou d'enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par lien radio, par lien optique sans fil ou par d'autres moyens.
Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
Alternativement, le support d'informations ou d'enregistrement peut être un circuit intégré dans lequel un programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution de l'un des procédés tels que décrits précédemment.
Brève description des dessins
D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci- dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures :
[Fig. 1] la figure 1 représente un serveur proxy conforme à l'invention dans son environnement.
[Fig. 2] la figure 2 représente le serveur proxy de la figure 1 ;
[Fig. 3] la figure 3 représente sous forme d'ordinogramme les principales étapes d'un procédé d'enregistrement conformément à un mode particulier de réalisation de l'invention ;
[Fig. 4] la figure 4 représente un contexte pouvant être utilisé dans un mode particulier de réalisation ;
[Fig. 5] la figure 5 représente sous forme d'ordinogramme les principales étapes de gestion d'une demande d'accès à un service conformément à un mode de réalisation de l'invention ;
[Fig. 6] la figure 6 représente sous forme d'ordinogramme les principales étapes de gestion d'un service entrant conformément à un mode de réalisation de l'invention ; [Fig. 7A] la figure 7A représente l'architecture fonctionnelle d'un serveur d'enregistrement conforme à un mode de réalisation de l'invention ;
[Fig. 7B] la figure 7B représente l'architecture fonctionnelle d'un serveur de gestion des demandes d'accès à un service conforme à un mode de réalisation de l'invention ;
[Fig. 7C] la figure 7C représente l'architecture fonctionnelle d'un serveur de gestion des services entrants conforme à un mode de réalisation de l'invention ; et
[Fig. 8] la figure 8 représente l'architecture matérielle de ces serveurs conformément à un mode de réalisation de l'invention.
Description détaillée de modes de réalisation particuliers
On considère par la suite le cas d'un utilisateur possédant un terminal nominal TN et au moins un terminal additionnel TA. Ce terminal additionnel TA ne comporte pas ou n'utilise pas de de carte SIM/eSIM.
La figure 1 représente un serveur proxy 100 conforme à l'invention dans son environnement.
On suppose que le terminal nominal TN est enregistré dans un réseau NCSOP de cœur SIP d'un opérateur OP et qu'il bénéficie de services de voix sur IP. On appelle NUMTN le numéro téléphonique de cette ligne VoIP.
Dans le mode de réalisation décrit ici, le réseau NCSOP de cœur SIP est un réseau IMS. En variante, ce réseau est un réseau NGN.
Dans le mode de réalisation décrit ici, le terminal additionnel TA est sous la couverture d'un point d'accès AP qui définit un réseau local sans fil WLAN.
Un dispositif de traduction d'adresses NAPT (en anglais Network Address Port Translation) connu de l'homme du métier, et intégré au point d'accès AP, établit une correspondance entre les adresses IPV4 privées du réseau WLAN et une adresse IPV4 publique attribué par le réseau à l'interface WAN (en anglais Wide Area Network) du point d'accès.
Dans le cas où le point d'accès qui fournit l'accès au terminal additionnel se fait attribuer une adresse IPV6 sur son interface WAN par l'opérateur, le point d'accès alloue aux terminaux connectés sur son LAN, une adresse IPV6 portant le même préfixe que celle de son interface WAN, les terminaux complétant la valeur de l'adresse IPV6 avec par exemple leur propre adresse MAC. Ces adresses IPV6 attribuées au point d'accès et aux terminaux connectés sur le LAN sont donc connues de l'opérateur.
Sur la figure 1, on a représenté un réseau NAMZ géré par une entité AMZ fournisseur du terminal additionnel TA. Ce réseau NAMZ est interconnecté par une liaison Internet à un réseau NOP géré par l'opérateur OP, lui-même interconnecté au réseau de cœur NCSOP de cœur SIP. Dans le mode de réalisation décrit ici, le réseau NAMZ comporte un serveur web SWAMZ interconnecté à une base de données BDAMZ, un client SIP (User Agent) VOIPAMZ et un contrôleur SBCAMZ (en anglais Session Border Controller). Le serveur web SWAMZ administré par l'entité AMZ gère une pluralité de terminaux additionnels, dont le terminal additionnel TA.
Ce client SIP VOIPAMZ est apte à s'enregistrer dans le réseau NCSOP de cœur SIP d'un opérateur pour activer au moins un service pour le terminal additionnel dans ledit réseau.
Dans le mode de réalisation décrit ici, le client SIP VOIPAMZ est un client de voix sur IP. Dans ce mode de réalisation, le client SIP VOIPAMZ est apte à s'enregistrer dans le réseau NCSOP pour activer le service de voix sur IP pour le terminal additionnel TA.
Dans le mode de réalisation décrit ici, le serveur web SWAMZ comporte une passerelle WebRTC configurée pour traiter les flux de signalisation et les flux média.
Dans le mode de réalisation décrit ici, le réseau NOP de l'opérateur comporte un contrôleur SBCOP configuré pour communiquer avec le contrôleur SBCAMZ du réseau NAMZ, le serveur proxy 100 conforme à l'invention et un gestionnaire d'identités GIOP (en anglais Enabler Identity). Les contrôleurs SBCAMZ et SBCOP sont configurés pour établir un tunnel sécurisé TLS.
On note ci-après :
- @SWAMZ l'adresse IP du serveur Web SWAMZ ; elle est enregistrée dans une mémoire du terminal additionnel TA
- @VOIPAMZ l'adresse du client SIP VOIPAMZ attaché au terminal additionnel TA;
- @SBCAMZ l'adresse du contrôleur SBCAMZ ;
- @SBCOP l'adresse du contrôleur SBCOP ; et
- @100, l'adresse du serveur proxy 100 conforme à l'invention.
La figure 2 représente le serveur proxy 100 dans un mode particulier de réalisation de l'invention. Dans le mode de réalisation décrit ici, le serveur proxy 100 comporte :
- un serveur SRVREG configuré pour créer un contexte CTX suite à une demande d'enregistrement dans le réseau NCSOP de cœur SIP émise par le client SIP VOIPAMZ attaché au terminal additionnel TA ;
- un serveur SRVAS configuré pour gérer les demandes d'accès à un service émises par le terminal additionnel TA en utilisant le contexte CTX ;
- un serveur SRVic configuré pour gérer les services entrants destinés au terminal additionnel TA en utilisant le contexte CTX ; et
- le contexte CTX.
Dans le mode de réalisation décrit ici, le serveur SRVREG joue le rôle d'un serveur SIP Registrar mais il n'enregistre pas le client SIP VOIPAMZ attaché au terminal additionnel TA dans le réseau NCSOP de cœur SIP. Dans le mode de réalisation décrit ici, le serveur SRVAS de gestion des demandes d'accès à un service est un serveur B2BUA (en anglais Back To Back User Agent) configuré pour émettre un appel en mode OOTB (en anglais Out Of The Blue) suite à une demande d'appel sortant émise par le terminal additionnel TA.
Dans le mode de réalisation décrit ici, le serveur SRVic de gestion des services entrants est un serveur B2BUA ou un serveur proxy apte à interroger la base de données du serveur d'enregistrement SRVREG.
La figure 3 représente sous forme d'ordinogramme les principales étapes d'un procédé d'enregistrement du terminal additionnel TA, conformément à un mode particulier de réalisation de l'invention.
Au cours d'une étape E05, le terminal additionnel TA envoie une requête d'activation HTTPS RACT au serveur Web SWAMZ pour s'enregistrer dans le réseau NCSOP de cœur SIP de sorte à pouvoir ultérieurement accéder à des services, notamment émettre et recevoir des appels de voix sur IP.
Cette requête comporte une adresse source @IPSOURŒ fournie par le dispositif de traduction d'adresses NAPT (IPV4) et l'identifiant unique IDTA du terminal additionnel TA. L'adresse source @IPSOURŒ est une adresse IPV4 publique correspondant à une adresse publique WAN du point d'accès AP.
Sur réception de cette requête, le serveur SWAMZ interroge (étape E10) la base de données BDAMZ pour vérifier que le terminal additionnel TA est un terminal connu de l'entité AMZ et autorisé par celle-ci à utiliser des services, par exemple de téléphonie.
Si tel est le cas, le serveur SWAMZ demande via une API Web, au cours d'une étape E15, l'activation d'un service, au niveau du client SIP VOIPAMZ. Dans le mode de réalisation décrit ici, on supposera que l'activation concerne l'activation d'un service de voix sur IP.
Cette demande d'activation comporte l'adresse source @IPSOURŒ.
Au cours d'une étape E20, le client SIP VOIPAMZ du réseau NAMZ envoie une requête SIP REGISTER (requête d'enregistrement au sens de l'invention) à l'entité de bordure SBCAMZ du réseau NAMZ. Cette requête comporte :
- des champs RURI, FROM et TO quelconques ;
- un champ Contact et un champ Via comportant l'adresse @VOIPAMZ du client SIP VOIPAMZ ; et
- un champ Instance-ID comportant l'adresse source @IPSOURŒ.
Dans le mode de réalisation décrit ici, le protocole de transport utilisé entre le client VOIPAMZ et le contrôleur SBCAMZ est le protocole UDP.
Au cours d'une étape E25, l'entité de bordure SBCAMZ du réseau NAMZ encapsule la requête SIP REGISTER dans le tunnel sécurisé TLS créé avec le contrôleur SBCOP du réseau opérateur NOP. Les champs Contact et Via sont modifiés pour comporter l'adresse @SBCAMZ du contrôleur SBCAMZ. Au cours d'une étape E30, le contrôleur SBCOP du réseau opérateur NOP déchiffre le message et transfert la requête SIP REGISTER au serveur d'enregistrement SRVREG du serveur proxy 100. Pour cela, le contrôleur SBCOP ajoute l'adresse @100 de ce serveur 100 dans l'entête Route du message. Les champs Contact et Via sont modifiés pour comporter l'adresse@ SBCNOP du contrôleur SBCOP.
Le protocole de transport utilisé entre le contrôleur SBCOP et le serveur proxy 100 peut par exemple être le protocole UDP, TCP, STCP ...
Au cours d'une étape E35, le serveur d'enregistrement SRVREG du dispositiflOO recherche dans le message SIP REGISTER l'adresse IP du point d'accès AP qui offre la connectivité au terminal additionnel TA.
Dans l'exemple décrit ici, cette adresse est l'adresse @IPSOURCE contenue dans le champ Instance-ID. Mais dans d'autres configurations cette adresse pourrait se trouver dans un autre champ du message SIP REGISTER, par exemple dans le champ SIP Via ou dans le champ SIP Contact. Cette adresse pourrait aussi être l'adresse IP source du paquet IP contenant le message SIP REGISTER, typiquement dans le cas où le client SIP VOIPAMZ attaché au terminal TA est directement intégré dans le terminal additionnel TA.
Par conséquent, au cours de l'étape E35, le serveur proxy Registrar 100 recherche toutes les adresses IP du message SIP REGISTER, et, pour chacune de ces adresses IP, le serveur proxy Registrar 100 interroge le gestionnaire d'identités GIOP pour obtenir les éventuelles informations concernant un service de voix sur IP, attaché à cette adresse IP.
C'est le cas si cette adresse IP (IPV4) ou si le préfixe de cette adresse IP (IPV6) a été attribué à un point d'accès et si ce service existe.
Dans le mode de réalisation décrit ici, le serveur proxy Registrar 100 interroge le gestionnaire d'identités GIOP via une API.
Plus précisément, dans le mode de réalisation décrit ici, lorsque le gestionnaire d'identités GIOP reçoit une adresse IP, il interroge sa base de données BDGI pour vérifier si cette adresse IP (ou préfixe en IPV6) a été attribuée par l'opérateur OP et si un service de voix sur IP géré par l'opérateur OP est attaché à cette adresse IP, et retourne dans sa réponse 200 OK, l'identité publique IMPU associée à ce compte de voix sur IP. En outre, le gestionnaire d'identités GIOP pourrait fournir des informations de service supplémentaires telles que par exemple un nombre maximal de terminaux additionnels autorisés, les marques et/ou type de terminaux additionnels autorisés et pouvant être retrouvés dans des champs du protocole SIP tel que le SIP User Agent, l'Instance-ID,..., des informations de service VoIP telles que l'autorisation des appels sortants et/ ou entrants exploitables, le nombre maximal d'appels simultanés autorisés pour les terminaux additionnels, l'autorisation d'accès aux services d'urgence, l'autorisation d'accès à des services à valeur ajoutée, l'autorisation d'accès à des correspondants fixe et/ou mobile nationaux et/ou internationaux, le support du service de visiophonie, le support des services de messagerie de type RCS (en anglais Rich Communication Suite), SMSoIP...ces informations pouvant être exploitées par le serveur Proxy 100 et limitant au strict minimum les interactions du serveur proxy 100 avec le cœur VoIP NCSOP.
Dans l'exemple de réalisation décrit ici, le terminal nominal TN bénéficie de services de voix sur IP, une de ces identités publiques IMPU est le numéro téléphonique NUMTN de la ligne VoIP associée. Il n'est pas nécessaire que le terminal nominal TN soit enregistré dans le réseau NCSOP. Il peut en particulier être éteint ou hors couverture radio.
Au cours d'une étape E40, le serveur d'enregistrement SRVREG du serveur proxy 100 crée un contexte CTX comportant :
- l'adresse comprise dans le champ Contact du message SIP REGISTER reçu à l'étape E30. Cette adresse est celle du contrôleur SBCOP, mais elle est représentative de l'adresse @VOIPAMZ du client SIP VOIPAMZ attaché au terminal TA;
- toutes les adresses IP du message SIP REGISTER et associées à un compte dans le gestionnaire d'identités GIOP et pour chacune d'elle la ou les identités publiques IMPU associées à ce compte de voix sur IP, dont nécessairement le numéro téléphonique NUMTN de la ligne VoIP du terminal nominal TN
- de manière optionnelle, les informations de services.
Un exemple de contexte CTX est représenté à la figure 4. Dans cet exemple on considère que la seule adresse IP du message SIP REGISTER et associée à un compte de voix sur IP est l'adresse @IPSOURŒ du point d'accès AP et que la seule identité publique IMPU associée à un compte de voix sur IP est le numéro téléphonique NUMTN de la ligne VoIP du terminal nominal TN.
Dans un mode de réalisation décrit ici, le serveur d'enregistrement SRVREG détermine de lui-même les services associés à ce compte de voix sur IP dont le terminal additionnel TA peut bénéficier, et il enregistre explicitement ces services dans le contexte CTX. Le serveur d'enregistrement SRVREG peut par exemple autoriser le terminal additionnel à émettre des appels et/ou à en recevoir.
Dans un autre mode de réalisation, le serveur d'enregistrement SRVREG détermine les services associés à ce compte de voix sur IP dont le terminal additionnel TA peut bénéficier sur la base des informations de services retournées par le gestionnaire d'identités GIOP.
Au cours d'une étape E45, le serveur d'enregistrement SRVREG du serveur proxy 100 envoie une réponse 200 OK au contrôleur SBCOP. Cette réponse est destinée au client SIP VOIPAMZ attaché au terminal additionnel TA et elle comporte des informations permettant au client SIP VOIPAMZ attaché au terminal additionnel TA de déterminer les services dont le terminal additionnel TA peut bénéficier. Dans le mode de réalisation décrit ici, par défaut, le terminal additionnel TA est autorisé à émettre et à recevoir des appels de voix sur IP.
Dans un mode de réalisation, les services utilisables par le terminal additionnel sont explicitement spécifiés dans la réponse SIP. Dans un mode de réalisation de l'invention, les services sont octroyés par le serveur d'enregistrement pour une durée déterminée, cette durée étant enregistrée dans le contexte CTX comme représenté à la figure 4.
Dans ce mode de réalisation, cette durée peut être envoyée dans un paramètre Expires de la réponse 200 OK pour inciter le client SIP VOIPAMZ attaché au terminal additionnel TA à envoyer une nouvelle requête d'enregistrement avant l'expiration de cette durée.
Dans le mode de réalisation décrit ici, la réponse 200 OK comporte également un champ P- Associated-URI comportant l'ensemble des identités publiques IMPU obtenues à l'étape E35. Ceci n'est pas obligatoire et il peut ne pas être interprétable par le client SIP VOIPAMZ attaché au terminal TA si celui-ci n'est pas conforme à l'IMS.
La réponse 200 OK est acheminée (étapes E50 et E55) jusqu'au client SIP VOIPAMZ attaché au terminal additionnel TA du réseau NAMZ via le tunnel TLS établi entre les contrôleurs SBCOP et SBCAMZ.
Le client SIP VOIPAMZ attaché au terminal additionnel TA est alors vu comme enregistré en cœur de réseau VoIP de l'opérateur OP mais il ne l'est pas d'un point de vue technique.
Le client SIP VOIPAMZ attaché au terminal additionnel TA enregistre dans la base de données BDAMZ le fait que le terminal additionnel TA est fictivement enregistré en cœur de réseau VoIP ainsi que la durée restante Expires de cet enregistrement fictif si celle-ci est présente dans la réponse 200 OK.
Si ce client SIP VOIPAMZ attaché au terminal additionnel TA est conforme à l'IMS, il peut aussi mémoriser les identités publiques IMPU du champ P-Associated-URI, dont le numéro de téléphone NUMTN si ce champ est présent dans la réponse 200 OK. Pour rappel, la première information présente dans ce champ P-Associated-URI est considérée comme étant l'identité publique par défaut. Cette information peut également lui permettre de sélectionner une identité publique préférée parmi la pluralité retournées lors des appels sortants en l'insérant dans le champ SIP FROM et/ou P- Preferred-Id. En outre, cette information peut être fournie au terminal additionnel TA si ce dernier peut restituer cette information à son utilisateur, le choix de l'identité publique IMPU utilisée pour l'appel étant alors effectué par l'utilisateur du terminal additionnel TA.
Sinon, le client SIP VOIPAMZ ignore l'entête P-Associated-URI du message SIP 200 OK.
Au cours d'une étape E60, le client SIP VOIPAMZ attaché au terminal additionnel TA confirme l'activation du service au serveur Web SWAMZ.
Au cours d'une étape E65, le serveur SWAMZ confirme l'activation du service au terminal additionnel TA. Il fournit éventuellement l'identité publique IMPU de la ligne VoIP.
La figure 5 représente sous forme d'ordinogramme les principales étapes de gestion d'une demande d'accès à un service émise par le terminal additionnel TA conformément à un mode de réalisation de l'invention.
Dans le mode de réalisation décrit ici, cette demande est une demande pour établir un appel sortant. Au cours d'une étape F05, un utilisateur du terminal additionnel TA demande, par une commande vocale, d'appeler le numéro appelé NUMCALLED. Une requête REA d'établissement d'appel est transmise en HTTPS POST au serveur Web SWAMZ. Elle comporte l'adresse source @IPSOURŒ du point d'accès AP et la commande vocale incluant le numéro NUMCALLED.
Au cours d'une étape F10, le serveur Web SWAMZ applique un algorithme de reconnaissance vocale pour reconnaître la commande d'appel du numéro NUMCALLED, et interroge la base de données BDAMZ pour déterminer si le terminal additionnel TA est fictivement enregistré dans le réseau de cœur SIP. Cette deuxième condition est vérifiée à partir de la valeur courante Expires enregistrée dans la base de données BDAMZ.
Si c'est le cas, au cours d'une étape F15, le serveur Web SWAMZ utilise une API du client SIP VOIPAMZ attaché au terminal additionnel TA pour demander l'établissement d'un appel sortant de voix sur IP vers le numéro NUMCALLED, en utilisant dans l'offre SDP (en anglais Session Description Protocol) les codées supportés par la passerelle WebRTC du serveur Web SWAMZ et une adresse IP d'écoute @IPWRTC.
Au cours d'une étape F20, le client SIP VOIPAMZ attaché au terminal additionnel TA génère un message SIP INVITE (requête d'établissement d'appel au sens de l'invention) comportant :
- dans les champs RURI et TO le numéro appelé NUMCALLED ;
- dans le champ FROM : i/ une valeur aléatoire « aléa » si le client SIP VOIPAMZ ne supporte pas l'entête SIP P- Associated-URI reçu dans la réponse 200 OK à l'étape E55 ; soit ii / le ou l'un des numéros de téléphone de la ligne VoIP du terminal nominal NUMTN, si le client SIP VOIPAMZ attaché au terminal additionnel TA supporte cet entête SIP P-Associated-URI ;
- dans les champs CONTACT, VIA, l'adresse @VOIPAMZ du client SIP VOIPAMZ attaché au terminal additionnel TA, le paramètre Instance-ID étant valorisé par l'adresse source @IPSOURŒ de la requête HTTPS d'établissement d'appel REA ;
- dans le champ SDP, les informations fournies par la passerelle WebRTC du serveur Web SWAMZ ; et
- dans le champ ROUTE, l'adresse @SBCAMZ du contrôleur SBCAMZ du réseau NAMZ.
De manière optionnelle, si le client SIP VOIPAMZ attaché au terminal additionnel TA supporte l'entête SIP P-Associated-URI et si l'utilisateur du terminal TA ne souhaite pas présenter l'identité publique IMPU par défaut à son correspondant appelé, le champ P-Preferred-ID peut être utilisé en le valorisant avec l'une des identités publiques IMPU présentes dans le champ P-Associated-URI reçue dans la réponse 200 OK REGISTER.
Dans le mode de réalisation décrit ici, le message SIP INVITE est routé jusqu'au contrôleur SBCAMZ selon un protocole de transport non sécurisé, par exemple UDP, TCP ou STCP.
Au cours d'une étape F25, le message SIP INVITE est modifié par le contrôleur SBCAMZ :
- l'adresse @IPSDP du SDP généré par la passerelle WebRTC est remplacée par l'adresse @SBCAMZ du contrôleur SBCAMZ ;
- dans les champs CONTACT, VIA, l'adresse @VOIPAMZ est remplacée par l'adresse @SBCAMZ du contrôleur SBCAMZ, le paramètre Instance-ID est inchangé ;
- dans le champ ROUTE, l'adresse @SBCAMZ est remplacée par l'adresse @SBCOP du contrôleur SBCOP du réseau NOP de l'opérateur OP.
Le message SIP INVITE est envoyé dans le tunnel TLS au contrôleur SBCOP.
Au cours d'une étape F30, le message SIP INVITE est modifié par le contrôleur SBCOP :
- l'adresse @SBCAMZ du contrôleur SBCAMZ est remplacée par l'adresse @SBCOP du contrôleur SBCOP au niveau du paramètre SDP;
- dans les champs CONTACT, VIA, l'adresse @SBCAMZ du contrôleur SBCAMZ est remplacée par l'adresse @SBCOP du contrôleur SBCOP, le paramètre Instance-ID est inchangé ;
- dans le champ ROUTE, l'adresse @SBCOP du contrôleur SBCOP est remplacée par l'adresse @100 du serveur SRVAS de gestion des demandes d'accès à un service compris dans le serveur proxy 100.
Le message SIP INVITE est routé jusqu'au serveur SRVAS de gestion des demandes d'accès à un service. Dans le mode de réalisation décrit ici, le message est transporté par un protocole de transport non sécurisé, par exemple UDP, TCP, STCP.
Au cours d'une étape F35, le serveur SRVAS de gestion des demandes d'accès à un service du serveur proxy 100 vérifie si une adresse IP contenue dans le message SIP INVITE est enregistrée dans un contexte CTX créé par le serveur SIP Registrar (étape E40). Cette adresse peut être par exemple l'adresse IP source du paquet IP contenant le message SIP INVITE, une adresse comprise dans le champ SIP Via ou dans le champ SIP Contact ou dans le paramètre Instance-Id. Si le serveur SRVAS trouve un contexte CTX comportant une adresse IP dans le message SIP INVITE, il autorise l'appel sortant. Sinon, il renvoie une réponse SIP 403 Forbidden ou 480 Calling Party not Registered au client SIP VOIPAMZ.
De manière alternative ou complémentaire, le serveur SRVAS du serveur proxy 100 vérifie si une identité publique IMPU contenue dans le message SIP INVITE au niveau des champs SIP FROM et/ou P-Preferred-ID est enregistrée dans un contexte CTX créé par le serveur SIP Registrar (étape E40).
Si le serveur SRVAS de gestion des demandes d'accès à un service intégré au serveur proxy 100 autorise l'appel sortant, au cours d'une étape F40 il modifie le message SIP INVITE :
- si le champ FROM comporte une valeur aléatoire (c'est le cas si le client SIP VOIPAMZ n'a pas interprété l'entête SIP P-Associated-URI reçu à l'étape E55), cette valeur est remplacée par le numéro de téléphone NUMTN associé à la ligne VoIP attribué au terminal nominal TN et mémorisé dans le contexte CTX ;
- au moins une identité appelante certifiée PAI (P-Asserted-ID) est ajoutée, correspondant à l'identité publique IMPU contenue dans le champ FROM et certifiée ;
- dans le champ CONTACT, l'adresse @SBCOP du contrôleur SBCOP est remplacée par l'adresse @100 du serveur proxy 100 ;
- dans le champ ROUTE, l'adresse @100 du serveur proxy est remplacée par l'adresse IP de l'entité I- CSCF (Interrogating Call Session Control Function) du réseau NCSOP et le paramètre « orig » est ajouté pour que l'appel entrant soit traité en mode OOTB comme s'il s'agissait d'un appel sortant émis par le terminal nominal TN.
Le message SIP INVITE est acheminé vers l'entité I-CSCF du réseau NCSOP.
De façon connue, lorsque l'I-CSCF détecte la présence du paramètre « orig » dans le champ ROUTE du message SIP INVITE, après avoir vérifié que le serveur proxy 100 est un équipement autorisé, il comprend qu'il doit traiter l'appel en mode OOTB. Il doit donc retrouver le profil de service VoIP du compte associé à l'identité publique IMPU certifiée présente dans l'identité appelante certifiée PAI du message SIP INVITE, c'est-à-dire au terminal nominal TN et non pas à celui du numéro appelé NUMCALLED du champ RURI ou TO.
Ce traitement est connu de l'homme du métier. Le I-CSCF consulte la base de données HSS via le protocole DIAMETER en lui envoyant un message LIR (Location Information Request) avec pour paramètre le numéro de téléphone NUMTN compris dans le paramètre PAI (P-Asserted-ID) du message SIP INVITE.
La base de données HSS retourne au I-CSCF l'adresse du S-CSCF prenant en charge cet abonné IMS.
L'entité S-CSCF dispose du profil du compte de service associé à l'identité publique NUMTN, autrement dit au terminal nominal TN.
Le S-CSCF modifie le message SIP INVITE. En particulier :
- un entête P-Served-User est ajouté et valorisé avec l'identité publique NUMTN avec le paramètre Session = Orig ;
- un champ ROUTE est ajouté et valorisé par l'adresse @TAS du serveur TAS
Le S-CSCF envoie le message SIP INVITE au serveur d'application téléphonique TAS (en anglais Telephony Application Server), le paramètre P-Served-User de ce message étant valorisé avec le numéro NUMTN et le paramètre Session=Orig pour que celui-ci exécute les services Originating.
Si le numéro appelé NUMCALLED n'est pas barré via le service Originating, le message SIP INVITE est routé de manière classique jusqu'au destinataire NUMCALLED.
Le client VOIPAMZ de voix sur IP attaché au terminal additionnel TA reçoit un code SIP provisoire 180 Ringing. Il notifie le serveur Web SWAMZ qui notifie à son tour le terminal additionnel TA et celui-ci génère un retour de sonnerie.
Le flux média est transmis en mode sécurisé via le protocole SRTP lorsque ce trafic emprunte le réseau IP Internet public puis en mode non sécurisé via le protocole RTP lorsque ce trafic emprunte le réseau NAMZ. Dans le mode de réalisation décrit précédemment le service accédé par le terminal additionnel TA est une demande d'appel en voix sur IP et la requête est une requête INVITE.
L'invention s'applique de la même façon pour accéder à d'autres services. Il suffit de rechercher l'information (adresse IP et/ou information contenue dans un champ FROM et/ou P-Preferred-ID) dans la requête MESSAGE, INFO, SUBSCRIBE, OPTIONS, REFER, PUBLISH émise par le client SIP pour demander l'accès à ce service.
La figure 6 représente sous forme d'ordinogramme les principales étapes de gestion d'un service entrant dirigé vers un terminal additionnel TA conformément à un mode de réalisation de l'invention.
Dans le mode de réalisation décrit ici, ce procédé est mis en œuvre par le serveur SRVic de gestion des services entrants compris dans le dispositif proxy 100.
On suppose qu'une identité NUMioo attribuée au serveur SRVic de gestion des services entrants a été préalablement enregistrée en tant que numéro appelé secondaire du terminal TN dans le serveur d'application téléphonique TAS du réseau NCSOP de cœur SIP de manière à ce que le serveur d'application téléphonique TAS déclenche, lorsqu'il détecte un service entrant dirigé vers le terminal nominal TN, un mécanisme de redirection de ce service, vers le serveur SRVic de gestion des services entrants.
Dans le mode de réalisation décrit ici, le service entrant est un appel en voix sur IP et le mécanisme de redirection est un renvoi d'appel simultané ou séquentiel de cet appel vers le serveur SRVic.
Cet enregistrement peut être fait pour tous les terminaux nominaux TN ou n'être fait que pour les terminaux nominaux TN associés à une identité publique IMPU enregistrée dans un contexte CTX. Par exemple, cet enregistrement peut être effectué par le serveur d'enregistrement SRVREG.
Ainsi, en reprenant l'exemple décrit à la figure 3 de l'enregistrement fictif du terminal additionnel TA, lorsqu'à l'étape E35, le serveur d'enregistrement SRVREG obtient, de la base de données BDGI du gestionnaire d'identités GIOP le numéro téléphonique NUMTN de la ligne VoIP associée au terminal nominal TN, il enregistre l'identité NUMioo du serveur SRVic de gestion des services entrants en tant que numéro appelé secondaire du terminal TN dans le serveur d'application téléphonique TAS.
Ainsi, et de façon connue, quand un appel entrant destiné à l'identité publique IMPU du terminal nominal TN contenue dans les header SIP RURI et TO d'un message SIP INVITE est présenté à un réseau NCSOP de cœur SIP, le serveur d'application téléphonique TAS dirige cet appel vers le terminal nominal TN, puis simultanément ou séquentiellement vers le serveur SRVic de gestion des services entrants. Un tel mécanisme est connu de l'homme du métier sous le nom de « forking ».
Plus précisément, et de façon connue de l'homme du métier, le serveur d'application téléphonique TAS génère un appel sortant de type renvoi d'appel avec :
- l'exécution des services Originating. Le serveur TAS vérifie en particulier que l'identité NUMioo du serveur SRVic est bien autorisée par le service Outgoing Call Barring : - génération d'un message SIP INVITE sortant dans lequel:
- les champs RURI et TO comportent l'identité NUMioo du serveur SRVic de gestion des services entrants ;
- les champs FROM et PAI comportent les informations FROM & PAI du message SIP INVITE reçu par le TAS ;
- le champ CONTACT comporte l'adresse @TAS du serveur d'application téléphonique TAS ;
- un champ de redirection DIVERSION et/ou HISTORY INFO comporte l'identité publique IMPU NUMTN de la ligne VoIP appelée, le paramètre cause de renvoi étant valorisé à FollowMe, et le compteur de renvoi étant valorisé à 1.
Ce message INVITE est reçu par le serveur SRVic de gestion des services entrants compris dans le dispositif proxy 100 au cours d'une étape G05.
Au cours d'une étape G10, le serveur SRVic de gestion des services entrants recherche :
- si le message SIP INVITE comporte un entête SIP de redirection DIVERSION ou HISTORY INFO ; et lorsque c'est le cas
- si un contexte CTX créé par le serveur d'enregistrement SRVREG (comme décrit en référence à la figure 3) comporte l'identité publique IMPU comprise dans ce champ de redirection DIVERSION ou HISTORY INFO, en l'espèce l'identité publique NUMTN.
Si cette double condition n'est pas satisfaite, le serveur SRVic répond un code erreur SIP, par exemple 404 Not Found ou 480 Temporarily Unavailable ou 403 Forbidden.
Si aucun contexte n'est trouvé, le serveur SRVic répond un code erreur SIP, par exemple 404 Not Found ou 480 Temporarily Unavailable ou 403 Forbidden.
Si un contexte CTX est trouvé, au cours d'une étape G15, le serveur SRVic modifie le message INVITE :
- dans le champ RURI, l'identité NUMioo du serveur SRVic est remplacée par l'adresse @SBCOP de Contact comprise dans le contexte CTX, représentative de l'adresse @VOIPAMZ du client SIP VOIPAMZ attaché au terminal additionnel TA ; et
- dans le champ TO, l'identité NUMioo du serveur SRVic est remplacée par l'identité publique IMPU NUMTN contenue dans le champ SIP de redirection DIVERSION ou HISTORY-INFO. Il s'agit d'une identité publique IMPU du champ P-Associated-URI du message SIP 200 OK généré par le serveur d'enregistrement SRVREG à l'étape E45.
Le champ SIP de redirection DIVERSION et/ou HISTORY INFO peut être supprimé.
Le message SIP modifié est routé vers le client SIP VOIPAMZ attaché au terminal additionnel TA via le contrôleur SBCOP de l'opérateur, le tunnel TLS et le contrôleur SBCAMZ du réseau NAMZ.
Ce dernier notifie le serveur Web SWAMZ de l'appel entrant. Le serveur SBCAMZ recherche dans la base de données BDAMZ, l'identifiant unique IDTA de terminal additionnel TA associé à l'identité publique IMPU NUMTN contenue dans le TO du message SIP INVITE, puis notifie l'appel entrant au terminal additionnel TA.
Dans le mode de réalisation décrit précédemment, le serveur SRVREG, le serveur SRVAS de gestion des demandes d'accès à un service et le serveur SRVic de gestion des appels entrants sont intégrés dans un serveur proxy 100.
En variante, le serveur SRVREG, le serveur SRVAS de gestion des demandes d'accès à un service et le serveur SRVic de gestion des appels entrants peuvent être des équipements distincts qui partagent le contexte CTX.
La figure 7A représente l'architecture fonctionnelle du serveur d'enregistrement SRVREG dans un mode particulier de réalisation. Il comporte :
- un module ME30 de réception d'une requête d'enregistrement en provenance d'un client SIP apte à s'enregistrer dans un réseau de cœur SIP d'un opérateur pour activer au moins un service pour un terminal additionnel ;
- un module ME35 de recherche d'au moins une adresse IP connue de l'opérateur dans cette requête d'enregistrement ;
- un module ME40 de création d'un contexte comportant au moins une adresse de contact représentative de l'adresse du client SIP attaché au terminal additionnel TA et au moins une identité publique associée à un compte géré par l'opérateur dans ledit réseau, ce compte pouvant être utilisé pour fournir au moins un service au terminal additionnel et
- un module ME45 d'envoi d'une réponse destinée audit client SIP attaché au terminal additionnel TA pour que celui-ci détermine les services dont le terminal additionnel peut bénéficier.
La figure 7B représente l'architecture fonctionnelle du serveur SRVAS de gestion d'au moins une demande d'accès à un service émise par un terminal additionnel TA pour accéder à un service dans un réseau de cœur SIP, dans un mode particulier de réalisation. Ce serveur comportant :
- un module MF30 de réception d'une requête d'accès à un service émise par un client SIP et considérant à tort être enregistré dans ce réseau;
- un module MF35 pour vérifier si au moins une information contenue dans la requête est enregistrée dans un contexte en association avec une identité publique associée à un compte géré par cet opérateur dans le réseau, cette information pouvant être une adresse IP et/ou une information contenue dans un champ FROM et/ou P-Preferred-ID de la requête ;
- un module MF40 d'envoi d'une requête à une entité du réseau de cœur SIP pour établir ledit service pour le client SIP attaché au terminal additionnel TA en utilisant un profil de service de ce compte.
La figure 7C représente l'architecture fonctionnelle du serveur SRVic de gestion des services entrants destinés dirigés vers un terminal additionnel d'un terminal nominal dans un mode particulier de réalisation. Ce serveur comporte :
- un module MG05 de réception d'une requête d'établissement de service en provenance d'un serveur d'application téléphonique, ce serveur téléphonique comportant au moins un enregistrement d'une identité attribuée audit serveur en tant que numéro appelé secondaire du terminal nominal pour déclencher un mécanisme de redirection d'un service destiné audit terminal nominal vers ledit serveur de gestion des services entrants ;
- un module MG10 pour vérifier si ladite requête d'établissement de service comporte une identité publique IMPU comprise dans un de ses champs et associée dans un contexte à une adresse de contact représentative de l'adresse d'un client SIP ;
- un module MG15 de transfert de la requête d'établissement de service vers l'adresse de contact pour qu'elle soit acheminée jusqu'au dit client SIP attaché au terminal additionnel TA.
Chacun de ces serveurs peut avoir l'architecture matérielle d'un ordinateur tel que représenté à la figure 8.
Cet ordinateur ORD comporte notamment un processeur 10, une mémoire vive de type RAM 11, une mémoire morte de type ROM 12, une mémoire non volatile réinscriptible de type Flash 14 et des moyens de communication 13.
La mémoire morte 12 constitue un support conforme à un mode particulier de réalisation de l'invention. Cette mémoire comporte un programme d'ordinateur PG conforme à un mode particulier de réalisation de l'invention, qui lorsqu'il est exécuté par le processeur 10, met en œuvre un ou plusieurs des procédés d'enregistrement, de gestion des appels sortants ou de gestion des appels entrants conformes à l'invention et décrits précédemment en référence aux figures 3, 5 et 6.
Dans le mode de réalisation décrit ici, la mémoire 14 de l'ordinateur ORD comporte un contexte CTX tel que décrit précédemment, notamment en référence à la figure 4.
Dans l’exemple de la figure 1 , le dispositif de traduction d'adresses NAPT est intégré dans le module AP : il établit une correspondance entre les adresses IPV4 privées du réseau WLAN et une adresse IPV4 publique attribué par le réseau à l'interface WAN. La fonction de traduction d’adresses peut aussi être mise en œuvre dans un équipement réseau de type CGN (Carrier Grade NAT).

Claims

REVENDICATIONS
[Revendication 1] Procédé d'enregistrement d'un terminal additionnel (TA) mis en œuvre par un serveur d'enregistrement (SRVREG), ledit terminal additionnel (TA) étant un terminal qui partage son identité publique avec un terminal nominal (TN), ce procédé comportant :
- une étape (E30) de réception d'une requête d'enregistrement en provenance d'un client SIP (VOIPAMZ) attaché au terminal additionnel (TA) et apte à s'enregistrer dans un réseau (NCSOP) de cœur SIP d'un opérateur (OP), pour activer au moins un service pour le terminal additionnel (TA) dans ledit réseau;
- une étape (E35) de recherche d'au moins une adresse IP connue de l'opérateur (OP) dans ladite requête d'enregistrement ;
- une étape (E40) de création d'un contexte (CTX) comportant au moins une adresse de contact (@SBCOP) représentative de l'adresse (@VOIPAMZ) du client SIP (VOIPAMZ) et au moins une identité publique (NUMTN) associée à un compte dudit terminal nominal (TN) géré par l'opérateur dans ledit réseau (NCSOP) et associé à ladite adresse IP, ce compte pouvant être utilisé pour fournir au moins un service audit terminal additionnel (TA) ;
- une étape de détermination d'au moins un service dont ledit terminal additionnel peut bénéficier ; et
- une étape (E45) d'envoi d'une réponse destinée audit client SIP (VOIPAMZ) et comportant des informations obtenues par le serveur d'enregistrement lors de ladite étape de détermination pour que ledit client SIP (VoIPAMz)détermine les services dont le terminal additionnel (TA) peut bénéficier.
[Revendication 2] Procédé d'enregistrement selon la revendication 1 dans lequel ledit contexte (CTX) comporte en outre ladite adresse obtenue au cours de ladite étape (E35) de recherche et associée audit compte.
[Revendication 3] Procédé d'enregistrement selon la revendication 1 ou 2 dans lequel ledit contexte (CTX) comporte en outre au moins une information de service définissant au moins un droit d'accès à un service pour au moins un type de terminal additionnel (TA).
[Revendication 4] Procédé d'enregistrement selon Tune quelconque des revendications 1 à 3 dans lequel ledit contexte (CTX) est destiné à être utilisé pour :
- déclencher (F40), dans ledit réseau (NCSOP) de cœur SIP, l'établissement d'un service pour le client SIP (VOIPAMZ) en utilisant un profil de service d'un compte associé à ladite identité publique (NUMTN) et/ou pour
- rediriger (G15) jusqu'au dit client SIP (VOIPAMZ), un service dirigé vers ladite identité publique (NUMTN) dans ledit réseau (NCSOP) de cœur SIP.
[Revendication 5] Procédé d'enregistrement selon Tune quelconque des revendications 1 à 4 dans lequel ladite requête d'enregistrement est une requête SIP REGISTER et en ce que ladite au moins adresse IP recherchée (E35) dans ladite requête d'enregistrement est comprise dans un champ IP source du paquet IP ou Instance-ID, Via, ou Contact de ladite requête.
[Revendication 6] Procédé d'enregistrement selon l'une quelconque des revendications 1 à 5 dans lequel ledit au moins un service utilisable par ledit terminal additionnel (TA) est explicitement enregistré dans ledit contexte (CTX) et/ou précisé dans ladite réponse.
[Revendication 7] Procédé d'enregistrement selon l'une quelconque des revendications 1 à 6 dans lequel une durée d'utilisation dudit au moins un service par ledit terminal additionnel (TA) est explicitement enregistrée dans ledit contexte (CTX) et/ou précisée dans ladite réponse.
[Revendication 8] Procédé de gestion d'une demande (REA) émise par un terminal additionnel (TA) pour accéder à un service dans un réseau (NCSOP) de cœur SIP, ledit terminal additionnel (TA) étant un terminal qui partage son identité publique avec un terminal nominal (TN), ce procédé comportant :
- une étape (F30) de réception d'une requête d'accès à un service émise par un client SIP (VOIPAMZ) attaché audit terminal additionnel (TA), ledit client SIP (VOIPAMZ) n'étant pas enregistré dans ledit réseau (NCSOP) ;
- une étape (F35) pour vérifier si au moins une information contenue dans la requête d'accès à un service et représentative de l'adresse (@VOIPAMZ) dudit client SIP (VOIPAMZ) est enregistrée dans un contexte (CTX) en association avec une identité publique (NUMTN) associée à un compte dudit terminal nominal (TN) géré par un opérateur dudit réseau (NCSOP) ;
- une étape (F40) d'envoi d'une requête à une entité du réseau (NCSOP) de cœur SIP pour établir ledit service pour ledit client SIP (VOIPAMZ) en utilisant un profil de service dudit compte.
[Revendication 9] Procédé de gestion selon la revendication 8 dans lequel ladite au moins une information est :
- une adresse IP ; et/ou
- une information contenue dans un champ FROM et/ou P-Preferred-ID de ladite requête.
[Revendication 10] Procédé de gestion d'un service entrant dirigé vers un terminal additionnel (TA) d'un terminal nominal (TN), ledit terminal additionnel (TA) étant un terminal qui partage son identité publique avec ledit terminal nominal (TN), ce procédé étant mis en œuvre par un serveur (SRVic) de gestion des services entrants et comportant :
- une étape préalable d'enregistrement d'une identité (NUMioo) attribuée audit serveur (SRVic) en tant qu'identité appelée secondaire du terminal nominal (TN) dans un serveur d'application téléphonique (TAS) pour déclencher un mécanisme de redirection d'un service dirigé vers ledit terminal nominal (TN) vers ledit serveur (SRVic) de gestion des services entrants ;
- une étape (G05) de réception d'une requête d'établissement de service en provenance dudit serveur d'application téléphonique (TAS) ;
- une étape (G10) pour vérifier si ladite requête d'établissement de service comporte une identité publique IMPU (NUMTN) comprise dans un de ses champs et associée dans un contexte (CTX) à une adresse de contact (@SBCOP) représentative de l'adresse (@VOIPAMZ) d'un client SIP (VOIPAMZ) attaché au terminal additionnel (TA);
- une étape (G15) de transfert de ladite requête d'établissement de service vers l'adresse de contact pour qu'elle soit acheminée jusqu'au dit client SIP (VOIPAMZ).
[Revendication 11] Serveur d'enregistrement (SRVREG) comportant :
- un module (ME30) de réception d'une requête d'enregistrement en provenance d'un client SIP (VOIPAMZ) apte à s'enregistrer dans un réseau (NCSOP) de cœur SIP d'un opérateur (OP), pour activer dans ledit réseau au moins un service pour un terminal additionnel (TA) auquel ledit client SIP (VOIPAMZ) est attaché, ledit terminal additionnel (TA) étant un terminal qui partage son identité publique avec un terminal nominal (TN);
- un module (ME35) de recherche d'au moins une adresse IP connue de l'opérateur (OP) dans ladite requête d'enregistrement ;
- un module (ME40) de création d'un contexte (CTX) comportant au moins une adresse de contact (@SBCOP) représentative de l'adresse (@VOIPAMZ) du client SIP (VOIPAMZ) et au moins une identité publique (NUMTN) associée à un compte dudit terminal nominal (TN) géré par l'opérateur dans ledit réseau (NCSOP) et associé à ladite adresse IP, ce compte pouvant être utilisé pour fournir au moins un service audit terminal additionnel (TA) ;
- un module de détermination d'au moins un service dont ledit terminal additionnel peut bénéficier ;
- un module (ME45) d'envoi d'une réponse destinée audit client SIP (VOIPAMZ) et comportant des informations obtenues par le serveur d'enregistrement lors de ladite étape de détermination pour que ledit client SIP (VOIPAMZ)Î détermine les services dont le terminal additionnel (TA) peut bénéficier.
[Revendication 12] Serveur (SRVAS) de gestion d'au moins une demande émise par un terminal additionnel (TA) pour accéder à un service dans un réseau (NCSOP) de cœur SIP, ledit terminal additionnel (TA) étant un terminal qui partage son identité publique avec un terminal nominal (TN), ce serveur comportant :
- un module (M30) de réception d'une requête d'accès à un service émise par un client SIP (VOIPAMZ) attaché audit terminal additionnel (TA), ledit client SIP (VOIPAMZ) n'étant pas enregistré dans ledit réseau (NCSOP) ;
- un module (MF35) pour vérifier si au moins une information contenue dans ladite requête et représentative de l'adresse (@VOIPAMZ) dudit client SIP (VOIPAMZ) est enregistrée dans un contexte (CTX) en association avec une identité publique (NUMTN) associée à un compte dudit terminal nominal (TN) géré par un opérateur (OP) dudit réseau (NCSOP) ;
- un module (MF40) d'envoi d'une requête à une entité du réseau (NCSOP) de cœur SIP pour établir ledit service pour ledit client SIP (VOIPAMZ) en utilisant un profil de service dudit compte.
[Revendication 13] Serveur (SRVic) de gestion des services entrants dirigés vers au moins un terminal additionnel (TA) d'un terminal nominal (TN), ledit terminal additionnel (TA) étant un terminal qui partage son identité publique avec ledit terminal nominal (TN), ce serveur comportant :
- un module (MG05) de réception d'une requête d'établissement de service en provenance d'un serveur d'application téléphonique (TAS), ledit serveur téléphonique (TAS) comportant au moins un enregistrement d'une identité (NUMioo) attribuée audit serveur (SRVic) en tant qu'identité appelée secondaire du terminal nominal (TN) pour déclencher un mécanisme de redirection d'un service dirigé vers ledit terminal nominal (TN) vers ledit serveur (SRVic) de gestion des services entrants ;
- un module (G10) pour vérifier si ladite requête d'établissement de service comporte une identité publique IMPU (NUMTN) comprise dans un de ses champs et associée dans un contexte (CTX) à une adresse de contact (@SBCOP) représentative de l'adresse (@VOIPAMZ) d'un client SIP (VOIPAMZ) attaché au terminal additionnel (TA);
- un module (MG15) de transfert de la requête d'établissement de service vers l'adresse de contact pour qu'elle soit acheminée jusqu'au dit client SIP (VOIPAMZ).
[Revendication 14] Serveur proxy SIP (100) comportant un serveur d'enregistrement (SRVREG) selon la revendication 11, un serveur (SRVAS) de gestion d'une demande d'accès à un service selon la revendication 12 et un serveur (SRVic) de gestion des services entrants selon la revendication 13.
[Revendication 15] Programme d'ordinateur (PG) comportant des instructions configurées pour mettre en œuvre les étapes d'un procédé selon l'une quelconque des revendications 1 à 10 lorsqu'elles sont exécutées par un ordinateur (ORD).
PCT/FR2021/051061 2020-06-22 2021-06-14 Procedes et serveurs de gestion des services d'un terminal additionnel dans un reseau de coeur sip WO2021260290A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2006511A FR3111496B1 (fr) 2020-06-22 2020-06-22 Procédés et serveurs de gestion des services d’un terminal additionnel dans un réseau de cœur SIP
FRFR2006511 2020-06-22

Publications (1)

Publication Number Publication Date
WO2021260290A1 true WO2021260290A1 (fr) 2021-12-30

Family

ID=72709526

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2021/051061 WO2021260290A1 (fr) 2020-06-22 2021-06-14 Procedes et serveurs de gestion des services d'un terminal additionnel dans un reseau de coeur sip

Country Status (2)

Country Link
FR (1) FR3111496B1 (fr)
WO (1) WO2021260290A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1990968A1 (fr) * 2007-05-07 2008-11-12 Nokia Siemens Networks Oy Procédé pour faire fonctionner un système de télécommunications
EP3471379A1 (fr) * 2017-10-12 2019-04-17 Deutsche Telekom AG Méthode et appareils de service multi-identité basées sur l'enregistrement d'identités partagées

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1990968A1 (fr) * 2007-05-07 2008-11-12 Nokia Siemens Networks Oy Procédé pour faire fonctionner un système de télécommunications
EP3471379A1 (fr) * 2017-10-12 2019-04-17 Deutsche Telekom AG Méthode et appareils de service multi-identité basées sur l'enregistrement d'identités partagées

Also Published As

Publication number Publication date
FR3111496B1 (fr) 2023-06-30
FR3111496A1 (fr) 2021-12-17

Similar Documents

Publication Publication Date Title
EP1560368A1 (fr) Procédé d'établissement d'une session multimédia entre un équipement appelant et un équipement appelé d'un réseau du type à sous domaine multimédia et système de communication mettant en oeuvre ce procédé
EP3417591B1 (fr) Procédé et serveur de sélection d'un serveur d'entrée d'un réseau de communication ims
WO2006024791A1 (fr) Procede et systeme de localisation d'utilisateurs pour les services bases sur les protocoles sip ou h.323 avec attribution d'adresse ip dynamique.
EP3639541B1 (fr) Configuration d'un terminal dans un réseau ims avec une stratégie de resélection d'un type réseau
WO2013057437A1 (fr) Procede d'echange d'informations relatives a des services de communication enrichie
WO2012153033A1 (fr) Procede de traitement d'une requete de basculement d'une communication entre deux reseaux d'acces
WO2016102841A1 (fr) Procédé et dispositif de maintien d'associations d'adresses de transport auprès d'une entité de traduction d'adresses
EP2550776B1 (fr) Procede de gestion des enregistrements dans un reseau ims et serveur s-cscf mettant en oeuvre ce procede
EP3646554B1 (fr) Procédé de traitement d'une requête et serveur d'un coeur de réseau ip multimédia
WO2014009502A1 (fr) Procede d'enregistrement d'au moins une adresse publique dans un reseau ims et application correspondante
WO2013178909A1 (fr) Procédé et entité de traitement d'un message
WO2021260290A1 (fr) Procedes et serveurs de gestion des services d'un terminal additionnel dans un reseau de coeur sip
WO2009122078A1 (fr) Partage de contenu multi supports a partir d'une communication audio-video
EP3391615B1 (fr) Procédé de communication entre un terminal appelant et une pluralité de terminaux appelés
WO2014114871A1 (fr) Enregistrement d'un equipement client par l'intermediaire d'un serveur mandataire dans un reseau de communication
EP2365686B9 (fr) Procédé et dispositif de traitement d'appels dans un réseau de communication comprenant des terminaux nomades tels que des terminaux de téléphonie de type softphone
EP2859704B1 (fr) Serveur d'application et procede de traitement d'un message destine a une identite publique partagee par une pluralite de dispositifs
EP2458813B1 (fr) Procédé de détection d'une situation de nomadisme d'un terminal SIP et terminal mettant en oeuvre ce procédé
WO2013121158A1 (fr) Procédé d'enregistrement d'un serveur d'application et serveur d'application
WO2014170582A1 (fr) Procede de restauration de service dans un reseau ims
EP3643035A1 (fr) Procédé de contrôle de l'obtention par un terminal d'un fichier de configuration
EP3583757A1 (fr) Procédé de changement de réseau mobile
FR2988951A1 (fr) Procede d'enregistrement d'un serveur aupres d'une pluralite de coeurs de reseau, et serveur.
WO2013102716A1 (fr) Procede dynamique de determination d'une liste de services dans un reseau sip

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21737486

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21737486

Country of ref document: EP

Kind code of ref document: A1