[jitsi-dev] Re: PTT between Jitsi and Lumicall?
- From: Kelvin Chan <kelvin.chan@...>
- To: dev@...
- Subject: [jitsi-dev] Re: PTT between Jitsi and Lumicall?
- Date: Mon, 20 Feb 2012 14:22:04 -0800
- Authentication-results: mr.google.com; spf=pass (google.com: domain of kelvin.chan@... designates 10.229.78.227 as permitted sender) smtp.mail=kelvin.chan@...
>> It is basically RTP multicast (PCMA) with a default list of 40
>> `channels', which are just the multicast addresses:
>> 22.214.171.124 : 5004
>> 126.96.36.199 : 5004
>> 188.8.131.52 : 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:
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