Changes

RTP: add vty option for ortp vs twrtp selection

With this patch it finally becomes possible for the user to select
which RTP library should be used: ortp or twrtp.  ortp is still
the default for now, in order to not alter behavior for existing
installations until twrtp receives more real world testing by users
beyond the original author.  Future patches may change the default
or even remove ortp support altogether - but twrtp should receive
more testing as a user opt-in feature first.

Related: OS#6474
Change-Id: Iff4e3a399250c16ba8fe4cb12e4e22f4c6b346ec

RTP: add vty option for ortp vs twrtp selection

With this patch it finally becomes possible for the user to select
which RTP library should be used: ortp or twrtp.  ortp is still
the default for now, in order to not alter behavior for existing
installations until twrtp receives more real world testing by users
beyond the original author.  Future patches may change the default
or even remove ortp support altogether - but twrtp should receive
more testing as a user opt-in feature first.

Related: OS#6474
Change-Id: Iff4e3a399250c16ba8fe4cb12e4e22f4c6b346ec

RTP: use new abstraction layer instead of direct osmo_ortp

As of this patch in the series, the RTP library in active use
is still always ortp, but all BTS code now accesses it through
the new abstraction layer, paving the way for twrtp option.

Related: OS#6474
Change-Id: I5e3de4f84e8e8875437cb94a9b8feeb07f9cc1cf

RTP: implement RTP socket abstraction layer

This abstraction layer is another step toward supporting a choice
between legacy Belledonne ortp and Osmocom-integrated twrtp.

Related: OS#6474
Depends: Ibda74c0dbfb163f5d0e3fb13f593a6e2c6817673 (libosmo-netif.git)
Change-Id: Ic945f6d753ec7f5c0ac5cecc9f71049464de7e8f

RTP: implement RTP socket abstraction layer

This abstraction layer is another step toward supporting a choice
between legacy Belledonne ortp and Osmocom-integrated twrtp.

Related: OS#6474
Depends: Ibda74c0dbfb163f5d0e3fb13f593a6e2c6817673 (libosmo-netif.git)
Change-Id: Ic945f6d753ec7f5c0ac5cecc9f71049464de7e8f

RTP: add vty configuration for twjit

This patch is the first step in the series adding the ability to use
twrtp+twjit instead of Belledonne ortp.  twjit requires vty config
for tunable parameters - add this config.  Actual use of this added
config will happen in subsequent patches.

Related: OS#6474
Change-Id: I9ccd060fce8416e01356fccd9ae465a7298a9ce5

RTP: use new abstraction layer instead of direct osmo_ortp

As of this patch in the series, the RTP library in active use
is still always ortp, but all BTS code now accesses it through
the new abstraction layer, paving the way for twrtp option.

Related: OS#6474
Change-Id: I5e3de4f84e8e8875437cb94a9b8feeb07f9cc1cf

RTP: implement RTP socket abstraction layer

This abstraction layer is another step toward supporting a choice
between legacy Belledonne ortp and Osmocom-integrated twrtp.

Related: OS#6474
Depends: Ibda74c0dbfb163f5d0e3fb13f593a6e2c6817673 (libosmo-netif.git)
Change-Id: Ic945f6d753ec7f5c0ac5cecc9f71049464de7e8f

RTP: add vty configuration for twjit

This patch is the first step in the series adding the ability to use
twrtp+twjit instead of Belledonne ortp.  twjit requires vty config
for tunable parameters - add this config.  Actual use of this added
config will happen in subsequent patches.

Related: OS#6474
Change-Id: I9ccd060fce8416e01356fccd9ae465a7298a9ce5

RTP: add vty option for ortp vs twrtp selection

With this patch it finally becomes possible for the user to select
which RTP library should be used: ortp or twrtp.  ortp is still
the default for now, in order to not alter behavior for existing
installations until twrtp receives more real world testing by users
beyond the original author.  Future patches may change the default
or even remove ortp support altogether - but twrtp should receive
more testing as a user opt-in feature first.

Related: OS#6474
Change-Id: Iff4e3a399250c16ba8fe4cb12e4e22f4c6b346ec

Bump version: 1.10.0.36-b9839-dirty → 1.11.0

Change-Id: I595b31071a071bfa5666931d99e24e9b56877a6f

Bump version: 1.10.0.36-b9839-dirty → 1.11.0

Change-Id: I595b31071a071bfa5666931d99e24e9b56877a6f

power_control: lchan_ms_pwr_ctrl(): always log input values

Depending on the power control interval (P_Con_INTERVAL), the MS power
loop may delay the power control decision for a certain amount of SACCH
block periods.  In this case lchan_ms_pwr_ctrl() returns early and no
logging is printed at all.

Let's always log the input values (reported level, UL measurements)
early in lchan_ms_pwr_ctrl().  This is useful for debugging, and
this is exactly what lchan_bs_pwr_ctrl() does.

Change-Id: I3b8466f062624fc8a2ea6f8220c057d3812f2c35

power_control: lchan_ms_pwr_ctrl(): always log input values

Depending on the power control interval (P_Con_INTERVAL), the MS power
loop may delay the power control decision for a certain amount of SACCH
block periods.  In this case lchan_ms_pwr_ctrl() returns early and no
logging is printed at all.

Let's always log the input values (reported level, UL measurements)
early in lchan_ms_pwr_ctrl().  This is useful for debugging, and
this is exactly what lchan_bs_pwr_ctrl() does.

Change-Id: I3b8466f062624fc8a2ea6f8220c057d3812f2c35

osmo-bts-trx: apply 'max-initial' value before POWERON

Not applying this value before powering the transceiver on results
in transmission at full Tx power for a certain amount of time before
the power ramping begins.

Change-Id: Iff03d4dcb74f67629a59c8d6f8bb60929d9f6ddd
Related: OS#6939

osmo-bts-trx: trx_provision_fsm: mark internal functions as static

Change-Id: I0cf13e091938db2b991156189bf4ff7c523e24da

osmo-bts-trx: trx_provision_fsm: do not send *_CNF events on failure

The trx_provision_fsm currently does not check the event data (rc),
causing failed operations (rc != 0) to be treated as successful
confirmations.  Avoid emitting *_CNF events when a command fails,
ensuring that only successful operations generate confirmation events.

Change-Id: Id85fb19c6621f55a9c46882df24bec534864a9dc

osmo-bts-trx: add missing \n to a logging message

Change-Id: I5b3091b5ed96e28ae056272398c5eddbdef4b8b5

doc: fix default 'max-initial' value

The default value is set in gsm_bts_trx_alloc() and it's actually 0.

Change-Id: I178e0664f6818d0eda15701b57bb030916b06006

osmo-bts-trx: apply 'max-initial' value before POWERON

Not applying this value before powering the transceiver on results
in transmission at full Tx power for a certain amount of time before
the power ramping begins.

Change-Id: Iff03d4dcb74f67629a59c8d6f8bb60929d9f6ddd
Related: OS#6939

Avoid accessing struct log_target members directly

Use newly available APIs instead.

Change-Id: Icd48874cf51d6af78305a30faeae48ba518e46b3
Depends: libosmocore.git Change-Id Ie48e7e635feb91509b9c034394df4fb16cb931a3

Avoid accessing struct log_target members directly

Use newly available APIs instead.

Change-Id: Icd48874cf51d6af78305a30faeae48ba518e46b3
Depends: libosmocore.git Change-Id Ie48e7e635feb91509b9c034394df4fb16cb931a3