Problems with SRFLX ICE candidate

[Anand Sivaram]

Greetings,

I am making a session between an Android App using Native WebRTC (PEER1 Originating) and a libnice based PC client on the other side (PEER2 Terminating).  I observed that, around 10-20% of the sessions are failing and this happens only when the Android phone is connected to *one* particular ISP's 4G network.


Observations:

1) Switched off Wi-Fi on the Android phone, currently this particular 4G is the only network.  Also disabled TURN support to simplify things.  That way number of candidates could be limited.

2) When I open "www.whatismyip.com" or similar on Android browser, it shows an IPv6 address along with an IPv4 public address.  Let us say, this IPv4 address is X.Y.100.101 belonging to the ISP.

3) Repeated call sessions multiple times. During the time the sessions fail, Android PEER1 is generating and forwarding 2 SRFLX candidates, as shown below.  As I stated before, the 2nd SRFLX candidate is getting generated only 10-20% of times randomly and those are the failure cases.

SRFLX1: Candidate 1
candidate:842163049 1 udp 1685987071 X.Y.100.101 48269 typ srflx raddr 192.168.1.100 rport 48269 generation 0 ufrag WGLk network-id 3 network-cost 10
SRFLX2: Candidate 2
candidate:842163049 1 udp 1685987071 X.Y.109.200 48269 typ srflx raddr 192.168.1.100 rport 48269 generation 0 ufrag WGLk network-id 3 network-cost 10

4) That means, SRFLX1 is using the same public IP returned by "whatismyip".  SRFLX2 is a different IP address (X.Y.109.200) belonging to the Public pool of the ISP.  For both candidates the raddr/rport is the same and it is corresponding to the Address in the HOST candidate.

5) Now, I changed the terminating side (PEER2) to drop SRFLX2 candidate from processing, then I noticed that all the calls are getting connected.

6) But, instead if I drop the received SRFLX1 candidate on PEER2, then *no* call is getting connected.


Questions:
1) As I understand the SRFLX candidate is the public IP address the STUN server "sees" of the top most NAT.  Then, how could the same local raddr/rport be seen with two different public IP addresses?

2) This problem was seen only with one particular ISP network that too on 4G.  I tried with other 4G, Fiber, DSL etc. and I could not find the issue.

2) Could it be a bug in the stun server?

3) Or, is there any possibility of some routing issue for that particular ISP level?


I would appreciate any comments or feedback.


Thanks and Regards

Anand