Web browser / Android ICE connection failure?

[Kyle Cummings]

I am working on developing an application for Android devices that allows voice / video calling to other WebRTC enabled devices connected to an XMPP server. I have already been successful in getting the application to voice / video chat between Android devices, and now I am working on extending that capability to WebRTC enabled browsers. I have successfully had browser to browser voice / video calling, however that system works on the SDP protocol, and the Android application I have built works on the Jingle / XMPP protocol. I know that I can rewrite the application to work on the SDP protocol, as that has been done before. However, I would like to maintain the Jingle protocol with the Android devices, as the application I have built has developed many features / capabilities that are heavily dependent on the Jingle based code within LibJingle.

Building off of SDP / Jingle translators that have already been done (the Phono library specifically) I currently have a browser client and an Android device negotiating the media aspects of the voice / video call successfully. However, things seem to be failing while one side tries to connect to the other. Part of me believes that the failure lies with the ICE / JINGLE translations. I have noticed that the ice candidates passed to the browser, via "onicecandidate", do not contain any username and password information. I have tried copying the username and password information in the original SDP offer, generated by the browser client, into each of the appropriate ice candidates (voice vs. video), but that has not yielded any success. I have also tried just not including any username and password information in the transport stanza, but that too yielded nothing.

I ran wireshark on the browser side during the entire bit of communications, and I continued to see binding errors between the browser and the Android device until the Android device finally sent a "session-terminate" signal. Specifically, I am seeing the following:

STUN 158 Binding Request user: r8bGP7y5LklOOKEb:IjgBbKgXQe9V8Pur

STUN 130 Binding Error Response error-code: 274 (*Unknown error code*) Stale Credentials user: r8bGP7y5LklOOKEb:IjgBbKgXQe9V8Pur

Eventually the error response stops showing up, and then messages like the following start showing up:

ICMP 186 Destination unreachable (Port unreachable)

I am still quite new to the ICE / transport part of the negotiations, so I am not sure if any of the wireshark logs were relevant, or if I am even diagnosing the problem correctly.

Does anyone know what I might be doing wrong? Or have any experience getting the connection between an SDP based client and a Jingle based client working?

[Kyle Cummings]

Just to clarify the ICE translations that I am doing.

The SDP side of the candidate is:

a=candidate:[foundation] [component-id] [transport type] [priority] [connection address] [port] [candidate type] [username] [password] [generation]

The Jingle side of the candidate is:

<candidate component="[comp]" name="[name]" address="[ip]" port="[port]" protocol="[proto]" username="[uname]" password="[pass]" preference="[pref]" generation="[gen]"/>

While going from Jingle to SDP, I use the following mapping:

foundation = randomly generated number

component-id = comp

transport type = udp

priority = pref * 10000

connection address = ip

port = port

candidate type = typ host

username = uname

password = pass

sdpMLineIndex = 0 if audio, 1 if video

sdpMid = audio / video 

When going from SDP to Jingle, I use the following mapping:

comp = component-id

name = event.candidate.sdpMid (with the adjustment of rtp and rtcp based on the component value)

ip = connection address

port = port

proto = transport type

uname = varies from being empty to being the respective one generated in the original SDP media information

pass = varies from being empty to being the respective one generated in the original SDP media information

pref = 0.99

gen = 0

[Philipp Hancke]

Does set SDP you give to setLocalDescription contain ice-ufrag and ice-pwd lines?

--
 
---
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.
 
 

[Kyle Cummings]

Yes it does. I've tried saving those to "globals" and then adding them into the transport stanzas, with no result.

[Kyle Cummings]

I have been doing a bit more work, and now I am getting the following error stanza back from the Android device:

<iq to="us...@domain.com/resa" id="61458" type="error" from="us...@domain.com/resd">

<jingle xmlns="urn:xmpp:jingle:1" action="transport-info" sid="3626752471">

<content name="video" creator="initiator">

<transport xmlns="http://www.google.com/transport/p2p">

<candidate name="video_rtcp" component="2" address="xxx.xxx.xxx.xxx" port="41284" preference="0.99" username="p6mcGRxYKXv+KcHV" protocol="udp" generation="0" password="C1XLylgu9nkt+btiCbe/Dx8Y" type="stun" network="wlan0"/>

