Currently this function fails to initialize all bcap fields properly,
so the resulting CC Setup message generated by osmo-msc has some
fields set to reserved/invalid values.
With these changes I am able to establish a data call on TCH/F9.6:
* cap->{mode,coding}: assign default values explicitly;
* cap->radio: value 0 is reserved, set GSM48_BCAP_RRQ_FR_ONLY;
* cap->data.sig_access: value 0 is reserved, set GSM48_BCAP_SA_I440_I450;
* cap->data.transp: this is not a bool, set GSM48_BCAP_TR_{TRANSP,RLP};
* cap->data.{nr_{data,stop}_bits,parity}: set 8N1 by default;
* cap->data.modem_type: explicitly assign default value;
* cap->data.interm_rate: value 0 is reserved, set GSM48_BCAP_IR_{8k,16k}.
The related libosmocore.git patch additionally fixes encoding of the
"Connection element (octet 6c)", so that bcap->data.transp is used.
Change-Id: If49c89e4f867bac92ad062c062b9f36bab2b4531
Related: libosmocore.git I7339908864e8a2aef6f2b48a108650167e413c7f
Related: OS#6110, OS#4394
Without the gsm0808_speech_codec functions:
* codec_mapping_by_gsm0808_speech_codec_type(), and
* codec_mapping_by_gsm0808_speech_codec()
fail to find the codec mapping for CLEARMODE.
Change-Id: I87b3aedaf7ff7bbbcb381e94158566dc765e3ae6
Related: OS#6110, OS#4394
As per 3GPP TS 48.008, section 3.2.2.103, the Codec Type is valid if
at least one of FI, PI or PT is set to '1'. Otherwise the Speech
Codec Element is considered invalid and shall be ignored.
Change-Id: Ibc452d37d4215c961a7946eef3ba2e7efdba078b
Related: OS#6110, OS#4394
Whenever we call build_tlv() we must
call destroy_tlv() after we are finished with it.
Similarly, smpp34_unpack() makes calls to smpp34_malloc()
and these need to be free'd by us later.
Change-Id: Ic2abcbe78cf7cf7b6ce36fe09aa9b4f8daee973f
Voice group call and voice broadcast call messages as well as assignment
result are forwarded to VGCS/VBS call control.
Change-Id: Ie68eedb8fcb064a55cd71b58630d7a8c8b5f29ad
Related: OS#4854
When sending or receiving BSSMAP reset msg, the ongoing VGCS/VBS SCCP
connections are cleared. E.g. this happens if the BSC is restarted and
there is an ongoing VGCS/VBS call at this BSC.
Change-Id: Ib0b309150b82148098d05cfb1fb18767283e654e
Related: OS#4854
When the calling phone releases the uplink before it has been assigned
to the group channel, it will send an UPLINK RELEASE message on the
dedicated channel.
This message is forwarded to VGCS state machine to handle the release
there.
Change-Id: Ie8f7338da18eaaefbb022c09b96f18a3d78f8a95
Related: OS#4854
Switching ASCI support is controled via VTY. This added in a later
patch. (Chg-Id: I5bd034a62fc8b483f550d29103c2f7587198f590)
Change-Id: Id68deb69f7395f0f8f50b3820e9d51052a34f753
Related: OS#4854
A voice group/broadcast call has no SCCP connection that is related 1:1
to a calling or called subscriber. Instead there are multiple connections
between MSC and BSS. Some of them control the uplink for each BSS and
some of them assign the channels for each BTS.
SCCP connections are maintained by the VGCS call control. Message from the
RAN are directly forwarded to the VGCS call control.
Change-Id: Ie4a2f19ba75140a6f2de02b709597239c01f02a2
Related: OS#4854
There is no GSM0808_DATA_RATE_TRANSP_300 (not in libosmocore and not in
3GPP TS 48.008 § 3.2.11 on which the enum is based). As I understand it,
we need to use GSM0808_DATA_RATE_TRANSP_600.
As pointed out in review, either TCH/H2.4 or TCH/F2.4 would work for
rates below 9600, so use GSM0808_DATA_FULL_PREF.
Use GSM0808_DATA_FULL_BM instead of GSM0808_SPEECH_FULL_BM. The value is
0x8 for both, but this is the correct name.
Related: OS#4394
Change-Id: I7297cc481fbe36355b5231ca800cf566a1ee93c0
VGCS/VBS messages from BSS are decoded and a receiver funktion for
the GCC/BCC (VGCS/VBS call control) is selected.
Change-Id: Ief6259ba3914eeaceb063b562a0bcbc48349ce60
Related: OS#4854
The (optional) call reference is required to assign a calling subscriber
to a voice group/bcast channel. The BSC can then determine to which
existing VGCS/VBS channel the MS is assigned to.
This IE is part of the GSM standard TS 48.008 (see §3.2.1.1)
Change-Id: I7955c6e0eebc930f85f360dda46be17cbd39e181
Related: OS#4854
This is a built-in data structure to store and handle voice group calls.
The GCR will be used by VGCS/VBS call control.
(Chg-Id: I9947403fde8212b66758104443c60aaacc8b1e7b)
The GCR will be used by VTY code.
(Chg-Id: I5bd034a62fc8b483f550d29103c2f7587198f590)
Change-Id: Ia74a4a865f943c5fb388cd28f9406005c92e663e
Related: OS#4854
Generally a transaction is linked with a subscriber (vsub).
A voice group call transaction may not have a subscriber associated. The
vsub field of the transaction will be NULL. If the group call is
initiated by a calling subscriber, the vsub field is set until the
calling subscriber is assigned to the voice group channel. If the group
call is initiated via VTY, vsub field is not set on creation of the
transaction.
Change-Id: I2b9afe95db4c106c141f4b7bd199ec74e197e523
Related: OS#4854
- TRANS_GCC is used for the voice group call.
- TRANS_BCC for the voice broadcast call.
This also includes the use counters for transaction and CM service
request usage:
- MSC_A_USE_GCC
- MSC_A_USE_BCC
- MSC_A_USE_CM_SERVICE_BCC
- MSC_A_USE_CM_SERVICE_GCC
Change-Id: Iddd11f813582ac2ac2bdee91cc3a525986deb514
Related: OS#4854
A transaction can be identified by the callref and the type. Because
transactions with different types may share the same callref value,
it is required to include the type in the trans_find_by_callref()
parameters.
E.g. a voice group call may have the same callref as a voice broadcast
call, but they are different calls. They also may not be confused with
other transaction types having eventually equal callref value, like
GSM 04.08 calls, SMS or supplementary services transactions.
By adding the transaction type to trans_find_by_callref(), we
essentially now use the (type, callref) tuple as unique ID for
transactions, instead of just callref.
Change-Id: Ic0b82033a1aa3c3508ad610c690a5f29073006c1
Related: OS#4854, OS#3294
Allow the caller of rtp_stream_alloc() to define what events will be
dispatched to the parent FSM. This allows other state machines to use
rtp_stream. It is required for using RTP stream process with VGCS FSM.
Drop the unused parent_call_leg member.
Change-Id: I0991927b6d00da08dfd455980645e68281a73a9e
Related: OS#4854
So far rtp_stream_commit() triggers an MGCP MDCX message only when
codecs or the RTP address changed.
Do the same for mode changes. ('sendrecv', 'recvonly', 'sendonly',...)
Change-Id: I7a5637d0a7f1df13133e522fc78ba75eeeb2873e
Related: OS#4854
The MGCP protocol features the 'C' (call-id) to identify which
connections belong to the same call. They may be used by MGW for
accounting or management procedures.
So far we sent the MNCC callref as call-id. Instead, add a separate
unique call_id number space. Assign a unique call_id to each
transaction.
Change-Id: I36c5f159fa0b54fb576ff8bd279928b895554793
Related: OS#4854
Use the MNCC bearer capabilities in CC setup for CSD, if available.
Note that in the MNCC_F_BEARER_CAP code path sdp_audio_codecs_set_csd()
also gets called by trans_cc_set_remote_from_bc().
Related: OS#4394
Change-Id: I56e49ebc41696912a81b8f4f63fbc36d0b605e9e
Check the return code before writing it to unsigned ct->data_rate, as
"ct->data_rate < 0" is never true.
Fixes: CID#321277
Fixes: 106321 ("Add initial CSD support with external MNCC")
Change-Id: I5d77da71b60748818ba631229126c1bf061a9c7d
Prepare to use trans->bearer_cap.transfer in trans_cc_filter_run() to
differentiate between speech and data (CSD).
Related: OS#4394
Change-Id: Id0476a4882bcb27413d033f2de2c5288954f0b95
Move remote out of codecs, as it will be used by CSD code as well.
Otherwise we would need to store it twice (in cc.codecs.remote and
cc.csd.remote).
Related: OS#4394
Change-Id: I5d2e078db3b3437cb6feae40d8955912d7a297e4
Remove the comment as trans->bearer_cap will be used in CSD code to
differentiate between speech and data.
Related: OS#4394
Change-Id: I0539632f464bc44945599bec52dc2a4df2f0115f
Remove the misleading "We must not pass bearer_cap to
codec_filter_init()" part of the comment. The function doesn't accept a
bearer_cap parameter, it cannot be passed to the function:
void codec_filter_init(struct codec_filter *codec_filter)
{
*codec_filter = (struct codec_filter){};
}
Related: OS#4394
Change-Id: I87a1e371e108d8da514b30f1726aad0f85ea4111
In all the places where codec_filter_ functions get called, for CSD we
will need to filter the bearer services. Add a new
transaction_cc.c file for functions that either combine the
codec_filter_ function with logic for CSD and voice calls or just call
the existing codec_filter function and a new csd_filter function.
Start with moving codec_filter_set_ms_from_bc to this new file, it will
be extended with a case for CSD in a future patch.
Related: OS#4394
Change-Id: If225f2a299ce6bc9ae35a17d6f591d889f49155e
For all 3G calls, convert IuUP <-> plain AMR/RTP on the MSC's MGW hop
like this:
Before this patch:
hNodeB <--IuUP--> MGW@hnbgw <--IuUP--> MGW@msc <--IuUP--> other call leg
After this patch:
hNodeB <--IuUP--> MGW@hnbgw <--IuUP--> MGW@msc <--AMR--> other call leg
^
This allows, in principle, 2G to 3G calls without expensive transcoding,
like this:
hNodeB <--IuUP--> MGW@hnbgw <--IuUP--> MGW@msc <--AMR--> MGW@msc <--AMR--> MGW@bsc <--AMR--> 2G-BTS
^
(So far only proven to work with AMR-FR at 12k2.)
3G to 3G calls now look like this:
hNodeB <--IuUP--> MGW@hnbgw <--IuUP--> MGW@MSC <--AMR--> MGW@MSC <--IuUP--> MGW@hnbgw <--IuUP--> hNodeB
^
Implementatino: get rid of the shim that was put in place to still send
IuUP (VND.3GPP.IUFP) to the CN. So now, for all 3G voice, the IuUP gets
decapsulated to plain AMR/RTP at the MSC's MGW hop.
What is proven to work with this patch:
successful voice call between 2G and 3G with these conditions:
- a hNodeB that stubbornly accepts only 12k2 AMR;
- a 2G BTS configured to use only TCH/F and only FR3, with only 12k2 as
allowed AMR rate.
We have not yet seen a call working for TCH/H HR3 <-> 3G, because of the
lab hNodeB's limitation to 12k2.
Future work we probably need:
- properly request and negotiate AMR rates via SDP fmtp:mode-set.
- request more RFCIs in our RANAP RAB Assignment requests
(see I61e0e9e75e3239662846fd797532acdefa9f73dc).
- Convert IuUP to AMR already at the HNBGW's MGW?
Solving this is not part of this patch.
Related: SYS#5092
Change-Id: I386a6a426c318040b019ab5541689c67e94672a1
When the SMS sqlite db is opened and not closed properly, sqlite will
print a trace on the next OsmoMSC startup while restoring the database.
This happens when e.g. attempting to bind OsmoMSC on an IP that is not
available (yet) and then restarting OsmoMSC.
db.c:521 Init database connection to 'sms.db' using SQLite3 lib version 3.34.1
db.c:318 SQLITE3: (283) recovered 37 frames from WAL file /var/lib/osmocom/sms.db-wal
backtrace.c:42 backtrace() returned 22 addresses
backtrace.c:53 /lib/x86_64-linux-gnu/libsqlite3.so.0(+0x36a56) [0x7f1518c00a56]
backtrace.c:53 /lib/x86_64-linux-gnu/libsqlite3.so.0(sqlite3_log+0x9e) [0x7f1518c00b3e]
backtrace.c:53 /lib/x86_64-linux-gnu/libsqlite3.so.0(+0x5f4f4) [0x7f1518c294f4]
backtrace.c:53 /lib/x86_64-linux-gnu/libsqlite3.so.0(+0x5fbb3) [0x7f1518c29bb3]
backtrace.c:53 /lib/x86_64-linux-gnu/libsqlite3.so.0(+0x7ee02) [0x7f1518c48e02]
backtrace.c:53 /lib/x86_64-linux-gnu/libsqlite3.so.0(+0x7f908) [0x7f1518c49908]
backtrace.c:53 /lib/x86_64-linux-gnu/libsqlite3.so.0(+0xb9a5f) [0x7f1518c83a5f]
backtrace.c:53 /lib/x86_64-linux-gnu/libsqlite3.so.0(+0xcddac) [0x7f1518c97dac]
backtrace.c:53 /lib/x86_64-linux-gnu/libsqlite3.so.0(+0xcddef) [0x7f1518c97def]
backtrace.c:53 /lib/x86_64-linux-gnu/libsqlite3.so.0(+0xf537d) [0x7f1518cbf37d]
backtrace.c:53 /lib/x86_64-linux-gnu/libsqlite3.so.0(+0xb479e) [0x7f1518c7e79e]
backtrace.c:53 /lib/x86_64-linux-gnu/libsqlite3.so.0(+0xb79b6) [0x7f1518c819b6]
backtrace.c:53 /lib/x86_64-linux-gnu/libsqlite3.so.0(+0xb8116) [0x7f1518c82116]
backtrace.c:53 /lib/x86_64-linux-gnu/libsqlite3.so.0(+0xb853f) [0x7f1518c8253f]
backtrace.c:53 /lib/x86_64-linux-gnu/libsqlite3.so.0(sqlite3_prepare_v2+0x16) [0x7f1518c826a6]
backtrace.c:53 /lib/x86_64-linux-gnu/libsqlite3.so.0(sqlite3_exec+0xb4) [0x7f1518c8fce4]
backtrace.c:53 /usr/bin/osmo-msc(+0x1bf13) [0x564f81946f13]
backtrace.c:53 /usr/bin/osmo-msc(+0x524c0) [0x564f8197d4c0]
backtrace.c:53 /usr/bin/osmo-msc(+0x1324e) [0x564f8193e24e]
backtrace.c:53 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xea) [0x7f1518991d0a]
backtrace.c:53 /usr/bin/osmo-msc(+0x13fea) [0x564f8193efea]
Related: SYS#6360
Change-Id: I9bb799048db5fcdb2a2520107bd75d5f7a865459
Don't fall back to the legacy config if the pool is configured but no
connection to any pool member can be established.
Depends: osmo-mgw I009483ac9dfd6627e414f14d43b89f40ea4644db
Related: OS#5993
Change-Id: I44e7b2723d801ceb03aaa2e5546802b4eb56b3c3
In order to send the MSC's RTP endpoint IP address+port in the initial
SDP, move the MGCP CRCX up to an earlier point in the sequence of
establishing a voice call.
Update the voice call sequence chart to show the effects.
Though the semantic change is rather simple, the patch is rather huge --
things have to happen in a different order, and async waits have to
happen at different times.
The new codec filter helps to carry codec resolution information across
the newly arranged code paths.
Related: SYS#5066
Change-Id: Ie433db1ba0c46d4b97538a969233c155cefac21c
Transmit and receive full SDP information via MNCC, to accurately pass
codecs choices between the call legs.
In msc_vlr_test_call.c test_call_mt(), show that when receiving MNCC,
the codec information in SDP overrules the Bearer Cap codec information
-- we expect to still receive inaccurate Bearer Cap from e.g.
osmo-sip-connector, because we have chosen to add SDP to MNCC instead of
trying to fix the codecs represented in Bearer Cap.
For internal MNCC, the MT call leg now knows which codec the MO has
chosen and assigned.
For external MNCC, osmo-sip-connector receives SDP about our codecs
choices and sends it in SIP messages, and we also receive the full SDP
information from the remote SIP leg.
Update the SDP in codec_filter every time it is received, to always have
the latest SDP information from the remote leg.
CC MNCC
| ---ALERTING--> | add local side SDP to MNCC msg
| <--ALERTING--- | store remote side SDP
| <--SETUP-RESP- | store remote side SDP
| --SETUP-CNF--> | add local side SDP to MNCC msg
| -RTP-CREATE--> | use codec_filter, add local side SDP to MNCC msg
| <-RTP-CONNECT- | store remote side SDP
There still is one problem: when initiating MNCC, we do not yet know the
RTP address and port to be used for the CN side, because the CN CRCX
happens later. So far we send 0.0.0.0:0 as RTP endpoint in the SDP,
until the CN CRCX is done. A subsequent patch moves CN CRCX to an
earlier time, adding proper RTP information right from the start.
Related: SYS#5066
Change-Id: Ie0668c0e079ec69da1532b52d00621efe114fc2c
So far, patches have set up rtp_stream to allow setting multiple codecs,
and collected the codecs information into the codecs filter struct.
Now actually use the codecs filter result to choose a codec.
Setting up the call leg FSMs and codecs still looks rather confusing in
this patch, because this is an incremental step in a larger series. The
upcoming patch 'do CN CRCX first' clarifies this substantially.
The resulting codecs behavior is tested in upcoming patch
I879ec61f523ad4ffc69a0b02810591f7c0261ff9. (The test ideally should have
come before this patch, but my time to rework this branch is up.)
With the codecs filter in place, we are ready for sending and receiving
full SDP via MNCC, see upcoming Ie0668c0e079ec69da1532b52d00621efe114fc2c
and Ie433db1ba0c46d4b97538a969233c155cefac21c
Related: SYS#5066
Change-Id: I66e7c8c5e401f4f3a7d3d42b9525b2c6e99691d9
So far, we just forwarded the Bearer Capabilities received in MNCC from
the remote MO call leg, and omitted Bearer Cap if the remote call leg
did not provide any.
Instead, always include Bearer Cap, and compose it from the codecs
filter result. Hence the Bearer Cap is now an intersection of MS, BSS
and remote call leg, instead of just the remote call leg.
Related: SYS#5066
Change-Id: I9586221ef56352b7ce4b2604ae0dc04554145a78
Do not convert to enum mgcp_codecs, but directly pass the
gsm0808_speech_codec IE from the A interface to codecs handling.
For Iu:
- RAN side: use ran_infra.force_mgw_codecs_to_ran to keep the MGW
endpoint towards RAN on IUFP.
- CN side: introduce flag ran_msg.assignment_complete.codec_with_iuup,
so to decide whether to forward IUFP towards CN, we don't need to test
the RAN type, but use the flag from the ran_msg implementation.
In msc_vlr_tests, use the SDP codec string instead of enum
mgcp_codecs.
So far limit to intra-MSC related messaging, adjusting inter-MSC
handover follows in a separate patch.
Change-Id: Ia666cb697fbd140d7239089628faed93860ce671
Allow configuring MGW conns with multiple codecs. The new codecs filter
can have multiple results, and MGCP can configure multiple codecs. Get
rid of this bottleneck, that so far limits to a single codec to MGW.
On Assignment Complete, set codec_filter.assignment to the assigned
codec, and use that to set the resulting codec (possibly multiple codecs
in the future) to create the CN side MGW endpoint.
Related: SYS#5066
Change-Id: If9c67b298b30f893ec661f84c9fc622ad01b5ee5
Indicate in the ran_infra data structure whether a RAN needs specific
codecs to be set up on the RAN facing MGW endpoint.
This allows setting forced RAN codecs as first-class citizen in the
ran_infra data structure, instead of special cases in the code (for IuUP
on IuCS).
Will be used in subsequent commit
I37f65c36af2679ecba1040a11a9aa0eb9481d817, submitted separately for
easier readability.
Change-Id: I37f65c36af2679ecba1040a11a9aa0eb9481d817
Codec List (BSS Supported) is received once in Complete Layer 3 and
again in Assignment Complete messages. Use the most recent one, i.e. the
one from Assignment Complete, when it occurs.
Related: SYS#5066
Change-Id: I5e66ecc7987fa926f39d8be8eaf5799b931ab20a
Collect either the SDP or the Bearer Capabilites in the incoming
MNCC in the new codecs filter.
So far just collect the info and do not change the behavior, using the
filter result will follow in a subsequent patch.
Related: SYS#5066
Change-Id: I84d9bbca3e4061da622b1b2fc0bde8868e7e3521
For MT call, initialize the codecs filter and apply the
Codec List (BSS Supported) from Compl L3.
Related: SYS#5066
Change-Id: I530409a64d11da48518a3dc60aa3a4e47c384663
The initial Compl L3 happens long before we establish a CC transaction.
Remember the Codec List (BSS Supported), so that we can feed the new
codecs filter with it. Subsequent patches implement feeding the filter.
Related: SYS#5066
Change-Id: I7cdc348218433141a43d2e42750af02591688240
Add the infrastructure to store and filter all codec limitiations from
the different stages: MS, BSS, CN and remote call leg. Upcoming patches
will properly collect these and find an optimal codec.
No functional change, yet.
Related: SYS#5066
Change-Id: I4d90f7ca62f2307a7b93dd164aeecbf4bd98ff0a
Converting between different codec representations is confusing. This
codec mapping provides a consolidated overview of all our codec
representations, and how they match up.
In particular, it adds the SDP codec representation repertoire,
preparing the use of full SDP on the MNCC interface.
Related: SYS#5066
Change-Id: Iaa307be6a8487aa8d4ba7cd59d5c5ef04818a744
Omit "in state FOO", because LOG_TRANS() already logs the state.
Most MNCC "rx" logging was duplicated. Log "rx" only once.
If there is RTP information passed with the MNCC message, log it:
- if there is SDP, log the SDP information.
- if there is no SDP, log the legacy MNCC RTP fields, if any.
One motivation to do this is to get RTP information in ladder diagrams
generated by msc_log_to_ladder.py without the need to add udtrace MNCC
logging to osmo-msc; and also to get RTP info for internal MNCC, where
udtrace doesn't apply, because no unix domain socket is involved in
internal MNCC operation.
Change-Id: I4b916cb482ed441b508c6295de211a21c49cd5c1
Since osmo-mgw now supports IuUP properly, and since we indicate IUFP in
the MGCP CRCX towars an IuCS RAN [1], we should no longer place the MGW
endpoint in loopback mode to hack up an IuUP Initialization.
This hack should have been removed along with [1].
[1] IUFP sent to MGW since this commit:
commit 3a02d29804
Refs: 1.8.0-13-g3a02d2980
Announce IuFP audio codec for UTRAN conns in CRCX towards MGW
I7aca671e00ed27ac03f0d106b5a6b665a9bed4c1
Change-Id: I6446c64421e3e13e2b829293d031c98b99cd39a7
A new VTY node was added in commit [1], but bsc_vty_go_parent() was
not updated. Because of that, commands following the MGW node may
crash osmo-msc. See related patch [2] for more details.
Change-Id: I2422fa9152ecc8c4be1f2487ee016c3fe737e653
Fixes: [1] b44cf2d575
Related: [2] osmo-bsc.git Id3050ff7e2402c33ee76c7bf0cc83603c0cc6dfc
According to 3gpp spec the Call Reference part of GCR is 5 octets,
3 octets Call ID followed by 2 octets BSS ID.
We are using our internal call reference (4 octets) and the
location area code, or optionally Cell ID as BSS ID
(2 octets). Obviously it does not fit.
Let's use only 3 octets from the call reference, dropping the MSB.
Includes code by Vadim Yanitskiy <vyanitskiy@sysmocom.de>
Change-Id: I9c33a89c819e8925d89ca833d7705ed5ced6b566