Comment 22 for bug 380091

BrainwreckedTech ,

Sorry for the long delay.

I cannot really explain why the first log (MTU 7000) is a failure.
The PDU is bigger than 1500, Ekiga is sending the packet. But the connection timeout. Something in path is eating the packet, most probably because of MTU reason.

Indeed, in the second log, with a PDU smaller than 1500, Ekiga connect to the echo test. Thus if the size of the packets is smaller than 1500 (approximately, we will discuss this later), the connection works.
The issue with no sound is not related to the MTU issue; the echo test simply do not support the GSM codec and SIP is designed as a best effort: thus as Ekiga and the echo test can agree on video, you only get video. This is something you can see on the panel call, below the video are the codecs in use; GSM was probably not written there.

The interesting point here is even if the MTU is large enough for the PDU Ekiga use (PDU ~1600 and MTU 7000) the connection failed because of a timeout. Something in the path did nor react well to the PDU size, i do not know what it is (might even be our server...). This need further investigation.But I've no clue how to do this. I'll ask our dev, but he is on holidays now and it is somewhat tricky...

The third log is also interesting; it prove if the PDU is a little bit bigger than 1500, the connection can work. I observe the same using my own setup. 1500 is not a hard threshold. I've no clue why.

The 4th log works as the PDU is smaller than 1500 and the echo test accept the audio codec proposed. The noticeable drop out are explained as some kind of network congestion. Ekiga is designed to not allow a delay bigger than 500milliseconds (above that is not good for audio communication; you will experience a long delay before the other side answer you), if the delay is bigger it drops packets. The PCMA codec is the simplest codecs, it has no mechanism to correct the perception if packets are dropped, thus the noticeable drop out. Other codecs more sophisticated have mechanism to support packets drop (at some extend), e.g. speex.

This is expressed in the log:
2009/07/10 18:28:36.451 0:25.460 Media Patch:0xef4af950 RTP Jitter buffer length exceeded
2009/07/10 18:28:36.451 0:25.460 Media Patch:0xef4af950 RTP Jitter buffer oldest packet (78720 < 79040) too late, throwing away
2009/07/10 18:28:36.451 0:25.460 Media Patch:0xef4af950 RTP Jitter buffer oldest packet (78880 < 79040) too late, throwing away
2009/07/10 18:28:36.451 0:25.460 Media Patch:0xef4af950 RTP Jitter buffer size increased to 4000 (500ms)

2009/07/10 18:28:45.810 0:34.819 Media Patch:0xef4af950 RTP Jitter buffer length exceeded
2009/07/10 18:28:45.811 0:34.820 Media Patch:0xef4af950 RTP Jitter buffer oldest packet (133120 < 153440) too late, throwing away
2009/07/10 18:28:45.811 0:34.820 Media Patch:0xef4af950 RTP Jitter buffer oldest packet (133280 < 153440) too late, throwing away
2009/07/10 18:28:45.811 0:34.820 Media Patch:0xef4af950 RTP Jitter buffer size increased to 4000 (500ms)

2009/07/10 18:28:46.051 0:35.060 Media Patch:0xef4af950 RTP Jitter buffer length exceeded
2009/07/10 18:28:46.051 0:35.060 Media Patch:0xef4af950 RTP Jitter buffer oldest packet (133440 < 153440) too late, throwing away
2009/07/10 18:28:46.051 0:35.060 Media Patch:0xef4af950 RTP Jitter buffer oldest packet (133600 < 153440) too late, throwing away
2009/07/10 18:28:46.051 0:35.060 Media Patch:0xef4af950 RTP Jitter buffer oldest packet (133760 < 153440) too late, throwing away
2009/07/10 18:28:46.051 0:35.060 Media Patch:0xef4af950 RTP Jitter buffer oldest packet (133920 < 153440) too late, throwing away
2009/07/10 18:28:46.051 0:35.060 Media Patch:0xef4af950 RTP Jitter buffer oldest packet (134080 < 153440) too late, throwing away
2009/07/10 18:28:46.051 0:35.060 Media Patch:0xef4af950 RTP Jitter buffer oldest packet (134240 < 153440) too late, throwing away
2009/07/10 18:28:46.051 0:35.060 Media Patch:0xef4af950 RTP Jitter buffer oldest packet (134400 < 153440) too late, throwing away
2009/07/10 18:28:46.051 0:35.060 Media Patch:0xef4af950 RTP Jitter buffer oldest packet (134560 < 153440) too late, throwing away
2009/07/10 18:28:46.051 0:35.060 Media Patch:0xef4af950 RTP Jitter buffer oldest packet (134720 < 153440) too late, throwing away
2009/07/10 18:28:46.051 0:35.060 Media Patch:0xef4af950 RTP Jitter buffer oldest packet (134880 < 153440) too late, throwing away
2009/07/10 18:28:46.051 0:35.060 Media Patch:0xef4af950 RTP Jitter buffer oldest packet (135040 < 153440) too late, throwing away
2009/07/10 18:28:46.051 0:35.060 Media Patch:0xef4af950 RTP Jitter buffer oldest packet (135200 < 153440) too late, throwing away
2009/07/10 18:28:46.051 0:35.060 Media Patch:0xef4af950 RTP Jitter buffer size increased to 4000 (500ms)
2009/07/10 18:28:46.051 0:35.060 Media Patch:0xef4af950 RTP Jitter buffer length exceeded
2009/07/10 18:28:46.051 0:35.060 Media Patch:0xef4af950 RTP Jitter buffer oldest packet (135360 < 153440) too late, throwing away
2009/07/10 18:28:46.051 0:35.060 Media Patch:0xef4af950 RTP Jitter buffer size increased to 4000 (500ms)

The "compact form" is part of the SIP standard:
http://tools.ietf.org/html/rfc3261#section-7.3.3
"SIP provides a mechanism to represent common header field names in an
   abbreviated form. This may be useful when messages would otherwise
   become too large to be carried on the transport available to it
   (exceeding the maximum transmission unit (MTU) when using UDP, for
   example)."
This is a standard optimization to not exceed the MTU if possible.

AFAIK, only the first log is a bug. Still as Ekiga send the packets, I doubt it is a bug in the Ekiga softphone.

Best regards,
Yannick