EP4659434A1 - Procédé de gestion d'un test de la qualité d'une liaison de communication téléphonique - Google Patents

Procédé de gestion d'un test de la qualité d'une liaison de communication téléphonique

Info

Publication number
EP4659434A1
EP4659434A1 EP24701024.2A EP24701024A EP4659434A1 EP 4659434 A1 EP4659434 A1 EP 4659434A1 EP 24701024 A EP24701024 A EP 24701024A EP 4659434 A1 EP4659434 A1 EP 4659434A1
Authority
EP
European Patent Office
Prior art keywords
test
terminal
link
ter
tst
Prior art date
Legal status (The legal status 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 status listed.)
Pending
Application number
EP24701024.2A
Other languages
German (de)
English (en)
Inventor
Juan Pascual
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
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 SA filed Critical Orange SA
Publication of EP4659434A1 publication Critical patent/EP4659434A1/fr
Pending legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80Responding to QoS
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/08Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0852Delays
    • H04L43/0864Round trip delays
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/10Active monitoring, e.g. heartbeat, ping or trace-route
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/50Testing arrangements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M3/00Automatic or semi-automatic exchanges
    • H04M3/22Arrangements for supervision, monitoring or testing
    • H04M3/2209Arrangements for supervision, monitoring or testing for lines also used for data transmission
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M3/00Automatic or semi-automatic exchanges
    • H04M3/22Arrangements for supervision, monitoring or testing
    • H04M3/2227Quality of service monitoring
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M3/00Automatic or semi-automatic exchanges
    • H04M3/22Arrangements for supervision, monitoring or testing
    • H04M3/26Arrangements for supervision, monitoring or testing with means for applying test signals or for measuring