</transport>

</content>

</jingle>

<error type="modify">

<sta:bad-request xmlns:sta="urn:ietf:params:xml:ns:xmpp-stanzas">

</sta:bad-request>

<sta:text xmlns:sta="urn:ietf:params:xml:ns:xmpp-stanzas" xml:lang="en">Candidate has unknown component: Cand[:0:stun:udp:wlan0:65.101.207.121:41284:p6mcGRxYKXv+KcHV:C1XLylgu9nkt+btiCbe/Dx8Y] for content: video

</sta:text>

</error>

</iq> 

In response to the following transport stanza being sent out by the browser:

<iq type="set" id="61458" to="us...@domain.com/resd" from="us...@domain.com/resa">

<jingle xmlns="urn:xmpp:jingle:1" action="transport-info" sid="3626752471">

<content name="video" creator="initiator">

<transport xmlns="http://www.google.com/transport/p2p">

<candidate name="video_rtcp" component="2" address="xxx.xxx.xxx.xxx" port="41284" preference="0.99" username="p6mcGRxYKXv+KcHV" protocol="udp" generation="0" password="C1XLylgu9nkt+btiCbe/Dx8Y" type="stun" network="wlan0"/>

</transport>

</content>

</jingle>

</iq>

It appears that there is either something I am missing, or something is not entered correctly, and thus is not being parsed out of the stanza.

I am pretty sure that the modifications that I have made since the start of this thread have not done / will not do anything to fix the original problem, but I obviously cannot test that with this new error. So, if anyone knows how to fix the original, or this new error, please let me know.

Thanks.

[Kyle Cummings]

For those interested, the candidate lines that I am receiving from Chromium are:

a=candidate:3376904655 2 udp 2113937151 192.168.1.144 46794 typ host generation 0

a=candidate:1208975227 1 udp 1845501695 xxx.xxx.xxx.xxx 46794 typ srflx raddr 192.168.1.144 rport 46794 generation 0

[Sebastian Kummer]

Hi there,

I also did a SDP-over-XMPP conversation in my Android app and finally got it interoperable to Chrome. However, this is not very straightforward and the Jingle-extensions of XMPP Libraries may still be outdated or incomplete.

There are severeal pitfalls:

- Bugs may occur in the SDP-to-XMPP-Conversation, the XMPP en- or decoding or the logical control flow.

- Always compare the original SDP created by the PeerConnection Library on side-A to the fully converted and transmitted SDP on side-B before you pass it to the PeerConnection. That way you will unveil potential errors in your XMPP layer too

- An unsuccessfull session establishment is not necessarily caused by invalid candidates. Wrong values in the Session-Description (session-initiate / session-accept) are critical too (e.g. do they also contain the correct ICE user/password?)

In your XMPP Candidate I see: 

- preference="0.99" but the "priority" attribute in the candidate SDP is an integer (at worst, transmit 0 (zero) and the peerconntion on the other side will do their best)

- type="stun" but this is not a valid "typ" attribute for a candidate SDP (should be host or srflx or relay)

[Justin Uberti]

Yes. The current version of libjingle doesn't currently handle a XEP-0176-compliant version of ICE signaling. It is currently a TODO in p2ptransport.cc...

Glad you were able to get things working.

[Anoop Vijayan]

I am currently working on Android P2P streaming from IPcamera using XMPP Jingle Standard.For this i have tried different libraries like WebRTC,Jingle Bells etc.My aim is to stream IPCamera to Android Device.Can any one tell me a right way to achieve this?Any libraries to support this?Any sample Application code  is available?

[sabo...@qagate.com]

i am trying to establish p2p streaming between ipcamera and android device. i am getting a response from camera .

<candidate xmlns='urn:xmpp:jingle:transports:ice-udp:1' port='52418' component='1' network='1' ip='220.227.167.61' priority='1677721855' type='srflx' foundation='3' protocol='udp'/></transport></content></jingle></iq>

From this response how can i retrieve separate stanza .