Bug 1713947 - Sip protocol fails for private IPv6 addresses on peer to peer
Summary: Sip protocol fails for private IPv6 addresses on peer to peer
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: linphone
Version: 32
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: nucleo
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2019-05-26 00:56 UTC by Stuart D Gathman
Modified: 2020-05-01 00:42 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed:
Type: Bug

Attachments (Terms of Use)

Description Stuart D Gathman 2019-05-26 00:56:42 UTC
Description of problem: calls terminate after a little over 32 secs

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Make peer to peer call between private IPv6 addresses

Actual results:
Call works normally for 30+ seconds, then disconnects with timeout for CALL ack error in debugging log.

Expected results:
Normal call

Additional info:
This broke early this year, with no change to linphone itself.  My debugging points to eXosip library.  The problem is that the CALL Ack gets sent to a public IPv6 if one is available.  If IPv6 is completely disabled on both machines except for the VPN interface (using IPv4 for VPN packets), then it still works normally.  The SIP handling really, really, hates to use private IPs.

Upstream says they no longer support eXosip - and please use a newer version.  Any chance of packaging a newer version?  (Does it break something else?)  Should I file a separate "New Release Available" bug?

Comment 1 Stuart D Gathman 2019-05-26 01:04:49 UTC
The workaround for now is to echo 1 > /proc/sys/net/ipv6/conf/<yournetif>/disable_ipv6
Your VPN should not depend on IPv6 and the private IPs will still be available on the tunX interface for the VPN.  

To restore normal IPv6 connectivity, echo 0 to disable_ipv6 for the wifi/ethernet.

Note: a peer to peer IPv6 sip URL looks like this:

Linphone addressbook handles that just fine.

Also, upstream claims to have simplified and improved peer to peer operation.

Comment 2 Stuart D Gathman 2019-05-26 01:07:45 UTC
Note: a peer to peer call over public IPv6 also works fine.

Comment 3 Stuart D Gathman 2019-05-27 18:57:11 UTC
I tried just plugging in linphone-3.12.0 - and a required dependency is bctoolbox, which isn't in Fedora.  So updating is not trivial.  bctoolbox has a GPL2 license, so could be packaged for Fedora.  Or maybe it should be embedded?

Comment 4 nucleo 2019-05-27 19:07:12 UTC
Also mediastreamer is not included in new linphone sources.
If you can suggest changes in linphone.spec to build all of them in one package (or submit for review separate packages containing required dependencies) then maybe will be possible to build linphone update.
Building of belle-sip is also not trivial.

Comment 5 Stuart D Gathman 2019-05-27 19:24:04 UTC
Tried 3.6.99 (which has a fix that might address my problem), and it requires:
 configure: error: Package requirements (belle-sip >= 1.2.0) were not met

I'm guessing they stopped using libeXosip2 at that point?

Comment 6 Stuart D Gathman 2019-05-27 19:26:08 UTC
I had no problem dropping in mediastreamer2 as an embedded source.  It should probably be it's own package in Fedora, but just trying to find a target I can get working atm.

Comment 7 nucleo 2019-05-27 19:30:02 UTC
Looks like belle-sip is new sip stack used for new linphone versions.
It was packaged but currently FTBFS https://src.fedoraproject.org/rpms/belle-sip
belle-sip will be removed if FTBFS will be not fixed (I have no time to work on fix).

Comment 8 Stuart D Gathman 2019-05-27 21:10:01 UTC
I'm going through belle-sip build errors on f29 - they are all compiler warnings.  Some are real potential overwrite bugs, so I'm patching them all.  Got 4 done.

Comment 9 Stuart D Gathman 2019-05-28 00:04:34 UTC
Got belle-sip-1.4.2 built for f29 and f30.

Comment 10 Stuart D Gathman 2019-05-28 00:20:53 UTC
Now I can drop the other sip libs as BR and add bell-sip.  Building linphone-3.6.99 now fails at:

config.status: creating m4/Makefile
BUILDSTDERR: config.status: error: cannot find input file: `po/Makefile.in.in'

There is indeed no po/Makefile* in the source.

Comment 11 Stuart D Gathman 2019-05-28 00:36:59 UTC
Copied po/Makefile.in.in to SOURCE2 for building 3.6.99 (missing in 3.12.0 also).  Now configure for mediastream2 can't fine ortp:

checking for ORTP... no
BUILDSTDERR: configure: error: Couldn't find ortp library
BUILDSTDERR: configure: error: ./configure failed for mediastreamer2

Comment 12 nucleo 2019-05-28 16:19:40 UTC
Maybe also ortp needs to be updated.
I added sdgathman in acl for ortp, belle-sip, linphone.

Comment 13 Stuart D Gathman 2019-05-29 02:14:10 UTC
Yes, mediastreamer2 requires ortp >= 0.24.0

Comment 14 Stuart D Gathman 2019-06-01 15:12:47 UTC
ortp 0.24.0 drops built-in srtp.  Instead of disabling srtp, I think it's time to make the bctoolbox package, and see if we can get all the way up to date.

Comment 15 Stuart D Gathman 2019-08-03 19:26:03 UTC
I did a test with IPv4 VPN on linphone-3.6.1, it does the same thing.  The two ends connect at private IPs, the call lasts for 30 secs, packet trace shows that the SIP stack replaces the private IP specified as "gateway" with an arbitrary public IP - despite the devices not being able to reach each other on public IP (behind NAT).  As mentioned before, this broken behavior is new for 2019. I'll try to get back to updating, but I have two packages failing to build in rawhide...

Comment 16 Ben Cotton 2020-04-30 21:25:22 UTC
This message is a reminder that Fedora 30 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '30'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 30 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Note You need to log in before you can comment on or make changes to this bug.