Patent Application
20090187664
The invention lies in the field of telecommunications, and more particular in that of telephony over IP.
Networks complying with a communication protocol called IP (an abbreviation well known to those skilled in the art standing for Internet Protocol) are being used with increasing frequency as universal media for a multitude of services and applications. This IP protocol has played a federating role with many operators who have chosen this protocol to share hitherto disparate service offerings.
IPv4 is a version of the IP communication protocol that has been used for years.
To satisfy the constraints imposed by such communication services, and more particularly to respond to the increasing needs in terms of addresses, operators and manufacturers of network equipment have joined together to specify a new generation communication protocol, commonly called IPv6, defined by specifications and analysis documents that are at a sufficiently advanced development stage to make it possible now to envisage an operational deployment in the operators' networks.
Nevertheless, the introduction of this new protocol generation poses significant problems associated with a need to ensure interoperability and interworking of the IPv6 protocol and the IPv4 protocol which is already deployed in the IP networks.
In the transport layer, mechanisms have been proposed and even standardized at the IETF (an abbreviation well known to those skilled in the art standing for Internet Engineering Task Force) such as a technique called NAT-PT and various techniques known as “tunneling” and consisting in encapsulating IPv6 data in IPv4 datagrams or vice versa.
In addition, upgrades and adaptations of service architectures and platforms are necessary to allow interworking between clients situated in IP environments of different types (IPv4 or IPv6) in as transparent a manner as possible for the end client.
Amongst its multimedia activities, the IETF has standardized a protocol called SIP (an abbreviation well known to those skilled in the art standing for Session Initiation Protocol) offering as its main functions the initiation, modification and termination of multimedia sessions. The SIP protocol is an interesting example of an application of the present invention. The SIP protocol uses an SDP protocol (an abbreviation well known to those skilled in the art standing for Session Description Protocol) to produce a description of parameters associated with the session concerned. Once a negotiation has been successful between two parties participating in a call, the latter may interchange media streams thanks to an activation of an RTP (an abbreviation well known to those skilled in the art standing for Real Time Transport Protocol) protocol. RTP session parameters are prenegotiated via SIP signaling messages, notably in the SDP portion. These parameters are mainly termination addresses and port numbers that will be used on either side.
Since the first version of the SIP protocol described in a document referenced RFC 2543 (RFC meaning “Request For Comment”), the latter has supported the IPv6 protocol. An implementation complying with RFC 2543 or with its update RFC3261 in principle easily decodes addresses that conform to the IPv4 and IPv6 protocols. Such an address may be inserted in a specific field such as a “CONTACT” header or in headers of the SDP portion. However, the presence of such addresses may prevent the setting-up of SIP calls if the two terminals cannot be reached in one and the same IP environment, that is, if one has an IPv4 address and the other an IPv6 address. Thus, when a user agent of IPv4 type A initiates an SIP session to a user agent of IPv6 type that is registered with an IPv4 location server (marked R hereinafter), the interchange of SIP messages produced is described in figure la, where a first user agent A wishing to make contact with a second user agent B sends an “INVITE” message to a proxy server (marked PS hereinafter) by using an IPv4 address specific to the latter. The proxy server PS is in this instance a server attached to an exclusively IPv4 environment. Once the message is received by the proxy server PS, the latter makes a request to a location server also called a registration server and thereby retrieves the address of the second under agent B. Since this address can be assumed to be an IPv6 address, the proxy server PS does not know any route to this destination because this proxy server PS is exclusively of the IPv4 type. An error message is then sent to the user agent A stating that it is impossible to set up an SIP session between the first and second user agents A and B. This error message is marked (2)404 “No Route” in
If it is now supposed that the proxy server PS can nevertheless reach the location address of the first user agent A and that of the user agent B, another interchange of SIP messages is observed, when the second user agent B tries to call the first user agent A, as represented in
In this situation, the proxy server PS routes an “INVITE” message received from the second user agent B to the location address of the first user agent A. This “INVITE” message contains an SDP offer describing, in addition to the capabilities offered by the first user agent B in terms of CODEC (for coder/decoder), an RTP port number and an address that the second user agent B will use to transmit/receive RTP streams. In the situation of
A coexistence of IP addresses of different types could affect calls other than those that have been the subject of the graphic representation described above. Thus, calls to clients of the DS IP type (DS being an abbreviation well known to those skilled in the art standing for Dual Stack), may also not culminate in media stream interchanges, the user agents of the DS type being capable of processing both IPv4 and IPv6 address types. This is due to the fact that the basic SIP protocol allows only a single IP address to be entered for transmitting or receiving media streams. To alleviate this problem, documents referenced RFC 4092 and RFC 4091 introduce a new semantic element consisting, amongst other things, in defining an indicator denoted “sdp-anat”. This new semantic element allows a user agent to announce and/or discover one or more address types. Therefore, user agents of the dual stack type are able to indicate in their SDP offer both their IPv4 and IPv6 addresses. Thanks to this technique, all calls from/to a user agent of the DS type to single-version clients (i.e. compatible with the IPv4 protocol only or with the IPv6 protocol only) may give rise to successful SIP sessions.
If two nodes forming ends of a communication link intended to carry a given call are single-version, the SIP telephony service operator concerned may make use of ALG (an abbreviation well known to those skilled in the art standing for Application Layer Gateway) applications, to modify the SDP offers in order to ensure consistency between the address type supported and that contained in the SIP messages received. To do this the SIP servers use information relating to the transport layer and not specific to the SIP protocol to route the calls or to determine use of ALG applications to alter the content of the SDP offers. Such a behavior of the SIP servers is not described in the standard.
Generally, the problem associated with the interconnections of two heterogeneous user agents (that is to say user agents of distinct IP types) has not been studied in detail by the telecommunications community. Except for the ANAT proposal described by (RFC 4091, RFC 4092) which resolves part of the problem, there is in particular no IETF document describing the behavior of the SIP servers to route calls connecting two user agents belonging to different IP environments.
In addition, the existing techniques have the following disadvantages:
The work carried out by the inventors has led the latter to conclude that, notwithstanding a need that emerges from the foregoing study, there exists in the prior art no arrangement with which to enable a communication means belonging to a communication network conforming to an IP protocol to simply and generically identify the IP address type associated with a given user agent, such an omission explaining why most of the techniques for managing communications between heterogeneous nodes currently being studied are inadequate and do not meet the service needs consisting in allowing heterogeneous communications.
The object of the present invention is to remedy the disadvantages and limitations of the current techniques, taking account of the joint presence of IPv4, IPv6 or IP ISO communication protocols defined by the ISO 8473 standard in IP networks.
More specifically, an object of the invention is to allow the SIP servers to know the IP type of user agents seeking to communicate, in order to allow the successful setting-up of sessions between these agents, whether or not they are of the same type, to facilitate the routing of the calls and to optimize the usage of IP addresses.
According to the invention explained in the present patent application, consideration is given, as a single example, to telephony over IP usually called VOIP for Voice Over IP or usually grouped under the topic of interactive services.
The invention addresses the general issue of transmission services based on the SIP protocol defined by RFC 3261 and deployed both for IPv4 clients and IPv6 clients. These services may be voice, video, presence, etc. services.
The invention proposes a simple mechanism to facilitate the setting-up of SIP sessions between two clients or SIP nodes that are heterogeneous, one attached to an IPv4 domain and the other to an IPv6 domain for example.
Consequently, the subject of the present invention is notably the implementation of an SIP server addressing method for the interworking of heterogeneous SIP nodes making it possible to allocate resources to the SIP servers for recognizing the IP type of the user agents UA. “IP type of a user agent” means the IP protocol version or versions (for example IPv4, IPv6) that this user agent is capable of implementing by means of the network interface(s) that the SIP node that houses it has available. Heterogeneous SIP nodes are therefore SIP nodes that comprise user agents of different IP types.
Another subject of the present invention is also the implementation of an SIP server addressing method for the interworking of heterogeneous SIP nodes making it possible to simplify and therefore facilitate call routing.
Another subject of the present invention is, finally, the implementation of an SIP server addressing method making it possible to optimize the use of IP addresses.
The SIP server addressing method for the interworking of heterogeneous SIP nodes of a first respectively of a second IP type, the subject of the invention, is notable in that it includes at least the allocation to any SIP server, operating in an IP environment of one or the other IP type and furnished with a original address of determined IP type, of an auxiliary address of the same IP type as the original address type and corresponding to a communication address of distinct IP type, the provision, as call address, to any SIP node of the same IP type as this SIP server, of this original address in this IP environment and to any SIP node, of an IP type other than the IP type of this SIP server, of this communication address, the translation of this communication address of one or the other IP type into this auxiliary address of the same IP type as the IP type of this original address.
The operating mode of the addressing method that is the subject of the invention makes it possible to ensure the intercommunication of any SIP node from an IP environment of an IP type corresponding to that of the SIP servers or of a distinct IP type.
The addressing method that is the subject of the invention is also notable in that this communication address is configured as a DNS input of the IP environment of IP type distinct from that of this SIP server.
The invention also covers a method of communication between at least one server operating in an environment of determined IP type and at least one node of the network, this node being of the same IP type or of IP type distinct from the determined IP type.
This communication method is notable in that it comprises the following steps: allocation to the server of at least two addresses in the environment of determined IP type, comprising an address called original address and an address called auxiliary address, with which is associated, by translation, a communication address in an environment of IP type distinct from the determined IP type, provision to this node, as call address of the server, of this original address, if the node is of the same IP type as the determined IP type, respectively of this communication address, if the node is of the IP type distinct from the determined IP type, and, on a call to this server by this node, discrimination of the IP type of this node according to the source or auxiliary address of the server on which this call is received.
The communication method that is the subject of the invention is also notable in that, the server being a registration server, this method also comprises a step of registration of the node according to the discriminated IP type in at least one database.
The method that is the subject of the invention is also notable in that this registration server maintains at least two databases comprising respectively the nodes of the same IP type as the determined IP type and the nodes of IP type distinct from the determined IP type. The addresses stored in these databases are of the same type as that of the proxy server.
The communication method that is the subject of the invention is also notable in that, the node having at least two IP types, namely the determined IP type and at least one IP type distinct from this determined IP type, this method comprises a step of transmission by this node of a registration request to the original address of the registration server, and a step of transmission by this node of at least one registration request to the communication address of the server, intended to be received after translation to the auxiliary address of the server.
The communication method that is the subject of the invention is also notable in that, the server being a proxy server and the call to the proxy server by the node implementing a transmission to the proxy server of a call request from the calling node to a called node, this method also comprises a first step of transmission from the proxy server to the registration server of a request for the IP type of the called node, a second step of transmission from the registration server to the proxy server of the IP type of the called node registered in the database and of an address of the called node and a step of routing of this call from the calling node to the called node, according to the IP type of the calling node discriminated by the proxy server and of the IP type of the called node transmitted by the registration server.
The method that is the subject of the invention is finally notable in that, during the second transmission step, the address of the called node transmitted by the registration server is an address in the environment of determined IP type in which the proxy server operates.
The communication method that is the subject of the invention is also notable in that, during the execution of the registration step, for any SIP node of determined IP type, the IP address registered for said node in the database by the registration server is systematically of the same IP type as the proxy server used by the service, this being so in order to ensure the subsequent use of said address by said proxy server and in particular for the routing of the call.
The invention also covers an SIP registration server operating in an IP environment of determined IP type in the presence of another IP environment of distinct IP type and comprising input-output members connected to a central processor unit and to a working memory, notable in that it comprises, in addition to a source IP address, an auxiliary IP address of IP type corresponding to this IP environment, means for discriminating the IP type of any SIP node effecting a registration according to the source respectively communication call address corresponding to this auxiliary address used by this SIP node, in a registration request transmitted to this SIP registration server, first and second registration database means of each candidate SIP node, corresponding to an SIP node of the same IP type as the IP type of this SIP registration server whose call address is the source address of the latter, respectively of IP type distinct from the IP type of this SIP registration server, whose call address is the auxiliary address of this SIP registration server by means of this communication address.
Finally, the invention covers an SIP proxy server operating by transmission of a request to call a called SIP node by a calling SIP node, of determined type that is identical or distinct, in an IP environment of determined IP type in the presence of another IP environment of distinct IP type, this SIP proxy server comprising input/output members connected to a central processor unit and to a working memory.
It is notable in that it includes, in addition to a source IP address corresponding to this IP environment of determined IP type, an auxiliary address of the same IP type as the IP type of the source address, discrimination means, based on the call request of the IP type from any calling SIP node, according to the call address which may be either the original address or an auxiliary address of this SIP proxy server which corresponds to the initial call address, means for discrimination, by an SIP registration server that is the subject of the aforementioned invention, of the IP type of the called SIP node, and means for the transmission and routing of this call request, taking into account the IP type of the called SIP node.
They will be better understood on reading the description and on observing the following drawings in which, in addition to
a represents, purely as an illustration, a flow chart of the essential steps of the SIP server addressing method that is the subject of the present invention;
b represents, as an illustration, an IP network configuration in the presence of a first IP environment of IPv4 type and a second IP environment of distinct IP type, IPv6, interconnected via an intermediate node;
a represents, as an illustration, a flow chart of the essential steps of a process of registration of an SIP node with an SIP registration server, thanks to the implementation of the addressing method according to the subject of the present invention;
b represents, as an illustration, a specific flow chart of the implementation of the registration method illustrated in
a represents, as an illustration, a flow chart of the essential steps of a method of transmission of a call between a calling SIP node and a called SIP node via an SIP proxy thanks to the addressing method and to the registration process that are subjects of the present invention;
b represents, as an illustration, a flow chart of the essential steps of a method of communication according to the subject of the present invention, between a server operating in an environment of determined IP type and at least one node of a network;
c represents, as an illustration, a variant embodiment of the method of communication illustrated in
a to 5c represent, as an illustration, a call transmission protocol between SIP nodes of the same IP type, IPv6 in
a represents, as an illustration, a functional diagram of an SIP registration server according to the subject of the present invention;
b represents, as an illustration, a functional diagram of an SIP proxy server according to the subject of the present invention.
A more detailed description of the SIP server addressing method for the interworking of SIP nodes of a first respectively of a second IP type will now be given with reference to
With reference to the aforementioned figures, consideration is given as an example to a first IP environment of IPv4 type and a second IP environment of IPv6 type.
As shown in
It is however specified that the method that is the subject of the present invention is totally applicable by reversing the roles between the IPv4 environment and the IPv6 environment, the registration server element R and the SIP proxy server element P then being placed in the IPv6 environment in this case.
In addition, as a nonlimiting example and in order to make the whole easier to understand, the existence of an intermediate node IN is considered, shown in
With reference to
As shown in
Thus, in the step A of
The step A is then followed by a step B consisting in providing any SIP node of the same IP type as the SIP server with the original address of each SIP server in the corresponding environment, and any SIP node of IP type other than the IP type of the SIP proxy server with a communication address corresponding to the auxiliary address allocated to each SIP server.
As is shown in step B of
SIP node A:
SIP node B:
The step of providing the aforementioned addresses is then followed by a step C consisting in translating the communication address of one or the other IP type into the auxiliary address of the same IP type as the IP type of the original address of the SIP servers.
In step C of
P2@v6P2v4
R2@v6R2v4.
It is therefore understood that, thanks to the process of allocating auxiliary addresses, and in fact the dual addressing of each SIP server involved, the intercommunication between any SIP node of one and/or the other IP environment, IPv4 or IPv6, may thus be executed.
Generally, the original addresses R1@v4 and P1@v4 of the SIP servers are configured in the DNS inputs designated domain name naming inputs in a corresponding IP environment, IPv4.
The same applies in relation to the communication addresses R2@v6 and P2@v6 which may be configured as DNS input for the IPv6 environment.
Finally, it is specified that the SIP servers that are the subject of the dual addressing, according to the addressing method that is the subject of the invention, include any registration server respectively any SIP proxy server of one or the other of the IP environments.
A method of registering an SIP node of a determined IP type with a registration server, such as the server R represented in
With reference to the aforementioned
As shown in
With reference to
With reference to
It is understood in particular that, in the registration address, R@vx indicates either the original address R1@v4 of the registration server or, on the contrary, a communication address such as the address R2@v6 mentioned above in the description with reference to
The aforementioned communication address naturally corresponds to the auxiliary address R2@v4 allocated to the registration server R as mentioned above in the description.
In the step D of
The step D is then followed by a step E consisting in discriminating the IP type of the SIP node A according to the original respectively communication call address corresponding to the auxiliary address used by the SIP node in the aforementioned registration request.
In the step E of
vx=v4 if R@vx=R1@v4,
vx=v6 if R@vx≡R2@v4.
In the above relations and in the rest of the description, the = sign represents the direct equality of the addresses and the ≡ sign represents the equality of the addresses after translation by the intermediate node IN.
Specifically, it is understood that, when the call address is a communication address, the latter is translated into an auxiliary address which naturally makes it possible to discriminate the IP type of the SIP node on registration.
In the above relations, vx designates in fact the discriminated IP type of the SIP terminal.
The step E is then followed by a step F consisting in establishing and maintaining a first database DB1(v4) and a second database DB2(v6) of the registration of each SIP node.
Specifically, it is understood that, following the discrimination carried out in the step E, each SIP node corresponds to an SIP node of the same IP type as the IP type of the proxy server, of v4 type in the example given, with reference to
Conversely, an SIP node is of IP type distinct from the IP type of the proxy server, when the call address corresponds to the auxiliary address of this registration server via the communication address.
The establishment of the aforementioned registration databases may correspond to the insertion of a reference to the address of each corresponding SIP node, denoted for this reason A@vx=A@v4 when the candidate terminal A is registered in the first registration database DB1(v4), and A@vx=A′@v4, the address A@v6 having been translated en route into this address A′@v4 when the address of the corresponding SIP node corresponds to an SIP node of v6 type, the corresponding address A′@v4 being registered in the second registration database DB2(v6).
It is understood in particular that the registration process that is the subject of the invention is implemented because all the SIP nodes of IPv4 type, by configuration, contact the registration server R on its original address exclusively, while all the SIP nodes of IPv6 type make contact with the registration server R only via the communication address R2@v6, which is naturally translated into the auxiliary address R2@v4. The registration server therefore receives any request transmitted by an SIP terminal of IPv6 type exclusively on its auxiliary address.
In the case of a dual stack SIP terminal ADS, it is preferably the address used by the latter to register with the registration server R that makes it possible to determine the base in which it appears.
In addition, and in a preferred nonlimiting embodiment, it is indicated that, for an optimized registration procedure and in the case of an SIP node of dual stack IP type, the process may also consist, as shown in
This operation in the step D′ of
In the above relation, it is understood that RR1(R@vx) designates the registration request of IP type corresponding to the IP type of the proxy server for example and that RR2(R@vy) designates a registration request of IP type distinct from the IP type of the proxy server for example.
The IP types of the two requests may naturally be reversed.
The step D′ is then followed by a step E′ consisting in discriminating the IP type of the SIP node based on each of the two aforementioned transmitted registration requests.
In the step E′ shown in
vx=v4 if R@vx=R1@v4,
vy−v6 if R@vy≡R2@v4.
As in the case of
In the above relations, the equality of the call address of the registration server and of the auxiliary address of the registration server is understood to be the equality after conversion of the communication address forming the call address.
Step E′ is then followed by a step F′ consisting in establishing and maintaining jointly the first and the second registration databases DB1(v4) and DB2(v6) for the SIP node of dual stack type, based on the two discriminated IP types.
It is therefore understood that, by implementing the registration process according to the invention shown in
In addition, it is indicated that any SIP node of IPv6 type is represented in the IPv4 environment by an IPv4 address for which a correlation is made with the IPv6 address of the SIP node of IPv6 type in its original IP environment. The registration request for an SIP node of IPv6 type therefore arrives at the auxiliary address R2@v4 of the registration server R and the IPv4 address representing the SIP node of IPv6 type in the IPv4 environment is then available for the registration operation since it is supplied by the adaptation functions implemented elsewhere by the operator of the IPv4 network.
Accordingly, the registration databases maintained by the registration server R may then contain only IPv4 addresses which naturally ensures total consistency of the network transmission service.
A method of communication between at least one server S operating in an environment of determined IP type, taken as a nonlimiting example as the IPv4 type, and at least one node A of the network, this node A being able to be of the same IP type, IPv4, or of IP type, IPv6, that is distinct from the determined IP type, IPv4, of the server S, will now be described with reference to
With reference to the aforementioned
The node A is then provided with, as the call address of the server S, either the original address, S1@v4, if the node A is of the same determined IP type, IPv4, or the communication address, S2@v6, if the node A is of IP type, IPv6, that is distinct from the determined IP type, IPv4.
The corresponding operation is shown in
Vx=V4?
On a positive response to the test H, the original address S1@v4 is supplied in the step I as the call address of the server S to the node A, according to the relation:
A→S1@v4
A@vx
Otherwise, on a negative response to the test H, the communication address, S2@v6, distinct from the determined IP type, IPv4 is supplied in step J.
On a call, in the step K, to the server S by the node A, by transmission of a call request represented by the relation
where CR(Sy@v4) designates the call request, Sy@v4 designates either the original address S1@v4, or the communication address S2@v6 which is translated en route by IN into the auxiliary address S2@v4 of the server S, the user, in the step L, discriminates the IP type of the node A, according to the original address S1@v4 or auxiliary address S2@v4 of the server at which this call has been received.
In
Sy@v4=S1@v4.
On a positive response to the test L, the node A is discriminated, in the step M, as belonging to the determined IP type IPv4, A|A@vx=A@vx=A@v4. Otherwise, on a negative response to the test L, the node A is discriminated in the step N as belonging to the IP type, IPv6, distinct from the determined IP type A|A@vx=A′@v4 which is the translation of A@v6 by IN, because Sy@v4=S2@v4 when the call is received by P.
When the server S is a registration server, the communication method also comprises a registration step, as described with reference to
A more detailed description of a method of transmission of a call from an SIP node called by a calling SIP node is now given with reference to
With reference to the aforementioned
The call is transmitted via an SIP proxy server denoted P operating in an IP environment of the same IP type or of an IP type distinct from the IP type of the calling SIP node.
As an example, consider the SIP proxy server P which then comprises a original address P1@v4 and an auxiliary address P2@v4 of IP type corresponding to this IP environment and allocated according to the addressing method that is the subject of the invention, as described above in the description with reference to
In addition, it is considered that the calling SIP node A and the called SIP node B have satisfied the process of registration with the server R which itself has its original address R1@v4 and its auxiliary address R2@v4 as described above in the description with reference to
The call transmission method that is the subject of the invention comprises at least, as shown in
CR(P@v4, B@vy),
the discrimination, at the SIP proxy server, of the type of the calling SIP node from the original call address respectively the communication address corresponding to the auxiliary address allocated to the SIP proxy server.
It is understood, in particular, that in the step U the discrimination may be directly carried out by the SIP proxy server P on the basis of the call in the call request, either of the original address of the SIP proxy server, in which case the calling SIP node A corresponds to a node of IP type identical to that of the SIP proxy server P, or, on the other hand, to a node of IP type distinct from that of the SIP proxy server P, when the call address of the latter corresponds, after conversion, to the auxiliary address P2@v4.
The step U may then be followed by a step W consisting in discriminating, at the registration server R, the IP type of the called SIP node based on the registration bases DB1(v4) and DB2(v6). This operation is carried out by a call V to the registration server R by the SIP proxy server P as will be described later in the description.
In the step W of
vy=v4 if B@vyεD1(v4),
vy=v6 if B@vyεDB2(v6).
The aforementioned step W is then followed by a step X for transmission from the registration server to the SIP proxy server of the discriminated IP type for the called terminal B and of the communication address of the called SIP node for qualification and routing of the call request in the step Y represented in
In the transmission step X, the transmission operation is represented by a service message according to the relation:
Finally, the routing operation in the step Y is represented by the relation:
The operating mode of the call transmission according to the method that is the subject of the invention as shown in
During the setting-up of a call, the method that is the subject of the invention allows any SIP proxy server to determine, simply in the context of the call, notably the IP type of the calling respectively called SIP node in order to optimize the routing choices and notably the use of the aforementioned adaptation functions.
In the step U, the SIP proxy server determines the IP type of the calling SIP node A. For this purpose, it relies on the knowledge of the addresses used by the SIP nodes in order to contact it.
Specifically, by configuration, all the SIP nodes of IPv4 type contact the SIP proxy server P exclusively on its original address. Furthermore, the SIP nodes of distinct IP type, namely of IPv6 type in the example given, contact the aforementioned proxy server on its communication address P2@v6. The latter address corresponds, as described above, to the auxiliary address P2@v4 of the proxy server P in question since a correlation is ensured between these two addresses by the service applied furthermore by the operator of the IP network.
The SIP proxy server P in question therefore receives any request sent by an SIP node of type distinct from the IP type of this SIP server exclusively on its auxiliary address. The SIP proxy server P may therefore deduce that an SIP node is of the dual stack type when this SIP node has been referenced in each of the registration databases described above.
In addition, any dual stack SIP node uses the attribute “ANAT” to enter these two addresses.
In the step W, the registration server R determines the IP type of the called SIP node P.
In a conventional processing of an SIP call, the intermediate proxy server contacts the registration server for the latter to supply the address with which the called SIP node B was previously registered. The registration server R returns to the SIP proxy server P the address required after having consulted its registration database.
On the other hand, the method that is the subject of the invention introduces an additional element into these interchanges. Specifically, the SIP proxy server P also requires the IP type of the SIP node called in the step V. To respond, the registration server R relies on its registration databases, since the IP type of the reference of the registered SIP node is the registration criterion in the registration database in which the latter has been registered.
When this information has been determined, the registration server R transmits the latter in the step X, typically at the same time as the provision of the address of the called SIP node B.
When this operation has been executed, that is to say after the step W of
In particular, for a calling SIP node and a called SIP node of distinct IP type, the SIP proxy server routes the call by means of ALG adaptation functions making it possible to modify the content of the SDP field of the call request and to incorporate therein information intended for the called SIP node.
Thus, with reference to
following the step U of discrimination of the IP type of the called node by the registration server R, then the step X of transmission, from the registration server R to the proxy server P, of the IP type, vy, of the called node B, registered in the database and of an address B@vy of the called node. The step X is followed by the step Y of routing of the call from the calling node A to the called node B, according to the IP type, vx, of the calling node discriminated by the proxy server P in the step U and of the IP type, vy, of the called node B transmitted by the registration server R in step X.
As a variant, as shown in
The steps U and V of
vx/y=v4 if A/B@vx/yεDB1(v4)
vx/y=v6 if A/B@vx/yεDB2(v6).
The step W′ is followed by a step X′ of transmission from the registration server R to the proxy server P of a service message comprising the respective IP types vs, vy of the calling terminal A and of the called terminal B, accompanied by the communication address of the called terminal B@vx according to the relation:
The step X′ is followed by the routing step Y described with reference to
A representation of the various call transmission cases is now described with reference to
In this situation, the SIP proxy server P does not make use of the ALG adaptation functions, since the information contained in the SDP field of the call request will be relevant for both of the SIP nodes in question, the calling and called nodes.
a illustrates the case of the call between two SIP nodes of the same type IPv4 between the SIP node A and the user agent UA of the same type of an SIP node C.
The successive SIP messages are as follows:
b: Transmission of a call between SIP nodes of the same type, IPv6.
In this situation, the implementation of the ALG adaptation functions is also not required. Specifically, the IPv6 information contained in the SDP field of the SIP messages are relevant for both SIP nodes which are of the same SIP type, IPv6.
Not routing the call to adaptation functions typically implementing an ALG application also makes it possible to maintain the setting-up of the RTP streams within the IPv6 environment without going through an intermediate node. However, the service elements and in particular those represented on the intermediate node IN are in principle situated in an IPv4 IP environment. Consequently, the call signaling passes through a simple relay function from the point of view of transport between the IPv4 environment and the IPv6 environment.
The interchange of the successive SIP messages 1 to 4 is represented in the drawing of
c: The case of a call between heterogeneous clients of a distinct IP type.
If the calling and called SIP nodes A and B represented in
The interchange of the successive SIP messages 1 to 4 is also represented in
The method and the protocol used for the interchanges between the SIP proxy server and the registration server according to the subject of the invention depend on the implementation. In particular, many implementations have the particular feature of having the registration server R and the SIP proxy reside within the same physical entity, which makes it possible to lighten the overall implementation of the additional function of determining the IP types of the calling terminal and the called terminal, according to the subject of the present invention.
A more detailed description of an SIP registration server operating in an IP environment of determined type, in the presence of another IP environment of distinct IP type, according to the subject of the invention, will now be given with reference to
In a conventional manner, such a server comprises input/output members, denoted I/O, connected to a central processor unit CPU and a working memory RAM.
It is noteworthy in that it also comprises a original IP address denoted R1@v4 in
In addition, as shown in
Finally, as also shown in
In addition, and according to a notable feature of the registration SIP server that is the subject of the invention, it is indicated that for any SIP node of dual stack IP type, the first registration database DB1(v4) comprises a reference to the IP address of the SIP node of IP type corresponding to the IP type of the proxy server of IP type and the second registration database DB2(v6) comprises a reference to the IP address of the SIP node of IP type distinct from the IP type of the proxy server of IP type.
b represents an SIP proxy server according to the subject of the present invention and operating in transmission of a request to call a called SIP node by a calling SIP node.
It comprises input/output members I/O connected to a central processor unit CPU and a working memory RAM.
It is also noteworthy in that it includes a original IP address P1@v4 corresponding to the IP environment of determined IP type, in which the proxy server is installed, and an auxiliary address of the same IP type as the IP type of the original address, address denoted P2@v4. These addresses may be stored in a programmable memory.
Finally, it comprises a module M1 for discrimination, based on the call request, of the IP type of any calling SIP node based on the original call address respectively communication address corresponding to the auxiliary address of the SIP proxy server, as described above in the description.
It also comprises a module M2 for discrimination by interrogation of a registration SIP server of the IP type of the called SIP node as described above in the description.
It finally comprises a module M3 for the transmission and routing of the call request taking account of the IP type and of the communication address of the called SIP node.
In particular, when the calling SIP node and the called SIP node are of distinct type, the aforementioned module M3 executes the routing of the call request via adaptation functions making it possible to modify the content of the SDP field of the call request and to incorporate therein information intended for the called SIP node.
The invention also covers a computer program comprising a series of instructions stored on a storage medium and able to be executed by a computer or a dedicated device, such as a registration SIP server. The registration SIP server effects the registration of an SIP node of determined IP type in an IP environment of the same type or of another IP type.
This registration SIP server comprises a original address and an auxiliary address of IP type and an auxiliary address of IP type corresponding to the IP environment, this auxiliary address being allocated as described above in the description with reference to
Finally the invention covers a computer program comprising a series of instructions stored on a storage medium and able to be executed by a computer or a dedicated device, such as an SIP proxy server, working by transmission of a call request for a called SIP node by a calling SIP node of determined IP type that is identical or distinct.
The SIP proxy server comprises a original address and an auxiliary address of IP type corresponding to the IP environment and allocated according to the addressing method as described above in the description with reference to
It is noteworthy in that, when it is executed, this program executes the call transmission method as described above in the description with reference to
| Number | Date | Country | Kind |
|---|---|---|---|
| 0605945 | Jun 2006 | FR | national |
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/FR2007/051531 | 6/26/2007 | WO | 00 | 12/29/2008 |
