FIELD OF THE INVENTION [0001] 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.

BACKGROUND [0002] With the continuous advancement of Internet enabling technologies, bandwidths for carrying larger and larger amounts of data also continue to increase. With the increase in overall data capacity, the ability to provide an array of service levels such as real time transport services and the like

correspondingly increases. Such service levels are an important part of providing new capabilities such as streaming media and genuine real time services such as telephony services that use the so-called Voice over Internet Protocol (VoIP). However, as bandwidth increases, so does user demand leading to corresponding bandwidth restrictions and bottlenecks that can disrupt real time packet communications as will be described in greater detail herein below.

[0003] 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. In accordance with TCP/IP, 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. Among the above-described protocols, 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.

[0004] Although 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.

[0005] The size of a RTP packet in 8-bit bytes can be determined by equation (1) RTP packet size = IP + UDP + RTP + FrameSize * n EQ (1) where n is the number of frames, 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, RTP is the number of RTP bys which is 12 in the present example, resulting in a simplified relation where the RTP packet size = 40 + FrameSize ^* n. [0006] Since the length of each voice frame in time is the same for a given codec, the minimal bandwidth required to transmit or receive a VoIP stream of RTP packets with n frames is set forth in equation (2)

Bandwidth = RTP packet size / RTP packet time interval EQ (2)

[0007] Using the exemplary values noted above in connection with EQ (1 ), the bandwidth can be simplified to the expression where Bandwidth— (40 +

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. FrameSize FrameTime Bandwidth (Kbps) of n frames per packet

Codec

(bytes) (mSec)

1 2 3 4

G.711 8 1 384.00 224.00 170.67 144.00

G.723.1 5.3 20 30 16.00 10.67 8.89 8.00

G.723.1 6.3 24 30 17.07 11.73 9.96 9.07

G.729a 10 10 40.00 24.00 18.67 16.00

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

Table 1

[0008] As can be seen, the more voice frames in a packet, the less bandwidth is required to transmit or receive a VoIP stream. However, by having too many voice frames in a packet, 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. In practice, the number of voice frames is set to between 2 and 4,

[0009] While based on modern network speeds, the VoIP bandwidth

requirements described above can usually be met by most Internet service providers (ISP), there are still cases where sufficient bandwidth cannot be provided. One notable example is the 2G GPRS Internet data connection provided by mobile phone service providers. A standard GPRS connection has a maximum transfer rate of 14.4 Kbps for the uplink and 28.8 Kbps for the downlink. Thus, with the exception of G.723.1 , the uplink speed provided by 2G GPRS infrastructures is not sufficient for all codecs listed above. Since there may be infrastructures involved in a VoIP call that cannot meet the bandwidth requirements, problems can arise.

[00010] 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.

[00012] Still other problems may rise in connection with privacy. With the increasing awareness of personal privacy, there is a need to protect the content of a VoIP call from unauthorized access. Privacy can be achieved by encrypting the packet content by a scheme agreed between the sender and receiver.

However, traditional header compression methods have failed to accommodate further encryption. SUMMARY

[00013] Therefore, in view of the above described and other issues, A method for reducing a bandwidth requirement for a call between a sender and a receiver in a packet communication system is provided. [00014] In accordance with one aspect, 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. Accordingly, 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. [00015] In accordance with other aspects, 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.

[00016] It will be appreciated that 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.

[00017] In accordance with another aspect, 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.

[00018] 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] In accordance with various aspects, 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.

BRIEF DESCRIPTION OF THE DRAWINGS [00020] In order that embodiments of the invention may be fully and more clearly understood by way of non-limitative examples, the following description is taken in conjunction with the accompanying drawings in which like reference numerals designate similar or corresponding elements, regions and portions, and in which: [00021] FIG. 1 is a diagram illustrating an exemplary packet format including IP, UDP, and RTP headers;

[00022] FIG. 2 is a diagram further illustrating an exemplary packet format;

[00023] FIG. 3 is a diagram illustrating a conventional header compression scheme; [00024] FIG. 4 is a diagram illustrating an exemplary reduced size packet format in accordance with one or more embodiments; [00025] FIG. 5 is a diagram illustrating an exemplary packet format including redundant headers in accordance with standards and one or more embodiments;

[00026] FIG, 6 is a diagram illustrating a exemplary reduced size packet format including redundant headers in accordance with one or more

embodiments;

[00027] FIG. 7 is a diagram illustrating various exemplary configurations for sender, receiver and an intermediary in accordance with one or more

embodiments; [00028] FIG. 8A is a diagram illustrating an exemplary sender hardware configuration in accordance with one or more embodiments; and

[00029] FIG. 8B is a diagram illustrating an exemplary sender hardware configuration in accordance with one or more embodiments.

DETAILED DESCRIPTION

[00030] In accordance with various exemplary embodiments discussed and described herein, 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. In various embodiments, 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.

[00031] It will also be noted that, as will be described in greater detail hereinafter, due to the proprietary format of the resulting reduced size header, in order to allow communication with receivers that lack the ability to decode reduced size headers, 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.

Conversely, 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

