[jitsi-dev] testing Jitsi with JSCommunicator/JsSIP


#1

I did some testing of Jitsi and JSCommunicator through a SIP proxy

I see that Jitsi has some of the ingredients for this (e.g. it doesn't
reboot the machine when it sees RTP/SAVPF in the SDP, some other UAs
really do respond that badly however) but it is not complete yet either.

Can anybody comment on the plans for supporting this from Jitsi? Once
it is ready I would like to publish some sample config and screenshots,
this will be really useful for people trying the new debian.org SIP service.

I can provide a sample JSCommunicator/JsSIP config that you can access
through the web to test if necessary, you can just as easily wget the
sample and run it locally if you prefer


#2

Hey Daniel,

OK, just saw this one. So responding here as well:

I did some testing of Jitsi and JSCommunicator through a SIP proxy

I see that Jitsi has some of the ingredients for this (e.g. it doesn't
reboot the machine when it sees RTP/SAVPF in the SDP, some other UAs
really do respond that badly however) but it is not complete yet either.

Can anybody comment on the plans for supporting this from Jitsi?

Jitsi has all the ingredients (SRTP, AVPF, SDES and DTL/SRTP) except for ICE *for SIP*. This will come shortly. We already have ICE for XMPP but we need to also plug it into SIP.

Once
it is ready I would like to publish some sample config and screenshots,
this will be really useful for people trying the new debian.org SIP service.

I can provide a sample JSCommunicator/JsSIP config that you can access
through the web to test if necessary, you can just as easily wget the
sample and run it locally if you prefer

Thanks, we'll keep that in mind for when we start tinkering with it.

Cheers,
Emil

···

On 15.01.14, 10:04, Daniel Pocock wrote:

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
https://jitsi.org


#3

As mentioned in the other email, I don't believe the ICE support is
actually a critical requirement in every case, the WebRTC user will have
a relay IP and Jitsi would talk to that by default if it
doesn't recognise the ICE candidates (and if the WebRTC is well behaved
when talking to a non-ICE peer)

ICE in Jitsi is only essential for Jitsi to Jitsi calls across NAT
boundaries

Maybe I'm wrong though and the reason the JsSIP says

"SetRemoteDescription failed: Failed to update session state: ERROR_CONTENT"

may be a sign that it does reject legacy SDP

···

On 15/01/14 19:26, Emil Ivov wrote:

Hey Daniel,

OK, just saw this one. So responding here as well:

On 15.01.14, 10:04, Daniel Pocock wrote:

I did some testing of Jitsi and JSCommunicator through a SIP proxy

I see that Jitsi has some of the ingredients for this (e.g. it doesn't
reboot the machine when it sees RTP/SAVPF in the SDP, some other UAs
really do respond that badly however) but it is not complete yet either.

Can anybody comment on the plans for supporting this from Jitsi?

Jitsi has all the ingredients (SRTP, AVPF, SDES and DTL/SRTP) except for
ICE *for SIP*. This will come shortly. We already have ICE for XMPP but
we need to also plug it into SIP.


#4

Hey Daniel,

OK, just saw this one. So responding here as well:

I did some testing of Jitsi and JSCommunicator through a SIP proxy

I see that Jitsi has some of the ingredients for this (e.g. it doesn't
reboot the machine when it sees RTP/SAVPF in the SDP, some other UAs
really do respond that badly however) but it is not complete yet either.

Can anybody comment on the plans for supporting this from Jitsi?

Jitsi has all the ingredients (SRTP, AVPF, SDES and DTL/SRTP) except for
ICE *for SIP*. This will come shortly. We already have ICE for XMPP but
we need to also plug it into SIP.

As mentioned in the other email, I don't believe the ICE support is
actually a critical requirement in every case,

As explained: it is.

the WebRTC user will have
a relay IP and Jitsi would talk to that by default if it
doesn't recognise the ICE candidates (and if the WebRTC is well behaved
when talking to a non-ICE peer)

Nope.

ICE in Jitsi is only essential for Jitsi to Jitsi calls across NAT
boundaries

Maybe I'm wrong though and the reason the JsSIP says

"SetRemoteDescription failed: Failed to update session state: ERROR_CONTENT"

may be a sign that it does reject legacy SDP

Obviously there could always be other issues as well :slight_smile:

From a code perspective though, ICE with SIP is our only missing component. WebRTC to XMPP is already tested and working.

Emil

···

On 15.01.14, 19:56, Daniel Pocock wrote:

On 15/01/14 19:26, Emil Ivov wrote:

On 15.01.14, 10:04, Daniel Pocock wrote:

--
https://jitsi.org


#5

If you send me (off-list?) the dump from chrome://webrtc-internals and (possibly) the output of chromium --enable-logging --v=4 I can take a look. I've seen that error often enough.

···

Am 15.01.2014 19:56, schrieb Daniel Pocock:

Maybe I'm wrong though and the reason the JsSIP says

"SetRemoteDescription failed: Failed to update session state: ERROR_CONTENT"

may be a sign that it does reject legacy SDP


#6

Hi,

> Hey Daniel,
>
> OK, just saw this one. So responding here as well:
>
>>
>> I did some testing of Jitsi and JSCommunicator through a SIP proxy
>>
>> I see that Jitsi has some of the ingredients for this (e.g. it doesn't
>> reboot the machine when it sees RTP/SAVPF in the SDP, some other UAs
>> really do respond that badly however) but it is not complete yet either.
>>
>> Can anybody comment on the plans for supporting this from Jitsi?
>
> Jitsi has all the ingredients (SRTP, AVPF, SDES and DTL/SRTP) except for
> ICE *for SIP*. This will come shortly. We already have ICE for XMPP but
> we need to also plug it into SIP.

As mentioned in the other email, I don't believe the ICE support is
actually a critical requirement in every case, the WebRTC user will have
a relay IP and Jitsi would talk to that by default if it
doesn't recognise the ICE candidates (and if the WebRTC is well behaved
when talking to a non-ICE peer)

ICE in Jitsi is only essential for Jitsi to Jitsi calls across NAT
boundaries

Maybe I'm wrong though and the reason the JsSIP says

"SetRemoteDescription failed: Failed to update session state:
ERROR_CONTENT"

JsSIP does not mangle the incoming SDP which means that it is rejected by
RTCPeerConnection itself. Not too much to do here.

may be a sign that it does reject legacy SDP

Correct, it rejects legacy SDP.

···

2014/1/15 Daniel Pocock <daniel@pocock.com.au>

On 15/01/14 19:26, Emil Ivov wrote:
> On 15.01.14, 10:04, Daniel Pocock wrote:

--
You received this message because you are subscribed to the Google Groups
"JsSIP" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to jssip+unsubscribe@googlegroups.com.
To post to this group, send email to jssip@googlegroups.com.
Visit this group at http://groups.google.com/group/jssip.
For more options, visit https://groups.google.com/groups/opt_out.

--
José Luis Millán