From: john@nospam.thanks   
      
   > I took a look at the file. No SIP there, but just rtp, g.711 ulaw. _lots_   
   > of jitter. Way beyond the requirements for a stable SIP call.   
      
   Yes, I deleted all other packets except RTP.   
      
   I installed a softphone on a stationary computer and made a call from that   
   phone   
   to a softphone on my Android cell phone. The Android phone received the   
   SIP call via WiFi on a different network. So that might explain the jitter   
   you saw?   
      
      
   > Your observation is the standard jitter problem. When you play the stream   
   > in retrospect, all the packets are there, so wireshark can play out all   
   > the sound.   
      
   I don't agree. I think Wireshark is not capable of demultiplexing RTP packet   
   streams which is what the capture shows...The RTP stream is a stream of   
   multiplexed   
   RTP packets...some with payload type 101 and others with payload type 0.   
   Anyway...The payload type 101 packets shouldn't be there as they are   
   "out-of-band" DTMF tones...You don't signal DTMF tones _and_ send RTP   
   packets on top of that...that doesn't make any sense in my head. Either you   
   signal DTMF tones or you send the actual DTMF audio in RTP packets.   
      
   > But when the actual telephones did the call, you had a window of somewhere   
   > between 18 and 42 milliseconds for the packets to get there. Depending   
   > on the actual SIP implementation. (Or, RTP audio side). And a significant   
   > part of these packets got there, but too late to be useful.   
      
   That's a whole other issue :o)   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)