Hi, This is interesting.
Thanks for sharing. From: live-devel [mailto:live-devel-boun...@ns.live555.com] On Behalf Of Ben Rush Sent: 26 July 2016 22:30 To: LIVE555 Streaming Media - development & use Subject: [Live-devel] While investigating 'garbled' audio, Wireshark dump shows oddity I am using Live555 at the moment to implement, among other things, a two-way audio solution. People in one room (room A) can "call" people in another room (room B) and carry on a conversation with them. I implement this by a MediaSink-derived class (called SpeakerSink) which handles receiving RTP audio data. One SpeakerSink instance runs in Room B. Room A initiates the call with room B by SimpleRTPSink. SpeakerSink notices audio traffic, and uses SimpleRTPSink on its side to call back to a SpeakerSink instance in Room A (to complete the two-way audio). So in summary (and I think "SpeakerSink" is probably a bad name): ROOM A ROOM B SimpleRTPSink --------> SpeakerSink | | V SpeakerSink <--------- SimpleRTPSink This has been working great except for the occasional moment where audio starts getting, as I say, "garbled". Eventually the stream seems to right itself, but for a period of time (a minute or so), audio is jittery and choppy. Until recently I've been unable to find an oddity in wireshark. Today I have something that I'm unsure about: large bundles of packets (228 in one example) whose RTP timestamp are all the same. The sequence number increases nice and monotonically, but the timestamp is the same. I noticed in Wireshark, also, that they appear to be received about the same time as well. This happened during a session where the audio became garbled. In Wireshark dumps during times where audio is fine, I've yet to notice this behavior. It appears, at least from the outside, as if the server is sending a large burst of packets for some reason. I'm on Windows and so I'm using the WindowsAudioInputDevice_common/noMixer classes internally to do all the audio work. I notice certain areas in the code where the timestamp is modified, but only one packet at a time, but not en masse. Here is an example wireshark dump. Filter to UDP traffic 172.17.5.132 -> 172.17.5.156. You'll have to decode the UDP packet as RTP since Wireshark wasn't ran when the SDP was broadcast (presumably). http://www.ben-rush.net/badexamples.pcapng Starting from sequence number 22221 and ending with 22449, all the packets have the same timestamp 4276629357. Is this easily explainable by some mechanism, or does this indicate the server is having trouble sending the packets? The information in this e-mail transmission contains proprietary and business sensitive information. Unauthorized interception of this e-mail may constitute a violation of law. If you are not the intended recipient, you are hereby notified that any review, dissemination, distribution or duplication of this communication is strictly prohibited. You are also asked to contact the sender by reply email and immediately destroy all copies of the original message.
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
