Skype seems to fail with srv-rflx local candidates (peer-rflx identical candidates are OK)
Hi!
When pidgin + sipe-plugin is located behind a network with NAT, and initiates the connection to a Skype client, the discovery, integration in the connection check, and finally the nomination of pairs with a local candidate of type server-reflexive seems to generate a Skype error in a systematic way (x.x.x.x is the same local address in both components):
(Pidgin:3259): libnice-DEBUG: 12:14:49.932: Agent 0x61300001f4c0: Local selected pair: 1:1 13 UDP x.x.x.x:46725 PEER-RFLX
(Pidgin:3259): libnice-DEBUG: 12:14:49.932: Agent 0x61300001f4c0: Remote selected pair: 1:1 1 UDP y.y.y.y:50044 HOST
[...]
(Pidgin:3259): libnice-DEBUG: 12:14:50.162: Agent 0x61300001f4c0: Local selected pair: 1:2 9 UDP x.x.x.x:50051 SRV-RFLX
(Pidgin:3259): libnice-DEBUG: 12:14:50.162: Agent 0x61300001f4c0: Remote selected pair: 1:2 1 UDP y.y.y.y:50045 HOST
[...]
MESSAGE START <<<<<<<<<< SIP(0x60e0001238e0) - 2019-07-08T10:14:30.928583Z
SIP/2.0 500 Server Internal Error
[...]
User-Agent: UCCAPI/16.0.11727.20086 OC/16.0.11727.20230 (Skype for Business)
ms-client-diagnostics: 52001;reason="Client side general processing error."
Content-Length: 0
For this situation to happen, the router doing the NAT must not randomize its source port mapping, so a server-reflexive discovered candidate will still work during the conncheck. When NAT port mapping is randomized, new peer-reflexive candidates are obtained during conncheck, that deprecate the server-reflexive candidate initially discovered, and Skype works in that case.
I'm wondering if libnice shouldn't just disable completely the discovery of local server-reflexive candidates when compatibility mode is oc2007r2 ?
Another possibility could be to rewrite "on-the-fly" the selected candidate type in the sipe-plugin when writing the sdp. But it wouldn't fix the problem at the library level.
Do you have suggestions about that? Similar observations? More targeted workaround?