[jitsi-dev] sipml5 (WebRTC client) with Jitsi


#1

I'm trying to call from sipml5 to Jitsi

I have the latest version of each, Jitsi is a fresh install,
jitsi-1.1.4476.jar

Jitsi rings, but when I answer, it refuses the call with the error
below. I've also copied the INVITE further below

(in comparison, I have a Polycom handset that reboots itself on
receiving the INVITE from the webrtc client)

23:45:42.866 SEVERE: impl.protocol.sip.CallPeerSipImpl.answer().1327
Failed to create an SDP description for an OK response to an INVITE request!
net.java.sip.communicator.service.protocol.OperationFailedException:
Offer contained no valid media descriptions.
  at
net.java.sip.communicator.impl.protocol.sip.CallPeerMediaHandlerSipImpl.createMediaDescriptionsForAnswer(CallPeerMediaHandlerSipImpl.java:639)
  at
net.java.sip.communicator.impl.protocol.sip.CallPeerMediaHandlerSipImpl.processFirstOffer(CallPeerMediaHandlerSipImpl.java:341)
  at
net.java.sip.communicator.impl.protocol.sip.CallPeerMediaHandlerSipImpl.processOffer(CallPeerMediaHandlerSipImpl.java:314)
  at
net.java.sip.communicator.impl.protocol.sip.CallPeerSipImpl.answer(CallPeerSipImpl.java:1313)
  at
net.java.sip.communicator.impl.protocol.sip.OperationSetBasicTelephonySipImpl.answerCallPeer(OperationSetBasicTelephonySipImpl.java:1812)
  at
net.java.sip.communicator.impl.gui.main.call.CallManager$AnswerCallThread.run(CallManager.java:2012)

INVITE sip:1004@192.168.1.124:50417;transport=tls SIP/2.0
Via: SIP/2.0/TLS
192.168.1.2:5061;branch=z9hG4bK-524287-1---98996e3a6022990d;rport
Via: SIP/2.0/TCP
192.168.1.114:51523;branch=z9hG4bKHX0A65ARCtLsQ1XQKAzAU7IvRuydwnTV;rport=51523;received=192.168.1.114
Max-Forwards: 69
Record-Route:
<sip:KQAAAAIAAAAQAeWcwKgBfDE1YTZmZTY1NThkMGRjYzkwYjllMTlkMTkyMDM5ZTMx@srv1.office.readytechnology.co.uk;transport=tls;lr;drr>
Record-Route: <sip:192.168.1.2:5062;transport=ws;lr;drr>
Contact:
<sip:1005@192.168.1.2:5061;transport=tls;ws-src-ip=192.168.1.114;ws-src-port=51523;rtcweb-breaker=no>;language="en,fr";+g.oma.sip-im;+sip.ice

From: <sip:1005@srv1.office.readytechnology.co.uk>;tag=7ON5gByNVoJWrFD94GZw

Call-ID: 104a99ed-fd36-4f22-0f3c-5552d419dbde
CSeq: 61935 INVITE
Content-Type: application/sdp
Organization: Doubango Telecom
User-Agent: IM-client/OMA1.0 sipML5-v1.2013.02.13
Content-Length: 1617

v=0
o=- 3002941421 2 IN IP4 127.0.0.1
s=Doubango Telecom - chrome
t=0 0
a=group:BUNDLE audio
a=msid-semantic: WMS qh0sXeOMFjIIP2EkLfueSjXSjSqza4HCFJFR
m=audio 58216 RTP/SAVPF 103 104 111 0 8 107 106 105 13 126
c=IN IP4 213.x.y.z
a=rtcp:58216 IN IP4 213.144.156.34
a=candidate:27784895 1 udp 2113937151 192.168.1.114 58216 typ host
generation 0
a=candidate:27784895 2 udp 2113937151 192.168.1.114 58216 typ host
generation 0
a=candidate:2163208203 1 udp 1845501695 213..x.y.z 58216 typ srflx raddr
192.168.1.114 rport 58216 generation 0
a=candidate:2163208203 2 udp 1845501695 213.x.y.z 58216 typ srflx raddr
192.168.1.114 rport 58216 generation 0
a=candidate:1327761999 1 tcp 1509957375 192.168.1.114 52655 typ host
generation 0
a=candidate:1327761999 2 tcp 1509957375 192.168.1.114 52655 typ host
generation 0
a=ice-ufrag:8Rnzc0WYnIaNWBJg
a=ice-pwd:W3AJ4kJXEaWuuTLC/EC4pqe8
a=ice-options:google-ice
a=sendrecv
a=mid:audio
a=rtcp-mux
a=crypto:0 AES_CM_128_HMAC_SHA1_32
inline:5dI4ZdZIAGBBkwILexFm2VfcyfIwvyiOMh5Tlr7+
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:L78xfrqO3Uq1UlRNtiv4BNHpCjNWlhBT/J1gOjss
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:111 opus/48000/2
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:107 CN/48000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:126 telephone-event/8000
a=ssrc:1179996796 cname:XsAYZ4+TD6OfBvLh
a=ssrc:1179996796 msid:qh0sXeOMFjIIP2EkLfueSjXSjSqza4HCFJFR a0
a=ssrc:1179996796 mslabel:qh0sXeOMFjIIP2EkLfueSjXSjSqza4HCFJFR
a=ssrc:1179996796 label:qh0sXeOMFjIIP2EkLfueSjXSjSqza4HCFJFRa0