effectiveness at reducing the bandwidth requirement being traded off against supporting redundancy in order to solve the packet loss problem. 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.

[00033] As shown in FIG. 1 , 2, and 3 the RTP header can be defined, as outlined in RFC 3550, in the illustrated formats. With more specific reference to FIG. 2, 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

application. Default payload mappings for audio and video are specified in the companion RFC 3551. A receiver will ignore packets with payload types that it does not understand.

[00034] 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.

[00035] It will be appreciated by one of skill in the art that many fields such as field V 201 , P 202, X 203, CC 204, PT 206, SSRC 209, and, if present, the contributing source CSRC fields, never or seldom change during a single call session. Accordingly, in an embodiment, 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. Subsequently, once the values are established with the receiver, the M 205 field, the SN 207 and the TS 208 fields that can change in every packet are included. By eliminating such redundant information, the RTP header size can be reduced from 96 bits to 49 bits.

[00036] While the above noted reduction in header size can result in close to a 50% reduction in header size, further reduction can be achieved by reducing the number of bits used, for example, in the SN 207 and the TS 208 fields. To better understand the advantages provided in an embodiment, it can be noted that the value of the SN 207 increases in increments of INCSN=1 and the TS 208 increases in increments of INCTS=80. Thus, a reduced value equal to VALJINC can be sent with fewer bits than the full value amount. To interpret the actual value, the receiver multiplies the received reduced value by INC to restore the original true value. 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. In other words, 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.

[00037] By way of example, assuming that an exemplary 32-bit value of VALJINC is known to vary according to fairly consistent parameters as

exemplified by a sequence 0, 3, 2, 5, 8, 6, 9, 12, 14, and 17 from one packet to another. In the noted example, the minimum difference between any two consecutive packets is -2 and the maximum difference between any two consecutive packets is 3. Accordingly, 2 bits will generally be enough to represent all the differences set forth above and a value of N = 3 bits unsigned number will be sufficient to represent the whole sequence without loss of information. The above sequence can be encoded using 3-bit values only as 0, 3, 2, 5, 0, 6, 1 , 4, 6, and 1 saving 29 bits per value, which is clearly significant. [00038] Using the above descriptions of procedures and algorithms, one of skill in the art can construct instructions, logic and the like, represented herein below by actual and generalized exemplary source code descriptions in C to encode and decode a sequence of values. In the present example, a sequence is assumed to start with the value 0 although other values can be used such as a random value or the like according to the descriptions provided, for example, in RFC 3550, as will be appreciated.

[00039] Note that 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. As a result, the original RTP header size is advantageously reduced from 96 bits to NSN+NTS +1 bits. In accordance with embodiments, 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. In accordance with the advantages of the reduced size fields, 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.

FrameSize FrameTime Bandwidth (Kbps) of n frames per packet

Codec

(bytes) (mSec)

1 2 3 4

G.711 8 1 304.00 184.00 144.00 124.00

G.723.1 5.3 20 30 13.33 9.33 8.00 7.33

G.723.1 6.3 24 30 14.40 10.40 9.07 8.40

G.729a 10 10 32.00 20.00 16.00 14.00

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

Table 2

[00040] It will be appreciated that the 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. Thus, a sequence encoding algorithm can be defined, using a C language construct, as follows typedef unsigned int uint;

typedef unsigned int NBitVal;

/* Return the N-bit encoded value of the given true value val. INC is the minimum increment of val in a sequence. */

