Timeout in ICE candidates allocations?

[Lorenzo Miniero]

Hi all,

we've been playing with Chrome and a gateway (webrtc2sip) on some IMS-related scenarios. While this mostly works fine, there is one scenario in particular that is giving us a few headaches.

The scenario involves a Chrome user placing a call to another user through the gateway. Everything works fine if the callee answers in a short time (let's say 10 seconds or so), but whenever the callee takes some more time to answer (e.g., 25 seconds), the call is not established. Looking at a few wireshark dumps, we could verify that the gateway, which is between caller and callee, correctly sends STUN binding requests, but Chrome doesn't respond to any of them. To make sure it wasn't a webrtc2sip issue, we also tried to do the same using a simple p2p app based on JsSIP and the same thing happened.

For the sake of completeness, we tried this both in NATted scenarios and public ones and it made no difference, which means it probably is not anything related to NAT bindings expiring. From what we could understand, it looks like Chrome is simple refusing to respond to STUN requests after a fixed (?) timeout.

Anyone else experiencing the same behaviour? Is this a known bug/limitation? If so, is there any workaround that could "patch" this behaviour until this is fixed, e.g., some way to refresh the candidates and keep them alive?

Thanks,

Lorenzo

[Mallinath Bareddy]

On Tue, Sep 3, 2013 at 6:00 AM, Lorenzo Miniero <lmin...@gmail.com> wrote:

o tried to do the same using a simple p2p app based on JsSIP and the same thing happened.

Lorenzo, 

Is it possible to send the wireshark logs?

[ebu...@thrupoint.com]

We came across the same problem, and I seem to recall there being some bug related to it open, but I haven't followed it. I think we worked around it by not giving Chrome SDP until the user answered so no ICE happens till then.

Eric

[Lorenzo Miniero]

Mallinath,

my colleagues will prepare some dumps for you to look at as soon as they get back to the lab tomorrow. 

[Lorenzo Miniero]

Il giorno martedì 3 settembre 2013 18:01:07 UTC+2, ebu...@thrupoint.com ha scritto:

We came across the same problem, and I seem to recall there being some bug related to it open, but I haven't followed it. I think we worked around it by not giving Chrome SDP until the user answered so no ICE happens till then.

Eric

Yes, that's what apprtc seems to be doing as well. Since we're using SIP, though, and passing through IMS, the only way to do so would be to start with some offerless INVITE to delay the negotiation, which is something we haven't tried as of yet: besides, I'm not even sure the SBC or other intermediaries would digest it.

[TJ Grant]

Lorenzo…

In my experience (about two years ago) we'd run into the issue where Google's STUN server would not respond in a timely manner on occasion.

I think what you're seeing is not a specific bug in a server or browser, but instead just a single server that is trying to respond to everyone's requests (AppRTCDemo, peerconnection_client, etc.)

The way we resolved this issue at the time was to compile and set up our own "STUN" server for development purposes, and then point to that server in our configuration instead.

There's an open source one here: http://sourceforge.net/projects/stun/

I may be wrong, but I can't imagine Google wanting everything that uses WebRTC to use one global STUN server for IP resolution, however this is what all the sample code essentially does.

Best regards,

--TJ Grant
tjg...@tatewake.com

On Tue, Sep 3, 2013 at 6:00 AM, Lorenzo Miniero <lmin...@gmail.com> wrote:

--
 
---
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/groups/opt_out.

[Pierluigi Palma]

Hi TJ Grant,

thanks for the response, but the problem almost certainly is not the STUN server. In fact, browsers clients communicate only with webrtc2sip gateway, which is connected with an IMS network. The problem occurs when the aswer arrives after 25 seconds. In this case, Chrome clients doesn't respond to gateway binding requests, related to connectivity checks.

These problems happen also with another WebRTC o/ SIP client (JsSIP) so I tend to exclude bugs related to our client. In addition, using our client with Firefox, all works fine.

This is why I think that Chrome is someway involved.

[Pierluigi Palma]

In order to demonstrate that the problem is related to Chrome, i've made a simple test application which set up a peer-to-peer webrtc call with only video. 

In the first case (webRTC-TEST-Report-KO), the answer is sent after 30 seconds. As expected, the call fails.

In the second case (webRTC-TEST-Report-OK), the answer is sent after 20 seconds. In this case, it works.

See the attached logs.

Il giorno martedì 3 settembre 2013 16:30:43 UTC+2, Mallinath Bareddy ha scritto:

[Mallinath Bareddy]

My guess, this is happening is due to chrome receiving the stun binding requests before the answer received. Which can cause chrome reject incoming stun requests. Chrome (libjingle) doesn't has any timers for this. 

[Lorenzo Miniero]

Not answering until the answer has been processed is normal, and that's fine, that has always worked. This is a different issue, since the problem only happens when the answer is processed after a longer period of time. If Chrome doesn't envisage any timer in that sense, it's probably a bug.

Would it help if we shared the simple p2p app we're using for our tests, so that you can replicate the issue yourselves?

Lorenzo

[Mallinath Bareddy]

Yes please

[Pierluigi Palma]

Hi Mallinath,

I attached the code of the simple test application used to obtain previous logs.

The server is Nodejs. In order to deploy it on Windows (which is my environment) it is necessary to install nodejs for windows (download it from official website), then in eclipse add nodeclipse plugin (add the repository in Eclipse and install it). If it is necessary, open nodejs command line and give this two command to download additional modules: "npm install node-static" and "npm install socket.io".

At this point you should be able to start the server in Eclipse, running as node application the server file. If all work, you should see messages in Eclipse console. Now the last step is to open two browser tabs and go to 127.0.0.1:2013 and enter the same room name.

To change the timeout after which the peer sends its response, modify the js client code at line 84.

I hope I was clear!

[Robert]

Hi,

Do you have any new insights on this issue? We have the same problem. Has a bug been filed or something?

Thanks,
Robert

[Pierluigi Palma]

Hi Robert,

I suggest you to follow these issues related to the problem of the ICE candidates:

https://code.google.com/p/webrtc/issues/detail?id=2563

https://code.google.com/p/webrtc/issues/detail?id=2613

Kind Regards.

2013/11/28 Robert <hoffma...@googlemail.com>

--

---
You received this message because you are subscribed to a topic in the Google Groups "discuss-webrtc" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/discuss-webrtc/rKDoLqDe9Z8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to discuss-webrt...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--

Palma Pierluigi

Contacts:

palma.p...@gmail.com

palma.p...@meetecho.com

Skype: palma.pierluigi

[Vikas]

Hi,

Thanks, It would be good if you can attach the test page to issue 2563 or 2613 as the problem symptoms are the same.

/Vikas