Well, I'm sorry Steve but apparently, all the equipment I have at home are switches, no hub. Consequently, I could not build a setup where I could record all data to the ATA with Wireshark. I'll have to repeat the test later with my hub I have at work.
However, as I was already in the mood for it and had quite a lot of laundry to attend to, I did the following test.
I called my FPL line from my cellphone. I placed the cellphone near the computer's speakers and put on some music. I then hooked a headset to my home cordless phone, and went on to do some laundry listening to music streaming through pc -> cellphone -> FPL -> DSL -> ATA -> cordless. Crazy setup and the sound is not that great!
I listened to 7 minutes of continuous music. Absolutely impeccable. No glitches, no cuts, no delays. Other than the horrible sound quality (voice codecs have hilarious artifacts when dealing with electronic music), it was wonderful.
Then, I swapped the setup around. From my cordless phone (ATA/FPL), I called my cell. I placed the cordless near the speaker, put some headphones on my cell, and went back to do 15 more minutes of laundry while listening to the music. Again, impeccable. Not a single cut or glitch or delay. Again, horrible sound quality, much worse than with the iphone's mic. I assume the panasonic whatever cordless phone is already breaking up sound nicely even before it reaches ATA.
In any case, I'm very sorry (to other forum members) to inform you that in my case, there's no issue, at least not tonight.
Oh and I forgot Ping Plotter running since last Friday, so I now have about 280 000 pings to graph. In any case, here's the graph from the duration of my calls, about 25 minutes in total.
Interesting points to note about this graphic:
1) there's a few packet loss here and there on various hops. Didn't seem relevant to the voice data.
2) I set my Ping Plotter to use UDP pings, not ICMP. This way, I am apparently a bit closer to reality for VoIP in the test.
I'll try to bring a hub home so that I can repeat this test with wireshark running, but since it didn't do the issue to me, the log would only prove that I can't reproduce the issue others have.
One more thing: the audio source was a huge (34 minutes) youtube video, so I had quite some data going on during the entire test, which explains why all ping times go from near-zero to fifty-ish.