This is slightly more performant as it does the retrieval and removal
with just one lookup instead of two.
Change-Id: Iba702704218ac4689a6788fd23a792ad40460ea8
Using a pointer array instead of a linked lists allows us to directly
reference a media section by index number, without having to spool into
the linked list.
No functional changes.
Change-Id: I8b0e93f0c2e9addbcb4c938894118ed4a6aec768
There's no point in creating a new monologue that doesn't exist yet if
all we want to do is destroy it.
Change-Id: I6b782f2706f82d1f15a5718f1bf7352fc3c3f0a4
If "streams" is given, it contains one entry per media stream.
Media-specific subscriptions aren't currently supported, so we expect
only one entry per call party, which includes a subscription to all
media streams. Crudely work around this with a feed ID uniqueness test
until proper multi-stream support is available.
Change-Id: Iaf6f8e63fb2dc20880fe807b118cc574942d53eb
We can determine the feed ID from the handle and the API does not
mandate the feed ID to be present.
Change-Id: I25b6c84b7cd8fb816d95db13d30aef41d943cafe
The "configure" message can be used without SDP to update an existing
publisher. In this use case we simply use the "audio" and "video" flags
to update the respective RECV flags of the media streams. This supports
muting and unmuting.
Change-Id: Icc77c4720124616b8b8acae3419d4d3aa200ae81
Put the code to print the details of a publisher into a JSON into a
separate function so that it can be reused.
Change-Id: I6530f2450c971663e4000fcbdc63716f631385c4
Use a callback function to populate the internal JSON fields. This makes
it possible to reuse this function for other, similar notifications.
Change-Id: I0127379b26502d88e9af38cc89f77f6b88358018
We want to send the notification to each publisher's own session, and
not to the session of the originating event.
Change-Id: I46a7c9b6adf796b076da03fac62c77ddc1d2f214
Distinguish between two cases: Sending a message to one particular WS or
HTTP connection directly as a response to a request, and sending an
asynchronous message or event to a session. Introduce
janus_send_json_sync_response() to do the format, and update all event
notifications to use janus_send_json_async().
Change-Id: I3b5a05e8c3c61d046bcaec29006698625a2570fa
We only support websocket-connected Janus sessions for now, and don't
support the HTTP polling mechanism.
Change-Id: Ia4160deeb02db20ed819864fe35f45de14c47ed8
As multiple handles from multiple different sessions can participate in
the same room, we need a way to look up handles from different sessions.
We therefore transfer ownership of all janus_handle objects to global
level. As these are currently not reference-counted, this necessitates
holding the global lock for the entirety of the signalling process.
Change-Id: Ibe27cb28407d1c8d7290faaaf5b6ae7c7f71679a
Janus rooms are not necessarily tied to just a single session. Make it
possible for one room to be used from multiple sessions.
Change-Id: Id35db2ada66a5bf392ce577cb5f2a970ca13b9dc
Avoid calling lws_write() from threads other than the service thread, as
this might not be thread-safe. Instead store the values used for the
HTTP response headers in the websocket_output, then trigger a "writable"
callback, and finally do all the lws_write() calls from the service
thread.
Reported in #1624
Change-Id: Ifcb050193044e5543f750a12fb44f5e16d4c0a08
... so that the publishing session gets notified about "webrtcup" and
not the session which created the room.
Change-Id: If7b308df4afa7afb19ecaca1f743f87c3c736007
Our own Janus WS client would create a single WS session and then create
all rooms under this one session and run all publishes and subscribers
under the same session. This is not a restiction imposed by Janus
though, which allows participation in one room by multiple sessions.
Remove this restriction to more closely mirror Janus behaviour.
Change-Id: Ic11f961369ce5ded599a7a22cd730236460a8c61
To allow supplying the handle ID and session ID separately without
requiring it to be in the JSON.
Change-Id: I4a6f18410084add2a37cdf1ea3375072a8e192ca
According to:
{
"request" : "join",
"ptype" : "subscriber",
"room" : <unique ID of the room to subscribe in>,
"use_msid" : <whether subscriptions should include an msid that references the publisher; false by default>,
"autoupdate" : <whether a new SDP offer is sent automatically when a subscribed publisher leaves; true by default>,
"private_id" : <unique ID of the publisher that originated this request; optional, unless mandated by the room configuration>,
"streams" : [
{
"feed" : <unique ID of publisher owning the stream to subscribe to>,
"mid" : "<unique mid of the publisher stream to subscribe to; optional>"
"crossrefid" : "<id to map this subscription with entries in streams list; optional>"
// Optionally, simulcast or SVC targets (defaults if missing)
},
// Other streams to subscribe to
]
}
{
"videoroom" : "attached",
"room" : <room ID>,
"streams" : [
{
"mindex" : <unique m-index of this stream>,
"mid" : "<unique mid of this stream>",
"type" : "<type of this stream's media (audio|video|data)>",
"feed_id" : <unique ID of the publisher originating this stream>,
"feed_mid" : "<unique mid of this publisher's stream>",
"feed_display" : "<display name of this publisher, if any>",
"send" : <true|false; whether we configured the stream to relay media>,
"ready" : <true|false; whether this stream is ready to start sending media (will be false at the beginning)>
},
// Other streams in the subscription, if any
]
}
Change-Id: Ieb38d4f562686283457a963334056b27927be974
Apparently Janus allows a single handle to be both controller and
publisher, and possibly also both publisher and subscriber. Remove the
limitation that forces one handle to only take one role.
Change-Id: I22c20981a213b84d06dad07b1ff634bfd024fd91
Richard Fuchs