Age | Commit message (Collapse) | Author | Files | Lines |
|
In osmo-mgw, we recently chose 256 for maximum fmtp length.
Adjust to that here, too.
Change-Id: Ib9b9608d8d8f7ce34596a950dbc480e8a72ebf97
|
|
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
|
|
Related: OS#6258
Change-Id: I0905a1264cd8f940c7a9964addf241091425fe72
|
|
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
|
|
Used by I8760feaa8598047369ef8c3ab2673013bac8ac8a to add just a single
codec to a speech codec list, instead of a list.
Change-Id: I6ac23c54bc26939e048ff2df06eb987421cfb1c5
|
|
To parse and handle SDP included in incoming MNCC, use rx_mncc_sdp()
everywhere. So now rx_mncc_sdp() is the single implementation for
parsing the SDP string and taking action for codecs if needed.
One current dup of this code has a fall-back to use legacy bearer cap --
absorb that into rx_mncc_sdp(), so that we now also do that fall-back
for all of the incoming MNCC that contains bcap.
This is a cosmetic preparation for implementing MO Re-Assignment to
match MT's codec limitations.
Change-Id: I94ae11654e1f88fbd64361b639a4c583836dc13e
|
|
We're checking the result of trans_alloc() 6 out of 7 times, so check
it in gsm_silent_call_start() too, for the sake of consistency.
Change-Id: Ie989cd8146d66d9531cf3f3d84f46a2c6fcc2e5c
Fixes: CID#322140
|
|
Related: OS#6272
Change-Id: Ic710873f9203414b343b216097785cef36ca05a9
|
|
"[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
|
|
Change-Id: Ia7a90b7c192702bb71ee55df92cb05030fe5dd03
|
|
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
|
|
Change-Id: I5e4891091c2ce56d4fd4a7f5f67156a94ade852d
Related: OS#4854
|
|
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
|
|
Change-Id: I1de0f35f1606c997777f34bbf4033e069aadbc64
|
|
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
|
|
Change-Id: Ifc4bfe8b4154fa892a4d15d54cee34b501038c20
|
|
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
|
|
Related: OS#4394
Change-Id: I5fea299bdc19d2979b5c222d8dd265dac2068307
|
|
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
|
|
Change-Id: Ib707fa66ae789abfa8795b4e521a16e24c77647d
|
|
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
|
|
Change-Id: I1b692cee894826a306885253a53a351f952d52dc
Related: OS#4854
|
|
Change-Id: I3fbce71e47e9670f58e46e7c2a0f26a1bbc1a46e
Related: OS#4854
|
|
Otherwise we may fail to initialize cap->data.{user,interm}_rate.
Change-Id: Ibfb71d1ece502585b55db0f28069a6aa0666b9df
Related: OS#6110, OS#4394
|
|
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
|
|
Change-Id: I4095124be8ffb293863f35bea440cd465048a9fd
Related: OS#6110, OS#4394
|
|
Change-Id: I23d94c2d81c929deb819c02f4ddac3a702a3867d
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
|
|
Fixes: CID#322139
Change-Id: I8de1fce76ba36a06384581e3a1af706b41cad1fe
|
|
Fixes: CID#322142
Change-Id: Iab0b66dfcfdb870eaec4611720ce3a5f2089bd21
|
|
Fixes: CID#322143
Change-Id: I65cdf2b7feaa72167c8002cd4d47183f99cab761
|
|
Fixes: CID#322145, CID#322141
Change-Id: Iec0820f612450cde772076131b07fe7819d35790
|
|
Fixes: CID#322147
Change-Id: I1676d3cbf844930a6a433253f055a3f8fe3c210b
|
|
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
|