... 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
lsb-base as of version 11.5 and as present in Debian/testing AKA
bookworm is a transitional package (depending on sysvinit-utils).
As of lintian >=2.116.0 a dependency on lsb-base is considered an error:
| E: ngcp-rtpengine-daemon: depends-on-obsolete-package Depends: lsb-base (>= 3.0-6)
| E: ngcp-rtpengine-recording-daemon: depends-on-obsolete-package Depends: lsb-base (>= 3.0-6)
Now having lintian 2.116.1 in Debian/testing AKA bookworm our package
builds fail because of this.
Since we still have init script support and references to
/lib/lsb/init-functions, let's depend on either sysvinit-utils
or lsb-base.
See related discussion on debian-devel mailing list:
https://lists.debian.org/debian-devel/2023/01/msg00149.html
Change-Id: Id3228425405e39904e52de8fdf00911539ac63bb
So far we used ubuntu-latest for the unit-tests, though this is no
longer using Ubuntu/focal (wich we used to build for) but Ubuntu/jammy
(22.04 LTS, AKA Jammy Jellyfish) nowadays.
Instead let's stick to ubuntu-22.04 since we also use a specific release
for the packaging part.
FTR: see https://github.com/actions/runner-images for the overview
of available GitHub Actions Runner Images
Change-Id: I41f2fe1c35bccb40f1f8df59b23446ab27ce1033
For source files generated from the "strhash" helper script, output line
and file number information into the generated .c source to help gdb and
other tools correspond the compiled code with the correct source code.
Change-Id: Ieddc86ab59b41ab26942e8a7d3c24e7800e9936f
The option flags used when calling the rtpengine_offer()
have been re-ordered in the ascent manner according to alphabet.
Additionally three sub-sections have been created, to make
the sorting of flags simpler:
- Optionally included flags
- Optionally included replace-flags
- Optionally included codec manipulations
All subsection are also ordered inside.
Change-Id: I67663827eb710564f0314d1f6919d428206e1cef
Don't wait forever for a response from the daemon. Prevents tests
getting stuck in case of broken code.
Change-Id: I83dde4c2d626928fdfb0486e7fb4780e239c83e9
This is a new option flag, which provides a possiblity
to select specific crypto suite(s) for the offerer from
the given list of crypto suites received in the offer.
This will be used later on, when processing an answer from
the recipient and generating an answer to be sent out towards offerer.
Furthermore, this is being decided not when the answer is processed,
but already when the offer is processed.
Flag usage example:
`SDES-offerer_pref:AES_256_CM_HMAC_SHA;AES_256_CM_HMAC_SHA1_32;`
Change-Id: I2b22b38347d24f27331482e18b92305fbadb2520
We're already determining the destination media section in
media_player_play_init() (looking for audio media), so it makes sense to
determine the payload type there as well.
Change-Id: I33d4a15005c2146864f74663fe8de2893454345b
Split out the logic to determine the destination payload type into a
separate functions. This makes it possible to supply a different, or
pre-determined, payload type instead.
Change-Id: I9b67b29cafc0c6ce4e18eede64dea3d1973f8b63
It makes more sense to set up the codec handler from the init function
rather than from the function reading the media packet.
Change-Id: I0bea3d0fc0669a54f93b2598251df69274950365
Richard Fuchs
Michael Prokop
Donat Zenichev
Lasse Bang Mikkelsen
Stefan Mititelu
Sipwise Jenkins Builder
Дилян Палаузов