WO2011067540A1 - Procédés d'envoi et de traitement d'une reponse sip - Google Patents

Procédés d'envoi et de traitement d'une reponse sip Download PDF

Info

Publication number
WO2011067540A1
WO2011067540A1 PCT/FR2010/052597 FR2010052597W WO2011067540A1 WO 2011067540 A1 WO2011067540 A1 WO 2011067540A1 FR 2010052597 W FR2010052597 W FR 2010052597W WO 2011067540 A1 WO2011067540 A1 WO 2011067540A1
Authority
WO
WIPO (PCT)
Prior art keywords
node
request
sip
response
parameter
Prior art date
Application number
PCT/FR2010/052597
Other languages
English (en)
Inventor
Stéphane BOIZARD
Sébastien PROUVOST
Olivier Cleuziou
Original Assignee
France Telecom
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 France Telecom filed Critical France Telecom
Priority to US13/513,535 priority Critical patent/US8804498B2/en
Priority to EP10807455.0A priority patent/EP2507970B1/fr
Publication of WO2011067540A1 publication Critical patent/WO2011067540A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/28—Routing or path finding of packets in data switching networks using route fault recovery

Definitions

  • the present invention relates to the general field of telecommunications.
  • It relates more particularly to the processing of a request in accordance with the SIP (Session Initiation Protocol), transmitted on a telecommunications network, and crossing a plurality of nodes of the network to a recipient, one of these nodes having detected a an event that prevents it from processing the request and thus forwarding it to the next node.
  • SIP Session Initiation Protocol
  • a node of a SIP network designates any entity of this network capable of routing a SIP request (i.e. compliant with the SIP protocol) to its destination.
  • a node will preferably be a physical equipment of the network.
  • the invention has a preferred application, but not limited to, in the context of voice over IP (VoIP) networks based on the SIP protocol or for example with an IMS (Internet Multimedia Subsystem) network.
  • VoIP voice over IP
  • IMS Internet Multimedia Subsystem
  • An event or situation preventing a node of the network from processing a SIP request for example means a lack of resources at this node, congestion or a break in its links to the nodes located downstream of the network on the path identified for the request, etc.
  • downstream and upstream will be used with reference to the path taken by the request, in the source direction of the request to the destination of the request.
  • the node Al on receiving a failure response 503, the node Al must attempt to reroute the SIP call request to another node than the node A0. If the node Al does not find at its level other nodes for routing the SIP call request to its destination (either because they do not exist or because they are also failing) , a re-routing of the request is then undertaken by a node A2 located upstream of the node Al, then a node A3, etc.
  • the SIP protocol in its current version, authorizes the rerouting of a call request only in very limited cases of preventing the node to process the call request, and following the issuance of 503.
  • the SIP protocol in its current version, authorizes the rerouting of a call request only in very limited cases of preventing the node to process the call request, and following the issuance of 503.
  • the present invention aims in particular to overcome the aforementioned drawbacks.
  • the invention is based firstly on a method of sending a notification response of an impediment to process a SIP request by a node, and secondly on a method of processing this notification response. by the node receiving it, in other words interpretation of the parameter activated in this response.
  • the invention therefore relates to a method of sending a SIP response by a first node of a telecommunications network, comprising:
  • the invention also provides a device for sending a SIP response in a telecommunications network comprising:
  • the sending device is remarkable in that it further comprises means for activating in the SIP response, before sending it to the second device, a parameter allowing a rerouting of the request, and which can be configured by the second device.
  • the invention no longer proposes, as in the current state of the art, to associate with a particular failure response, namely a response 503 "Service Unavailable", a possibility of rerouting the request. But it proposes to activate in the response message sent by the node having detected an impediment to process the call request (that is to say in the failure response), in addition to the usual information of notification of the reason for the impediment, an additional parameter indicating that a rerouting of the request by the node immediately upstream in the path of the request and receiving this message, is allowed and possible.
  • parameter is to be considered here in its general sense, in that it designates a rerouting flag, or in other words, an element indicating that rerouting is authorized. It can be a SIP parameter as defined in RFC 3261 entitled “SIP: Session Initiation Protocol", edited by the IETF, but it can also be carried by a SIP header, by a field of one SIP header, by a body element of the SIP response, etc.
  • activation of a parameter means:
  • activated or active and deactivated or inactive, will be used indifferently to designate the state of the parameter in the response.
  • This parameter can advantageously be configured (ie be activated or deactivated, have its value modified, be maintained in the state, etc.) by the second node, in other words by the node, or in an equivalent manner by the device, receiving the response.
  • SIP containing the parameter.
  • the invention thus offers greater flexibility in terms of rerouting than the mechanisms currently implemented in the SIP protocol.
  • the use of a configurable parameter in the response advantageously makes it easy to activate and deactivate the possibility of rerouting by a node receiving this response, which is not currently allowed by the SIP protocol.
  • each node of the path receives the failure response 503 and, upon receipt of this response, may attempt to reroute the call request.
  • the invention offers the freedom to be able to delete this possibility at any time, and limit the rerouting of the request to the node immediately preceding the failed node in the path of the request.
  • the invention thus finds a particular interest in SIP networks where the routes are complex between a source node (requesting) and a destination node (requested), that is to say in particular in networks in which the number of intermediate nodes traversed by a SIP request is important (ie greater than 2) and the paths that can be taken by the request are multiple. It allows, in these networks, to limit the number of inefficient reroutings, by implementing appropriate processing by the node receiving the message including the parameter allowing rerouting.
  • the sending method further comprises, after the detection step, a step of checking the validity of at least one predetermined criterion.
  • the rerouting of the request can be conditioned, on the one hand, by the detection of an event or a situation preventing a node of the network from processing the SIP request, and, on the other hand, by additional criteria linked by example to the cause or the nature of the impediment.
  • the choice to allow rerouting therefore belongs to the node that detected the impediment.
  • the parameter can not be activated (for example inserted) in the response notifying the prevention, if it is due to a defect affecting only the first node (lack of resources, congestion, maintenance of the first node, etc.) and not all nodes downstream leading to the recipient of the request.
  • the second node will not receive this parameter and this done, will not transfer it to the upstream nodes in the path. Since these nodes do not receive a response containing this parameter, they will not attempt to reroute the request, whether or not they are suitable for interpreting the parameter.
  • the validity of the criterion related to the ability of the second node to process the parameter is checked by using an indication included in the SIP request and an identifier of the second node.
  • each node through which the SIP request passes may insert, in the request, an indication that it is suitable for interpreting the parameter, as well as an identifier, such as its IP address.
  • an indication may, for example, be inserted in the "Supported" header of the SIP request, known to those skilled in the art.
  • the first node can then ensure that this indication emanates well from the second node, that is to say the node just upstream on the path of the request, by comparing the identifier in the request and the identifier of the second node from which it receives the request (present in particular in the header "via parameter received").
  • the first node does not activate the parameter in the SIP response, so as to avoid inefficient rerouting by a node upstream of the second node.
  • a value of the parameter activated in the response depends on a cause of the prevention.
  • the invention also provides a method for processing a SIP response, implemented by a first node of a telecommunications network after having transferred to a second node of the network a SIP request received from a third node, the response being received from the second node and notifying the first node of an impediment of a processing of the request by the second node.
  • the process according to the invention is remarkable in that it comprises:
  • the response received from the second node contains an activated (or active) parameter allowing a rerouting of the request and which can be configured by the first node:
  • the invention also relates to a device for processing a SIP response of a telecommunications network, adapted to process said response after having transferred to a second device of the network a SIP request received from a third device, said response being received from the second device and notifying said processing device of an impediment of a processing of the request by the second device, said processing device being characterized in that it comprises:
  • the invention makes it possible to limit rerouting to the first level upstream of the node that has detected an impediment in processing the request.
  • any node receiving a prevention notification SIP response in which the parameter is disabled will not attempt to reroute the SIP request.
  • the first node does not have an alternative route or if the attempted rerouting fails, then it will trace an impediment notification SIP response by disabling the routing possibility indication (for example, by deleting it from the response he received from the second node).
  • the third node receiving this SIP response will not attempt rerouting. In this way, inefficient rerouting and unnecessary load in the network are limited.
  • the method of treatment further comprises:
  • the processing method when the response received from the second node contains the activated parameter, the processing method further comprises a step of checking the validity of at least one predetermined criterion, and, if the said at least one criterion is valid , a step of sending to the third node of a SIP response notifying it of a prevention of a processing of the request in which the parameter is activated.
  • the parameter authorizing the rerouting is not disabled by the first node in the SIP response, before its transmission to the upstream node (third node).
  • the third node can initiate a rerouting of the SIP request, on receiving the SIP response.
  • cascade rerouting can still be avoided, since the first node does not have an alternative route and therefore has not itself attempted rerouting. It will be sufficient for this reason that the third node, in the event of ineffective rerouting (s), deactivates the parameter contained in the SIP response before transmitting it to the upstream nodes.
  • a node receiving a SIP response notifying an impediment to process the request in which the parameter is disabled or inactive (that is, in which it does not exist or has a value indicating that a rerouting is not allowed), will not attempt to reroute, but will go back to the upstream node this SIP response as received.
  • the invention relates to a system of a telecommunications network comprising at least one source equipment and a destination device capable of exchanging a SIP request, and a plurality of intermediate nodes through which this request passes between the source equipment. and the recipient equipment, said system being characterized in that at least one of the intermediate nodes of the system is a device for sending a SIP response notifying an impediment to process the request according to the invention and at least one of the intermediate nodes of the system is a device for processing this response according to the invention.
  • the system according to the invention thus makes it possible to limit ineffective rerouting in the network, and has the same advantages as the processing device and the sending device according to the invention.
  • At least intermediate nodes comprises means for inserting into the SIP request an indication relating to its ability to process the parameter, these means being activated before sending the request to another node.
  • this intermediate node being a device for sending a SIP response according to the invention further comprising means, activated after the detection of an event preventing the processing of the request, checking the validity of a criterion related to this ability.
  • the source equipment comprises means, activated if it receives a SIP response containing said activated parameter:
  • the invention also provides a method for processing a SIP response, implemented by a source equipment of a telecommunications network, at the origin of a SIP request transmitted by the source equipment at a node of the network, the SIP response being received from this node and notifying the source equipment of an impediment of a processing of the request by the node.
  • this processing method is remarkable in that it comprises, if the response contains an activated parameter allowing a rerouting of the request:
  • a step of notifying a failure to process the request if the source equipment is notified of an impediment of a processing of the request by said at least one other node, a step of notifying a failure to process the request.
  • the notification of the failure of processing the request can be made for example to the user of the source equipment.
  • this notification can be performed by interworking the processing prevention response with another protocol.
  • the invention also aims at a signal comprising a SIP response notifying a prevention of a first node to process a SIP request sent by a second node, which is remarkable in that this SIP response includes a parameter allowing the rerouting of the request, and can be configured by the second node.
  • the different steps of the sending method and the processing method are determined by computer program instructions.
  • the invention also relates to a computer program on an information carrier, this program being capable of being implemented in a sending device or more generally in a computer, this program comprising instructions adapted to implementing the steps of a method of sending a SIP message as described above.
  • the invention also relates to a computer program on an information medium, this program being capable of being implemented in a processing device or more generally in a computer, this program comprising instructions adapted to the implementation of the steps of a method of processing a SIP message as described above.
  • Each program can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other form desirable shape.
  • the invention also relates to a computer-readable information medium, comprising instructions of a computer program as mentioned above.
  • the information carrier may be any entity or device capable of storing the program.
  • the medium may comprise storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording medium, for example a floppy disk or a disk. hard.
  • the information medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means.
  • the program according to the invention can be downloaded in particular 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 the execution of the method in question.
  • the sending method, the processing method, the sending device, the processing device and the system according to the invention have in combination all or some of the above features.
  • FIG. 1 already described, represents an example of a plurality of inefficient rerouting of a SIP request undertaken in a telecommunications network;
  • FIG. 2 represents an example of a system of a telecommunications network according to the invention, in a particular embodiment
  • FIG. 3 represents the hardware architecture of a node of the system represented in FIG. 2;
  • FIG. 4 represents an example of routing table extracts
  • FIG. 5 represents, in the form of a flow chart, the main steps of the method of sending a SIP response according to the invention, in a particular embodiment, and when it is implemented by a system node. shown in Figure 2;
  • FIG. 6 represents, in the form of a flow chart, the main steps of the method of processing a message according to the invention, in a particular embodiment, and when it is implemented by a node of the system represented on FIG. Figure 2;
  • FIG. 7 illustrates an exemplary application of the invention. Detailed description of an embodiment
  • FIG. 2 represents, in its environment, a system 1 of a telecommunications NW network according to the invention, in a particular embodiment.
  • the NW network is a Voice over IP (VoIP) network, based on the SIP signaling protocol. This protocol is known to those skilled in the art and will not be described in more detail here. Further information on the SIP protocol is available in RFC 3261, "SIP: Session Initiation Protocol" and edited by the IETF.
  • VoIP Voice over IP
  • the network NW has an architecture consisting of several distinct domains, namely the domains D1 and D2.
  • a domain is an independent telecommunications (sub) network, such as for example a VoIP network managed by a fixed telephony operator or by a mobile operator, etc.
  • the D1 and D2 domains are both based on an IMS (IP Multimedia Subsystem) architecture, as specified in 3GPP and SPAN standardization standards.
  • IMS IP Multimedia Subsystem
  • an IMS core network also called IMS core network
  • CSCF entity Call Session Control Function
  • BGCF entity Bandhouse Gateway Control Function
  • application servers application servers.
  • each domain D1 and D2 comprises an IMS core network, noted respectively IMS-1 and IMS-2, as well as a plurality of client terminals (for example the terminals C1 and C2), which can connect to the domains D1 and D2 via the IMS-1 and IMS-2 core networks according to various access networks.
  • the domains D1 and D2 are further connected to each other and to the external domains (for example to the public Internet network) by so-called edge equipment.
  • edge equipment for example to the public Internet network
  • BCS1-A, BCS1-B for the domain D1 and BCS2-A, BCS2-B for the domain D2.
  • BCS1-A and BCS1-B border elements can be used indiscriminately in the Dl domain from the IMS-1 core network.
  • the BCS2-A and BCS2-B edge elements can be used indiscriminately in the D2 domain from the IMS-2 core network.
  • a SIP request sent by a source equipment to a destination equipment is conveyed by a signal that passes through numerous nodes (i.e. equipment) of the network.
  • nodes Some of these nodes have important functions to perform on the SIP request, such as providing services such as the presentation of the name of the source equipment. Other nodes have transit only or protocol interworking roles, with no added value to the service itself, outside of the request routing and interworking function. It is easy to understand that these nodes can be replaced by other nodes having identical or similar functions.
  • the edge equipments BCS1-A, BCS1-B, BCS2-A, BCS2-B and the core networks IMS-1 and IMS-2 are nodes of the system 1 of the telecommunications network NW, for example. which transit a SIP request sent, for example, by the client terminal C1 (source equipment in the sense of the invention) to the client terminal C2 (recipient equipment in the sense of the invention).
  • they are entities of the NW network capable of routing a SIP request to its destination.
  • the terms node, equipment or device will be used indifferently to designate the entities BCS1-A, BCS1-B, BCS2-A, BCS2-B, IMS-1 and IMS-2.
  • each of these devices, or nodes is both a sending device and a processing device according to the invention. This hypothesis is however in no way limiting. The invention also applies when at least two nodes successively borrowed by the request are respectively a processing device and a sending device according to the invention.
  • Each device of the system 1 i.e. BCS1-A, BCS1-B, BCS2-A, BCS2-B, IMS-1 and IMS-2) here has the hardware architecture of a computer, as shown in FIG.
  • each equipment of the system 1 comprises in particular a processor 11, communication means 12 with the other equipment of the network NW, and possibly with equipment external to the network, a random access memory 13, a read-only memory 14, and a non-writable rewritable memory volatile 15.
  • the read-only memory 14 comprises a computer program according to the invention, adapted to perform the main steps of the sending method according to the invention shown in FIG. 5 described later, as well as a program according to the invention, adapted to execute the main steps of the treatment method according to the invention shown in Figure 6 described later.
  • the rewritable memory 15 here comprises a routing table within the NW network.
  • This routing table identifies the node (s) to which the equipment can route a SIP request reaching it.
  • Such a table is known to those skilled in the art and will not be described in more detail here. It can be predefined according to the topology of the network, or alternatively be determined and updated using a dynamic procedure based for example on network announcements issued by the various nodes of the network.
  • routing table extracts are given in FIG. 4, for the IMS-1 (table RTI1) and BCS1-A (table RTB1) equipment.
  • IMS-1 table RTI1
  • BCS1-A table RTB1
  • the IMS-1 core network can route a SIP request from a client C1 to edge elements BCS1-A and BCS1-B;
  • the BCS1-A edge equipment can route a SIP request from the IMS-1 core network to the BCS2-A and BCS2-B edge elements.
  • the BCS2-A edge equipment is temporarily overloaded: it is therefore not able to process a SIP request reaching it, and consequently to transmit it to the next node for routing to its destination.
  • no event prevents other devices from processing the SIP requests they receive.
  • a SIP call request S is sent by the client terminal C1 to the client terminal C2, C1 and C2 being mobile phones. This request S is an INVITE call setup request.
  • the invention also applies to any other type of SIP requests, in particular a request opening a dialogue (eg INVITE or SUBSCRIBE), a request opening a transaction within a dialog (eg ACK or BYE) or a query opening a non-dialog transaction (eg OPTION).
  • a request opening a dialogue eg INVITE or SUBSCRIBE
  • a request opening a transaction within a dialog eg ACK or BYE
  • a query opening a non-dialog transaction eg OPTION
  • the request S passes first through the node IMS-1.
  • the node IMS-1 Upon receipt of this request S (step E10), the node IMS-1 verifies its ability to process it (step E20). Then it executes the functions associated with it on the request S, and stores in memory a copy of the possibly modified request S (step E30).
  • the request initially sent by the client C1 and any request obtained as a result of the application of the functions associated with the nodes through which the request S is sent, will be referred to indifferently as the request S.
  • the IMS-1 node After consulting its routing table RTI1, the IMS-1 node transmits the request S to the next node, namely the BCS1-A edge equipment (step E40).
  • the selection of a node from among a plurality of routing candidate nodes and contained in a routing table is known to those skilled in the art and will not be described in more detail here.
  • the node BCS1-A verifies its ability to process it (step E20), performs the functions associated with it if necessary, and then stores in memory a copy of the request S thus obtained (step E30). After consulting its routing table RTB1, it transmits the request S to the next node, namely the BCS2-A edge equipment (step E40).
  • This request S is then received by the node BCS2-A (step E10), temporarily overloaded.
  • the node BCS2-A On receiving the request S, the node BCS2-A examines its resources and detects that it does not have sufficient resources to process the request S (step E20). For example, because there are too many requests to process, its CPU processor is overloaded (event preventing the processing of the request within the meaning of the invention).
  • the BCS2-A node can detect that all its IP resources are taken by other requests, or that the physical line to be used to transmit the request S to the next node is unusable.
  • the BCS2-A node is about to send a failure (or error) response to the BCSl-A node, immediately upstream of the BCS2-A node in the path taken by the S-request and having sent him the application S, in order to notify him of his impediment.
  • this failure response is a "480 Temporarily Unavailable" request. It constitutes a SIP response notifying an impediment within the meaning of the invention.
  • other failure or error responses specified by the SIP protocol could be considered, such as the failure response 503.
  • the BCS2-A node activates previously in the failure response 480, a parameter noted P, indicating that a rerouting by the node BCSl-A (and more generally, by any node receiving the response in which parameter P is enabled), is allowed.
  • the activation of the parameter P in the failure response is conditioned here by the verification of at least one additional criterion in addition to the detection of an event preventing the processing of the request S (step E50).
  • This is a criterion c related to the capacity of the node BCSl-A to which the failure response is sent to interpret and process the parameter P.
  • other criteria can be verified, such as a criterion related to the nature of the impediment, etc.
  • a node of the path taken by the request S knows how to interpret and process the parameter P according to the invention, in other words, when it implements the processing method according to FIG. invention, it insert in the request S, before transmitting it to the next node (ie, before the step E40), an identifier (such as its IP address), as well as an indication that it is able to process the parameter P.
  • This identifier and this indication are inserted here in the "Supported" header of the request.
  • this header indicates, using specific identifiers also called option tags ("option tags" in English) predefined by the Internet Assigned Number Authority (Ass), the different services supported by the nodes through which the request passes.
  • option tags option tags
  • they may be the subject of a new header of the SIP request.
  • the IMS-1 and BCS1-A nodes have inserted, in the "Supported" header of the request S, their IP address as well as an indication that they are capable of processing the parameter P.
  • the BCS2-A node compares the identifier of the node or nodes associated with this indication, namely here, the IP address of the BCS1-A node and the IP address of the IMS-1 node, with the identifier of the node of which it has received the request, and which is present, according to the SIP protocol, in the parameter "Received" of the header "Via" of the request S.
  • This comparison aims to detect dynamically, before allowing a rerouting, if the node having indicated its ability to process the parameter P is the node directly upstream of the node BCS2-A, that is to say the one that transmitted the request S.
  • the node BCS2-A does not activate the parameter P in the failure response but transmits it as such to the BCS1-A node (step E60).
  • the identifier of the BCSl-A node included here in the Supported header, the criterion c is verified, and the BCS2-A node activates in the failure response 480 the parameter P (step E70).
  • the BCS2-A node inserts the parameter P into the failure response 480.
  • the parameter P is inserted as a new header of the failure response. Alternatively, it may be a new field inserted in a header of the failure response or a new element inserted into the body of the failure response.
  • the insertion of the parameter in the request constitutes an activation of this parameter within the meaning of the invention.
  • the value of the parameter P thus inserted may depend on the cause or the nature of the impediment. For example and for illustrative purposes only:
  • the failure response 480 comprising the parameter P is then sent to the node BCS1-A (step E80). This response is carried on the network in a signal according to the invention.
  • the verification of the criterion c can be carried out using a preconstituted static list, and stored at the level of the node BCS2-A, this list comprising the identifiers of the nodes of the network NW implementing the processing method according to the invention.
  • this list will have to be updated according to the changes affecting the nodes, such as, for example, changes in software version of the nodes or topology of the network.
  • the node BCS1-A determines whether it contains the parameter P allowing it to reroute (ie if the parameter P is activated in the response received failure) (step F20).
  • the node BCSl-A transmits this response to the node immediately upstream (identified in the Via header of the request S), without attempting to reroute the request S (step F30).
  • the failure response 480 here containing the parameter P, the BCSl-A node looks in its routing table for another route for the request S (step F40), that is to say a node distinct from the BCS2-A node, to reroute the SIP request S.
  • the BCS1-A node here deletes the parameter P from the failure response 480 and transmits the modified query to the node immediately upstream. (ie at node IMS-1), without attempting to reroute the request S (step F30).
  • the deletion of the parameter P constitutes a deactivation step of the parameter P within the meaning of the invention.
  • the BCS2-A node could not reroute the request due to the absence of alternative route, transmits the failure response with the parameter P to the node IMS-1 . It will then attempt, upon receipt of the failure response with the parameter P, a re-routing of the SIP request, and delete the parameter P if rerouting fails to avoid cascade rerouting.
  • the parameter P can advantageously be configured by the node receiving the failure response, so as to adapt the rerouting strategies of the request S notably to the topology of the network and the state of the nodes. network.
  • the search for an alternative node constitutes in itself a verification of a predetermined criterion within the meaning of the invention (i.e. presence of an alternative node to reroute the request).
  • Other criteria may alternatively be considered before deciding the deactivation of the parameter P in the response, such as the detection of a particular node. These criteria are intended to identify certain situations in which, it may be relevant to attempt a rerouting by an upstream node.
  • step F50 a rerouting operation of the request S, previously stored by the BCS1-A node, is undertaken by the BCS1-A node to the identified alternative node (step F60).
  • This step is carried out according to mechanisms known to those skilled in the art and not described further here. The same applies to the choice of the node among the routing candidates in the case of a plurality of available candidates. In the example envisaged here (see FIG. 4), node BCS1-A determines that node BCS2-B is a potential candidate for rerouting.
  • step F70 either the request S is processed by the node BCS2-B: it is then transmitted to the IMS-2 node for routing to the client C2 (step F80);
  • the BCS1-A node receives a new failure response, this time sent by the node to which the rerouting was operated (ie the BCS2-B node) (step F70): a new potential candidate for rerouting, identified during the search step F40, is then considered and the steps F60-F90 are repeated.
  • step F90 If, however, all the candidate nodes identified in the search step have been tested (step F90) and transmitted to the BCS1-A node a failure response notifying an impediment to processing the request S, the node
  • BCS1-A deletes the parameter P from the previously received failure response 480 (step F100).
  • This deletion step is a step of deactivating the parameter P within the meaning of the invention.
  • the latter receiving the failure response without the parameter P does not attempt to reroute the request, but relays the failure response as it is to the client Cl.
  • the node BCS-IA is not the node at the origin of the SIP request S, ie, it has received this request from the node IMS-1A, which itself has received the request of the node Cl. If it is assumed in another example, that the node BCS-IA is the node at the origin of the request S, and that any attempt of rerouting undertaken by the node BCS-IA following the reception of the response 480 fails, then the BCS-IA node notifies this failure to the entities impacted by the failure to transmit the S-request.
  • the P parameter is disabled in the SIP failure response 480 transmitted by the BCS-2A node to the BCS-IA node, before being sent to the IMS-1 node.
  • the BCS-IA node can disable the parameter P (in other words, do not insert it) in the SIP failure response received from the BCS-2B node in step E70, and transfer this response to the IMS-1 node.
  • it may also disable this parameter in a new SIP failure response that it passes to the IMS-1 node.

