[jitsi-dev] RFC3550 for Jitsi Android


#1

Does the Jitsi Android Client have RFC3550 (RTP over TCP) on the road-map? [2]

  I am asking because I think RFC3550 is a popular feature since it allows caller and callee to send voice packets over tor. 

  Right now RedPhone and Silent Circle are really popular even though they only encrypt the call content while making no effort to secure metadata (IP location, length of call, timing, identity).  This metadata is much more useful because it's so easy to analyze[1] whereas call content is very difficult (and boring) to analyze.

  RFC3550 RTP over TCP over TOR could be even more popular than RedPhone or Silent Circle since it eliminates the the metadata problem while also encrypting call content.

  A

  [1] Go to to see how metadata can be analyzed by algorithm.  Analyzing call metadata can be easier since there are at least two participants. [2] If the answer is no then could you tell me how I could help bring this to the Jitsi Android Client.  I'm evaluating if it would be easier to develop RFC3550 for the Jitsi Android Client since libjitsi already has RFC3550.  Right now I'm developing an RFC3550 media transport for pjsip in the hopes that the Android Clients using pjsip as a base will use RFC3550...
···

www.20q.net


#2

Hey there,

Does the Jitsi Android Client have RFC3550 (RTP over TCP) on the
road-map? [2]

You probably mean RFC4571. (RFC3550 is just base RTP). We used to support this with Google Talk but the code is not currently used. We hope to be able to bring it back soon.

I am asking because I think RFC3550 is a popular feature since it allows
caller and callee to send voice packets over tor.

Oh that would likely also require RFC6544 ... I am not sure if this would actually work over TOR though. It requires simultaneous connection establishment for TCP which is a tricky business.

Right now RedPhone and Silent Circle are really popular even though they
only encrypt the call content while making no effort to secure metadata
(IP location, length of call, timing, identity). This metadata is much
more useful because it's so easy to analyze[1] whereas call content is
very difficult (and boring) to analyze.

RFC3550 RTP over TCP over TOR could be even more popular than RedPhone
or Silent Circle since it eliminates the the metadata problem while also
encrypting call content.

I am not aware of anyone currently working on this. Support for TURN-TCP is something we are likely to do first.

[1] Go to www.20q.net to see how metadata can be analyzed by algorithm.
Analyzing call metadata can be easier since there are at least two
participants.

[2] If the answer is no then could you tell me how I could help bring
this to the Jitsi Android Client. I'm evaluating if it would be easier
to develop RFC3550 for the Jitsi Android Client since libjitsi already
has RFC3550. Right now I'm developing an RFC3550 media transport for
pjsip in the hopes that the Android Clients using pjsip as a base will
use RFC3550...

Yes, libjitsi supports RFC3550 (this is how we transport all our media) but this has nothing to do with TCP. Both the desktop and the Android client use libjitsi so if you are interested in working on this, you could start by adding it for the desktop client.

Cheers,
Emil

···

On 30.04.14, 21:19, ShootAKite@riseup.net wrote:

--
https://jitsi.org


#3

Hey thanks for the reply!

Hey there,

Does the Jitsi Android Client have RFC3550 (RTP over TCP) on the
road-map? [2]

You probably mean RFC4571. (RFC3550 is just base RTP). We used to
support this with Google Talk but the code is not currently used. We
hope to be able to bring it back soon.

You are correct RTP over TCP is described in RFC6544 not RFC3550

I am asking because I think RFC3550 is a popular feature since it allows
caller and callee to send voice packets over tor.

Oh that would likely also require RFC6544 ...

I'm not sure if RFC6544 is needed for a direct connection between two
sip clients.

I am not sure if this would actually work over TOR though. It requires
simultaneous connection establishment for TCP which is a tricky business.

The developers at TorPhone have already done this using SpeakFreely's
proprietary p2p transport http://torfone.org/spfr.html. You can
download the C++ source code at
http://torfone.org/download/torfone_V11b_src.zip

Right now RedPhone and Silent Circle are really popular even though they
only encrypt the call content while making no effort to secure metadata
(IP location, length of call, timing, identity). This metadata is much
more useful because it's so easy to analyze[1] whereas call content is
very difficult (and boring) to analyze.

RFC3550 RTP over TCP over TOR could be even more popular than RedPhone
or Silent Circle since it eliminates the the metadata problem while also
encrypting call content.

I am not aware of anyone currently working on this. Support for
TURN-TCP is something we are likely to do first.

