A backup SIP server for the survivability of an enterprise network using SIP
BACKGROUND OF THE INVENTION
Field of the invention
The invention relates t o the enterprise telecommunication networks. An enterprise
telecommunication network often links terminals that are spread on a plurality of
sites, and today it uses the Internet Protocol (IP) and the Session Initiation Protocol
(SIP). Voice samples, data packets, and signaling messages are carried by an IP
network that is independent of the public telephone switched network (PSTN),
though the enterprise network is also linked to the PSTN by a gateway in order to
communicate with the world outside the enterprise.
Each SIP terminal runs a SIP User Agent. All the sip user agents are interconnected
through an IP network comprising at least one SIP server that acts as a registrar
server, a redirect server, a proxy server, and possibly as a presence server, in order
to set up telephone communications, and also provide numerous telephony
services. For instance: message waiting indications, presence state indications,
conference membership notifications, call statistics, messaging ... Generally an
enterprise network comprises a single SIP server, located i n a main site of the
enterprise, and the terminats of the remote sites communicate with the SIP server
of the main site via an IP network.
In case of failure of this IP network, part or totality of the services previously
provided by a SIP server i n the main site is no longer available in the remote sites.
Description of the prior art
Some solutions are known:
Calls may be rerouted t o the PSTN but none out of band service
information is conveyed through this way.
Some local proxy servers may offer specific services in case of loss of the
link with the SIP server of the main site, but they do not exchange any information
with it as long as the IP network is down; so, all the services hosted i n the SIP
server of the main site are no longer available i n the remote site.
Global IP routing through the PSTN, by means of a fully backed up
infrastructure. The cost of deployment and the cost of the required bandwidth are
very high.
The aim of the present invention i s to provide at least some of these telephony
services t o the SIP terminals located on remote sites, when the IP link t o the SIP
server of the main site is down, at a reasonable cost.
SUMMARY OF THE INVENTION
A first object of the invention is a backup SIP server for the survivability of an
enterprise network using session initiation protocol, this network comprising a main
site and at least one remote site, the main site comprising a main SIP server and
the remote site comprising said backup SIP server, these two sites exchanging SIP
signaling messages via an Internet protocol link through an Internet protocol
network;
characterized i n that it comprises:
- means for detecting whether the Internet protocol link is not working, and
enabling the use of a backup SIP signaling link to the main site via a SIP gateway
and a public telephone network when the Internet protocol link is not working;
- means for transferring SIP signaling information on this backup link;
- means for, when receiving a registration request from a terminal of the remote
site while the Internet protocol link is not working, registering this terminal locally
and forwarding the registration request to the main site via the backup link;
- means for storing policies defining what services, supplied by the main SIP server,
are compatible with said backup SIP signaling link, and for altering the content of
at least one field i n each SIP signaling message addressed t o the main SIP server
before transferring this SIP signaling message on the backup link, this content being
altered according to said policies.
Thanks to the means for transferring SIP signalling information on this backup link,
the main SIP server can continue t o provide services to the terminals of the remote
site because this SIP signalling information enables the main SIP server t o continue
to provide some of the telephony services to the SIP terminals located on remote
sites, when the IP link t o the SIP server of the main site is down.
Thanks t o the means for storing policies and for altering the content of at least one
field in each SIP signalling message addressed to the main SIP server according to
said policies, it is possible to continue to provide services by means of a cheap
backup link, because these means allow t o discriminate the services that are
compatible with the backup link and those that are not compatible. For instance, it
is possible to use a backup link constituted of one or a few voice channels of the
public switched telephone network by allowing only services for which the signalling
can be carried by such a low bandwidth link.
Other features and advantages of the present invention will become more apparent
from the following detailed description of embodiments of the present invention,
when taken in conjunction with the accompanying drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
In order t o illustrate in detail features and advantages of embodiments 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 is a block diagram showing an exemplary enterprise telecommunication
network, on a main site and a remote site, comprising a backup SIP server
according to the invention.
- Figure 2 illustrates the transmission of a REGISTER message from the SIP user
agent of a terminal located in the remote site to the main SIP server located in the
main site, for registering the terminal in the main SIP server.
- Figure 3 illustrates the transmission of a SUBSCRIBE message from the SIP user
agent of a terminal located i n the remote site to the main SIP server located i n the
main site, for subscribing to message waiting indication.
- Figure 4 illustrates the transmission of a NOTIFY message from the main SIP server
located i n the main site t o the SIP user agent of a terminal located in the remote
site, for notifying the terminal that a message is waiting.
- Figure 5 illustrates the transmission of a SUBSCRIBE message from the main SIP
server located i n the main site to the SIP user agent of a terminal located i n the
remote site, for subscribing t o call statistics publication.
- Figure 6 illustrates the transmission of a PUBLISH message from the SIP user agent
of a terminal located in the remote site t o the main SIP server located i n the main
site, for notifying call statistics t o the latter.
- Figure 7 is a block diagram showing an embodiment of the backup SIP server
according t o the invention.
- Figure 8 illustrates the operations made by a link monitor manager i n this
embodiment.
- Figure 9 illustrates with more details one of the operations made by the link
monitor manager in this embodiment.
- Figure 10 illustrates, with more details, the operations of a forward registration
manager i n this embodiment.
- Figure 11 illustrates, with more details, the operations of a policy manager i n this
embodiment.
- Figure 12 illustrates the operations of a classical SIP terminal when i t collaborates
with an embodiment of the backup SIP server according to the invention.
- Figure 13 is a block diagram showing an embodiment of the gateway according to
the invention.
- Figure 14 illustrates operations made by this embodiment of the gateway
according to the invention.
- Figures 1 and 6 illustrate other operations made by this embodiment of the
gateway according to the invention.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
The exemplary enterprise network represented on figure 1 comprises, on a main
site:
- SIP terminals such as T2
- Time Division Multiplexing (TDM) terminals such as T4,
- a main SIP server MSS,
- a router R2,
- a SIP gateway SIPGW2 according t o the invention;
and on a remote site:
- SIP terminals such as T ,
- Time Division Multiplexing (TDM) terminals such as T3,
- a backup SIP server BSS, according t o the invention,
- a router R1 ,
- a SIP gateway SIPGW1 according t o the invention.
All the network elements of the main site are linked t o a local area network LAN2,
except the TDM terminals that are linked t o the gateway SIPGW2. All the network
elements of the remote site are linked t o a local area network LAN1 , except the
TDM terminals that are linked t o the gateway SIPGW1 .
The routers R1 and R2 are linked by an IP link IPL through an IP network WAN. The
SIP gateways SIPGW1 and SIPGW2 are linked by a public switched telephone
network PSTN that may be analog or digital. In other embodiments, it may be
replaced by a public mobile network.
The SIP gateways SIPGW1 and SIPGW2 are used for calls between TDM terminals and
IP or TDM terminals of the enterprise network, and for calls between terminals of
the enterprise network and terminals of the network PSTN. In addition, they are
used for exchanging SIP signaling messages via the public network PSTN i n case the
IP link IPL through an IP network WAN the IP network WAN does not work.
Normal mode:
When the IP network WAN is working, the backup SIP server BSS is on standby. It
periodically checks that the IP link IPL i s working. The main SIP server MSS acts as a
registrar server, a redirect server, and a proxy server, for the users of all the
terminals of both sites, for setting up the calls to and from all the terminals of both
sites. For instance, when the SIP terminal T 1 sets up a session with one of the
terminals T2, T3, or T4, its sends SIP signaling message that are forwarded to the
main SIP server MSS via the local area network LAN1 , the router R1, the IP network
WAN, the router R2, and the local area network LAN2. Then the main SIP server MSS
forwards the messages t o the destination terminal via the local area network LAN2.
Backup mode:
When the SIP signaling link IPL, through the network WAN, does not work, the
backup SIP server BSS or one of the SIP terminals of the remote site, T 1 for
instance, detects the failure of the link IPL. Then the backup SIP server BSS orders
the setup of a backup SIP signaling link BL over the public switched telephone
network PSTN (It may be on an analog or digital trunk, according to the
configuration of the public switched telephone network PSTN). In other
embodiments, the backup link BL may be setup via a mobile network, for instance a
third generation mobile network. It may also be a permanent link, for a quicker
reactivity i n case of interruption of the IP link IPL.
The backup SIP server BSS becomes fully activated to act as a registrar server, a
redirect server, and a proxy server, for the users of all the terminals of the remote
site. So i t accepts the registration of all the terminals of the remote site. This local
registration enables the terminals of the remote site to set up local calls between
them.
In addition, the backup SIP server BSS forwards their registration requests to the
main SIP server MSS, via the backup SIP signaling link BL, in order to keep the main
SIP server MSS updated. This registration i n the main site enables the terminals of
the remote site to set up calls to terminals of the main site, and anywhere else, via
the public switched telephone network PSTN.
In addition, the backup SIP signaling link enables the main SIP server MSS to
continue t o provide at least a part of the services it usually provides t o the
terminals of the remote site. The backup SIP server BSS can transfer, on the backup
SIP signalling link BL, various kinds of SIP signalling information. However i t cannot
be real time signalling or high bandwidth signalling since the backup SIP signalling
link BL is carried by one or a few voice channels of the public switched telecom
network PSTN.
According t o the invention, the backup SIP server BSS allows only a subset of the
services usually provided by the main SIP server MSS t o the terminals of the remote
site. It allows the services that require signalling information that is compatible
with the backup SIP signalling link BL. For allowing or forbidding services, i t parses
the SIP signalling messages that are sent from the terminals of remote site t o the
main SIP server, on the main site; and i t alters the contents of some fields of these
SIP messages, by deleting some information that would be necessary for providing
the forbidden services.
On the other hand, i t propagates, on the backup SIP signalling channel BL, signalling
information necessary for allowed services such as:
- SIP device registrations;
- Service subscribing from local or remote users, and relevant notifications;
- Service messaging;
- Contextual data publications.
It may have additional capabilities such as routing feature for local and external
calls, local services, conference...
For instance, when the SIP terminal T 1 on the remote site sends a SIP message
addressed t o the terminal T2 on the main site, this message i s received by the
backup SIP server BSS. This latter alters the Allow header field of this message, i f
necessary, i n order t o allow only some services ; inserts the relevant route
headers ; and then forwards the message t o the main SIP server MSS via the
gateway SIPGW1, the backup signaling link BL through the public switched
telephone network PSTN, and the gateway SIPGW2. Then the main SIP server MSS
forwards the message t o the terminal T2.
The figures 2 t o 6 illustrate the transmission of different kinds of SIP signaling
messages between the SIP user agent of terminal T 1 and the main SIP server MSS,
and the transmission of the corresponding acknowledgements, i n backup mode, for
various services.
Figure 2 illustrates the transmission of a REGISTER message from the SIP user
agent of the terminal T 1 located in the remote site t o the main SIP server MSS
located in the main site, for registering the terminal i n the main SIP server MSS, in
backup mode. When this terminal T 1 detects that the IP link IPL with the main SIP
server no longer works, i t registers t o the backup SIP server BSS. The backup SIP
server BSS propagates the registration request t o the main SIP server MSS via the
backup SIP signalling link BL setup over the public switched network PSTN. In the
REGISTER message, the backup SIP server BSS may:
- rewrite the content of the field "Request-URI" t o match the main SIP server
registrar URI (Uniform Resource Identifier).
- alter the content of the header field "Allow" (that contains a list of "SIP
methods" such as SUBSCRIBE, NOTIFY, MESSAGE, PUBLISH, OPTIONS ...).
- insert the route headers of the corresponding gateway URI SIPGW1 and SIPGW2
according t o its configuration.
For instance, if:
BackupSIPServer.com is the URI of the backup SIP server BSS,
MainSIPServer.com i s the URI of the main SIP server MSS,
SIPUA@BackupSIPServer.com is the URI of the terminal T 1,
SIPUA@IPSIPUA is the contact URI of terminal T 1 formed by its IP address,
then the terminal T 1 sends t o the backup SIP server BSS a message:
Registerl : registrar.BackupSIPServer.com
From: SIPUA@BackupSIPServer.com
Contact: SIPUA@IPSIPUA
Allow: INVITE, ACK, BYE, REGISTER, SUBSCRIBE, NOTIFY, MESSAGE, PUBLISH,
OPTIONS,...
So the terminal T 1 has been registered i n the backup SIP server BSS, and this latter
has indicated that i t allows the SIP methods INVITE, ACK, BYE, REGISTER,
SUBSCRIBE, NOTIFY, MESSAGE, PUBLISH, OPTIONS.. .
Then the backup SIP server BSS sends, t o the gateway SIPGW1 a message:
Register2: registrar. MainSIPServer.com
From: SIPUA® MainSIPServer.com
Contact: SIPUA@IPSIPUA
Allow: REGISTER, SUBSCRIBE, NOTIFY, MESSAGE, PUBLISH, OPTIONS...
In the message Register2, the field "Allow" has been modified by the backup SIP
server BSS i n order t o suppress some SIP methods (INVITE, ACK, etc) among those
that were allowed by the terminal T . The suppressed methods correspond t o
services (such as establishment of real time media sessions and attached services
like transfer, for instance) that need a real time signalling or a wide band
signalling that cannot be supported by the backup SIP signalling link BL. Then the
backup SIP server BSS sends an acknowledgement 200ok t o the terminal T .
Then the gateway S1PGW1 sends, t o the gateway SIPGW2, via the backup SIP
signaling link BL, a message:
Register3: registrar. MainSIPAppliServer.com
From: SIPUA@MainSIPServer.com
Contact: SIPUA@IPSIPUA
Allow: REGISTER, SUBSCRIBE, NOTIFY, MESSAGE, PUBLISH, OPTIONS,...
Path: SIPGW1 .MainSIPServer.com
In the message Register3, a field Path has been added by the gateway SIPGW1 i n
order t o indicate a path towards the backup SIP server BSS, conforming t o standard
RFC3327.
The gateway SIPGW2 sends, t o the main SIP server MSS, a message:
Register4: registrar. MainSIPServer.com
From: SIPUA® MainSIPServer.com
Contact: SIPUA@IPSIPUA
Allow: REGISTER, SUBSCRIBE, NOTIFY, MESSAGE, PUBLISH, OPTIONS,...
Path: SIPGW2. MainSIPServer.com, SlPGW1 .MainSIPServer.com
The field Path has been completed by the gateway SIPGW2 in order t o indicate a
full path towards the backup SIP server BSS, conforming t o standard RFC3327.
Then the main SIP server MSS sends an acknowledgement message "200ok" t o
backup SIP server BSS via the gateway SIPGW2 and the gateway SIPGW 1.
The backup SIP server according t o the invention also enables service subscribing
from the remote site. In the following examples, the backup SIP server BSS shall
alter the relevant headers, including the Route header when needed.
Examples of services:
a) Message waiting indication (see figures 3 and 4): Each user located on the
remote site can use a Voice Mail service located in the main SIP server MSS. This
service notifies the user with the state of his/her mailbox, i n whatever mode
(normal/backup) the system is. For such purpose, after registration of a terminal,
the backup SIP server BSS propagates the relevant subscribe request (Message
Waiting Indication EventPackage) t o the main SIP server MSS. Upon any significant
change of the user's voice mailbox state, relevant notification shall be sent from
the main SIP server MSS and propagated t o the corresponding user. An application
or equipment can use this notification t o inform the user through an appropriate
way (Popup window, icon, blinking LED, tone ...)
b) Resource presence state: SIP devices of the remote site may display global
resource state information (remote user presence state, services availability as
Voicemail services ...). For such a purpose, a SIP user agent sends a subscribe
request (Presence Event Package) t o the backup SIP server BSS. This latter forwards
such requests t o the main SIP server MSS and processes subsequent notifications t o
the corresponding user agents.
c) Conference membership notification: A SIP user agent may participate t o a
conference hosted by a conference server in the main SIP server MSS, and require
the respective presence states of all participants, through a subscribe request
(Conference Event Package) t o the backup SIP server BSS which shall forward such
requests and shall process subsequent notifications.
Figure 3 illustrates the transmission of a SUBSCRIBE message from the SIP user
agent of the terminal T 1 located in the remote site t o the main SIP server MSS
located i n the main site, for subscribing t o the service called "message waiting
indication", i n backup mode.
The terminal T 1 sends, t o the backup SIP server BSS, a message:
Subscribel :SIPUA@vmail.BackupSIPServer.com
From: SIPUA@BackupSIPServer.com
Event: message-summary
where SIPUA@vmail.BackupSIPServer.com is the URI of the Voice Mail service
attached to Terminal 1 in Backup mode,
and where SIPUA@BackupSIPServer.com is the URI of Terminal 1 in Backup mode.
Then the backup SIP server BSS sends, t o the gateway SIPGW1 , a message:
Subscribe2:SIPUA@vmail. MainSIPServer.com
From: SIPUA@MainSIPServer.com
Route: SIPGW1 .MainSIPServer.com, SIPGW2.MainSIPServer.com
Event: message-summary
In the message Subscribe2, a field Route has been added by the gateway SIPGW1 for
routing the message t o the main SIP server MSS.
Then the gateway S1PGW1 sends, t o the gateway SIPGW 2, via the public switched
telephone network PSTN, a message:
Subscribe3 :SIPUA@vmail. MainSIPServer.com
From: SIPUA@MainSIPServer.com
Route: SIPGW2.MainSIPServer.com
Event: message-summary
In the message Subscribe3, the header field Route has been altered by the gateway
SIPGW1 by suppressing the URI of the SIP Gateway SIPGW1 which has just been
crossed.
Then the gateway SIPGW 2 sends, t o the main SIP server MSS a message:
SubscribedSIPUA@vmaiI.Mai nSI PServer. com
From: SIPUA@MainSIPServer.com
Event: message-summary
In the message Subscribe^ the field Route has been altered by the gateway SIPGW2
by suppressing the URI of the SIP Gateway SIPGW2 which has just been crossed.
Then the main SIP server MSS sends an acknowledgement message "200ok" t o the
terminal T 1 via the gateway SIPGW2, the public switched telephone network PSTN,
the gateway SIPGW 1, and the backup SIP server BSS.
The backup SIP server according t o the invention enables publications and
notification from the remote side.
a) Publications (An example will be described below with reference t o figure 6)
- Presence state publication (RFC 3856and PUBLISH method):
Devices of the main site (Conference servers, messaging applications,
routing ...) may need Presence state information relative t o the users
located in the remote site. These presence data are conveyed from user
agents i n the remote site t o a Presence agent associated t o main SIP server
MSS, via the backup SIP server BBS and the backup SIP signalling link.
-- Call statistics publication (PUBLISH method):
Some devices of the main site (Billing application, conference servers,
routing, voice quality system monitoring ...) need permanent call statistics
information. These call statistics are conveyed from user agents i n the
remote site t o a Call Statistics agent associated t o main SIP server MSS, via
the backup SIP server BBS and the backup SIP signalling link.
b) Notifications (An example will be described below with reference t o figure 4)
-- Call statistic notifications: according t o RFC6035, the subscribe/ notify
mechanism may also be used i n such a case.
-- Call Terminated notification: An automatic redial feature using Dialog
Event Package (RFC4235) may be invoked by a user A located on the main
site, as this user A is trying t o contact a user B located on the remote site
and that i s busy. A notification of call termination is forwarded t o the main
SIP server MSS when the user B becomes available, in order t o allow an
automatic redial for the user A.
Figure 4 illustrates the transmission of a NOTIFY message from the main SIP server
MSS located i n the main site t o the SIP user agent of the terminal T 1 located in the
remote site, for notifying the terminal T 1 that a message is waiting, i n backup
mode.
The main SIP server MSS sends, t o the gateway SIPGW2, a message:
Notifyl :SIPUA@MainSIPServer.com
From: SIPUA@MainSIPServer.com
Route: SIPGW2.MainSIPServer.com, SIPGW1 .MainSIPServer.com
Event: message-summary
Messages-Waiting: yes
The main SIP server MSS adds a field Route for routing the message t o the backup
SIP server BSS.
Then the gateway SIPGW2 sends, t o the gateway SIPGW1 , via the public switched
telephone network PSTN, a message:
Notify2:SIPUA@MainSIPServer.com
From: SIPUA@MainSIPServer.com
Route: SIPGW1 .MainSIPServer.com
Event: message-summary
Messages-Waiting: yes
The gateway SIPGW2 modifies the field Route in the message Notify2, by
suppressing the URI of the SIP gateway SIPGW2 which has just been crossed.
Then the gateway SIPGW1 sends, t o the backup SIP server BSS, a message
Notify3:SIPUA@MainSIPServer.com
From: SIPUA@MainSIPServer.com
Event: message-summary
Messages-Waiting: yes
The gateway SIPGW1 modifies the field Route in the message Notify3, by
suppressing the URI of the SIP gateway SIPGW1 which has just been crossed.
Then the backup SIP server BSS sends, t o the terminal T1, a message
Notify4:SIPUA@BackupSIPServer.com
From: SIPUA@BackupSIPServer.com
Event: message-summary
Messages-Waiting: yes
Then the terminal T 1 sends an acknowledgement message "200ok" t o the main SIP
server MSS via the backup SIP server BSS, the gateway SIPGW1 , the public switched
telephone network PSTN, and the gateway SIPGW2.
The backup SIP server according t o the invention enables subscription from the
main site.
Figure 5 illustrates the transmission of a SUBSCRIBE messages from the main SIP
server MSS located i n the main site t o the SIP user agent of a terminal T 1 located in
the remote site, for subscribing t o call statistics publication, i n backup mode.
The main SIP server MSS sends t o the gateway SIPGW2 a message:
Subscribel :SIPUA@MainSIPServer.com
From: callStat@MainSIPServer.com
Route: SIPGW2.MainSIPServer.com,
SIPGW1 .MainSIPServer.com
Event: vq-rtcpxr
In the message Subscribel, the main SIP sever MSS adds a field Route for routing
the message t o the backup SIP server BSS.
Then the gateway SIPGW2 sends, t o the gateway SIPGW1 , via the public switched
telephone network PSTN, a message:
Subscribe2: SIPUA@MainServer.com
From: callStat@MainSIPServer.com
Route: SIPGW1 .MainSIPServer.com
Event: vq-rtcpxr
Where callStat@MainSIPServer.com is the URI of the call statistics publication
service.
Then the gateway SIPGW1 sends, t o the backup SIP server BSS, a message:
Subscribe3: SIPUA@MainSIPServer.com
From: callStat@MainSIPServer.com
Event: vq-rtcpxr
Then the backup SIP server BSS sends, t o the terminal T 1, a message:
Subscribed SIPUA@BackupSIPServer .com
From : callStat@BackupSI PServer. com
Event: vq-rtcpxr
Then the terminal T 1 sends an acknowledgement message "200ok" t o the main SIP
server MSS via the backup SIP server BSS, the gateway SIPGW1 , the public switched
telephone network PSTN, and the gateway SIPGW2.
The backup SIP server according t o the invention enables publications from the
remote side.
Figure 6 illustrates the transmission of a PUBLISH message from the SIP user agent
of the terminal T 1 located in the remote site t o the main SIP server MSS located i n
the main site, for notifying call statistics t o the latter, in backup mode.
Terminal T 1 sends, t o the backup SIP server BSS, a message:
Publis : SIPUA@BackupSIPServer.com
From: SIPUA@BackupSIPServer.com
Event: vq-rtcpxr
Then the backup SIP server BSS sends, t o the gateway SIPGW1 a message
Publish2:SIPUA@MainSIPServer.com
From: SIPUA@MainSIPServer.com
Route: IPGW1 .MainSIPServer.com,
SIPGW2.MainSIPServer.com
Event: vq-rtcpxr
The backup SIP server BSS adds a field Route for routing the message t o the main
SIP server MSS.
Then the gateway SIPGW1 sends, t o the gateway SIPGW2, via the public switched
telephone network PSTN, a message:
Publish3 :SIPUA@MainSIPServer.com
From: SIPUA@MainSIPServer.com
Route: SIPGW2.MainSIPServer.com
Event: vq-rtcpxr
Then the SIP gateway SIPGW2 sends t o the main SIP server MSS, a message:
Publish4: SIPUA@MainSIPServer.com
From: SIPUA@MainSIPServer.com
Event: vq-rtcpxr
Then the main SIP server MSS sends an acknowledgement message "200ok" t o the
terminal T 1 via the gateway SIPGW2, via the public switched telephone network
PSTN, the gateway SIPGW1 , and the backup SIP server BSS.
Figure 7 is a block diagram showing an embodiment BSS of the backup SIP server
according t o the invention. It comprises:
a management and configuration module MMC;
- a classical SIP server CSS;
- and a backup application server BAS for implementing the backup operations
according t o the invention.
The classical SIP server CSS comprises a registrar module RGM and a proxy server
PRX. The backup application server BAS comprises:
- a forward registration manager FRM that duplicates and sends t o the main SIP
server MSS, via the proxy PRX, the registration data that are being written into
the registrar module RGM;
- a policy manager POM that checks the "SIP methods" (INVITE, ACK, BYE,
REGISTER, SUBSCRIBE, NOTIFY, MESSAGE, PUBLISH, OPTIONS,...) indicated i n a
message being sent by a terminal, for keeping or deleting each of these
methods i n the message before forwarding the message t o the main SIP server
MSS;
- and a link monitor manager LMM that monitors the IP link IPL carried by the
IP network WAN. If it detects any failure of the IP link IPL, it enables the
registrar module RGM of the backup SIP server BSS for registering the local
terminals, and i t sets up a backup SIP signaling channel BL via the public
switched telephone network PSTN. The signaling information concerning
services is forwarded t o the main SIP server MSS, whereas the signaling
concerning voice i s dealt with by the backup SIP server BSS.
Examples of methods selected by the policy manager POM:
- INVITE :
o Non media session (Case Content-Type header <> sdp :
depends on Content- Length header) : cf media type
description (http://www.iana.org/assignments/mediatypes)
o Media session (Content-Type header : application /sdp) :
NO
o Content-Type absent: NO (supposed to be SDP in Ack,...)
CANCEL:
BYE:
ACK:
o If from a non media session : YES
o Otherwise : no
REFER : NO
REGISTER : YES
- SUBSCRIBE/NOTIFY : Depends on Event header contents; may also
depend on the Content- Length header value:
o Message-summary : YES (rfc3842)
o vq-rtcpxr : YES (rfc6035)
o presence : YES (rfc3856)
o winfo : YES (rfc3857)
o dialog : YES (rfc4235)
o conference : YES (rfc4575)
o ... (list is not exhaustive)
- MESSAGE: depends on the Content-Length value (and the rate :
all data may not be transmitted i f traffic i s too important)
- OPTIONS : YES
- INFO : depends on the Content- Length value and the rate
- PUBLISH : i f Event header is accepted (rfc3903)
Some priorities may also be associated t o methods, events or users (SDP invite
might be authorized for a determined user or with a determined low priority),
depending on the value and the capacity of the backup signalling link, the transfer
may whether or not be guaranteed.
Figure 8 illustrates the operations made by the link monitor manager LMM i n the
backup application server BAS:
Step 81: At initialization, the backup SIP server BSS is on standby, i . e. its port is
closed.
Step 82: The link monitor manager LMM periodically sends a keep-alive message t o
the main SIP server MSS via the IP network WAN, in order t o detect a possible
default of the IP link through the network WAN.
Step 83: Then the link monitor manager LMM checks whether it receives a response
from the main SIP server MSS via the IP network WAN. If i t receives a response, it
continues t o keep the backup SIP server BSS on standby (Return t o step 8 1).
Step 84: If i t does not receive a response, the link monitor manager LMM activates
the backup SIP server BSS i n order t o forward the registration requests t o the main
SI server MSS.
Step 85: Then the link monitor manager LMM awaits a recovery of the IP network
WAN: It periodically sends a keep-alive message t o the main SIP server MSS via the
IP network WAN.
Step 86: Then the link monitor manager LMM checks whether i t receives a response
from the main SIP server MSS via the IP network WAN. If it does not receive a
response, the backup SIP server remains active (Return t o step 84).
Step 87: If i t receives a response from the main SIP server MSS via the IP network
WAN, i . e. if the IP link IPL carried by IP network WAN is working again, i t
unregisters the SIP user agents that it had registered locally, and then puts the
backup SIP server BSS back t o standby state (Return t o step 8 1 ).
Figure 9 illustrates, with more details, the step 84 made by the link monitor
manager LMM i n the backup application server BAS. If i t does not receive a
response, the link monitor manager LMM activates the backup SIP server BSS:
Step 9 1: It activates the register module RGM so that i t accepts t o register the
users of the terminals, of the remote site, which request registration.
Step 92: Then i t sends a SIP message INVITE t o the gateway SIPGW1 , for requesting
i t t o setup a call t o the gateway SIPGW2 via the public network PSTN, t o set up the
backup SIP signaling link BL.
Step 93: If the gateway SIPGW1 responds negatively or does not respond, the link
monitor manager LMM tries again (Return t o step 92).
Step 94: If the gateway SIPGW1 responds positively, a backup SIP signaling link BL is
now available via the public switched telephone network PSTN. Then the link
monitor manager LMM proceeds t o the step 85.
Figure 10 illustrates, with more details, the operations of the forward registration
manager FRM:
When the SIP user agent of a SIP terminal, located i n the remote site, sends a SIP
register request RR 1, via the proxy PRX, this request is locally dealt with by the
forward registration manager FRM. If the backup SIP server BSS i s activated:
- The forward registration manager FRM forwards the registration request by
sending a SIP register request message RRQ2 t o the main SIP server MSS, via the
proxy PRX. Then the main SIP server MSS acknowledges that i t has registered the
user. Then the forward registration manager FRM stores, i n a data base D that is
part of the registrar module RGM, an indication that the main SIP server MSS has
registered the user.
- The forward registration manager FRM allows a local registration, i n a registrar
memory RM that is part of the registrar module RGM, and allows the sending of an
acknowledgement message ROK, 200ok, t o the terminal that sent the register
request RRQ1 .
Figure 1 illustrates, with more details, the operations of the policy manager POM:
All the requests that transit through the proxy PRX are dealt with by the policy
manager POM. When the SIP user agent of a SIP terminal, located in the remote
site, sends a SIP request RR 1, via the proxy PRX, the policy manager POM supplies
a response RS, t o the proxy PRX, that may be one of the following ones according t o
predetermined rules:
- Continue treatment without modification (for instance for a local call, or a
mere phone call via the public network PSTN).
Negative response (For instance refusing a video call via the public switched
telephone network PSTN because the available bandwidth is insufficient, or
refusing a service that needs a real time signaling that the public switched
telephone network PSTN cannot support).
Forward the request to its destination (with header modifications).
- No action (For instance, on figure 2, there is no action done when the
backup SIP server BSS receives the message 200ok, because the message
Registerl has already been acknowledged previously by sending a message
200ok t o the terminal T 1) .
It is possible t o use classical SIP terminals, without any modification i n these SIP
terminals, when a backup SIP server according to the invention is installed in an
enterprise network.
Figure 12 illustrates the operations of a classical SIP terminal T 1 located i n the
remote site, when i t collaborates with an embodiment of the backup SIP server
according t o the invention. This terminal stores the address of a main SIP server
and the address of a backup SIP server.
Step 121: The terminal is i n its initial state. Generally, i n this initial state, the
terminal has been previously registered on the main SIP server.
Step 122: The terminal periodically sends a SIP message, REGISTER, requesting a
registration on any SIP server.
Step 123: Then i t checks that the main SIP server responds. If the main SIP server
responds, then the terminal stays in its initial state (Return to step 121 ), or
continues the normal steps of a call if a call is ongoing.
Step 122': Between two periodic automatic checking, the user of the terminal may
attempt to make a call while the IP link with the main SIP server does not work
anymore. The attempt triggers the sending of a SIP message, INVITE, addressed t o
the main SIP server.
Step 123': Then the terminal checks that the main SIP server responds. If the main
SIP server responds, then the terminal continues the normal steps of a call.
Step 124: If the main SIP server does not respond, the terminal sends a SIP
message, REGISTER, in order to be registered on the backup SIP server (For instance
the backup SIP server BSS described above).
Step 125: Then i t checks whether a SIP server responds. If the backup SIP server
has responded within a predetermined time interval, the terminal goes back t o in
its initial state (Return to step 121 ) in order to continue to periodically send a SIP
message, REGISTER, requesting a registration on the main SIP server.
Step 126: If the backup SIP server has responded that i t has registered the
terminal, then the terminal enters into a new state "Registered on backup SIP
server". It can benefit from the backup SIP server for using services hosted by the
main SIP server.
Figure 13 is a block diagram showing an embodiment SIPGW1 of the
gateway according t o the invention. The peer gateway SIPGW2 located in the main
site is similar. This embodiment SIPGW1 comprises a classical gateway CGW, a
proxy PRO and a data compression module DC. The classical gateway CGW
comprises:
- A management and configuration module MC that stores parameters such
as the parameters of IP interfaces, SIP and trunk layers, and route configuration.
- An analog or digital trunk interface module Tl for coupling the gateway t o
a trunk of the public network PSTN. Its type depends on the type of trunk.
- A media Server module MS coupled to the enterprise network: It is
located on the IP network side, and manages the RTP/RTCP/T38 ... flows.
- A transcoder module TC: It comprises several types of transcoding
resources, such as audio coders, a HDLC (High-Level Data Link Control) transcoder,
and a modem, in order to convert the protocol used i n the enterprise IP network
protocol, for the data payload, t o the protocol used i n a trunk of the public
network PSTN, and reciprocally.
- A call control module CC: It manages a call according to the type of the
signalization (SIP, Q931 , analog ...) used by the terminal of a calling party, and it
drives the Media Server module MS, the transcoder module TM, and the trunk
module TM.
The use of the backup SIP server BSS implies modification of the management and
configuration module MC and of the call control module CC of the classical gateway
CGW. The management and configuration module MC i s modified in order t o
receive and store the following parameters:
- A rescue call number that will be used for establishing the backup link BL.
- A data compression flag (to enable/disable compression).
- Value of the bandwidth of the backup link BL (optional).
The call control module CC is modified so as t o start (respectively stop) the
relevant HDLC resources of the transcoder module TC i n case the called number
matches the rescue call number (instead of starting (respectively stopping)
resources of media server MS and audio coder resources of the transcoder module
TC, as i t is normally done for any other call).
The proxy module PRO forwards each SIP message according t o the IP address
contained i n a SIP Request-URI. The SIP message is either sent t o the Call Control
module CC i f its IP address is the address of the gateway SIPGW1 (normal ISDN call),
or t o the Data compression module DC i f the IP address is the address of the main
SIP Server MSS. In the latter case the proxy adds its own IP address i n Path header
on each register method. For each other SIP method sent t o the Main SIP Server
MSS, the proxy PRO suppresses its own IP address in the Route header.
The data compression module DCM applies a compression according t o the
configuration parameters, in order the decrease the size of SIP packets, thus
increasing the maximal signalling data rate on the backup link BL.
Figure 4 illustrates operations made by this embodiment of the gateway
according t o the invention for call establishment on the SIP Gateway SIPGW1 (and
SIPGW2). There are two types of calls managed by the gateway SIPGW1 :
- Basic outgoing/incoming calls used from/to a local phone i n order t o make a voice
call.
- An outgoing rescue call, based on the rescue call number, when the call control
module CCM must establish a back up link BL for the SIP signalling data.
There are two types of calls managed by the gateway SIPGW2:
- Basic outgoing/incoming calls used from/to a local phone i n order t o make a voice
call.
- An incoming rescue call, based on the rescue call number, when the call control
module CCM of SIPGW1 must establish a back up link BL for the SIP signalling data.
- Step 140: The call control module CC receives a request to set up an outgoing call
(SIPGW1 )/incoming call (SIPGW2) to/from the public network PSTN.
- Step 141 : The call control module CC checks the called number, on the
outgoing/incoming call establishment request.
- Step 142: If the number matches the rescue call number, then the call control
module CC sets up a backup link BL supporting the HDLC protocol.
- Step 143: If the number does not match the rescue call number, then the call
control module CC sets up a classical voice link supporting a RTP (Real Time
Transport) protocol on the side of the enterprise network, and starts the data
transcoding i n the transcoder module TC.
Figure 5 illustrates operations made by this embodiment SIPGW1 of the gateway
according t o the invention, for sending SIP requests and responses t o the main site:
- Step 150: A SIP message originating from the remote site is received by the
proxy PRO of the gateway SIPGW1 .
- Step 15 1: The proxy PRO checks the content of its destination URI (request-URI or
identified destination for a SIP response message):
- Step 152: If URI= XXX@SIPGWAddress, the proxy PRO forwards the message
directly t o the call control module CC of the gateway SIPGW1 .
- Step 153: If URI= XXX@MainSIPGServerAddress, the proxy PRO forwards the
message t o data compression module DC, in order t o save bandwidth on the backup
link BL.
- Step 154: Then the compressed message is sent t o the transcoder module TC
(HDLC coder) of the gateway SIPGW1 , in order t o transmit the compressed message
via the PSTN network, on the backup link BL.
Figure 16 illustrates operations made by both the SIPGW1 i n remote site and the
peer gateway SIPGW2 in the main site for processing SIP egress traffic. The proxy
may receive SIP requests or responses from the local network, or from the remote
entity (either i n the main site or in the local site) via the public network PSTN:
- Step 160: The gateways SIPGW1 /SIPGW2 receive SIP a request or response from
the local network.
- Step 161 : The gateways SIPGW1 /SIPGW2 receive SIP a request or response from
the remote site via the public network PSTN.
- Step 162: In this latter case, an HDLC driver receives compressed data, forwards
them t o a decompression module. The decompression module decompresses the
data t o reconstitute a SI message and transmits the SIP message t o the proxy of
the gateway.
- Step 163: The proxy receives the SIP message.
- Step 164: The proxy forwards the SIP message t o its destination i n its local
network (BSS for SIPGW1 and main SIP server MSS for SIPGW2).
THERE IS CLAIMED:
1) A backup SIP server (BSS) for the survivability of an enterprise network using
session initiation protocol (SIP), this network comprising a main site and at least
one remote site, the main site comprising a main SIP server (MSS) and the remote
site comprising said backup SIP server (BSS), these two sites exchanging SIP
signaling messages via an Internet protocol link ( IPL) through an Internet protocol
network (WAN);
characterized in that i t comprises:
- means (LMM) for detecting whether the Internet protocol link (IPL) is not working,
and enabling the use of a backup SIP signaling link (BL) t o the main site via a SIP
gateway (SIPGW1 ) and a public telephone network (PSTN) when the Internet
protocol link is not working;
- means (FRM) for transferring SIP signaling information on this backup link (BL);
- means (FRM) for, when receiving a registration request from a terminal of the
remote site while the Internet protocol link (IPL) i s not working, registering this
terminal locally and forwarding the registration request to the main site via the
backup link (BL);
- means (POM) for storing policies defining what services, supplied by the main SIP
server (MSS), are compatible with said backup SIP signaling link, and for altering the
content of at least one field i n each SIP signaling message addressed to the main SIP
server before transferring this SIP signaling message on the backup link (BL), this
content being altered according to said policies.
AMENDED CLAIMS
received by the International Bureau o n 29 March 20 2 (29.03.201 2)
1) A backup SIP server (BSS) for the survivability of an enterprise network using
session initiation protocol SIP, this network comprising a main site and at least one
remote site, the main site comprising a main SIP server (MSS) and the remote site
comprising said backup SIP server (BSS), these two sites exchanging SIP signaling
messages via an Internet protocol link (IPL) through an Internet protocol network
(WAN); comprising:
- means (LMM) for detecting whether the Internet protocol link (IPL) is not working,
and enabling the use of a backup SIP signaling link (BL) t o the main site via a SIP
gateway (SIPGW1 ) and a public telephone network (PSTN) when the Internet
protocol link is not working;
- means (F M) for transferring SIP signaling information on this SIP backup link (BL);
- means (FRM) for, when receiving a registration request from a terminal of the
remote site while the Internet protocol link (IPL) is not working, registering this
terminal t o the backup SIP server and forwarding the registration request t o the
main SIP server via the SIP backup link (BL);
characterized in that it further comprises means (POM) for storing policies defining
what services, supplied by the main SIP server (MSS), are compatible with said
backup SIP signaling link, and for altering the content of at least one field in each
SIP signaling message addressed t o the main SIP server before transferring this SIP
signaling message on the SIP backup link (BL), this content being altered according
t o said policies.