RTP Analysis

[jkroonza]

Not taking away from the need to analyse RTCP, but in some cases it's also useful to analyse same at point where the capture is being made (which is not always one of the endpoints).

So in the call screen where RTP is shown, when RTP is being selected displaying some statistics about the RTP where the SIP frame is normally displayed would be great. I suspect here the RTCP statistics related to the specific RTP flow (ie, both sending reports and receiver reports), as well as the details about the flow as seen by sngrep (number of packets, jitter, loss etc) would be most helpful.

What gets tricky is that this changes over time, so some way to export the data to some form whereby it can be graphed (I'm nor sure about this, perhaps this is overkill for sngrep and other existing tools may be better suited for this) would be exceptional. This is lower priority IMHO since we generally care about overall use experience per call.

[Kaian]

Hi @jkroonza

I started working a long time ago in a 2.x version of sngrep using glib in the branch glib-2. That version is highly unstable and not recommended, but I think contains some RTP information you mention in preview frame. That version also comes with an RTP player for g711a and g711u.

Right now I don't have the required time to make 2.x to be stable enough, so porting that logic to 1.x branch would be more viable I think.

Regards!

[jkroonza]

@Kaian that is in part what we're looking for. Specifically that covers the RTCP portion (I believe there is another option issue for that), which in and by itself would already be a HUGE jump forward. If this could be back-ported already that would be a tremendous improvement over what we can get at currently.

For sngrep to be able to analyse exactly what RTP frames it saw would also be useful. In other words, perform the same analysis the final recipient would in order to generate the recipient report, and display that as well as the RTCP details from the actual peers. This calculation is from what I recall well defined in the relevant RFC. Just don't TX the report obviously :).

Consider a very much over-simplified scenario where sngrep is run on a router with two SIP devices attached to ethernet switches on either side (call them A and B, with the router R where sngrep is running on one of the two interfaces).

Now, for the RTP going from A to B, A would generate a sender report based on the RTP it's transmitting. B would receive the RTP, and generate a recipient report (RR) based on the RTP it received and the information in the SR. What you're displaying above I believe is most/all of the information from the RR, possibly including some data from the SR. I'm not seeing the latency calculation, but since you're somewhere in the middle it may actually be non-trivial to calculate that accurately.

Now, if on R the same analysis could be made, those two could be displayed in conjunction. If we're fault-finding, if these two reports agree on the level of badness, then we know the problem is towards A's side of R, if they disagree them the problem is towards B's side from R.

Our use case is to "prove" that our network is operating correctly up to the provider-customer hand-off point, so in this case our equipment would be A, but instead of a single switch there would be a number of switches and routers. If we find the problem is towards A we can bin-search on the path until we locate the faulty link. If we find the problem is towards B we can at least indicate to the client where to go look for the problem, and possibly even assist by injecting ourselves into the client links at various points with an ethernet bridge and perform the same analysis again. Or they could generate pcaps for us which we can then ingest into sngrep.

I'd be happy to contribute time & effort on this in terms of code if I had any spare cycles currently. So I also get that this probably is low priority if any, and it's not even critical for us, we can do most of this with wireshark, it's just much more cumbersome than to sniff realtime on interfaces with sngrep. If the above branch is available and you can point me at it, and I can find spare cycles I'd be happy to attempt back-porting into the 1.x branch the RTCP analysis so long at least.