WO2007071369A1

WO2007071369A1 - Communication device and method for filtering data according to a data policy

Info

Publication number: WO2007071369A1
Application number: PCT/EP2006/012232
Authority: WO
Inventors: Holger Ziemek; Marius-Iulian CORÎCI; Radu Popescu-Zeletin
Original assignee: Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V.
Priority date: 2005-12-19
Filing date: 2006-12-19
Publication date: 2007-06-28
Also published as: EP1969808A1

Abstract

The invention is concerned with a communication device and method with a signalling data input comprising at least one SIP message, a data input, a selector for the signalling data for scanning or filtering the signalling data according to at least one predefined signalling policy, a filter for the dynamical discrimination of the data input according to at least one signal received from the selector, a service device acting on the discriminated data input according to at least one data policy.

Description

COMMUNICATION DEVICEAND METHOD FOR FILTERING DATAACCORDING

TO A DATA POLICY

Currently the exchange of information between users using communication devices is becoming more and more important. The data stream between the communication devices and the various service providers is becoming more and more complex. One example is that Voice-over-IP and other data transfers are transmitted over the same communication lines making it difficult for the end devices to detect the data relevant for a certain service.

Therefore, it is the task of the present invention to provide a communication device, which improves the data exchanges. Furthermore, it is a task of the present invention to provide an improved method for data exchange. The task is solved by a device according to claim 1 and a method according to claim 14.

Various embodiments and their advantages are described in connection with the figures.

The non-limiting examples of the invention are described by

Fig. IA showing the use of devices (COMMDEVICES) according to the invention in IP data transmission;

Fig. IB showing the general use of COMMDEVICES;

Fig. 2 showing the use of SIP requests;

Fig. 3 showing the effect of INVITE involving communication using SIP data;

Fig. 4 showing data packets in a data stream and a media stream;

Fig. 5 showing an example using UPnP; Fig. 6 showing an example using STUN;

Fig. 7 showing the basic configuration of an embodiment of the invention;

Fig. 8 showing a configuration of a more complex embodiment of the invention;

Fig. 9 showing a schematic representation of the architecture of a device according to the invention;

Fig. 10 showing a schematic representation of the signalling message minimization of registration;

Fig. 11 showing a schematic representation of the optimized method for address translation overpassing;

Fig. 12 showing a schematic representation of the signalling pass minimization;

Fig. 13 showing a schematic representation of the signalling pass minimization considerung a multilayer architecture;

Fig. 14 showing a schematic view of a communication situation without using an embodiment of the present invention;

Fig. 15 showing a schematic view of a communication situation using an embodiment of the present invention.

The invention comprises a communication device with a signalling data input comprising at least one SIP message, a data input, a selector for the at least one signalling data for scanning or filtering the signalling data according to at least one predefined signalling policy, a filter for the dynamical discrimination of the data input according to at least one signals received from the selector, a service device acting on the discriminated data input according to at least one data policy.

This device will be more full described in connection with Figure 7 and 8.

In one embodiment the described invention optimizes multimedia communication (e.g. Voice-over-IP, IP-based video telephony, multimedia group conferencing etc.) between two, or a set of endpoints in an IP-based communication infrastructure, consisting of one or a set of interconnected communication networks (local and remote, i.e. connected over a remote link to the Internet or an IP-based communication network) , with respect to different optimization characteristics. The optimization is achieved by applying one or a combination of different optimization methods to the transmitted information, the optimization methods . being • ^■ embodiments of the present invention.

The usage of embodiments of the invention is appropriate in scenarios in which one or a set of local end devices connected to one or a set of locally interconnected IP-based communication networks wishes to communicate with one or a set of other end devices, either local or remote (i.e. connected via the Internet) (See Fig. IA) .

Typical communication links between such endpoints usually have a limited bandwidth and a limited number of available external public IP addresses, thus limiting the number of simultaneously possible undisturbed multimedia connections in the network. Furthermore, network traffic from other connections in the local network (e.g. HTTP downloads etc.) could normally affect the multimedia connections by reducing the available bandwidth per connection below their limits as a result of the shared link capacity between all the users.

Embodiments of the described invention address these and further issues. They optimize the communication by:

