Chrome / Android Jingle-SDP ICE connection failure

Question

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 protocol. I know that I can rewrite the Android application to work on the SDP protocol, as that has been done before. However, I would like to continue using the Jingle protocol on 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

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

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?

To clarify what I am doing in the ICE translations.

SDP candidate:

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

Jingle candidate:

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

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

An example of the ICE candidates that I am getting in Chrome:

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

An example of the ICE candidates that I am getting from Jingle:

<candidate name="video_rtp" address="xxx.xxx.xxx.xxx" port="37275" preference="0.99" username="4XqIQDW4n9lJrIOM" protocol="udp" generation="0" password="F0Vc9tWo4S2/VhleJ/BdNOId" type="local" network="wlan0"/>
<candidate name="video_rtp" address="xxx.xxx.xxx.xxx" port="54429" preference="0.86" username="0ftgSUZ0qRFXlMh5" protocol="udp" generation="0" password="lIyHJZuZt8L/wIZnnqfQfRED" type="stun" network="wlan0"/>

Answer 1

So, as it turns out, LibJingle isn't yet equipped to work with SDP / ICE conversions. Specifically, LibJingle does not currently support the XEP-0176-compliant version of ICE signaling. So, the only recourse was to redo the system to an SDP based system.