Decompression failure with simultaneous TS_STRIDE changes and packet loss
Bug #1080035 reported by
Didier Barvaux
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | ||
---|---|---|---|---|---|---|
rohc | Status tracked in Rohc-main | |||||
1.3.x |
Won't Fix
|
High
|
Didier Barvaux | |||
1.4.x |
Fix Released
|
High
|
Didier Barvaux | |||
Rohc-1.5.x |
Fix Released
|
High
|
Didier Barvaux | |||
Rohc-main |
Fix Released
|
High
|
Didier Barvaux |
Bug Description
A RTP stream with a TS_STRIDE change and a lost packet at the very same time may fail to be decompressed correctly.
RTP stream pattern that cause the bug:
* packet #N:
- SN = A
- TS = B
* packet #(N+1):
- SN = A + 1
- TS = B + TS_STRIDE
* packet #(N+2):
- SN = A + 2
- TS = B + TS_STRIDE # TS is unchanged wrt packet #(N+1)
If packet #(N+1) is lost while in SO state, then #(N+2) packet will not be correctly decompressed.
To post a comment you must log in.
Attach a PCAP file that contains a RTP stream that causes the bug. It was generated with scapy:
>>> packets = [] append( Ether() /IP(id= i)/UDP( dport=1234) /RTP(sequence= i, timestamp= (i+1)*160) ) i][RTP] .timestamp = 160*(i+1) 6][RTP] .timestamp = packets[ 5][RTP] .timestamp + 160*2 7][RTP] .timestamp = packets[ 6][RTP] .timestamp + 160 "non_sequential _rtp_ts. pcap", packets)
>>> for i in range(1, 9):
... packets.
...
>>> for i in range(0, 8):
... packets[
...
>>> len(packets)
8
>>> packets[
>>> packets[
>>> wrpcap(