Definitions

  • IP telephony that is to say fixed telephone connections made using the IP protocol (acronym for Internet Protocol).
  • the invention relates to a method for managing a test of the quality of a telephone communication link. Most often, the method according to the invention will be a method for managing a test of the quality of an IP telephone communication link.
  • IP Internet Protocol
  • VoIP Voice over IP
  • Old fixed telephone protocols such as RTC (acronym for Switched Telephone Network) or ISDN (acronym for Integrated Services Digital Network) are being abandoned.
  • terminal In telephony, the telephone which is at the end point of the telephone communication link and which will allow users to communicate with each other is generally called terminal.
  • IP telephones Telephone sets allowing communication via IP telephony are dedicated equipment called IP telephones. These IP phones can establish IP communication sessions with other IP phones by requesting IP telephony platforms. Once the session is established between two IP phones, a communication channel is established and voice is transmitted between the two IP phones over the IP protocol.
  • the landline phone does not connect directly to the IP network, but is present in a local network and connects to a domestic gateway which will establish the IP telephone communication.
  • a domestic gateway which serves as a relay for a telephone present in its local network.
  • the connection between the domestic gateway which serves as an IP terminal and the landline telephone is generally made with a DECT connection (acronym for Digital Enhanced Cordless Telecommunications').
  • IP telephone communication is generally done using the SIP protocol (acronym for Session Initiation Protocol) which is a general protocol for establishing communication sessions.
  • SIP protocol an acronym for Session Initiation Protocol
  • Previous versions of IP telephony used the ad hoc H.323 protocol.
  • IP telephony platforms also serve as gateways to allow IP phones and IP terminals to access terminals belonging to other telephony networks, in particular traditional fixed telephone networks or telephony networks mobile.
  • test server present in the IP telephony network, sends a request to an IP terminal whose communication link must be tested.
  • the test server transmits, after establishing the communication, data packets to the terminal which then allows it to calculate test results and give an indication as to the quality of the IP telephony communication link.
  • Carrying out the test by the server implies that the IP terminal must accept the establishment of the connection, which involves the insertion by the test server of a specific parameter in the request sent by the server to the IP terminal.
  • the test calculation can use the G.107 standard which is part of the ITU-T recommendations, i.e. recommendations for the telecommunications sector of the International Telecommunications Union.
  • the invention improves the situation.
  • the invention relates to a method for managing a test of the quality of a telephone communication link between a terminal and a test server, the telephone communication link being able to be opened or closed, the test being carried out by the test server when the link is open, characterized in that the opening of the telephone communication link is preceded by a request to open the link from the terminal and in that, during the carrying out the test of the quality of the link, said link is kept open independently of the receipt of an instruction to close the link by the terminal for a given duration.
  • the test management method ensures that the test is carried out completely by the test server.
  • a test here is a complete session of interaction between the server and the terminal, which includes several stages, and which makes it possible to obtain a whole set of information regarding the quality of the telephone communication link. The complete completion of such a test therefore takes place over a certain period of time. Completing the test requires the server to perform calculations for a certain amount of time. Keeping the communication link open for a given duration ensures that the test is carried out by the test server. The duration given is at least equal to the duration required to complete the test.
  • test is carried out at the initiative of the terminal.
  • the test can then be carried out by making a call to a dedicated number operated by the test server. It is therefore important in this case to ensure that the terminal does not hang up before the tests are completed.
  • the invention ensures that, even if a user hangs up before the tests are complete, the terminal will keep the link open to ensure the completion of the test steps.
  • the test server may have a dedicated telephone number which will be called by a terminal at the initiative of a user, who will simply dial the number. This action will trigger the opening of the communication link between the terminal and the test server following a request issued by the terminal. Opening the link will allow the server to start testing.
  • the advantage of this mode is that the test is carried out at the initiative of the customers, which avoids customers having to contact the after-sales service of the telephone service operator. The test is carried out remotely and at the initiative of customers, which minimizes the need to involve the telephone operator's after-sales service.
  • the instruction to close the link is postponed for a given duration but will be executed later.
  • the close instruction is a hang-up operation performed by a terminal user
  • the advantage of this mode is that the test will be completed, but the instruction will also be completed, even if it is delayed. As long as the necessary delay is limited, it is possible that the user will not notice the delay in execution of the close instruction.
  • This mode has the advantage of simplifying the processing of closing instructions received by the terminal.
  • the link is an open IP telephone communication link between the terminal and the test server, said link comprising a signaling channel allowing the test server to obtain information relating to the signaling and the performance, by the test server, of the test of the quality of the link depends on the information obtained relating to the signaling.
  • An IP telephone communication link generally comprises two channels, a channel making it possible to exchange information relating to signaling, and therefore to the establishment of the communication, and a multimedia data transmission channel which makes it possible in particular to exchange the voice signal between the two IP stations. It is this channel that allows users to talk to each other, their speech being transformed into IP data packets, and exchanged back and forth in the data transmission channel present in the open telephone communications link. Thanks to this mode of implementation, the test steps carried out are divided into two categories: on the one hand, tests relating to signaling, and on the other hand tests relating to the transmission of data packets. As the speech signal is transmitted by data packets, testing the quality of an IP telephone communication link mainly relies on testing relating to data transmission. However, signaling testing is also useful.
  • One of the advantages of this mode is to be able to carry out a quality test depending on the signaling information obtained.
  • signaling information makes it possible to know the IP terminal initiating the test.
  • the test server can then differentiate the tests according to the terminal at the origin of the opening of the link which is used for the test. For example, a telecommunications operator may refuse to run tests from terminals that are not its customers. Or, an operator will be able to carry out more or less detailed tests depending on the subscription of the customer owning the terminal at the origin of the test.
  • the opening of the link is preceded by a request to open the link from the terminal.
  • the test server may have a dedicated telephone number which will be called by a terminal at the initiative of a user, who will simply dial the number. This action will trigger the opening of the communication link between the terminal and the test server following a request issued by the terminal. Opening the link will allow the server to start testing.
  • the advantage of this mode is that the test is carried out at the initiative of the customers, which avoids customers having to contact the after-sales service of the telephone service operator. The test is carried out remotely and at the initiative of customers, which minimizes the need to involve the telephone operator's after-sales service.
  • This mode can be implemented when terminal users call a dedicated number operated by the test server; in this case, the terminal is responsible for opening the communication link, which triggers the execution of the test by the server.
  • the opening of the telephone communication link is done by the terminal without user intervention.
  • the terminal is programmed to open the link to the test server without human intervention.
  • the advantage of this mode is to be able to carry out preventive tests, and therefore to anticipate possible problems by detecting degradation of the quality of the connection which would not necessarily have been detected by a user.
  • the link is an IP telephone communication link
  • the IP terminal can be both an IP telephone and a home gateway.
  • connection is an IP telephone communication connection and the opening of the connection is preceded by an opening request from a telephone separate from the terminal.
  • the invention adapts to the case, present in IP telephony, where the IP terminal is a domestic gateway to which terminals such as DECT telephones are attached.
  • the user of the DECT telephone distinct from the IP terminal, will call a number dedicated to the test server, and therefore create a request to open the telephone communication link. This request will then come from the IP terminal (the home gateway) to the test IP server.
  • the DECT telephone which does not have an IP interface, is still at the origin of the request to open the telephone communication link.
  • the communication link being an IP telephone communication link open between the terminal and the test server , said link comprises a multimedia data transmission channel and the terminal transmits data packets in said data transmission channel independently of instructions received through an interface of the terminal.
  • the management method comprises the reception by the terminal, for the given duration, of a message from the test server intended to be returned by the terminal.
  • the server sends a message which can for example be a voice message.
  • This message will be reproduced by the terminal, for example directly on the telephone speaker if the terminal is itself a telephone or, in the case of an IP telephony link where the IP terminal is a domestic gateway, the message will be transmitted by the IP terminal to a DECT telephone which will then reproduce the voice message on its own loudspeaker.
  • the restitution can also take the form of a restitution on a screen.
  • the message received by the terminal includes information relating to the test carried out by the test server.
  • the message received by the terminal includes elements of information on the results of the different stages of the test carried out by the test server.
  • the advantage of this mode is to immediately provide information to the user who has called a number dedicated to the test server and who has therefore triggered the quality test of his communication link.
  • an advantage is to limit the use of after-sales service on the part of users since they have a support service. self-service test, which will carry out the test steps and provide them with the results via the message sent by the test server and returned by the terminal.
  • the invention relates to an entity for managing a test of the quality of a telephone communication link between a terminal and a test server, the telephone communication link being able to be opened or closed, the test being carried out by the test server when the link is open, characterized in that the opening of the telephone communication link is preceded by a request to open the link from the terminal and in that said management entity comprises a processor configured to ensure that, during the performance of the test of the quality of the link, said link is kept open by said management entity, independently of the reception of an instruction to close the link by the terminal, for a given duration.
  • the invention relates to a terminal comprising a management entity according to the previous aspect.
  • Such a terminal is a telephone.
  • an IP terminal can be, among other things, an IP telephone or a home gateway. It can also be a computer, fixed or portable, having the capacity to carry out communications in IP telephony and attached to an IP telephone network.
  • the invention relates to a computer program capable of being implemented by a terminal according to the previous aspect, the program comprising code instructions which, when executed by a processor, carries out the management method according to the invention.
  • the computer programs in question can be written in any programming language. They can be, for example, compiled languages, or interpreted, or use a mixed mode of operation using compilation to byte code (from English bytecoded) which will then be interpreted by a virtual machine. Programs can run on hardware architectures, or in virtual machines, or in similar technologies such as container systems.
  • the invention relates to a data medium on which a computer program according to the previous aspect is recorded.
  • Data carriers can be any entity or device capable of storing programs.
  • the media may comprise a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or even a magnetic recording means such as a hard disk.
  • the media may be transmissible media such as an electrical or optical signal, which may be carried via an electrical or optical cable, by radio or by other means.
  • the programs according to the invention can in particular be downloaded on an Internet type network.
  • the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in executing the method in question.
  • FIG 1 represents an example of steps implemented within the framework of an embodiment of the invention.
  • FIG 2 represents an example of implementation of the invention by an IP terminal and a test server, the IP terminal being a domestic gateway distinct from a telephone.
  • FIG 3 represents an example of implementation of the invention by an IP telephone and a test server.
  • Figure 1 represents an example of steps implemented within the framework of an embodiment of the invention.
  • the two vertical lines represent the evolution on the one hand of a TER terminal and on the other hand of an SRV test server during the implementation of a management method according to the invention.
  • the evolution of time is represented by the passage from top to bottom along the two vertical lines.
  • the test is a quality test of an IP telephone communication link
  • the TER terminal is an IP TER terminal.
  • the IP terminal TER comprises a management entity 100 according to the invention, which implements the test management method.
  • the management entity 100 may belong to the SRV test server or belong to service platforms, not shown in the figures, which implement the IP telephony network between the IP terminal TER and the SRV test server.
  • the embodiment in which the entity management 100 is included in the IP terminal TER is the preferred mode because the management entity 100 is responsible for canceling the effect of actions intended for the IP terminal TER and a situation of the management entity 100 in the IP TER terminal is the most suitable for this.
  • the management entity 100 includes a processor and possibly one or more memories (not shown in the figures) which allow it to execute programs.
  • the presence of processors and memories in telephone terminals, or in domestic gateways which serve as TER IP terminals is classic these days.
  • the processor of the management entity 100 must have access to the network interfaces of the IP terminal TER in order to be able to intercept the instructions for closing the link L during the execution of the test.
  • the processor program must also be able to detect that link L must remain open.
  • One way of proceeding may be to associate telephone numbers dedicated to quality tests, numbers which will be stored in a memory of the management entity 100.
  • the program implementing the method according to the invention having access to the network interfaces of the IP TER terminal will then detect a call to one of these numbers dedicated to quality tests and will then begin to execute the process.
  • Another way of proceeding may be, for the SRV test server, to send, at the start of a quality test of the link L, a specific message to the management entity 100 asking it to implement the method according to the invention and to keep the link L open for a duration at least equal to the duration necessary for the execution of the TST test.
  • the IP TER terminal can take several forms.
  • the TER IP terminal can for example be a domestic gateway which provides access to the Internet network in a home or small professional premises. Such a home gateway will create a local network and will have the possibility of connecting a TEL telephone to its local network, for example using the DECT protocol.
  • the domestic gateway will be connected to an IP telephone network as an IP TER terminal and will be able to establish IP telephone communication links for the benefit of the TEL telephone. This situation is shown in Figure 2, which will be detailed later.
  • the TER IP terminal can also be a telephone capable of connecting directly to the IP telephone network. This situation is represented in Figure 3, which will be detailed later.
  • the TER IP terminal can also be a computer, fixed or portable, with the capacity to carry out IP telephony communications and attached to an IP telephone network.
  • the SRV test server for its part, generally presents the hardware architecture of a conventional computer and notably includes a processor, a RAM type RAM (for English Read Access Memory) and a read only memory such as a Flash type memory, ROM (for English Read Only Memory), or others, not shown in the figure, as well as input-output devices such as keyboards and/or screens (not shown in the figure).
  • the management entity can be a hardware server or be deployed on a cloud computing architecture (doud computing).
  • the management entity has communication links (not shown in Figure 1) which allow it to communicate with other entities to exchange data or instructions.
  • the SRV test server must be capable of being connected to IP telephone communication links in order to perform quality tests of such a link.
  • the SRV test server must therefore be connected by a communication link not shown to the IP telephone network and must be able to interact with it, for example by having one or more dedicated telephone numbers on the IP telephone network and by being able to pass instructions relating to the establishment of IP telephone communication links.
  • the SRV test server therefore has communication possibilities following the SIP or H.323 protocols or others depending on the IP telephony protocols present in the IP telephony network for which the SRV test server will carry out tests.
  • the method is implemented while an IP telephone communication link L is open between the IP terminal TER and the test server SRV.
  • a link L can be opened following several events.
  • a telephone number is dedicated to the SRV test server and a user of the IP terminal TER will dial this number in order to open the IP telephone communication link L.
  • the IP terminal TER will be capable of initiating the opening of the link L without the initiative of a user. In this mode, the IP terminal TER has programming capabilities which allow it to trigger an IP telephone call and therefore the opening of an IP telephone communication link L with the SRV server, either at scheduled times or in response to instructions not coming from a user but from other machines.
  • the IP terminal TER triggers calls to the SRV test server in a planned manner makes it possible to implement preventive maintenance of the quality of the IP telephone communication link L, by carrying out tests at regular intervals.
  • the IP telephone communication link L comprises in several embodiments a CS signaling channel and a CD multimedia data transmission channel.
  • the CS signaling channel is used to transfer information and instructions relating to telephone signaling and for example to the establishment of IP telephone communications, to the transfer of these communications, to the closure of communications or to any other signaling operation.
  • the CD multimedia data transmission channel is used to transmit multimedia data in the form of data packets.
  • the voice signal between the two ends of the IP telephone communication link L is transmitted in both directions in the form of data packets encoding the voice signal transmitted at the two ends of the link L.
  • the protocol for exchanging such multimedia data packets is the RTP protocol (acronym for Real-time Transport Protocol).
  • IP telephone communication link L is open between the IP TER terminal and the SRV test server, the latter will carry out a TST test of the quality of the link L.
  • TST test is a series of steps which will make it possible to obtain a whole set of results qualifying the quality of the link L with the IP TER terminal.
  • the execution of the entire TST test by the SRV test server takes a significant amount of time before the results of the TST test steps performed by the SRV test server are obtained. This time occupies a period represented in Figure 1 by a thicker line placed on the line representing the actions of the SRV test server and the TER IP terminal.
  • Some of the TST test steps will be executed almost instantaneously by the SRV test server, which is represented in Figure 1 by a looping arrow, arriving a little below their starting point, representing that the end of this TST test step occurs very shortly after its start.
  • Other TST test steps will, on the contrary, take a significant amount of time to be executed, which is represented by an arrow whose arrival point is significantly later than the starting point.
  • TST test are in all cases labeled TST in Figure 1, the differentiation of the different steps of the TST test having no influence on the implementation of the management method according to the invention. In all cases, it is the execution of all the steps of the TST test by the test server SRV that takes a significant amount of time.
  • the steps of the TST test can be of several types.
  • the TST test may first concern IP telephone signaling.
  • the server recovers data transmitted through the CS channel of the IP telephone communication link L established between the IP terminal TER and the SRV server.
  • the SRV server must have the means to interpret the signaling messages which will generally use the SIP protocol and possibly protocols dedicated to IP telephony such as H.323.
  • the test server TST will thus obtain a set of information relating to signaling, transmitted by the signaling channel CS. For example, in the case where the link L is opened at the initiative of the IP terminal TER using the SIP protocol, the SRV test server will be able to access the P- Asserted -Identity field ⁇ s SIP-Invite message.
  • This field allows the SRV test server to obtain information on the IP TER terminal and in particular its telephone number and the telephony platform used by the IP TER terminal to place its call.
  • the SRV test server can thus deduce from which telephone network the IP TER terminal placed its call, as well as the operator of the telephone service used by the IP TER terminal and possibly other commercial information.
  • TST test relating to signaling consists of accessing the SDP field (acronym for Session Description Protocol) present in the SIP-Invite message sent by a TER IP terminal.
  • This field allows the SRV test server to know the capabilities of the network used to establish the IP telephone communication link L between the SRV test server and the TER IP terminal.
  • the TST test server can thus deduce the codecs (programs or hardware used to encode audio or video signals, acronym for encoder-decoders) which are used by the TER IP terminal or imposed by the underlying network to transmit multimedia data in the CD channel of the L link.
  • TST test relating to signaling consists of extracting the user-agent field from the SIP messages exchanged between the TER IP terminal and the SRV test server.
  • the SRV test server can thus deduce the model of the TER terminal located at the end of the IP telephone communication link L.
  • the steps of the TST test can then concern the quality of the IP telephone communication link L with regard to the transmission of multimedia data.
  • data must be transmitted in the multimedia data transmission channel CD of the IP telephone communication link L.
  • This data must in particular be transmitted from the IP TER terminal to the SRV test server.
  • the IP TER terminal is the initiator of the opening of the link L following an action by a user, i.e. when the user has used the IP TER terminal to call the dedicated number of the SRV test server
  • the analogue audio signal recorded by the microphone of the TEL telephone or the TER IP terminal will be encoded into data packets using a given codec, then the packets will be sent to the SRV test server using the RTP protocol.
  • the SRV test server will then perform a test of the quality of the L link based on the data packets received.
  • the SRV test server must therefore have the means to interpret the data packets received according to the RTP protocol.
  • the steps of the TST test relating to the transmission of data in the CD channel will be based on the transmission of a certain number of data packets and consist of calculations carried out on the packets received. By nature, these steps of the TST test must therefore take a certain time in order to be carried out on a sufficient quantity of data packets received so that the results obtained are significant.
  • the duration necessary to carry out the steps of the TST test varies from a few seconds to a few tens of seconds. During this period, the IP telephone communication link L between the IP terminal TER and the SRV test server must not be interrupted.
  • the steps of the TST test relating to data transmission will for example consist of a calculation of the ratio between the number of packets received by the SRV test server and the number of packets transmitted by the TER IP terminal. Calculating the number of lost packets is also an interesting result of the TST test.
  • Jitter is the variation in latency over time.
  • a packet sent by the TER IP terminal will take some time to be transmitted to the SRV test server. This transmission delay is latency.
  • latency can decrease (packets take less time to be transmitted) or, on the contrary, increase.
  • Jitter measures this variation in latency, and is for example defined in document RFC 3393 of the IETF (acronym for Internet Engineering Task Force.
  • TST test relating to data transmission consists of carrying out the calculations defined in the G.107 standard which is part of the recommendations of the ITU-T, that is to say recommendations for the telecommunications sector of the International Telecommunications Union.
  • the performance of the TST test relating to data transmission by the SRV test server depends on the information obtained during the TST test relating to signaling. For example, the telecommunications operator who deploys the SRV test server may want to reserve its use only for its customers and will therefore use the result of a step of the TST test identifying the TER IP terminal which calls the SRV test server and will continue the TST test only if the TER IP terminal belongs to the operator's customers.
  • the TST test steps ultimately carried out may also depend on the subscription to which the IP TER terminal subscribes and will for example be more detailed for a business customer than for an individual.
  • the SRV test server will be able to modify the TST test carried out according to the codecs used by the IP terminal TER, which is revealed by a step of the initial TST test relating to signaling. Or again, the steps of the TST test carried out will be selected according to the model of the IP TER terminal.
  • the communication link L is kept open for the duration necessary for the completion of the TST test, independently of the reception by the IP terminal TER of a RAC instruction to close the link L.
  • a RAC instruction will in the most frequent case be a hang-up operation initiated by the user of the IP terminal, as shown in Figure 1.
  • the management entity 100 ensures that such RAC instructions are ignored by the IP terminal TER. In this way, the IP telephone communication link L is kept open and the execution of the TST test by the SRV test server can continue.
  • the management entity 100 When the management entity 100 belongs to the IP terminal TER, keeping the link L open even in the presence of RAC instructions received by the IP terminal TER is made easier. The management entity 100 will in fact be able to more easily intercept the RAC instructions received by the IP terminal TER by being included in the IP terminal TER.
  • the duration necessary for the completion of the TST test by the SRV test server is known in advance to the management entity 100 which implements the management method.
  • the SRV test server sends a message to the management entity 100 when all the steps of the TST test have been completed. In this way, the management entity 100 is informed that it no longer has to implement the management method and ensure that the link L remains open even in the presence of RAC instructions.
  • a RAC instruction to close the link L when a RAC instruction to close the link L is received by the IP terminal TER during the given duration, the execution of said RAC instruction is postponed for another given duration. In this way, the RAC instruction will ultimately be executed by the IP terminal TER but outside the period during which the IP telephone communication link L must be kept open for execution of the TST test.
  • the execution of said RAC instruction is canceled.
  • the management entity 100 ensures that the RAC instruction is not received by the IP terminal TER.
  • the request to open the IP telephone communication link L comes from an IP interface of the IP TER terminal.
  • a user of the IP TER terminal triggers a telephone call to a dedicated number of the SRV test server, which sends a request to open the communication link L between the IP TER terminal and the SRV test server.
  • the SRV test server is self-service and will perform a TST test of the link L when it is called by the IP TER terminal.
  • the management method according to the invention will then make it possible to ensure that the link L remains open and therefore that the SRV test server has the time necessary to perform the TST test even in the presence of RAC instructions to close the link L.
  • RAC instructions are typically hang-up operations on the part of the user.
  • the IP TER terminal issues the request to open the L link without user intervention. The opening of the L link and the performance of the TST test is then programmed and triggered by the IP TER terminal.
  • the request to open the link L comes from a TEL telephone separate from the TER IP terminal.
  • the TER IP terminal is not a telephone but for example a home gateway to which one or more telephones are connected in its local network. The user will then use the TEL telephone to call the dedicated number of the SRV test server; the request to open the L link therefore comes from the TEL telephone, distinct from the TER IP terminal.
  • the IP terminal TER transmits data packets in the multimedia data transmission channel CD independently of instructions received through an interface of the IP terminal. These modes can be useful when the IP TER terminal initiates the opening of the L link independently of a user action. Indeed, even in the absence of instructions received, such as sending signals from the microphones, the IP TER terminal will transmit data packets to ensure that the SRV test server can carry out the TST test of link quality IP telephone communication.
  • the management entity 100 which is responsible for carrying out the management process and therefore for intercepting the RAC instructions for closing the link will also ensure the transmission of these packets for the duration necessary for the TST test.
  • the management method comprises reception by the IP TER terminal, during the given duration, of a message from the SRV test server intended to be returned by the IP TER terminal.
  • This message will be for example a vocal message, produced by a speech synthesis component, or pre-recorded, which will be reproduced by the speaker of the IP TER terminal, when the IP TER terminal is a telephone, or sent by the TER IP terminal to a TEL telephone which will broadcast it on its loudspeaker.
  • the message may also include elements which can be displayed on a screen of the IP TER terminal or the TEL telephone.
  • the message may ask the user to press one or more keys on the TER IP terminal or the TEL telephone.
  • the SRV test server will be able to carry out steps of the TST test relating to the proper functioning of DTMF (acronym for Dual-Tone Mu/ti-Frequency) along the IP telephone communication link L.
  • the message may ask the user to say a particular phrase.
  • a speech recognition system present in the SRV test server will then allow it to carry out a TST test based on the quality of the received speech signal which can be compared to the requested message.
  • An advantage of sending a message by the SRV test server is to encourage the user who initiated the TST test by calling the dedicated number of the SRV test server to keep the link L open for the time necessary to carry out the TST test, in other words to encourage him not to hang up RAC.
  • all of the steps of the TST test can be carried out by the SRV test server even when it comes to testing the quality of the link L with a TER IP terminal which does not have the management entity 100. Even in the absence of a management entity 100 intercepting the RAC instructions for closing the link L, this embodiment will make it possible to avoid the production of such RAC instructions.
  • the message sent by the SRV test server keeps the user who called the SRV test server on the line for the necessary time.
  • the message transmitted during the duration of carrying out the steps of the TST test includes information relating to the TST test carried out by the SRV test server. This information can for example be indications of the start and end of carrying out the steps of the TST test as each of them is carried out. This information may also include the results of the TST test, including an overall indication of the quality of the IP telephone communication link L between the IP terminal TER and the test server SRV.
  • FIG. 2 presents the situation when the TER IP terminal is not an IP telephone.
  • the TER IP terminal is for example a domestic gateway and creates a local DECT network to which a TEL telephone is attached.
  • the IP telephone communication link L is then opened within an IP network between the IP terminal TER and the test server SRV.
  • the communication link L includes a CS channel dedicated to the transmission of signaling information and a CD channel dedicated to the transmission of multimedia data, including the voice signal between the IP terminal TER and the test server SRV.
  • an RAC instruction to close the link L can be received by the IP terminal TER in several situations, and in particular when the user of the TEL telephone performs a RAC hang-up action on the TEL telephone. Such a RAC action is transmitted via the DECT link to the TER IP terminal.
  • the presence of the management entity 100 implementing the management method ensures that the RAC closure instruction will not be implemented for the duration necessary to carry out the TST test.
  • FIG 3 presents the situation when the TER IP terminal is an IP telephone.
  • the TER IP terminal is a telephone capable of directly implementing the necessary IP telephony protocols.
  • the IP telephone communication link L is open between the IP terminal TER and the SRV test server, possibly through several IPI, IP2 networks connected by one or more routers.
  • the L link includes a CS channel dedicated to the transmission of signaling information and a CD channel dedicated to the transmission of multimedia data.
  • the management entity 100 present in the IP terminal TER ensures that the link L remains open even in the presence of an RAC instruction closing the link L, in this case a hang-up instruction by the user of the IP TER terminal.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Quality & Reliability (AREA)
  • Environmental & Geological Engineering (AREA)
  • Health & Medical Sciences (AREA)
  • Cardiology (AREA)
  • General Health & Medical Sciences (AREA)
  • Multimedia (AREA)
  • Monitoring And Testing Of Exchanges (AREA)
  • Telephone Function (AREA)

Abstract

L'invention se rapporte à un procédé de gestion d'un test (TST) de la qualité d'une liaison (L) de communication téléphonique entre un terminal (TER) et un serveur de test (SRV), la liaison (L) de communication téléphonique pouvant être ouverte ou fermée, le test (TST) étant réalisé lorsque la liaison (L) est ouverte, caractérisé en ce que, durant la réalisation du test (TST) de la qualité de la liaison (L), ladite liaison (L) est maintenue ouverte indépendamment de la réception d'une instruction (RAC) de fermeture de la liaison (L) par le terminal (TER) pendant une durée donnée au moins égale à la durée nécessaire à l'achèvement du test (TST) réalisé par le serveur de test (SRV).

Description

Description
Titre : Procédé de gestion d'un test de la qualité d'une liaison de communication téléphonique
Domaine technique
Le domaine technique est celui de la téléphonie fixe et en particulier de la téléphonie IP, c'est-à-dire des liaisons téléphoniques fixes se faisant grâce au protocole IP (acronyme de l'anglais Internet Protocol).
Plus précisément, l'invention se rapporte à un procédé de gestion d'un test de la qualité d'une liaison de communication téléphonique. Le plus souvent, le procédé selon l'invention sera un procédé de gestion d'un test de la qualité d'une liaison de communication téléphonique IP.
Les liaisons téléphoniques fixes se font dorénavant en général en utilisant des plates-formes de téléphonie utilisant le protocole IP pour transmettre le signal vocal entre postes téléphoniques. On parle alors de téléphonie sur IP, ou également de voix sur IP. Le terme de téléphonie VoIP (acronyme de l'anglais Voice over IP) est également utilisé. Les anciens protocoles de téléphonie fixe, tels que le RTC (acronyme de Réseau Téléphonique Commuté) ou le RNIS (acronyme de Réseau Numérique à Intégration de Services) sont en cours d'abandon.
En téléphonie, on appelle généralement terminal le téléphone qui est au point terminal de la liaison de communication téléphonique et qui va permettre aux utilisateurs de communiquer entre eux.
Les postes téléphoniques permettant de communiquer en téléphonie sur IP sont des équipements dédiés appelés téléphones IP. Ces téléphones IP peuvent établir des sessions de communication IP avec d'autres téléphones IP en requêtant des plates-formes de téléphonie sur IP. Une fois la session établie entre deux téléphones IP, un canal de communication est établi et la voix est transmise entre les deux téléphones IP par le protocole IP. Parfois, le téléphone fixe ne se connecte pas directement au réseau IP, mais est présent dans un réseau local et se connecte à une passerelle domestique qui va établir la communication téléphonique IP. On parle en général de terminal IP pour recouvrir les deux cas distincts d'un téléphone pouvant utiliser directement le protocole IP et d'une passerelle domestique qui sert de relais à un téléphone présent dans son réseau local. La liaison entre la passerelle domestique qui sert de terminal IP et le téléphone fixe se fait en général avec une liaison DECT (acronyme de l'anglais Digital Enhanced Cordless Telecommunications') .
L'établissement de la communication téléphonique IP se fait en général en utilisant le protocole SIP (acronyme de l'anglais Session Initiation Protocol) qui est un protocole généraliste permettant d'établir des sessions de communication. Des versions précédentes de téléphonie sur IP utilisaient le protocole ad hoc H.323. Les plates-formes de téléphonie sur IP servent également de passerelles pour permettre aux téléphones IP et aux terminaux IP d'accéder à des terminaux appartenant à d'autres réseaux de téléphonie, en particulier les réseaux de téléphonie fixe traditionnels ou bien les réseaux de téléphonie mobiles.
Etat de la technique
Un des besoins des opérateurs de services de téléphonie est de pouvoir tester la qualité des lignes téléphoniques, et en particulier la partie des lignes téléphoniques qui se trouve entre les domiciles des clients et les premiers équipements du réseau de téléphonie. En effet, ces parties des lignes téléphoniques se trouvant en partie sur des terrains privés ne sont pas facilement accessibles aux employés des services de téléphonie. L'inspection de ces parties de lignes nécessite une prise de rendez-vous. Un client qui constate une mauvaise qualité de sa liaison téléphonique va donc contacter son opérateur de téléphonie qui va planifier une intervention avec un technicien qui procédera aux tests de la liaison téléphonique et devra a priori se déplacer, ce qui entraîne un coût important ainsi que des délais avant de disposer du résultat des tests. Il existe donc un besoin de pouvoir tester à distance la qualité d'une telle ligne. Dans le cas des anciens réseaux de téléphonie fixe, tels que le RTC, il existe une technique bien connue de test à distance des lignes téléphoniques. Cette technique de test à distance s'appuie sur les propriétés de propagation des ondes électriques dans un support en cuivre, qui est le support le plus largement utilisé dans le réseau RTC. En exploitant notamment le phénomène d'écho bien connu des ondes électriques dans ce type de support, il est ainsi possible pour un opérateur téléphonique de tester à distance une ligne téléphonique du réseau RTC. Lorsqu'un client se plaint de la qualité de sa ligne téléphonique, un technicien de l'opérateur va pouvoir effectuer un test à distance pour mesurer cette qualité et détecter d'éventuels problèmes.
Pour les services de téléphonie IP, de telles propriétés physiques de la ligne téléphonique ne peuvent pas être exploitées pour réaliser un test à distance. Cependant, le brevet français publié sous le numéro 3 063 407 le 31 août 2018 et délivré le 10 septembre 2021 présente un procédé de test à distance d'une telle liaison de communication et un serveur de test associé. Le serveur de test, présent dans le réseau de téléphonie IP émet une requête vers un terminal IP dont la liaison de communication doit être testée. Le serveur de test émet, après établissement de la communication, des paquets de données vers le terminal ce qui lui permet ensuite de calculer des résultats de test et de donner une indication quant à la qualité de la liaison de communication de téléphonie IP. La réalisation du test par le serveur implique que le terminal IP doit accepter l'établissement de la liaison, ce qui implique l'insertion par le serveur de test d'un paramètre spécifique dans la requête émise par le serveur à destination du terminal IP. Le calcul de test peut utiliser la norme G.107 qui fait partie des recommandations de l'UIT-T, c'est-à-dire des recommandations pour le secteur des télécommunications de l'Union Internationale des Télécommunications.
Cependant, un tel test étant déclenché par un serveur de test dans le réseau, le procédé décrit ci-dessus implique qu'un client doive contacter le service après- vente de son opérateur téléphonique pour déclencher un test quand il constate un dysfonctionnement de sa ligne. Si le procédé introduit une possibilité de test à distance, il ne permet pas à un client de diagnostiquer l'état de sa ligne de téléphonie IP sans intervention du service après-vente de son opérateur téléphonique. Une telle intervention implique un délai avant d'obtenir une réponse quant à l'état de sa ligne pour le client du service de téléphonie IP et un coût important pour l'opérateur de service de téléphonie IP afin de répondre aux demandes de ses clients. Cet inconvénient dû à la réalisation d'un test à l'initiative d'un serveur présent dans le réseau existe également en téléphonie classique.
D'autre part, la réalisation du test suivant la norme G.107 implique que le serveur de test doit disposer d'un certain temps avec la liaison ouverte vers le terminal pour effectuer des tests de qualité. Or, un utilisateur interagissant avec le terminal IP pourrait couper la liaison ouverte avec le serveur avant que le test soit terminé, par exemple en raccrochant un téléphone IP ou un téléphone DECT en lien avec la passerelle domestique qui sert de terminal IP. Cet inconvénient dû au temps pris pour réaliser un test existe également en téléphonie classique. Dans ce cas, si l'utilisateur raccroche le terminal, il peut couper la liaison ouverte avec le serveur avant que le test soit terminé.
L'invention vient améliorer la situation.
Exposé de l'invention
Selon un premier aspect fonctionnel, l'invention a trait à un procédé de gestion d'un test de la qualité d'une liaison de communication téléphonique entre un terminal et un serveur de test, la liaison de communication téléphonique pouvant être ouverte ou fermée, le test étant réalisé par le serveur de test lorsque la liaison est ouverte, caractérisé en ce que l'ouverture de la liaison de communication téléphonique est précédée d'une demande d'ouverture de la liaison issue du terminal et en ce que, durant la réalisation du test de la qualité de la liaison, ladite liaison est maintenue ouverte indépendamment de la réception d'une instruction de fermeture de la liaison par le terminal pendant une durée donnée.
Grâce à l'invention, le procédé de gestion de test assure que le test est réalisé complètement par le serveur de test. Un test ici est une session complète d'interaction entre le serveur et le terminal, qui comprend plusieurs étapes, et qui permet d'obtenir tout un ensemble d'informations quant à la qualité de la liaison de communication téléphonique. La réalisation complète d'un tel test s'étale donc sur une certaine durée. La complétion du test nécessite que le serveur réalise des calculs pendant un certain temps. Le maintien de la liaison de communication ouverte pendant une durée donnée permet d'assurer que le test est bien réalisé par le serveur de test. La durée donnée est au moins égale à la durée nécessaire à l'achèvement du test.
Cet avantage est particulièrement important à mettre en œuvre quand le test est réalisé à l'initiative du terminal. En effet, le test peut être réalisé alors en effectuant un appel vers un numéro dédié opéré par le serveur de test. Il est donc important dans ce cas de s'assurer que le terminal ne raccroche pas avant la complétion des tests. L'invention permet de s'assurer que, même si un utilisateur raccroche avant que les tests soient complets, le terminal maintiendra la liaison ouverte pour s'assurer de la complétion des étapes de test.
Comme l'ouverture de la liaison est précédée d'une demande d'ouverture de la liaison issue du terminal, il est possible de réaliser des tests de qualité de la liaison de communication à l'initiative des clients du service de téléphonie. Le serveur de test peut disposer d'un numéro de téléphone dédié qui sera appelé par un terminal à l'initiative d'un utilisateur, qui composera simplement le numéro. Cette action déclenchera l'ouverture de la liaison de communication entre le terminal et le serveur de test à la suite d'une demande émise par le terminal. L'ouverture de la liaison permettra au serveur de démarrer le test. L'avantage de ce mode est que le test est réalisé à l'initiative des clients, ce qui évite aux clients d'avoir à contacter le service après-vente de l'opérateur du service de téléphonie. Le test se réalise à distance et à l'initiative des clients, ce qui diminue au maximum le besoin de faire intervenir le service après-vente de l'opérateur téléphonique.
Selon un premier mode de mise en œuvre particulier de l'invention, si une instruction de fermeture de la liaison est reçue pendant la durée donnée, l'exécution de ladite instruction est repoussée d'une autre durée donnée.
Grâce à ce mode de mise en œuvre, l'instruction de fermeture de la liaison est repoussée pendant une durée donnée mais sera bien exécutée ultérieurement. Quand l'instruction de fermeture est une opération de raccrocher effectuée par un utilisateur du terminal, l'avantage de ce mode est que le test sera bien complété, mais l'instruction sera également bien effectuée, même si c'est de façon retardée. Pour peu que le délai nécessaire soit restreint, il est possible que l'utilisateur ne remarque pas le décalage d'exécution de l'instruction de fermeture.
Dans un autre mode possible de mise en œuvre de l'invention, l'exécution de l'instruction est annulée. Ce mode a l'avantage de simplifier le traitement des instructions de fermeture reçues par le terminal.
Selon un deuxième mode de mise en œuvre particulier de l'invention, qui pourra être mis en œuvre alternativement ou cumulativement avec le précédent mode, la liaison est une liaison de communication téléphonique IP ouverte entre le terminal et le serveur de test, ladite liaison comprenant un canal de signalisation permettant au serveur de test d'obtenir des informations relatives à la signalisation et la réalisation, par le serveur de test, du test de la qualité de la liaison dépend des informations obtenues relatives à la signalisation.
Une liaison de communication téléphonique IP comprend en général deux canaux, un canal permettant d'échanger les informations relatives à la signalisation, et donc à l'établissement de la communication, et un canal de transmission de données multimédia qui permet en particulier d'échanger le signal vocal entre les deux postes IP. C'est ce canal qui permet aux utilisateurs de se parler, leur parole étant transformée en paquets de données IP, et échangée dans les deux sens dans le canal de transmission de données présent dans la liaison de communication téléphonique ouverte. Grâce à ce mode de mise en œuvre, les étapes de test effectuées sont réparties en deux catégories : d'une part, des tests relatifs à la signalisation, et d'autre part des tests relatifs à la transmission des paquets de donnée. Comme le signal de parole est transmis par des paquets de données, le test de la qualité d'une liaison de communication téléphonique IP repose principalement sur les tests relatifs à la transmission de données. Cependant, les tests de signalisation sont également utiles. Un des avantages de ce mode est de pouvoir réaliser un test de qualité en dépendance des informations de signalisation obtenues. Par exemple, les informations de signalisation permettent de connaître le terminal IP à l'initiative du test. Le serveur de test peut alors différencier les tests suivant le terminal à l'origine de l'ouverture de la liaison qui sert au test. Un opérateur de télécommunications pourra par exemple refuser d'exécuter des tests issus de terminaux qui ne font pas partie de ses clients. Ou bien, un opérateur pourra effectuer des tests plus ou moins détaillés selon l'abonnement du client possédant le terminal à l'origine du test.
Selon un troisième mode de mise en œuvre particulier de l'invention, qui pourra être mis en œuvre alternativement ou cumulativement avec les modes précédents, l'ouverture de la liaison est précédée d'une demande d'ouverture de la liaison issue du terminal.
Grâce à ce mode de mise en œuvre de l'invention, il est possible de réaliser des tests de qualité de la liaison de communication à l'initiative des clients du service de téléphonie. Le serveur de test peut disposer d'un numéro de téléphone dédié qui sera appelé par un terminal à l'initiative d'un utilisateur, qui composera simplement le numéro. Cette action déclenchera l'ouverture de la liaison de communication entre le terminal et le serveur de test à la suite d'une demande émise par le terminal. L'ouverture de la liaison permettra au serveur de démarrer le test. L'avantage de ce mode est que le test est réalisé à l'initiative des clients, ce qui évite aux clients d'avoir à contacter le service après-vente de l'opérateur du service de téléphonie. Le test se réalise à distance et à l'initiative des clients, ce qui diminue au maximum le besoin de faire intervenir le service après-vente de l'opérateur téléphonique.
Ce mode peut être mis en œuvre quand des utilisateurs du terminal appellent un numéro dédié opéré par le serveur de test ; dans ce cas, le terminal est à l'origine de l'ouverture de la liaison de communication, ce qui déclenche l'exécution du test par le serveur.
Dans une variante, l'ouverture de la liaison de communication téléphonique se fait par le terminal sans intervention d'un utilisateur. Le terminal est programmé pour réaliser des ouvertures de la liaison vers le serveur de test sans intervention humaine. L'avantage de ce mode est de pouvoir réaliser des tests en préventif, et donc d'anticiper des problèmes éventuels en détectant des dégradations de la qualité de la liaison qui n'auraient pas forcément été détectées par un utilisateur. Dans cette variante, si la liaison est une liaison de communication téléphonique IP, le terminal IP peut être aussi bien un téléphone IP qu'une passerelle domestique.
Selon un quatrième mode de mise en œuvre particulier de l'invention, qui pourra être mis en œuvre alternativement ou cumulativement avec l'un des modes précédents, la liaison est une liaison de communication téléphonique IP et l'ouverture de la liaison est précédée d'une demande d'ouverture issue d'un téléphone distinct du terminal.
Grâce à ce mode de réalisation, l'invention s'adapte au cas, présent en téléphonie IP, où le terminal IP est une passerelle domestique à laquelle des terminaux tels que des téléphones DECT sont rattachés. Dans ce cas, l'utilisateur du téléphone DECT, distinct du terminal IP, va appeler un numéro dédié au serveur de test, et donc créer une demande d'ouverture de la liaison de communication téléphonique. Cette demande sera ensuite issue du terminal IP (la passerelle domestique) vers le serveur IP de test. Le téléphone DECT, qui ne dispose pas d'interface IP, est quand même à l'origine de la demande d'ouverture de la liaison de communication téléphonique.
Selon un cinquième mode de mise en œuvre particulier de l'invention, qui pourra être mis en œuvre cumulativement avec l'un des deux modes précédents, la liaison de communication étant une liaison de communication téléphonique IP ouverte entre le terminal et le serveur de test, ladite liaison comprend un canal de transmission de données multimédia et le terminal émet des paquets de données dans ledit canal de transmission de données indépendamment d'instructions reçues au travers d'une interface du terminal.
Dans le cas de la téléphonie IP, pour qu'un test de la qualité de la liaison de communication téléphonique IP prenne place, il est nécessaire que des paquets de données soient échangés sur le canal ouvert de transmission de données multimédia. Les calculs nécessaires à la réalisation du test s'appliquent en effet sur l'ensemble des paquets transmis à travers la liaison de communication pendant la durée du test. Or, si le terminal IP est à l'origine de l'ouverture de la liaison, y compris sans intervention d'un utilisateur, il est nécessaire que le terminal IP émette des paquets de données dans le canal de transmission de données et ce même sans action de l'utilisateur aux interfaces du terminal ou, plus clairement, sans que l'utilisateur ne parle dans le téléphone. Ce mode de réalisation permet donc de s'assurer que le test va se dérouler dans de bonnes conditions même en l'absence de l'intervention d'un utilisateur.
Selon un sixième mode de mise en œuvre particulier de l'invention, qui pourra être mis en œuvre alternativement ou cumulativement avec les modes précédents, le procédé de gestion comprend la réception par le terminal, pendant la durée donnée, d'un message issu du serveur de test destiné à être restitué par le terminal.
Grâce à ce mode de réalisation, le serveur émet un message qui peut être par exemple un message vocal. Ce message sera restitué par le terminal, par exemple directement sur le haut-parleur du téléphone si le terminal est lui-même un téléphone ou bien, dans le cas d'une liaison de téléphonie IP où le terminal IP est une passerelle domestique, le message sera restitué par le terminal IP vers un téléphone DECT qui restituera ensuite le message vocal sur son propre haut- parleur. La restitution peut également prendre la forme d'une restitution sur un écran. L'avantage de ce mode de réalisation est de restituer un message pendant toute la durée de réalisation du test et donc d'inciter l'utilisateur à rester en ligne ce qui permet d'éviter une action de raccrocher de sa part.
Selon un septième mode de mise en œuvre particulier de l'invention, qui pourra être mis en œuvre cumulativement avec le mode précédent, le message reçu par le terminal comprend des informations relatives au test réalisé par le serveur de test.
Grâce à ce mode de réalisation, qui complète le mode précédent, le message reçu par le terminal comprend des éléments d'information sur les résultats des différentes étapes du test effectué par le serveur de test. L'avantage de ce mode est de fournir immédiatement des informations à l'utilisateur qui a procédé à l'appel d'un numéro dédié au serveur de test et qui a donc déclenché le test de qualité de sa liaison de communication. Là encore, un avantage est de limiter le recours au service après-vente de la part des utilisateurs puisqu'ils disposent d'un service de test en libre-service, qui va réaliser les étapes du test et leur fournir les résultats par l'intermédiaire du message émis par le serveur de test et restitué par le terminal.
Selon un premier aspect matériel, l'invention a trait à une entité de gestion d'un test de la qualité d'une liaison de communication téléphonique entre un terminal et un serveur de test, la liaison de communication téléphonique pouvant être ouverte ou fermée, le test étant réalisé par le serveur de test lorsque la liaison est ouverte, caractérisée en ce que l'ouverture de la liaison de communication téléphonique est précédée d'une demande d'ouverture de la liaison issue du terminal et en ce que ladite entité de gestion comprend un processeur configuré pour assurer que, durant la réalisation du test de la qualité de la liaison, ladite liaison est maintenue ouverte par ladite entité de gestion, indépendamment de la réception d'une instruction de fermeture de la liaison par le terminal, pendant une durée donnée.
Selon un autre aspect matériel, l'invention a trait à un terminal comprenant une entité de gestion selon l'aspect précédent.
Grâce à cet aspect matériel, il est possible de disposer de terminaux qui vont collaborer avec un serveur de test afin de s'assurer que, une fois qu'un test de qualité de la liaison de communication téléphonique est démarré, celui-ci ne sera pas interrompu, y compris en présence d'actions de l'utilisateur du terminal, comme une action de raccrochage. L'invention permet donc de disposer d'un système de test de la qualité d'une liaison de communication téléphonique accessible en libre-service pour un utilisateur et qui reste robuste face aux actions de l'utilisateur. En général, un tel terminal est un téléphone. Comme déjà expliqué, dans le cas de la téléphonie IP, un tel terminal IP peut être, entre autres, un téléphone IP ou une passerelle domestique. Il peut également s'agir d'un ordinateur, fixe ou portable, disposant de la capacité de réaliser des communications en téléphonie IP et attaché à un réseau téléphonique IP.
Selon un autre aspect matériel, l'invention a trait à un programme d'ordinateur apte à être mis en œuvre par un terminal selon l'aspect précédent, le programme comprenant des instructions de code qui, lorsqu'il est exécuté par un processeur, réalise le procédé de gestion selon l'invention.
Les programmes d'ordinateur en question peuvent être rédigés dans tout langage de programmation. Ils peuvent être par exemple des langages compilés, ou bien interprétés, ou bien utiliser un mode de fonctionnement mixte utilisant une compilation vers un code à octet (de l'anglais bytecodé) qui sera ensuite interprété par une machine virtuelle. Les programmes peuvent s'exécuter sur des architectures matérielles, ou bien dans des machines virtuelles, ou bien dans des technologies proches comme des systèmes de conteneurs.
Selon un autre aspect matériel, l'invention a trait à un support de données sur lequel est enregistré un programme d'ordinateur selon l'aspect précédent.
Les supports de données peuvent ê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 tel qu'un un disque dur. D'autre part, les supports peuvent être des supports transmissibles tels qu'un signal électrique ou optique, qui peuvent être acheminés via un câble électrique ou optique, par radio ou par d'autres moyens. Les programmes selon l'invention peuvent être en particulier téléchargés sur un réseau de type Internet. Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.
Brève description des figures
L'invention sera mieux comprise à la lecture de la description qui suit, donnée à titre d'exemple, et faite en référence aux dessins annexées sur lesquels :
[Fig 1] représente un exemple d'étapes mises en œuvre dans le cadre d'un mode de réalisation de l'invention.
[Fig 2] représente un exemple de mise en œuvre de l'invention par un terminal IP et un serveur de test, le terminal IP étant une passerelle domestique distincte d'un téléphone.
[Fig 3] représente un exemple de mise en œuvre de l'invention par un téléphone IP et un serveur de test.
Description détaillée
La figure 1 représente un exemple d'étapes mises en œuvre dans le cadre d'un mode de réalisation de l'invention.
Les deux lignes verticales représentent l'évolution d'une part d'un terminal TER et d'autre part d'un serveur de test SRV lors de la mise en œuvre d'un procédé de gestion selon l'invention. De manière classique, l'évolution du temps est représentée par le passage du haut vers le bas le long des deux lignes verticales.
Dans notre exemple de description détaillée, on se place dans le cadre de la téléphonie IP. Le test est un test de qualité d'une liaison de communication téléphonique IP, et le terminal TER est un terminal IP TER.
Dans le mode de réalisation présenté ici, le terminal IP TER comprend une entité de gestion 100 selon l'invention, qui met en œuvre le procédé de gestion de test. Dans d'autres modes, l'entité de gestion 100 peut appartenir au serveur de test SRV ou bien appartenir à des plates-formes de service, non représentées sur les figures, qui mettent en œuvre le réseau de téléphonie IP entre le terminal IP TER et le serveur de test SRV. Cependant, le mode de réalisation dans lequel l'entité de gestion 100 est comprise dans le terminal IP TER est le mode préféré car l'entité de gestion 100 est chargée d'annuler l'effet d'actions à destination du terminal IP TER et une situation de l'entité de gestion 100 dans le terminal IP TER est la plus adaptée pour cela.
L'entité de gestion 100 comprend un processeur et éventuellement une ou plusieurs mémoires (non représentés sur les figures) qui lui permettent d'exécuter des programmes. La présence de processeurs et de mémoires dans les terminaux téléphoniques, ou dans les passerelles domestiques qui servent de terminaux IP TER est classique de nos jours. Le processeur de l'entité de gestion 100 devra avoir accès aux interfaces réseau du terminal IP TER afin de pouvoir intercepter les instructions de fermeture de la liaison L durant l'exécution du test. Le programme du processeur devra également pouvoir détecter que la liaison L doit rester ouverte. Une manière de procéder peut être d'associer des numéros de téléphone dédiés aux tests de qualité, numéros qui seront mémorisés dans une mémoire de l'entité de gestion 100. Le programme mettant en œuvre le procédé selon l'invention ayant accès aux interfaces réseau du terminal IP TER détectera alors un appel vers un de ces numéros dédiés aux tests de qualité et commencera alors à exécuter le procédé. Une autre manière de procéder peut être, pour le serveur de test SRV, d'envoyer, au début d'un test de qualité de la liaison L, un message spécifique à destination de l'entité de gestion 100 lui demandant de mettre en œuvre le procédé selon l'invention et de maintenir ouverte la liaison L pendant une durée au moins égale à la durée nécessaire à l'exécution du test TST.
Le terminal IP TER peut prendre plusieurs formes.
Le terminal IP TER peut par exemple être une passerelle domestique qui offre l'accès au réseau Internet dans un domicile ou un petit local professionnel. Une telle passerelle domestique créera un réseau local et disposera de la possibilité de connecter un téléphone TEL à son réseau local par exemple en utilisant le protocole DECT. D'autre part, la passerelle domestique sera connectée à un réseau de téléphonie IP en tant que terminal IP TER et pourra établir des liaisons de communication téléphonique IP au bénéfice du téléphone TEL. Cette situation est représentée en figure 2, qu'on détaillera ultérieurement. Le terminal IP TER peut également être un téléphone capable de se rattacher directement au réseau de téléphonie IP. Cette situation est représentée en figure 3, qu'on détaillera ultérieurement.
Le terminal IP TER peut également être un ordinateur, fixe ou portable, disposant de la capacité de réaliser des communications en téléphonie IP et attaché à un réseau téléphonique IP.
Le serveur de test SRV, quant à lui, présente en général l'architecture matérielle d'un ordinateur conventionnel et comporte notamment un processeur, une mémoire vive de type RAM (pour l'anglais Read Access Memory) et une mémoire morte telle qu'une mémoire de type Flash, ROM (pour l'anglais Read Only Memory), ou autres, non représentés sur la figure, ainsi que des dispositifs d'entrée-sortie tels que claviers et/ou écrans (non représentés sur la figure). L'entité de gestion peut être un serveur matériel ou bien être déployée sur une architecture informatique en nuage (de l'anglais doud computing). L'entité de gestion dispose de liaisons de communication (non représentées sur la figure 1) qui lui permettent de communiquer avec d'autres entités pour échanger des données ou des instructions.
Le serveur de test SRV doit être capable d'être connecté à des liaisons de communication téléphonique IP afin de réaliser des tests de qualité d'une telle liaison. Le serveur de test SRV doit donc être relié par une liaison de communication non représentée au réseau de téléphonie IP et doit pouvoir interagir avec celui-ci, par exemple en disposant d'un ou plusieurs numéros de téléphone dédiés sur le réseau de téléphone IP et en étant capable de passer des instructions relatives à l'établissement des liaisons de communication téléphonique IP. Le serveur de test SRV dispose donc de possibilités de communication suivant les protocoles SIP ou H.323 ou d'autres selon les protocoles de téléphonie IP présents dans le réseau de téléphonie IP pour lequel le serveur de test SRV va réaliser des tests.
Le procédé est mis en œuvre alors qu'une liaison L de communication téléphonique IP est ouverte entre le terminal IP TER et le serveur de test SRV. Une telle liaison L peut être ouverte à la suite de plusieurs événements. Dans un mode de réalisation le plus simple, un numéro de téléphone est dédié au serveur de test SRV et un utilisateur du terminal IP TER va composer ce numéro afin d'ouvrir la liaison L de communication téléphonique IP. Dans un autre mode de réalisation, le terminal IP TER va être capable d'initier l'ouverture de la liaison L sans initiative d'un utilisateur. Dans ce mode, le terminal IP TER dispose de capacités de programmation qui lui permettent de déclencher un appel téléphonique IP et donc l'ouverture d'une liaison L de communication téléphonique IP avec le serveur SRV, soit à des moments planifiés, soit en réponse à des instructions ne provenant pas d'un utilisateur mais d'autres machines. Le mode de réalisation dans lequel le terminal IP TER déclenche des appels vers le serveur de test SRV de façon planifiée permet de mettre en œuvre une maintenance préventive de la qualité de la liaison L de communication téléphonique IP, en réalisant des tests à intervalles réguliers. Dans un autre mode de réalisation, c'est le serveur de test SRV qui va déclencher un appel vers le terminal IP TER ce qui va ouvrir la liaison L de communication téléphonique IP.
La liaison L de communication téléphonique IP comprend dans plusieurs modes de réalisation un canal de signalisation CS et un canal CD de transmission de données multimédia. Le canal de signalisation CS est utilisé pour transférer les informations et les instructions ayant trait à la signalisation téléphonique et par exemple à l'établissement des communications téléphoniques IP, au transfert de ces communications, à la fermeture des communications ou à toute autre opération de signalisation. Le canal CD de transmission de données multimédia sert quant à lui à transmettre des données multimédia sous forme de paquets de données. En particulier, le signal vocal entre les deux extrémités de la liaison L de communication téléphonique IP est transmis dans les deux sens sous forme de paquets de données encodant le signal vocal émis aux deux extrémités de la liaison L. Le protocole d'échange de tels paquets de données multimédia est le protocole RTP (acronyme de l'anglais Real-time Transport Protocol). Ses notions sont bien connues par l'homme du métier dans le domaine de la téléphonie IP et ne sont pas davantage détaillées. Une fois la liaison L de communication téléphonique IP ouverte entre le terminal IP TER et le serveur de test SRV, ce dernier va procéder à un test TST de la qualité de la liaison L. Un tel test TST est une succession d'étapes qui va permettre d'obtenir tout un ensemble de résultats qualifiant la qualité de la liaison L avec le terminal IP TER.
L'exécution de l'ensemble du test TST par le serveur de test SRV prend un temps significatif avant que ne soit obtenu les résultats des étapes du test TST réalisé par le serveur de test SRV. Ce temps occupe une période représentée dans la figure 1 par un trait plus épais disposé sur la ligne représentant les actions du serveur de test SRV et du terminal IP TER. Certaines des étapes du test TST vont être exécutées de façon quasi -instante née par le serveur de test SRV ce qui est représenté dans la figure 1 par une flèche en boucle, arrivant un peu en-dessous de leur point de départ représentant que la fin de cette étape du test TST a lieu très peu de temps après son début. D'autres étapes du test TST vont au contraire prendre un temps significatif à être exécutées, ce qui est représenté par une flèche dont le point d'arrivée est significativement plus tardif que le point de départ. Ces différentes étapes du test TST sont dans tous les cas étiquetées TST dans la figure 1, la différenciation des différentes étapes du test TST n'ayant pas d'influence sur la réalisation du procédé de gestion selon l'invention. Dans tous les cas, c'est l'exécution de l'ensemble des étapes du test TST par le serveur de test SRV qui prend un temps significatif.
Les étapes du test TST peuvent être de plusieurs natures.
Le test TST peut d'abord concerner la signalisation téléphonique IP. Dans ce cas, le serveur récupère des données transmises à travers le canal CS de la liaison L de communication téléphonique IP établie entre le terminal IP TER et le serveur SRV. Pour réaliser un test TST relatif à la signalisation, le serveur SRV doit disposer des moyens d'interpréter les messages de signalisation qui vont en général utiliser le protocole SIP et éventuellement des protocoles dédiés à la téléphonie IP tel que H.323. Le serveur de test TST obtiendra ainsi un ensemble d'informations relatives à la signalisation, transmises par le canal de signalisation CS. Par exemple, dans le cas où la liaison L est ouverte à l'initiative du terminal IP TER en utilisant le protocole SIP, le serveur de test SRV pourra accéder au champ P- Asserted -Identity \s message SIP-Invite. Ce champ permet au serveur de test SRV d'obtenir des informations sur le terminal IP TER et en particulier son numéro de téléphone et la plate-forme de téléphonie utilisée par le terminal IP TER pour placer son appel. Le serveur de test SRV peut ainsi déduire depuis quel réseau de téléphonie le terminal IP TER a placé son appel, ainsi que l'opérateur du service de téléphonie utilisé par le terminal IP TER et possiblement d'autres informations commerciales.
Un autre exemple de test TST relatif à la signalisation consiste à accéder au champ SDP (acronyme de l'anglais Session Description Protocol) présent dans le message SIP-Invite envoyé par un terminal IP TER. Ce champ permet au serveur de test SRV de connaître les capacités du réseau utilisé pour établir la liaison L de communication téléphonique IP entre le serveur de test SRV et le terminal IP TER. Le serveur de test TST peut ainsi déduire les codecs (programmes ou matériels utilisés pour encoder des signaux audios ou vidéos, acronyme de codeurs- décodeurs) qui sont utilisés par le terminal IP TER ou imposés par le réseau sous- jacent pour transmettre des données multimédia dans le canal CD de la liaison L.
Un autre exemple de test TST relatif à la signalisation consiste à extraire le champ user-agent des messages SIP échangés entre le terminal IP TER et le serveur de test SRV. Le serveur de test SRV peut ainsi en déduire le modèle du terminal TER situé à l'extrémité de la liaison L de communication téléphonique IP.
Les étapes du test TST peuvent ensuite concerner la qualité de la liaison L de communication téléphonique IP en ce qui concerne la transmission de données multimédia. Pour établir ces étapes du test TST, des données doivent être émises dans le canal CD de transmission de données multimédia de la liaison L de communication téléphonique IP. Ces données doivent en particulier être émises depuis le terminal IP TER vers le serveur de test SRV. Dans le cas où le terminal IP TER est à l'initiative de l'ouverture de la liaison L à la suite d'une action d'un utilisateur, c'est-à-dire quand l'utilisateur a utilisé le terminal IP TER pour appeler le numéro dédié du serveur de test SRV, le signal audio analogique enregistré par le microphone du téléphone TEL ou du terminal IP TER va être encodé en paquet de données grâce à un codec donné, puis les paquets vont être expédiés vers le serveur de test SRV grâce au protocole RTP. Le serveur de test SRV va ensuite effectuer un test de la qualité de la liaison L en s'appuyant sur les paquets de donnée reçus. Le serveur de test SRV doit donc disposer des moyens d'interpréter les paquets de données reçus selon le protocole RTP.
Les étapes du test TST relatives à la transmission de données dans le canal CD vont s'appuyer sur la transmission d'un certain nombre de paquets de données et consister en calculs réalisés sur les paquets reçus. Par nature, ces étapes du test TST doivent donc prendre un certain temps afin d'être réalisées sur une quantité de paquets de données reçus suffisante afin que les résultats obtenus soient significatifs. De façon indicative, la durée nécessaire à la réalisation des étapes du test TST varie de quelques secondes à quelques dizaines de secondes. Pendant cette durée, la liaison L de communication téléphonique IP entre le terminal IP TER et le serveur de test SRV ne doit pas être interrompue.
Les étapes du test TST relatives à la transmission des données vont par exemple consister en un calcul du rapport entre le nombre de paquets reçus par le serveur de test SRV et le nombre de paquets émis par le terminal IP TER. Le calcul du nombre de paquets perdus est également un résultat intéressant du test TST.
Un autre exemple de test TST relatif à la transmission des données dans le canal CD consiste à calculer la gigue. La gigue est la variation de la latence au fil du temps. Un paquet émis par le terminal IP TER mettra un certain temps à être transmis au serveur de test SRV. Ce délai de transmission est la latence. Au fur et à mesure de la transmission, la latence peut diminuer (les paquets mettent moins de temps à être transmis) ou au contraire augmenter. La gigue mesure cette variation de la latence, et est par exemple définie dans le document RFC 3393 de l'IETF (acronyme de l'anglais Internet Engineering Task Force . Plusieurs méthodes de calcul de la gigue peuvent être appliquées et donner différents résultats de test TST et ne sont pas détaillées plus avant.
Un autre exemple de test TST relatif à la transmission des données consiste à réaliser les calculs définis dans la norme G.107 qui fait partie des recommandations de l'UIT-T, c'est-à-dire des recommandations pour le secteur des télécommunications de l'Union Internationale des Télécommunications.
Dans certains modes de réalisation, la réalisation du test TST relatif à la transmission de données par le serveur de test SRV dépend des informations obtenues pendant le test TST relatives à la signalisation. Par exemple, l'opérateur de télécommunications qui déploie le serveur de test SRV peut vouloir réserver son utilisation uniquement à ses clients et va donc utiliser le résultat d'une étape du test TST identifiant le terminal IP TER qui appelle le serveur de test SRV et continuera le test TST uniquement si le terminal IP TER appartient bien aux clients de l'opérateur. Les étapes du test TST réalisées finalement peuvent également dépendre de l'abonnement auquel le terminal IP TER souscrit et seront par exemple plus détaillées pour un client entreprise que pour un particulier. Ou bien, le serveur de test SRV va pouvoir modifier le test TST réalisé en fonction des codecs utilisés par le terminal IP TER, ce qui est révélé par une étape du test TST initial relative à la signalisation. Ou bien encore, les étapes du test TST réalisé seront sélectionnées en fonction du modèle du terminal IP TER.
Dans l'ensemble des modes de réalisation du procédé de gestion selon l'invention, la liaison L de communication est maintenue ouverte pendant la durée nécessaire à l'achèvement du test TST et ce indépendamment de la réception par le terminal IP TER d'une instruction RAC de fermeture de la liaison L. Une telle instruction RAC sera dans le cas le plus fréquent une opération de raccrochage initiée par l'utilisateur du terminal IP, comme représenté dans la figure 1. Pendant toute la durée de l'exécution des étapes du test TST, l'entité de gestion 100 fait en sorte que de telles instructions RAC sont ignorées par le terminal IP TER. De cette manière, la liaison L de communication téléphonique IP est maintenue ouverte et l'exécution du test TST par le serveur de test SRV peut se poursuivre. Lorsque l'entité de gestion 100 appartient au terminal IP TER, le maintien de la liaison L ouverte même en présence d'instructions RAC reçues par le terminal IP TER est rendu plus facile. L'entité de gestion 100 pourra en effet plus facilement intercepter les instructions RAC reçues par le terminal IP TER en étant incluse dans le terminal IP TER. Dans certains modes de réalisation, la durée nécessaire à l'achèvement du test TST par le serveur de test SRV est connue à l'avance de l'entité de gestion 100 qui met en œuvre le procédé de gestion. Dans d'autres modes de réalisation, le serveur de test SRV émet un message à destination de l'entité de gestion 100 lorsque l'ensemble des étapes du test TST ont été réalisées. De cette manière, l'entité de gestion 100 est informée qu'elle n'a plus à mettre en œuvre le procédé de gestion et à assurer que la liaison L reste ouverte même en présence d'instructions RAC.
Dans certains modes de réalisation de l'invention, lorsqu'une instruction RAC de fermeture de la liaison L est reçue par le terminal IP TER pendant la durée donnée, l'exécution de ladite instruction RAC est repoussée d'une autre durée donnée. De cette manière, l'instruction RAC sera bien exécutée finalement par le terminal IP TER mais en dehors de la période pendant laquelle la liaison L de communication téléphonique IP doit être maintenue ouverte pour l'exécution du test TST.
Dans d'autres modes de réalisation de l'invention, lorsqu'une instruction RAC de fermeture de la liaison L est reçue par le terminal IP TER pendant la durée donnée, l'exécution de ladite instruction RAC est annulée. L'entité de gestion 100 fait en sorte que l'instruction RAC ne soit pas reçue par le terminal IP TER.
Dans certains modes de réalisation, la demande d'ouverture de la liaison L de communication téléphonique IP est issue d'une interface IP du terminal IP TER. Par exemple, dans un mode simple, un utilisateur du terminal IP TER déclenche un appel téléphonique vers un numéro dédié du serveur de test SRV ce qui envoie une demande d'ouverture de la liaison L de communication entre le terminal IP TER et le serveur de test SRV. Dans ce mode, le serveur de test SRV est en libre- service et va effectuer un test TST de la liaison L quand il est appelé par le terminal IP TER. Le procédé de gestion selon l'invention va alors permettre de s'assurer que la liaison L reste ouverte et donc que le serveur de test SRV dispose du temps nécessaire pour réaliser le test TST même en présence d'instructions RAC de fermeture de la liaison L. Ces instructions RAC sont typiquement des opérations de raccrochage de la part de l'utilisateur. Dans d'autres exemples, le terminal IP TER émet la demande d'ouverture de la liaison L sans intervention d'un utilisateur. L'ouverture de la liaison L et la réalisation du test TST est alors programmée et déclenchée par le terminal IP TER.
Dans certains modes de réalisation, la demande d'ouverture de la liaison L est issue d'un téléphone TEL distinct du terminal IP TER. Il s'agit des modes dans lesquels le terminal IP TER n'est pas un téléphone mais par exemple une passerelle domestique à laquelle sont connectés un ou plusieurs téléphones dans son réseau local. L'utilisateur va alors utiliser le téléphone TEL pour appeler le numéro dédié du serveur de test SRV ; la demande d'ouverture de la liaison L est donc issue du téléphone TEL, distinct du terminal IP TER.
Dans certains modes de réalisation, le terminal IP TER émet des paquets de données dans le canal CD de transmission de données multimédia indépendamment d'instructions reçues au travers d'une interface du terminal IP. Ces modes peuvent être utiles quand le terminal IP TER est à l'initiative de l'ouverture de la liaison L indépendamment d'une action d'un utilisateur. En effet, même en l'absence d'instructions reçues, comme des envois de signaux depuis les microphones, le terminal IP TER va émettre des paquets de données pour assurer que le serveur de test SRV puisse réaliser le test TST de qualité de la liaison L de communication téléphonique IP. L'entité de gestion 100 qui a la charge de réaliser le procédé de gestion et donc d'intercepter les instructions RAC de fermeture de la liaison va également assurer l'émission de ces paquets pendant la durée nécessaire au test TST.
Dans des modes de réalisation de l'invention, le procédé de gestion comprend la réception par le terminal IP TER, pendant la durée donnée, d'un message issu du serveur de test SRV destiné à être restitué par le terminal IP TER. Ce message va être par exemple un message vocal, produit par un composant de synthèse de la parole, ou bien pré-enregistré, qui sera restitué par le haut-parleur du terminal IP TER, quand le terminal IP TER est un téléphone, ou envoyé par le terminal IP TER à un téléphone TEL qui le diffusera sur son haut-parleur. Le message peut aussi comprendre des éléments qui pourront être restitués sur un écran du terminal IP TER ou du téléphone TEL. Un des avantages de ce mode apparaît quand l'ouverture de la liaison L a été réalisée à la demande d'un utilisateur du terminal IP TER qui a composé le numéro de téléphone dédié du serveur de test SRV. Le message issu du serveur de test SRV et restitué par le terminal IP TER va permettre de communiquer des informations à l'utilisateur relatives au déroulement des étapes du test TST exécutées par le serveur de test SRV. Le message peut également donner des instructions à l'utilisateur pour aider à la réalisation du test TST.
Par exemple, le message peut demander à l'utilisateur de presser une ou plusieurs touches du terminal IP TER ou du téléphone TEL. De cette manière, le serveur de test SRV sera capable de réaliser des étapes du test TST relatives au bon fonctionnement du DTMF (acronyme de l'anglais Dual-Tone Mu/ti-Frequency) le long de la liaison L de communication téléphonique IP.
Dans certains modes de réalisation, le message peut demander à l'utilisateur de prononcer une phrase particulière. Un système de reconnaissance de la parole présent dans le serveur de test SRV va alors lui permettre de réaliser un test TST s'appuyant sur la qualité du signal de parole reçu qui peut être comparé au message demandé.
Un avantage de l'émission d'un message par le serveur de test SRV est d'inciter l'utilisateur qui a initié le test TST en appelant le numéro dédié du serveur de test SRV à conserver ouverte la liaison L le temps nécessaire pour réaliser le test TST, autrement dit pour l'inciter à ne pas raccrocher RAC. De cette manière, l'ensemble des étapes du test TST pourra être réalisé par le serveur de test SRV même quand il s'agit de tester la qualité de la liaison L avec un terminal IP TER qui ne dispose pas de l'entité de gestion 100. Même en l'absence d'une entité de gestion 100 interceptant les instructions RAC de fermeture de la liaison L, ce mode de réalisation va permettre d'éviter la production de telles instructions RAC. Ce mode de réalisation permet donc de mettre à disposition en libre-service un serveur de test SRV qui pourra être appelé par tous types de terminaux IP TER et réalisera l'ensemble de tests TST. Le message émis par le serveur de test SRV conserve l'utilisateur qui a appelé le serveur de test SRV au bout du fil le temps nécessaire. Dans des modes de réalisation, le message émis pendant la durée de réalisation des étapes du test TST comprend des informations relatives au test TST réalisé par le serveur de test SRV. Ces informations peuvent être par exemple des indications de début et de fin de la réalisation des étapes du test TST au fur et à mesure de la réalisation de chacune d'entre elles. Ces informations peuvent comprendre également les résultats du test TST, y compris une indication globale sur la qualité de la liaison L de communication téléphonique IP entre le terminal IP TER et le serveur de test SRV.
La figure 2 présente la situation quand le terminal IP TER n'est pas un téléphone IP. Le terminal IP TER est par exemple une passerelle domestique et crée un réseau local DECT auquel se rattache un téléphone TEL. La liaison L de communication téléphonique IP est alors ouverte au sein d'un réseau IP entre le terminal IP TER et le serveur de test SRV. La liaison L de communication comprend un canal CS dédié à la transmission d'informations de signalisation et un canal CD dédié à la transmission de données multimédia, dont le signal vocal entre le terminal IP TER et le serveur de test SRV. Dans cette situation, une instruction RAC de fermeture de la liaison L peut être reçue par le terminal IP TER dans plusieurs situations, et en particulier quand l'utilisateur du téléphone TEL effectue une action de raccrochage RAC sur le téléphone TEL. Une telle action RAC est transmise par l'intermédiaire de la liaison DECT vers le terminal IP TER. La présence de l'entité de gestion 100 mettant en œuvre le procédé de gestion assure que l'instruction de fermeture RAC ne sera pas mise en œuvre pendant la durée nécessaire à la réalisation du test TST.
La figure 3 présente la situation quand le terminal IP TER est un téléphone IP. Le terminal IP TER est un téléphone capable de mettre en œuvre directement les protocoles nécessaires de téléphonie IP. La liaison L de communication téléphonique IP est ouverte entre le terminal IP TER et le serveur de test SRV, éventuellement au travers de plusieurs réseaux IPI, IP2 connectés par un ou plusieurs routeurs. La liaison L comprend un canal CS dédié à la transmission d'informations de signalisation et un canal CD dédié à la transmission de données multimédia. L'entité de gestion 100 présente dans le terminal IP TER permet d'assurer que la liaison L reste ouverte même en présence d'une instruction RAC de fermeture de la liaison L, en l'occurrence ici une instruction de raccrochage par l'utilisateur du terminal IP TER.

Claims

Revendications
1. Procédé de gestion d'un test (TST) de la qualité d'une liaison (L) de communication téléphonique entre un terminal (TER) et un serveur de test (SRV), la liaison (L) de communication téléphonique pouvant être ouverte ou fermée, le test (TST) étant réalisé par le serveur de test (SRV) lorsque la liaison (L) est ouverte, caractérisé en ce que l'ouverture de la liaison (L) est précédée d'une demande d'ouverture de la liaison (L) issue du terminal (TER) et en ce que, durant la réalisation du test (TST) de la qualité de la liaison (L), ladite liaison (L) est maintenue ouverte indépendamment de la réception d'une instruction (RAC) de fermeture de la liaison (L) par le terminal (TER) pendant une durée donnée
2. Procédé de gestion d'un test (TST) selon la revendication 1 caractérisé en ce que, si une instruction (RAC) de fermeture de la liaison (L) est reçue pendant la durée donnée, l'exécution de ladite instruction (RAC) est repoussée d'une autre durée donnée
3. Procédé de gestion d'un test (TST) selon l'une des revendications 1 ou 2 caractérisé en ce que, la liaison (L) étant une liaison de communication téléphonique IP ouverte entre le terminal (TER) et le serveur de test (SRV), ladite liaison (L) comprend un canal de signalisation (CS) permettant au serveur de test (SRV) d'obtenir des informations relatives à la signalisation et en ce que la réalisation, par le serveur de test (SRV), du test (TST) de la qualité de la liaison (L) dépend des informations obtenues relatives à la signalisation
4. Procédé de gestion d'un test (TST) selon l'une des revendications 1 à 3, caractérisé en ce que la liaison (L) est une liaison de communication téléphonique IP et en ce que la demande d'ouverture de la liaison (L) issue du terminal (TER) est précédée d'une demande d'ouverture issue d'un téléphone (TEL) distinct du terminal (TER)
5. Procédé de gestion d'un test (TST) selon la revendication 4, caractérisé en ce que, la liaison (L) étant une liaison de communication téléphonique IP ouverte entre le terminal (TER) et le serveur de test (SRV), ladite liaison comprend un canal (CD) de transmission de données multimédia et en ce que le terminal (TER) émet des paquets de données dans le canal (CD) indépendamment d'instructions reçues au travers d'une interface du terminal (TER)
6. Procédé de gestion d'un test (TST) selon l'une des revendications 1 à 5 caractérisé en ce qu'il comprend la réception par le terminal (TER), pendant la durée donnée, d'un message issu du serveur de test (SRV) destiné à être restitué par le terminal (TER)
7. Procédé de gestion d'un test (TST) selon la revendication 6 caractérisé en ce que le message reçu par le terminal (TER) comprend des informations relatives au test (TST) réalisé par le serveur de test (SRV)
8. Entité de gestion (100) d'un test (TST) de la qualité d'une liaison (L) de communication téléphonique entre un terminal (TER) et un serveur de test (SRV), la liaison (L) de communication téléphonique pouvant être ouverte ou fermée, le test (TST) étant réalisé par le serveur de test (SRV) lorsque la liaison (L) est ouverte, caractérisée en ce que l'ouverture de la liaison (L) de communication téléphonique est précédée d'une demande d'ouverture de la liaison (L) issue du terminal (TER) et en ce que ladite entité de gestion comprend un processeur configuré pour assurer que, durant la réalisation du test (TST) de la qualité de la liaison (L), ladite liaison (L) est maintenue ouverte par ladite entité de gestion (100), indépendamment de la réception d'une instruction (RAC) de fermeture de la liaison (L) par le terminal (TER), pendant une durée donnée
9. Terminal (TER) comprenant une entité de gestion (100) selon la revendication 8
10. Programme d'ordinateur apte à être mis en œuvre par un terminal (TER) selon la revendication 9, le programme comprenant des instructions de code qui, lorsqu'il est exécuté par un processeur, réalise le procédé de gestion selon la revendication 1
11. Support de données sur lequel est enregistré un programme d'ordinateur selon la revendication 10
EP24701024.2A 2023-01-31 2024-01-19 Procédé de gestion d'un test de la qualité d'une liaison de communication téléphonique Pending EP4659434A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2300862A FR3145456A1 (fr) 2023-01-31 2023-01-31 Procédé de gestion d’un test de la qualité d’une liaison de communication téléphonique
PCT/EP2024/051295 WO2024160564A1 (fr) 2023-01-31 2024-01-19 Procédé de gestion d'un test de la qualité d'une liaison de communication téléphonique

Publications (1)

Publication Number Publication Date
EP4659434A1 true EP4659434A1 (fr) 2025-12-10

Family

ID=87280402

Family Applications (1)

Application Number Title Priority Date Filing Date
EP24701024.2A Pending EP4659434A1 (fr) 2023-01-31 2024-01-19 Procédé de gestion d'un test de la qualité d'une liaison de communication téléphonique

Country Status (3)

Country Link
EP (1) EP4659434A1 (fr)
FR (1) FR3145456A1 (fr)
WO (1) WO2024160564A1 (fr)

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6160871A (en) * 1998-04-10 2000-12-12 Sprint Communications Company, L.P. Communications test system
US6754310B1 (en) * 2001-03-08 2004-06-22 3Com Corporation Telephony interface device for providing diagnostic information to a telephone
FR3063407B1 (fr) * 2017-02-24 2021-09-10 Orange Test de liaison de communication ip

Also Published As

Publication number Publication date
FR3145456A1 (fr) 2024-08-02
WO2024160564A1 (fr) 2024-08-08

Similar Documents

Publication Publication Date Title
EP1519516A2 (fr) Procédé d'établissement d'un transfert de données entre deux dispositifs de communication et dispositif associé
EP1946523B1 (fr) Procédé et serveur d'invocation des serveurs d'application dans un réseau sip
EP3777081B1 (fr) Procédé de gestion d'une pluralité de flux média, et dispositif associé
FR2982107A1 (fr) Procede de gestion d'une communication destinee a un utilisateur et serveur d'application
EP2882161B1 (fr) Procédé et dispositf d' établissement d'une communication
WO2009125149A1 (fr) Procede de terminaison d'un appel et terminal de voix sur ip
EP2997714A1 (fr) Procédé de communication en temps réel entre navigateurs web
EP3811604B1 (fr) Procédé et dispositif de filtrage d'une communication
EP2371106A1 (fr) Procede de notification et passerelle d'acces a un reseau de voix sur ip
WO2024160564A1 (fr) Procédé de gestion d'un test de la qualité d'une liaison de communication téléphonique
EP3903476B1 (fr) Procédé de traitement de messages vocaux, procédé de désactivation d'un codage dtmf et procédé de traitement d'une demande de désactivation d'un codage dtmf
FR2938720A1 (fr) Procede, appareil et support apte a etre lu par ordinateur apparente pour permettre a un poste internet d'appeller un poste classique
EP2064855B1 (fr) Procede de communication entre plusieurs terminaux
EP2100430B1 (fr) Procédé et système de télécommunication permettant à au moins deux utilisateurs distincts d'accéder à un meme ensemble d'informations
WO2004100492A1 (fr) Procede et dispositif de synchronisation de flux de donnees
WO2009112760A1 (fr) Procede de gestion d'une session de communication au niveau d'une passerelle domestique
FR3057129A1 (fr) Procede d'enregistrement simplifie d'un identifiant dans une liste noire
FR2977433A1 (fr) Procede de filtrage de flux early media dans un reseau ims et serveur mettant en œuvre ce procede
FR3096536A1 (fr) Procédé d’établissement d’une session de communication entre deux terminaux de communication permettant de lutter contre des fraudes « wangiri ».
WO2020136317A1 (fr) Procédé de libération d'un canal de communication conforme à la norme dect, base et terminal conformes à la norme dect
FR3099019A1 (fr) Procédé de gestion d’une communication téléphonique dans un réseau de communication, dispositif, plateforme de gestion et programme d’ordinateur associé.
JP2012147056A (ja) Ip電話キャリア判定装置及びプログラム並びに記録媒体
FR3029725A1 (fr) Procede d'etablissement d'une liaison telephonique entre un premier dispositif de communication et un deuxieme dispositif de communication, et serveur associe
OA19745A (fr) Procédé de communication en temps réel entre navigateurs web.
FR2983024A1 (fr) Procede de rejet d'un appel telephonique

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20250808

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC ME MK MT NL NO PL PT RO RS SE SI SK SM TR