NBitVal encode (uint val, uint N, uint INC) {

int range = 1 << N;

return (val / INC) & (range - 1) ;

[00041] Similarly, the processing of a reduced RTP header can be accomplished on the receiver side through, for example, the use of a software module that receives a stream of packets from a communication channel and decodes them according to the exemplary routines set forth herein below. Thus, 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.*/

uint decode (uint prev_val, NBitVal en_val, uint N, uint INC) {

int range = 1 « N;

NBitVal prev_en_val = encode (prev_val, N, INC); //previous encoded value

int diff = en_val - prev_en_val;

//difference of two encoded values

if (diff > range/2) //prev_en_val wraps around N bits, adjust diff

diff -= range;

else if (diff < -range/2) //en_val wraps around N bits, adjust diff

diff += range;

return prev_val + diff *■ INC;

} [00042] It should be noted that in accordance with embodiments, 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. [00043] In an exemplary implementation, shown below, an original 32-bit sequence can be fully recovered from a 3-bit reduced sequence.

#include <stdio.h>

int main(int argc, char *argv[]) {

uint val[] = {0, 3, 2, 5, 8, 6, 9, 12, 14,

17};

uint len = sizeof(val) / sizeof (uint ) ;

uint prev_val = 0;

uint N = 3;

uint INC = 1; uint i;

for (i = 0; i < len; ++i) {

NBitVal en_val = encode (val [i] , N, INC) ; - uint de_val = decode (prev_val, en_val,

N, INC) ;

printf ("val=%2d en_val=%2d

de_val=%2d\n" , val[i], en_val, de_val) ;

prev_val = de_val;

}

}

Output of the .above code

val= 0 en val= 0 de val= 0

val= 3 en val= 3 de ^" val= 3

val= 2 en val= 2 de ^" val= 2

val= 5 en val= 5 de ^" val= 5

val= 8 en val= 0 de ^" val= 8

val= 6 en val= 6 de ^" val= 6

val= 9 en val= 1 de ^" val= 9

val=12 en val= 4 de ^" val= 12

val=14 en val= 6 de ^" val= 14

val=17 en val= 1 de ^" val= 17

[00044] It can be noted that if a value other than 5, 9, 12 and 14 is removed, emulating a packet loss, the true values of any of the remaining entries can be known. For the present example, in order to facilitate the reduction of packet loss, a higher minimum value of N = 4 is necessary. [00045] In accordance with embodiments, 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. 5 for one or more secondary payloads are not used since a secondary payload with arbitrary mark bit and sequence number cannot be supported. Additionally, two consecutive payloads with a jumped or out of order sequence number cannot be supported. Instead, in accordance with embodiments, 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.

[00046] 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. It should be noted that 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. For example, 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

embodiments where more formats are used, a special field can be set forth to identify the format used providing flexibility for expansion and using fewer bits overall.

[00048] Table 3 shown below, lists the improvement in bandwidth

requirement for a 4-byte reduced RTP header with redundant payload. It should be noted that n now is the total number of frames in primary and secondary payloads and packet interval becomes FrameTime*n/2.

Table 3

[00049] In accordance with above described embodiments, formats have been set forth for sending reduced size packets. As noted, 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. Thus, it is necessary to send a command packet, or preliminary packet containing all static data extracted from the RTP header at the beginning of a call session. It will be appreciated that 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. It should also be noted that 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.

[00050] 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.

[00051] In accordance with embodiments, to address the most general cases and to accommodate expansion, 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. To facilitate packet parsing, the packet type field should be at the start of each packet format.

[00052] 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.

[00053] To address the above described problems associated with communicating with receivers having firewalls with limited open ports, senders of different call sessions are required to send their packets to a common destination port of the receiver who is behind the firewall. The term firewall as used herein 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. Since, under such circumstances, the receiver has no idea what the original destination port is for each packet received, 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. [00054] 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. Alternatively, 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.

[00055] For privacy protection, 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.

[00056] In accordance with embodiments, 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. For example, 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.

[00057] 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. For example, 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. 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. [00058] While the above described aspects deal primarily with the inventive format of an exemplary RTP header, it will be appreciated that to implement the above formats and achieve the associated advantages, 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. As shown in FIG. 7, 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. Specific reference to detailed configuration will be omitted for simplicity, however it will be understood that the embodiments set forth herein can be implemented using, for example, software modules executed on a high performance processor that has the ability to interface with hardware associated with a communication channel, programmable logic, custom integrated circuits such as application specific integrated circuits or the like, and other means commonly available to those of skill in the art. The above described algorithms, procedures, descriptions and the like provide sufficient teachings such that the methods described herein can be easily implemented on a general purpose computer to form structural embodiments. Alternatively, the same algorithms, procedures, descriptions and the like can be implemented on programmable logic or can be configured into a special purpose integrated circuit. Accordingly, in addition to being capable of implementation in a sender and receiver, 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. Conversely, 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. When both sides are implementing reduced header size, 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.

[00059] Accordingly, the various illustrative embodiments shown in FIG. 7 exemplify various combinations that can occur between a sender 710 and a receiver 720. In accordance with an embodiment, 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. It will also be appreciated that the proxy unit 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.

[00060] In an embodiment, sender 710 and receiver 720 can be coupled through an intermediary 740, which can include two proxy units 741 and 742. Proxy unit 741 , for example, 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.

[00061] In an embodiment, 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. In a manner similar to 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.

[00062] In an embodiment, 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. In a manner similar to 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. [00063] 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.

[00064] In an exemplary sender or transmitter unit 801 as illustrated in FIG. 8A, 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

accordance with the above described header reduction algorithms, processes and the like using the encoding module 830 and can optionally provide

encryption using encryption module 820 using public key encryption such as PKI encryption or the like whereby the receiver, proxy or other registered

infrastructure elements agree on a key that is passed between registered elements so that packets can be encrypted and decrypted using the known key. It will be appreciated that 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. For example, 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. [00065] On the receive side, 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

functionality associated with both a receiver and a transmitter (sender). 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. It will also be appreciated that, as above, 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. Of course it is possible that the receiver unit 802 is coupled wirelessly to a broadband digital channel. In any case, 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.

[00066] It is also possible, as described herein, that 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. When packets are directed to the receiver from a caller, 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.

[00067] It should be noted that to those of skill in the art, the inventions discussed and described herein can be implemented in accordance with different variations of headers and protocols with the same or similar results. In other words, while embodiments of the invention have been described and illustrated, it will be understood by those skilled in the technology concerned that many variations or modifications in details of design or construction may be made without departing from the present invention. For example, while the exemplary RTP header can be identified with a certain number of bits, a different number of bits can be used than the number as described herein without departure from the gist of the invention.