Wireshark - incorrect timestamp and audio shift

Hello, everyone. I try to analyze calls in wireshark. Some of my calls contain incorrect timestamp on the outbound leg. Also, in some calls there are significant audio delays in one leg agains the other, when I play them in Wireshark, although in real recordings there is no such problem. How can I fix these errors, so that in Wireshark everyhing is OK?

In what way are the time stamps wrong?

Here is a screenshot.

This typically happens on a source change. I don’t know how pjsip handles these and I don’t know if chan_sip has been improved, but Asterisk used not to track the SSRC value, as there was no mechanism in the backbone of Asterisk to carry that information from A to B sides. What it did do is set the mark bit. That is supposed to indicate a good place to reset jitter buffers, not a warning that a different source of timestamps is being used.

The place where I used to work added an option that basically caused SSRC to change whenever a source change was signalled, but we were working on an old Asterisk at the time, so weren’t in a position to formally submit it.

We found that whilst this helped with some peers (Cisco) it actually broke things for others.

I have remember that something similar may have been added in the official version.

I also seem to remember that going in and out of native bridging tended to have this effect.

Note that this would result in wireshark seeing lots of different media streams, which may actually be worse for your purposes.

How can I turn this mark bit on and off? We nave a cisco router. In my trace it occasionally shows up. I want to turn it off to see the difference.

After analysis I have found that this incorrect times stamp after channels get connected is due to the fact that asterisk starts to transmit the timestamps of the peer instead of its own timestamps. Wireshark shows that this the first packet after the receiving the OK status and sending an ACK in return. The scenario is as follows: asterisk receives an incoming call from a peer, makes a redirecting call through the same peer and then connects two subscribers.
How to correct this?

What problem is it causing you.

If you really want ot avoid it, set options that are incompatible with native bridging.

Doing this properly would require deep changes in Asterisk, because the Asterisk core has no concept of an SSRC or an end to end time stamp.

Sometimes there is no incorrect timestamp and no skew, incoming and outgoing streams have there own timestamps, and other time timestamps after bridging are taken from the inbound channel. I do not understand how asterisk decides which of the two channels to use as a timestamp source after bridging.

Native bridge: use the incoming time stamps.

Non-native bridge: generate timestamps on the outgoing leg.

I use simple bridge, but this is the problem, as shown, that simple bridge does not use previously timestamps, previously generated on the outgoing leg.

Could I ask again why this is actually a problem? Most SIP peers tolerate this well, Even Ciscos recover reasonably quickly. I believe Wirkshark can play back audio in a mode where it ignores timestamps, and, as I said, strictly correct handling would cause wireshark to consider call progress and IVR to be in separate streams compared with through audio.

Basically, source changes and timestamps have been mishandled for over a decade, and hardly anyone even notices a problem.

I can hear that some audio is lost. Hope that at some time this problem will be solved.

I have seen a bug reports on the Internet on this issue, and was said that the marker should be set after 200 OK message.
How can I set it?


It’s always been set for the last decade. Setting it will not stop wireshark complaining, as its an abuse of the marker bit. As I already said, the correct use of the marker bit is to indicate a good place to reset the jitter buffer, not to indicate where it is absolutely essential to do so.

Did you ever say what your real problem was, as wireshark is a debugging aid, so stopping it complaining is only important where the complaints are due to a cause that is causing problems in the real world.

Yes, I clearly hear that part of the first sounds of audio is often lost. I hope, sometime this will be fixed.
It is interesting that it does not happen in all cases. With some called party phone numbers it does not happen.

It can’t easily be fixed, as it is a limitation of the asterisk core structure, so will need changes well outside the RTP handling. It has been present for a very long time and not important enouth for anyone to want to fix it. I doubt that there has been any change that would increase the priority.

Asterisk is an ISDN/analogue PBX with VoIP bolted on. The only concessions the backbone really makes to IP is the nomination of codecs and a source change event.

That kind of begs for using an “enhanced” proxy like Kamailio. Given all the additional modules, one may not always need a complete PBX. Asterisk would be used locally for special tasks, like interfacing with legacy hardware or special functionality, but the proxy would be the primary VoIP gateway.

Anyway, I am currently looking into such a system to see how it handles more difficult cases where a service provider uses more complicated setups with plenty of servers, but expects the customer to do the bookkeeping.

It could also mean that there could be simple ways to enhance Asterisk (by fiddling with sip_resolve_callback() and the DNS scheduler).

The other question is whether one should routinely install something like Homer (but using a more general capture mechanism than using the hep module in Asterisk).