• Maximizing the number of simultaneously possible communication connections between users under a given bandwidth limit while retaining guaranteed Quality of Service assurance for each of them.

• Optimizing the usage of multiple communication devices for connections to non-local communication peers while using a smaller number (even one) of globally routable IP addresses by making the usage of inefficient and bandwidth-consuming current technical workarounds obsolete and thus reducing the session setup, time and . . ^• protocol overhead of the communication .. > . • Enabling the local end devices to. have a transparent communication with non-local peers, while also protecting the communications terminals by possible outside attacks pertaining media sessions provisioning.

• Increasing the efficiency of the administration of media communication within one local network, by offering a hybrid set of services to the locally connected users.

• Minimizing the signalling traffic pertaining to media streams in the overall communication system by using a hierarchical registration and session provisioning system.

This is achieved by intercepting, serving and dynamically modifying signalling and data traffic between involved parties .

With the above described optimizations, embodiments of the described invention enable communication under conditions (e.g. traffic load, number of users), in which communication would not have been possible without the usage of an embodiment of the invention.

Embodiments of the invention comprise of one or a set of devices, (from here on called " COMMDEVICES " ) , e.g. adequate for being easily carried by human beings (portable devices) , compliant to current network and communication standards, e.g. Session Initiation Protocol (SIP) (J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler

RFC 3261 - SIP: Session Initiation Protocol, IETF June 2002, http://www.ietf.org/rfc.html. ) with or without its extensions for providing session parameters, e.g. Session Description Protocol (SDP) (M. Handley, V. Jacobson, RFC 2327 - SDP: Session Description Protocol, IETF April 1998, http://www.ietf.org/rfc.html.) and having the ability for . transmitting and receiving network packets, by this stated that it can communicate with exterior parties .

The functionality is implemented in a unique or in a. set of COMMDEVICES, implemented in software, hardware or an intermixed form. A COMMDEVICE is able to: . ' , ..<-.. ,

• interconnect with each other in order to ensure communication between end devices connected to the same COMMDEVICE, between user connected to different COMMDEVICES and between users connected to a COMMDEVICE and other devices not connected to a COMMDEVICE. • connect to various communication types of equipment, such as computers with network adaptors (e.g. wired and wireless) , LAN telephones, PDAs etc (from here on called "end devices" ) .

The general scenario for the COMMDEVICES as presented in the Figure IB consists of a set of local networks and a limited set of exterior networks as seen from the COMMDEVICE perspective. To the set of local networks various end devices could be connected, including routers for other address spaces and other COMMDEVICES .

In order to ensure access for multiple end devices on a limited (smaller) number of exterior public IP addresses, an address translator has to be considered. Two major problems have to be considered: the correct routing of the signalling messages and the provisioning for the media streams (also called data streams) involved in the conversation between the two involved end devices .

In the following, certain SIP header fields and certain information contained in the body of the messages are analyzed. Also some considerations about bandwidth usage and the known techniques are further discussed.

SIP "Contact" Header Field. A SIP registration request binds a special form of SIP Uniform Resource Identifier (URI) to the address of the connected end device. In order to register, an end device sends a request to a known SIP Proxy, as shown as example for IPv4 in Figure 2. This message contains the SIP URI in both the "To": and "From" header . fields, e.g. sip:marius@fraunhofer.de and the address of the local machine, which is private, in the "Contact" header. field e.g. sip.-marius&lO .147.65.110 : 5060. The message is then forwarded to the appropriate Registrar, introducing a "Via" header field in order to receive the responses of this transaction using the same path. The Registrar binds the address of contact with the generic SIP address and sends the proper response.

The entry in the User Location Database created by this transaction binds a public SIP URI to an IP address which is part of a local network. Further requests coming from third party end devices addressed to the registered user will have as destination address the local address of the end device. The local address is not known to the exterior network, therefore this messages will not be routed in the exterior network as to reach their intended target .

Each SIP session is made of two or more transactions with no other than logical connection. To be able to start the transactions following the "INVITE" request, an entity must be able to find the other parties. For this it memorizes the address from the "Contact" header field that comes either with the initial request or with the response to it.

As example, in Figure 3 such a scenario is described for IPv4. When one of the parties is located in a local network and communicates through address translation, as the private end device is in the example, subsequent requests coming from the other party will be sent to the local address from the previous "Contact" header field, therefore never reaching their intended target . .

The contact address received by the entity situated in the local network is the address of the public party .. Therefore no issues are. created when these requests are signalled'.

SI-P Body. When signalling for a media call between two end devices, data blocks could be exchanged through the body of the SIP messages. These parameters contain the address where the originator wants to receive media messages and a port number .

As example the following SDP block could be generated by an end device from a local network:

v=0 o=mco 2890844526 2890842807 IN IN4 10.147.65.110 S=SIP initiated call t=2873397496 2873404696 m=audio 9020 RTP/AVP 0 C=IN IN4 10.147.65.110 For a media connection to be possible, the address specified in the contact field (c) must be routable in the public address space. Also if the public address of the SIP Proxy is deployed in the body of the message, a connection must be considered for an address translation in order to let the data stream pass the gateway.

Bandwidth Considerations. By using the default routing policy, all the traffic has the same priority and therefore the packets from different streams, like the data streams and the media streams, are processed in the order of their arrival. Considering that the data packets for media streams and SIP packets are relatively small compared to the possibilities of transfer using IP protocol, they might be delayed by a large amount of time and then sent in bursts which cannot be accepted in real-time communications .

The example from Figure 4 considers two streams,., one with data traffic having large size packets, and a media stream with small, but frequent packets. Each packet enters in the sending queue ordered by the time that they were created. Therefore the queue will contain one packet of" the bulk connection followed by several of the real-time connection. The messages of the later connection are waiting in the queue for the message of the data transfer to be sent. When the transmission of the bulk message is completed, the set of real-time packets that was meanwhile created is sent to the outer interface. The first of these packets has a larger delay, proportionate to the length of the bulk traffic packets while the last one could be considered without any delay.

In order to obtain a minimal quality of the media transmission, the other party situated at the exterior end has to order the received packages in a regular pattern. Considering that multiple data traffic streams compete with the media traffic, the effect is aggravated.

Even though actual media protocols, e.g. Real-Time Transmission Protocol (RTP) , use a timestamp feature in the header and buffering at the receiving side if the timing disturbance is too large, the buffer can not absorb all the packets that were bursted, resulting in disruptive noise.

Considering also that the size of media traffic and SIP messages surpasses the capacity of the connection, some of the messages may be dropped because of lack of buffering or be delayed with a large amount of time. In order to obtain a better performance the number of messages must be restricted to the maximum sustainable.

In order to solve these problems some techniques are known in the art . These existing techniques are described in the following. , • ^r

UPnP. In order to solve , the address translation problem, an end device could ask the address translator how it would map a particular address-port using a protocol called Universal ■ Plug and Play (UPnP) (UPnP Forum, UPnP Device Architecture, 1999-2000, http://www.upnp.org/).

The client queries the address translator via UPnP asking what mapping it should use if it wants to receive data on port X. The address translator responds with the address-port pair that someone on the exterior network should use to reach the end device on that port .

One problem with UPnP is that it will not work in the case of cascading address translators. Such a design using two address translators deployed one over the other is illustrated in Figure 5, considering IPv4 protocol. If a local end device were to use UPnP to determine its public address-port, then it would only get back the innermost mapping. In the example given, the end device will receive the private 10.147.65.110 instead of the public address 193.175.135.177. There will still be one direction media connection because the public Internet would still not recognize the address-port that the client was giving, since a second translation occurs between the inner most address translator and the exterior network. Furthermore, few of the existing end devices are able to send UPnP requests.

STUN. If there are no means of communicating with the address translator, a next possible solution might be for an end device to determine its external address-port pair is to ask an entity situated outside the address translator in the exterior network how it sees the source of a packet coming from this end device. One of the solutions proposed is the Simple Traversal of UDP through Network address translators (STUN) (J.Rosenberg, J. Weinberger, C. Huitema, R. Mahy RFC 3489 - STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) , IETF

March 2003, http://www.ietf.org/rfc.html) A^' STUN server is basically a kind of mirror, that sends back some information about the packet it has received from an. address translator shielded end device.

In this scenario, illustrated in Figure 6 a server called Address Translation Probe waits for this kind of packets. When it receives such a packet, it returns a message from the same port to the source of the received packet containing the address-port that it sees as the source of that packet. In every case of address translation mapping, the client will receive the return packet. The client can then determine:

• If it is behind an address translator in other words if the address-port contained within the return packet is different than the IP-port put as source for the inquire packet . • Which public address-port it should use in the media message in order for the endpoint to reach it. For example, if the client wants to be reached on 10.147.65.110:8000, it will first send out a query to the address translator probe from port 8000. The address translator probe will actually receive the query packet from 193.175.135.177:12345 and so it will respond to that IP-port with a packet containing

193.175.135.177:12345. The end device then puts into its SIP request the port 12345 and the address

193.175.135.177 while the end device itself listens on 10.147.65.110:8000.

Some issues must be considered for this model . The client must send and receive media data on the same port. He also must send out the SIP message shortly after sending out a query- to. the address translator probe. If there is a long delay, the mapping may change. In the case of Restricted Cone or Port Restricted Cone address translators, the client must send out a packet to the endpoint before the address translator will allow packets from the endpoint through to the client.

This method will not work in the case of symmetric address translators, since the address of the address translator probe is different than that of the endpoint, and therefore the mapping the address translator probe sees is different than the mapping that the endpoint would use to send packets through to the client on that address-port. Considering the deployment of a non-symmetric address translator for the goal system, a number of messages have to be sent to the exterior network, before any SIP signalling can be performed.

Media Relay. Another solution for address translator traversal which does not imply using additional packets for signalling is the usage of a Media Relay in the middle of the media flow between the endpoints. The Media Relay acts as the second endpoint to each of the actual endpoints that are attempting to communicate with each other. Typically, there would be a server in the middle of the SIP flow, herein called a SIP Address Translation Proxy, that would manipulate the body of the SIP message in such a way as to instruct the endpoints to send media packets to the Relay instead of directly to each other. The Relay would set up its own internal mapping of a session, noting the source address-port of each endpoint sending it media packets. It then uses that mapping to forward the media from endpoint to endpoint.

This solution will work for all types of address translators, but because of the delay associated with the Media Relay, which may be substantial, especially if the Media Relay is not close to at least one of the endpoints, it should probably not be used unless a Symmetric Address Translator is involved. This delay could hamper the media packets introducing a large delay that could cause packet loss and also a stopping of the media connection for some end devices.

Application Layer Gateways. An Application Layer Gateway (ALG) is a program running in cooperation with a firewall, performing Network Address Translation. ALGs supporting FTP, DNS and SNMP are common componets in address translation firewalls and have some common features.

1. The ALG is using a different policy for each particular protocol it supports. A higher security level is achieved by this understanding of the relayed protocol . 2. The ALG is not limited to support only connection protocols like TCP, but also other UDP based protocols like TFTP. 3. If the ALG is used over a traversal application application, then it can examine the application data for occurness of the internal addresses and replace them with the addresses of the firewall's external interface. An application layer gateway could be developed as to deal with SIP protocol. In order to obtain such a result the address translator is doubled by a mechanism which alterates SIP packages. This mechanism introduces an important delay caused by the pre-sorting of all incoming traffic to the address translator.

Now turning towards the solution of the problems associated with the known prior art.

The embodiments of the invention comprise a set of optimization methods related to signalling and data traffic in the Internet, comprised in a generic device, named COMMDEVICE .

A principle of the invention is to intercept (e.g. monitor, filter,^', select or drop) , service and/or modify SIP messages in an intermediary entity, which is between source (s) and destination (s) ,. in . order to achieve an optimized traffic exchange for both signalling and data information.

One COMMDEVICE system according to the invention is able to acquire'- the SIP messages from the at least one source and to select them in conformity with a set of data policies, by this stated that it can scan for specific data into the messages pertaining to the data that will be received during the consequent media session (s) .

Using the information received by scanning, the COMMDEVICE is able to filter data messages received from one source and to offer specific service according to a set of one or more data policies .

To this basic system, as depicted in Figure 7, other methods of optimisation, presented as claims of the invention, can be added as described in the following. In Fig. 7 the COMMDEVICE has two input streams, a signalling input stream and a data input stream. In practice any number of signalling and data input streams can be used.

The data input streams e.g. comprises media data, voice data, functional data, imaging data, textual data, music data.

A signalling selector selects certain parts of the signalling data subject to at least one predetermined signalling policy which might be stored in a container. An example of a signalling policy is e.g. a list of known users entitled for using a certain service, like Voice over IP. The signalling selector generates at least one signal to a Data Filter instructing the filtering of data.

The data filer dynamically discriminates the data input according to the signal received from the selector. This can be for example, the extraction of the data, as instructed by . the signal from the selector.

Furthermore, a service device acts on the discriminated data input according to at least one data policy. The servicing device for signalling proxies the at least one SIP message. . from the at least one source to the at least one destination. Also transmitting an input to the data service which by combining with the data policies optimizes the data path. This can e.g. lead to a prioritization of data streams and to minimization of SIP traffic. In Fig. 7 the servicing device comprises a signalling device and a data service.

An example for the data policy is the dynamically prioritization of the data stream by using data from the at least one SIP message, as will be described below.

This COMMDEVICE is able to intercept SIP messages that are sent from one or more sources and addressed to one or more destinations, matching certain criteria, as depicted in Figure 7. The sources and the destinations of the SIP messages during a session provisioning may interchange, thus a COMMDEVICE can act as a simplex or a duplex SIP message interceptor.

A SIP message that enters a COMMDEVICE is scanned and filtered based on specific SIP selection criteria, for example the type of message, the source and the destination of the message etc. The SIP message is also served as a remote signalling request or response, for example the session to which the SIP message pertains is stored in a structured form, a session is discarded because of wrong signalling order etc. The message is also processed using additional optimisations of the invention and- sent to the appropriate destinations.

The processing of the SIP message can offer when requested an optimized method for address translation overpassing, a method for minimizing the SIP communication, a method for protecting local communications or a dynamic control of the SIP retransmission timers. ^{■ ■}

As an additional feature a COMMDEVICE can be able to filter data traffic, execute some service and modify it, in order to offer specific stream prioritization, optimize the address translation overpassing. This feature is controlled by the service of the SIP message flow. Fig. 8 shows a special embodiment of the one shown in Fig. 7. The embodiment according to Fig. 8 contains also the additional feature of data interception in a simplex model.

The invention can be implemented as software running on a computer. Furthermore, the invention can be implemented on a chip. Considering the previous stated, a possible implementation for the COMMDEVICE as software, as depicted in Figure 9 contains the following logical entities:

• [Hybrid Registrar] Supplies the end devices of the local network with SIP registration, also performing a more efficient registration on the SIP Registrars of the end devices .

• [Session Manager] Provides session control as an additional feature over the SIP protocol.

• [Quality of Service Control] Manages the usage of a set of network interfaces for an improved quality of media streams on limited resources (bandwidth, packet loss, delay etc) . • [Address Translator Control] Manages the address translation for both the SIP signalling messages and media streams .

Possibly, using the architecture described above, the COMMDEVICE implements at least one of the methods described below.

Method for Dynamically Prioritizing Media Streams by Using Media Information from SIP Messages

The quality of service control guarantees the necessary bandwidth for each media stream by using an intelligent range management. By using the information obtained dynamically from the SIP messages that signal the start of a new media session and from the SIP messages that modify the parameters of a media session, the QoS Control prioritizes a specific connection in detriment of the other network services if necessary. The common static prioritization is replaced by a dynamic one, also able to prevent the establishment of additional media sessions when no more bandwidth could be provided for a good quality of real-time transmission. Each entity involved in a media session is transmitting at least one message containing a body. From these messages only the last one is considered to be still valid at a certain moment in time. The body of the SIP message contains the location of the media destination for that specific entity which for symmetric traffic is also the location of the media source for that specific entity.

Considering as example for a possible body of SIP an SDP block, also previously presented, that could be generated by an end device or by the processing in the COMMDEVICE of one end device:

v=0 . o=mco 2890844526 2890842807 IN IN4 10.147.65.110 S=SIP initiated call t=2873397496 2873404696 m=audio 1420 RTP/AVP 80 0 24 C=IN IN4 193.47.56.211

It states that the end-device could accept media at the address 193.47.56.211 on the port 1420, thus leaving the opportunity for the COMMDEVICE to prioritize, as media the traffic received for that specific IP address - port pair. The numbers 80 0 24 on the media line in the SDP ( "m=" ) , denote the coding styles supported by the end-user, which denote the bandwidth consumed by the media flow, thus enabling an appropriate dynamic prioritization, pertaining to the type of traffic and also to the bandwidth consumed.

By prioritizing the media traffic, packet loss and delay on the media streams due to congestion on the COMMDEVICE is eliminated making the system more robust to denial of service attacks .

The rest of the traffic is classified according to the common behaviour and quality of service requirements. This method proposes a low delay for SIP messages in the disadvantage of the other possible data streams, for a fast and reliable signalling.

Compared to static prioritization, the described method has the advantage of a more efficient use of the bandwidth based on the momentary conditions of the environment, e.g. the number of users having simultaneous media sessions. Also it is not agnostic to the traffic as other dynamic methods, being able to provision the information flows with a specific priority from the initiation moment.

Optimized Method of Address Translation Overpassing by Dynamically Binding the SIP Processing and Address Translation Functions

By direct binding of the address translator with the SIP processing, a smaller logistic has to be used and a more adequate processing and resource allocation, optimizing the usage of the network bandwidth and local resources consumption. The address translator and the SIP processing are correlated in order to create a mapping before the media session is started either by introducing a logic of address translation in the COMMDEVICE, or by communicating with an exterior address translator, thus a higher level of performance is obtained.

This mapping is done by inquiring the address translator of the address that could be given for the local address-port location on the exterior interface and also to reserve that address for a possible future use in a media session. With the response received from the address translator, the address and the port where the media session is received are modified accordingly in the body of the SIP message.

Another possible solution is to preallocate an address-port on the external interface and to instruct the address translator to bind the local address-port pair with the one preallocated in the COMMDEVICE software.

In both situations the address translator can be implemented directly on the networking level of the message processing stack, thus the media messages do not pass through another application like in the model of the Media Relay, but are forwarded directly to the appropriate destination. This method reduces the logistic necessary for processing the media messages, therefore reducing the latency and the processing power consumed on the COMMDEVICE for media streams .

No other messages are necessary to be sent to any other external entity for obtaining address translation knowledge as in the STUN model, reducing the consumption of bandwidth and making possible the usage of end devices that are not STUN compliant.

By having the knowledge of the SIP messages, the Address

Control Component of the COMMDEVICE is able, to dynamically eliminate the address binding in the address translator when the appropriate SIP message is received or when the media connection fails to supply a minimum number of messages, enabling the COMMDEVICE to liberate the resources involved in address translation on the SIP end-of-session signalling, without considering any waiting time as an Application Level Gateway does .

Method for Minimizing the SIP Communication by Considering Partial Local Registration of Users

In order to reduce this signalling overload on the exterior links, COMMDEVICE intercepts and caches incoming registrations. By keeping a local binding containing registration times for all the local users, the COMMDEVICE gives, using its own "Hybrid Registrar" part, in a transparent manner, the same functionality as a SIP Registrar for the end devices and acts as a SIP client to the SIP Registrar which provides the service for the user of the end device .

With SIP an end device user needs to register himself with a SIP Registrar of his media service provider in order to be reachable by other users . In order to allow the users to utilize the services of such a media provider located in the exterior network, the COMMDEVICE would have to forward all incoming registrations over one of the exterior links to the service provider of the user. Registration messages are sent periodically by the user.

The COMMDEVICE optimization, for the known local users, instead of sending each registration to the external media service provider, only sends the first one and sets the lifetime of the registration to a high number, e.g., one day. Follow-up registrations that only refresh the first one are not forwarded as depicted from Figure 10, reducing SIP signalling over the exterior link and thus the processing time for the SIP messages .

The binding created by the first "REGISTER" request is between a public SIP URI and an address which is part of a local network, by using the "Contact" header field. This field is then modified to contain the public address of the COMMDEVICE system. It is forwarded to the service provider of the user, which creates in its database an entry binding the general SIP URI to the public address of the COMMDEVICE system. Therefore requests coming from third party entities will be routed by the user's service provider to the COMMDEVICE box from where, with help from the user database are forwarded to the local end device, enabling the establishment of media sessions . Such a scenario is illustrated in Figure 11. The user of the local end device with the address 10.147.65.110 and with the SIP signalling port 5060, tries to register with the general SIP URI raarius@fraunhofer.de. The Hybrid Registrar of COMMDEVICE memorises a binding between the general SIP URI and the particular local address of the end device. The request is then forwarded to the SIP Registrar of the specific user, in this case to fraunhofer.de domain containing as address of the remote phone one of the exterior address of the COMMDEVICE which is registered in the user location database of the Registrar. For maintaining of transparency, the response received by the end device is altered as to contain the local address. If exterior entities want to contact the user from the local network, their request reaches the SIP Registrar containing as destination address the general SIP URI marius@fraunhofer.de. The registrar finds in the binding as destination address 193.175.135.177:5060 representing the address of the SIP Registrar proxy and sends the message to it. The "Hybrid Registrar" of the COMMDEVICE finds user marius@fraunhofer.de binded to the local end device's address and forwards the message to this address.

By using this replacement mechanism of the address. of the local network end device with the one exterior address of the COMMDEVICE, the proxying of the SIP requests regarding session signalling is done in a transparent manner and using a minimal number of messages for all implied parties. Thus for an exterior entity all the end devices of the local network appear as having one address from the set of exterior addresses of the COMMDEVICE.

Method for Protecting Local Communications of Exterior Interfering by SIP Message Path Reduction

By having behaviour of SIP Hybrid Registrar as described above for the local end devices, all the media session signalling in between two such end devices becomes internal to the local network, as depicted in Figure 12. No message is sent to any SIP Proxy or any SIP Registrar, which provides service to the user of the end device, as it happens in the common SIP scenarios. Thus the sessions that take place in the local network, Local-to-Local sessions, are completely invisible to any exterior entity.

For the rest of the sessions, Local-to-Exterior and Exterior- to-Local, the COMMDEVICE acts as a SIP Proxy that modifies SIP messages in order to reach their intended destination and in a transparent manner to all the parties involved.

Considering the method of processing SIP messages here stated and multiple hierarchical levels of COMMDEVICES, the length of the signalling path is reduced to the minimum, thus the trust in the network environment is reduced to the minimal routable path as depicted in the example from Figure 13.

Method for Dynamic Control of SIP Retransmission Timers by Session Management

The Session Manager logical entity in a COMMDEVICE enables the system to dynamically set the SIP retransmission timers to values appropriate for the types of links that are involved in the SIP transactions. The messages sent by one end device that become redundant because of the properties of the exterior connection, like increased delay, congestion etc. are filtered by the COMMDEVICE.

They are also re-considered if the other parties involved in the transaction did not have an appropriate response in a specified amount of time. The redundancy is computed considering the retransmission properties of a previous SIP transaction in a certain session and the redundancy observed in previous sessions using the same signalling path, thus being adaptable to dynamic environment changes. In summary the invention is concerned with the establishment of an advanced IP-based communication infrastructure, compatible to the current network and multimedia communication standards (e.g. IPv4, IPv6, TCP/UDP, SIP etc.) that optimizes the communication by various means to enhance support of multimedia communication under limited connection conditions, e.g. limited bandwidth, number of available addresses, delay control etc. Furthermore, the system supports the provisioning of a hierarchical model while maintaining a transparent functionality for all entities involved.

In Fig. 14 and 15 the effect of using an embodiment applying the dynamic prioritization method is described. In Fig. 14 a typical situation of a communication between Alice and Bob is shown. Alice wants to transmit Voice-over-IP data packets (A) to Bob via the Internet. Some server, here called BOX connects Alice to the internet. Also connected, to this server is at least another user, Charlie. Charlie also transmits or receives data packets (pictured as black boxes) to or from the Internet, which are not belonging to a Voice-over-IP transmission or any other multimedia communication transmission that is known to the COMMDEVICE. The concurrent processing of the data packets from Alice and Charlie leads to the dropping and/or delaying of data packets from Alices transmission to Bob. Since the Data from Alice to Bob is Voice-over-IP, the quality of the voice transmission suffers dramatically.

In Fig. 15 the effect of the dynamic prioritization is demonstrated, by showing the beneficial effect of optimizing the server with a COMMDEVICE according to the invention. The COMMDEVICE, after extracting information about the multimedia coding algorithm out of the SIP messages sent by Alices communication device and out of it calculating the actual transmission bandwidth needed, is able to dynamically adapt the data streams such that Alice retains a stable transmission rate for her communication with Bob, which is critical to have a functioning Voice-over-IP transmission. A decreased data transmission for Charlie is acceptable since the data download can be achieved at lower speed.

Claims

1. Communication device with at least one signalling data input comprising at least one SIP message, a data input , a selector for the signalling data for scanning or filtering the signalling data according to at least one predefined signalling policy, a filter for the dynamical discrimination of the data input according to at least one signal received from the selector, a service device acting on the discriminated data input according to at least one data policy.

2. Communication device according to claim 1, whereas the at least one data input comprises media data, voice data, functional data, imaging data, textual data, music data.

3. Communication device according claim 1 or 2 , whereas the at least one data input comprises IP data, especially TCP/IP or UDP/IP data.

4. Communication device according to at least one of the preceding claims, whereas the at least one predefined policy comprises a list of known users for a service.

5. Communication device according to at least one of the preceding claims, whereas the at least one data policy comprises the dynamically prioritization of the at least one data stream by using data from the at least one SIP message .

6. Communication device according to at least one of the preceding claims, whereas the at least one data policy comprise an optimization of the address translation overpassing.

7. Communication device according to at least one of the preceding claims, whereas the at least one data policy comprises the protection of local communication from exterior interference .

8. Communication device according to at least one of the preceding claims, whereas the at least one signalling policy comprises the minimization of the SIP communication by considering partial local registration of users .

9. Communication device according to at least one of the preceding claims, whereas the at least one signalling policy comprises the protection of local communication from exterior interference .

10. Communication device according to at least one of the preceding claims, whereas the at least one signalling policy comprises the static prioritization of the at least one data stream by using data from the at least one SIP message.

11. Communication device according to at least one of the preceding claims, whereas the at least one signalling policy comprises dynamic control of SIP retransmission timers by session management.

12. Communication device according to at least one of the preceding claims, whereby the device is portable.

13. Use of a communication device according to one of the preceding claims in an IP telephony network.

14. Communication method in which at least one signalling data input comprising at least one SIP message is processed by a selector for scanning or filtering signalling data according to at least one predefined signalling policy, and a data input is processed with a filter for the dynamical discrimination of the at least one data input according to at least one signal received from the selector and a service device acts on the discriminated data input according to at least one data policy.

15. Communication method according to claim 14, whereas the at least one data input comprises media data, voice data, functional data, imaging data, textual data, music data.

16. Communication method according to claim 14 or 15, whereas the at least one data input comprises IP data, especially TCP/IP or UDP/IP data.

17. Communication method according to at least one of the claims 14 to 16, whereas the at least one predefined policy comprises a list of known users for a service .

18. Communication method according to at least one of the claims 14 to 17, whereas the at least one data policy comprises the dynamically prioritization of the at least one data stream by using data from the at least one SIP message.

19. Communication method according to at least one of the claims 14 to 18, whereas the at least one data policy comprise an optimization of the address translation overpassing.

20. Communication method according to at least one of the claims 14 to 19, whereas the at least one data policy comprises the protection of local communication from exterior interference.

21. Communication method according to at least one of the claims 14 to 20, whereas the at least one signalling policy comprises the minimization of the SIP communication by considering partial local registration of users.

22. Communication method according to at least one of the claims 14 to 21, whereas the at least one signalling policy comprises the protection of local communication from exterior interference.

23. Communication method according to at least one of the claims 14 to 22, whereas the at least one signalling policy comprises the static prioritization of the at least one data stream by using data from the at least one SIP message.

24. Communication method according to at least one of the claims 14 to 23, whereas the at least one signalling policy comprise dynamic control of SIP retransmission timers by session management.