It's a minor technicality, but it seems the newly added API to
iterate the codec_mapping can slightly improve this implementation:
For some reason, the Bearer Capabilities should reflect whether any HR
codec is possible with its listed Speech Versions. So far we looked only
whether the first match for a given Speech Version in the global const
codec_mapping is a HR codec. Instead, look through *all* entries for a
Speech Version, and see if any one of them indicates HR.
For example, an AMR-FR codec with a well adjusted mode-set can work with
a half rate channel.
Change-Id: Ic964af4bec21598836748279f3fee480e470738c
Enable fmtp matching in sdp_audio_codecs_by_descr(). This has profound
effects on the codec_filter and other loops that collect codec matches.
By properly matching the meaning of fmtp, msc_vlr_test_call.c now works
as expected: all AMR variants are picked up properly. Adjust
expectations.
Change-Id: I63dc27e76243074ae0f019d219cae4412d322a84
So far the API is pivoting on the payload type numbers as the "primary
key" for codec lists. However, working with variants of codecs, the
payload type numbers are just incidental, and the API isn't helpful.
- change the behavior to regard the subtype name and fmtp as the
defining identity of a codec: use sdp_audio_codec_cmp() to match.
- add argument 'once': flag to make sure a given subtype+fmtp exists
only once, regardless of payload type nr.
- add argument 'pick_unused_pt_nr': flag to make sure a new entry
doesn't duplicate payload type numbers.
This is preparation to properly match AMR variants, in order to fix the
expected error currently visible in msc_vlr_test_call.c:875.
Change-Id: I87db779dbab39dfdef2724488ccdb6959e6731ed
In msc_a_up_call_assignment_complete(), iterate all the new AMR modes
and rates recently added to codec_mapping, and enlist all possible
matches.
Change-Id: I6163a51765efff998e05c9ee4e82a0a3759f2043
These flags are redundant, the aim is to speed up comparisons of AMR
fmtp when traversing a long list of codec variants. It can skip a lot of
repetitive strcmp and fmtp string parsing when used by a loop.
Change-Id: Ic2c9b4983b5374621e02389900e3622faa29cad9
So far, querying the codec mapping returns one match.
For example:
const struct codec_mapping *m;
m = codec_mapping_by_speech_ver(GSM48_BCAP_SV_FR);
if (!m)
return -ENOENT;
But when supporting various AMR rates, we need to find multiple matches
in some code paths.
Also to support AMR OA vs BE modes, we need to combine multiple criteria
in some places.
With this patch, and as soon as an upcoming patch implements
codec_mapping_matches_speech_ver(), above code example becomes:
const struct codec_mapping *m;
codec_mapping_foreach (m) {
if (codec_mapping_matches_speech_ver(m, GSM48_BCAP_SV_FR))
break;
}
if (!m)
return -ENOENT;
This pattern supports collecting multiple matches in a list:
const struct codec_mapping *m;
codec_mapping_foreach (m) {
if (codec_mapping_matches_speech_ver(m, GSM48_BCAP_SV_FR))
sdp_audio_codecs_add_copy(my_list, m);
}
And this pattern also supports combining criteria:
const struct codec_mapping *m;
codec_mapping_foreach (m) {
// only allow AMR in OA mode
if (!osmo_sdp_fmtp_amr_is_octet_aligned(m->sdp.fmtp))
continue;
if (codec_mapping_matches_speech_ver(m, GSM48_BCAP_SV_AMR_F)
|| codec_mapping_matches_speech_ver(m, GSM48_BCAP_SV_AMR_H))
sdp_audio_codecs_add_copy(my_list, m);
}
Change-Id: Iaaa59d4bf5a6126a1bfe4ae282b82f6cb3ec6f99
Instead of returning multiple occurences of AMR as duplicated
gsm0808_speech_codec_type entries, combine their cfg bits to form a
single entry listing all AMR rate combinations that are allowed.
Prepare for AMR mode-set negotiation: soon we'll have multiple AMR
variants in codec_mapping.c, and then these must produce correct
gsm0808_speech_codec_list.
Change-Id: Ibeffb6c1325abebb904a14f00e6a0818870b119e
We have sdp_audio_codec_to_str() in a pretty sane and compact format,
so far for logging. It occured to me that this format is fit for VTY
config arguments.
Add a string-back-to-codec conversion.
- enable testing AMR mode-set and octet-align in msc_vlr_test_call.c, by
giving convenient codec strings parsed by this new function.
- enable VTY config options for codecs.
Change-Id: Ibf23a8888ab79d3b10b044383cd161f1dfdf7e63
Use the full struct gsm0808_speech_codec instead of just the enum
gsm0808_speech_codec_type: allow testing specific AMR mode-sets on A/Iu
signalling.
Prepare for matching AMR fmtp parameters between call legs.
Change-Id: I387490525007bdf2e95306fd9b4e5e3b7e487d0f
ptmap[].codec is already set correctly, so we can simply drop use of
codecs[] now.
Related: osmo-mgw I798e02c6663376d3d52f4a74fc4b32411ce95bed
Change-Id: I701eb97ddafa871cfbc12fdbe8a1fe14aa2a4db1
Since recent libosmo-mgcp-client update (see Depends), we can now pass
fmtp for each individual codec entry to be sent in the SDP. Use that new
feature to pass any fmtp from rtp_stream.c to the MGW via MGCP.
In effect, this adds the 'octet-align=1', defined in codec_mapping.c as
the default for AMR, which was missing from the SDP/MGCP that osmo-msc
sends out.
A 2G to 2G call worked out OK without it, because omitting the
'octet-align' setting from MGCP disables all octet-align payload checks
in osmo-mgw. Both 2G call legs use octet-align=1, and things work out.
Running a call from 3G to 2G before this patch would result in osmo-mgw
dropping the RTP with logging like:
DRTP NOTICE (rtpbridge/1@bsc0 I:B38CF524) rx_rtp(44 bytes): Expected RTP AMR octet-aligned=1 but got octet-aligned=0. check the config of your call-agent! (mgcp_network.c:1527)
...because osmo-bsc's MGW was instructed to expect octet-align=1, while
osmo-msc's MGW emits octet-align=0. This happens because converting the
3G IuUP to 2G AMR heeds the RFC 6871 specified default of octet-align=0.
So, after this patch, we accurately send "octet-align=1", and make the
IuUP-to-AMR conversion emit octet-align=1 to match 2G.
Side note: 3GPP specifies AoIP to use bandwidth-efficient AMR only;
however, in all known Osmocom world, our 2G BTS emit octet-aligned AMR
instead -- so in practice it makes most sense to run osmo-msc with
octet-align=1 as the default. osmo-msc shall at some point feature a
.cfg option to switch to octet-align=0 to conform with 3GPP, but until
then, osmo-msc now configures all AMR to be octet-align=1.
Depends: osmo-mgw If58590bda8627519ff07e0b6f43aa47a274f052b
Change-Id: Ief9225c9bcf7525a9a0a07c282ffb8cc0d092186
Looking at 3GPP TS 26.103 table 4.1, none of the AMR-Oxx variants are
supported by GERAN-GMSK nor UTRAN, so it makes no sense to include
these. There are no users of this.
Change-Id: I0cbc770fff55209676d9b6aae50011d6d5f897e2
(Same as osmo-bsc I47c9011b5e0e2886d221e34e6aa281d1dd0495c7)
*.vty tests are picked up by the Makefile.am by means of a wildcard --
they are run when they are there. So when you forget to add it to
EXTRA_DIST, it will be run in your local build tree, but it will be
silently omitted from a distribution tar, and nothing will complain
about it gone missing.
Instead, also use a *.vty wildcard in EXTRA_DIST. So any *.vty test
added to the git source will both be run *and* included in distribution
tars implicitly.
So far, test_neighbor_ident.vty was missing from the distribution.
Change-Id: Id28e020fc59b83d1b4cd0e5b72314a46bea62259
Better match the pattern of sdp_audio_codecs_* instead of having
foreach_ in the front. Prepare for prepending osmo_ some day, because I
plan to move the SDP API to a separate library.
Change-Id: Ia96190e0bdb513886663be1c8c12be3b403b71c9
When we get the codec filter result logged, it is most interesting to
know the caller. So wrap a file-line macro around trans_cc_filter_run().
Change-Id: I243404487c1871e921b08098086ef2fc78a5561d
The comments indicating which two "members" are identical are
inaccurate. (One of them is a macro pointing at the other.)
Change-Id: Ifaa2f361db77cd0ed3ad39d6ca197195b9354ea1
Currently the CSD check is in the middle of figuring out the voice codec
for normal voice calls. Rather do the CSD check first, and then do voice
in one coherent section.
(prep for upcoming change in this code, to support AMR rate selection.)
Change-Id: Ibd21f0bb46c66a406904105564ce961a8760cbe7
Before the codec filter, it would have been the CN side codec, but now
it is only the codec that the RAN reports as assigned, fed into the
codecs filter.
(prep for upcoming change in this code, to support AMR rate selection.)
Change-Id: Ie7966099c5565013018734b0c2028484c24341a7
This also makes sure it doesn't compile against older libosmogsm gsup
versions which would break ABI.
Related: OS#6091
Depends: libosmocore.git Change-Id 70be3560659c58f24b8db529c4fc85da4bb0ec04
Change-Id: Ia002fd6e0334d56de34d352a0bf1a8604e2e9fd3
low/high layer compatibility are used for capability checking between
caller and called entitiy. The transcoding is performed by libosmogsm.
Related: OS#6152
Depends: libosmocore.git Ia6a2159ecf810a02f85b558026edf20b934567de
Change-Id: I760980a7e17e2fa81615adc69ef85797eb0c07f1
low/high layer compatibility are used for capability checking between
caller and called entitiy.
The information is added to the end of struct gsm_mncc increases, so
that the version number needs not to be incremented.
Related: OS#6152
Change-Id: I15f5afcf069ee6c1c4641108ceacc837bee311b5
We do include this IE in result and error messages, but somehow
not in the request messages. For the sake of consistency, let's
ensure that the Source Name IE is present in all SMS related PDUs.
This additionally brings osmo-msc in sync with ttcn3-msc-test, which
was modified to expect the Source Name IE in all receive templates,
and makes the following testcases pass [again]:
* MSC_Tests.TC_gsup_mo_sms
* MSC_Tests.TC_gsup_mo_smma
* MSC_Tests.TC_gsup_mo_mt_sms_rp_mr
Change-Id: I65f5e3b7a0688e258979bb2679598659881a4321
Related: osmo-ttcn3-hacks.git Ic24d3082fe3dce08e43e8f3ecb6d6132503c55c6
Related: OS#6135
... so that it's clear which MNCC handler is used by looking
at the output of `show running-config`.
Change-Id: Id1fe7aecc1c8445db48ff5fddcf6df0f05ba5e2e
Prior to this change, if there was no explicit ipa-name configuration
in OsmoMSC, OsmoHLR would see the GSUP connection as MSC-00-00-00-00-00-00.
However, this default is constructed somewhere deep in IPA libraries
and is not visible to the GSUP client application, in this case OsmoMSC.
This situation creates a problem for SMS-over-GSUP routing: when we get
MT-forwardSM.req from an SMSC, we have to send a GSUP response, and this
response needs to get back to the MT-sending SMSC. Because OsmoHLR
applies only passive routing for these responses, we have to set
source_name when generating MT-forwardSM.res in OsmoMSC - but we cannot
do so if don't know our own IPA name.
Change the default OsmoMSC ipa-name from MSC-00-00-00-00-00-00 to
unnamed-MSC, mirroring OsmoHLR default of unnamed-HLR, and set it
at our application level rather than deep in the libraries.
Related: OS#6135
Change-Id: I7bacd001b81326c32bc262c7d0c0491ded822fa8
Previously added codecs tests uses non-default PT number sent by MT and
adopted by MO. Also test the other direction, i.e. a non-standard PT
from MO is adopted by MT.
Related: OS#6258
Change-Id: I8fbabe242982441d676d09f4d0ed7557c8349f2c
In msc_vlr_test_call.c, allow to tell MO non-default payload type
numbers in the SDP, to verify that it adopts the other call leg's PT
numbers.
Actually apply the non-default payload type number (AMR=96 instead of
the default of 112 from codec_mapping.c) and see the effects in
msc_vlr_test_call.err.
The diff shows that, as intended, the change in payload type number
should result in modifying the MGW endpoint to change the earlier '112'
to the modified '96' used in this test.
Related: OS#6258
Change-Id: I25df2ed7ad792fbe66dfd0fbf08182c9cf6cfc5b
In msc_vlr_test_call.c, allow to tell MO non-default payload type
numbers in the SDP, to verify that it adopts the other call leg's PT
numbers.
This test differs only slightly from the first codecs test, so in this
patch add the test as a 1:1 copy of the first test. The next patch [2/2]
will then show only the difference the new test makes.
Related: OS#6258
Change-Id: I618e3cf1b412985589a0c63bd76b7a60202f17b9
In patch I8760feaa8598047369ef8c3ab2673013bac8ac8a, osmo-msc learns to
handle codec mismatches reported by MT. For simplicity, that patch cuts
short the msc_vlr codecs tests by validating only the first codec.
Now test the full list of codecs properly.
This also introduces testing the re-assignment that MO does to match
MT's codec limitations, and removes the "EXPECTED FAILURE" markers.
Related: OS#6258
Change-Id: Ib933554f826c1b4347dfa3f6c4f6fe086be8b133
It was true once, but not since "do CN CRCX first"
Ie433db1ba0c46d4b97538a969233c155cefac21c
Related: OS#6258
Change-Id: I94e430e4e5b5bf18dbb155258d82f599ada453e6
This is the last missing piece that allows osmo-msc to make good TFO
codecs choices.
Since the codec_filter, osmo-msc properly gathers codec options and
limitations. But the MO call leg still assigns a voice channel before
getting a response from the MT call leg, and is then stuck with that.
Add the capability to adjust the MO call leg's codec in case the MT side
needs a different codec for TFO.
This is only relevant for 2G; on 3G we always have AMR/IuUP.
For inter-MSC handover, keep the behavior unchanged: offer only the
currently assigned codec to the remote side. Codec-changing HO should be
equally trivial to implement, but that is for another day.
msc_vlr_test_call's codec tests are adjusted to test the new feature in
Ib933554f826c1b4347dfa3f6c4f6fe086be8b133. For now, avoid change in
these tests by validating the first codec in SDP lists only.
Related: OS#6258
Related: osmo-ttcn3-hacks I402ed0523a2a87b83f29c5577b2c828102005d53
Change-Id: I8760feaa8598047369ef8c3ab2673013bac8ac8a
Neels Hofmeyr
Pau Espin
Vadim Yanitskiy
Andreas Eversberg