| 00:07.05 | jsmith | Anybody here with a better-than-average understanding of RTP feel like lending me their brain for a few minutes? |
| 00:07.13 | jsmith | is trying to figure out a packet capture |
| 00:07.44 | jsmith | (And yes, I realize it's Friday night... what other time do I have quiet time to look at interesting packet captures?!?) |
| 00:13.07 | *** join/#asterisk-dev jpepper (~jpepper@173-14-206-193-huntsville.hfc.comcastbusiness.net) |
| 00:14.25 | jpepper | I have a better understanding of RTP than I ever wanted. Maybe I can be of service? |
| 00:19.41 | marv | jpepper: it was jsmith who was asking for help |
| 00:20.11 | jsmith | So, I'm looking at a packet capture of a call in wireshark |
| 00:20.33 | jsmith | About 460 seconds into the call, the sequence number jumps |
| 00:21.00 | jsmith | The sequence number jumps from 29056 to 29060 |
| 00:22.05 | jpepper | Oh neat. |
| 00:22.25 | jsmith | But there's no corresponding gap in the packets... the packets are still coming along every 20 ms |
| 00:22.35 | jsmith | (or close to it) |
| 00:23.01 | jsmith | Any ideas? Clock drift, perhaps? |
| 00:23.18 | jpepper | That's odd. Does the RTP timestamp jump similarly? |
| 00:23.49 | jsmith | I'll have to look at that ... hold on. |
| 00:25.59 | jsmith | Yeah, it does. |
| 00:26.07 | jsmith | Jumps by 640, instead of 160 |
| 00:27.07 | sruffell | you know that when you took the trace no packets were dropped by the kernel? |
| 00:27.22 | jsmith | sruffell: No, unfortunately I don't. |
| 00:27.31 | jsmith | sruffell: That's a possibility, though |
| 00:28.25 | jsmith | If three packets were dropped, I would expect to see a 60ms gap between the packets, though |
| 00:28.35 | jsmith | That's what I'm having a hard time wrapping my head around |
| 00:29.05 | sruffell | 160 * 4 == 640 |
| 00:29.09 | jsmith | The only thing I can figure is that Asterisk noticed clock skew, and skipped sending three packets to get back in sync |
| 00:29.15 | jsmith | sruffell: Exactly :-) |
| 00:29.40 | sruffell | you said you saw the rtp timestamp jump up 640…which would match if 3 packets were dropped? |
| 00:29.54 | sruffell | (instead of the normal 160)? |
| 00:31.25 | jsmith | sruffell: Ugh, wireshark wasn't calculating the delta correctly |
| 00:31.35 | jsmith | sruffell: There's a 55ms gap in the wall clock between those packets as well |
| 00:31.49 | jpepper | That makes a lot more sense |
| 00:31.50 | jsmith | Looks like three packets went missing or were dropped by the kernel |
| 00:32.37 | sruffell | :/ probably those were the packets that contained the question to which 42 was the answer. |
| 00:36.39 | jsmith | sruffell: Of course :-) |
| 00:36.51 | sruffell | sorry…I shouldn't have gone there. |
| 00:36.55 | jsmith | extracts the audio and listens for drop-outs |
| 00:37.09 | jsmith | sruffell: It's all good :-) |
| 00:37.16 | sruffell | jsmith: you know about using audacity in spectral mode? You can just see the dropouts..no need to listen. |
| 00:37.17 | jsmith | sruffell: Now that I know I'm not going crazy, it's good :-) |
| 00:37.30 | jsmith | sruffell: No, I haven't tried that... mind giving me the 30 second tour? |
| 00:37.36 | jsmith | installs audacity quickly |
| 00:38.51 | sruffell | Load up your *.wav in audacity…then on the drop down menu for the track select "Spectrogram". Then any drop in audio will show up as a white vertical line since a shift in phase shows energy across the entire spectrum. |
| 00:39.11 | sruffell | If that's not clear, let me know and I can try to load up an example and link some pictures. |
| 00:45.46 | jsmith | Oooh, nice! |
| 00:45.59 | jsmith | That helped me find another cut-out, which I'll have to go back to the RTP stream to look at |
| 00:46.19 | jsmith | But first -- answer me this -- why is the break in the audio several seconds long if we only lost 3 packets (60ms?) of audio? |
| 00:47.08 | sruffell | that could be due to the smoothing when looking at it. If you want to measure exact intervals you'll need to switch to waveform and zoom in and look for a jerk…not nearly as convenient. |
| 00:47.22 | sruffell | at least in my experience. I'm sure a DSP guru would have better ways. |
| 00:47.38 | jsmith | OK. I guess what I"m trying to say is that I hear a three-second gap in the music |
| 00:48.05 | sruffell | ohhh….hmm….that I'm not sure about. |
| 00:51.06 | jsmith | The other gap corresponds to 400 seconds into the RTP, and the RTP packet timestamp rolled over from 3738974532 to 3219480 |
| 00:51.25 | jsmith | (and the marker bit was set to true) |
| 00:53.21 | sruffell | have to run…good luck |
| 00:54.42 | *** join/#asterisk-dev ZX81 (~ZX81@134.sub-70-193-203.myvzw.com) |
| 00:54.42 | *** part/#asterisk-dev ZX81 (~ZX81@134.sub-70-193-203.myvzw.com) |
| 01:21.49 | *** join/#asterisk-dev wudles (~wudles@gateway.secureinstrument.com) |
| 01:41.37 | *** join/#asterisk-dev marv (~Adium@c-50-130-4-242.hsd1.al.comcast.net) |
| 01:46.25 | *** join/#asterisk-dev wudles (~wudles@gateway.secureinstrument.com) |
| 02:08.03 | *** join/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 02:08.03 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 03:53.29 | *** join/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 03:53.29 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 08:07.03 | *** join/#asterisk-dev ChanServ (ChanServ@services.) |
| 08:07.03 | *** mode/#asterisk-dev [+o ChanServ] by lindbohm.freenode.net |
| 08:34.07 | *** join/#asterisk-dev ChanServ (ChanServ@services.) |
| 08:34.07 | *** mode/#asterisk-dev [+o ChanServ] by lindbohm.freenode.net |
| 11:00.04 | *** join/#asterisk-dev micols (~t@rlogin.dk) |
| 12:04.46 | *** join/#asterisk-dev kpfleming (~kpfleming@unaffiliated/kpfleming) |
| 15:24.22 | *** join/#asterisk-dev marv (~Adium@c-50-130-4-242.hsd1.al.comcast.net) |
| 15:29.44 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 15:29.44 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 15:44.04 | *** join/#asterisk-dev wudles (~wudles@gateway.secureinstrument.com) |
| 16:21.47 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 17:13.16 | *** join/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 17:13.16 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 17:22.00 | *** join/#asterisk-dev wudles (~wudles@gateway.secureinstrument.com) |
| 17:42.45 | *** join/#asterisk-dev wudles (~wudles@gateway.secureinstrument.com) |
| 17:56.47 | *** join/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 17:56.47 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 18:07.16 | *** join/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 18:07.16 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 18:22.57 | *** join/#asterisk-dev wudles (~wudles@gateway.secureinstrument.com) |
| 18:44.39 | *** part/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 19:33.31 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@bzq-84-111-20-159.red.bezeqint.net) |
| 19:33.31 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 21:24.33 | *** join/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 21:24.33 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 21:42.53 | *** join/#asterisk-dev wudles (~wudles@gateway.secureinstrument.com) |
| 23:20.27 | *** join/#asterisk-dev wudles (~wudles@gateway.secureinstrument.com) |
| 23:37.32 | *** join/#asterisk-dev wudles (~wudles@gateway.secureinstrument.com) |
| 23:43.55 | *** part/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 23:54.30 | *** join/#asterisk-dev wudles (~wudles@gateway.secureinstrument.com) |