RTP Sequence number jump

Unanswered Question
Sep 9th, 2008


I'm troubleshooting an issue with monodirectional audio.

Looking at the rtp trace I noted that the very first rtp packets have sequence number 80 81 82 and the following have seq. number 0 1 2 3 ....

Is this the cause of my problem?

Is this admitted by the rfc or not?


I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
vmoopeung Mon, 09/15/2008 - 10:51

During compression of an RTP stream, a session context is defined. For each context, the session state is established and shared between the compressor and the decompressor. The context state consists of the full IP/UDP/RTP headers, a few first-order differential values, a link sequence number, a generation number, and a delta encoding table. Once the context state is established, compressed packets may be sent. It is admitted by RFC 2507

atimpanaro Wed, 09/24/2008 - 06:47

Sorry, but I cannot understand your answer.

I'm asking about rtp sequence number, not TCP.

Could you explain what you meant?


CHRIS CHARLEBOIS Wed, 09/24/2008 - 10:17

In which direction do you see this jump? Do the users report that they have two-way audio at the beginning of a call, but lose either the send or receive stream at some point?

What you describe could conceivably cause an RTP stream to fail, although I've never seen that happen. One-way audio is much more likely an ACL issue or routing problem with binding the wrong source interface address.


This Discussion