GAPK I/O is currently generating too many UL voice frames, causing
Tx queue overflow in the L1 PHY. Change the logic to make DL voice
frames drive the Uplink processing chain, like we do for CSD.
Change-Id: I3a7fa223cb592acd5b850819e0682c9c8f81e9d1
Now that we support data (CSD) calls in addition to voice calls,
we can no longer initialize the TRAFFIC.{ind,req} routing mode
in gsm48_rr_init(). We need to apply the appropriate TCH routing
mode *during call establishment* based on its type and the
configured I/O handler type.
After this patch, one can have the following configuration:
tch-voice
io-handler l1phy
tch-data
io-handler unix-sock
io-tch-format ti
so that the io-handler setting for voice would not affect data calls.
Before this patch, the L1 PHY (specifically, Calypso firmware) would
not route TRAFFIC.{ind,req} during data calls at all.
Thanks to this patch, it's also no longer required to restart the
mobile application after changing voice or data I/O handler.
Change-Id: Iab68cb47c28380a9c1efc149c6196ea54f75fdb8
Related: OS#4396
During a Mobile Originating voice call, we would normally start
receiving traffic indications with ringback tone (or even some
melody) before the call gets CONNECTed. So in order for the user
to be able to hear that, we need to init the voice call handler
earlier (on receipt of CC ALERTING message).
We should not be transmitting voice/data frames before the call
gets CONNECTed, so add 'rx_only' flag to the TCH state. In
tch_send_msg() drop msgb if this flag is set.
Rx only mode makes no sense for data calls, so in tch_recv_cb() we
discard received DL frames and thus do not trigger sending UL frames.
Change-Id: Idd32c823639cc1f9999d77fcefe7e260e31a85ec
Related: OS#4396
In tx_pdtch_fn(), delay sending DATA.cnf until bid=3. Otherwise we
send it too early (at bid=0) and trick the upper layers (RLC/MAC)
to believe that the whole block (all bursts) has been transmitted.
Change-Id: If32fafeef0ea347ed3800e6b67349bf12e66047f
The current timeout is too low, taking into account that SM PDP
Activation timeout is already 30. When SM fails, it will retry sending
PDP Context Activation Req. Hence, give it enough time to at least retry
once, plus some extra buffer time (eg to go through GMM attach once).
Change-Id: I34f9b0a5ad5767155dc3e4c0ac1c4bf1521be596
It's unlikely to happen as long as all TCH_DATA_IOF_* variants are
handled in the switch statements, but still gcc does complain.
Change-Id: I0a81d5c4f11feb7cf73771c23848dee9ce6ec620
We already have VTY commands to configure data call parameters at
run-time, but so far there was no way to save and restore them.
This commit adds the respective commands to TCH_DATA_NODE.
Change-Id: I4453f2e7e048b3f3ebb1727f6d26f018c792c92d
Related: OS#4396
Currently we unconditionally expect the rate adaption (octet 5) in
the Bearer Capability IE to be GSM48_BCAP_RA_V110_X30. This is
correct for UDI (GSM48_BCAP_ITCAP_UNR_DIG_INF), but not for 3.1 kHz
audio (GSM48_BCAP_ITCAP_3k1_AUDIO) and fax (GSM48_BCAP_ITCAP_FAX_G3)
calls. For the later two it should be GSM48_BCAP_RA_NONE.
Change-Id: I70d36b3540ed2469068e050809a17ed07b434ad7
Related: OS#4396
So far we supported the Texas Instruments format (TCH_DATA_IOF_TI),
which is used by Calypso based phones (e.g. Motorola C1xx), but not
the format that trxcon speaks/understands (TCH_DATA_IOF_OSMO).
Change-Id: Ib17e800e91ad536db53aa55661076089f0ce34b0
Related: OS#4396
We cannot initiate V.34 data calls because gsm48_encode_bearer_cap()
does not support octet 6d. This variant should not be selectable.
Change-Id: Ibafb9a693654672fb9a6abf665c500a27c87bf22
Related: OS#4396, OS#6344
We will need to know the current Bearer Capability of a CC
transaction in the upcoming patches adding CSD support.
Change-Id: Ifc3ecf832a552c65444f49711ac836b6cd984715
Related: OS#4396
This allows driving logic in other modules based on transaction
related events, such as allocation, deallocation, or a state change.
These new signals will be used in the upcoming CSD implementation.
Change-Id: Idae5da24cb517878a26cc14b2ba6976e60f0b31b
Related: OS#4396
Fix a regression: check if Location Area Information IE fits.
Change-Id: I51e2ae1be1c51a6359f8b0faad56f654251f1413
Fixes: bb0ac02e "mobile: always check return value of tlv_parse()"
Fixes: CID#341618
A similar check was recently added to gsm48_cc_data_ind().
Change-Id: Ibc5153df41e2c6365a3c65b1906d440a1074514b
Related: 273d412a "mobile: gsm48_cc_data_ind(): check if struct gsm48_hdr fits"
The L1 PHY may emit empty TRAFFIC.ind in case of decoding errors.
Abort execution of pq_audio_sink early, otherwise we hit an assert.
Change-Id: Ice11b72ddfd51fbfb17a4c609c664b86a8f69591
* Migrate from deprecated gsm48_mi_to_string() API.
* Take a chance to unfify printing of mobile identity.
* Use osmo_load32be() for printing TMSI - this is what
the osmo_mobile_identity API does internally.
Change-Id: Ida67adaa61689c55505a89e1a1bebde041c91139
Depends: libosmocore.git If4f7be606e54cfa1c59084cf169785b1cbda5cf5
Checking the stderr makes a little sense, since it's an integer
value (usually equal to 2). The actual intention, most likely,
was to check 'stderr_target' against NULL.
Change-Id: Id597f766142f928135f9fd2b7cf4d69de7bc72f0
Related: OS#6299
After adding the strongest cell to the measurement report, the variables
'strongest' and 'strongest_i' are used to prevent that already added
cells are added again.
Please note that there are no neighbor cell measurements available,
because current layer 1 does not report BSIC of neighbor cells. This
means that there is no neighbor cell reported.
Related: OS#6280
Change-Id: Iaeeaf978da31611c47a20af41790bfa6640dcffd
A wrong index was used, causing the first neighbor cell to be
uninitialized. This uninitialized neighbor cell was reported by
MEASUREMENT REPORT.
Related: OS#6280
Change-Id: I192c0777450cbe24abb3c7c8736c678b97725e9f