#362 SIPE currently ignores the local IP address configured in Pidgin, making it impossible to use with a corporate server that is reachable only via VPN

[Alain Knaff]

SIPE currently ignores the IP address configured in Pidgin's
Tools->Preferences->Network->IPAddress->PublicIP setting.

This breaks communications in different ways when connected via VPN to
a corporate Skype-for-business server which is only reachable via this
VPN.

3 issues were observed:

1. Slow establishment of connection: it takes about a minute until the
   popup to accept the call shows up at the callee's screen. After
   clicking accept, it takes again about a minute until caller and callee
   can actually talk to each other.

2. Possible to establish a call only in one direction. When attempting
   the other direction, the caller sees a pop-up "User sip:callee@yyy.lu
   is not available" after a while, the callee sees "User rejected
   acall". And the caller finds the following error in his log:
   ms-diagnostics: 13014;reason="The routing rules did not result in a
   final response and callee is not enabled for Unified Messaging"

3. After connection is established, from time-to-time the audio
   becomes unidirectional (no sound heard in the other directions), and
   than after a while bidirectional again.

Debug log shows that sipe actually tries to use both adresses as
return addresses for the sip stream: the LAN address of the PC
(192.168.178.42, unreachable from the Skype-for-business server), and
the VPN address of the PC (10.202.77.9, reachable from the server,
although it's a 10.x.x.x address). Actually 3 addresses, as the PC
initially also had an IPv6 address on the LAN.

Disabling IPv6 fixed issue #3, but the two other issues remained.

Explicitly entering the VPN address into Pidgin's
Tools->Preferences->Network->IPAddress->PublicIP setting didn't do a
thing. Note that I didn't indicate a STUN server, as there was no need
for one: my PC had connectivity without NAT with the
Skype-for-business server via the VPN. STUN would not have helped, as
our Skype-for-business server is not accepting requests from the
public network (where they would have come from if I had used STUN).

Then I made an LD_PRELOADable object which filtered unwanted IP
addresses out of the result from getifaddrs... The callee also
activated this on his side (he's on a similar VPN setup as me). This
solved (or rather: worked around...) all 3 issues.

Issue 2 is weird: apparently this should still have succeeded as one
of the two alternative streams that SIPE tried to establish had the
correct address (VPN). But apparently the handling of the error
response is broken, as it seems to tears down both streams if an
error is encountered on one of them (... while the other would have
succeeded if allowed to continue).

Attached is pidgin's stdout during issue #2 (with potentially
security-relevant info blanked), and a gdb stacktrace of where
getifaddrs is being called from: it is indeed SIPE who directly calls
purple_media_add_stream, without going through Pidgin! Which might
explain why a configuration in Pidgin is not being taken into account
(but obviously should).

Versions are 1.25.0-2 for pidgin-sipe (as in Debian testing), and
2.13.0-2.2+b1 for pidgin (as in Debian 10).

Thanks for fixing this,

Alain

[Stefan Becker]

libpurple API does not support IPv6, hence the code was replaced, see commit purple: update sipe_backend_transport_ip_address(). The code determines the IP address from the SIP connection socket which in your log shows f.ex.:

:::txt
(15:36:32) sipe: transport_get_socket_info: 10.202.77.9:55432(0x55eab8fae430)

So as far as I understand from your report SIPE does use the correct IP internally, e.g. in SIP message creation.

The rest of the issues you describe are most likely related to libnice, not SIPE. That library knows nothing about libpurple and hence won't honor any Pidgin settings anyway. SIPE just passes on the connection candidate information determined by libnice to the remote peer via SIP protocol and the media backend.

There is one thing you can check: please make sure that your version of libnice is not outdated. If your problem isn't fixed by libnice git HEAD code, consider reporting the issue as a bug there.

Closed as NOTABUG.

[Alain Knaff]

I reported it just now to libnice: https://gitlab.freedesktop.org/libnice/libnice/-/issues/108

[Stefan Becker]

libnice 0.1.14 is obsolete. I doubt they will act on the report unless you can
reproduce it with 0.1.16 or even better git HEAD.

[Alain Knaff]

It can still be reproduced with git HEAD (downloaded April 10th 16:33 CET)

[Alain Knaff]

Correction: Actually, there is some improvement with the HEAD version: connection can now be initiated from either side (issue #1) ... only the set up time remains slow (15 seconds) (issue #2).
With my trap-bind.c workaround, connection setup is instantaneous.

[Stefan Becker]

I'm taking an educated guess here:

• a detailed SIPE log with libnice git HEAD will show that the private IPs are no longer returned as valid candidates by libnice, i.e. they will no longer be included in the INVITE sent by SIPE when your side initiates the call.
• a detailed libnice log will show that the ICE handshakre requires roughly 15 seconds to determine that the private IPs are no valid candidates.

IMHO your issue is solved then.

[Alain Knaff]

a detailed SIPE log with libnice git HEAD will show that the private IPs are no longer returned as valid candidates by libnice

Indeed, there were no longer any "c=IN IP4 192.168.178.42" lines in the log with the git HEAD version.
However, the following still showed up:

a=candidate:1 1 UDP 2028994815 192.168.178.42 50054 typ host
a=candidate:1 2 UDP 2028994814 192.168.178.42 50030 typ host
a=candidate:10 1 TCP-PASS 174326015 185.106.25.8 59245 typ relay raddr 192.168.178.42 rport 50032
a=candidate:10 2 TCP-PASS 174326015 185.106.25.8 59245 typ relay raddr 192.168.178.42 rport 50032
a=candidate:2 1 TCP-ACT 1013580031 192.168.178.42 50032 typ host
a=candidate:2 2 TCP-ACT 1013580031 192.168.178.42 50032 typ host
a=candidate:3 1 TCP-PASS 1013186815 192.168.178.42 50032 typ host
a=candidate:3 2 TCP-PASS 1013186815 192.168.178.42 50032 typ host
a=candidate:9 1 TCP-ACT 174719231 185.106.25.8 59245 typ relay raddr 192.168.178.42 rport 50032
a=candidate:9 2 TCP-ACT 174719231 185.106.25.8 59245 typ relay raddr 192.168.178.42 rport 50032
a=candidate:1 1 UDP 2028994815 192.168.178.42 50005 typ host
a=candidate:1 2 UDP 2028994814 192.168.178.42 50034 typ host
a=candidate:10 1 TCP-PASS 174326015 185.106.25.8 56883 typ relay raddr 192.168.178.42 rport 50044
a=candidate:10 2 TCP-PASS 174326015 185.106.25.8 56883 typ relay raddr 192.168.178.42 rport 50044
a=candidate:2 1 TCP-ACT 1013580031 192.168.178.42 50044 typ host
a=candidate:2 2 TCP-ACT 1013580031 192.168.178.42 50044 typ host
a=candidate:3 1 TCP-PASS 1013186815 192.168.178.42 50044 typ host
a=candidate:3 2 TCP-PASS 1013186815 192.168.178.42 50044 typ host
a=candidate:9 1 TCP-ACT 174719231 185.106.25.8 56883 typ relay raddr 192.168.178.42 rport 50044
a=candidate:9 2 TCP-ACT 174719231 185.106.25.8 56883 typ relay raddr 192.168.178.42 rport 50044
a=candidate:1 1 UDP 2028994815 192.168.178.42 50007 typ host
a=candidate:1 2 UDP 2028994814 192.168.178.42 50022 typ host
a=candidate:2 1 TCP-ACT 1013580031 192.168.178.42 50005 typ host
a=candidate:2 2 TCP-ACT 1013580031 192.168.178.42 50005 typ host
a=candidate:3 1 TCP-PASS 1013186815 192.168.178.42 50005 typ host
a=candidate:3 2 TCP-PASS 1013186815 192.168.178.42 50005 typ host
a=candidate:7 1 TCP-ACT 174719231 185.106.25.8 56642 typ relay raddr 192.168.178.42 rport 50005
a=candidate:7 2 TCP-ACT 174719231 185.106.25.8 56642 typ relay raddr 192.168.178.42 rport 50005
a=candidate:8 1 TCP-PASS 174326015 185.106.25.8 56642 typ relay raddr 192.168.178.42 rport 50005
a=candidate:8 2 TCP-PASS 174326015 185.106.25.8 56642 typ relay raddr 192.168.178.42 rport 50005

a detailed libnice log will show that the ICE handshakre requires roughly 15 seconds to determine that the private IPs are no valid candidates.

Good to know, that nicely explains the exactly 15 seconds of connection set up time. And it also proves that somehow unusable addresses were still included at that initial stage of connection setup, even though they were later eliminated. Despite having explictely specified the IP address which should be used in Pidgin's config.

IMHO your issue is solved then.

Well not really. Bad addresses are still used at an initial stage, even though they are eliminated later on. If a correct address is manually configured, that one should be used, and no others should be "guessed".