Quoting Dave Koelmeyer:

"Ekiga 3.2.7 is running on two separate OpenIndiana machines, both have webcams 
connected which run fine using V4L2. Client A is running with a public IP 
address on a coporate LAN, client B is running behind a home ADSL2+ NAT router. 
Echo test and calling otherwise for both clients is fine.

In both Ekiga clients, only the H261 and Theora video codecs are selected.

Now, if I place a call from either Client A to Client B or vice versa, with the 
H261 codec only enabled or at the top in the Ekiga codec listing, then both 
parties can see both their local video and remote video, as you would expect.

If I then terminate the call, sort the video codecs so that Theora is only 
enabled or at the top in the Ekiga codec listing, then *only* the party to who 
the call is placed can see both their local and remote video. The user who 
placed the call can *only* view their local video stream.

For example; Client A calls Client B. The call is successfully handled, but 
Client A can only see his local video stream (remote video, picture in picture 
settings are greyed out). Client B however can enable both their local video, 
and the remote video.

Here is the debug output. Using the example setup described above (Client A calling Client B) this has been captured from Client A:

http://www.davekoelmeyer.co.nz/docs/ekigatheora20110121.txt "

In this output and the one posted in launchpad the error is shown here:

theora_plugin.cxx(390)	THEORA	Decoder	Got OGG data packet but still waiting for header and/or table Packets
2011/01/21 17:46:18.404	  0:15.595	       Media Patch:0x10	Patch	Media conversion (primary) failed
2011/01/21 17:46:18.404	  0:15.595	       Media Patch:0x10	Patch	WriteFrame failed
2011/01/21 17:46:18.404	  0:15.595	       Media Patch:0x10	Patch	Thread ended because all sink writes failed failed
2011/01/21 17:46:18.404	  0:15.595	       Media Patch:0x10	Patch	Thread ended for Patch OpalRTPMediaStream-Source-theora -> OpalVideoMediaStream-Sink-YUV420P

I will dig it further, with two machines here.

In the meantime, if you have spare time, it would be good if you could test with latest ekiga (on Windows it is http://eugen.dedu.free.fr/ekiga-setup-3.3.1-git-64_gb8c9352-debug.exe, on gnu/linux it should be compiled...)

A random thought - maybe this bug is related to this: http://thread.gmane.org/gmane.comp.video.gstreamer.devel/29500/focus=29501

Judging from the Dave's debug log, Ekiga sends Theora identification and setup headers in-band, but the packet carrying that data from the calee is lost, probably due to NAT or Ekiga starts listening on RTP too late. I suspect the latter, if it was NAT then I would expect only the party behind the NAT experiencing the problems w/ remote video, but that doesn't seem to be the case.


If the above is correct, here are some ways to attack (not exluding each other) this bug:
1) Include Theora configuration in SDP in addition to/instead of sending it in-band;
2) Ensure that Ekiga starts listening on incoming media as soon as it sends SDP, as required by RFC 3264;
3) On the sender side, retransmit the in-band configuration periodically;
4) On the receiver side, keep listening for in-band configuration if it is missing.


HTH

The same error appears at http://www.davekoelmeyer.co.nz/docs/EkigaWindows3.2.7TheoraFreezes.txt (see  for more information):

2010/12/07 18:11:25.713	  0:39.767	       Media Patch:1116	Patch	Media conversion (primary) failed
2010/12/07 18:11:25.713	  0:39.767	       Media Patch:1116	Patch	WriteFrame failed
2010/12/07 18:11:25.713	  0:39.767	       Media Patch:1116	Patch	Thread ended because all sink writes failed failed
2010/12/07 18:11:25.713	  0:39.767	       Media Patch:1116	Patch	Thread ended for Patch OpalVideoMediaStream-Source-YUV420P -> OpalRTPMediaStream-Sink-theora

However, this appears during communication (20 sec after beginning, i.e. at sec. 39), when the user moves, hence when video bitrate increases.

I suspect this might come from the fact that the machine is not able to process all the frames; it sends only the latest frames, skipping previous frames, which might contain vital information.  The hypothesis given in previous comment could be true too.

Before spending more time looking at the code (in opal, src/opal/patch.cxx and plugins/video/THEORA/theora_plugin.cxx), I think the simplest thing is to generate the -d 4 trace for *both* machines.  If this will not be sufficient, a wireshark capture for both machines allows to see what is sent and what is received, and compare with a correct communication.

Another occurrence is given at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=611313.

I forgot to add address in comment #4: see http://mail.gnome.org/archives/ekiga-list/2010-December/msg00007.html and follow-ups.

Hi, 

I have performed some further testing using the http://eugen.dedu.free.fr/ekiga-setup-3.3.1-git-64_gb8c9352-debug.exe application linked above. I have captured debug output from both machines as requested. 


TEST CASE SCENARIO

Machine 1) Ekiga 3.3.1 running on Windows XP SP3

Machine 2) Ekiga 3.2.7 running on OpenIndiana oi_147 x86

Both machines have public IP addresses, and reside on the same corporate 100Mb/s LAN.

I have a test Ekiga.net account on each machine. Webcams have been tested successfully on both machines (drivers are PTLIB/DirectShow on Machine 1, PTLIB/V4L2 on Machine 2). Theora is the only enabled video codec. PCMA and PCMU are the only enabled audio codecs, with PCMA sorted at the top. 

The video bitrate has initially been set to 128Kb/s on each machine, then the test has been repeated with the bitrate set to 1000kb/s on each machine.


=> Calling Machine 1 from Machine 2

Machine 1 detects an incoming call (a pop-up window appears with accept and reject buttons), but upon accepting the call, the client appears to crash: the call is never successfully answered, and the Ekiga GUI on Machine 1 appears to freeze, requiring termination of the application via the task manager. At the Machine 2 end, a constant ringtone is heard, until timeout. 


=> Calling Machine 2 from Machine 1

Machine 2 detects an incoming call (a pop-up window appears with accept and reject buttons). The call can be accepted. With the bit rate set to 128Kb/s, the video is observed to freeze at both ends almost instantly.

In the recorded debug outputs captured on both machines, video freezes roughly at the same time, about five seconds into the call.

The debug outputs for both machines are here:

www.davekoelmeyer.co.nz/docs/ekigamachine1-20110412-128kbs.txt
www.davekoelmeyer.co.nz/docs/ekigamachine2-20110412-128kbs.txt


Repeating the same test with the bitrate set to 1000Kb/s on both machines, everything seems far less susceptible to video freezing - I cannot reproduce the issue by making rapid movements in front of either webcam. However, remote video from Machine 1 viewed at the Machine 2 end appears to freeze by itself: in the following example debug output, video freezes at a call duration of around ~ 2m.10s.

http://www.davekoelmeyer.co.nz/docs/ekigamachine1-20110412-1000kbs.txt
http://www.davekoelmeyer.co.nz/docs/ekigamachine2-20110412-1000kbs.txt

Ekiga is not under active development anymore:
https://gitlab.gnome.org/Infrastructure/Infrastructure/-/issues/273

Ekiga saw its last release 7 years ago. The last code commits were 4 years ago.

Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (and transfer the project to GNOME Gitlab, as GNOME Bugzilla is deprecated) if anyone takes the responsibility for active Ekiga development again in the future.