Yes it would be interesting. Perhaps for 2.2.

I would also welcome this feature pretty much.

If I may, I also suggest:

- "Rec" press/depressed button in the main UI to be accessible quickly

Options in Preferences:

- "Record calls by default" to start recording upon call start automatically.

- "Compress to OGG" to background low priority compression.

- "OGG quality" - some settings...

- "Record audio only" - I don't know whether you consider to grab video streams too, one face on the left half, second on the right. :-) Or they can be alternated based on some voice detection like in the movie. Just kidding.

I imagine the following storage:

~/.ekiga-recordings/<initiator>-<called user>-<start YYYYMMDD-HHMMSS>.ogg

The call duration is easily deduced from the stream duration and does not need to complicate the file name.

About the format.

There should be several options to chose from. For example:
* RAW, simply the data which go thourgh the network, without any reencoding to different codec.
* WAV, uncompressed data that go into and out from soundcard.
* compressed, IMHO preferably ogg/speex.

Whichever way to record and compress you choose, files should be saved in stereo with each party in a separate channel. With OGG files it is possible to save even multi party conferences.

*** Bug 375221 has been marked as a duplicate of this bug. ***

*** Bug 352608 has been marked as a duplicate of this bug. ***

I'm assuming that there has been no progress on this?  (I'm waiting on the next ubuntu for 3.0 but I checked the feature list)

It would be really great to have this feature so I'm adding some thoughts.  It would probably not be too hard to code from scratch (I'm of course only guessing so don't bite if I'm wrong :) ), but there's a open source skype call recorder in case any of its code would help. http://atdot.ch/scr/

It would also be great to record video to ogg theora (or any format for that matter) though audio only would be fine if that's too hard.

There should be if possible a way to send a notification to the other party that you've started recording.  Just in case there are any legal requirements (if not a disclaimer/warning or something similar would probably be fine when enabling it)

Anyway I hope that ekiga will one day get this feature.  I've been having to use skype which is a shame as the non recording part is of course proprietary.

No progress on this -- and I don't think there will be any notification : it's up to you to tell the other end you're doing it (or request permission to do so).

Does your normal phone have anything to let you know the call is being recorded?

Wow that was quick.  I wasn't expecting a reply to this for days. :)

No a normal phone doesn't have anything like that and it was just a spur of the moment thought.  Not having it would be perfectly alright too.

Even though there has been no progress been made so far is it on any roadmap? (apologies if ekiga hasn't got one and people just add features to scratch specific itches)

The internals have been reworked heavily, but being able to do fancy things like changing devices during a call or recording isn't even realistically on the roadmap...

Changing devices during a call already works in 3.00 :-)

Would it be possible to feed ffmpeg with our streams and let it encode that in a container ? We already use ffmpeg and it does a great job at stuff like that.

In the mean time if you want to record Ekiga, both audio and video, one should be able to use some screencast software, e.g. this gui to ffmpeg : http://lprod.org/wiki/doku.php/video:screencastor (in french but it is translated in english too)

This feature is useful, I will try to work on it when I have time.  The first thing to test is that ptlib already offers a wav device, I have to look into it.  Also, think if using an external program (as you pointed out, Yannick) works.

So it could work, but I have to think about it and test it...

My idea is to feed ffmpeg directly with the streams (audio and video), IMHO it supports directly almost, if not all the codecs found in opal.

If you got to decode the audio stream (let's say PCMA) to wav then ask ffmpeg to re-encode it to let's say vorbis, or PCMA again you'll probably will lose quality in the process.

Try ffmpeg -codecs to see the list of codecs available. If the codec is supported in D (decode), ffmpeg should be able to transcode it to another format (let's say the audio in vorbis/mp3 and the video in Xvid)

I'm using the latest version here ffmpeg version 0.9.1 and I have those at least :
Codecs:
 D..... = Decoding supported
 .E.... = Encoding supported
 ..V... = Video codec
 ..A... = Audio codec
 ..S... = Subtitle codec
 ...S.. = Supports draw_horiz_band
 ....D. = Supports direct rendering method 1
 .....T = Supports weird frame truncation


 DEA D  g722            G.722 ADPCM
 DEA    g723_1          G.723.1
 DEA D  g726            G.726 ADPCM
 D A D  g729            G.729

 DEV D  h261            H.261
 DEVSDT h263            H.263 / H.263-1996
 D VSD  h263i           Intel H.263
  EV    h263p           H.263+ / H.263-1998 / H.263 version 2
 D V D  h264            H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10
 D V D  h264_vdpau      H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (VDPAU acceleration)

 DEA D  libgsm          libgsm GSM
 DEA D  libgsm_ms       libgsm GSM Microsoft variant

 DEA D  libspeex        libspeex Speex
  EV    libtheora       libtheora Theora
  EA    libvorbis       libvorbis Vorbis
 DEV    libvpx          libvpx VP8
  EV    libx264         libx264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10
  EV    libx264rgb      libx264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 RGB

 DEVSDT mpeg4           MPEG-4 part 2
 D V DT mpeg4_vdpau     MPEG-4 part 2 (VDPAU)

 DEA D  pcm_alaw        PCM A-law

 DEA D  pcm_mulaw       PCM mu-law

Try ffmpeg -formats to check if ffmpeg can mux and demux the stream in a container (E for muxing is the most relevant HIMO as Ekiga should have the streams available at hand directly):
File formats:
 D. = Demuxing supported
 .E = Muxing supported

 DE alaw            PCM A-law format
 DE alsa            ALSA audio output

 DE g722            raw G.722
 DE g723_1          raw G.723.1
 D  g729            G.729 raw format demuxer

 DE h261            raw H.261
 DE h263            raw H.263
 DE h264            raw H.264 video format

 DE m4v             raw MPEG-4 video format

 DE mulaw           PCM mu-law format

 D  video4linux,v4l Video4Linux device grab
 D  video4linux2,v4l2 Video4Linux2 device grab

Even more interesting is ffmpeg support protocols: ffmpeg -protocols
Supported file protocols:
I.. = Input  supported
.O. = Output supported
..S = Seek   supported

IO.   rtp
IO.   tcp
IO.   udp

I do wonder if all that means we can feed ffmpeg with the RTP stream directly abd have it to mux the audio and video stream to some nice container like avi,mp4 or mkv and also have the option to transcode audio and video in let's say Xvid/vorbis in a mkv, all in the fly for us.

I would gladly work on it with gstreamer, as that would be easy, but for some reason I never managed to get audio working and no one ever lent a hand...

Yannick, the first thing I have to do is to record it to wav; re-encoding it through ffmpeg is the second part.

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.