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
"[ESTABLISHED] transition to state ESTABLISHED not permitted"
i.e. don't complain when we already are in the established state.
Change-Id: I9b1fd63ed1ee7ed2877a4b2059386354598f4ea4
The cfg bits are for AMR-HR, not GSM-HR. The function
gsm0808_enc_speech_codec_list2() will return -EINVAL when it encounters
GSM-HR with non-zero cfg bits.
It appears this mapping was never used before, and my testing of call
re-assignment to match MT's codecs (it allows more than just the
assigned codec, because it can re-assign) has uncovered this bug
via MSC_Tests.TC_ho_inter_msc_out. I don't fully understand all the
details why we didn't see this before; anyway, the fix is obvious.
Change-Id: I19cff847a0f618ad000d12c1df54c55ef2f79699
The SGs interface is currently only casually mentioned in the chapter
running, even though the SGs interface is a prominent and often
requested feature. Let's give the SGs interface its own section so that
users can find the info about it quicker.
Related: OS#6008
Change-Id: Ic7c17511ee19cb7f6d5069b27beb661ecb4b0be8
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
Only the originator may terminate the VGCS/VBS call. This will not
happen in real life, because the UI of the MS should not allow
termination of a recevied VGCS call.
Change-Id: Ibe289920fa3ea50dd3e7d5c1371456dca9b72604
Related: OS#4854
Certain calls (seen on very old Nokias) won't have the rate adaptation flag
set on "analog" CSD calls. The field for the intermediate rate (after RA) is
still filled correctly.
Workaround this by setting the RA to V.110 whenever the RA is unset but an
intermediate rate is specified.
Change-Id: I5b3e5649fe071636f1becddfbfee06f9175a5f17
Bearer capability 3k1_AUDIO and FAX_G3 are only important
for the interworking function, the MSC should handle
these calls the same as CSD calls with unrestricted digital
bearer capability.
Change-Id: I198aa867a8f236b8ddd05d3b2356f64b876fd4c1
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
If the GSUP request message to which we are replying is an MT SMS
delivery from an SMSC relayed via OsmoHLR, we must set destination_name
in our reply - otherwise our reply won't make it back to the SMSC.
Related: OS#6135
Change-Id: I892fe87a733a78ed9d5761a8ce238caa135dea1e
The intent of the guard timer is to clear hung or stuck states
during call setup or teardown. However, there are some MNCC
messages that will be exchanged between OsmoMSC (passing CC
messages to and from the MS) and the external MNCC agent during
the active call state, not related to setup or teardown: DTMF
start and stop, plus call hold and retrieve operations for call
waiting. Unpatched OsmoMSC restarts the guard timer on every
received MNCC message, even those that pass through to CC without
affecting any state, and the result is breakage for users.
Consider the case of an IVR where you have to press some DTMF keys
before you can be transferred to a human operator. You press the
needed keys, get the human operator, and start talking. Then
3 minutes into your conversion (default guard timer duration)
your call unceremoniously disconnects without any warning.
Fix: look at the MNCC message type, and skip the call to start
the guard timer for known-benign MNCC messages.
Change-Id: Ibe2dd53f8e9e06d175b64df67d2a2e3e2d4155aa
This is a fixup for the patch
'3G: decapsulate IuUP to AMR at the MGW; allow 3G<-AMR->2G'
I386a6a426c318040b019ab5541689c67e94672a1
After above patch, osmo-msc intelligently decides which codecs to run on
which legs of the RTP streams. In the meantime, it seems the necessary
matching changes to call_leg_local_bridge() had been lost somehow.
Testing 3G to 3G voice now, I noticed that call_leg_local_bridge()
overwrites the intelligent choices made earlier.
The history of an MGW endpoint that should convert from IUFP to plain
AMR, extracted from a pcap, looks like this:
<- CRCX None None
-> CRCX-OK audio 4050 RTP/AVP 112 None
<- MDCX audio 4056 RTP/AVP 112 AMR
-> MDCX-OK audio 4050 RTP/AVP 112 AMR
<- MDCX audio 4056 RTP/AVP 96 VND.3GPP.IUFP
-> MDCX-OK audio 4050 RTP/AVP 96 VND.3GPP.IUFP
So after call_leg_local_bridge(), there is an extra MDCX + MDCX-OK that
switches the codec from 112 AMR back to 96 IUFP.
That is because call_leg_local_bridge() copies the *RAN* side's codec to
both CN sides, which used to be ok when RAN and CN codecs were always
identical.
Instead, adjust only the CN sides of the MGW endpoints, and adjust them
so that both CN sides are identical. osmo-mgw should then be able to
trivially translate the codecs appropriately.
Change-Id: I130bcd77ec57e332370c487a11b0b973b6e1089d
Fail if MNCC tries to switch the Information Transfer Capability from
CSD to speech, so it is obvious that something is wrong here. I ran into
this while writing a test.
Related: OS#4394
Change-Id: Ibb76d08cad1ac3bc3320391c89766150a2e605c3
Reject any other codec than GSM0808_SCT_CSD in Assignment Complete from
RAN, if OsmoMSC is preparing a CSD call.
Related: OS#4394
Change-Id: I94de84df41bcd050d0e7b4e4fea1c6a6551ef7d3
Instead of asserting on an empty list of bearer services, return
-EINVAL. This makes the function more similar to
sdp_audio_codecs_to_gsm0808_channel_type which also doesn't assert if
an empty list of codecs is passed.
Related: OS#4394
Change-Id: I15a389e1f7a9d3d17b6531c9836d3d5f9d148267
The MS in general provides the Selected PLMN ID (IE) in the Complete
Layer 3 Information message. osmo-msc handles that message in
msc_a_ran_dec_from_msc_i() and stores the information of the PLMN in
msc_a->via_cell. If no PLMN information is provided in the message, then
at that same place the PLMN configured in the VTY is taken as an implicit
default.
This patch changes trans_lcls_compose() to use the PLMN stored in
msc_a->via_cell instead of the VTY configured one, meaning the PLMN
provided by the MS (through the RAN in use) is used if available
(otherwise the VTY-configure one is still used, as before).
With this patch the PLMN VTY config option use is relegated to a single
point of use in msc_a_ran_dec_from_msc_i() where the Complete Layer 3
Information is used. As a result, it becomes clear now that the VTY
config is only applied in the scenario where no PLMN is provided at that
time.
Related: SYS#6360
Change-Id: Ibad0005a1d7cef64dd8fefa3e554ba99a06c3666
The MS in general provides the Selected PLMN ID (IE) in the Complete
Layer 3 Information message. osmo-msc handles that message in
msc_a_ran_dec_from_msc_i() and stores the information of the PLMN in
msc_a->via_cell. If no PLMN information is provided in the message, then
at that same place the PLMN configured in the VTY is taken as an implicit
default.
The PLMN information stored in msc_a->via_cell is then finally stored
into vsub->cgi in evaluate_acceptance_outcome().
This patch changes gsm0408_loc_upd_acc() to avoid re-applying the PLMN
configured at the VTY again, and instead use whatever is already in
vsub->cgi. This is more correct since the PLMN provided by the MS takes
precedence over the implicitly configured one, meaning several PLMNs can
be handled. Otherwise, the code is always overwriting the PLMN announced
by the network on a specific RAN with the one in the MSC, which may end
up with unexpected results.
Related: SYS#6360
Change-Id: I421bd63a264db2bf6e1c4a4eea976f389e87b332
Currently this function fails to initialize all bcap fields properly,
so the resulting CC Setup message generated by osmo-msc has some
fields set to reserved/invalid values.
With these changes I am able to establish a data call on TCH/F9.6:
* cap->{mode,coding}: assign default values explicitly;
* cap->radio: value 0 is reserved, set GSM48_BCAP_RRQ_FR_ONLY;
* cap->data.sig_access: value 0 is reserved, set GSM48_BCAP_SA_I440_I450;
* cap->data.transp: this is not a bool, set GSM48_BCAP_TR_{TRANSP,RLP};
* cap->data.{nr_{data,stop}_bits,parity}: set 8N1 by default;
* cap->data.modem_type: explicitly assign default value;
* cap->data.interm_rate: value 0 is reserved, set GSM48_BCAP_IR_{8k,16k}.
The related libosmocore.git patch additionally fixes encoding of the
"Connection element (octet 6c)", so that bcap->data.transp is used.
Change-Id: If49c89e4f867bac92ad062c062b9f36bab2b4531
Related: libosmocore.git I7339908864e8a2aef6f2b48a108650167e413c7f
Related: OS#6110, OS#4394
Without the gsm0808_speech_codec functions:
* codec_mapping_by_gsm0808_speech_codec_type(), and
* codec_mapping_by_gsm0808_speech_codec()
fail to find the codec mapping for CLEARMODE.
Change-Id: I87b3aedaf7ff7bbbcb381e94158566dc765e3ae6
Related: OS#6110, OS#4394
As per 3GPP TS 48.008, section 3.2.2.103, the Codec Type is valid if
at least one of FI, PI or PT is set to '1'. Otherwise the Speech
Codec Element is considered invalid and shall be ignored.
Change-Id: Ibc452d37d4215c961a7946eef3ba2e7efdba078b
Related: OS#6110, OS#4394
Whenever we call build_tlv() we must
call destroy_tlv() after we are finished with it.
Similarly, smpp34_unpack() makes calls to smpp34_malloc()
and these need to be free'd by us later.
Change-Id: Ic2abcbe78cf7cf7b6ce36fe09aa9b4f8daee973f
Voice group call and voice broadcast call messages as well as assignment
result are forwarded to VGCS/VBS call control.
Change-Id: Ie68eedb8fcb064a55cd71b58630d7a8c8b5f29ad
Related: OS#4854
When sending or receiving BSSMAP reset msg, the ongoing VGCS/VBS SCCP
connections are cleared. E.g. this happens if the BSC is restarted and
there is an ongoing VGCS/VBS call at this BSC.
Change-Id: Ib0b309150b82148098d05cfb1fb18767283e654e
Related: OS#4854
When the calling phone releases the uplink before it has been assigned
to the group channel, it will send an UPLINK RELEASE message on the
dedicated channel.
This message is forwarded to VGCS state machine to handle the release
there.
Change-Id: Ie8f7338da18eaaefbb022c09b96f18a3d78f8a95
Related: OS#4854
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
There is no GSM0808_DATA_RATE_TRANSP_300 (not in libosmocore and not in
3GPP TS 48.008 § 3.2.11 on which the enum is based). As I understand it,
we need to use GSM0808_DATA_RATE_TRANSP_600.
As pointed out in review, either TCH/H2.4 or TCH/F2.4 would work for
rates below 9600, so use GSM0808_DATA_FULL_PREF.
Use GSM0808_DATA_FULL_BM instead of GSM0808_SPEECH_FULL_BM. The value is
0x8 for both, but this is the correct name.
Related: OS#4394
Change-Id: I7297cc481fbe36355b5231ca800cf566a1ee93c0
VGCS/VBS messages from BSS are decoded and a receiver funktion for
the GCC/BCC (VGCS/VBS call control) is selected.
Change-Id: Ief6259ba3914eeaceb063b562a0bcbc48349ce60
Related: OS#4854
Andreas Eversberg
Neels Hofmeyr
Philipp Maier
Manawyrm
Oliver Smith
Pau Espin
Vadim Yanitskiy
Keith Whyte