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

Fri Mar 13 17:37:44 MSK 2015

To be completely honest, I don't think anyone is going to look at this issue.  We try hard to make sure we work with the browsers, but have made no effort to work on interop with other devices, particularly ones that deviate behaviors with the browsers.  If you can figure it out we'd be happy to review any patches.  Might try talking to the JAIN guys and see why they are using sha-1 ?

Mike

> On Mar 13, 2015, at 6:24 AM, Oleg Blinnikov <osblinnikov at gmail.com> wrote:
> 
> 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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto:mike at jerris.com>> wrote:
>>> you need to tell freeswitch to send a webrtc compatible SDP.
>>> 
>>> https://wiki.freeswitch.org/wiki/Variable_media_webrtc <https://wiki.freeswitch.org/wiki/Variable_media_webrtc>
>>> 
>>> 
>>>> On Mar 5, 2015, at 3:51 AM, Oleg Blinnikov <osblinnikov at gmail.com <mailto:osblinnikov at gmail.com>> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> I've made a simple Android Java application utilizing JAIN SIP, webrtc.org <http://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/ <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/ <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 <tel:4062413514> 1 udp 2122260223 <tel: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 <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 <tel:4062413514> 1 udp 2122260223 <tel: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 <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?
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20150313/38b166e2/attachment.html 