This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Reported RTP Packet Loss

0

I was working on an issue where a commercial packet level RTP stream analyzer tool was reporting very high packet loss (on the order of +50%) for one RTP stream (the other stream reported without loss) on some calls but users were not reporting call quality issues. From the beginning we believed the issue was related to false reporting by the tool and not actual loss of packets. We used Wireshark to analyze a packet capture in an attempt at locating the issue and we found the RTP tools in Wireshark reported the same loss.

In the end, the reported loss was confirmed false and no packet loss was actually occurring. The root cause was the VoIP platform "shifting" the RTP media stream to a DSP resource during DTMF use.

  • SIP would establish bi-directional RTP streams between a Phone and a SBC for an outbound call
  • User would signal DTMF from the Phone for call routing
  • The Phone->SBC stream would shift away from the SBC over to a DSP resource (out-of-band DTMF because we use G.729)
  • After a period of time without DTMF signaling, the stream would shift back to the SBC to release the DSP resource

During this shifted period of time:

  • The SSRC would stay the same
  • The sequence numbers would continue to increment from the point at which the stream shifted to the DSP resource
  • The end point IP address would obviously change from that of the SBC to that of the DSP resource

This caused both our tool and Wireshark to report a new/discrete steam for the Phone->DSP during the shifted period. If/when the stream shifted back to the original Phone->SBC path:

  • The SSRC would remain the same
  • The sequence numbers would continue to increment from the point at which the stream shifted away from the DSP resource
  • The end station IP address would return being that of the SBC

This resulted in this steam matching up with the original stream but the sequence number being significantly higher from when the steam organically shifted to the DSP resource. This gap in sequence numbers is reported by both tools as lost packets.

My questions are...

  • Has anyone seem this behavior and/or have any documentation this RTP stream behavior that you would provide for additional research?
  • Is there any current or planned functionality in Wireshark to detect and identify this event/behavior then correctly correlate the streams for accurate reporting?

Any assistance with this issue is greatly appreciated. Please feel free to respond with questions if any additional information is needed.

Thanks!

alt text

asked 13 Apr '14, 11:44

oma1981's gravatar image

oma1981
11●1●1●3
accept rate: 0%

edited 15 Apr '14, 17:35

How is the RTP stream "shifted"? Is there a SIP re-INVITE or UPDATE with a new SDP offer/answer to shift the stream to the DSP resource? Or is it instead done with proprietary signaling or some other protocol between the SBC and DSP resource?

Can you post an example pcap file of this happening, like on cloudshark.org or somewhere publicly accessible?

(13 Apr '14, 13:14) Hadriel

@Oma: did you get my comment? (I've noticed the emailing system for this site isn't consistent, so just making sure...)

(15 Apr '14, 14:09) Hadriel

Sorry for the slow response. I am unfortunately not able to post a packet capture due to privacy and security reasons. About the best I can do at this moment is a sanitized call tree. This capture was taken from the perspective of the SBC. Near the bottom it can be seen when the Remote DSP starts providing RTP DTMF but the capture did not witness any signaling to the SBC for establishing the RTP stream with the Remote DSP.

Thoughts?

(15 Apr '14, 17:36) oma1981

You asked:

Thoughts?

Yes: that this will be hard to diagnose without an example capture file. :)

The above call ladder diagram doesn't show any signaling between the SBC and even the phone, let alone with the branch or remote DSP resources. You said above that the capture is taken from the perpsective of the SBC - doesn't the SBC signal SIP to the phone?

Was your original problem of incorrect RTP reporting also from captures taken on the SBC, or was it from somewhere else?

All I see in the above call flow is the initial INVITE transaction at the start, and what I assume are in-dialog re-INVITEs after that, but only between the Session Manager and the SBC. So I assume the Session Manager is the one controlling the media shifting, by sending a re-INVITE without SDP, getting SBC's 200 OK with an SDP offer, and changing the SDP info in the ACKs it sends back to the SBC to move the media. Right?

Also, in this call flow it looks like the SSRCs are changing, and the DTMF events are going from the DSP to the SBC... both of which you said were not the case in your original question. (I think?)

(15 Apr '14, 21:30) Hadriel

BTW, the reason I'm asking these things is because Wireshark doesn't really know what RTP streams are associated with what call except by seeing the appropriate signaling (i.e., SIP or H.323 or whatever) in the capture. In fact it doesn't even usually know they're RTP packets at all, instead of just random UDP packets, without seeing that signaling. In the call flow above, anything that's labeled "RTP" is only labeled that because Wireshark has seen SIP/SDP that tells it the address:ports of those RTP streams, I believe.

So if the streams you were talking about in your original question aren't on that call flow, Wireshark doesn't know about them.

(15 Apr '14, 21:47) Hadriel