[sip-comm-dev] Questions / wishes regarding new media implementation


#1

Emil,

the last day I had a first short look into the new media
implementation. I saw that security was not addressed yet, which
is quite normal at this early stage :slight_smile: .

Due to some constraints in the ZRTP protocol with respect to
the RTP stream I would require a way to determine if a RTP
stream is "receive only". In case of a "receive only" stream
the client does not send any RTP data and JMF (and FMJ) does
not generate a send stream and thus no SSRC. ZRTP requires a
SSRC. For "receive only" streams I would then just generate
a dummy SSRC for the purpose of ZRTP only.

Without such a detection mechanism the implementation of
"receive only" RTP streams would be very hard if not impossible.
Because the current media implementation does not provide the
detection of "receive only" streams (at least I couldn't find a
good way to do it) I need to switch of the support of
"receive only" streams for the time being.

Any ideas / comments about this?

Regards,
Werner

路路路

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#2

Hey Werner,

Werner Dittmann wrote:

Emil,

the last day I had a first short look into the new media
implementation. I saw that security was not addressed yet, which
is quite normal at this early stage :slight_smile: .

Not yet indeed, but it does live in our hearts! :slight_smile:

Seriously, we are indeed considering the options for the SIP<->Media and
XMPP<->Media interactions.

Due to some constraints in the ZRTP protocol with respect to
the RTP stream I would require a way to determine if a RTP
stream is "receive only".

This was actually previewed in the original design in order to allow
handling the recvonly, sendonly, and sendrecv SDP params. I see now that
I've forgotten to also add it in the service interfaces. Will fix this.

In case of a "receive only" stream
the client does not send any RTP data and JMF (and FMJ) does
not generate a send stream and thus no SSRC. ZRTP requires a
SSRC. For "receive only" streams I would then just generate
a dummy SSRC for the purpose of ZRTP only.

Without such a detection mechanism the implementation of
"receive only" RTP streams would be very hard if not impossible.
Because the current media implementation does not provide the
detection of "receive only" streams (at least I couldn't find a
good way to do it) I need to switch of the support of
"receive only" streams for the time being.

Got it. Will try to think of something.

Thanks for the heads up!

Cheers,
Emil

路路路

Any ideas / comments about this?

Regards,
Werner

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net