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
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
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
Neels Hofmeyr
Pau Espin
Vadim Yanitskiy
arehbein
Keith Whyte