Patent Application
20120106348
The present invention relates to digital networks, and in particular, to delivering and managing reliable delivery of RTP streams.
Digital networks have rapidly become the backbone of many enterprises, small and large. Such networks are used for handling many different kinds of traffic. The RTP (Real-time Transport Protocol), as defined in RFC 1889 and RFC 3550 defines handling of streaming media commonly used for voice, video, telephony, and the like.
Many applications which use RTP to deliver streaming media such as voice or video perform end-to-end encryption on their signaling sessions, which render Application Level Gateways (ALGs) as part of firewalls useless. Encryption of RTP streams defeats attempts to recognize RTP streams based on simple pattern recognition and/or regular expression matching of RTP payload data, as encryption makes those RTP payloads unavailable for deep packet inspection. Additionally, identifying RTP packets just based on the protocol header fields can lead to false positives due to small static header patterns. An RTP recognition process needs to consider the recurring fields in the subsequent RTP packets to ensure determinism in RTP identification process.
What is needed is a way to improve handling of RTP streams passing through networks.
The invention may be best understood by referring to the following description and accompanying drawings that are used to illustrate embodiments of the invention in which:
Embodiments of the invention relate to methods of improving the handling of RTP streams in digital networks.
According to the present invention, a switching device in a digital network such as a controller, bridge, or access point examines streams flowing through the device. When the device detects that a session has been initiated, the device monitors the initial UDP packets of that stream until a predetermined number of packets have been monitored. The device monitors and fingerprints the header portion of UDP packets, looking for RTP header bit patterns, ignoring certain RTP packet types, and caching others. This fingerprinting process continues, attempting to match cached packet header information against subsequent packets in the stream to detect RTP streams deterministically. If the stream is determined to be an RTP stream, then the RTP type from the packet header is used to tag the stream. In one embodiment, such tags are QoS tags. Tagging may also be based on the control session port used.
Client devices 200 have similar architectures, chiefly differing in input/output devices; a laptop computer will usually contain a large LCD, while a handheld wireless scanner will typically have a much smaller display, but contain a laser barcode scanner.
The present invention deals with RTP (Real-time Transport Protocol) data streams, as defined in RFC 1889 and RFC 3550 and incorporated herein by reference. RTP streams are typically used for the end-to-end transport of streaming media in real time, such as voice and/or video. RTP is based on UDP, a connectionless protocol. UDP is a simple transmission protocol, defined in RFC 768, without implicit hand-shaking dialogs for providing reliability, packet ordering, or data integrity. It is understood that UDP provides a service without reliability guarantees, and that UDP datagrams may arrive out of order, appear duplicated, or go missing without notice, assuming that error detection and correction if any is either not necessary or is performed in the client application.
It is common for applications using RTP streams to encrypt the payload portion of the RTP packet, leaving only the RTP header available for inspection. This encryption, such as applied by applications such as Microsoft OCS or SIP-over-IPSEC, cause methods of identifying RTP streams by deep packet inspection of RTP payloads to fail. Additionally, attempting to identify RTP packets just based on the protocol header fields can lead to false positives due to small static header patterns. An RTP identification process needs to consider the recurring fields in the subsequent RTP packets to ensure determinism in RTP identification process.
According to the present invention, a network device such as a controller, bridge, or access point monitors the traffic it is carrying to detect and tag RTP streams. Packets are fingerprinted and cached, the cached information being used to determine if the stream is an RTP stream.
The device monitors UDP packets for the session until a predetermined packet count has been reached. Additional optimization can be applied, by triggering the detection based on the initiation of active control sessions, for example, control sessions which are pre-configured on ports that the server listens on for SIP clients such as TCP:2000 or TCP:5060. In one embodiment, initial packets such as STUN, TURN, and ICE which are used to establish NAT traversal are ignored.
As part of the fingerprinting process, packets which match RTP header bit patterns are cached. This cached information includes selective RTP header information on the RTP flow state such as SSRC, CSRC, and RTP type. The entire packet may be cached, or just the header portion of the packet header containing the fingerprinted information may be cached.
These cached packets for the stream are used to try and match subsequent packets in the stream to determine if the stream is an RTP stream or not.
If a predetermined number of matches occur, the stream is identified as an RTP stream.
Once the stream has been identified as an RTP stream, the RTP type field from the RTP header may be used to tag packets belonging to the stream. As an example, QoS (Quality of Service) tags may be added to speed reliable delivery of RTP streams identified as video or voice streams. The type of tag applied may also depend on the control session port.
The present invention may be realized in hardware, software, or a combination of hardware and software. The present invention may be realized in a centralized fashion in one computer system such as AP 100, or in a distributed fashion where different elements are spread across several interconnected computer systems. A typical combination of hardware and software may be a controller or access point with a computer program that, when being loaded and executed, controls the device such that it carries out the methods described herein.
The present invention also may be embedded in nontransitory fashion in a computer program product, which comprises all the features enabling the implementation of the methods described herein, and which when loaded in a computer system is able to carry out these methods. Computer program in the present context means any expression, in any language, code or notation, of a set of instructions intended to cause a system having an information processing capability to perform a particular function either directly or after either or both of the following: a) conversion to another language, code or notation; b) reproduction in a different material form.
This invention may be embodied in other forms without departing from the spirit or essential attributes thereof. Accordingly, reference should be made to the following claims, rather than to the foregoing specification, as indicating the scope of the invention.
