Two version of the origin replace exist from now on:
- `origin-replace` - replaces only the origin address
- `origin-replace-full` - replaces all the values,
so name, id, version and IP family with address.
Values for replacing are taken from the rtpengine instance,
so local values provided by the daemon.
Additionally: documentation updated accordingly.
Additionally: revert changes in pub-sub test.
Change-Id: I4d068944726d1ab82683ca5aa641a954890aefcf
Since the `replace-session-connection` has been
deprecated by the 9f8820bd36 then the docs have
to be updated accordingly.
Change-Id: I57200440f360b7e72168989f9dde8c3a38a18867
Describe generally: what are option flags and how the parsing
of them is done. Also add a description of two currently supported
approaches:
- parsing using a module (e.g. kamailio)
- parsing using the daemon
Change-Id: I55cee8fc82c2de8eb1f8cef565d19d73023d8be9
Refactor the text in the NG-protocol description header:
- fix typos
- fix grammatical mistakes
- reformat the text for simpler reading in blocks
Change-Id: I4aa66d11607ddab6cf12d4571a3fd07e4a850c4a
Handle the `output-destination` flag in the same way as the `metadata`
flag, eliminating the need to do it explicitly everywhere it's relevant.
Add a few alternative spellings of `output-destination`.
Rename the member from flags to `recording_file` to make it more clear
what it is.
Add save/restore capabilities of that field to the Redis code.
Unify printing of monologue LABEL into the same function that handles
the metadata.
Update documentation to better explain this option, and use the new
clearer name.
Change-Id: I4496341013b0ccab5b1dec026cf3a1a0ea879018
In order to let the docs comply with what we have in the code,
we have to adjust some of docs definitions and also remove partially.
Change-Id: Ied5791d196267abfc1e1717d23751b1acf8e9dc1
To be able to use this feature from controlling agents which don't
directly support the new dictionary keys, add an alternative syntax via
the `flags` list. This is in line with all other similar dictionary keys
(e.g. `codec-` etc)
Change-Id: I7210c74c9cd3b31338052efa1c3504fe775c1c46
Make it possible to set output-destination immediately when starting the
reording, not only afterwards.
Closes#1667
Change-Id: Idb7de770ad5a41d6ae6055784213e7983df9bfec
When the `discard-recording` flag is given in one of the commands to
rtpengine (e.g. in the `delete` command), the metafile is renamed to a
.DISCARD suffix and then deleted.
The recording daemon then, seeing the .DISCARD suffix, proceeds to
immediately close all recordings, delete the files if any, and delete
the entries from the DB.
Change-Id: I3f0cac129f2d56cbccd770d43bf434dea6c0a0db
There's a mixture of RTPengine and RTPEngine, though we lowercase it
entirely most of the time, so let's stick to this and unify its style.
While at it remove the "the" article for rtpengine as well,
where applicable.
Change-Id: Idbad9313499942ad12ade2c9ce76fe3ec4cd2762
It substitutes a specified `a=` line taken from the concerned
media attributes list. If such line has been not found,
the attributes list remains untouched.
It subsitutes one attribute at a time, so one attribute into
another attribute.
Change-Id: Ie0a48ba46a1b196fbe33b09dedc40e4498640e34
Track audio writes in the mix buffer to set the `active` flag to true
whenever a write occurs, which makes it possible to create the buffer in
an inactivate state and implicitly set it active on demand.
Handle the mix buffer not returning any data in the RTP sending logic
(which is what happens for an inactive buffer) by simply not sending any
packets.
Change-Id: Iaeb0f6deadb3d90020c8c62872735cc94db80504
Similar to the existing media_player, but instead of simply producing
its own standalone output media stream, the audio_player takes over the
entire media stream flowing to the receiver, including media forwarded
from the opposite side of the call, as well as media produced by the
media_player.
Change-Id: Ic34ecf08fc73b04210cfffb1a7d795b462ece5ea
We have to restructure project's general README.md
in order to make all recently added documentation sources
(including RTD) be compliant and let it look centralized and
good organized.
The root of the repository still has the README.md, but
it only shows general summary on the project and then gives
links to the extended documentation sources:
- RTD stored
- GitHub stored
Change-Id: Ief160669432ecb3e22df16d9278df863da995991
New section of option flags has been introduced for SDP body
attributes manipulations.
Three levels of the SDP session are concerned:
- session level (global one)
- media level - audio
- media level - video
Three different actions are supported for now:
- add
- remove
The value of the command has a wildcard matching approach.
Other attributes apart `a=` can not be edited by this functionality.
So such headers as: `c=`, `s=`, `o=` cannot be touched.
Change-Id: I939d4582839096b2399f7ded865e91ff6eb960a4
(cherry picked from commit 3f06c18793)
Defined in RFC 8842. If a tls-id was previously given and a the new SDP
shows a different tls-id or none at all, we must restart DTLS.
Relevant to #1585
Change-Id: I554234dfcacbd330c7a0c6aea68f24d0449cba21
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
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
This is a new option flag, which provides the ordered list,
in which to add crypto suites into the SDP body.
Right now they're always added in the order given in the source code.
Flag usage example:
`SDES-order:AES_256_CM_HMAC_SHA;AES_256_CM_HMAC_SHA1_32;AES_192_CM_HMAC_SHA1_80;`
This means — those listed SDES crypto suites will be added
into the generated SDP body at the top of crypto suites list, in the given order.
But, each of them is added, only if it is about to be added/generated.
In other words, the `SDES-order:` flag itself doesn't add crypto suites,
it just affects the order of those suites to be added.
And the rest of non-mentioned suites, which are also to be added,
will be appended after those given, in the free manner of ordering.
Important thing to remember - it doesn't change the crypto suite tag
for the recipient, even though changing the order of them.
Additionally.
This flag does not contradict with `SDES-nonew`, `SDES-only-` and `SDES-no-` flags.
It just orders the list of crypto suites already prepared to be sent out.
Change-Id: I0fec54f9e2f3cd4913e905e8afe825712f82d1ae
Add a new flag to only accept these individual crypto suites
and none of the others.
For example, `SDES-only-NULL_HMAC_SHA1_32`
would only accept the crypto suite `NULL_HMAC_SHA1_32` for
the offer being generated.
This also takes precedence over the `SDES-no-` flag(s),
if used together, so the `SDES-no` will be not taken into account.
This has two effects:
- if a given crypto suite was present in a received offer,
it will be kept, so will be present in the outgoing offer; and
- if a given crypto suite was not present in the received offer,
it will be added to it. The rest, which is not mentioned,
will be dropped/not added.
Flag name: 'SDES-only-<crypto name>'
Additionally: add another new flag 'SDES-nonew'.
It will not add any new crypto suites into the offer.
It takes precedence over the `SDES-no` and `SDES-only` flags,
if used in combination.
Change-Id: Ic4fa03957ee3d4d24b0c4f3fd003eada05f49b0b
Add a flag to force increasing the SDP version,
even if the SDP hasn't been changed.
And cover it with tests.
Flag name: 'force-increment-sdp-ver'
Additionally fix the name of the 'sdp-version' flag
in the 'rtpengine-ng-client' tool.
Change-Id: I466792668b0cd313b5e21b248dd14cd599333cbd
Support multiple tone frequencies for DTMF-security=tone to enable
audibly distinguishing multiple consecutive DTMF events from one
another.
Change-Id: I6fa33a5768aae198220d0b0cc4c53308c5661a52