Landscapes

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

Abstract

Conformément à l'invention, le procédé d'envoi d'une réponse SIP par un premier nœud d'un réseau de télécommunications, comprend; une étape de réception (ElO) par le premier nœud d'une requête SIP envoyée par un second nœud du réseau; une étape de détection (E20) d'un événement empêchant un traitement de cette requête par le premier nœud; une étape d'envoi (E80) au second nœud d'une réponse SIP notifiant cet empêchement; ledit procédé étant caractérisé en ce qu'il comprend en outre, avant l'étape d'envoi, une étape d'activation (E70) dans la réponse SIP d'un paramètre autorisant un reroutage de la requête et pouvant être configuré par le second nœud.

Description

Procédés d'envoi et de traitement d'une réponse SIP
Arrière-plan de l'invention
La présente invention se rapporte au domaine général des télécommunications.
Elle concerne plus particulièrement le traitement d'une requête conforme au protocole SIP (Session Initiation Protocol), émise sur un réseau de télécommunications, et traversant une pluralité de nœuds du réseau jusqu'à un destinataire, l'un de ces nœuds ayant détecté un événement l'empêchant de traiter la requête et donc de la transmettre vers le nœud suivant.
Au sens de l'invention, un nœud d'un réseau SIP désigne toute entité de ce réseau capable de router une requête SIP (i.e. conforme au protocole SIP) vers sa destination. Un tel nœud sera préférentiellement un équipement physique du réseau.
Ainsi, l'invention a une application privilégiée, mais non limitative, dans le contexte des réseaux de voix sur IP (VoIP) basés sur le protocole SIP ou par exemple avec un réseau IMS (Internet Multimedia Subsystem).
Un événement ou une situation empêchant un nœud du réseau de traiter une requête SIP désigne par exemple un manque de ressources au niveau de ce nœud, une congestion ou une rupture de ses liens vers les nœuds situés en aval du réseau sur le chemin identifié pour la requête, etc. Dans la suite de la description, les termes aval et amont seront employés en référence au chemin emprunté par la requête, dans le sens source de la requête vers destination de la requête.
Or, il se peut que d'autres chemins dans le réseau existent pour cette même requête, c'est-à-dire, arrivant au même destinataire mais passant par des nœuds différents. Par conséquent, il peut être utile qu'un nœud en amont du nœud ayant détecté l'empêchement (désigné ci-après par « nœud en échec ») tente un chemin alternatif : on parle alors de reroutage de la requête.
Dans les réseaux SIP actuels, lorsqu'un nœud intermédiaire A0, présent sur le chemin d'une requête d'appel SIP, est dans un état de congestion temporaire ou de maintenance, il peut être configuré de sorte à envoyer au nœud Al, le précédant sur le chemin, une réponse d'échec 503 « Service Unavailable ». Ce message est défini plus en détails dans le document RFC 3261 intitulé « SIP : Session Initiation Protocol », édite par I1ETF.
Conformément au protocole SIP, à la réception d'une réponse d'échec 503, le nœud Al doit tenter de rerouter la requête d'appel SIP vers un autre nœud que le nœud A0. Si le nœud Al ne trouve pas à son niveau d'autres nœuds permettant d'acheminer la requête d'appel SIP vers son destinataire (soit parce qu'il n'en existe pas, soit parce que ceux- ci sont également en échec), un reroutage de la requête est alors entrepris par un nœud A2 situé en amont du nœud Al, puis un nœud A3, etc.
Or, il arrive qu'aucun reroutage ne permette l'acheminement de la requête d'appel vers son destinataire, et ce, quel que soit le niveau auquel il est entrepris dans le chemin. On parlera alors de reroutage inefficace.
Ces reroutages inefficaces peuvent être nombreux en fonction de la topologie du réseau et, de ce fait, nuisibles au bon fonctionnement du réseau de télécommunications. Ils sont en effet à l'origine d'une charge inutile du réseau, qui peut être non négligeable et se faire aux dépens d'autres appels.
Par exemple, en référence à la figure 1, dans une configuration où une requête SIP d'appel émise par un appelant (CALLER) doit transiter par quatre nœuds pour atteindre son destinataire (CALLEE) et le quatrième nœud N4 envoie une réponse d'échec 503 « Service Unavailable », les nœuds précédents sont chacun à leur tour, sur réception de cette réponse d'échec, susceptibles de tenter un reroutage inefficace de la requête. Dans l'exemple représenté sur la figure 1, ceci donne lieu à quatre émissions successives de la requête (transitions 4, 8, 14, 18), qui se soldent par quatre réponses d'échec (transitions 5, 9, 15, 19) envoyées par le quatrième nœud N4 avant que l'échec de l'appel ne soit notifié à l'appelant (transition 22). Autrement dit, la charge du réseau occasionnée par une seule requête SIP au final inefficace dans cette configuration est multipliée par quatre sur le quatrième nœud.
On comprend donc bien que les multiples tentatives de reroutage entreprises dans le réseau SIP peuvent non seulement accroître sensiblement la charge inutile dans le réseau mais également l'engorgement des nœuds déjà en échec.
Par ailleurs, le protocole SIP, dans sa version actuelle, n'autorise le reroutage d'une requête d'appel que dans des cas très limités d'empêchement du nœud à traiter la requête d'appel, et suite à l'émission d'une réponse d'échec 503. Or, en raison notamment de la multiplication des reroutages inefficaces pouvant être rencontrés dans le cadre de l'utilisation de cette réponse d'échec, celle-ci n'est finalement que peu utilisée par les opérateurs des réseaux de télécommunications.
Obiet et résumé de l'invention
La présente invention a pour but notamment de pallier les inconvénients précités.
Elle propose avantageusement à cette fin, d'activer un paramètre dans les réponses remontées par un nœud en échec sur le réseau SIP (typiquement dans une réponse d'échec), de sorte à contrôler le reroutage des requêtes dans le réseau.
Ainsi l'invention repose d'une part, sur un procédé d'envoi d'une réponse de notification d'un empêchement à traiter une requête SIP par un nœud, et d'autre part sur un procédé de traitement de cette réponse de notification par le nœud la recevant, autrement dit d'interprétation du paramètre activé dans cette réponse.
Selon un premier aspect, l'invention vise donc un procédé d'envoi d'une réponse SIP par un premier nœud d'un réseau de télécommunications, comprenant :
- une étape de réception par le premier nœud d'une requête SIP envoyée par un second nœud du réseau ;
- une étape de détection d'un événement empêchant un traitement de cette requête par le premier nœud ;
- une étape d'envoi au second nœud d'une réponse SIP notifiant cet empêchement.
Ce procédé est remarquable en ce qu'il comprend en outre, avant l'étape d'envoi, une étape d'activation dans la réponse SIP d'un paramètre autorisant un reroutage de la requête, et pouvant être configuré par le second nœud. Corrélativement, l'invention vise également un dispositif d'envoi d'une réponse SIP dans un réseau de télécommunications comprenant :
- des moyens pour recevoir une requête SIP envoyée par un second dispositif du réseau ;
- des moyens pour détecter un événement empêchant un traitement de cette requête par le dispositif d'envoi ;
- des moyens pour envoyer au second dispositif une réponse SIP notifiant cet empêchement.
Le dispositif d'envoi selon l'invention est remarquable en ce qu'il comprend en outre des moyens pour activer dans la réponse SIP, avant son envoi au second dispositif, un paramètre autorisant un reroutage de la requête, et pouvant être configuré par le second dispositif.
Ainsi, l'invention ne propose plus, comme dans l'état actuel de la technique, d'associer à une réponse d'échec particulière, à savoir une réponse 503 « Service Unavailable », une possibilité de reroutage de la requête. Mais elle propose d'activer dans le message de réponse émis par le nœud ayant détecté un empêchement à traiter la requête d'appel (c'est- à-dire dans la réponse d'échec), en complément des informations usuelles de notification de la raison de l'empêchement, un paramètre additionnel indiquant qu'un reroutage de la requête par le nœud immédiatement en amont dans le chemin de la requête et recevant ce message, est autorisé et possible.
On notera que le terme paramètre est à considérer ici dans son sens général, en ce qu'il désigne un indicateur de reroutage, ou autrement dit, un élément indiquant qu'un reroutage est autorisé. Il peut s'agir d'un paramètre SIP tel que défini dans le document RFC 3261 intitulé « SIP : Session Initiation Protocol », édite par l'IETF, mais il peut également être porté par un entête SIP, par un champ d'un entête SIP, par un élément du corps de la réponse SIP, etc.
En outre, on entend au sens de l'invention, par activation d'un paramètre :
- l'insertion de ce paramètre dans la réponse SIP, de sorte qu'un nœud recevant ce message et capable d'interpréter le paramètre, identifie qu'un reroutage de la requête est autorisé du fait de la simple présence de ce paramètre dans la réponse ; et/ou - le positionnement de ce paramètre à une valeur prédéterminée, interprétée par le nœud comme autorisant le reroutage.
On utilisera indifféremment les termes activé ou actif, et désactivé ou inactif, pour désigner l'état du paramètre dans la réponse.
Ce paramètre peut avantageusement être configuré (i.e. être activé ou désactivé, avoir sa valeur modifiée, être maintenu en l'état, etc.) par le second nœud, autrement dit par le nœud, ou de façon équivalente par le dispositif, recevant la réponse SIP contenant le paramètre.
L'invention offre ainsi une plus grande flexibilité en termes de reroutage que les mécanismes actuellement implémentés dans le protocole SIP.
En effet, d'une part, la possibilité de reroutage n'est plus limitée à une cause particulière d'empêchement, ni au choix d'un type particulier de réponse notifiant l'empêchement (réponse d'échec SIP 503).
D'autre part, l'utilisation d'un paramètre configurable dans la réponse permet avantageusement d'activer et de désactiver facilement la possibilité de reroutage par un nœud recevant cette réponse, ce qui n'est pas permis actuellement par le protocole SIP.
En effet, dans les réseaux SIP actuels, lorsqu'un nœud reçoit une réponse d'échec 503, il ne peut en changer le type avant de la transmettre aux nœuds précédents. Par conséquent, chaque nœud du chemin reçoit la réponse d'échec 503 et, sur réception de cette réponse, peut tenter un reroutage de la requête d'appel. L'invention offre la liberté de pouvoir à tout moment supprimer cette possibilité, et limiter le reroutage de la requête au nœud précédant immédiatement le nœud en échec dans le chemin de la requête.
L'invention trouve ainsi un intérêt particulier dans les réseaux SIP où les acheminements sont complexes entre un nœud source (demandeur) et un nœud destinataire (demandé), c'est-à-dire notamment dans les réseaux dans lesquels le nombre de nœuds intermédiaires traversés par une requête SIP est important (i.e. supérieur à 2) et les chemins pouvant être empruntés par la requête sont multiples. Elle permet, dans ces réseaux, de limiter le nombre de reroutages inefficaces, par la mise en œuvre d'un traitement approprié par le nœud recevant le message comprenant le paramètre autorisant le reroutage. Dans un mode particulier de réalisation de l'invention, le procédé d'envoi comprend en outre, après l'étape de détection, une étape de vérification de la validité d'au moins un critère prédéterminé.
Ainsi, le reroutage de la requête peut être conditionné d'une part, par la détection d'un événement ou d'une situation empêchant un nœud du réseau de traiter la requête SIP, et d'autre part, par des critères supplémentaires liés par exemple à la cause ou à la nature de l'empêchement. Le choix d'autoriser le reroutage appartient donc au nœud ayant détecté l'empêchement.
Notamment, le paramètre ne pourra être activé (par exemple inséré) dans la réponse notifiant l'empêchement, que si celui-ci est dû à un défaut n'affectant que le premier nœud (manque de ressources, congestion, maintenance du premier nœud, etc.) et non l'ensemble des nœuds situés en aval et menant au destinataire de la requête.
En variante, on peut également considérer un critère lié à la capacité du nœud amont dans le chemin, auquel est envoyé la réponse SIP (second nœud), à traiter le paramètre se trouvant dans cette réponse.
De cette sorte, si le second nœud n'est pas apte à interpréter le paramètre comme autorisant un reroutage (par exemple parce qu'il n'a pas encore été mis à jour), le second nœud ne recevra pas ce paramètre et de ce fait, ne le transférera pas aux nœuds amont dans le chemin. Ces nœuds ne recevant pas de réponse comportant ce paramètre, ils ne tenteront pas de reroutage de la requête, qu'ils soient adaptés ou non à interpréter le paramètre.
Dans un mode de réalisation particulier, on vérifie la validité du critère lié à la capacité du second nœud à traiter le paramètre en utilisant une indication comprise dans la requête SIP et un identifiant du second nœud.
Ainsi, avantageusement, chaque nœud par lequel transite la requête SIP peut insérer, dans la requête, une indication selon laquelle il est adapté à interpréter le paramètre, ainsi qu'un identifiant, tel que son adresse IP. Une telle indication peut, par exemple, être insérée dans l'entête « Supported » de la requête SIP, connu de l'homme du métier. Le premier nœud peut alors s'assurer que cette indication émane bien du second nœud, c'est-à-dire du nœud placé juste en amont sur le chemin de la requête, en comparant l'identifiant se trouvant dans la requête et l'identifiant du second nœud dont il reçoit la requête (présent notamment dans l'en-tête « Via paramètre received »). Si le critère n'est pas vérifié, autrement dit, si le second nœud n'est pas adapté à interpréter le paramètre, le premier nœud n'active pas le paramètre dans la réponse SIP, de sorte à éviter tout reroutage inefficace par un nœud en amont du second nœud.
Dans un mode particulier de réalisation, une valeur du paramètre activé dans la réponse dépend d'une cause de l'empêchement.
De cette sorte, il est possible de renseigner le second nœud, pour qu'il soit en mesure de juger de la pertinence d'un reroutage de la requête SIP vers différents candidats potentiels.
Selon un second aspect, l'invention vise également un procédé de traitement d'une réponse SIP, mis en œuvre par un premier nœud d'un réseau de télécommunications après avoir transféré à un deuxième nœud du réseau une requête SIP reçue d'un troisième nœud, la réponse étant reçue du deuxième nœud et notifiant le premier nœud d'un empêchement d'un traitement de la requête par le deuxième nœud. Le procédé selon l'invention est remarquable en ce qu'il comprend :
- si la réponse reçue du deuxième nœud contient un paramètre activé (ou actif) autorisant un reroutage de la requête et pouvant être configuré par le premier nœud :
-une étape de recherche d'au moins un quatrième nœud vers lequel rerouter la requête ;
-une étape de reroutage de la requête vers ledit au moins un quatrième nœud, le cas échéant ; et
-si le premier nœud est notifié d'un empêchement d'un traitement de la requête par ledit au moins un quatrième nœud, une étape d'envoi au troisième nœud d'une réponse SIP notifiant celui-ci d'un empêchement d'un traitement de la requête, dans laquelle le paramètre est désactivé ;
- sinon, une étape de transfert de la réponse reçue du second nœud au troisième nœud.
Corrélativement, l'invention vise également un dispositif de traitement d'une réponse SIP d'un réseau de télécommunications, adapté à traiter ladite réponse après avoir transféré à un deuxième dispositif du réseau une requête SIP reçue d'un troisième dispositif, ladite réponse étant reçue du deuxième dispositif et notifiant ledit dispositif de traitement d'un empêchement d'un traitement de la requête par le deuxième dispositif, ledit dispositif de traitement étant caractérisé en ce qu'il comprend :
- des moyens, activés si la réponse reçue du deuxième dispositif contient un paramètre activé autorisant un reroutage de la requête et pouvant être configuré par ledit premier dispositif :
-pour rechercher au moins un quatrième dispositif vers lequel rerouter la requête ;
-pour rerouter la requête vers ledit au moins un quatrième dispositif, le cas échéant ; et
-des moyens, activés si en outre le dispositif de traitement est notifié d'un empêchement d'un traitement de la requête par ledit au moins un quatrième dispositif, pour envoyer au troisième dispositif une réponse SIP notifiant celui-ci d'un empêchement d'un traitement de la requête, dans laquelle le paramètre est désactivé ;
- des moyens activés sinon, pour transférer la réponse reçue du deuxième dispositif au troisième dispositif.
Ainsi, l'invention permet de limiter le reroutage au premier niveau en amont du nœud ayant détecté un empêchement à traiter la requête. Préférentiel lement, tout nœud recevant une réponse SIP de notification d'empêchement dans laquelle le paramètre est désactivé (par exemple une réponse SIP ne contenant pas ce paramètre), ne tentera pas de reroutage de la requête SIP.
De ce fait, si le premier nœud ne dispose pas de route alternative ou si le reroutage tenté échoue, alors il remontera une réponse SIP de notification d'empêchement en désactivant l'indication de possibilité de routage (par exemple, en la supprimant de la réponse qu'il a reçue du deuxième nœud). Le troisième nœud recevant cette réponse SIP, ne tentera pas de reroutage. De cette sorte, on limite les reroutages inefficaces et une charge inutile dans le réseau.
Les inventeurs ont par ailleurs constaté qu'une telle stratégie en termes de reroutage atteignait des performances similaires, voire meilleures, que celles atteintes aujourd'hui lorsqu'il est possible de rerouter la requête à tous les niveaux, et ce, avec une complexité bien inférieure. Dans un mode particulier de réalisation de l'invention, si l'étape de recherche ne permet pas d'identifier un quatrième nœud, le procédé de traitement comprend en outre :
- une étape de désactivation du paramètre dans la réponse reçue du deuxième nœud ; et
- une étape d'envoi de la réponse ainsi modifiée au troisième nœud.
Dans une variante de réalisation, lorsque la réponse reçue du deuxième nœud contient le paramètre activé, le procédé de traitement comprend en outre une étape de vérification de la validité d'au moins un critère prédéterminé, et, si ledit au moins un critère est valide, une étape d'envoi au troisième nœud d'une réponse SIP notifiant celui-ci d'un empêchement d'un traitement de la requête dans laquelle le paramètre est activé.
On se laisse ainsi la possibilité de tenter un reroutage par le troisième nœud dans certaines situations, telles que par exemple, lorsque la réponse SIP vient d'un nœud particulier, ou lorsque l'étape de recherche ne permet pas d'identifier un quatrième nœud. Autrement dit, dans ces situations identifiées par des critères prédéterminés, le paramètre autorisant le reroutage n'est pas désactivé par le premier nœud dans la réponse SIP, avant sa transmission au nœud amont (troisième nœud).
Dans l'exemple précité où l'étape de recherche ne permet pas d'identifier un quatrième nœud (i.e., le premier nœud ne dispose pas de chemin alternatif pour la requête), le troisième nœud pourra entreprendre un reroutage de la requête SIP, sur réception de la réponse SIP. Toutefois, le reroutage en cascade peut encore être évité, étant donné que le premier nœud ne dispose pas de route alternative et n'a donc pas entrepris lui-même de tentative de reroutage. Il suffira pour cela que le troisième nœud, en cas de reroutage(s) inefficace(s), désactive le paramètre contenu dans la réponse SIP avant de la transmettre vers les nœuds amont.
On notera que conformément à l'invention, un nœud recevant une réponse SIP notifiant un empêchement à traiter la requête dans lequel le paramètre est désactivé ou inactif (autrement dit, dans lequel il n'existe pas ou il a une valeur indiquant qu'un reroutage n'est pas autorisé), ne tentera pas de reroutage, mais remontera vers le nœud amont cette réponse SIP tel que reçue.
Selon un troisième aspect, l'invention vise un système d'un réseau de télécommunications comprenant au moins un équipement source et un équipement destinataire aptes à échanger une requête SIP, et une pluralité de nœuds intermédiaires par lesquels transite cette requête entre l'équipement source et l'équipement destinataire, ledit système étant caractérisé en ce qu'au moins un des nœuds intermédiaires du système est un dispositif d'envoi d'une réponse SIP notifiant un empêchement à traiter la requête conforme à l'invention et au moins un des nœuds intermédiaires du système est un dispositif de traitement de cette réponse conforme à l'invention.
Le système selon l'invention permet ainsi de limiter les reroutages inefficaces dans le réseau, et dispose des mêmes avantages que le dispositif de traitement et le dispositif d'envoi selon l'invention.
Dans un mode particulier de réalisation, au moins des nœuds intermédiaires comprend des moyens d'insertion dans la requête SIP d'une indication relative à sa capacité à traiter le paramètre, ces moyens étant activés avant l'envoi de la requête vers un autre nœud intermédiaire, ce nœud intermédiaire étant un dispositif d'envoi d'une réponse SIP conforme à l'invention comprenant en outre des moyens, activés après la détection d'un événement empêchant le traitement de la requête, de vérification de la validité d'un critère lié à cette capacité.
Dans un autre mode particulier de réalisation, l'équipement source comprend des moyens, activés s'il reçoit une réponse SIP contenant ledit paramètre activé :
- pour rechercher au moins un nœud intermédiaire vers lequel rerouter la requête ;
- pour rerouter la requête vers ledit au moins un nœud intermédiaire, le cas échéant ; et
- des moyens, activés si l'équipement source est en outre notifié d'un empêchement d'un traitement de la requête par ledit au moins un nœud intermédiaire, de notification d'un échec de traitement de la requête.
Ainsi l'invention vise également un procédé de traitement d'une réponse SIP, mis en œuvre par un équipement source d'un réseau de télécommunications, à l'origine d'une requête SIP transmise par l'équipement source à un nœud du réseau, la réponse SIP étant reçue de ce nœud et notifiant l'équipement source d'un empêchement d'un traitement de la requête par le nœud. Conformément à l'invention, ce procédé de traitement est remarquable en ce qu'il comprend, si la réponse contient un paramètre activé autorisant un reroutage de la requête :
- une étape de recherche d'au moins un autre nœud vers lequel rerouter la requête ;
- une étape de reroutage de la requête vers ledit au moins un autre nœud, le cas échéant ; et
- si l'équipement source est notifié d'un empêchement d'un traitement de la requête par ledit au moins un autre nœud, une étape de notification d'un échec de traitement de la requête.
La notification de l'échec de traitement de la requête peut être faite par exemple à l'usager de l'équipement source. En variante, si l'équipement source est une entité d'interfonctionnement de protocoles, cette notification peut être effectuée par l'interfonctionnement de la réponse d'empêchement de traitement vers un autre protocole. Selon un quatrième aspect, l'invention vise aussi, un signal comprenant une réponse SIP notifiant un empêchement d'un premier nœud à traiter une requête SIP envoyée par un second nœud, remarquable en ce que cette réponse SIP comporte un paramètre autorisant le reroutage de la requête, et pouvant être configuré par le second nœud.
Dans un mode particulier de réalisation, les différentes étapes du procédé d'envoi et du procédé de traitement sont déterminées par des instructions de programmes d'ordinateurs.
En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en œuvre dans un dispositif d'envoi ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en œuvre des étapes d'un procédé d'envoi d'un message SIP tel que décrit ci-dessus.
L'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en œuvre dans un dispositif de traitement ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en œuvre des étapes d'un procédé de traitement d'un message SIP tel que décrit ci- dessus.
Chaque programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
L'invention vise aussi un support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus.
Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy dise) ou un disque dur.
D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
Alternativement, le support d'informations 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.
On notera qu'on peut également envisager, dans d'autres modes de réalisation, que le procédé d'envoi, le procédé de traitement, le dispositif d'envoi, le dispositif de traitement et le système selon l'invention présentent en combinaison tout ou partie des caractéristiques précitées.
Brève description des dessins
D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures : - la figure 1, déjà décrite, représente un exemple d'une pluralité de reroutages inefficaces d'une requête SIP entrepris dans un réseau de télécommunications ;
- la figure 2 représente un exemple d'un système d'un réseau de télécommunications conforme à l'invention, dans un mode particulier de réalisation ;
- la figure 3 représente l'architecture matérielle d'un nœud du système représenté sur la figure 2 ;
- la figure 4 représente un exemple d'extraits de table de routage ;
- la figure 5 représente, sous forme d'ordinogramme, les principales étapes du procédé d'envoi d'une réponse SIP selon l'invention, dans un mode particulier de réalisation, et lorsqu'il est mis en œuvre par un nœud du système représenté sur la figure 2 ;
- la figure 6 représente, sous forme d'ordinogramme, les principales étapes du procédé de traitement d'un message selon l'invention, dans un mode particulier de réalisation, et lorsqu'il est mis en œuvre par un nœud du système représenté sur la figure 2 ;
- la figure 7 illustre un exemple d'application de l'invention. Description détaillée d'un mode de réalisation
La figure 2 représente, dans son environnement, un système 1 d'un réseau NW de télécommunications conforme à l'invention, dans un mode particulier de réalisation.
Le réseau NW est un réseau de voix sur IP (VoIP), s'appuyant sur le protocole de signalisation SIP. Ce protocole est connu de l'homme du métier et ne sera pas décrit plus en détails ici. De plus amples informations sur le protocole SIP sont disponibles dans le document RFC 3261, intitulé « SIP : Session Initiation Protocol » et édité par l'IETF.
Dans l'exemple envisagé ici, le réseau NW a une architecture constituée de plusieurs domaines distincts, à savoir les domaines Dl et D2. De façon générale, un domaine est un (sous-)réseau de télécommunications indépendant, tel que par exemple un réseau de VoIP géré par un opérateur de téléphonie fixe ou par un opérateur de téléphonie mobile, etc.
Les domaines Dl et D2 reposent tous deux ici sur une architecture IMS (IP Multimedia Subsystem), telle que spécifiée dans les standards de normalisation 3GPP et SPAN. De façon connue, une telle architecture s'appuie sur un cœur de réseau IMS (aussi appelé réseau cœur IMS), qui comprend plusieurs entités fonctionnelles telles que par exemple une entité CSCF (Call Session Control Function), une entité BGCF (Breakout Gateway Control Function), et des serveurs d'applications. Ces entités sont décrites plus en détails dans le document SPAN, « ES 282 007 IP Multimedia Subsytem (IMS) : Functional architecture NGN IMS Architecture », ETSI, Technical Report, 2006.
Ainsi, chaque domaine Dl et D2 comprend un réseau cœur IMS, noté respectivement IMS-1 et IMS-2, ainsi qu'une pluralité de terminaux clients (par exemple les terminaux Cl et C2), pouvant se connecter aux domaines Dl et D2 via les réseaux cœurs IMS-1 et IMS-2 selon divers réseaux d'accès.
Les domaines Dl et D2 sont en outre reliés entre eux et aux domaines externes (par exemple au réseau public Internet), par des équipements dits de bordure. Dans l'exemple décrit ici, pour des raisons de simplicité, on se limitera à deux éléments de bordure par domaine, à savoir BCS1-A, BCS1-B pour le domaine Dl et BCS2-A, BCS2-B pour le domaine D2. Pour atteindre les domaines externes, les éléments de bordure BCS1-A et BCS1-B peuvent être utilisés sans distinction dans le domaine Dl à partir du réseau cœur IMS-1. De même, les éléments de bordure BCS2-A et BCS2-B peuvent être utilisés sans distinction dans le domaine D2 à partir du réseau cœur IMS-2.
On notera que l'exemple décrit ici n'est donné qu'à titre illustratif et n'est en aucun cas limitatif. L'invention s'applique en effet à d'autres architectures de réseau, notamment constituée d'un seul domaine ou plus de deux domaines, gérés ou non par le même opérateur. En outre, ces domaines peuvent avoir une architecture différente, et il est possible de considérer un nombre différent d'éléments de bordure et/ou d'équipements IMS, ainsi que d'autres types d'équipements.
De façon connue dans un réseau SIP, une requête SIP émise par un équipement source vers un équipement destinataire, est véhiculée par un signal qui passe par de nombreux nœuds (i.e. équipements) du réseau.
Certains de ces nœuds ont des fonctions importantes à réaliser sur la requête SIP, comme par exemple la fourniture de services supplémentaires telle que la présentation du nom de l'équipement source. D'autres nœuds ont des rôles de transit uniquement ou d'interfonctionnement de protocoles, sans plus value à proprement parler sur le service, en dehors de l'acheminement de la requête et cette fonction d'interfonctionnement. On comprend aisément que ces nœuds peuvent être remplacés par d'autres nœuds ayant des fonctions identiques ou similaires.
Dans l'exemple envisagé ici, les équipements de bordure BCS1- A, BCSl-B, BCS2-A, BCS2-B et les réseaux cœur IMS-1 et IMS-2 sont des nœuds du système 1 du réseau de télécommunications NW, par lesquels transitent une requête SIP émise, par exemple, par le terminal client Cl (équipement source au sens de l'invention) à destination du terminal client C2 (équipement destinataire au sens de l'invention). Autrement dit, il s'agit d'entités du réseau NW capables de router une requête SIP vers sa destination. On utilisera indifféremment, dans la suite de la description, les termes nœud, équipement ou dispositif pour désigner les entités BCS1-A, BCSl-B, BCS2-A, BCS2-B, IMS-1 et IMS-2.
Pour des raisons de simplicité, on limitera la description de l'invention à ces six nœuds. Toutefois, bien entendu, d'autres nœuds pourraient être considérés, et notamment en nombre plus important.
En outre, dans l'exemple envisagé ici, on suppose que chacun de ces équipements, ou nœuds, est à la fois un dispositif d'envoi et un dispositif de traitement conformes à l'invention. Cette hypothèse n'est toutefois en aucun cas limitative. L'invention s'applique également dès lors qu'au moins deux nœuds successivement empruntés par la requête sont respectivement un dispositif de traitement et un dispositif d'envoi conformes à l'invention.
Chaque équipement du système 1 (i.e. BCS1-A, BCSl-B, BCS2- A, BCS2-B, IMS-1 et IMS-2) a ici l'architecture matérielle d'un ordinateur, telle que représentée sur la figure 3.
Ainsi, chaque équipement du système 1 comprend notamment un processeur 11, des moyens de communication 12 avec les autres équipements du réseau NW, et éventuellement avec des équipements externes au réseau, une mémoire vive 13, une mémoire morte 14, et une mémoire réinscriptible non volatile 15. La mémoire morte 14 comporte un programme informatique conforme à l'invention, adapté à exécuter les principales étapes du procédé d'envoi selon linvention représentées sur la figure 5 décrite ultérieurement, ainsi qu'un programme conforme à l'invention, adapté à exécuter les principales étapes du procédé de traitement selon l'invention représentées sur la figure 6 décrite ultérieurement.
La mémoire réinscriptible 15 comprend ici une table de routage au sein du réseau NW. Cette table de routage identifie le ou les nœuds vers le(s)quel(s) l'équipement peut router une requête SIP lui parvenant. Une telle table est connue de l'homme du métier et ne sera pas décrite plus en détails ici. Elle peut être prédéfinie en fonction de la topologie du réseau, ou en variante être déterminée et mise à jour à l'aide d'une procédure dynamique s'appuyant par exemple sur des annonces réseau émises par les divers nœuds du réseau.
Des exemples d'extraits de tables de routage sont donnés à la figure 4, pour les équipements IMS-1 (table RTI1) et BCS1-A (table RTB1). Par souci de simplicité, seuls les nœuds vers lesquels router les requêtes dans le sens Cl vers C2 ont été représentés. Ainsi, selon ces exemples :
- le réseau cœur IMS-1 peut router une requête SIP lui parvenant d'un client Cl, vers les éléments de bordure BCS1-A et BCS1-B ; et
- l'équipement de bordure BCS1-A peut router une requête SIP lui parvenant du réseau cœur IMS-1, vers les éléments de bordure BCS2-A et BCS2-B.
Nous allons maintenant décrire, en référence aux figures 5, 6 et 7, les principales étapes d'un procédé d'envoi et d'un procédé de traitement selon l'invention, lorsqu'ils sont mis en œuvre par des équipements du système représentés sur la figure 2, dans un mode particulier de réalisation de l'invention.
On suppose, dans l'exemple représenté sur la figure 7, que l'équipement de bordure BCS2-A est temporairement en surcharge : il n'est donc pas en mesure de traiter une requête SIP lui parvenant, et par conséquent de la transmettre au nœud suivant pour acheminement jusqu'à son destinataire. En revanche ici, aucun événement n'empêche les autres équipements de traiter les requêtes SIP qu'ils reçoivent. On suppose en outre qu'une requête S d'appel SIP est envoyée par le terminal client Cl à destination du terminal client C2, Cl et C2 étant ici des téléphones mobiles. Cette requête S est une demande d'établissement d'appel INVITE. Bien entendu, l'invention s'applique également à tout autre type de requêtes SIP, qu'il s'agisse notamment d'une requête ouvrant un dialogue (ex. INVITE ou SUBSCRIBE), d'une requête ouvrant une transaction au sein d'un dialogue (ex. ACK ou BYE) ou d'une requête ouvrant une transaction non liée à un dialogue (ex. OPTION).
La requête S transite tout d'abord par le nœud IMS-1. Sur réception de cette requête S (étape E10), le nœud IMS-1 vérifie sa capacité à la traiter (étape E20). Puis il exécute les fonctions qui lui sont associées sur la requête S, et stocke en mémoire une copie de la requête S éventuellement modifiée (étape E30).
Par souci de simplification dans la suite de la description, on désignera indifféremment par requête S, la requête initialement envoyée par le client Cl, ainsi que toute requête obtenue suite à l'application des fonctions associées aux nœuds par lesquels transite la requête S.
Après consultation de sa table de routage RTI1, le nœud IMS-1 transmet la requête S au nœud suivant, à savoir l'équipement de bordure BCS1-A (étape E40). On notera que la sélection d'un nœud parmi une pluralité de nœuds candidats au routage et contenus dans une table de routage est connue de l'homme du métier et ne sera pas décrite plus en détails ici.
De façon similaire, sur réception de la requête S (étape E10), le nœud BCS1-A vérifie sa capacité à la traiter (étape E20), exécute le cas échéant les fonctions qui lui sont associées, puis stocke en mémoire une copie de la requête S ainsi obtenue (étape E30). Après consultation de sa table de routage RTB1, il transmet la requête S au nœud suivant, à savoir l'équipement de bordure BCS2-A (étape E40).
Cette requête S est alors reçue par le nœud BCS2-A (étape E10), temporairement en surcharge.
Sur réception de la requête S, le nœud BCS2-A examine ses ressources et détecte qu'il ne dispose pas de ressources suffisantes pour traiter la requête S (étape E20). Par exemple, en raison d'un nombre trop important de requêtes à traiter, son processeur CPU est surchargé (événement empêchant le traitement de la requête au sens de l'invention).
En variante, d'autres événements ou situations peuvent empêcher le traitement d'une requête par le nœud BCS2-A. Par exemple, celui-ci peut détecter que toutes ses ressources IP sont prises par d'autres requêtes, ou que la ligne physique à emprunter pour transmettre la requête S au nœud suivant est inutilisable.
Conformément au protocole SIP, le nœud BCS2-A s'apprête à envoyer une réponse d'échec (ou d'erreur) au nœud BCSl-A, situé immédiatement en amont du nœud BCS2-A dans le chemin emprunté par la requête S et lui ayant transmis la requête S, afin de lui notifier son empêchement. On suppose ici que cette réponse d'échec est une requête « 480 Temporarily Unavailable». Elle constitue une réponse SIP notifiant un empêchement au sens de l'invention. Bien entendu, d'autres réponses d'échec ou d'erreur spécifiées par le protocole SIP pourraient être envisagées, comme par exemple la réponse d'échec 503.
Avantageusement selon l'invention, le nœud BCS2-A active au préalable dans la réponse d'échec 480, un paramètre noté P, indiquant qu'un reroutage par le nœud BCSl-A (et plus généralement, par tout nœud recevant la réponse dans laquelle le paramètre P est activé), est autorisé.
L'activation du paramètre P dans la réponse d'échec est conditionnée ici par la vérification d'au moins un critère supplémentaire en plus de la détection d'un événement empêchant le traitement de la requête S (étape E50). Il s'agit d'un critère c lié à la capacité du nœud BCSl-A auquel est envoyée la réponse d'échec à interpréter et à traiter le paramètre P. En variante, d'autres critères peuvent être vérifiés, comme par exemple un critère lié à la nature de l'empêchement, etc.
Dans l'exemple envisagé ici, de façon avantageuse, lorsqu'un nœud du chemin emprunté par la requête S sait interpréter et traiter le paramètre P conformément à l'invention, autrement dit, lorsqu'il met en œuvre le procédé de traitement selon l'invention, il insert dans la requête S, avant de la transmettre au nœud suivant (i.e., avant l'étape E40), un identifiant (tel que son adresse IP), ainsi qu'une indication selon laquelle il est capable de traiter le paramètre P. Cet identifiant et cette indication sont insérés ici dans l'entête « Supported » de la requête. De façon connue de l'homme du métier, cet entête indique, à l'aide d'identifiants spécifiques aussi appelés tags d'option (« option tags » en anglais), prédéfinis auprès de ΠΑΝΑ (Internet Assigned Number Authority), les différents services supportés par les nœuds par lesquels transite la requête. Une description des entêtes et des tags d'option déjà déclarés auprès de ΓΙΑΝΑ est présentée dans le document RFC 3261.
En variante, ils peuvent faire l'objet d'un nouvel entête de la requête SIP.
Ainsi, dans l'exemple envisagé ici, les n uds IMS-1 et BCS1-A, ont inséré, dans l'entête « Supported » de la requête S, leur adresse IP ainsi qu'une indication selon laquelle ils sont capables de traiter le paramètre P.
Pour déterminer si le critère c est vérifié, le nœud BCS2-
A examine, dans un premier temps, si la requête S comprend une indication selon laquelle un nœud du chemin emprunté jusqu'alors par la requête S met en œuvre le procédé de traitement selon l'invention.
Le cas échéant, le nœud BCS2-A compare l'identifiant du ou des nœuds associés à cette indication, à savoir ici, l'adresse IP du nœud BCS1- A et l'adresse IP du nœud IMS-1, avec l'identifiant du nœud dont il a reçu la requête, et qui est présent, conformément au protocole SIP, dans le paramètre « Received » de l'entête « Via » de la requête S. Cette comparaison a pour but de détecter dynamiquement, avant d'autoriser un reroutage, si le nœud ayant indiqué sa capacité à traiter le paramètre P est bien le nœud directement en amont du nœud BCS2-A, c'est-à-dire celui qui lui a transmis la requête S. De cette sorte, on se prémunit de la situation dans laquelle un nœud intermédiaire, non conforme à l'invention, se trouverait entre le nœud BCS2-A et le nœud BCS1-A, et ne ferait que retransmettre de façon transparente la requête S (autrement dit sans la modifier), sans que le nœud BCS2-A ne puisse le détecter.
Si les identifiants sont différents (i.e. l'identifiant du nœud dont il a reçu la requête ne coïncide pas avec l'un des identifiants associés aux nœuds capables de traiter le paramètre P), le nœud BCS2-A n'active pas le paramètre P dans la réponse d'échec mais la transmet telle quelle au nœud BCS1-A (étape E60). L'identifiant du nœud BCSl-A figurant ici dans l'entête Supported, le critère c est vérifié, et le nœud BCS2-A active dans la réponse d'échec 480 le paramètre P (étape E70).
Plus précisément, dans l'exemple envisagé ici, le nœud BCS2-A insère le paramètre P dans la réponse d'échec 480. Le paramètre P est inséré en tant que nouvel entête de la réponse d'échec. En variante, il peut s'agir d'un nouveau champ inséré dans un entête de la réponse d'échec ou d'un nouvel élément inséré dans le corps de la réponse d'échec.
L'insertion du paramètre dans la requête constitue une activation de ce paramètre au sens de l'invention. Avantageusement, la valeur du paramètre P ainsi inséré peut dépendre de la cause ou de la nature de l'empêchement. Par exemple et à titre illustratif uniquement :
P=l en cas de surcharge,
P=2 en cas de ligne inutilisable.
La réponse d'échec 480 comprenant le paramètre P est alors envoyée au nœud BCSl-A (étape E80). Cette réponse est transportée sur le réseau dans un signal conforme à l'invention.
En variante, la vérification du critère c peut être réalisée à l'aide d'une liste statique préconstituée, et mémorisée au niveau du nœud BCS2-A, cette liste comprenant les identifiants des nœuds du réseau NW mettant en œuvre le procédé de traitement selon l'invention. Cette liste devra toutefois être mise à jour au gré des changements affectant les nœuds, tels que par exemple des changements de version logicielle des nœuds ou de topologie du réseau.
En référence à la figure 6, sur réception de la réponse d'échec 480 (étape F10), le nœud BCSl-A détermine si celle-ci contient le paramètre P lui autorisant un reroutage (i.e. si le paramètre P est activé dans la réponse d'échec reçue) (étape F20).
Si la réponse d'échec 480 ne contient pas le paramètre P, alors le nœud BCSl-A transmet cette réponse au nœud immédiatement en amont (identifié dans l'entête Via de la requête S), sans tenter de reroutage de la requête S (étape F30).
La réponse d'échec 480 contenant ici le paramètre P, le nœud BCSl-A recherche alors, dans sa table de routage, une autre route pour la requête S (étape F40), c'est-à-dire un nœud distinct du nœud BCS2-A, vers lequel rerouter la requête SIP S.
Si aucun nœud alternatif n'a pu être identifié au cours de cette étape de recherche (étape F50), le nœud BCS1-A supprime ici le paramètre P de la réponse d'échec 480 et transmet la requête ainsi modifiée au nœud immédiatement en amont (c'est-à-dire au nœud IMS- 1), sans tenter de reroutage de la requête S (étape F30). La suppression du paramètre P constitue une étape de désactivation du paramètre P au sens de l'invention.
En variante, dans un autre mode de réalisation, le nœud BCS2-A n'ayant pu entreprendre de reroutage de la requête du fait de l'absence de route alternative, transmet la réponse d'échec avec le paramètre P au nœud IMS-1. Celui-ci tentera alors, sur réception de la réponse d'échec avec le paramètre P, un reroutage de la requête SIP, et supprimera le paramètre P en cas d'échec du reroutage afin d'éviter des reroutages en cascade.
Ainsi, conformément à l'invention, le paramètre P peut avantageusement être configuré par le nœud recevant la réponse d'échec, de sorte à adapter les stratégies de reroutage de la requête S notamment à la topologie du réseau et à l'état des nœuds du réseau.
La recherche d'un nœud alternatif constitue en soi une vérification d'un critère prédéterminé au sens de l'invention (i.e. présence d'un nœud alternatif pour rerouter la requête). D'autres critères peuvent en variante être envisagés avant de décider la désactivation du paramètre P dans la réponse, comme notamment, la détection d'un nœud particulier. Ces critères sont destinés à identifier certaines situations dans lesquelles, il peut être pertinent de tenter un reroutage par un nœud situé en amont.
Si au moins un nœud alternatif (i.e. un candidat potentiel pour le reroutage) a pu être identifié par le nœud BCS2-A (étape F50) au cours de l'étape de recherche, une opération de reroutage de la requête S, préalablement stockée par le nœud BCS1-A, est entreprise par le nœud BCS1-A à destination du nœud alternatif identifié (étape F60). Cette étape est mise en œuvre selon des mécanismes connus de l'homme du métier et non décrits davantage ici. Il en est de même du choix du nœud parmi les candidats au routage en cas de pluralité de candidats disponibles. Dans l'exemple envisagé ici (cf. figure 4), le n ud BCS1-A détermine que le nœud BCS2-B est un candidat potentiel pour le reroutage.
Deux cas de figure peuvent alors être rencontrés (étape F70) : - soit la requête S est traitée par le nœud BCS2-B : elle est alors transmise au nœud IMS-2 pour acheminement jusqu'au client C2 (étape F80) ;
- soit, suite au reroutage vers le nœud BCS2-B, le nœud BCS1-A reçoit une nouvelle réponse d'échec, envoyée cette fois-ci par le nœud vers lequel le reroutage a été opéré (i.e. le nœud BCS2-B) (étape F70) : un nouveau candidat potentiel pour le reroutage, identifié au cours de l'étape de recherche F40, est alors considéré et les étapes F60-F90 sont reprises.
Si toutefois tous les nœuds candidats identifiés à l'étape de recherche ont été testés (étape F90) et ont transmis au nœud BCS1-A une réponse d'échec notifiant un empêchement à traiter la requête S, le nœud
BCS1-A supprime le paramètre P de la réponse d'échec 480 reçue précédemment (étape F100). Cette étape de suppression est une étape de désactivation du paramètre P au sens de l'invention.
Il envoie ensuite la réponse d'échec 480, sans le paramètre P, au nœud immédiatement en amont et dont il a reçu la requête S, à savoir le nœud IMS-1 (étape F110).
Celui-ci recevant la réponse d'échec sans le paramètre P, ne tente pas de reroutage de la requête, mais relaye la réponse d'échec telle quelle jusqu'au client Cl.
On notera que dans l'exemple envisagé ici, le nœud BCS-IA n'est pas le nœud à l'origine de la requête SIP S, i.e., il a reçu cette requête du nœud IMS-1A, qui lui-même a reçu la requête du nœud Cl. Si l'on suppose dans un autre exemple, que le nœud BCS-IA est le nœud à l'origine de la requête S, et que toute tentative de reroutage entreprise par le nœud BCS-IA suite à la réception de la réponse 480 échoue, alors le nœud BCS-IA notifie cet échec aux entités impactées par l'échec de la transmission de la requête S.
On notera en outre, que dans le mode de réalisation décrit ici, le paramètre P est désactivé dans la réponse d'échec SIP 480 transmise par le nœud BCS-2A au nœud BCS-IA, avant son envoi au nœud IMS-1.
Toutefois, de façon équivalente, le nœud BCS-IA peut désactiver le paramètre P (autrement dit ici, ne pas l'insérer) dans la réponse d'échec SIP reçue du nœud BCS-2B à l'étape E70, et transférer cette réponse vers le nœud IMS-1. En variante, il peut également désactiver ce paramètre dans une nouvelle réponse d'échec SIP qu'il transmet au nœud IMS-1.

Claims

REVENDICATIONS
1. Procédé d'envoi d'une réponse SIP par un premier nœud (BCS2-A) d'un réseau de télécommunications, comprenant :
- une étape de réception (E10) par le premier nœud (BCS2-A) d'une requête SIP (S) envoyée par un second nœud (BCS1-A) du réseau ;
- une étape de détection (E20) d'un événement empêchant un traitement de cette requête par le premier nœud ;
- une étape d'envoi (E80) au second nœud d'une réponse SIP notifiant cet empêchement ;
ledit procédé étant caractérisé en ce qu'il comprend en outre, avant l'étape d'envoi, une étape d'activation (E70) dans la réponse SIP d'un paramètre (P) autorisant un reroutage de la requête et pouvant être configuré par le second nœud.
2. Procédé de transmission selon la revendication 1 caractérisé en ce qu'il comprend en outre, après l'étape de détection (E20), une étape de vérification (E50) de la validité d'au moins un critère prédéterminé.
3. Procédé de transmission selon la revendication 2, caractérisé en ce qu'au cours de l'étape de vérification (E50) on considère un critère lié à une cause de l'empêchement.
4. Procédé de transmission selon la revendication 2, caractérisé en ce qu'au cours de l'étape de vérification (E50) on considère un critère lié à une capacité du second nœud à traiter le paramètre.
5. Procédé de transmission selon la revendication 4, caractérisé en ce qu'on vérifie la validité du critère lié à la capacité du second nœud à traiter le paramètre en utilisant une indication comprise dans la requête SIP et un identifiant du second nœud.
6. Procédé de transmission selon la revendication 1, caractérisé en ce qu'une valeur dudit paramètre dépend d'une cause de l'empêchement.
7. Programme d'ordinateur comportant des instructions pour l'exécution des étapes du procédé d'envoi selon la revendication 1 lorsque ledit programme est exécuté par un ordinateur.
8. Procédé de traitement d'une réponse SIP, mis en œuvre par un premier nœud (BCS1-A) d'un réseau de télécommunications après avoir transféré à un deuxième nœud (BCS2-A) du réseau une requête SIP (S) reçue d'un troisième nœud (IMS-1), ladite réponse étant reçue (F10) du deuxième nœud (BCS2-A) et notifiant le premier nœud (BCS1-A) d'un empêchement d'un traitement de la requête par le deuxième nœud, ledit procédé étant caractérisé en ce qu'il comprend :
- si la réponse reçue du deuxième nœud contient un paramètre activé (P) autorisant un reroutage de la requête et pouvant être configuré par le premier nœud (F20) :
-une étape de recherche (F40) d'au moins un quatrième nœud vers lequel rerouter la requête ;
-une étape de reroutage (F60) de la requête (S) vers ledit au moins un quatrième nœud (BCS2-B), le cas échéant ; et
-si le premier nœud (BCS1-A) est notifié (F70) d'un empêchement d'un traitement de la requête (S) par ledit au moins un quatrième nœud (BCS2-B), une étape d'envoi (F110) au troisième nœud (IMS-1) d'une réponse SIP notifiant celui-ci d'un empêchement d'un traitement de la requête, dans laquelle ledit paramètre est désactivé (F100) ;
- sinon, une étape de transfert (F30) de la réponse reçue du second nœud (BCS2-A) au troisième nœud (IMS-1).
9. Procédé de traitement selon la revendication 8 comprenant en outre, si l'étape de recherche (F40) ne permet pas d'identifier un quatrième nœud :
- une étape de désactivation dudit paramètre dans la réponse reçue du deuxième nœud ; et
- une étape d'envoi de la réponse ainsi modifiée au troisième nœud.
10. Procédé de traitement selon la revendication 8 comprenant en outre, lorsque ladite réponse reçue du deuxième nœud contient ledit paramètre activé, une étape de vérification de la validité d'au moins un critère prédéterminé, et, si ledit au moins un critère est valide, une étape d'envoi au troisième nœud (IMS-1) d'une réponse SIP notifiant celui-ci d'un empêchement d'un traitement de la requête, dans laquelle ledit paramètre est activé (F100).
11. Programme d'ordinateur comportant des instructions pour l'exécution des étapes du procédé de traitement selon la revendication 8 lorsque ledit programme est exécuté par un ordinateur.
12. Dispositif d'envoi d'une réponse SIP (BCS2-A) dans un réseau de télécommunications comprenant :
- des moyens pour recevoir une requête SIP (S) envoyée par un second dispositif (BCSl-A) du réseau ;
- des moyens pour détecter un événement empêchant un traitement de cette requête (S) par ledit dispositif d'envoi (BCS2-A);
- des moyens pour envoyer au second dispositif (BCSl-A) une réponse SIP notifiant cet empêchement ;
ledit dispositif d'envoi étant caractérisé en ce qu'il comprend en outre des moyens pour activer dans la réponse SIP, avant son envoi audit second dispositif (BCSl-A), un paramètre (P) autorisant un reroutage et pouvant être configuré par le second dispositif.
13. Dispositif de traitement (BCSl-A) d'une réponse SIP d'un réseau de télécommunications, adapté à traiter ladite réponse après avoir transféré à un deuxième dispositif (BCS2-A) du réseau une requête SIP (S) reçue d'un troisième dispositif (IMS-1), ladite réponse étant reçue du deuxième dispositif (BCS2-A) et notifiant ledit dispositif de traitement (BCSl-A) d'un empêchement d'un traitement de la requête (S) par le deuxième dispositif (BCS2-A), ledit dispositif de traitement étant caractérisé en ce qu'il comprend :
- des moyens, activés si la réponse reçue du deuxième noeud contient un paramètre activé (P) autorisant un reroutage de la requête et pouvant être configuré par ledit deuxième dispositif :
-pour rechercher au moins un quatrième dispositif vers lequel rerouter la requête (S) ; -pour rerouter la requête vers ledit au moins un quatrième dispositif (BCS2-B), le cas échéant ; et
-des moyens, activés si en outre le dispositif de traitement (BCS1-A) est notifié d'un empêchement d'un traitement de la requête par ledit au moins un quatrième dispositif (BCS2-B), pour envoyer au troisième nœud (IMS-1) une réponse SIP notifiant celui-ci d'un empêchement d'un traitement de la requête, dans laquelle ledit paramètre est désactivé ;
- des moyens activés sinon, pour transférer la réponse reçue du second dispositif (BCS2-A) au troisième dispositif (IMS-1).
14. Système d'un réseau de télécommunications comprenant au moins un équipement source (Cl) et un équipement destinataire (C2) aptes à échanger une requête SIP (S), et une pluralité de nœuds intermédiaires (IMS-1,IMS-2,BCS1-A,BCS2-A,BCS1-B,BCS2-B) par lesquels transite cette requête entre l'équipement source et l'équipement destinataire, ledit système étant caractérisé en ce qu'au moins un desdits nœuds intermédiaires (BCS2-A) du système est un dispositif d'envoi conforme à la revendication 12 et au moins un desdits nœuds intermédiaires (BCS1-A) du système est un dispositif de traitement conforme à la revendication 13.
15. Signal comprenant une réponse SIP notifiant un empêchement par un premier nœud à traiter une requête SIP (S) envoyée par un second nœud, caractérisé en ce que ladite réponse comporte un paramètre autorisant un reroutage de ladite requête et pouvant être configuré par le second nœud.
PCT/FR2010/052597 2009-12-04 2010-12-02 Procédés d'envoi et de traitement d'une reponse sip WO2011067540A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US13/513,535 US8804498B2 (en) 2009-12-04 2010-12-02 Methods for sending and processing an SIP response
EP10807455.0A EP2507970B1 (fr) 2009-12-04 2010-12-02 Procédés d'envoi et de traitement d'une réponse sip

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0958666 2009-12-04
FR0958666 2009-12-04

Publications (1)

Publication Number Publication Date
WO2011067540A1 true WO2011067540A1 (fr) 2011-06-09

Family

ID=42112278

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2010/052597 WO2011067540A1 (fr) 2009-12-04 2010-12-02 Procédés d'envoi et de traitement d'une reponse sip

Country Status (3)

Country Link
US (1) US8804498B2 (fr)
EP (1) EP2507970B1 (fr)
WO (1) WO2011067540A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11108911B2 (en) * 2018-07-17 2021-08-31 Avaya Inc. System and method for flexible routing

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1528818A2 (fr) * 2003-10-28 2005-05-04 AT&T Corp. Contrôle de la congestion dans un réseau IP
WO2009086935A1 (fr) 2008-01-10 2009-07-16 Telefonaktiebolaget Lm Ericsson (Publ) Traitement de message dans un réseau de communications
US20090196183A1 (en) 2008-02-06 2009-08-06 Cellco Partnership D/B/A Verizon Wireless Optimized sip routing architecture using an integrated network and systems approach

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7660297B2 (en) * 2002-06-13 2010-02-09 Nice Systems Ltd. Voice over IP forwarding
US8014299B2 (en) * 2006-05-22 2011-09-06 Alcatel Lucent Method and apparatus for detecting forwarding loops
US20080013447A1 (en) * 2006-07-14 2008-01-17 Lauber Pamela J Method and Apparatus for Survivable Failover in Communication System
JP2008104112A (ja) * 2006-10-20 2008-05-01 Fujitsu Ltd 送信経路設定装置、送信経路設定方法および送信経路設定プログラム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1528818A2 (fr) * 2003-10-28 2005-05-04 AT&T Corp. Contrôle de la congestion dans un réseau IP
WO2009086935A1 (fr) 2008-01-10 2009-07-16 Telefonaktiebolaget Lm Ericsson (Publ) Traitement de message dans un réseau de communications
US20090196183A1 (en) 2008-02-06 2009-08-06 Cellco Partnership D/B/A Verizon Wireless Optimized sip routing architecture using an integrated network and systems approach

Also Published As

Publication number Publication date
US20120250497A1 (en) 2012-10-04
US8804498B2 (en) 2014-08-12
EP2507970B1 (fr) 2020-06-17
EP2507970A1 (fr) 2012-10-10

Similar Documents

Publication Publication Date Title
EP2772035B1 (fr) Procede de gestion d'une communication destinee a un utilisateur et serveur d'application
EP2080339A1 (fr) Procede de routage d'un message sip en cas d'indisponibilite de noeuds intermediaires
EP1921819A1 (fr) Marqueur pour systèmes de communication composés d'une pluralité de serveurs SIP
EP2769526B1 (fr) Procédé d'échange d'informations relatives à des services de communication enrichie
EP2504982B1 (fr) Procede de basculement d'un hss primaire sur un hss de secours dans un reseau ip
WO2006108989A2 (fr) Procede de lutte contre l'envoi d'information vocale non sollicitee
EP1868346B1 (fr) Détection de boucles au sein d'un élement intermédiaire de signalisation SIP
WO2008037921A1 (fr) Routeur coeur apte a securiser un routeur de sortie d'un systeme autonome
EP2396950B1 (fr) Procede et systeme de gestion de la signalisation dans un reseau de telecommunications
EP2926524B1 (fr) Routage d'une requête de service visant un abonné ims
EP2507970B1 (fr) Procédés d'envoi et de traitement d'une réponse sip
EP2856732A1 (fr) Procédé et entité de traitement d'un message
WO2017203118A1 (fr) Procédé de repli dans un réseau de télécommunication
EP2786546A1 (fr) ENREGISTREMENT D'UN DISPOSITIF AUPRES D'UN COEUR DE RESEAU VoIP
FR3103921A1 (fr) Procédé de coordination de la mitigation d’une attaque informatique, dispositif et système associés.
WO2021123659A1 (fr) Procede d'acheminement de messages, equipement reseau associe
WO2014170582A1 (fr) Procede de restauration de service dans un reseau ims
FR3044195A1 (fr) Procede et dispositif de traitement d'une annonce non legitime d'un bloc d'adresses ip
EP2801178B1 (fr) Procédé dynamique de détermination d'une liste de services dans un réseau sip
FR3103920A1 (fr) Procédé d’assistance pour la gestion d’une attaque informatique, dispositif et système associés.
WO2013156727A1 (fr) Procede de traitement d'un message, entite et cœur de reseau
WO2009030869A2 (fr) Procede et dispositif pour gerer le desenregistrement d'un terminal aupres d'une entite dans un reseau de telecommunications
FR2958820A1 (fr) Routage de requetes sip
FR2909501A1 (fr) Procede et systeme de telecommunication permettant a au moins deux utilisateurs distinct d'acceder a un meme ensemble d'informations
WO2012117178A1 (fr) Procédé de gestion d'identites publiques par un utilisateur d'un reseau ims

Legal Events

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

Ref document number: 10807455

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 13513535

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2010807455

Country of ref document: EP