Dear maintainer, A week ago pjproject 2.5.5 has been made available in Debian. The same as in ring-daemon contribs. However ring applies following patches: endianness.patch gnutls.patch notestsapps.patch ipv6.patch ice_config.patch multiple_listeners.patch pj_ice_sess.patch fix_turn_fallback.patch fix_ioqueue_ipv6_sendto.patch The biggest one gnutls.patch can be dropped, since packaged pjproject can dynamically link to a SSL library. Is the rest important? If not, then the packaged pjproject could be used already. If not, is pjproject not really usable without them? Then they should be forwarded upstream and for now applied in the packaged pjproject. Or there are some issues with that? Please share the current status. Thanks, Andrey
Dear ring and srtp maintainers, additionally, how important is the usage of a recent version of libsrtp? 1.5.3 is already available in Debian experimental, thus the update to a bug fix release 1.5.4 should be easy, doesn't it? Or there is some blocking issue (if yes, what is the status/progress)? Thanks, Andrey
asterisk. Upstream of asterisk recommends applying a set of their own patches: http://git.asterisk.org/gitweb/?p=asterisk/asterisk.git;a=tree;f=third-party/pjproject/patches;hb=13
Hello, gnutls.patch ============ Savoir-faire Linux supports the whole stack and all pjsip bumps are tested extensively. This would require some investigation as we are not sure that Ring would work correctly if pjsip linked against OpenSSL. Also, Ring is not licensed with an OpenSSL exception. As far as I can tell, this means that we couldn't link with OpenSSL: - https://lists.debian.org/debian-legal/2002/10/msg00113.html - https://www.gnu.org/licenses/license-list.en.html#OpenSSL My interpretation of this is that it would not be legal to distribute a version of Ring that links with a version of pjsip that links with libssl, because the combined work uses all of those libraries. The best case scenario would be that our GnuTLS patch gets merged and that Debian links pjsip against GnuTLS. Related link: - http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/2014-May/017492.html Would someone like to help us move this forward? other patches ============= Some of the other patches are absolutely necessary and are needed for Ring to work. Some patches have already been forwarded to upstream but require more work. For example, multiple_listeners.patch works for our use case but would need further work to be applicable to the whole library. I'll mail ring devs about this because me and Guillaume Roguez couldn't remember exactly what this was for. This isn't really needed. This isn't really needed, depending on how pjsip is built in Debian. This is absolutely needed, but might not be wanted by upstream. In our use case, we need many more ICE candidates than what is configured by default. I have talked with the author and we might be able to drop this one. However, it wouldn't hurt to have it merged You can take a look at upstream's review here: - http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/2016-April/019197.html This one needs much more work to be applicable to all use cases. This is a hack to allow us to add reflective candidates ourselves to the ice transport. This may not be the right way to do it, but we absolutely need the feature. If you want to help move this bug forward, that would be patch to start with. I will submit this to upstream right now. PJSIP gives up the ice initialization if the turn server does not respond/work properly. However, we might still be able to make a call because the other candidates could work. Some of it is already fixed in the master branch but their solution is incomplete. I am submitting it to upstream right now. There is a structure that does not support IPV6 addresses yet. This causes an abort. Cheers,
Hello, The author is Guillaume Roguez <guillaume.roguez@savoirfairelinux.com> (in CC). The patch was developed for Ring (https://ring.cx/) Please let us know if you have any questions,
Erm. Now the patch is attached. I promise.
This patch fixes an issue where ice init fails when there is a bad server. Init should not fail, because other candidates might still work. Some of this patch was already integrated in the master branch of pjsip, but it does not cover all use cases. The author is Guillaume Roguez <guillaume.roguez@savoirfairelinux.com> (in CC). The patch was developed for Ring (https://ring.cx/) Related issue: https://trac.pjsip.org/repos/changeset/5465 Please let us know if you have any questions,
Hi Tzafrir, hi Bernhard, hi Alexandre Tzafrir, thanks for pointing this out. I've just noticed that these patches have been included in pjproject. Bernhard, what do you think about including the bug-fix patches from the Ring's pjproject also? For the same reasons as for Asterisk [1]: Alexandre, could you please add "forwarded upstream" links for each of these patches and what Ring bugs are they suppose to fix? Thanks, Andrey [1] http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/2016-November/019650.html
Alexandre, sorry, I haven't received your mails (CC: me?), now found them on the bug report page. Thanks. Andrey
No objections per se, as long as the changes do not interfere with Asterisk. Ideally they have already been accepted upstream and are only small, verifiable changesets. Looking at the list Alexandre at least some of them don't really fall into this category. Especially, although I'm disgruntled by the OpenSSL mess, switching to GnuTLS that close to the freeze is something I want to avoid. Also adding symbols that might cause a transition to be necessary in case we would have to revert them. If you have a cleaned up list of patches you definitely need, ideally with upstream commits and/or explainations why they won't affect Asterisk's use of pjproject, please file a bug on pjproject and we'll have a look. Bernhard
pjproject and libsrtp have been removed from Debian for a long time, so this bug is not valid anymore. There is libsrtp2 now, which can be used maybe. Debian's current version is 2.3.0 which is later than the bundled version.