Chrome M24 and webrtc2sip : ICE issue ?

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Use SIPML5 demo page, lightly modified to enable to initiate calls without 
priori registration
2. Make a call to a SIP legacy video system with Chrome stable (M24)
3.

What is the expected output? What do you see instead?
No audio/video.
ICE connectivity checks seem to fail. Looking at network traces show that no 
STUN requests are sent/received (except those sent by webrtc2sip to 
stun.l.google.com). Furthermore (or consequently), webrtc2sip sends SRTP to a 
candidate IP that is not routable for it (192.168.1.24).

What version of the product are you using? On what operating system?
webrtc2sip 2.2.0
SIPML5 r168

Please provide any additional information below.
webrtc2sip config.xml:
<config>

  <debug-level>INFO</debug-level>

  <transport>udp;*;10060</transport>
  <transport>ws;*;10060</transport>
  <transport>wss;*;10062</transport>

  <enable-100rel>no</enable-100rel>
  <enable-media-coder>yes</enable-media-coder>
  <enable-videojb>no</enable-videojb>
  <rtp-buffsize>65535</rtp-buffsize>
  <avpf-tail-length>100;400</avpf-tail-length>
  <srtp-mode>optional</srtp-mode>

  <codecs>pcma;pcmu;vp8;h263</codecs>
  <enable-rtp-symetric>no</enable-rtp-symetric>
  <srtp-type>sdes</srtp-type>
  <video-size-pref>cif</video-size-pref>

  <!--nameserver>66.66.66.6</nameserver-->

  <!--ssl-certificates>
    self.pem;
    self.pem;
    *
  </ssl-certificates-->

</config>

Original issue reported on code.google.com by zobo...@gmail.com on 15 Jan 2013 at 9:46

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Have you edited the wireshark trace? Because there is no server reflexive 
candidate i the 200 OK from webrtc2sip to chrome.

Original comment by boss...@yahoo.fr on 16 Jan 2013 at 12:08

[GoogleCodeExporter]

The webrtc2sip is not supposed to have reflexive candidates, since it is not 
behind a NAT. More precisely, the webrtc2sip and Chrome are on a same private 
network without access to internet.

Original comment by zobo...@gmail.com on 16 Jan 2013 at 9:32

[GoogleCodeExporter]

New network trace

Original comment by zobo...@gmail.com on 16 Jan 2013 at 10:50

Attachments:

• trace2.pcap

[GoogleCodeExporter]

Very strange because you said that it was working with the previous version. 
Looks at the code source it looks like the only conditions to stop gathering 
reflexive candidates are "network error" or "timeout". In the current state, 
you should always receive "timeout" error if you don't have access to internet.
As this issue is not related to chrome, I've opened ticket 197 on Doubango 
(http://code.google.com/p/doubango/issues/detail?id=197)

Original comment by boss...@yahoo.fr on 16 Jan 2013 at 11:18

• Changed state: Accepted

[GoogleCodeExporter]

Some news about that issue :

I have deactivated STUN server on the browser side (i.e. in the SIPML5), and 
changed the STUN server IP on the webrtc2sip side to set a reachable (thus 
internal) STUN server.
 -> Result : the issue is solved

Note that using the reachable STUN server on the browser side generates still 
an issue leading to a "SetRemoteDescription Failed" on the browser side. This 
SetRemoteDescription failure occurs after the SIPML5 tries to initiate a second 
offer/answer exchange.

Original comment by zobo...@gmail.com on 21 Feb 2013 at 12:40

[GoogleCodeExporter]

you should try latest code, some ICE issues have been fixed

Original comment by boss...@yahoo.fr on 27 Feb 2013 at 7:44

[GoogleCodeExporter]

I tried to install stund (from http://sourceforge.net/projects/stun/) locally 
and use it with webrtc2sip but I get this error messages bellow from stun 
server console. Stéphane, could you tell me which stun server did you use on 
your local network to make it work?
Thanks,
Minh

-------------------------
Received stun message: 104 bytes
Bad length strign 9
problem  parsing Username
Request did not parse
Failed to parse message

Original comment by quang-mi...@wengo.com on 12 Mar 2013 at 2:58

[GoogleCodeExporter]

Nevermind, I manage to make it work by using user name and password with the 
right length. STUND requires the lengh of username and password to be a 
divisible by 4

Original comment by quang-mi...@wengo.com on 12 Mar 2013 at 3:16