WO2012057703A1 - En-tête de protocole en temps réel de taille réduite - Google Patents

En-tête de protocole en temps réel de taille réduite Download PDF

Info

Publication number
WO2012057703A1
WO2012057703A1 PCT/SG2010/000414 SG2010000414W WO2012057703A1 WO 2012057703 A1 WO2012057703 A1 WO 2012057703A1 SG 2010000414 W SG2010000414 W SG 2010000414W WO 2012057703 A1 WO2012057703 A1 WO 2012057703A1
Authority
WO
WIPO (PCT)
Prior art keywords
information
receiver
packets
packet
call
Prior art date
Application number
PCT/SG2010/000414
Other languages
English (en)
Inventor
Chih-Hsiang Chou
Original Assignee
S I2I Limited
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by S I2I Limited filed Critical S I2I Limited
Priority to PCT/SG2010/000414 priority Critical patent/WO2012057703A1/fr
Publication of WO2012057703A1 publication Critical patent/WO2012057703A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]

Definitions

  • the present invention relates generally to packet communications and, more particularly, to reducing the size of a real-time transport protocol (RTP) header in a real time data packet without affecting the network compatibility of the packet.
  • RTP real-time transport protocol
  • VoIP Voice over Internet Protocol
  • VoIP is a protocol suite based on the well known Transport Control Protocol/Internet Protocol (TCP/IP) that enables setting up and conducting voice conversations through the Internet.
  • TCP/IP Transport Control Protocol/Internet Protocol
  • each packet can contain headers such as a User Datagram Protocol (UDP), TCP, IP and RTP headers that carry certain information about the data packet including data that is encapsulated within larger packets.
  • UDP User Datagram Protocol
  • IP IP
  • RTP is the standard protocol used to transmit and receive voice in the form of RTP packets.
  • the conventional RTP header as set forth, for example, in Internet Engineering Task Force (IETF), Request for Comments (RFC) 3550, can be defined as shown in FIG. 1 , each RTP packet 100 has at least a 20-byte IP header 110, an 8-byte UDP header 120, a 12-byte RTP header 130, followed by various number of voice frames in a voice sample 140.
  • IETF Internet Engineering Task Force
  • RRC Request for Comments
  • voice sample 140 is indicated as a variable size, the size of voice sample 140 is governed by the codec device used to perform voice compression from native or raw voice data with different codecs generating different voice data. It will be noted that for a given codec, the size of the voice sample 140 is generally the same.
  • RTP packet size IP + UDP + RTP + FrameSize * n EQ (1)
  • IP is the number of IP bytes or 20 in the present example
  • UDP is the number of IDP bytes or 8 in the present example
  • FrameSize * n (FrameTime * n).
  • Table 1 shown below, lists the bandwidth requirement of a few popular codecs used to convert voice data into packet compatible data for transmission in a VoIP system. The table shows the various requirements for different number of voice frames. It should be noted that the units shown below for the values of FrameSize are expressed in bytes,
  • FrameTime is expressed in milliseconds and Bandwidth is expressed in kilobits per second.
  • GSM 33 20 29.20 21.20 18.53 17.20 iLBC 20 38 20 31.20 23.20 20.53 19.20 iLBC 30 50 30 24.00 18.67 16.89 16.00
  • the more voice frames in a packet the less bandwidth is required to transmit or receive a VoIP stream.
  • the time interval between two RTP packets increases leading to voice quality problems associated with network impairment brought about by phenomena such as packet loss, latency, jitter, and the receipt of packets in a sequence that deviates from the original order, or so-called "out of order" packets, which is particularly troublesome for real time applications.
  • the number of voice frames is set to between 2 and 4,
  • One solution is to perform header compression. Note that since the voice frames are already compressed, there is little to no improvement by compressing them again. Further, by compressing the combined IP/UDP/RTP header, compatibility issues may arise that makes such a solution undesirable. Compression schemes have been proposed for the RTP header such as those set forth in the IETF RFC 2508 and RFC 3545, whereby the RTP header is compressed and only a first order delta value is sent reflecting a difference between the current value and the previous value or a reference value.
  • Synchronization problems can arise however that can seriously degrade the quality of, for example, a real time voice call. If a packet or packets are lost, the delta values of received packets are added to the previous context twice or more to approximate or simulate the change that would have occurred if the missing packets had arrived. Another proposed solution is to add redundancy to RTP packets as recommended by RFC 2198. In the case of packet loss, the lost information can be recovered from the next packet received. But adding redundancy increases the bandwidth usage. [00011] Further, each VoIP call requires a unique UDP port opened at the receiver side. Since receivers that are behind a firewall typically allow only one or a few ports opened to receive calls, calls in excess of the number of ports allowed by the firewall cannot be handled.
  • first information is extracted from a header of a packet in a real time communication stream associated with the call.
  • the first information is associated with fields in each of the headers of packets of the real time communication stream that do not change during the call.
  • the first information is sent in a command packet at the beginning of the call to provide the receiver with the first information for purposes of preparation to receive the reduced size packets and to perform other parameter passing and the like.
  • the receiver can be configured for receiving the packets whereupon the command packet is received at the receiver.
  • the packets of the real time communication stream are encoded by including reduced versions of second information in the header, such as information that does change during the call, and eliminating the first information from the header in the packets so as to reduce the size of the packets and reduce the bandwidth requirement for the call.
  • the encoding can be carried out by reducing the second information in two parts.
  • a first reduced second information can be generated by dividing the value of the second information by an increment.
  • the first reduced second information can be further reduced to a second reduced second information equal to a value represented by a number of N bits.
  • the N-bit value covers all possible differences, positive or negative, between the reduced second information of two consecutive packets. To reduce bandwidth, N is chosen as the minimal number of bits satisfying the requirement of covering the largest expected difference magnitude.
  • the maximum value represented by the N bits is greater than an average difference between the reduced second information of two consecutive packets, so as to generate the reduced versions of the second information.
  • the encoded packets are decoded in the receiver according to the first information received in the command packet, which can be resent from time to time when necessary or can be resent periodically whether or not it has been specifically deemed necessary.
  • the command packet can further include the number N of bits to be used to represent the reduced version of the second information.
  • the header can include a real time transport protocol (RTP) header and the first information can include a version (V) field, a padding (P) field, an extension (X) field, a CSRC count (CC) field, a payload type (PT) field, and a synchronization source (SSRC) identifier field.
  • the second information includes a reduced size timestamp field and a reduced size sequence number field.
  • an intermediary apparatus can be provided for reducing a bandwidth requirement for a call between a sender and a receiver in a packet communication system.
  • the intermediary apparatus can include a receiving unit located between the sender and the receiver.
  • the receiving unit transfers packets between the sender and the receiver and extracts first information from a header of a packet in a real time communication stream associated with the call.
  • the first information is associated with fields in the header of packets of the real time communication stream that do not change during the call.
  • An encoding unit can operate on the packets of the real time communication stream to reduce the size of the second information in the header and to eliminate the first information from the header in packets.
  • An encoded reduced size packet header associated with the packets is thereby generated to reduce the bandwidth requirement for the call.
  • the intermediary apparatus can further include a transmission unit that sends the first information in a command packet at the beginning of the call to provide the receiver with the first information.
  • the command packet configures the receiver for receiving the encoded reduced size packet headers associated with the packets, for example, according to the first information received in the command packet.
  • the command packet further includes the number N of bits to be used to represent the reduced version of the second information [00019]
  • the encoding unit operates on the packets to reduce the second information by generating a first reduced second information by dividing the value of the second information by an increment.
  • the first reduced second information can be further reduced to a second reduced second information equal to a value represented by a number of N bits, such that the maximum value represented by the N bits is greater than an average difference between the reduced second information of two consecutive packets, so as to generate the reduced versions of the second information.
  • FIG. 1 is a diagram illustrating an exemplary packet format including IP, UDP, and RTP headers
  • FIG. 2 is a diagram further illustrating an exemplary packet format
  • FIG. 3 is a diagram illustrating a conventional header compression scheme
  • FIG. 4 is a diagram illustrating an exemplary reduced size packet format in accordance with one or more embodiments
  • FIG. 5 is a diagram illustrating an exemplary packet format including redundant headers in accordance with standards and one or more embodiments;
  • FIG, 6 is a diagram illustrating a exemplary reduced size packet format including redundant headers in accordance with one or more
  • FIG. 7 is a diagram illustrating various exemplary configurations for sender, receiver and an intermediary in accordance with one or more
  • FIG. 8A is a diagram illustrating an exemplary sender hardware configuration in accordance with one or more embodiments.
  • FIG. 8B is a diagram illustrating an exemplary sender hardware configuration in accordance with one or more embodiments.
  • VoIP, communications over limited bandwidth channels can be enhanced by a method and apparatus for reducing the size of an RTP header.
  • Various exemplary embodiments are described herein that reduce the bandwidth requirement by reducing the voice packet size. It will be appreciated that a VoIP call, particularly a wide ranging or international call generates real time packets that have the potential to traverse many diverse infrastructures within a single network "cloud.” Since the ability to maintain compatibility and to interoperate with other Internet devices and to traverse nodes having different infrastructures and thus different bandwidth requirements, no changes can be made to the IP and UDP headers. The remaining option to reduce overall packet size to reduce the size of the RTP header.
  • a reduced size header can be generated/encoded from the sender side and decoded at the receiver side. It will be appreciated however, that in a normal VoIP call, packets flow bi- directionally since each side of the call functions as both a sender and a receiver. In such a configuration, each side may independently apply or not apply a reduced size header in accordance with embodiments. For simplicity and illustrative purposes, the following description fill focus one direction of an exemplary call, such as from the caller or sender to the receiver, but it will readily be appreciated that the invention can be applied to both directions of a call independently.
  • embodiments can be implemented in the packet sending and receiving modules of the caller and proxy.
  • the proxy converts a packet from a reduced size header format to a standard RTP format then sends the packet on to the receiver, so as to maintain compatibility with the rest of the world.
  • a proxy can convert a packet originating from a receiver in the standard RTP format to the reduced size header format and can then send the packet on to the caller. If the reverse direction also applies the invention, then packets can be transferred with far greater efficiency since there is no need for conversion to standard RTP format. [00032] As described in greater detail herein below, various methods to reduce the RTP header size will be described, with greater or lesser
  • the methods support operation with firewalls having limited open ports and with encrypted content. It will also be noted that in order to enable one of skill in the art to practice the invention and to describe what the applicant considers as the invention, necessary instructions, algorithms, protocols and the like that are used to encode and decode inventive RTP headers as described herein, are provided. The encoding and decoding are provided such that no RTP header information is lost when it is reconstructed on a receiver side.
  • the RTP header can be defined, as outlined in RFC 3550, in the illustrated formats.
  • RFC 3550 a detailed version of an exemplary RTP header 200 is shown with the various fields. It should be noted that the first twelve octets, representing fields 201-209 are present in every RTP packet.
  • the fields can be defined as follows.
  • the version field, V 201 is a 2 bit identifier that identifies the version of RTP.
  • the version defined by RFC 3550 is, for example, version 2.
  • the padding field, P 202 is a flag bit that indicates, if set, that the packet contains one or more additional padding octets at the end which are not part of the payload including a count of how many padding octets should be ignored. Padding may be needed by some encryption algorithms with fixed block sizes or for carrying several RTP packets in a lower-layer protocol data unit.
  • the extension bit, X 203 indicates, if set, that the fixed header MUST be followed by exactly one pre-defined header extension.
  • the CSRC count field, CC 204 is a 4 bits field that contains a count of the number of CSRC identifiers that follow the fixed header.
  • the marker bit, M 205 is a 1 bit field the interpretation of which is defined by a profile. M 205 is intended to allow significant events such as frame boundaries to be marked in the packet stream.
  • the payload type field, PT 206 is a 7 bit field that identifies the format of the RTP payload and determines its interpretation by the
  • the sequence number 207 is a 16 bits value that increments by one for each RTP data packet sent during a session and may be used by the receiver to detect packet loss and to restore packet sequence.
  • the timestamp 208 is a 32 bit timestamp that reflects the sampling instant of the first octet in the RTP data packet. It should be noted that according to the standard, the sampling instant must be derived from a clock that increments monotonically and linearly in time to allow synchronization and jitter calculations. RTP timestamps from different media streams may advance at different rates and usually have independent, random offsets. Therefore, although these timestamps are sufficient to reconstruct the timing of a single stream, directly comparing RTP timestamps from different media is not effective for synchronization.
  • the synchronization source identifier, SSRC 209 is a 32 bit field that identifies the synchronization source.
  • fields 201-204, 206 and 209 can be removed from RTP headers associated with an in-progress.
  • the contents of fields 201-204, 206 and 209 can be sent once to the receiver at the beginning of a call session.
  • the contents can be sent in an intact RTP packet or can be established in another manner such as through the use of pre arranged values, profiles as set forth in RFC 3550, or the like.
  • the M 205 field, the SN 207 and the TS 208 fields that can change in every packet are included.
  • the RTP header size can be reduced from 96 bits to 49 bits.
  • the number of bits of a reduced value of VALJINC can be further reduced to an arbitrary number of N bits as long as the difference of VALJINC in two consecutive packets is not greater than N-1 bits.
  • N must provide for a magnitude that is greater than or equal to a greatest expected difference magnitude between the reduced second information of two consecutive packets, so as to be capable of generating all the possible difference values while still representing a reduction in the number of bits required to provide the second information.
  • SN 207 and TS 208 are two independent sequences represented by certain number of bits as described herein above.
  • the number of bits used to convey each of the values represented by SN 207 and TS 208 can be independently reduced.
  • the original RTP header size is advantageously reduced from 96 bits to NSN+NTS +1 bits.
  • a fixed format is not required in connection with the reduced header. Rather embodiments can be implemented based on values for N S N and NTS that are appropriate for the requirements. Further, the information can be arranged in whatever format and order within the reduced header is suitable.
  • FIG. 4 illustrates an exemplary one of many possible embodiments of a reduced size RTP header format.
  • Exemplary reduced RTP header 400 can include marker field 401 , a reduced size sequence number field 402, a reduced size time stamp field 403, immediately followed by voice data fields 404.
  • Table 2 shown below lists the reduced bandwidth requirement when the reduced RTP header can be fit into two bytes. Note that the reduced header now enables G.729a with four or more frames and G.723.1 with any number of frames to be sent over the GPRS uplink.
  • GSM 33 20 25.20 19.20 17.20 16.20 iLBC 20 38 20 27.20 21.20 19.20 18.20 il_BC 30 50 30 21.33 17.33 16.00 15.33
  • RTP header reduction can be accomplished through, for example, the use of a software module that receives a stream of packets and encodes them according to the exemplary routines set forth herein below.
  • a sequence encoding algorithm can be defined, using a C language construct, as follows typedef unsigned int uint;
  • a sequence decoding algorithm can be defined, using a C language construct, as follows /* Return the true value of the given encoded libit value en_val. prev_val is the decoded true value before this one in a sequence. prev_val should be 0 for the first call to decode a sequence. INC is the minimum increment of true vale in a sequence.*/
  • NBitVal prev_en_val encode (prev_val, N, INC); //previous encoded value
  • the decoding algorithm can advantageously return, for example, a correct sequence value or time stamp value, even if previous packets are lost, as long as the magnitude of the difference between VALJINC of the present packet and the previously received packet is not greater than N-1 bits.
  • a correct sequence value or time stamp value can be returned, for example, a correct sequence value or time stamp value, even if previous packets are lost, as long as the magnitude of the difference between VALJINC of the present packet and the previously received packet is not greater than N-1 bits.
  • uint val[] ⁇ 0, 3, 2, 5, 8, 6, 9, 12, 14,
  • uint len sizeof(val) / sizeof (uint ) ;
  • de_val %2d ⁇ n" , val[i], en_val, de_val) ;
  • redundant payloads can be used to improve the chances of maintaining synchronization.
  • a redundant header format is defined in RFC 2198 and shown in FIG. 5. Note that the first 12 bytes are exactly the same as those in the normal RTP header. Accordingly, the size of the redundant header can be reduced in the same manner as described herein above including handling of the SN and TS of the primary payload. It should be noted that the remainder of the fields show in FIG.
  • a new format is defined herein to support only one secondary payload, since adding a secondary payload is a common practice.
  • the newly defined format includes fields about the location and mark bit of the secondary payload, as well as differences in sequence number and timestamp between the secondary and primary payloads.
  • the following example in connection with the illustration in FIG. 6 is one of many possible formats or embodiments of reduced RTP header with redundant payload.
  • the header is followed immediately by the primary payload then the secondary payload.
  • the length field gives the length of the primary payload which in turn indicates where the secondary payload starts.
  • the bit m is an independent marker bit for the secondary payload.
  • the next two fields are signed numbers which store the differences in sequence number and timestamp respectively between the secondary and primary payloads. Since these differences have the same minimum and maximum values as those found in RTP header reduction, their lengths can be set to NSN and N T s bits respectively.
  • the timestamp of the secondary payload can be determined by adding the difference to the timestamp of the primary payload [00047] It should also be noted that the same format can be used to support both reduced RTP header with or without redundant payload by setting the length equal to zero when there is no secondary payload. The primary payload then starts immediately after the length field. However, such an approach uses more bits than necessary when compared to the non-redundant format. In
  • a special field can be set forth to identify the format used providing flexibility for expansion and using fewer bits overall.
  • n is the total number of frames in primary and secondary payloads and packet interval becomes FrameTime*n/2.
  • formats have been set forth for sending reduced size packets.
  • the ability of a receiver to properly interpret the reduced packets depends on extracting and sending the information contained in the first portion of the RTP header prior to transmitting reduced size packets.
  • the fields normally eliminated from the reduced size RTP header will be included, at least so far as the content thereof, in the command packet.
  • the command packet can include any kind of data.
  • the length and order of each field in the command packet is unrestricted as long as the format of the command packet is agreed upon in advance between the sender and receiver.
  • the command packet can be intermixed with voice packets in a voice stream. It will also be understood that the command packet can be sent any time when necessary such as in a situation where synchronization appears to have been lost or periodically as a matter of common practice.
  • the command packet is sent as a UDP packet and there is a possibility of packet loss during delivery. Unlike the voice packets with reduced size RTP headers, the data in command packets must be received before normal operation and synchronization between receiver and sender can occur. The sender is therefore required to resend the command packet if an
  • acknowledgement packet is not received from the receiver within certain time limit. If no acknowledgement is received after several attempts, the sender may abort the call session.
  • a common field called packet type can be established that identifies the type of the packet such as command packet, voice packet with reduced RTP header, or voice packet with reduced RTP header and redundant payload.
  • the length of the packet type field should be as short as possible, yet enough to cover all types needed in the future.
  • the packet type field should be at the start of each packet format.
  • each packet type field in a packet Immediately after the packet type field in a packet in accordance with embodiments described herein, are the fields required by each packet type.
  • a certain bit length or order of each field in the reduced size packets, command packet or any packet of the inventive format is not required, provided that the length is as short as possible while covering the possibility of expansion to additional packet types and formats.
  • Fields that affect packet parsing are moved to the front of the packet. For example, the content of a command packet may be further dependent on a field called command type for different actions to be performed by the receiver. Therefore, to facilitate packet parsing, the command type field should be located close to the start of the command packet.
  • firewall can refer to a device near a proxy or receiver. From the perspective of the sender, both are in the cloud. The packets from a sender must pass the firewall before it can reach a proxy then to the receiver. If no proxy is used for the call, then the firewall can be located near the receiver side as would be understood to be the case for most enterprise and home configurations. In other words, regardless of the individual circumstance, the call destination, whether the receiver directly or the receiver through a proxy, is located behind or protected by a firewall.
  • the sender of packets associated with a call session is required to include the original destination port information in a command packet sent at the beginning of the call session.
  • the receiver Upon receiving the command packet, the receiver extracts the original destination port and adds an entry to a lookup table that provides a mapping from the sender's IP address and port to the original destination port. Thereafter, when a voice packet is received at the common destination port, the original destination port can be easily found and the packet directed by looking up the table with the sender's IP address and port.
  • the sender could include the original destination port in every voice packet sent to the common destination port and the lookup table can be eliminated. However, the extra field in every voice packet defeats the objective of reducing packet size.
  • packet content is conventionally protected from unauthorized use by encryption.
  • An agreed upon private key is usually used to encrypt and decrypt the packet content. If the key is the same for all calls, then there is no need to pass or keep the key separately for each call. The whole packet can be encrypted and decrypted easily. However, if the key varies for different calls there is a need to pass and keep the key efficiently on a per call basis and to find the key associated with a call when an encrypted command or voice packet is received.
  • the sender must pass the key in one of the fields of the command packet sent to the receiver.
  • the command packet must not be encrypted such that it can be easily retrieved by the receiver. If a firewall is in place, the original destination port can also be easily retrieved from the command packet.
  • the receiver can then associate the key with the actual destination port. Thereafter, all packets sent can be fully encrypted, including command packets, as long as the key does not change. It should be noted that in systems that require the first command packet to be encrypted, but no firewalls are involved, the sender must pass the key and original destination port to the receiver via a separate channel before sending any command or voice packets.
  • the key and original destination port can be passed from a SIP proxy to the receiver during a call signaling phase. After the key and port have been received, any packets thereafter can be fully encrypted by the sender and decrypted by the receiver with reference to the key and the original destination port.
  • the sender In systems that require the first command packet to be encrypted and a firewall with limited open ports is involved, the sender must pass the key and original destination port to the receiver via a separate channel before sending any command or voice packets.
  • the key and original destination port can be passed from a SIP proxy to the receiver during call signaling phase. After that, any packets can be fully encrypted except the original destination port in the first command packet.
  • the receiver Upon receiving the first command packet at the common destination port, the receiver can retrieve the original destination port without decryption first and an entry to a lookup table can be added. Thereafter, the lookup table can be used to find every encrypted packet's original destination port, and the associated key such that the receiver can decrypt the packet.
  • an intervening or apparatus can be placed between the sending and receiving node, whatever form they may take.
  • the sending and receiving nodes can be network gateways individual communication nodes such as phones or the like, or any combination of sending and receiving nodes or devices.
  • an intervening apparatus can be, for example, an audio proxy server or the like as set forth in U.S. Patent No. 7,417,978 and U.S. Patent No. 7,346,044, the contents of which are incorporated herein by reference.
  • header size reduction can be implemented as described herein in the packet sending and receiving modules of an exemplary proxy that is configured to handle the proprietary format.
  • the proxy can convert from a reduced header size proprietary format to standard RTP header format and then send packets on to a conventional receiver.
  • an exemplary proxy can convert from a standard RTP format received from a conventional sender to the reduced header size proprietary format described herein and then send the packet to a receiver configured to decode the proprietary format.
  • the proxy can forward the packets more efficiently in each direction due to the compressed size and any additional configuration capability such as flow streaming or the like.
  • sender 710 can be coupled to sender 720 through an intermediary 730 containing, for example, proxy 731 that can be configured to encode and decode packets as described herein when one of the sender or receiver is configured to perform RTP header reduction as described herein.
  • proxy 731 can pass through encoded communication in the event that both the sender 710 and the receiver 720 are both configured to encode and decode packets with RTP header reduction and encoding as described herein.
  • sender 710 and receiver 720 can be coupled through an intermediary 740, which can include two proxy units 741 and 742.
  • Proxy unit 741 can receive packets from sender 710, encode the packets and send them to proxy 742, which can concurrently encode and send packets toward proxy unit 741 to sender 710 from receiver 720.
  • Proxy 742 can further decode encoded packets from proxy 741 and send them on to receiver 720.
  • Proxy 741 can decode the packets received from proxy 742 and send them on to sender 710.
  • sender 710 and receiver 720 can be coupled through an intermediary 750, which can include two networks 751 and 753 and a proxy 752.
  • the networks may include network gateway hardware, may be dissimilar and may, for example, use different codec or the like.
  • intermediary 730 the configuration is most helpful when one of the nodes is configured to send and receive packets with reduced RTP headers and the other is not.
  • sender 710 and receiver 720 can be coupled through an intermediary 760, which can include two networks 761 and 764 and two proxies 762 and 763.
  • intermediary 740 the proxies 762 and 763 can gain efficiencies by encoding and sending toward each other with reduced bandwidth requirements. It will also be appreciated that such an advantage can be important when, for example, a network cloud (not shown) is inserted between the proxies 762 and 763.
  • FIG. 8A. and FIG. 8B To better appreciate the construction of an exemplary sender and receiver in accordance with embodiments, reference is made to FIG. 8A. and FIG. 8B. Of course it will be understood that in embodiments, the sender and the receiver are embodied within the same device, such as a phone or radio handset and that communications are bidirectional such that when a sender is
  • transmitting information it can also be configured to receive information associated with the same call subject to the individual protocol or protocols involved.
  • a packet can be transmitted according to physical layer protocols over an air interface 814 through an antenna or the like 813.
  • the signal conversion from digital baseband to intermediate and higher frequency including amplification can be accomplished using an RF module 812.
  • the sender unit 801 can be configured with a processor 810, a memory 81 , which are coupled with an interconnection such as a bus 815. It will be appreciated that in embodiments the memory 811 can be integrated with the processor 810. Additional modules can be provided such as an encoding module 830, an encryption module 820 and an internal memory 840.
  • the sender can accomplish encoding in
  • encryption using encryption module 820 using public key encryption such as PKI encryption or the like whereby the receiver, proxy or other registered
  • the sender 801 can also be configured to act as a receiver with little change to the above described hardware and/or software components aside from a change in functionality or a corresponding functional operation.
  • the encryption module 820 can be configured to decrypt received packets that are encrypted
  • the encode module 830 can be configured to decode received packets that are encoded and the like.
  • an exemplary receiver unit 802 can be provided with similar elements as shown in FIG. 8B. However, it will be understood that while the transmitter and receiver are described herein as separate units, they can represent functionality and hardware configurations that are included in any device such as a handset device or the like. In other words, a typical handset device in accordance with embodiments will include
  • the receiver unit 802 can include a processor 850, a memory 851 , and an interface module 852.
  • the processor can additionally include a decryption module 854, a decoding module 855, and a memory 856, such as an internal memory.
  • the elements can be interconnected using an interconnection such as, for example, a bus 803 or the like.
  • the memory 851 can optionally be integrated with the processor 850.
  • the interface module 852 can be either an RF conversion module if the receiver device 802 is coupled to an air interface, or can be, for example, a digital broadband interface in the case where the receiver is coupled directly to a digital broadband channel.
  • the receiver unit 802 is coupled wirelessly to a broadband digital channel.
  • packets received from the sender unit 801 can be processed in the decryption module 854 provided that a public key has been received, such as through a command packet received at the beginning of a call session as described herein.
  • the packets can be decoded in module 855, that is, can be processed in accordance with the reduced size RTP header described in accordance with embodiments.
  • the receiver is located behind a firewall, such as firewall 860, which can be associated with a proxy or can be between a proxy and the receiver but are most readily implemented as part of the cloud.
  • a firewall such as firewall 860
  • the firewall must be traversed before the packet can reach the proxy and then the receiver. If no proxy is present, then the firewall is most likely located near the receiver side, such as in connection with a service provider, server or the like, as in most enterprise and home setups. In other words, the proxy and sender are behind or protected by the firewall.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention porte sur un procédé et un appareil destinés à réduire une exigence de bande passante pour une communication entre un expéditeur et un récepteur dans un système de communication par paquets. Des informations sont extraites d'un en-tête d'un paquet dans un flux de communication en temps réel associé à la communication. Les informations sont associées à des champs dans l'en-tête de paquets du flux en temps réel qui ne changent pas durant la communication. Les informations sont envoyées dans un paquet de commande au début de la communication pour fournir les informations au récepteur. Les paquets du flux en temps réel sont codés par inclusion de versions réduites d'informations dans l'en-tête qui change durant la communication et élimination des informations qui ne changent pas durant la communication dans l'en-tête des paquets de manière à réduire la taille des paquets et à réduire l'exigence de bande passante pour la communication.
