No audio from Android libjingle WebRTC demo to Chrome WebRTC

[James Mortensen]

We're working on doing some tests on our local network to make calls from the Android libjingle WebRTC demo to Chrome WebRTC.  We're able to successfully connect the call, but no audio is sent to either endpoint.

We're using JsSIP to handle the SIP messaging on Chrome, and the SIP/SDP messages look okay as far as I can tell.  These two logs span the call from initiation from Android as user 1004 to Chrome user 1000.  After two minutes, I explicitly hangup the call from Chrome.

I've attached  the Chrome console logs, as well as the logs from the chrome_debug from starting up Chrome with verbose logging enabled. If there is more information that you need, please let me know. I'm happy to help!

James

[James Mortensen]

After looking at the chrome_debug log further and comparing a Chrome to Chrome call to the Android to Chrome logs, it looks like the Android to Chrome call was trying to use TCP for the audio instead of UDP.

I'm not an expert on these logs and may be mistaken, but I hope this helps!

James

[Ami Fischman]

James,

Your email talks about "the Android libjingle WebRTC demo", which I assume is AppRTCDemo from talk/examples/android.  AppRTCDemo is very specific to the apprtc.appspot.com demo; in particular it uses SDP over AppEngine Channels for signaling.

Given this, I'm confused as to where SIP (or JsSIP) comes into play in your setup.

Is the chrome in your setup _not_ loading apprtc.appspot.com?

Can you share more details about what HTML/JS chrome is loading in your setup?

Cheers,

-a

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

[Shaun]

We use jssip to handle the messaging to our gateway and then dump the sdps off after the negotiation is done. The end result in this case is just a peer to peer call. We started with the demo code just to get us going, but have since modified it to work with our messaging platform. In this situation the endpoints both get the correct sdps and the peer connections on both sides accept them but no audio flows.

On one side of this you have our packaged app and the other the android peerconnection.

[Ami Fischman]

On Thu, May 23, 2013 at 11:27 AM, Shaun <shaun...@a-cti.com> wrote:

We use jssip to handle the messaging to our gateway and then dump the sdps off after the negotiation is done. The end result in this case is just a peer to peer call. We started with the demo code just to get us going, but have since modified it to work with our messaging platform. In this situation the endpoints both get the correct sdps and the peer connections on both sides accept them but no audio flows.

FWIW, "peer connections on both sides accept [the SDPs]" does not imply that things are correct :)  

An easy way to repro this even in vanilla apprtc is to not be using TURN in a network configuration where TURN is necessary.  Each side will set the offer/answer SDP successfully, but one or both sides will fail to contact the other b/c the ICE candidates gathered locally and/or with STUN are insufficient (because one or both of the peers can't see the other).

The resulting symptom is that apprtc thinks the call is connected but media data does not flow.

Without knowing more about your network layout and the details of your modifications I can't offer more help, but hopefully the above gives you something to work with.

Cheers,

-a

[Shaun]

So the network here is Chrome on one side in our LAN and Android, also on our LAN. We use SIP to allow both sides to exchange SDPs to setup a peer-to-peer connection. TURN is not being used. Each peer should be able to see each other just fine since they exist on the same network.

[James Mortensen]

The problem is not that the peers can't see each other but that no audio flows, period.  There is no turn server, and there is no RTP flowing in our tcpdumps.

The Sdp makes it to the other side and is processed just fine.  If the SDP had a problem I would think we would see one endpoint trying to send audio packets to a bad port.

Hope this helps clarify what we are doing.

James

--
 
---
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/GmTnbU3NbR4/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to discuss-webrt...@googlegroups.com.

[Justin Uberti]

Does ICE connect? Can you attach a dump from webrtc-internals?

--
 
---

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.