BACKGROUND OF THE INVENTION
Field of the invention
The present invention generally relates t o a method for SIP (Session Initiation
Protocol) proxy failover in a SIP telecommunication network.
Figure 1 schematically represents an example of a classical SIP
telecommunication network SIPN comprising two proxies P 1 , P2 and a domain
name server DNSR. Telephone terminals respectively comprise user agents
SIPUA1 , SIPUA2, etc, and are linked t o this SIP network via Ethernet links.
All SIP user agents SIPUA1 , SIPUA2, etc, are registered t o a same SIP
domain, by using the procedures defined by standards RFC3261 and RFC3263, and
especially Domain Name System (DNS) resolution. For instance, the user agent
SIPUA1 has registered t o the proxy P 1 , and the user agent SIPUA2 has registered
t o the proxy P2. For registering in a proxy, a user agent makes a "DNS request" t o
a DNS server in order get a list of proxy addresses, with a priority ranking, then it
selects the proxy address having the highest priority in this list and registers t o it.
Once registered, it sends subsequent requests t o that proxy (unless DNS server
configuration is changed), in particular it sends requests t o set up calls.
A SIP domain is generally managed by a set of proxies and these proxies
are redundant, so that each proxy provides a failover function in case another one
is shutdown (for maintenance purpose for example). For instance, if the proxy P 1
is shutdown for maintenance, then the SIP User Agent SIPUA1 is supposed t o
switch t o the backup proxy P2. But the SIP user agent SIPUA1 is not immediately
aware, by SIP protocol means, that the proxy P 1 is shutdown.
Figure 2 illustrates the failover from the proxy P 1 t o the proxy P2 in this
examplary SIP telecommunication network SIPN. When the proxy P 1 is shutting
down, then the proxy P2 is taking over in order t o serve all the user agents in the
domain. When a user starts his/her SIP telephone, the SIP user agent SIPUA1 of
this telephone makes the following steps:
- Step 20: It send a DNS request t o the DNS server DNSR, according t o standard
RFC3263, in order t o solve the domain name.
- Step 2 1: The DNS server DNSR responds by a DNS response containing proxy
addesses respectively pointing t o the proxy P 1 in first priority and t o the proxy P2
in second priority.
- Step 22: Some time later, the proxy P 1 shuts down.
- Step 23: Some time later, the user of this telephone calls another telephone
user. The user agent SIPUA1 again sends a DNS request t o the DNS server DNSR,
according t o standard RFC3263, in order t o solve the domain name.
- Step 24: The DNS server DNSR responds by a DNS response containing proxy
addresses respectively pointing t o the proxy P1 in first priority and t o the proxy
P2 in second priority, because it is not aware of the shutdown of the proxy P 1 .
- Step 25: Then the user agent SIPUA1 sends a message "INVITE
sip:bob@example.com" t o the proxy P 1 , because it has the highest priority. The
proxy P 1 fails t o establish a session because it is shutdown. It does not respond
at all. The terminal is waiting for a response.
- Step 26: In the user agent SIPUA1 , a timer B (request timeout, see timer
reference in RFC3261 ) expires after a predetermined time.
- Step 27: Then the user agent SIPUA1 sends a message "INVITE
sip:bob@example.com" t o the proxy P2, that has a second priority in the list of
proxy addresses received from the domain name server DNSR .
- Step 28: The proxy P2 responds by a message "403 Forbidden" because the user
agent SIPUA1 is not registred in the proxy P2.
- Step 29: The user agent SIPUA1 sends an acknowledgement message "ACK" t o
the proxy P2.
The call establishment has not been possible because the SIP User Agent SIPUA1 is
not registered t o proxy P2. This registration will occurs later, at the registration
refresh time (according t o RFC3261 registration refresh). So a call will be
possible after the refresh time, but this delay may be long (several minutes).
Description of the prior art
The best existing solution is described in RFC3261 , RFC3263, and RFC5626 section
4.5:
- RFC3261 defines a refresh time (named "expire") at which a SIP user agent tries
t o register again t o the same proxy.
- RFC5626 defines an algorithm t o accelerate the recovery in case a proxy is not
reachable.
- RFC3263 sends a "DNS SRV" message t o communicate the list of backup proxies.
The sip user agent must use this list of proxies (with a priority ranking) t o switch
t o a recovery proxy.
This known solution is not good enough, because the recovery time is too long,
this time should be as short as possible. Let's try t o estimate this time :
- When an INVITE message is sent t o proxy P 1 , a timer B is started and will expire
before the shutdown is detected. By default, the timer B (cf. RFC3261 ) lasts
32 seconds.
- When a second INVITE message is sent t o the proxy P2, it is rejected because it
is not registered t o the proxy P2. To register again, it may last, at worst, the
expire time which can be very long (several minutes).
Another known solution, illustrated by Figure3, comprises a common database
CDB where all the proxies P 1 , P2, of a domain, store the registration addresses of
all the user agents. However if a SIP user agent, SIPUA 3 for instance, is behind a
router R comprising a network address translator (commonly abbreviated "NAT"),
this solution doesn't work anymore : Actually, the network address translator
assigns two different transport addresses (IP address + port), respectively
10.0.0.1 :3333 and 10.0.01 :2222 for instance, when an a message is forwarded t o
the proxy P2, and when a message is forwarded t o the proxy P 1 . So the
registration address (10.0.0.1 :3333) used for reaching the proxy P2 cannot be re
used for reaching the proxy P 1 , in case of failure of the proxy P2, though this
registration adress (10.0.0.1 :3333) has been registered in the common data
base DB.
Thus, there is a need t o provide a technical solution for providing a quick SIP
proxy failover. It is peculiarly important when users are waiting for emergency
phone calls t o be set up.
This problem can be solved by applying the method according t o the invention.
SUMMARY OF THE INVENTION
The object of the invention is a method for SIP proxy failover in a SIP
telecommunication network comprising a plurality of proxies and a domain name
server, this method comprising the following steps:
- storing, in the domain name server, the add resses of the proxies that are
working;
- if a first proxy shuts down, then informing the domain name server that this first
proxy has shutdown;
- then, if a user agent sends a domain name system request t o the domain name
server, sending, from the domain name server t o this user agent, a response only
containing the respective add resses of proxies that are working,
- and then, said user agent registering itself in a proxy the add ress of which is
contained in the response from the domain name server.
Thanks t o this method , when shutting down a SIP proxy, the domain name server
is updated t o memorize that this proxy is not available. When a user agent needs
t o send a message t o a proxy, the domain name server provides it with at least
one address of a proxy that is working. So the user agent does not send any
message t o a proxy that is not available any more. This way dramatically shortens
the waiting time of a user when a SIP proxy fai lover occurs.
Another object of the invention is a SIP proxy, a domain name server, and SIP user
agent for implementing this method. An algorithm is distributed in the SIP proxies,
the DNS server and the SIP User Agent.
Other features and advantages of the present invention will become more
apparent from the following detai led description of embodiments of the present
invention, when taken in conj unction with the accompanying drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
In order t o illustrate in detail features and advantages of an embodiment of the
present invention, the following description will be with reference t o the
accompanying drawings. If possible, like or similar reference numerals designate
the same or similar components throughout the figures thereof and description, in
which:
- Figure 1, described above, schematically represents an example of a classical
SIP telecommunication network.
- Figure 2, described above, shows a signaling flow for an example in which a first
known method is applied for a proxy failover.
- Figure 3, described above, shows a signaling flow for an example in which a
second known method is applied for a proxy failover.
- Figure 4 shows a signaling flow for an example in which the method according t o
the invention is applied for a proxy failover.
DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT
The method according t o the invention is applied by executing the following
algorithms, respectively in the proxies, the DNS server, and the SIP user agents.
Algorithm in a proxy:
- When the proxy starts, it sends a message t o the DNS server, this message
informing the DNS server that this proxy has started. This message is "domain
name:proxy name:proxy IP address:UP".
- According t o the invention, when the proxy shuts down it sends a message t o the
DNS server, this message informing the domain name server that this proxy has
started. This message is "domain name:proxy name:proxy IP address:DOWN".
- If this proxy starts again, then it sends a message t o the DNS Server, this
message informing the DNS server that this proxy is working again. This message is
"domain name:proxy name:proxy IP address:UP".
Algorithm in the DNS Server:
- It is waiting for messages from proxies.
- When it receives a message from a proxy:
-- If message type is "UP", then it enables the name of this proxy
for any DNS response i t will send for that domain.
-- If message type is "DOWN", then it disables the name of this
proxy for any DNS response it will send for that domain.
So, if a user agent sends a domain name system request t o the domain name
server, this latter sends, t o this user agent, a response only containing the
respective addresses of proxies that are working.
Algorithm in a SIP user agent, when it needs t o send a message t o a proxy:
- The user agent sends a DNS request t o the DNS server.
- The user agent receives a DNS response containing the address of a proxy or a
list of addresses of proxies, with a priority ranking.
- The user agent selects from the DNS response the target proxy address t o send
the SIP message (as specified in RFC3263 statements)
- According t o the invention, it compares the selected target proxy address t o the
address of the proxy where it is currently registered to:
-- If the address of the proxy where it is currently registered t o is
equal t o the selected target proxy address, then it is allowed t o
send a message t o this selected target proxy address.
-- If the address of the proxy where it is currently registered t o is
not equal t o the selected target proxy address, then prior t o send
the message t o that selected target proxy address, i t initiates a
registration t o it through a REGISTER transaction.
For instance, let us consider a SIP telecommunication network SIPN
comprising two proxies P1 , P2 and a domain name server DNSR. Telephone
terminals respectively comprise user agents, such as SIPUA1 , that is linked t o this
SIP network via an Ethernet link.
Figure 4 shows a signaling flow for this exemplary telecommunication network, in
which the method according t o the invention is applied for the fai lover from the
proxy P1 t o the proxy P2. At the considered instant, the proxies P 1 and P2 are
working. The domain name server DNSR memorizes the address of proxy P 1 and
the address of proxy P2 in a data base (not represented). So, when the domain
name server DSNSR receives a DNS request, it responds by a DNS response
containing the address of the proxy P 1 and the address of the proxy P2, with a
priority ranking. In this example, the proxy P 1 has the highest priority. For
instance, a user agent SIPUA 1 has been registered in the proxy P 1 because i t
placed a phone call earlier (This previous event is not represented).
- Step 42: Now, the proxy P 1 shuts down. It informs the DNS server DNSR of that
event by sending a message "example.com: P 1 :DOWN" t o it. The DNS server DNSR
is now aware that the proxy P 1 cannot be reached. It removes the address of
proxy P 1 from its database, so that the address of the proxy P 1 will not be
included i n any DNS response that the domain name server DNSR will send.
- Step 43: Some time later, the user of the user agent SIPUA1 wants t o call Bob.
The SIP user agent SIPUA1 makes a DNS request t o the DNS server DNSR.
- Step 44: The DNS server DNSR answers by a DNS response only containing the
address of the proxy P2.
- Step 45: The user agent SIPUA1 selects a proxy according t o RFC3263
statements. In this example, proxy P2 is the only proxy i n the list provided by the
DNS server, so user agent SIPUA1 selects the proxy P2. According t o the invention,
it compares the address of the proxy P2 t o the address of the proxy where i t is
currently registered to, i . e. proxy P 1 . Since the address of the proxy P2 is
different of the address of the proxy P 1 , the user agent SIPUA1 sends a message
"REGISTER sip:p2" t o proxy P2, for registering in the proxy P2. This latter
replaces P 1 .
- Step 46: The proxy P2 sends an acknowledgement message "ACK" t o the user
agent SIPUA1 .
- Step 47: Then, the user agent SIPUA1 sends a message INVITE
sip:bob@example.com" t o the proxy P2.
- Step 48: The proxy P2 answers by a message "180 Ringing" indicating that the
destination terminal is ringing.
- Step 49: Then proxy P2 sends a message "200 OK" t o the user agent SIPUA1 .
- Step 50: The user agent SIPUA1 sends an acknowledgement message "ACK" t o
the proxy P2.
Now, let's estimate the switching delay for the SIP user agent SIPUA1 for
instance:
Let's suppose the round trip time t o DNS server DNSR and proxies P 1 , P2 is
50 milliseconds:
- DNS exchange (request + response) will last 50ms,
- REGISTER exchange (REGISTER + 200 OK) will last 50ms.
Total delay is: 50 + 50 = 100 milliseconds.
This is a very big improvement compared t o already existing solutions (see former
estimations of 32 seconds). This makes this solution much better than the current
state of the art. The method according t o the invention will much decrease the
delay for the user when a SIP proxy is shutdown. If we apply it t o IMS (IP
Multimedia Subsystem) for example, the carrier will provide a much better quality
of service for the user because the unavailability time will be dramatically
improved.
This solution is compatible with routers comprising address translators (NAT)
because the new registration it triggers will update contact information into the
new proxy. In the example of figure 4, if there is a NAT binding used for
communication between the user agent SIPUA1 and the main proxy P1 , the backup
proxy P2 will not use this NAT binding used for communication between the User
Agent and main proxy P 1 , but will use a new dedicated NAT binding created by
new registration.

