In various places that receive an error cause from RSL and place it in
lchan.release.rsl_error_cause, translate it to an RR cause and place that in
the recently added lchan.release.rr_cause. Hence the RR Channel Release message
now reflects more specific error causes when the reason for the error was
received in an RSL message's cause value.
Change-Id: I46eb12c91a8c08162b43dd22c7ba825ef3bbc6ac
In lchan.release, add 'cause_rr', and set RR Channel Release message's cause
value to lchan.release.cause_rr.
In lchan_release(), do not set lchan.release.rsl_error_cause to the RR cause
value, these are unrelated. Store in new lchan.release.cause_rr instead. The
rsl_error_cause is apparently only used for logging, except for one place in
lchan_fsm_wait_activ_ack() that compares it to RSL_ERR_RCH_ALR_ACTV_ALLOC, so
there should not be a functional difference by this fix.
Propagate the BSSMAP Clear Command cause to the RR Channel Release:
Add struct gscon_clear_cmd_data as event data for GSCON_EV_A_CLEAR_CMD -- so
far it sent the is_csfb flag, add the gsm0808_cause; invoking the event happens
in bssmap_handle_clear_cmd().
Adjust event handling in gscon_fsm_allstate(); there, pass the cause to
gscon_release_lchans(). In gscon_release_lchans(), pass the cause to
gscon_release_lchan(), and then lchan_release(), which sets the new
lchan.release.cause_rr to the passed cause value.
As soon as the lchan FSM enters the proper state, it calls
gsm48_send_rr_release(). There, set the cause value in the encoded message to
lchan.release.cause_rr.
Interworking with osmo-msc: so far, osmo-msc fails to set the Clear Command
cause code for normal release, it just passes 0 which amounts to
GSM0808_CAUSE_RADIO_INTERFACE_MESSAGE_FAILURE. Before this patch, osmo-bsc
always sent GSM48_RR_CAUSE_NORMAL in the RR Channel Release, and after this
patch it will receive 0 == GSM0808_CAUSE_RADIO_INTERFACE_MESSAGE_FAILURE from
osmo-msc and more accurately translate that to GSM48_RR_CAUSE_PROT_ERROR_UNSPC.
This means in practice that we will now see an error cause in RR Channel
Release instead of GSM48_RR_CAUSE_NORMAL when working with osmo-msc. For
changing osmo-msc to send GSM0808_CAUSE_CALL_CONTROL instead (which translates
to GSM48_RR_CAUSE_NORMAL), see OS#4664 and change-id
I1347ed72ae7d7ea73a557b866e764819c5ef8c42 (osmo-msc).
A test for this is in Ie6c99f28b610a67f2d59ec00b3541940e882251b
(osmo-ttcn3-hacks).
Related: SYS#4872
Change-Id: I734cc55c501d61bbdadee81a223b26f9df57f959
conn->fi might be NULL and thus can't be safely dereferenced.
E.g. we're checking if it's NULL or not just a few lines above. so we
should here as well.
Here is a backtrace for the crash:
(gdb) bt
0 0x000055b948002772 in gscon_forget_lchan (conn=0x55b949c6b870, lchan=lchan@entry=0x7f00ae9ade68) at bsc_subscr_conn_fsm.c:718
1 0x000055b948036c84 in lchan_fsm_wait_rf_release_ack_onenter (fi=<optimized out>, prev_state=<optimized out>) at lchan_fsm.c:1040
2 0x00007f00afc6a599 in state_chg (fi=fi@entry=0x55b949bcfe10, new_state=new_state@entry=8, keep_timer=keep_timer@entry=false, timeout_ms=2000, T=3111, file=<optimized out>, line=1344) at fsm.c:699
3 0x00007f00afc6aa5d in _osmo_fsm_inst_state_chg (fi=fi@entry=0x55b949bcfe10, new_state=new_state@entry=8, timeout_secs=<optimized out>, T=<optimized out>, file=<optimized out>, line=<optimized out>)
at fsm.c:748
4 0x00007f00afc78e62 in _osmo_tdef_fsm_inst_state_chg (fi=fi@entry=0x55b949bcfe10, state=state@entry=8, timeouts_array=timeouts_array@entry=0x55b9482b56a0 <lchan_fsm_timeouts>, tdefs=<optimized out>,
default_timeout=140730455622800, default_timeout@entry=5, file=file@entry=0x55b948079d39 "lchan_fsm.c", line=1344) at tdef.c:346
5 0x000055b9480341eb in lchan_fsm_timer_cb (fi=0x55b949bcfe10) at lchan_fsm.c:1344
6 0x00007f00afc6b84a in fsm_tmr_cb (data=0x55b949bcfe10) at fsm.c:325
7 0x00007f00afc65926 in osmo_timers_update () at timer.c:257
8 0x00007f00afc65cda in _osmo_select_main (polling=0) at select.c:260
9 0x00007f00afc66526 in osmo_select_main_ctx (polling=<optimized out>) at select.c:291
10 0x000055b947fdcadf in main (argc=<optimized out>, argv=<optimized out>) at osmo_bsc_main.c:953
(gdb) p conn->fi
$1 = (struct osmo_fsm_inst *) 0x0
Change-Id: I2427266ef4660935cde899462fa6df8d785c420e
We already have counters for Rx side, now we also count Tx side.
See comments in the msc_ctr_description array implementation for
the details.
Change-Id: I89a173f6bdd9a3c21233fe01d07ab2ff0442bb10
TTCN3 BSC_Tests.TC_ms_rel_ind_does_not_cause_bssmap_reset seems to
sometimes run into a race condition on the order of messages received by
osmo-bsc comming from MSC and BTS.
Usual (expected) scenario):
BTS->BSC EST IND
BSC->MSC CL3 Info
BSC<-MSC CC
BTS->BSC REL IND
BTS<-BSC DEACT SACCH
BSC->MSC ClearRequest
BSC<-MSC ClearCommand
BSC->MSC ClearComplete
BTS<-BSC RF Chan Release
BTS->BSC RF Chan Release ACK
Sometimes CC message and REL IND message are received swapped (because they
are sent by different components asynchronously in TTCN3).
As a result, osmo-bsc was failing to go into CLEARING state and was
unable to send the ClearRequest because CC was still not received.
So the idea is to stay in WAIT_CC until CC is received, then check if
the lchan was dropped and in that case go into clearing state.
Change-Id: Id1abf5ee44c60925b478123409f26bd29006202b
If a handover fails when the new lchan is already fully established, osmo-bsc
so far caused two BSSMAP Clear Requests to be sent out to the MSC: one caused
by detaching the lchan from the gscon, one from returning the gscon back to
ST_ACTIVE, which detects that no lchan is present and Clears. In fact only one
of those is necessary.
Checking for the presence of an lchan when entering ST_ACTIVE is an earlier
attempt to catch insane situations. Since then, osmo-bsc has acquired other
logic that will ensure sending a Clear Request in all cases, see
gscon_forget_lchan(). Sending another BSSMAP Clear Request in ST_ACTIVE's
onenter is simply not necessary. Drop gscon_fsm_active_onenter() entirely.
Note: the double Clear Request is currently hit by
TC_ho_out_fail_no_ho_detect(), which currently fails and will pass again after
this patch; however, osmo-bsc should actually not release the lchan at all
during this test, see OS#4093. In other words, osmo-bsc behavior for this
scenario as well as TC_ho_out_fail_no_ho_detect() need to be changed, and the
test will, once fixed, not be useful to trigger this issue anymore.
Related: OS#4078
Change-Id: Iac1519eb8b24e8523caec682f9ac8e6dcf1327ce
Having the helper makes it easier to read/find for transport type checks. It
will be ifurther re-used in forthcoming commits.
Change-Id: Ic0ee4c472e29ec3092049e5e23b744395613616d
The Osmux CID obtained from the MSC is passed to the co-located BSC MGW
to configure the MSC-side MGW conn of a call leg.
Depends on: osmo-mgw.git I73b4c62baf39050da81d65553cbea07bc51163de
Change-Id: I86e7e13fc7921e3209fb764c0e7797e7ec09b79e
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
With the FORGET_MGW_ENDPOINT event, the MGW endpoint FSM notifies the gscon
that it has deallocated and that hence the gscon should forget all references
to it (to avoid a use-after-free).
Also do this for the endpoint FSM and endpoint ci pointers in the conn->ho.*
sub struct.
I saw a use-after-free after a Handover Failure message tears down the lchan
and MGW endpoint before triggering the handover_fsm.c cleanup code, which also
tries to clean up an endpoint CI if it was created for the failed Handover.
Change-Id: I6702ccd0df44bea5eb8b26d471d7903c24e6e30b
When the MSC sends a BSSMAP CLEAR CMD containing a CSFB Indication IE,
it lets us know that the to-be-released connection related to a CSFB
call.
We as the BSC then subsequently should include the "Cell Selection
Indicator after release of all TCH and SDCCH" IE in the RR RELEASE
message sent to the MS/UE. This IE contains the LTE neighbor cells
that we're configured to broadcast in si2quater.
That in turn will make sure the MS/UE can return very quickly to
the LTE cell.
Closes: OS#3777
Change-Id: Ibfbb87e2e16b05032ad1cb91c11fad1b2f76d755
Requires: libosmocore Id4bd7f7543f5b0f4f6f876e283bd065039c37646
Requires: libosmocore I0e101af316438b56d63d43fc2cb16d7caf563d07
Requires: libosmocore I8980a6b6d1973b67a2d9ad411c878d956fb428d1
Rationale: reading pcaps becomes so much easier when each of osmo-bsc and
osmo-msc address their MGW with differing domain names. Otherwise, both will
have a '0@mgw' endpoint and it gets really confusing.
After this, with according configuration, there can be a '0@bsc' and a '0@msc'
endpoint.
osmo-mgw-for-bsc.cfg:
mgcp
domain bsc
osmo-bsc.cfg:
msc 0
mgw endpoint-domain bsc
Depends: Ia662016f29dd8727d9c4626d726729641e21e1f8 (osmo-mgw)
Change-Id: I492023e9dca0233ec0a077032455d9f2e3880f78
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
* use osmo_lcls struct from libosmocore
* use enum values instead of magic numbers
Change-Id: I5e962d4fbb24bf1fb2398dc13e142a4a3304d858
Related: OS#3659
Currently, we see all subscribers' FSM transitions on NOTICE level even though
the code uses LOGPFSML(LOGL_DEBUG), because LOGPFSML() uses the max loglevel of
the passed level and the FSM instance's level. Too noisy!
By default, start out all gscon FSM instances on DEBUG level, so it is possible
to silence the osmo-bsc log. Individual instances can still be lifted (I
presume using the CTRL interface?).
Change-Id: Ie021483e93ab174abac51357bcca8895756566c4
When a gscon wants to send a BSSMAP Clear Request, it makes no sense to do it
conditionally depending on the current conn state. Just send it: don't call
gscon_sigtran_send(), directly go for osmo_bsc_sigtran_send().
In particular, if an incoming inter-BSC handover ends in failure, the gscon
state is still ST_INIT, but if the MSC fails to give us a Clear Command, we may
want to ask with a BSSMAP Clear Request.
Change-Id: I39fae24260a4bb7a6af704ebe760f93fff566536
conn->fi should actually never be NULL, they are allocated and discarded
simultaneously. So check its null from the start and remove some conditions
below, to remove the coverity warning.
Related: CID 189671
Change-Id: I62354aa998832131c86535f39a29294000114adc
Put all lchan release related flags and settings in a sub-struct named
'release' to better indicate what those fields are for. There is no functional
change.
Change-Id: Icfddc6010e5d7c309f1a7ed3526b5b635ffeaf11
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
When reading the log of OS#3686, I wished for explicit logging of when exactly
an lchan disassociates from a conn. Here is the debug logging I would have
liked to see.
I'm not sure whether we really need to merge this patch...
Change-Id: I97558b899e7f2578ba98287e7352dc072d02ce44
Clear all lchan->conn pointers when the subscr conn code is choosing to release
an lchan, with gscon_release_lchan().
Rationale: when an lchan releases in error, it should trigger the conn to be
notified and cause a BSSMAP Clear. However, if the conn is actively requesting
for an lchan release, it is already taking care of the situation.
Related: osmo-ttcn3-hacks If772dbbc5f9790d3f911465e1303dd0a99811154
Change-Id: I4fd582b41ba4599af704d670af83651d2450b1db
Send a BSSMAP Clear Request only if absolutely no lchan remains associated to
the conn, anywhere (Assignment, Handover as well as primary lchan).
Conceivable would be a situation where e.g. we're in handover and a new lchan
is ready, when just at a time where it doesn't matter anymore the old lchan
fails. We could just carry on with the new one then.
Change-Id: Ibd8e38ccf7759b8834efdedf742c46c227b26e91
Send a BSSMAP Clear Request only if we are not already in ST_CLEARING, i.e.
haven't received a BSSMAP Clear Command yet.
Related: osmo-ttcn3-hacks If772dbbc5f9790d3f911465e1303dd0a99811154
Change-Id: Idc749068580da45e821e0af04cfa14cc7ce5c432
The API of a_reset.c is currently called with a pointer to struct
reset_ctx. This puts the responsibility of checking the presence of
msc->a.reset_fsm to the caller. It would be much more effective if the
caller would check if msc->a.reset_fsm before dereferencing it.
This also fixes at least one segfault that ocurrs when gscon_timer_cb()
is called but no sccp connection is present yet. Therefore the pointer
to bsc_msc_data would not be populated. This is now detected by
a_reset.c itsself.
- minor code cleanups
- call a_reset.c functions with msc (struct bsc_msc_data)
Change-Id: I0802aaadf0af4e58e41c98999e8c6823838adb61
Related: OS#3447
In cases where a codec has no fixed (IANA) payload type number, a
dynamically coosen payload type number is used. For the route between
BSC and MSC 3GPP as designated certain payload type numbers. However,
beond that, those payload type numbers may not necessarly apply. The
RTP communication between BTS and BSC still might run on a completely
different payload type number.
libosmo-netif contains a header file which payload type numbers
shall be used. Lets use those in order to signal the same payload type
numbers as we actually use in the RTP packets to the MGW.
Change-Id: I507a1b1446c8f140b2950d73cf737797604c1ac3
Related: OS#2728
Related: OS#3384
I often see "ERROR [ST_CLEARING] Entering ST_CLEARING not permitted!", avoid
the bogus error messages by checking entering ST_CLEARING only if not in it
yet. Still don't allow re-entering, to not restart the timeout.
Change-Id: Ia1f171c08dcbc529f907a20eed43bf5ee3a452b3
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
In certain situations like handover or assignment, DTAP must not go out via RSL
directly but is cached to be submitted later. Make sure that all RSL DTAP
sending adheres to this:
gscon_submit_rsl_dtap() is the new "public" API to request an RSL DTAP to be
sent. Depending on the gscon's state, this ends up in the cache or is sent
directly. When caching, there is no way to tell whether sending will succeed or
not, so semantically it does not make sense to even return a result code. Just
return void. Change all "public" callers to gscon_submit_rsl_dtap().
Merge gsm0808_submit_dtap() and submit_dtap() guts to gsm0808_send_rsl_dtap(),
static in bsc_subscr_conn_fsm.c: directly send DTAP, assume a conn->lchan to be
present, or otherwise trigger a BSSMAP Clear Request.
The static submit_dtap() becomes a thin convenience wrapper.
Move ho_dtap_cache* functions to bsc_subscr_conn_fsm.c and rename to
gscon_dtap_cache_* -- they are not only for handover, also for assignment.
Function gsm0808_submit_dtap() m
Introduce function gscon_submit_rsl_dtap()
Change-Id: I6ffd7aa641c8905292c769400048c96aa0949585
While GSCON is setting the codec info when operating on the MGW, LCLS
is not doing that yet. This means that the MDCX messages that are
sent by LCLS do not contain any payload type and also no ptime or
rtpmap fields. This also causes the following TTCN3 tests to fail:
TC_lcls_connect_break
TC_lcls_connect_clear
TC_lcls_gcr_bway_connect
TC_lcls_gcr_bway_dont_connect_csc
- Make mgcp_pick_codec() public as bsc_subscr_pick_codec()
- use bsc_subscr_pick_codec() to set codec info in osmo_bsc_lcls.c
Change-Id: I383d55fa602cda0926dd701ee517a299db578260
Closes: OS#3358
The GSCON FSM does not care about the codec information when performing
interactions with the MGW. Before upgrading the client the codec
information was hardcoded to AMR inside the client. Now the client
offers APIs to set the codec information. Since this feature is new,
osmo-bsc does not set any codec information yet, which causes many of
the TTCN3 tests to fail. So lets add some logic to pick suitable codec
info.
- Hardcode ptime to 20 (is the same for all possible codecs)
- Select a codec according to the flags in userplane
Change-Id: Ibddc3492572b39f166e3a1b8b8120813ce2dadc2
Related: OS#2728
3GPP TS 48.006 section 9.2 states clearly that any SCCP connection
release must be initiated by the MSC.
for bsc_subscr_conn_fsm, this means that even after sending the
BSSMAP CLEAR COMPLETE, we must not terminate the FSM, as this would
cause a N-DISCONNET.req to be sent to the stack for the associated
SCCP connection.
The bsc_subscr_conn_fsm instances will hence stay alive until the MSC
eventually decises to release them.
Change-Id: Iaaca220b598609b77b600fcfc2f9a78b221c1fbb
Closes: OS#3331
Do not invoke OSMO_STRINGIFY() with arbitrary names, just quote instead.
The idea was that OSMO_STRINGIFY() avoids typos by ensuring well-defined names
are stringified, but this highlights that OSMO_STRINGIFY() is in fact usable
with completely arbitrary arguments and actually lacks the validation part :/
Change-Id: I458cd2cd0d6ddb0e6db3bb8d546a20336ae8c5f1
Keep the bsc_subscr associated with the conn as long as possible, to benefit
logging, which then contains the subscriber identity (if any).
Change-Id: Ifa528b58842a02509bfe0af6915c64bd67058bcd
The guts of bssap_speech_from_lchan() and lchan_to_chosen_channel() have been
moved to libosmocore; call those instead.
The return value of bssap_speech_from_lchan() used to be -1 on error, now the
error value is 0. The only caller did not handle -1 properly, but fed it
directly to a uint8_t.
On gsm0808_chosen_channel() error, log the error. Proper handling is missing.
Fixing the error handling in send_ass_compl() is a separate issue: currently it
is limited to logging, there is no way to return an error yet, nor any actions
to take on error.
Depends: Icca23940791f97fa64dbc3f2734270b99f9550c1 (libosmocore)
Change-Id: Ib5c940a9dae11c5e26d4b47fa9d95fef889ad2f6
Move all of libbsc/ into osmo-bsc/, and separate/move some implementations to
allow linking from utils/* and ipaccess/* without pulling in unccessary
dependencies.
Some utilities use gsm_network and gsm_bts structs, which already include data
structures for fairly advanced uses. Move initialization that only osmo-bsc
needs into new bsc_network_init() and bsc_bts_alloc_register() functions, so
that the leaner tools can use the old gsm_* versions without the need to link
everything (e.g. handover and lchan alloc code).
In some instances, there need to be stubs if to cut off linking "just before
the RSL level" and prevent dependencies from creeping in.
- abis_rsl_rcvmsg(): the only program currently interpreting RSL messages is
osmo-bsc, the utils are merely concerned with OML, if at all.
- paging_flush_bts(): ip.access nanobts models call this when the RSL link is
dropped. Only osmo-bsc actually needs to do anything there.
- on_gsm_ts_init(): the mechanism to trigger timeslot initialization is related
to OML, while this action to take on init would pull in RSL dependencies.
utils/ and ipaccess/ each have a stubs.c file to implement these stubs. Tests
implement stubs inline where required.
From src/utils/, src/ipaccess/ and tests/*/, link in .o files from osmo-bsc/.
In order for this to work, the osmo-bsc subdir must be built before the other
source trees. (An alternative would be to include the .c files as sources, but
that would re-compile them in every source tree. Not a large burden really, but
unless linking .o files gives problems, let's have the quicker build.)
Minor obvious cleanups creep in with this patch, I will not bother to name them
individually now unless code review asks me to.
Rationale:
1) libbsc has been separate to use it for osmo-nitb and osmo-bsc in the old
openbsc.git. This is no longer required, and spreading over libbsc and osmo-bsc
is distracting.
2) Recently, ridiculous linking requirements have made adding new functions
cumbersome, because libbsc has started depending on osmo-bsc/*.c
implementations: on gscon FSM and bssap functions. For example, neither
bs11_config nor ipaccess-config nor bts_test need handover_cfg or BSSMAP
message composition. It makes no sense to link the entire osmo-bsc to it, nor
do we want to keep adding stubs to each linking realm.
Change-Id: I36a586726f5818121abe54d25654819fc451d3bf
Pau Espin
Neels Hofmeyr
Martin Hauke
Harald Welte
Philipp Maier