Is a direct media stream connection between two SIP clients better than
going through a TURN-TCP. I think a direct between two .onion clients
may possibly be better than TURN-TCP for three reasons. A direct
connection may have ~1/2 the latency of going through TURN-TCP.
Addressing/authenticating users directly using tor's .onion hidden
service address may be harder to spoof then addressing/authenticating
users through TURN-TCP. a p2p media stream can use tor for encryption
however going through a TURN-TCP may requires additional layers of
encryption (like ZRTP) to avoid attacks at the TURN-TCP server.
Thanks Again!
+a

···

On 05/01/2014 10:17 AM, Emil Ivov wrote:

On 30.04.14, 21:19, ShootAKite@riseup.net wrote:

[1] Go to www.20q.net to see how metadata can be analyzed by algorithm.
Analyzing call metadata can be easier since there are at least two
participants.

[2] If the answer is no then could you tell me how I could help bring
this to the Jitsi Android Client. I'm evaluating if it would be easier
to develop RFC3550 for the Jitsi Android Client since libjitsi already
has RFC3550. Right now I'm developing an RFC3550 media transport for
pjsip in the hopes that the Android Clients using pjsip as a base will
use RFC3550...

Yes, libjitsi supports RFC3550 (this is how we transport all our
media) but this has nothing to do with TCP. Both the desktop and the
Android client use libjitsi so if you are interested in working on
this, you could start by adding it for the desktop client.

Cheers,
Emil


#4

Hey thanks for the reply!

> Hey there,
>
>> Does the Jitsi Android Client have RFC3550 (RTP over TCP) on the
>> road-map? [2]
>
> You probably mean RFC4571. (RFC3550 is just base RTP). We used to
> support this with Google Talk but the code is not currently used. We
> hope to be able to bring it back soon.
You are correct RTP over TCP is described in RFC6544 not RFC3550
>
>> I am asking because I think RFC3550 is a popular feature since it

allows

>> caller and callee to send voice packets over tor.
>
> Oh that would likely also require RFC6544 ...
I'm not sure if RFC6544 is needed for a direct connection between two
sip clients.

Yes, that's exactly what it's necessary for.

> I am not sure if this would actually work over TOR though. It requires
> simultaneous connection establishment for TCP which is a tricky

business.

The developers at TorPhone have already done this using SpeakFreely's
proprietary p2p transport http://torfone.org/spfr.html. You can
download the C++ source code at
http://torfone.org/download/torfone_V11b_src.zip

I am not very familiar with TorPhone but I believe they target TOR
explicitly and exclusively. This makes the situation much simpler to handle.

If we were to do this in Jitsi we would need to add it to what we already
have so the complexity would be significant.

It's doable but I don't see it happening in the near term.

Emil

--sent from my mobile

>
>> Right now RedPhone and Silent Circle are really popular even though

they

>> only encrypt the call content while making no effort to secure metadata
>> (IP location, length of call, timing, identity). This metadata is much
>> more useful because it's so easy to analyze[1] whereas call content is
>> very difficult (and boring) to analyze.
>>
>> RFC3550 RTP over TCP over TOR could be even more popular than RedPhone
>> or Silent Circle since it eliminates the the metadata problem while

also

···

On 01 May 2014 7:00 PM, "ShootAKite@riseup.net" <ShootAKite@riseup.net> wrote:

On 05/01/2014 10:17 AM, Emil Ivov wrote:
> On 30.04.14, 21:19, ShootAKite@riseup.net wrote:
>> encrypting call content.
>
> I am not aware of anyone currently working on this. Support for
> TURN-TCP is something we are likely to do first.
Is a direct media stream connection between two SIP clients better than
going through a TURN-TCP. I think a direct between two .onion clients
may possibly be better than TURN-TCP for three reasons. A direct
connection may have ~1/2 the latency of going through TURN-TCP.
Addressing/authenticating users directly using tor's .onion hidden
service address may be harder to spoof then addressing/authenticating
users through TURN-TCP. a p2p media stream can use tor for encryption
however going through a TURN-TCP may requires additional layers of
encryption (like ZRTP) to avoid attacks at the TURN-TCP server.
Thanks Again!
+a
>
>> [1] Go to www.20q.net to see how metadata can be analyzed by algorithm.
>> Analyzing call metadata can be easier since there are at least two
>> participants.
>>
>> [2] If the answer is no then could you tell me how I could help bring
>> this to the Jitsi Android Client. I'm evaluating if it would be easier
>> to develop RFC3550 for the Jitsi Android Client since libjitsi already
>> has RFC3550. Right now I'm developing an RFC3550 media transport for
>> pjsip in the hopes that the Android Clients using pjsip as a base will
>> use RFC3550...
>
> Yes, libjitsi supports RFC3550 (this is how we transport all our
> media) but this has nothing to do with TCP. Both the desktop and the
> Android client use libjitsi so if you are interested in working on
> this, you could start by adding it for the desktop client.
>
> Cheers,
> Emil
>

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