PCT/SG2010/000414 2010-10-28 2010-10-28 En-tête de protocole en temps réel de taille réduite WO2012057703A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/SG2010/000414 WO2012057703A1 (fr) 2010-10-28 2010-10-28 En-tête de protocole en temps réel de taille réduite

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/SG2010/000414 WO2012057703A1 (fr) 2010-10-28 2010-10-28 En-tête de protocole en temps réel de taille réduite

Publications (1)

Publication Number Publication Date
WO2012057703A1 true WO2012057703A1 (fr) 2012-05-03

Family

ID=45994189

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/SG2010/000414 WO2012057703A1 (fr) 2010-10-28 2010-10-28 En-tête de protocole en temps réel de taille réduite

Country Status (1)

Country Link
WO (1) WO2012057703A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9930570B2 (en) 2013-04-17 2018-03-27 Thomson Licensing Method and apparatus for packet header compression
CN108401263A (zh) * 2017-02-07 2018-08-14 大唐移动通信设备有限公司 一种语音质量的评估方法及装置

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7733867B2 (en) * 2005-08-26 2010-06-08 Alcatel-Lucent Usa Inc. Header compression for real time internet applications

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7733867B2 (en) * 2005-08-26 2010-06-08 Alcatel-Lucent Usa Inc. Header compression for real time internet applications

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
FITZEK, F. ET AL.: "HEADER COMPRESSION SCHEMES FOR WIRELESS INTERNET ACCESS", MOBILE INTERNET: ENABLING TECHNOLOGIES AND SERVICES, 13 April 2004 (2004-04-13), USA, pages 10 - 1 - 10-24 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9930570B2 (en) 2013-04-17 2018-03-27 Thomson Licensing Method and apparatus for packet header compression
CN108401263A (zh) * 2017-02-07 2018-08-14 大唐移动通信设备有限公司 一种语音质量的评估方法及装置
CN108401263B (zh) * 2017-02-07 2021-09-17 大唐移动通信设备有限公司 一种语音质量的评估方法及装置

