Hi rtpengine experts,
We have some customers processing long multi-party call pcaps using
mediaMin who are reporting large amounts of packets with timestamp
jumps but no packet loss (for instance 10% of packets over a 1 hr 45
min call). For example, in the Wireshark excerpt shown below, packets
6 and 8 sent by rtpengine show a timestamp increment of 640, but
sequence number increment of 1:
In the mediaMin output packet log we typically see sections similar to:
  :
  :
Seq num 98584Â Â Â Â Â Â Â Â Â Â Â Â Â timestamp = 3902252372, rtp pyld len = 33 media-R
Seq num 98585Â Â Â Â Â Â Â Â Â Â Â Â Â timestamp = 3902252692, rtp pyld len = 33 media
Seq num 98586Â Â Â Â Â Â Â Â Â Â Â Â Â timestamp = 3902253012, rtp pyld len = 33 media-R
Seq num 98587Â Â Â Â Â Â Â Â Â Â Â Â Â timestamp = 3902253332, rtp pyld len = 33 media
Seq num 98588Â Â Â Â Â Â Â Â Â Â Â Â Â timestamp = 3902253652, rtp pyld len = 33 media-R
Seq num 98589Â Â Â Â Â Â Â Â Â Â Â Â Â timestamp = 3902253972, rtp pyld len = 33 media
Seq num 98590Â Â Â Â Â Â Â Â Â Â Â Â Â timestamp = 3902254292, rtp pyld len = 33 media
Seq num 98591Â Â Â Â Â Â Â Â Â Â Â Â Â timestamp = 3902254612, rtp pyld len = 33 media-R
Seq num 98592Â Â Â Â Â Â Â Â Â Â Â Â Â timestamp = 3902254932, rtp pyld len = 33 media
Seq num 98593Â Â Â Â Â Â Â Â Â Â Â Â Â timestamp = 3902255252, rtp pyld len = 33 media
Seq num 98594Â Â Â Â Â Â Â Â Â Â Â Â Â timestamp = 3902255572, rtp pyld len = 33 media-R
Seq num 98595Â Â Â Â Â Â Â Â Â Â Â Â Â timestamp = 3902255892, rtp pyld len = 33 media
Seq num 98596Â Â Â Â Â Â Â Â Â Â Â Â Â timestamp = 3902256212, rtp pyld len = 33 media
Seq num 98597Â Â Â Â Â Â Â Â Â Â Â Â Â timestamp = 3902256532, rtp pyld len = 33 media
Seq num 98598Â Â Â Â Â Â Â Â Â Â Â Â Â timestamp = 3902256852, rtp pyld len = 33 media-R
Seq num 98599Â Â Â Â Â Â Â Â Â Â Â Â Â timestamp = 3902257172, rtp pyld len = 33 media
Seq num 98600Â Â Â Â Â Â Â Â Â Â Â Â Â timestamp = 3902257492, rtp pyld len = 33 media-R
Seq num 98601Â Â Â Â Â Â Â Â Â Â Â Â Â timestamp = 3902257812, rtp pyld len = 33 media
Seq num 98602Â Â Â Â Â Â Â Â Â Â Â Â Â timestamp = 3902258132, rtp pyld len = 33 media
Seq num 98603Â Â Â Â Â Â Â Â Â Â Â Â Â timestamp = 3902258452, rtp pyld len = 33 media
Seq num 98604Â Â Â Â Â Â Â Â Â Â Â Â Â timestamp = 3902258772, rtp pyld len = 33 media-R
Seq num 98605Â Â Â Â Â Â Â Â Â Â Â Â Â timestamp = 3902259092, rtp pyld len = 33 media
  :
  :
 Â
where media-R packets are timestamp gap repairs (i.e. frame loss
concealment). The behavior tends to be bursty, but once it gets going
it goes for a while and seems relatively consistent.
Is this expected behavior for rtpengine ? If so is rptengine in turn
dealing with some type of "slow packet rate" issue from a remote
sender ?
Thanks, Jeff