> First of all - please, use threads for your mails. Follow rule "One > discussion - > one thread". That is all your last four mail should be chained in one thread.
ok, I will try. What basic requirement that threads did not interrupt? > > Probably MprFromNet should notify the decoder when there is a switching > > on new SSRC, for example to do decoder::initDecode() to pick up a new > > stream. > > Yes, this may be a good solution. Patch, implementing this is welcome. > Though, I'm not sure how to do this cleanly. If someone will take this, I'll > work on elaborating right way. > As a quick solution, you may check for SSRC inside decoder itself, and > reset stats if SSRC have changed. Publish your patch on this - it may be > interesting for others, even if not included in svn. Look the attached file, all is correct? I have checked up, the sound does not interrupt. > > But, after all the situation when within the limits of one call > > simultaneously > > there will be some RTP-streams with different SSRC is quite admissible, > > and on idea they should be processed and mix up correctly in one. Yes? > > Yes, I think it is a correct way. I think we may implement something like this > in next few month. However it is not definitely planned yet. By the way, and external decoders, for example speex, support different SSRC in one stream? -- Best regards, Alexey [ [EMAIL PROTECTED] ]
decoders_ssrc.patch
Description: Binary data
_______________________________________________ sipxtapi-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