THERE IS CLAIMED:
1) A method for SIP proxy failover in a SIP telecommunication network (SIPN)
comprising a plurality of proxies (P1 , P2) and a domain name server (DNSR),
comprising the following steps:
- storing, in the domain name server (DNSR), the addresses of the proxies that are
working,
- if a first proxy (P1 ) shuts down, then informing (42) the domain name server
(DNSR) that this first proxy has shutdown;
- then, if a user agent (SIPUA1 ) sends a domain name system request (43) t o the
domain name server (DNSR), sending (44), from the domain name server (DNSR) t o
this user agent, a response only containing the respective addresses of proxies
(P2) that are working,
- and then, said user agent registering itself in a proxy (P2) the address of which
is contained in the response from the domain name server (DNSR).
2) A proxy (P1 ) comprising means for:
- if the proxy shuts down, then sending (42) a message from the proxy (P1 ) t o a
domain name server (DNSR), this message indicating that this proxy has shut
down;
- if the proxy starts, then sending (40) a message from the proxy t o said domain
name server (DNSR), this message indicating that this proxy has started.
3) A computer program product comprising computer-executable instructions for
performing a method when the program is run on a computer, the method
comprising the steps of:
- if the proxy shuts down, then sending (42) a message from the proxy (P1 ) t o a
domain name server (DNSR), this message indicating that this proxy has shut
down;
- if the proxy starts, then sending (40) a message from the proxy t o said domain
name server (DNSR), this message indicating that this proxy has started.
4) A domain name server (DNSR) for a domain, comprising means for:
- when it receives a message from a proxy, indicating that the proxy (P1 ) has
started, then enabling the name of this proxy for all records for said domain;
- when it receives (42) a message from a proxy, indicating that the proxy (P1 ) has
shut down, then disabling the name of said proxy for all records for said domain.
5) A computer program product comprising computer-executable instructions for
performing a method when the program is run on a computer, the method
comprising the steps of:
- if a message is received, indicating that a proxy (P1 ) has shut down, then
disabling the name of said proxy for all records for said domain;
- Else, if message the message indicates that a proxy (P1 ) is working, then
enabling the name of this proxy for all records for said domain.
6) A SIP user agent (SIPUA1 ) comprising means for:
- sending (43) a domain name request t o a domain name server (DNSR),
- then receiving (44) a response containing at least one proxy address,
- then selecting one proxy address among the proxy addresses contained in the
response,
- then, if the selected proxy address (P2) is not equal t o the proxy address (P1 )
where this user agent is currently registered, sending a registration request t o the
selected proxy address (P2).
7) A computer program product comprising computer-executable instructions for
performing a method when the program is run on a computer, the method
comprising the steps of:
- sending (43) a domain name request t o a domain name server (DNSR),
- then receiving (44) a response containing at least one proxy address,
- then selecting one proxy address among the proxy addresses contained in the
response,
- then, if the selected proxy address (P2) is not equal t o the proxy address (P1 )
where this user agent is currently registered, sending a registration request t o the
selected proxy address (P2).