[Freeswitch-users] JAVA & WebRTC & JAIN SIP - no WebSockets

Fri Mar 13 13:24:54 MSK 2015

I tried to debug again and now I noticed that the audio flow actually goes
in both directions but still no video. I discovered in FreeSwitch log that
during successful video call from Chrome to Android all 4 fingerprints are
sha-256 and all of them are shown as "verified". But during unsuccessful
call from Android I get sha-1 (from Chrome still sha-256) and for some
reason FreeSwitch shows only 3 fingerprints verified. So I guess that
something is wrong with the video fingerprint verification from my Android
Application.

Logs are attached.

Thank you Michael!

On Thu, Mar 12, 2015 at 3:57 PM, Michael Jerris <mike at jerris.com> wrote:

> its not changing it back and forth to sha-256/sha-1 those are 2 different
> channels... the leg to android is always sha-1.  That being said, Nothing
> we have tested against uses sha-1.  That could be an issue.  You should
> look at the full debug log of the call between fs and android and see if
> there is anything useful there.
>
> On Mar 12, 2015, at 8:07 AM, Oleg Blinnikov <osblinnikov at gmail.com> wrote:
>
> Hi,
>
> Unfortunately not everything runs smoothly. I run FreeSWITCH Version
> 1.5.15b+git~20150203T210457Z~4174fb9cbe~64bit (git 4174fb9 2015-02-03
> 21:04:57Z 64bit) with the default configuration + webrtc module + tweaked
> bridge application for 1010 - 1019 extensions where I added
> ignore_early_media=true because of chrome troubles with pranswer and
> media_webrtc=true because one of my clients is actually JAIN SIP  without
> WebSockets.
>
> Now I call from Chrome to my Android app. In Android app I receive
> modified SDP from FreeSwitch and all the media traffic goes though
> FreeSwitch. I have the audio and video in both directions.
>
> But when I createOffer in the Android application and send it to Chrome
> the media is not flowing in any directions. In case I set "<action
> application="set" data="bypass_media=true"/>" media starts flowing.
>
> PS. May be it's irrelevant  but the only strange thing I noticed is that
> Android App produces fingerprint in sha-1 then FreeSwitch changes it to
> sha-256 and sends to Chrome. Chrome responds with sha-256 then FreeSwitch
> modifies it back to sha-1.
>
> I don't know, may be I forget about some other magic options?
>
> PS: SDPs are in the attachment
>
> On Fri, Mar 6, 2015 at 4:43 PM, Michael Jerris <mike at jerris.com> wrote:
>
>> Always nice to hear that we are magic!
>>
>> On Mar 6, 2015, at 5:05 AM, Oleg Blinnikov <osblinnikov at gmail.com> wrote:
>>
>> thank you very much Michael, it magically works.
>>
>> On Thu, Mar 5, 2015 at 6:51 PM, Michael Jerris <mike at jerris.com> wrote:
>>
>>> you need to tell freeswitch to send a webrtc compatible SDP.
>>>
>>> https://wiki.freeswitch.org/wiki/Variable_media_webrtc
>>>
>>>
>>> On Mar 5, 2015, at 3:51 AM, Oleg Blinnikov <osblinnikov at gmail.com>
>>> wrote:
>>>
>>> Hi,
>>>
>>> I've made a simple Android Java application utilizing JAIN SIP,
>>> webrtc.org android library and connected to FreeSwitch via UDP.
>>>
>>> But when I send SDP from SIP/Chrome/Firefox phone to my JAIN SIP client
>>> this SDP is not managed well by FreeSwitch for establishment WebRTC
>>> PeerConnection.
>>>
>>> When I call `peerConnection.setRemoteDescription(new SDPObserver(),
>>> sdp);` in my Android Application with the SDP from FreeSwitch I get:
>>>
>>> "onSetFailure Failed to set remote offer sdp: Called with SDP without
>>> DTLS fingerprint."
>>>
>>> At the same time the calls between Chrome/Firefox(
>>> http://tryit.jssip.net/) and SIP-phone (e.g. linphone) greatly managed
>>> by FreeSwitch and I have pure audio flow.
>>>
>>> Here is initial SDP from Chrome (http://tryit.jssip.net/):
>>>
>>> v=0
>>> o=- 6887715720880489867 2 IN IP4 127.0.0.1
>>> s=-
>>> t=0 0
>>> a=group:BUNDLE audio video
>>> a=msid-semantic: WMS itEKr0vXP6lg3KNs4kVau9aL3uAfyWOlItfU
>>> m=audio 38359 RTP/SAVPF 111 103 104 0 8 106 105 13 126
>>> c=IN IP4 192.168.122.1
>>> a=rtcp:38359 IN IP4 192.168.122.1
>>> a=candidate:4062413514 1 udp 2122260223 192.168.122.1 38359 typ host
>>> generation 0
>>> .......
>>> a=candidate:3741779331 2 tcp 1518018303 172.17.42.1 0 typ host tcptype
>>> active generation 0
>>> a=ice-ufrag:bwrCv9yS8rCY12Az
>>> a=ice-pwd:3k35jpG/i+TCbvBcJPWrw2eP
>>> a=ice-options:google-ice
>>> a=*fingerprint*:sha-256
>>> 52:8C:0F:27:C6:D6:CF:AE:F4:87:AC:AE:DF:7B:9B:B2:75:90:60:6A:2A:82:09:98:AD:04:0B:35:45:6A:13:A2
>>> a=setup:actpass
>>> a=mid:audio
>>> a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
>>> a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
>>> a=sendrecv
>>> a=rtcp-mux
>>> a=rtpmap:111 opus/48000/2
>>> a=fmtp:111 minptime=10
>>> a=rtpmap:103 ISAC/16000
>>> a=rtpmap:104 ISAC/32000
>>> a=rtpmap:0 PCMU/8000
>>> a=rtpmap:8 PCMA/8000
>>> a=rtpmap:106 CN/32000
>>> a=rtpmap:105 CN/16000
>>> a=rtpmap:13 CN/8000
>>> a=rtpmap:126 telephone-event/8000
>>> a=maxptime:60
>>> a=ssrc:1291334905 cname:ALccmKLk9bGpSGWB
>>> a=ssrc:1291334905 msid:itEKr0vXP6lg3KNs4kVau9aL3uAfyWOlItfU
>>> 4e8f212e-746a-47bb-bc62-4a42d4e9e84e
>>> a=ssrc:1291334905 mslabel:itEKr0vXP6lg3KNs4kVau9aL3uAfyWOlItfU
>>> a=ssrc:1291334905 label:4e8f212e-746a-47bb-bc62-4a42d4e9e84e
>>> m=video 38359 RTP/SAVPF 100 116 117 96
>>> c=IN IP4 192.168.122.1
>>> a=rtcp:38359 IN IP4 192.168.122.1
>>> a=candidate:4062413514 1 udp 2122260223 192.168.122.1 38359 typ host
>>> generation 0
>>> ............
>>> a=candidate:3741779331 2 tcp 1518018303 172.17.42.1 0 typ host tcptype
>>> active generation 0
>>> a=ice-ufrag:bwrCv9yS8rCY12Az
>>> a=ice-pwd:3k35jpG/i+TCbvBcJPWrw2eP
>>> a=ice-options:google-ice
>>> a=*fingerprint*:sha-256
>>> 52:8C:0F:27:C6:D6:CF:AE:F4:87:AC:AE:DF:7B:9B:B2:75:90:60:6A:2A:82:09:98:AD:04:0B:35:45:6A:13:A2
>>> a=setup:actpass
>>> a=mid:video
>>> a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
>>> a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
>>> a=recvonly
>>> a=rtcp-mux
>>> a=rtpmap:100 VP8/90000
>>> a=rtcp-fb:100 ccm fir
>>> a=rtcp-fb:100 nack
>>> a=rtcp-fb:100 nack pli
>>> a=rtcp-fb:100 goog-remb
>>> a=rtpmap:116 red/90000
>>> a=rtpmap:117 ulpfec/90000
>>> a=rtpmap:96 rtx/90000
>>> a=fmtp:96 apt=100
>>>
>>>
>>> Here is SDP received from FreeSwitch in JAIN SIP via UDP:
>>>
>>> v=0
>>> o=FreeSWITCH 1425524563 1425524564 IN IP4 192.168.131.253
>>> s=FreeSWITCH
>>> c=IN IP4 192.168.131.253
>>> t=0 0
>>> m=audio 16390 RTP/AVP 111 0 8 101 13
>>> a=rtpmap:111 opus/48000/2
>>> a=fmtp:111 minptime=10
>>> a=rtpmap:0 PCMU/8000
>>> a=rtpmap:8 PCMA/8000
>>> a=rtpmap:101 telephone-event/8000
>>> a=fmtp:101 0-16
>>> a=ptime:20
>>> m=video 16388 RTP/AVP 100
>>> a=rtpmap:100 VP8/90000
>>>
>>>
>>> I suppose that FreeSwitch wants to see WebRTC connection only on the
>>> WebSocket ports and it doesn't know that my UDP client is actually WebRTC
>>> client.
>>>
>>> So I'm wondering if it possible to connect SIP client to the WebSocket
>>> port via TCP using standard SIP client and never upgrade connection to
>>> WebSocket?
>>>
>>>
>>
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://confluence.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>

-- 
Sincerely,
Oleg Blinnikov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20150313/266bbc72/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fail
Type: application/octet-stream
Size: 98240 bytes
Desc: not available
Url : http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20150313/266bbc72/attachment-0002.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: success
Type: application/octet-stream
Size: 103599 bytes
Desc: not available
Url : http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20150313/266bbc72/attachment-0003.obj 