multiple RTP streams received on multicast

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Benny Prijono schrieb:
> On Mon, Jul 28, 2008 at 10:19 AM, Klaus Darilion 
> <klaus.mailinglists at pernau.at <mailto:klaus.mailinglists at pernau.at>> wrote:
> 
>     Hi Benny!
> 
>     I have modified the streamutil.c sample to send/receive from multicast
>     IP and subscribe to the multicast group. This works fine if there is
>     only one sender in the multicast group. If there are multiple senders to
>     the same mutlicast group, the audio played back by pjsip is broken.
> 
> 
> That's probably because you use one stream (i.e. one jitter buffer) for 
> everyone. If the multiple senders are talking at the same time, I can 
> imagine that the jitter buffer will get confused because of this. Even 
> when talkers are talking in turns, the jitter buffer will also get 
> confused if senders have different RTP timestamp reference (in other 
> words, you need to make sure that all participants have the same RTP 
> timestamp clock).
>  
> The later problem probably could be alleviated with using the jitter 
> buffer in fixed mode.
> 
>     To solve this issue I want to have multiple choices, e.g:
>       - conference all the incoming streams
>       - use only the first stream (and some timeout to change to another
>     stream if the current stream stops)
>       - manual selection of the stream (SSRC)
> 
>     Can you give me some hints how to implement this?
> 
> 
> If you want to create one stream for each participant, you'd need to 
> implement some sort of wrapper to the media transport, which will check 
> the SSRC in incoming RTP and distribute it to the appropriate stream 
> instance (or create the stream if it doesn't exist). This kind of 
> adapter is explained a bit in 
> http://trac.pjsip.org/repos/wiki/SRTP#pjmedia_transport_srtpImplementation

So, the RTP packet is decoded twice?
  1. In my adapter (between the UDP transport and the multiple streams) 
to get the SSRC and the corresponding stream
  2. In the corresponding stream?


regards
klaus



[Index of Archives]     [Asterisk Users]     [Asterisk App Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [Linux API]
  Powered by Linux