WebRTC inbound via Kamailio media relay causing ICE fail

[jon.pete...@gmail.com]

I am using JsSIP on Firefox 38 and making calls via Kamailio SIP proxy and media relay. With an inbound call (offer to WebRTC) coming via Kamailio, I see ICE fail in browser console (JsSIP defaults to terminate the call if it sees iceconnetionstate === 'fail' in oniceconnectionstatechange event).

Kamailio modifies the candidate lines in SDP offer, inserting its IP/port, and they appear to Firefox end like this:

a=candidate:iwIBAJAL55e3Lvye 2 UDP 2130706430 <Kamilio IP> <Kamailio port> typ host

Kamailio also adds this: a=ice-lite. I believe this means it will simply respond to STUN requests, but not much more. I see that, on browser side, ICE checks between its local ip to the Kamailio ip fail, but it succeeds between server reflexive IP and Kamailio IP. So there is always 2 fails and 2 successes (for audio and video).

If ICE partially succeeded, why does it seem to fail completely?

[Byron Campen]

Can you check about:webrtc and send me the connection log, the
table of ICE stats, and the SDP?

Best regards,
Byron Campen

> _______________________________________________
> dev-media mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-media

[jon.pete...@gmail.com]

Sorry for the delayed response. This seems to no longer be a problem for me (I am now using 38.0.5 for info). In the about:webrtc I would see something like this in the 'Ice Stats' tab:

<local-ip:port>/udp(host) <kamailio-ip:port>/udp(host) failed
<local-ip:port>/udp(host) <kamailio-ip:port>/udp(host) failed
<local-ip:port>/udp(peerreflexive) <kamailio-ip:port>/udp(host) succeeded
<local-ip:port>/udp(peerreflexive) <kamailio-ip:port>/udp(host) succeeded

(the two succeeded ones were nominated and selected)

A typical local candidate in the local SDP (just showing one of the two):
a=candidate:0 1 UDP 2128609535 <local-ip> <local-port> typ host

A typical remote candidate in remote SDP:
a=candidate:iwIBAJAL55e3Lvye 1 UDP 2130706431 <kamailio-ip> <kamailio-port> typ host

[andrey.kri...@gmail.com]

пятница, 22 мая 2015 г., 19:49:22 UTC+3 пользователь Byron Campen написал:

> Can you check about:webrtc and send me the connection log, the
> table of ICE stats, and the SDP?
>
> Best regards,
> Byron Campen

Dear Byron,
sorry to hijack the thread, but could you please help us with calls through Kamailio+Rtpengine SIP backend? We have hard time adopting latest Firefox (39.0 and 42.0a1 tested). Chrome and Linphone works just fine. FF with JsSIP also answers the call successfully, then there's no media exchange. I see that no RTP packets are sent to/from any interface from Firefox instances. Currently I don't know why exactly.
I am ready to provide all debug info, and also test accounts on our non-production SIP server.
Please email me to andrey.kri...@gmail.com . I will pay for prompt help, I just need this to be resolved as quickly as possible.
Thanks in advance.

[Randell Jesup]

On 7/29/2015 5:50 PM, andrey.kri...@gmail.com wrote:
> пятница, 22 мая 2015 г., 19:49:22 UTC+3 пользователь Byron Campen написал:

>> Can you check about:webrtc and send me the connection log, the
>> table of ICE stats, and the SDP?

>> sorry to hijack the thread, but could you please help us with calls through Kamailio+Rtpengine SIP backend? We have hard time adopting latest Firefox (39.0 and 42.0a1 tested). Chrome and Linphone works just fine. FF with JsSIP also answers the call successfully, then there's no media exchange. I see that no RTP packets are sent to/from any interface from Firefox instances. Currently I don't know why exactly.

File a bug in bugzilla in product Core, component WebRTC, and attach the
data from 42.0a1 from about:webrtc (use Save Page) while in a call. You
could also set NSPR_LOG_MODULES=signaling:4,timestamp and set
NSPR_LOG_FILE=whatever and then run firefox and try a call to generate a
logfile.

--
Randell Jesup

[msalm...@gmail.com]

Hi guys,

Is there an update on the above mentioned issue:

"calls through Kamailio+Rtpengine SIP backend? We have hard time adopting latest Firefox (39.0 and 42.0a1 tested). Chrome and Linphone works just fine. FF with JsSIP also answers the call successfully, then there's no media exchange. I see that no RTP packets are sent to/from any interface from Firefox instances. Currently I don't know why exactly."

Would you guys refer me to the bug logger for this specific issues so that we can check for updates. Looks like everybody is facing this issue.

Also which version of Mozilla is fully working for kamailio+rtpproxy+JSSIP ? in your opinion.

Looking forward to your valuable reply. Thanks

[Randell Jesup]

On 8/9/2015 4:28 AM, msalm...@gmail.com wrote:
> On Thursday, 30 July 2015 10:12:52 UTC+5, Randell Jesup wrote:

> Hi guys,
>
> Is there an update on the above mentioned issue:
>

> "calls through Kamailio+Rtpengine SIP backend? We have hard time adopting latest Firefox (39.0 and 42.0a1 tested). Chrome and Linphone works just fine. FF with JsSIP also answers the call successfully, then there's no media exchange. I see that no RTP packets are sent to/from any interface from Firefox instances. Currently I don't know why exactly."
>

> Would you guys refer me to the bug logger for this specific issues so that we can check for updates. Looks like everybody is facing this issue.

So far as I can see you did not file a bug about this, nor provide the
logs requested. Without those, this is unlikely to get any attention -
we don't even know what the issue is - and by far the most likely cause
is a bug in the framework you're using - or failing to update the framework.

That's the problem with frameworks - when something breaks, you have no
idea what broke or why often. And nothing synchronizes framework
releases with browser changes; usually the site author has to
copy/cut-and-paste code from the framework -- if they remember, and pay
attention to updates.

> Also which version of Mozilla is fully working for kamailio+rtpproxy+JSSIP ? in your opinion.

We don't generally test frameworks, and no one has reported Kamailio
failing. There's a report (bug 1163893) about it having issues with
H.264 for someone. That's it.

--
Randell Jesup, Mozilla