The impacts of ICE Candidate gathering mechanisms on STUN bad M-I errors

[André Cravo]

Hi,

I'm currently working on an iOS app that uses WebRTC to connect with a web app. The iOS app will act as the caller and the web app as the callee.

I'm using a generated build from trunk revision 5773 and can successfully (at random times) have sound and video shared from the web app to the iOS app and sound from the iOS app to the web app (per requirement).

My issue is that most of the times the peers fail to connect, throwing errors like "Received STUN request with bad M-I from <ip:port>", "Received STUN request with bad local username <generated-username> from <ip:port>" or even "Received TURN data indication with invalid peer address, addr=<ip:port>".

Since I'm not using trickle ICE "mechanism", and in almost every example I find it's being used, I was wondering if this could cause my connection problems. What I do is:

1. Create the peer connection in the iOS app (adding the stream with audio)

2. As the callback on ice candidate fires (peerConnection:gotICECandidate:) is called , and create the candidate and add him to the peer connection (os the iOS app).

3. When the ICE gathering is completed, I send the SDP offer to the web app.

4. On SDP offer, the web app creates the peer connection and add the local stream (from the getUserMedia).

5. Generate the SDP answer (but don't send it just yet)

6. On icecandidate callback , if we have a candidate I add it to the web app peer connection.

7. After gathering is completed, I send the SDP answer to the iOS app.

I've compared logging for success and error cases and failed detect the issue.

I've attached one log file with an example of the issue I'm facing.

If someone as any hint, it would be appreciated.

Thanks,

Andre

[Silvia Pfeiffer]

You might be hitting a timeout between the creation of your sdp and setting it. Chrome doesn't like old sdp.

Best Regards,
Silvia.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[André Cravo]

Hi Silvia,

Thanks for the reply. Let me see if I understand. You're saying that there's a timeout value for setting the SDP as the offer after it was generated? And that might be causing this type of errors. So theoretically, by using trickle ICE and setting the SDP faster, this problems might be avoid.

I should dig in the WebRTC code (that I believe is shared between the iOS app and Chrome browser. The use the same WebRTC foundation code right!?). Should I be looking for something in particular?

Big thanks.

Andre

[Justin Uberti]

The timeout was removed in a recent version of Chrome - not sure if Chrome 33 or 34. Can you retry on Chrome 34 or canary?

[André Cravo]

Hi Justin,

Thanks for the hint. But even with Chrome Canary (Version 36.0.1922.0 canary) on Mac OS X Mavericks, I get the same behaviour.

Cheers,

Andre

[Mallinath Bareddy]

Is it possible to send wireshark traces along with logs? I suspect there is some mess up with ice ufrag/pwd.

[André Cravo]

Hi Mallinath,

A fresh log file and corresponding capture file is attached.

Thanks.

Cheers,

Andre 

[André Cravo]

It appears to me that the SDP might be getting corrupted by my signalling "system". For instance, the + sign on the ufrag is replaced by a space. Gonna check it.

[Mallinath Bareddy]

Yea, most likely some corruption is happening. I can see that username attribute in STUN BINDING request and ice-ufrag in SDP are not matching.

[André Cravo]

Hi,

Guys this was totally an SDP corruption. When the ufrag or password (besides everything else in the SDP) had plus signs (or other url reserved characters) they we're getting messed up.

Big thanks to y'all.

Andre

[Anna Noell]

Hi André,

Did you ever solved this? I have the same problem.

[Federico Henze]

Hi

I experienced the same problem and the solution was disabling the pooling on the socket instance (SocketIO in my case) used to establish the connection. 

[[SocketManager alloc] initWithSocketURL:self.configuration.sessionManagerURL config:@{

@"log": @NO, @"forcePolling": @NO, @"selfSigned": @NO, @"sessionDelegate": self.configuration, @"path":socketPath}];

If you used polling the SDP should be base64url encoded in order to avoid this scenario.

Good luck!