Similar Documents

Publication Publication Date Title
AU2005206976B2 (en) Method and apparatus for transporting encrypted media streams over a wide area network
US8155090B2 (en) Method and apparatus for efficient multimedia delivery in a wireless packet network
Sze et al. A multiplexing scheme for H. 323 voice-over-IP applications
US7124202B2 (en) System and method for aggregating channel segment ID's into a first section and data segments into a second section
EP1495612B1 (fr) Procede et appareil de transmission efficace de trafic voip
EP1360818B1 (fr) Procede de compression, emetteur et recepteur de communication radio de donnees
US10630656B2 (en) System and method of encrypted media encapsulation
US9148257B2 (en) Method and apparatus for reducing delays in a packets switched network
US7337384B2 (en) Error detection scheme with partial checksum coverage
WO2012057703A1 (fr) En-tête de protocole en temps réel de taille réduite
Al-Mimi et al. Enhancing Bandwidth Utilization of IP Telephony Over IPv6 Networks.
Subbiah et al. RTP payload multiplexing between IP telephony gateways
WO2007039597A1 (fr) Procede et dispositif servant a transporter des services commutes par circuit sur un reseau de transport en mode de paquets
CN117201468A (zh) 一种voip自适应语音编码系统
WO2007106548A2 (fr) Système et procédé de cryptographie de réseau

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 10859042

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205N DATED 04/07/2013)

122 Ep: pct application non-entry in european phase

Ref document number: 10859042

Country of ref document: EP

Kind code of ref document: A1