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
cat-testlogs.sh does "exit 1", so no workspace.tar.xz is created.
Call this script after archiving the workspace.
Change-Id: Ibcb842f32418e66a186d6b21bb5861cf4a0b7c4a
Fixes: 799d972132 "contrib/jenkins: create workspace.tar.xz on error"
Related: OS#5665
In order to figure out why we sometimes get a coredump in the jenkins
master jobs, add a quick hack to get all relevant binaries on libraries
on error.
Related: OS#5665
Change-Id: If7b4eb050e2b3f763b5cfddf1a5b6a18bb41f46e
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 msc_vlr_test_call, we fail to send the right MNCC struct for
MNCC_RTP_CREATE. We should pass a struct gsm_mncc_rtp. Fix that.
Change-Id: Ia0b3253f85c716e45f925da3f58f025af1f15ec9
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
Upcoming patch 'do CN CRCX first' changes the ordering of MGCP. To
properly show the change in behavior in the msc_vlr_test_call, first
clarify which side is expected to do MGCP when.
Related: SYS#5066
Change-Id: I972e7426006e5b62f81ccfe4fa224ee9eed7a7ac
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
