Hi Timur, yes thanks, I could duplicate the closeStream bug. I seem to receive a closeStream Event too much and with another (Room)Client object set. That is strange, I will need some more time to debug that.
Sebastian 2013/2/13 Тимур Тлеукенов <[email protected]> > Hello Sebastian! > > This issue happens without SIP integration. You can see it with laslo > debuger. > After somebody click "(Re) start audio/video" button, other clients > receive newStream twice. > > Here part of log from laszlo debuger: > **** closeStream: «Object#935| {allowRecording: true, avsettings: 'av', > broadCastID: 5, ... > sendVarsToMessageWithClient : «Array(0)#937| []» «Array(3)#938| > ['avsettings', '0', 'av']» avsettings > newStream: «Object#939| {allowRecording: true, avsettings: 'av', > broadCastID: 6, ... > **** closeStream: «Object#942| {allowRecording: true, avsettings: 'av', > broadCastID: 6, ... > newStream: «Object#944| {allowRecording: true, avsettings: 'av', > broadCastID: 6, ... > > Sometimes i see that client receive second closeStream before newStream > and stream is duplicated. > > I checked log when SIP user connects: > newStream: «Object#975| {allowRecording: true, ..., broadCastID: 10, > canDraw: false, ... > addNewUser: «Object#977| {allowRecording: true, avsettings: 'av', > broadCastID: 10, ... > ### initializeStreams addClientItem: «Date#978| Wed Feb 13 13:01:03 > GMT+0700 2013» false 11 2 null > participantList addItem: «Object#977| {allowRecording: true, avsettings: > 'av', broadCastID: 10, ... > object.isSuperModerator false > updateByMod, false 2 > onmicMutedStatusChangedItem :3: b8d379ff26758fd4ff0ebe8de3921e54 false > newStream: «Object#980| {allowRecording: true, avsettings: 'av', > broadCastID: 10, ... > > Actually newStream called twice in this case. So setSipTransport should be > fixed. > > > 2013/2/13 [email protected] <[email protected]> > > I actually don't understand: >> ((IServiceCapableConnection) conn).invoke("newStream", new >> Object[]{currentClient}, this); >> in the method setSipTransport >> >> Actually _every_ stream that starts broadcasting will trigger an Event in >> OpenMeetings. >> We catch those "stream start events" in the method: >> @Override >> public synchronized void streamPublishStart(IBroadcastStream stream) >> >> In the ScopeApplicationAdapter. >> >> Where this stream is coming from, if its screensharing or audio/video, it >> does not matter. >> I would expect that if a SIP user connects via red5SIP, this method will >> be >> still invoked, as it is just a "yet another stream" from the view of the >> red5 server. >> So why does "setSipTransport" call this method actively? >> "streamPublishStart" (and through that "newStream") should be called >> automatically as soon as the SIP user starts to stream audio to red5. >> >> You just need to make sure that the Client (former RoomClient) has the >> right flags set _before_ you start to stream. Cause the method >> "streamPublishStart" will send a client object to all users. And you can't >> pass any variables to "streamPublishStart" as this is a method/event >> listener of Red5. >> >> Calling "addNewUser" from "setSipTransport" makes sense for me, as this >> logic is the same like in "setRoomValues". But calling "newStream" from >> "setSipTransport" makes no sense to me. From my point of view you would >> get >> a duplicated "newStream" method call everytime a SIP user connects: >> 1) When setSipTransport is invoked >> 2) When the actual stream starts >> >> Can you check with that with Timur? >> >> Sebastian >> >> >> 2013/2/13 [email protected] <[email protected]> >> >> > Is this a problem that only happens with SIP integration or also >> > standalone? >> > >> > I will have to test that first. It sounds a bit weird, but I can't test >> it >> > as I don have 5-7 pc's. >> > And using a single pc makes no sense when testing audio/video. >> > >> > We have two rtmp connection per stream, but that would still not explain >> > your issues with the id. >> > Which Id are your refering to exactly? broadCastId or streamId ? >> > broadcastId would be the name of the stream under which the user >> publishs >> > (aka NetStream) streamId is the rtmp connection (aka NetConnection), >> > you connect to: rtmp://blabla:1935/openmeetings/ >> > And each client will publish his webcam+micro in one stream, with the >> name >> > of the "broadCastId". >> > >> > The StreamId can stay the same, for example if you re-publish your >> > settings, the NetConnection will always stay, but each time your webcam >> is >> > published a new "broadCastId" is requested from the server. (See >> > ScopeApplicationAdapter::getBroadCastId()). It is better to use a fresh >> > broadCastId each time you make a new NetStream. >> > >> > "setSipTransport" and "streamPublishStart" are new only methods that >> > invoke "newStream" as event in the client. >> > >> > Sebastian >> > >> > >> > 2013/2/13 Maxim Solodovnik <[email protected]> >> > >> >> Hello Sebastian, >> >> >> >> sorry for double post, but I would like to gain your attention at the >> >> following problem: >> >> >> >> >> >> if there is lot of users lots of users in the room (5-7) some of them >> >> can't hear some others until "reload" of streams on the client. >> >> Timur told me that according to the log of red5sip there is weird queue >> >> of method calls: newStream gets called twice. Additionally if user has >> >> stream with id 24 and select "reload" the following methods are gets >> called: >> >> closeStream(25) // NOTE 25 not 24 >> >> then >> >> newStream(25) >> >> >> >> Maybe you can say what is wrong? >> >> >> >> -- >> >> WBR >> >> Maxim aka solomax >> >> >> > >> > >> > >> > -- >> > Sebastian Wagner >> > https://twitter.com/#!/dead_lock >> > http://www.webbase-design.de >> > http://www.wagner-sebastian.com >> > [email protected] >> > >> >> >> >> -- >> Sebastian Wagner >> https://twitter.com/#!/dead_lock >> http://www.webbase-design.de >> http://www.wagner-sebastian.com >> [email protected] >> > > > > -- > Timur Tleukenov -- Sebastian Wagner https://twitter.com/#!/dead_lock http://www.webbase-design.de http://www.wagner-sebastian.com [email protected]
