NEC Europe Network Laboratories--SIP-Server

SIP-Server (completed)


The SIP-Server Project involved adding to a prototype Linux SIP Server some extensions that are essential for the successful deployment of SIP-signalled services. These extensions target primarily enterprise networks (but some apply as well to public ones). They address the need of the Network Administration to provide the appropriate quality to the calls (Quality Agent) and to keep under control the call cost and the authorization to place them (Call Detail Record, Access Restriction, Least Cost Routing). Presence Service helps users to optimize their communications. Finally, through a MIDCOM client, the safe opening of firewall pinholes for media data flows into and out of a managed domain is achieved.

As a result of the consensus gained both in the standards and in the industry, the offering of SIP based services is seeing its dawn. The first industry's effort was in the manufacturing of SIP terminals (both hardware and Software SIP Phones) that, following the Internet vision of placing intelligence at the network's edge, can directly open a session between them.

The extensions are essential for the successful deployment of SIP-signalled services. They target primarily enterprise networks (but some apply as well to public ones). They address the need of the Network Administration to provide the appropriate quality to the calls (Quality Agent) and to keep under control the call cost and the authorization to place them (Call Detail Record, Access Restriction, Least Cost Routing). Presence Service helps users to optimize their communications. Finally, through a MIDCOM client, the safe opening of firewall pinholes for media data flows into and out of a managed domain is achieved.

NEC "core" SIP Server and its extension

Presence Information can be defined as information about the willingness and ability to communicate. This knowledge allows focusing the setup of communication channels only on those with the highest probability of success (i.e. no need to try in vain). One example is a user specifying he/she's reachable again after having declared "unavailability" because of him/her being involved in a meeting. An interested communication partner can be automatically informed of this "status change" and successfully establish a call. Another example is the automatic setup of a video-conference by a conference server when all or a minimum subset of requested participants are present.

The business value of presence is certainly relevant in an Enterprise environment, where a company can save time and money improving the way employees communicate: they do not have to uselessly try to get somebody when he/she is not in the office or busy in a meeting or talking on the phone. Also, notifying the participants when everybody is available might reduce the waiting time at the beginning of meetings. There are also a lot of use cases for presence information in the public area. For example, in wireless LAN hotspots people can get localized information when entering, or they can learn if friends are already in the neighbourhood. Operators of such hotspots can give their customers a value-added service.

In the Presence Service three logical entities interact:
1. Presentity
2. Presence Server
3. Watcher

The presentity submits presence information to the presence server, for example through SIP REGISTER messages containing a body with specific information on presence. The watcher is a human end user or an automatic entity interested in the presence of a presentity. Watchers subscribe to presentities at the presence server and will then be notified of available presence information and changes therein.

An example for a watcher is the NL-E Heidelberg Presence Application. This is an application to manage (collect and display) presence information. The protocol used for the collection of presence information is SIP. The necessary SIP extensions for presence are implemented in the NL-E Heidelberg extended SIP server.

Three Logical Entities

One of the factors today limiting the rollout of VoIP services is the absence of QoS guarantees. While it's possible to experience excellent VoIP quality over the "free" Internet in some moments, it's equally possible not to be able to communicate for long period of times. In the long term, this will be of course unacceptable, especially for Enterprise customers. Also in the medium/shorter term, however, Operators will want to differentiate their VoIP service offering into "lower price, lower quality" and "higher price, higher quality" to better target their customer.

The Quality Agent ensures high quality to SIP calls by checking resource availability along the path where SIP calls must be established. Even if in the future bandwidth availability won't represent any more a concern in core's network portions, on the access portion it's foreseeable that bandwidth scarceness will be an issue for still a long time.

The Quality Agent (QA) is an extension module of a SIP server that from the parsing of SIP messages can derive bandwidth requirements for an incoming SIP calls. Then, it compares it with its knowledge of network resource availability, and will "book" resources and admit the call only if it is possible. Otherwise, the call will be blocked and the caller will get a busy signal (as in the GSM or PSTN network when all channels are occupied).

The Quality Agent doesn't perform the "resource booking" itself. Rather, it interacts with a dedicated QoS resource management entity (QoS server), with the advantage that the same QoS management architecture can be used by other QoS demanding services and that the Quality Agent doesn't have to know the details of network equipment configuration. Particular care has been put in designing the QA in such a way that this interaction is much less frequent than on a ball-by-call basis.

How the quality agent works


As in SIP the signalling path is decoupled from the data path, whenever the UDP media traffic has to cross a company firewall, it brings a problem. In fact, as the end terminals decide the ports used for the communication, letting all the UDP ports open at any time would be a too loose configuration rule for any firewall. The solution is to allow a timely "firewall control" by trusted entities (the SIP servers) that know the ports requested by a pair of terminals and can instruct a firewall to open a "pinhole" for the associated UDP media traffic for the duration of the conversation only. For more details on this issue, please have a look at the MIDCOM project.
	Firewall MIDCOM

For more information please contact use our contact form.

Last modified 01-Sep-2010

| Back to Projects | Top |