So far, the selected codec needs to be a member of the list. Instead,
make this API safe for any instance, member or not, by looking it up.
Remove the lookup from the only caller.
A subsequent patch adds another caller that would have needed a manual
lookup before calling sdp_audio_codecs_select().
Change-Id: Ic1b5ba46c6f4c58e518b080bcb9b5741cb70ccc3
Instead of generating the default codecs list for a RAN for each call,
place a pre-composed list in ran_infra.c.
(1) The main aim is to allow configuring this list -- subsequent commit
Ib5655214ce48c66d095e8f1b7b7106ac3ee43ec0 will add the VTY commands to
modify the predefined lists.
(2) As a free side effect, this also allows configuring the order of
preference for specific codecs.
(3) It may also save us some iterations of the codec_map[], which may
grow a lot more variants; for example, we could add one entry for each
possible AMR mode-set...
Change-Id: If46231a53f7512dbd81790fd30462d65fe059aa3
These changes will allow dynamically negotiating AMR rates between 2G
and 3G, and between full-rate and half-rate, spanning from 2G and 3G RAN
all the way across to SDP over MNCC / SIP and back.
To ran_msg_assignment, add a full codecs list (sdp_audio_codecs).
So far, there was only the gsm0808_channel_type with a list of
permitted-speech entries, which is not a complete representation.
This patch only adds the list, the two users of this are added in
separate patches:
[2/3] In ran_msg_a.c for 2G:
Before this, we pass a gsm0808_channel_type to ran_msg_assignment, and
from *that* we derive a gsm0808_speech_codec_list -- this loses the AMR
rate config bits. So far, we always transmitted the default cfg bits
defined in gsm0808_speech_codec_defaults, enabling all supported S0-S15
AMR rate combinations. Instead, we'll directly derive the available AMR
rates from the list of SDP codecs resulting from the codecs filter.
[3/3] In ran_msg_iu.c for 3G:
Before this, we compose a fixed set of RAB SDU subflows, i.e. for
exactly and only AMR 12k2. Now, we'll ask for RAB subflows corresponding
to the AMR codec's mode-set fmtp present in the codec list.
Change-Id: Ia9f4ad7f3646556aadc632bc5ffa477941626c5f
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
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
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
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
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
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
Used by I8760feaa8598047369ef8c3ab2673013bac8ac8a to add just a single
codec to a speech codec list, instead of a list.
Change-Id: I6ac23c54bc26939e048ff2df06eb987421cfb1c5
When trying to modify the value of an SGs counter (eg. ns11), then the
setting is never stored. The reason for this is that OsmoMSC uses the
wrong string table to compare the user input.
Related: OS#6008
Change-Id: I0358c1ec0026c37fda6db1f3af3145393df25cfd
For MO-forwardSM and MT-forwardSM request messages, OsmoHLR applies
routing based on the SMSC address for MO or based on the IMSI for MT.
However, reply messages following these requests are routed passively
based on the destination_name IE. This passive message routing path
requires the source_name IE to be set as well - implement this
source_name setting.
Related: OS#6135
Change-Id: I0b7f4760bdce8a38d43d3860086c6dfb7b390701
When OsmoMSC is used with OsmoHLR rather than a GSUP-to-MAP gateway,
MT-forwardSM.req GSUP messages delivering MT SMS will be coming from
a separate SMSC relayed via OsmoHLR, rather than from OsmoHLR itself.
When we reply to these messages, in order for these replies to reach
the MT-sending SMSC via OsmoHLR, we need to save source_name from
the request and regurgitate it into destination_name in our response
messages. Implement this logic.
Related: OS#6135
Change-Id: I436e333035b8f6e27f86a49fe293ea48ea07a013
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
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
- 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
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
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
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
Neels Hofmeyr
Andreas Eversberg
Philipp Maier
Oliver Smith
Pau Espin
Vadim Yanitskiy