On 7/23/07, Alexey Trizno <[EMAIL PROTECTED]> wrote: > > 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?
You should "Reply to" to some mail in the thread, even if it is your mail. In this case mailer insert In-Reply-To and Reference fields in mail header and other mailers consider correct threading. > > > 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. Well, idea is correct. But I'd rather call freeDecode() and then initDecode() in case of SSRC change. This will reset some more stream parameters, such as clock drift and so. Later this could be generalized to use with all decoders. > > > 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? I think no. Something similar to PCMU/PCMA should be done for them too. -- Regards, Alexander Chemeris. SIPez LLC. SIP VoIP, IM and Presence Consulting http://www.SIPez.com tel: +1 (617) 273-4000 _______________________________________________ sipxtapi-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
