You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openmeetings.apache.org by Maxim Solodovnik <so...@gmail.com> on 2013/02/13 04:39:07 UTC
Issue with OM per user streams
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
RE: Issue with OM per user streams
Posted by Irina Arkhipets <ia...@unipro.ru>.
Sebastian,
>From my experience: it happens more often when SIP user is in the room, but
also we observed similar behavior without him too.
We can help you if you would like to try it. Just let me know and let's
discuss convenient time for this.
SIP integration is currently configured on our demo server (demo.dataved.ru)
so that you can call to the room from some software phone (we deal with
linphone).
Regards,
Irina.
-----Original Message-----
From: seba.wagner@gmail.com [mailto:seba.wagner@gmail.com]
Sent: Wednesday, February 13, 2013 12:31 PM
To: Maxim Solodovnik
Cc: dev
Subject: Re: Issue with OM per user streams
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 <so...@gmail.com>
> 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
seba.wagner@gmail.com
Re: Issue with OM per user streams
Posted by "seba.wagner@gmail.com" <se...@gmail.com>.
Hi Timur,
I found and fixed the issue why "closeStream" was called twice.
The bug was that in the method "_stop" this._nc = null was missing to make
sure the stop method is not called twice.
Long description:
When the user hits the "re-start audio/video settings" icon on his own
video pod, the choose-settings dialog will popup. But also a there is a
call on the icon to the method: resetStream,
this will call: this._chatvideoinner._videostream._stop();
_stop() does close the NetStream, on server side this event is catched,
and in ScopeApplicationAdapter:streamBroadcastClose() we listen for that
event and send a "closeStream" to all participants.
That is all good, the issue is, when the user re-starts the stream, in the
method "broadcast" there is an if-clause:
if (this._ns != null) {
this._stop();
}
And this fired a stop event for the second time because this._ns = null was
missing.
Should be all good, let me know if there are more issues with the stream
handling.
Thanks
Sebastian
2013/2/13 seba.wagner@gmail.com <se...@gmail.com>
> 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 Тимур Тлеукенов <ti...@gmail.com>
>
>> 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 seba.wagner@gmail.com <se...@gmail.com>
>>
>> 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 seba.wagner@gmail.com <se...@gmail.com>
>>>
>>> > 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 <so...@gmail.com>
>>> >
>>> >> 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
>>> > seba.wagner@gmail.com
>>> >
>>>
>>>
>>>
>>> --
>>> Sebastian Wagner
>>> https://twitter.com/#!/dead_lock
>>> http://www.webbase-design.de
>>> http://www.wagner-sebastian.com
>>> seba.wagner@gmail.com
>>>
>>
>>
>>
>> --
>> Timur Tleukenov
>
>
>
>
> --
> Sebastian Wagner
> https://twitter.com/#!/dead_lock
> http://www.webbase-design.de
> http://www.wagner-sebastian.com
> seba.wagner@gmail.com
>
--
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wagner@gmail.com
Re: Issue with OM per user streams
Posted by "seba.wagner@gmail.com" <se...@gmail.com>.
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 Тимур Тлеукенов <ti...@gmail.com>
> 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 seba.wagner@gmail.com <se...@gmail.com>
>
> 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 seba.wagner@gmail.com <se...@gmail.com>
>>
>> > 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 <so...@gmail.com>
>> >
>> >> 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
>> > seba.wagner@gmail.com
>> >
>>
>>
>>
>> --
>> Sebastian Wagner
>> https://twitter.com/#!/dead_lock
>> http://www.webbase-design.de
>> http://www.wagner-sebastian.com
>> seba.wagner@gmail.com
>>
>
>
>
> --
> Timur Tleukenov
--
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wagner@gmail.com
Re: Issue with OM per user streams
Posted by Тимур Тлеукенов <ti...@gmail.com>.
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 seba.wagner@gmail.com <se...@gmail.com>
> 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 seba.wagner@gmail.com <se...@gmail.com>
>
> > 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 <so...@gmail.com>
> >
> >> 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
> > seba.wagner@gmail.com
> >
>
>
>
> --
> Sebastian Wagner
> https://twitter.com/#!/dead_lock
> http://www.webbase-design.de
> http://www.wagner-sebastian.com
> seba.wagner@gmail.com
>
--
Timur Tleukenov
Re: Issue with OM per user streams
Posted by "seba.wagner@gmail.com" <se...@gmail.com>.
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 seba.wagner@gmail.com <se...@gmail.com>
> 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 <so...@gmail.com>
>
>> 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
> seba.wagner@gmail.com
>
--
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wagner@gmail.com
Re: Issue with OM per user streams
Posted by "seba.wagner@gmail.com" <se...@gmail.com>.
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 <so...@gmail.com>
> 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
seba.wagner@gmail.com