[jitsi-dev] PTT between Jitsi and Lumicall?


#1

I've just pushed out v1.4.1 of Lumicall with push-to-talk (PTT) support

It is basically RTP multicast (PCMA) with a default list of 40
`channels', which are just the multicast addresses:

224.0.224.1 : 5004
224.0.224.2 : 5004
...
224.0.224.40 : 5004

Is there anything like this on the roadmap for Jitsi? It would be good
to align them to use the same channels to make it easy for users
unfamiliar with multicast addresses.

Regards,

Daniel


#2

I've just pushed out v1.4.1 of Lumicall with push-to-talk (PTT) support

It is basically RTP multicast (PCMA) with a default list of 40
`channels', which are just the multicast addresses:

224.0.224.1 : 5004
224.0.224.2 : 5004
...
224.0.224.40 : 5004

Is there anything like this on the roadmap for Jitsi? It would be good
to align them to use the same channels to make it easy for users
unfamiliar with multicast addresses.

Hi Daniel,

I have implemented PTT in Jitsi with SIP but not RTP. As far as I can tell,
Neomedia, the media processing stack, does not export any
ProtocolProviderService and OperationSet. So you'll have to implement your
own if you were to do RTP streaming on multicast.

hope it helps.

kel


#3

How closely will the Jitsi for Android RTP stack follow the existing
Neomedia model? This is a particularly useful feature for the mobile user.

I've put up some docs here with test commands for VLC:

http://www.lumicall.org/push-to-talk-walkie-talkie

···

On 20/02/12 22:41, Kelvin Chan wrote:

    I've just pushed out v1.4.1 of Lumicall with push-to-talk (PTT) support

    It is basically RTP multicast (PCMA) with a default list of 40
    `channels', which are just the multicast addresses:

    224.0.224.1 : 5004
    224.0.224.2 : 5004
    ...
    224.0.224.40 : 5004

    Is there anything like this on the roadmap for Jitsi? It would be good
    to align them to use the same channels to make it easy for users
    unfamiliar with multicast addresses.

Hi Daniel,

I have implemented PTT in Jitsi with SIP but not RTP. As far as I can
tell, Neomedia, the media processing stack, does not export any
ProtocolProviderService and OperationSet. So you'll have to implement
your own if you were to do RTP streaming on multicast.


#4
It is basically RTP multicast \(PCMA\) with a default list of 40
\`channels', which are just the multicast addresses:

224\.0\.224\.1 : 5004
224\.0\.224\.2 : 5004
\.\.\.
224\.0\.224\.40 : 5004

Is there anything like this on the roadmap for Jitsi?  It would be good
to align them to use the same channels to make it easy for users
unfamiliar with multicast addresses\.

Hi Daniel,

I have implemented PTT in Jitsi with SIP but not RTP. As far as I can
tell, Neomedia, the media processing stack, does not export any
ProtocolProviderService and OperationSet. So you'll have to implement
your own if you were to do RTP streaming on multicast.

How closely will the Jitsi for Android RTP stack follow the existing
Neomedia model? This is a particularly useful feature for the mobile user.

I've put up some docs here with test commands for VLC:

http://www.lumicall.org/push-to-talk-walkie-talkie

I'm not sure about ProtocolProviderService/OpSet in Jitsi for android.
It's better for someone else to answer that question.

For neomedia, it implements MediaService interface. You can either
implement a ProtocolProviderService/OpSet or simply use MediaService.
The difference is whether you want PTT be part of Jitsi (implement
ProtocolProviderService/OpSet) or MediaService/Neomedia be part of you
PTT (simply use MediaService).

If MediaService is implemented on Android, you can safely rely on it
for streaming without having to worry about ProtocolProviderService
and OperationSet.

kel