other than the inventive concept , the elements shown in the figures are well known and will not be described in detail . for example , other than the inventive concept , familiarity with packet data communications , including internet protocol ( ip ), user datagram protocol ( udp ), real - time transport protocol ( rtp ), and robust header compression ( rohc ), and broadcast systems such as atsc - m / h or dvb - h is assumed and not described herein . it should also be noted that aspects of the inventive concept may be implemented using conventional programming techniques , which , as such , will not be described herein . finally , like - numbers on the figures represent similar elements . the inventors have discovered that burst modes present unique challenges to communication . in particular , the inventors have recognized that the use of rohc , along with , for example , an underlying protocol of rtp , presents particular challenges . as is known , rohc uses an expanded header for a given ( underlying ) protocol , as well as including data formatted according to the underlying protocol ( for example , rtp ). as described above , rohc uses ir packets to transmit certain control information . in a burst mode , the inventors have recognized that if an ir packet is lost , has errors , or is otherwise not usable at the receiver , then the receiver might ordinarily throw out the data packets that depended on that lost ir packet . in an exemplary embodiment , a later received ir packet can be used to determine , or estimate , the values for various pieces of information in the lost ir packet . in an exemplary embodiment , only the information that is used in decoding the data packets is determined or estimated . in other embodiments , the entire ir packet is determined or estimated . fig1 shows a schematic representation of a typical system employing robust header compression ( rohc ). rfc 3095 describes rohc as well as its application to various underlying protocols including rtp , among others . as shown in fig1 , a typical rohc scheme includes a source 101 of data packets coupled to a client 102 via a rohc - compliant compressor or transmitter 110 and a rohc - compliant decompressor or receiver 120 . source 101 and compressor 110 are typically co - located , as are client 102 and decompressor 120 , but they need not be . compressor 110 and decompressor 120 may be coupled by any suitable wired or wireless link or links . based on the data that is being transmitted , rohc can operate in one of three modes : unidirectional mode ( u - mode ), optimistic mode ( 0 - mode ), or reliable mode ( r - mode ). in u - mode , there is assumed to be no feedback channel . 0 - and r - modes include a feedback mechanism , whereby compressor 110 can vary the level of compression used based on feedback from decompressor 120 . rohc operation typically starts with the transmission of an initialization and refresh ( ir ) packet . the ir packet is an uncompressed packet that contains full contextual information about the profile of the data that is being transmitted . in a unidirectional mode of operation ( u - mode ), packets are transmitted from compressor 110 to decompressor 120 without feedback . because compressor 110 does not receive feedback indicating what information was not received by decompressor 120 , rohc u - mode includes a timeout mechanism whereby the compressor 110 switches between different modes of compression . in the u - mode of operation , as may be used for example in atsc - m / h transmission , an ir packet , which contains the full context , can be transmitted periodically . such operation is illustrated in fig2 . an ir packet can either contain the static and dynamic parts of the contextual information in an uncompressed form , or it can contain only the static parts . a related packet type , the ir - dyn packet , contains only the dynamic parts of the contextual information . compressor 110 can switch between sending these two types of ir packets at a fixed interval . this is particularly useful since there is no feedback provided in u - mode . the formats of ir and ir - dyn packets are described below in greater detail . as shown in fig2 , ir packet ir 1 contains the contextual information to decompress the packets a , b and c , whereas ir packet ir 2 contains the contextual information to decompress the packets p , q and r . in the illustrative scenario of fig2 , the packets ir 1 , a , b , and c are transmitted together in a time slice and the packets ir 2 , p , q and r are transmitted together in a later time slice . time slicing is a method of transmission in which each transmission is sent out as a burst of data over a period of time and is commonly employed in unidirectional broadcast systems such as atsc - m / h or dvb - h . in an exemplary embodiment , each time slice contains one ir packet and the packets to which the contextual information contained in the ir packet pertains . each time slice starts with an ir packet . a time slice may contain different numbers of packets and ir packets than those illustrated for this embodiment . in cases such as where decompressor 120 switches on during the transmission of a time slice of data , decompressor 120 may receive some packets of the time slice while missing the ir packet preceding said packets . as such , decompressor 120 will have received packets without the associated ir packet needed to decompress them . such a scenario is illustrated in fig3 , in which packets a , b and c are received , but ir packet ir 1 is not . because the ir packet associated with packets a , b and c was not received by decompressor 120 , the contextual information contained therein for decompressing packets a , b and c is not available to decompressor 120 . it is possible , however , that one or more subsequent ir packets are later received in a subsequent slice . in the scenario illustrated in fig3 , ir packet ir 2 preceding the packets p , q and r is received by decompressor 120 . as mentioned , however , an ir packet contains contextual information for the packets following it . in accordance with an exemplary embodiment of the disclosure , a rohc decompressor uses the contextual information contained in an ir packet to decompress packets preceding the ir packet . in the illustrative scenario depicted in fig3 , decompressor 120 uses contextual information contained in ir packet ir 2 to decompress packets a , b and c , for which contextual information is otherwise lacking . this is possible because successive ir packets , such as ir 2 and ir 1 , will contain information in common . moreover , some or all of the information in a previous , missing ir packet can be re - created from a subsequent ir packet . for example , the rtp timestamp ( ts ), timestamp stride ( ts_stride ), and rtp sequence number ( sn ) in ir 2 can be used to reconstruct the corresponding information in ir 1 . fig4 a shows the format of an rtp ir packet and fig4 b shows the format of an rtp ir - dyn packet . ( fig4 a and b are derived from rfc 3095 .) the ir packet type communicates the static part of the context , i . e ., the values of the constant - sn functions . it can optionally also communicate the dynamic part of the context , i . e ., the parameters of non - constant - sn functions . it can also optionally communicate the payload of an original packet , if any . the ir - dyn packet type communicates the dynamic part of the context , i . e ., the parameters of non - constant - sn functions . each field of the packets is shown with the number of octets of each field in parentheses . as shown in fig4 a and 4b , each ir and ir - dyn packet includes context identifier information ( add - cid , cid ) which allows multiple packet streams with different contexts to share a channel . the second octet of each packet identifies the packet type ( ir or ir - dyn ) and in the case of an ir packet , indicates ( bit d ) whether a dynamic chain field is present . as shown in fig4 a and 4b , each ir and ir - dyn packet includes a header compression profile octet which specifies how to compress the headers of a certain kind of packet stream over a certain kind of link . compression profiles provide the details of the rohc header compression framework . as shown in fig4 a and 4b , each ir and ir - dyn packet header includes a cyclic redundancy check ( crc ) octet for checking the integrity of the header . in an exemplary embodiment , the ir header information of fig4 a and 4b , including the fields for add - cid , packet header , profile , and crc are not re - created for the lost ir packet because they are not used in decoding the data packets . in an ir packet header , the crc octet is followed by a static chain field which may be followed by a dynamic chain field . in an ir - dyn packet header , the crc octet is followed by a dynamic chain field . the header of an ir or ir - dyn packet is followed by the payload of the corresponding original packet , if any . the static chain field contains a chain of static subheader information , whereas the dynamic chain field contains a chain of dynamic subheader information . what dynamic information is present is inferred from the static chain field . the subheaders which are compressible are split into static and dynamic parts . fig5 a through 5c show the static and dynamic parts of an rohc ir packet header for internet protocol version 4 ( ipv4 ), user datagram protocol ( udp ), and real - time transport protocol ( rtp ) subheaders , respectively . ( fig5 a - c are derived from rfc 3095 .) as discussed below , however , the contents of the udp and ip headers typically change less frequently than the contents of the rtp header . in the scenario of fig3 , in which packet ir 1 is lost , the static and dynamic information pertaining to the packets a , b and c are lost . the subsequent ir packet ir 2 , however , is received and typically contains the same static information and some minor changes to the dynamic information that was contained in lost packet ir 1 . as such , static and dynamic information contained in packet ir 2 can be re - used to recreate static and dynamic information contained in lost packet ir 1 . in an exemplary embodiment , the static information of packet ir 2 is re - used as the static information of packet ir 1 and the dynamic and / or static information of packet ir 2 is used to derive the dynamic information of packet ir 1 . for the ip and udp packet headers , static information that can be re - used includes the source and destination addresses and ports . in a broadcast application , as contemplated in an exemplary embodiment , the source and destination network addresses and ports typically do not change frequently . the same can be said of the dynamic part of the ipv4 header ( fig5 a ) which contains some network parameters such as , for example , time to live ( ttl ) and type of service ( tos ). this information changes infrequently and can be re - used for packets for which the corresponding ir packet is unavailable . in the case of the rtp header of an ir packet , such as shown in fig5 c , there is additional information that is to be re - created . as shown in fig5 c , the static part of the rtp header contains the synchronization source identifier ( ssrc ) for the stream . the ssrc identifies the stream and is not expected to change from one ir packet to the next ir packet . as such , the ssrc from the next received ir packet can be assumed to be the same as the ssrc from the lost ir packet . because such information will not change significantly over time , it can be re - used . in the dynamic part of the rtp header ( fig5 c ), the first two bytes ( including version number v , rx , cc , m , and payload type pt ) are not typically expected to change from one ir packet to the next ir packet . as such , in an exemplary embodiment , these two bytes from the next received ir packet can be assumed to be the same as the corresponding two bytes from the lost ir packet and can be re - used . the sequence number ( sn ) of ir packet ir 2 can be used to derive the sequence numbers for the previous packets . as part of rtp , sn increments from one packet to the next packet . the sn of the lost ir packet can be determined from the sn of the received ir packet . for example , if there are “ x ” rtp data packets between the lost ir packet and the received ir packet , then the sn of the lost ir packet can be determined by decrementing the sn of the received ir packet by “ x ”+ 1 . thus , as an illustration , if packet ir 2 shown in fig3 has a sn of 4 , then it can be deduced that the preceding packets a , b and c would have sns of 1 , 2 and 3 , respectively . as shown in fig5 c , the dynamic part of the rtp header also includes timestamp ( ts ), ts_stride and time_stride fields . ts_stride and time_stride provide the changes between successive rtp timestamps and successive absolute timestamps ( wall clock ), respectively . more specifically , ts_stride tells the receiver the expected change in rtp timestamp from the previous ir packet . accordingly , the rtp timestamp of the lost ir packet can be determined from the rtp timestamp and ts_stride of the received ir packet . additionally , ts_stride and time_stride are generally not expected to change from one ir packet to the next ir packet . for example , if there are “ x ” data rtp packets between the lost ir packet and the received ir packet , then the timestamp of the lost ir packet can be determined by subtracting (( x + 1 )* ts_stride ) from the rtp timestamp of the received ir packet . as such , by way of illustration , if ir packet ir 2 has a timestamp value of 100 and a ts_stride value of 10 , then it can be deduced that the preceding packets a , b and c would have timestamp values of 70 , 80 and 90 , respectively . as shown in fig5 c , the dynamic part of the rtp header also includes a crl list field . the crl list is generally not expected to change from one ir packet to the next ir packet . accordingly , the crl list from the lost ir packet can be assumed to be the same as the crl list from the next received ir packet . hence , using a later ir packet , most of the information needed , e . g ., the payload type ( pt ), the rtp version ( v ), and the timestamp ( ts ) of the rtp packet can be re - created and applied to the packets lacking contextual information . this leads to a more robust service . this also helps the receiver tune faster since it can decode information from the packets even though it missed the reception of the packets &# 39 ; associated ir packet . in exemplary embodiments , because of the signaling requirements relating to certain fields in rohc headers , it may be necessary to rebuild the packets a , b and c in a reverse sequence . for example , in the case of rtp , packet c is rebuilt first , then packet b , and then packet a . this is due to the way the sequence number ( sn ) and timestamp ( ts ) information is signaled in the rohc headers . because there is only incremental data available , the packets are rebuilt by working backwards from the ir . in an exemplary embodiment , crc information in the rohc packet headers can be used to check the validity of the header information re - created as described above . in u - mode rohc , for example , the rohc header of each packet includes a crc . for packets such as a , b and c that have been decompressed using information re - created from information contained in another ir packet , such as ir 2 , the decompressor can test the validity of the re - created information by calculating the crc for each packet after decompression and comparing it to the crc contained in the packet header as received . if there is a match , then it can be determined that the re - created data is valid and the packet can be forwarded to the client . if there is no match , the packet may be discarded . if an rtp / udp / ip packet is compressed with rohc , the receiver can decompress the rtp / udp / ip headers and then apply the crc to validate the resultant header . if a packet is lost , however , there can be ambiguity in the reconstructed packets . thus , under normal operation without packet loss , packets p 0 , p 1 , p 2 , p 3 , . . . are compressed by compressor 110 to rohc packets r ( p 0 ), r ( p 1 ), r ( p 2 ), r ( p 3 ), . . . and transmitted to decompressor 120 which decompresses the packets back to p 0 , p 1 , p 2 , p 3 , . . . . if , however , r ( p 2 ) is lost , for example , p 2 cannot be reconstructed and because r ( p 2 ) contained differential information , it is possible that p 3 will be reconstructed incorrectly . a simple embodiment of a receiver simply ignores packets r ( p 3 ), r ( p 4 ), . . . until the next ir packet is received . a more complex embodiment of a receiver reconstructs p 3 and checks its crc . if the crc passes , then the receiver continues to decode the subsequent packets p 4 , p 5 , . . . , otherwise it stops decoding and waits for the next ir packet . in yet another embodiment of a receiver , if the crc fails , the contents of p 3 are varied ( such as for example , by incrementing the sn and ts by an amount predicted based on the missing packets ), the crc is re - calculated based on the varied contents , and the crc is tried again . this procedure of varying the packet contents and re - trying the crc can be repeated until the crc passes or some event occurs , such as , for example , the elapsing of a predetermined time period . where packets are rebuilt in reverse order , as described above , it may not be guaranteed that the packets can be generated unambiguously , even without lost packets . preferably , therefore , a check of the crc is performed . additionally , an iterative procedure of varying the packet contents and re - checking the crc , as described , can be used . fig6 shows a flowchart of an exemplary embodiment of a method in accordance with the above description . as shown in fig6 , at step 202 , a time slice containing multiple packets , such as those shown in fig2 and 3 , is received by the decompressor . the decompressor examines the time slice and if it is determined at 204 that the time slice lacks an ir packet , as in fig3 , operation proceeds to step 206 . at step 206 , the compressed packets received in the current time slice are stored for later decompression in the expectation that a subsequent time slice is received with an ir packet containing context information that can be used to decompress the packets . operation then returns to step 202 for reception of another time slice . if it is determined at step 204 that the current time slice was received with an ir packet , as in the scenario depicted in fig2 , operation proceeds to step 207 in which the decompressor checks whether there are any compressed packets from a previous time slice that were stored in step 206 awaiting decompression . if not , operation proceeds to step 212 in which the packet headers received in the current time slice are decompressed in accordance with the context information provided in the ir packet received in the current time slice . if it is determined at step 207 that there are stored compressed packets from a previous time slice awaiting decompression , operation proceeds to step 208 , in which information in the current ir packet is extracted . the extracted information is then used in step 210 to re - create the static and dynamic information for the stored packets whose associated ir packet was lost . as described above , the step of re - creating the context information may include re - using some or all of the extracted static and / or dynamic information and / or deriving context information from some or all of the extracted static and / or dynamic information . operation then proceeds to step 212 in which the stored packets are decompressed in accordance with the context information thus re - created . in addition , the packets received in the current time slice are also decompressed in accordance with the extracted information . operation then returns to step 202 for reception of another time slice . although exemplary embodiments have been disclosed above with reference to burst modes of operation , with packets transmitted in bursts or time slices , the principles of the invention are also applicable to streaming modes of operation as well , in which packets are sent in continuous streams . in a further exemplary embodiment , a rohc decompressor uses an earlier - received context - rich packet to decompress later received packets for which no context information was received . the exemplary rohc decompressor , instead of throwing out packets for which it lacks any contextual information , uses an earlier - received context - rich packet , such as an ir packet , to re - create the context information pertaining to the later received packets . the context information thus re - created is then used to decompress the received packets . in an exemplary embodiment , only the information that is used in decoding the data packets is determined or estimated . in other embodiments , the entire ir packet is determined or estimated . in yet a further exemplary embodiment , a rohc decompressor uses an earlier - received context - rich packet and a later - received context - rich packet to decompress packets for which no context information was received . the exemplary rohc decompressor , instead of throwing out packets for which it lacks any contextual information , uses a combination of context - rich packets such as ir packets , preceding and following packets for which no context information was received , to re - create the context information pertaining to the packets . for example , in an rtp application , information such as the sn and ts of a lost ir packet can be determined by interpolating the corresponding values in the earlier and later ir packets that were correctly received . the context information thus re - created is then used to decompress the packets . in an exemplary embodiment , only the information that is used in decoding the data packets is determined or estimated . in other embodiments , the entire ir packet is determined or estimated . note also , that although a proximate ir packet — such as an ir packet immediately preceding or immediately following a lost ir packet — will most likely contain the most accurate information for re - creating the contents of the lost ir packet , it may be possible to also use information from further removed ir packets , particularly if the validity of the information in a more proximate ir packet is in doubt . various exemplary embodiments in accordance with the invention are possible . for example , in an exemplary embodiment , a method is provided for re - creating all or part of a lost ir packet in an rohc system , using a different ir packet . in another exemplary embodiment , a method is provided for processing , such as , for example , decoding data that depends on the lost ir packet , the processing being done with the use of the re - created ir packet . in a further exemplary embodiment , a processing device is provided that performs the aforementioned re - creating and / or processing methods . in yet a further exemplary embodiment , a device is provided , such as for example a pre - processor , an encoder , a transmitter , a receiver , a decoder , a post - processor , a set - top box , a cell - phone , a laptop or other personal computer , a pda , or other consumer communications equipment , containing the aforementioned processing device . embodiments in accordance with the present invention may be adapted to a variety of applications . for example , embodiments may be used in the context of coding video and / or other types of data . additionally , embodiments may be used in the context of , or adapted for use in the context of , a standard . one such standard is the atsc - m / h standard , but other standards ( existing or future ) may apply . of course , embodiments need not be used in a standard . the implementations described herein may be implemented in , for example , a method or a process , an apparatus , a software program , a data stream , or a signal . even if only discussed in the context of a single form of implementation ( for example , discussed only as a method ), the implementation of features discussed may also be implemented in other forms ( for example , an apparatus or program ). an apparatus may be implemented in , for example , appropriate hardware , software , and firmware . the methods may be implemented in , for example , an apparatus such as , for example , a processor , which refers to processing devices in general , including , for example , a computer , a microprocessor , an integrated circuit , or a programmable logic device . processors also include communication devices , such as , for example , computers , cell phones , portable / personal digital assistants ( pdas ), and other devices that facilitate communication of information between end - users . implementations of the various processes and features described herein may be embodied in a variety of different equipment or applications , particularly , for example , equipment or applications associated with data encoding and decoding . examples of such equipment include an encoder , a decoder , a post - processor processing output from a decoder , a pre - processor providing input to an encoder , a video coder , a video decoder , a video codec , a web server , a set - top box , a laptop , a personal computer , a cell phone , a pda , and other communication devices . as should be clear , the equipment may be mobile and even installed in a mobile vehicle . additionally , the methods may be implemented by instructions being performed by a computer , and such instructions ( and / or data values produced by an implementation ) may be stored on a computer - readable medium such as , for example , an integrated circuit , a software carrier or other storage device such as , for example , a hard disk , a compact diskette , a random access memory (“ ram ”), or a read - only memory (“ rom ”). the instructions may form an application program tangibly embodied on a computer - readable medium . instructions may be , for example , in hardware , firmware , software , or a combination . instructions may be found in , for example , an operating system , a separate application , or a combination of the two . a processor may be characterized , therefore , as , for example , both a device configured to carry out a process and a device that includes a computer - readable medium ( such as a storage device ) having instructions for carrying out a process . further , a computer - readable medium may store , in addition to or in lieu of instructions , data values produced by an implementation . a number of implementations have been described . nevertheless , it will be understood that various modifications may be made . for example , elements of different implementations may be combined , supplemented , modified , or removed to produce other implementations . additionally , one of ordinary skill will understand that other structures and processes may be substituted for those disclosed and the resulting implementations will perform at least substantially the same function ( s ), in at least substantially the same way ( s ), to achieve at least substantially the same result ( s ) as the implementations disclosed . accordingly , these and other implementations are contemplated by this disclosure and are within the scope of this disclosure . in view of the above , the foregoing merely illustrates the principles of the invention and it will thus be appreciated that those skilled in the art will be able to devise numerous alternative arrangements which , although not explicitly described herein , embody the principles of the invention and are within its spirit and scope . for example , although illustrated in the context of separate functional elements , these functional elements may be embodied in one , or more , integrated circuits ( ics ). similarly , although shown as separate elements , some or all of the elements may be implemented in a stored - program - controlled processor , e . g ., a digital signal processor or a general purpose processor , which executes associated software , e . g ., corresponding to one , or more , steps , which software may be embodied in any of a variety of suitable storage media . further , the principles of the invention are applicable to various types of wireless communications systems , e . g ., terrestrial broadcast , satellite , wireless - fidelity ( wi - fi ), cellular , etc . indeed , the inventive concept is also applicable to stationary or mobile transmitters and receivers . it is therefore to be understood that numerous modifications may be made to the illustrative embodiments and that other arrangements may be devised without departing from the spirit and scope of the present invention .