···

To: <sip:1004@srv1.office.readytechnology.co.uk>


#2

Hey Daniel

I'm trying to call from sipml5 to Jitsi

I have the latest version of each, Jitsi is a fresh install,
jitsi-1.1.4476.jar

Jitsi rings, but when I answer, it refuses the call with the error
below. I've also copied the INVITE further below

(in comparison, I have a Polycom handset that reboots itself on
receiving the INVITE from the webrtc client)

m=audio 58216 RTP/SAVPF 103 104 111 0 8 107 106 105 13 126

Jitsi doesn't know the media profile RTP/SAVPF, and neither AVPF. Personally
it's the first time I've seen these two. SAVPF is defined in RFC 4585, but
maybe Emil knows something more about it?

Regards,
Ingo


#3

Is this really why we are failing? I had a quick look at the code and it
seemed to me that a problem with the protocol would not produce this
exception, but I might be mising something.

Either way there's really no reason why we should be barfing when we see
SAVPF. We do use features from AVPF and I would suppose SAVPF is just
SDES on top of that.

Emil

···

On 16.02.13, 00:41, Ingo Bauersachs wrote:

Hey Daniel

I'm trying to call from sipml5 to Jitsi

I have the latest version of each, Jitsi is a fresh install,
jitsi-1.1.4476.jar

Jitsi rings, but when I answer, it refuses the call with the error
below. I've also copied the INVITE further below

(in comparison, I have a Polycom handset that reboots itself on
receiving the INVITE from the webrtc client)

m=audio 58216 RTP/SAVPF 103 104 111 0 8 107 106 105 13 126

Jitsi doesn't know the media profile RTP/SAVPF, and neither AVPF. Personally
it's the first time I've seen these two. SAVPF is defined in RFC 4585, but
maybe Emil knows something more about it?

--
https://jitsi.org


#4

Either way there's really no reason why we should be barfing when we see
SAVPF. We do use features from AVPF and I would suppose SAVPF is just
SDES on top of that.

I committed a small patch (r10455) to accept SAVPF the same way as SAVP, but
that doesn't make us any more aware of the F profile than before. I.e. we'll
never send an F-profile.

Daniel: sipml5 works with that. If you enables SDES and move it to the top
of the list, you'll get an encrypted call. However the icon is only green
when the server connection is using TLS.

Emil

Ingo


#5

I just did a fresh install of 2.0.4498 and observed the same problem.

I'm testing against DruCall, which is based on SIPml5

Also, I'd like to put together a howto guide on the DruCall site for
using DruCall + Jitsi against a single SIP proxy (repro or Kamailio),
would anybody be interested in collaborating on that? The DruCall
release has been reported quite widely and is getting a lot of attention:

http://www.webrtcworld.com/topics/from-the-experts/articles/328829-drucall-paradigm-expands.htm

···

On 16/02/13 13:10, Ingo Bauersachs wrote:

Either way there's really no reason why we should be barfing when we see
SAVPF. We do use features from AVPF and I would suppose SAVPF is just
SDES on top of that.
    

I committed a small patch (r10455) to accept SAVPF the same way as SAVP, but
that doesn't make us any more aware of the F profile than before. I.e. we'll
never send an F-profile.

Daniel: sipml5 works with that. If you enables SDES and move it to the top
of the list, you'll get an encrypted call. However the icon is only green
when the server connection is using TLS.