I am looking for people to maintain and document
fritzcap.
Having for now survived metastasised rectum cancer, but still recovering from all the treatments (energy is about 25% of what I used to have), i need to tell you my further health future does not look bright. I have passed the moment of being sad about that and now face it as a fact of life: 90% of my peer group gets back metastases within 10 years time the chance I will make it to age 60 is slim.
It means I am preparing for when things get worse. If in the end things might still continue OK, it means I can have ease of mind instead of being in critical paths of things. Since the only guarantees in life are to die and to pay taxes, that is a good general approach anyway
Since my English is far better than my German writing (reading and speaking is OK, so feel free to respond in German), I have kept current documentation in English despite most of the Frtiz!Box users being in D-A-CH. That need to change to become more balanced.
So in short I am looking for people:
A. extending the current English documentation (mainly in direction of examples, capture interfaces
B. translating current English documentation into German and keep up with changes
C. act as a liaison between this forum and the
fritzcap GitHub repository
D. maintain and expand the current code base
Documentation wise, the capture interface - used with the
--cap_interface parameter - is kind of important, as in this thread quite a few people bumped into getting that correct. In that respect, I was quite surprised to find zero response to [
Wayback/
Archive]
[Frage] - Looking for input on Fritz!Box capture interfaces | IP Phone Forum. I know you can better given this thread is already 24 pages in size.
Even on the
GitHub: jpluimers/fritzcap: Fork of elpatron68/fritzcap which was previously automatically exported from code.google.com/p/fritzcap repository, many people had trouble:
1. finding
fritzcap/fritzcap-interfaces-table.md
2. interpreting the information in
fritzcap/fritzcap-interfaces-table.md
It means that documentation-wise, that needs to be better so it is easier for people to get started. That will help forum members too.
In addition documentation about configuring encoding in the Fritz!Box correctly (only unencrypted G.711 is supported by
fritzcap, and even sometimes that goes wrong) and explaining the why is important. Note that encryption won't be supported as that is impossible without the private key of the VoIP server (even with that, it is kind of hard todo, just search for people that have done it in Wireshark). Other encodings might be possible given the cap2wav shell script floating around this thread.
Both from a code and documentation perspective, it is important to get the
GitHub - jpluimers/fritzcap: Issues list synced with this thread.
As I don't have enough energy to get through all the 24 pages, I need help with that.
It would be cool if a few of the regulars in this thread would be so kind to split the pages among them and verify on each page if things asked there are covered in the issues and/or documentation and if not: add a new issue (or update an existing issue) linking to the messages here.
I know the syntax on this forum is vastly different from
Markdown used on
GitHub, but the issues do not need to be perfectly adhere to the
GitHub flavoured Markdown: basic writing and formatting syntax, just plain text is OK (note the
The Ultimate Guide to Markdown is easier to get started with Markdown than the GitHub documentation: feels a bit like the AVM documentation where blog posts and forums often are easier to get started with).
For me, I am fine with issues starting with a short broken English introduction section, then continuing the details in German both in rudimentary text. Maybe some volunteers then can help translating those parts in more proper English or Markdown.
Code wise, I am thinking about for instance:
- getting changed postulated in the forum into the
fritzcap codebase (for instance there seems to be a fix around for making the capture directories and filenames more descriptive).
- command-line switch to go from internal G.711 support to cap2wav
- compressing to mp3, flac, ogg, aac or other lossy or lossless audio formats
- running fritzcap as a Windows or Linux service
- making fritzcap more robust (autostart features upon failure - needs good failure detection! - or restart after a certain time of inactivity with the chance of missing a call)
I am mainly interested to keep things centered around the GitHub repository as the organisation there is much more suited to link code/documentation/issues than the forum is.
As an intermediate I could start a complete new thread that is only used as liaison between this forum and the GitHub repository.
Please let me know your inputs on that.
A blog post on
https://wiert.me asking for maintainers will follow in a few weeks time.
Regards,
--jeroen