aboutsummaryrefslogtreecommitdiffstats
path: root/src/osmo-bsc/lchan_rtp_fsm.c
AgeCommit message (Collapse)AuthorFilesLines
2019-04-30move mgw endpoint FSM to osmo-mgw.gitNeels Hofmeyr1-15/+99
osmo-mgw.git also includes fixes of the MGW endpoint FSM, for example I92a9944acc96398acd6649f9c3c5badec5dd6dcc. Depends: I9a3effd38e72841529df6c135c077116981dea36 (osmo-mgw) Change-Id: I03e6b48d9b0a5370310d5f56809259ff7909cf9d
2019-04-23use libosmocore osmo_tdefNeels Hofmeyr1-6/+5
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
2019-01-16Log MDCX ACK for established lchanMax1-1/+8
Previously LCHAN_RTP_EV_IPACC_MDCX_ACK was not permitted for LCHAN_RTP_ST_ESTABLISHED state in lchan FSM. However this message is normal in case of LCLS loop closed via IPA (as opposed to MGCP). Let's permit this message and log it to make debug output easier to read. Change-Id: Ib642df799f3405c4d707eb57b2ebc84386d7f03f Related: OS#2487
2018-12-21make sure early lchan act failure resets the lchanNeels Hofmeyr1-13/+13
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
2018-12-05bsc: lchan_rtp_fsm: Avoid duplicate LCHAN_EV_RTP_RELEASED eventPau Espin Pedrol1-1/+5
When lchan_rtp_fsm instance is allcoated with osmo_fsm_inst_alloc_child(..., LCHAN_EV_RTP_RELEASED) we already let fsm code to take care of sending that event ito the parent when the fsm is terminated (but only if freeing cause is not OSMO_FSM_TERM_PARENT). The lchan_rtp_fsm cleanup() callback, which is called immediatelly before sending to the parent the event defined during osmo_gsm_install_alloc_child(), currently also sends that same event, which ends up in a duplicated event being sent as shown in log files below. Let's only send the event in cleanup() if we are in the cause=OSMO_FSM_TERM_PARENT scenario, to make sure parent always receives the event, but only once. 20181128193707326 DAS osmo-bsc/assignment_fsm.c:127 assignment(conn4_0-0-6-TCH_F_PDCHasPDCH-0)[0x6120000024a0]{WAIT_LCHAN_ACTIVE}: (bts=0,trx=0,ts=6,ss=0) Assignment failed 20181128193707326 DAS osmo-bsc/assignment_fsm.c:128 assignment(conn4_0-0-6-TCH_F_PDCHasPDCH-0)[0x6120000024a0]{WAIT_LCHAN_ACTIVE}: Terminating (cause = OSMO_FSM_TERM_ERROR) 20181128193707326 DAS osmo-bsc/assignment_fsm.c:128 assignment(conn4_0-0-6-TCH_F_PDCHasPDCH-0)[0x6120000024a0]{WAIT_LCHAN_ACTIVE}: Removing from parent SUBSCR_CONN(conn4)[0x612000002920] 20181128193707326 DCHAN osmo-bsc/lchan_fsm.c:1333 lchan_rtp(0-0-6-TCH_F_PDCH-0)[0x612000002320]{WAIT_MGW_ENDPOINT_AVAILABLE}: Received Event LCHAN_RTP_EV_ROLLBACK 20181128193707326 DCHAN osmo-bsc/lchan_rtp_fsm.c:193 lchan_rtp(0-0-6-TCH_F_PDCH-0)[0x612000002320]{WAIT_MGW_ENDPOINT_AVAILABLE}: Terminating (cause = OSMO_FSM_TERM_REQUEST) 20181128193707326 DCHAN osmo-bsc/lchan_rtp_fsm.c:193 lchan_rtp(0-0-6-TCH_F_PDCH-0)[0x612000002320]{WAIT_MGW_ENDPOINT_AVAILABLE}: Removing from parent lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0] 20181128193707326 DRSL osmo-bsc/mgw_endpoint_fsm.c:441 mgw-endpoint(conn4)[0x6120000021a0]{WAIT_MGW_RESPONSE}: (rtpbridge/*@mgw) CI[0] to-BTS: DLCX :0: notify=NULL 20181128193707326 DRSL osmo-bsc/mgw_endpoint_fsm.c:482 mgw-endpoint(conn4)[0x6120000021a0]{WAIT_MGW_RESPONSE}: (rtpbridge/*@mgw) CI[0] to-BTS: DLCX :0: Scheduling 20181128193707326 DCHAN osmo-bsc/lchan_rtp_fsm.c:742 lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0]{WAIT_TS_READY}: Received Event LCHAN_EV_RTP_RELEASED 20181128193707326 DCHAN osmo-bsc/lchan_rtp_fsm.c:193 lchan_rtp(0-0-6-TCH_F_PDCH-0)[0x612000002320]{WAIT_MGW_ENDPOINT_AVAILABLE}: Freeing instance 20181128193707327 DCHAN fsm.c:381 lchan_rtp(0-0-6-TCH_F_PDCH-0)[0x612000002320]{WAIT_MGW_ENDPOINT_AVAILABLE}: Deallocated 20181128193707327 DCHAN osmo-bsc/lchan_rtp_fsm.c:193 lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0]{WAIT_TS_READY}: Received Event LCHAN_EV_RTP_RELEASED 20181128193707330 DCHAN osmo-bsc/lchan_fsm.c:1347 lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0]{WAIT_TS_READY}: transition to state WAIT_RLL_RTP_RELEASED not permitted! 20181128193707330 DAS osmo-bsc/assignment_fsm.c:128 assignment(conn4_0-0-6-TCH_F_PDCHasPDCH-0)[0x6120000024a0]{WAIT_LCHAN_ACTIVE}: Freeing instance 20181128193707330 DAS fsm.c:381 assignment(conn4_0-0-6-TCH_F_PDCHasPDCH-0)[0x6120000024a0]{WAIT_LCHAN_ACTIVE}: Deallocated Change-Id: I3e95a21e5a5ec6c35b1ab20b7a642fd7eb81e556
2018-11-14lchan: set cause for 4 instances of release_in_error = trueNeels Hofmeyr1-0/+1
Make sure some RSL cause is set. Change-Id: I372ade9fc58919fbf858ce14caab8a0a22dbb083
2018-11-14cosmetic: lchan: introduce sub-struct lchan->release.*Neels Hofmeyr1-4/+4
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
2018-08-29log: lchan_rtp_fsm: add missing '\n'Neels Hofmeyr1-4/+4
Change-Id: Ifa46295ef23cf3728bc946fe27b34f0607a24c9e
2018-08-25MGCP: add 'X-Osmo-IGN: C' for SCCPlite by defaultNeels Hofmeyr1-1/+5
Use libosmo-mgcp-client's new X-Osmo-IGN header to indicate that CallIDs are allowed to mismatch. Add VTY commands 'msc' / 'mgw x-osmo-ign call-id' and 'no mgw x-osmo-ign' to switch this behavior explicitly. For SCCPlite MSCs, unless a specific config was issued, always send 'X-Osmo-IGN: C' by default, to ignore CallID mismatches. Depends: Id7ae275ffde8ea9389270cfe3db087ee8db00b51 (osmo-mgw) Change-Id: I257ad574d8060fef19afce9798bd8a5a7f8c99fe
2018-08-22fix lchan_rtp_fsm: missing event handlingNeels Hofmeyr1-0/+13
Release and Rollback events are allowed but unhandled in states WAIT_MGW_CONFIGURED and ROLLBACK, and hence would result in an assertion. Add handling in these states. Change-Id: Iab233c592384902098644eee27bb8445fde3aa6f
2018-08-01gscon: use BSS-common payload types on BSS sidePhilipp Maier1-2/+2
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
2018-07-28create separate logging categories for lchan,ts,as FSMsNeels Hofmeyr1-1/+1
Change-Id: Ie889b8860a4a63c7c22ef65025f690d64cd7330c
2018-07-28lchan_fsm: split off lchan_rtp_fsm, establish RTP a bit earlierNeels Hofmeyr1-0/+743
Change-Id: Id7a4407d9b63be05ce63f5f2768b7d7e3d5c86fb
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-19 21:16:37 +0000