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
I noticed by chance that the Assignment Complete message generated in
the test lacks a remote RTP address for the RAN side.
Make the test more realistic by adding a remote RTP address and port. It
doesn't have any bearing on the tests besides more accurately showing
RTP stream setup in the logs.
Change-Id: Ia428762a16dcc17f036d725a00e0b3767418289b
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 central codecs_filter for Call Control. The new member is not
used in this patch yet, subsequent patches will start to populate the
various stages of this codec filter, one by one.
Related: SYS#5066
Change-Id: Ib3fdeff8d1e1ea0760168d63ee6e1b1fb993aa5f
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
This option should be used for any executables which are used only
for testing, or for generating other files and are consequently never
installed. By specifying this option, we are telling Libtool that
the executable it links will only ever be executed from where it is
built in the build tree. Libtool is usually able to considerably
speed up the link process for such executables.
Also take a chance to add the missing $(COVERAGE_LDFLAGS).
Change-Id: I664a9d5abed2777deee302f9d3afd1bbfde7a844
Same as voice_call_external_mncc.msc, but run with internal MNCC. Shows
some curious differences like the MNCC_LCHAN_MODIFY that internal MNCC
sends, but external doesn't.
Change-Id: Ic003322dc4e3fce24a8413688cfe18198a4dc08a
Re-run the msc_log_to_ladder.py on an actual 2G-2G voice call log, to
see if anything changed in the meantime, to prepare for upcoming changes
to the sequencing of establishing voice calls.
Also shows recent improvements on picking up RTP ports from MGCP and
MNCC.
Change-Id: I9dcf980ad24d5921c291c9aada211b37f6f3db7f
(multiple changes in one patch because who cares about this script)
tweak regexes -- they worked ok, but some of the '[^:]' should really be
'[^:)]', and they also look happier that way.
don't skip RAN=NONE, so we also see messages before Complete Layer 3.
s/sip/mncc, to generally be valid for both internal and external MNCC.
pick up RTP port information from MGCP OK
pick up RTP port information from MNCC rx and tx
add --verbose flag, to be able to check whether the regex rules are
still working (getting any hits).
fix rule_imsi_detach: should return True to be counted in --verbose.
tweak comment 'Generated by...' to include the full git path.
Change-Id: If619182ba76c6b238a1fa105a3c3449d7f473dd1
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
Both EXTRA_DIST and CLEANFILES had missing entries. It is easy to
forget to keep them up to date. Rather use wildcards to always pick up
all relevant files.
(Not adding *.dot because there are no .dot charts here, yet.)
Change-Id: I3a18e4608a310169d7c9cd9c1b8ac9015a990920
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
Now that the warnings in osmo-iuh have been fixed, we should be able to
build the IU version of OsmoMSC with --enable-werror too.
Related: OS#4462
Change-Id: Id54be9dd1aa66cc27eb5ee4010be9e495865b331
When the HLR fails to return auth info and authentication and ciphering
are configured to be optional, fall back to no-auth.
This patch concludes a series of preparatory patches and implements the
actual functional change.
Related: OS#4830
Change-Id: I5feda196fa481dd8a46b0e4721c64b7c6600f0d1
Add third outcome of auth_fsm: the no_auth_info_event, which should be
dispatched when auth failed because the HLR has no auth info for this
subscriber, i.e. not because an actual auth challenge failed.
No functional change: Handling no_auth_info_event separately follows in
another patch (to allow fallback to no-auth). Feed the same
_E_AUTH_FAILURE as no_auth_info_event to still behave unchanged.
Related: OS#4830
Change-Id: I5103b1f2727f1729a5517ae359df813d50436ed3
Previous patch added the AUTH_FAILURE event, which means that the
AUTH_RES event now only signals success. Reflect that in the name.
No functional change.
Related: OS#4830
Change-Id: I7124a3591fcf36cee06d7488eeb94f9b85af5dc2
Explicitly send distinct parent events on auth success and failure. So
far determining success depended only on the data pointer passed on with
the event. Distinct events clarify the logging and the FSM code.
This prepares for a third FSM outcome to be added in a subsequent patch,
to separately signal when the HLR has no auth data.
No functional change.
Related: OS#4830
Change-Id: I02776dfe6785983f2ebe398f57867f5ceb288ba0
These functions actually return whether these procedures should be
attempted, not whether they are absolutely required. Rename to avoid
confusion in upcoming patches.
Related: OS#4830
Change-Id: I0ea90476470109134411255ffd1f11d88236c91b
For establishing Layer 3, pass a flag from msc_a to VLR that indicates
to fail if encryption is not possible.
An earlier patch [1] renamed a previously existing flag
require_ciphering to is_ciphering_to_be_attempted, because the naming
was not accurate. This new flag now indicates what its name suggests.
This new flag is needed for upcoming patch [2] to distinguish between
optional and mandatory encryption.
[1] Ia55085e3b36feb275bcf92fc91a4be7d1c24a6b9
[2] I5feda196fa481dd8a46b0e4721c64b7c6600f0d1
Related: OS#4830
Change-Id: I52090c5f5db997030da7c2ed9beca9c51f55f4cf
