To support the 3 possible preferences, the changes needed were:
- Replace 'full_rate' bool with a 3 option enum to represent
the channels types for signalling
- Switch from _pref/_alt to using an array sorted in preference
order
Originally merged as Change-Id I4c7499c8c866ea3ff7b1327edb3615d003d927d3,
reverted because the change broke voice calls. Re-submitting with the fix:
don't forget to set conn->assignment.requires_voice_stream.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I7513d2cbe8b695ba6f031ad11560c63a6535cf2d
osmo-mgw.git also includes fixes of the MGW endpoint FSM, for example
I92a9944acc96398acd6649f9c3c5badec5dd6dcc.
Depends: I9a3effd38e72841529df6c135c077116981dea36 (osmo-mgw)
Change-Id: I03e6b48d9b0a5370310d5f56809259ff7909cf9d
Move the T_defs API to libosmocore as osmo_tdefs: remove the local T_defs API
and use libosmocore's osmo_tdef* API instead.
The root reason is moving the mgw_endpoint_fsm to libosmo-mgcp-client to be
able to use it in osmo-msc for inter-MSC handover.
When adding osmo_tdef, the new concept of timer groups was added to the API. It
would make sense to apply group names here as well, but do not modify the VTY
configuration for timers. The future might bring separate groups (or not).
Depends: Ibd6b1ed7f1bd6e1f2e0fde53352055a4468f23e5 (libosmocore)
Change-Id: I66674a5d8403d820038762888c846bae10ceac58
This reverts commit 94c9324fe0.
Multiple ttcn3 handover tests were broken due to this commit. Let's
merge this once all the other commits pertaining to that fix can be
merged as well.
Fixes: OS#3942
Change-Id: I01d93778fb19c601c21f99ec4d2a3ab8a4a48f67
Move the HO_ST_WAIT_MGW_ENDPOINT_TO_MSC state up to right after the lchan is
done establishing. For AoIP, the local RTP address towards the MSC already
needs to be known before the Handover Request Acknowledge is sent, so the AoIP
Transport Layer Address IE can be included. This patch only modifies the
handover FSM, a subsequent patch adds the IE.
Change-Id: I4a5acdb2d4a0b947cc0c62067a67be88a3d467ff
During inter-BSC-incoming, the MSC sends the chosen encryption algorithm in the
Handover Request message. Actually parse this Chosen Encryption Algorithm IE.
Place the chosen algorithm and the CK into lchan_activate_info->encr so that
the new lchan will use the same ciphering on this new BSS as it did on the old
BSS.
Change-Id: I5b269f50bd2092516bfdf87746196983d3ac49d1
For intra-BSC handover, the previous encryption is copied from the old lchan,
which of course is not available during inter-BSC handover. Hence the lchan
activation info needs to include an explicit encryption information, and we
must not rely on the presence of the previous lchan to copy encryption
information from.
Add struct lchan_activate_info.encr to allow passing encryption info through
lchan_activate() without requiring a previous struct gsm_lchan to be present.
Instead of copying from the old lchan, always copy encryption info to
lchan_activate_info, and during activation, just before sending the Channel
Activation, copy the lchan_activate_info.encr to the new lchan.
This prepares for upcoming I5b269f50bd2092516bfdf87746196983d3ac49d1 which
obtains the encryption information from an intra-BSC-incoming Handover Request
message.
Related: OS#3842
Related: I5b269f50bd2092516bfdf87746196983d3ac49d1
Change-Id: Ib3d259a5711add65ab7298bfa3977855a17a1642
This commit breaks voice channel assignment. It results in the
Assignment Complete sent to the MSC for a voice lchan lacking
AoIP Transport Layer Address, Speech Version and Speech Codec.
Hence the MSC cannot complete the Assignment for a voice call.
Let's revisit this patch, test thoroughly and re-merge later.
This reverts commit 4d3a21269b.
Reason for revert: <INSERT REASONING HERE>
Change-Id: I72aaa03539919e7e85b5b75b133326cec5e68bc9
To support the 3 possible preferences, the changes needed were:
- Replace 'full_rate' bool with a 3 option enum to represent
the channels types for signalling
- Switch from _pref/_alt to using an array sorted in preference
order
Change-Id: I4c7499c8c866ea3ff7b1327edb3615d003d927d3
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
When a new lchan is selected during handover, some of the properties of
the old lchan are inherited by the new lchan. At the moment S15-S0 is
not not inherited so that the value for those bits will always be 0x0000
for the new lchan. Since those bits also define the active set AMR codec
the channel activation will fail because 0x0000 is invalid (active set
with zero rates)
Change-Id: Ifd470397e99985394634da1bb13ccfc5041984d2
Related: OS#3503
When the MSC allocates a channel through the ASSIGNMENT REQUEST, it may
ask for a TCH/H and a TCH/F at the same time and tell which of the two
types it prefers.
The process of channel allocation currently selects, based on the BTS,
MSC and MS capabilites exactly one apropriate codec/rate (e.g. TCH/H)
and then tries to allocate it. If that allocation fails, there is no way
to try the second choice and the assignment fails.
For example: The MSC asks for TCH/F and TCH/H, prefering TCH/F, then the
channel allocator will try TCH/F and if it fails (all TCH/F are
currently in use), then TCH/H is never tried.
Since the BSC currently only trys the first best codec/rate that is
supported it also ignores the preference.
Lets fix those problems by including the preference information and both
possible codec/rate settings into the channel allocation decision.
Change-Id: I5239e05c1cfbcb8af28f43373a58fa6c2d216c51
Related: OS#3503
handover_fsm.c accesses conn->assignment.req.s15_s0 to find out the current
lchan's AMR configuration. However, conn->assignment.* values are only valid
during an ongoing assignment. Those values may be overwritten by any failed
Assignment attempt, at any time, and hence do not reflect the currently
assigned conn->lchan. Those realms must be kept separate.
The assignment.req.s15_s0 get passed to lchan_activate(), so it makes most
sense to store these values in struct gsm_lchan once the lchan activation
succeeded.
Add gsm_lchan.s15_s0, store the s15_s0 received in lchan_activate_info during
lchan_activate().
In handover_fsm.c, use conn->lchan->s15_s0 instead of conn->assignment.*.
Change-Id: Id8018fd9d56421f2ab7be91703018f6d6f21c929
Fix crash after AMR configuration fails.
The crash is due to an assertion that finds a non-NULL conn in the lchan, when
re-using an lchan that has failed in AMR configuration earlier on. That is
because the AMR config still happens in state UNUSED.
DCHAN ERROR lchan(0-0-2-TCH_F_TCH_H_PDCH-0)[0x6120000066a0]{UNUSED}: (type=TCH_F) lchan allocation failed in state UNUSED: Can not generate multirate configuration IE
...
DCHAN DEBUG lchan(0-0-2-TCH_F_TCH_H_PDCH-0)[0x6120000066a0]{UNUSED}: (type=TCH_F) After failure handling, already in state UNUSED
...
...
DCHAN DEBUG lchan(0-0-2-TCH_F_TCH_H_PDCH-0)[0x6120000066a0]{UNUSED}: Received Event LCHAN_EV_ACTIVATE (lchan_fsm.c:324)
Assert failed !lchan->conn ../../../../src/osmo-bsc/src/osmo-bsc/lchan_fsm.c:491
The FSM design idea is that when returning to the UNUSED state, all lchan state
is cleared. However, when calling lchan_activate(), a failure may happen still
in state UNUSED, so that we don't transition *back* to UNUSED properly.
So, first transition out of UNUSED before failures can happen. (Other ways to
solve this would be to invoke lchan clearing even if already in UNUSED, but
semantically, transitioning first makes more sense.)
Upon LCHAN_EV_ACTIVATE, just remember the lchan_activate_info and transition to
WAIT_TS_READY, so that on lchan_fail(), we can normally transition back to
UNUSED and clear the lchan.
Move the initial lchan activation code to lchan_fsm_wait_ts_ready_onenter().
Also, there is a bit of duplication of members of the lchan->activate (lchan
state) and the lchan_activate_info (passed to lchan_activate()) structs. The
fix for this also removes the dup:
Add struct lchan_activate_info as child struct at lchan->activate.info, drop
the other lchan->activate members that would dup .info.*. Move struct
lchan_activate_info declaration to gsm_data.h.
Apply the new '.info' member struct throughout the code.
Related: OS#3737
Change-Id: Ide665b10fa3f4583059c55346db8da833959e3cc
When an internal handover is done the specification demands to inform
the MSC about the event.
- Add sending of BSSMAP HANDOVER PERFORMED msg.
Change-Id: If26e5807280e0f75a423b3b04f8e3c698c82a351
Depends: libosmocore I825106858bd89afc9837811b8fed2e8accc82441
Related: OS#3645
If an lchan is being released and had a SACCH active, there is no reason to
omit the Deact SACCH message ever. All of the callers that passed
do_deact_sacch = false did so for no good reason.
Drop the do_deact_sacch flag everywhere and, when the lchan type matches and
SAPI[0] is still active, simply always send a Deact SACCH message.
The do_deact_sacch flag was carried over from legacy code, by me, mainly
because I never really understood why it was there. I do hope I'm correct now,
asserting that having this flag makes no sense.
Change-Id: Id3301df059582da2377ef82feae554e94fa42035
After commit [1], the code makes sure to disassociate lchan and conn before
invoking the lchan release. However, we only send RR Release if a conn is
present, which clearly is nonsense after [1].
[1] commit 8b818a01b0
"subscr conn: properly forget lchan before release"
Change-Id: I4fd582b41ba4599af704d670af83651d2450b1db
Manage sending of RR Release via a flag, set during invoking lchan release.
Add do_rr_release arg to lchan_release(), gscon_release_lchans(). In
lchan_fsm.c, send RR Release only if do_rr_release was passed true; do not care
whether a conn is still associated (because it won't ever be since [1]).
That way we can intelligently decide what release process makes sense (whether
the lchan terminates the subscriber connection or whether the connection goes
on at another lchan), and still disassociate lchan and conn early.
BTW, this problem wasn't caught by the stock OsmoBSC TTCN3 tests, because the
f_expect_chan_rel() don't care whether an RR Release happens or not. This is
being fixed by Ibc64058f1e214bea585f4e8dcb66f3df8ead3845.
So far this patch should fix BSC_Tests_LCLS.TC_lcls_connect_clear.
Related: OS#3413
Change-Id: I666b3b4f45706d898d664d380bd0fd2b018be358
The chan mode is figured out per-BTS, but may remain uninitialized. Rather log
info about the channel request, like further above.
Change-Id: I07b89b6101879fb7c070c87be9bd38cc05ffa0b1
Inter-BSC outgoing lacked the required BSSMAP HO Failure dispatch.
Not all cases should send BSSMAP HO Failure, name the relevant spec paragraphs
in comments and adjust handling.
Related: osmo-ttcn3-hacks If772dbbc5f9790d3f911465e1303dd0a99811154
Change-Id: I0980cacb9713e41a1eef3a0a7f6cc892e8a20da5
Opposed to all other codecs that are common in GSM, AMR requires a codec
configuration that is expressed by a bitmask (S0 to S15) in the speech
codec list in the ASSIGNMENT REQUEST. Also the BSC acknowledges those
configuration in the ASSIGNMENT COMPLETE message.
At the moment osmo-bsc ignores all incoming configuration bits. The bits
in the ASSIGNMENT COMPLETE speech codec (choosen) field are hardcoded.
- Store the configuration bits while parsing the ASSIGNMENT COMPLETE
- Create an intersection with the configuration that is actually
supported by the BSS
- Return the resulting (chosen) configuration bits with the assignment
complete message.
- Use the (highest of the) agreed codec rates in RSL channel activation.
Change-Id: I2d8ded51b3eb4c003fe2da6f2d6f48d001b73737
Related: OS#3529
Before, this would ignore the failure and hit a timeout instead. Rather handle
the event directly.
Change-Id: I21c43d2907d0413ef18ec43cf27f680ebecf9e82
Drop nonsensical legacy code.
The Circuit Identifier Code in A/SCCPlite does *not* indicate the RTP port to
use. Rather, it indicates the MGW endpoint name to use when configuring the
BSC's side of the MGW endpoint, and only the MGW will ever know the RTP port.
Change-Id: I471bd5e5cc2a083dd37290aeaae5c334ca5f7eed
3GPP mandates either Classmark Information 1 or 2 in BSSMAP Handover Request,
but an SCCPlite MSC currently tested does not pass either of them. Make this
missing IE a non-fatal error, continuing anyway should work out.
See 3GPP TS 48.008, 3.2.1.8 HANDOVER REQUEST, where it says "Classmark
Information 1 or Classmark Information 2" with note 6: "One of these two
elements is sent."
Change-Id: I34d64b028210b4df8652fee1a8830ec4a4e3ac11
When building with -Werror=format-security, such as our OBS builds,
it fails like this:
[ 118s] handover_fsm.c: In function 'parse_ho_request':
[ 118s] handover_fsm.c:478:4: error: format not a string literal and no format arguments [-Werror=format-security]
[ 118s] gsm0808_cell_id_name(&req->cell_id_serving));
[ 118s] ^~~~~~~~~~~~~~~~~~~~
[ 118s] handover_fsm.c:489:4: error: format not a string literal and no format arguments [-Werror=format-security]
[ 118s] gsm0808_cell_id_name(&req->cell_id_target));
[ 118s] ^~~~~~~~~~~~~~~~~~~~
[ 120s] cc1: some warnings being treated as errors
Let's make sure we don't call sprintf() and friends without a format
string. In fact, if we only want to copy a string without extra
formatting, use osmo_strlcpy() or OSMO_STRLCPY_ARRAY().
Change-Id: I56cff3618f012f6b019f4fca7e2768814487137a
In various FSMs, some events may appear later or earlier without need of
action. Do not indicate these as 'ERROR' (event not permitted), but allow and
ignore them.
Debug-log about some of those.
From the old code, we've taken over the habit to change into
WAIT_BEFORE_RF_RELEASE even before SAPI[0] is released. Hence we may still
receive a SAPI[0] REL_IND in WAIT_BEFORE_RF_RELEASE. Don't show this as error
message, just silently accept it.
Change-Id: Ie320c7c6a1436184aaf2ec5a1843e04f4b3414ab
Add FSMs:
- timeslot_fsm: handle dynamic timeslots and OML+RSL availability.
- lchan_fsm: handle an individual lchan activation, RTP stream and release,
signal the appropriate calling FSMs on success, failure, release.
- mgw_endpoint_fsm: handle one entire endpoint with several CI.
- assignment_fsm: BSSMAP Assignment Request.
- handover_fsm: all of intra, inter-MO and inter-MT handover.
Above FSMs absorb large parts of the gscon FSM. The gscon FSM was surpassing
the maximum amount events (32), and it is more logical to treat assignment,
handover and MGW procedures in separate FSMs.
- Add logging macros for each FSM type:
- LOG_TS()
- LOG_LCHAN()
- LOG_MGWEP(), LOG_CI()
- LOG_ASSIGNMENT()
- LOG_HO()
These log with the osmo_fsm_inst where present.
New style decision: logging without a final newline char is awkward,
especially for gsmtap logging and when other logs interleave LOGPC() calls;
we have various cases where the final \n goes missing, and also this invokes
the log category checking N times instead of once.
So I decided to make these macros *always* append a newline, but only if
there is no final newline yet. I hope that the compiler optimizes the
strlen() of the constant format strings away. Thus I can log with or without
typing "\n" and always get an \n termination anyway.
General:
- replace osmo_timers, state enums and program-wide osmo_signal_dispatch()
with dedicated FSM timeouts, states and events.
- introduce a common way to handle Tnnn timers: gsm_timers.h/.c: struct T_def.
These can be used (with some macro magic) to define a state's timeout once,
and not make mistakes for each osmo_fsm_inst_state_chg().
Details:
bsc_subscr_conn_fsm.c:
- move most states of this FSM to lchan_fsm, assignment_fsm, handover_fsm and
mgw_endpoint_fsm.
- There is exactly one state for an ongoing Assignment, with all details
handled in conn->assignment.fi. The state relies on the assignment_fsm's
timeout.
- There is one state for an ongoing Handover; except for an incoming Handover
from a remote BSS, the gscon remains in ST_INIT until the new lchan and conn
are both established.
- move bssmap_add_lcls_status() to osmo_bsc_lcls.c
abis_rsl.c:
- move all dynamic timeslot logic away into timeslot_fsm. Only keep plain send/receive functions in
abis_rsl.c
- reduce some rsl functions to merely send a message, rename to "_tx_".
- rsl_ipacc_mdcx(): add '_tx_' in the name; move parts that change the lchan state out into the
lchan_fsm, the lchan->abis_ip.* are now set there prior to invoking this function.
- move all timers and error/release handling away into various FSMs.
- tweak ipa_smod_s_for_lchan() and ipa_rtp_pt_for_lchan() to not require an
lchan passed, but just mode,type that they require. Rename to
ipacc_speech_mode*() and ipacc_payload_type().
- add rsl_forward_layer3_info, used for inter-BSC HO MO, to just send the RR
message received during BSSMAP Handover Command.
- move various logging to LOG_LCHAN() in order to log with the lchan FSM instance.
One drawback is that the lchan FSM is limited to one logging category, i.e. this moves some logging
from DRR to DRSL. It might actually make sense to combine those categories.
- lose LOGP...LOGPC logging cascades: they are bad for gsmtap logging and for performance.
- handle_classmark_chg(): change logging, move cm2 len check out of the cm3 condition (I hope that's
correct).
- gsm48_send_ho_cmd(): split off gsm48_make_ho_cmd() which doesn't send right away, so that during
inter-bsc HO we can make an RR Handover Command to send via the MSC to the remote BSS.
assignment_fsm.c:
- the Chan Mode Modify in case of re-using the same lchan is not implemented
yet, because this was also missing in the previous implementation (OS#3357).
osmo_bsc_api.c:
- simplify bsc_mr_config() and move to lchan_fsm.c, the only caller; rename to
lchan_mr_config(). (bsc_mr_config() used to copy the values to mr_bts_lv
twice, once by member assignment and then again with a memcpy.)
- During handover, we used to copy the MR config from the old lchan. Since we
may handover between FR and HR, rather set the MR Config anew every time, so
that FR rates are always available on FR lchans, and never on HR lchans.
Depends: I03ee7ce840ecfa0b6a33358e7385528aabd4873f (libosmocore),
I1f2918418c38918c5ac70acaa51a47adfca12b5e (libosmocore)
Change-Id: I82e3f918295daa83274a4cf803f046979f284366
Sylvain Munaut
Neels Hofmeyr
Daniel Willmann
Neels Hofmeyr
Philipp Maier
Harald Welte