Age | Commit message (Collapse) | Author | Files | Lines |
|
Change-Id: I315ba8c67fbb5bec520f1bc42aedd25d47e4ca95
|
|
We shall not include additional BCD length octet into the value part
of SM-RP-OA (Originating Address) IE. Instead, there should be
ToA/NPI header (1 octet).
Since we do not get ToN/NPI fields from the VLR/HLR, let's assume
the following default values:
1... .... = Extension: No extension
.001 .... = Type of number: International (1)
.... 0001 = Numbering plan: ISDN/telephone (E.164/E.163) (1)
Change-Id: I0f32e2af0ed2d2fea6addf45efbdfee120c2425d
TTCN-3 test case: Ib467eeca6439bc6cce72293fbb5bb48f6d233db9
Related: OS#4324
|
|
Because there is no real need for that.
Change-Id: I19d4d0de0d5a46bf1de194b966f18ea8a84ced94
|
|
Change-Id: I77e7a1501f74b9045f032c5b6c2322025a11fd59
|
|
seemed like a good idea, but not sure if we need it at all.
Change-Id: I5fa55307a6abb8bbfe56619235d7b79fbbda6caf
|
|
Make build and external tests work with python3, so we can drop
the python2 dependency.
This should be merged shortly after osmo-python-tests was migrated to
python3, and the jenkins build slaves were (automatically) updated to
have the new osmo-python-tests installed.
Related: OS#2819
Depends: osmo-python-tests I3ffc3519bf6c22536a49dad7a966188ddad351a7
Change-Id: I53ccde96dd3785098df0f7d693c504c8b8302e90
|
|
In order for osmo-hlr to be able to 100% guarantee distinct INDs for CS and PS,
set CN-Domain = CS in all SendAuthInfo Requests.
In Milenage auth, it is highly desirable that osmo-hlr guarantees use of
distinct INDs for CS and PS domains. If an MSC and SGSN attached at the same
time use the same IND bucket to generate Milenage SQN, that collision would
rapidly waste SQNs and load osmo-hlr with requesting new auth tuples on each
CS/PS Complete-Layer3.
So far, osmo-msc did not indicate the CN domain in the GSUP SendAuthInfo
Request, which was neither required nor evaluated. The CN-Domain is only sent
for the UpdateLocation Request that usually follows later.
Related: OS#4318
Change-Id: I22f44068268e62801cadbf6542efaf153423cd65
|
|
Change-Id: Iad858974e9d97ae14f3da6dc21267aafafcda0ef
|
|
Change-Id: Ib7ba8909dce64d1b8ff3a53495fe3eefc446ed8e
|
|
Change-Id: I273bc4165c70cd54ed94ff5f99377189f3306f51
|
|
Change-Id: Iad1ef917a229c3be51bd8fbe155f009f81e7d72a
|
|
Change-Id: I4f4a0d644db0a2dd7c8eefd846ea6913c0b780ce
|
|
Please note that counter "sms:delivered" assumes "Delivered MT SMS",
but actually counts total number MT SMS delivery attempts. This
change describes its _actual_ (erroneous) behaviour.
Change-Id: I081cf962ce2658ceab02699f3cdee19658d00939
Related: OS#4273
|
|
Change-Id: I4cce3d6798fe3184a3085d114b749b4645620978
|
|
Change-Id: I2c03d8424c218155dae9038dd7cc5660a290c5c8
|
|
Change-Id: I2bc34f3962ca7355f20757e36a86ab2fd1a7aef6
|
|
Change-Id: I46a41321e6d1be3672a56a6e3cc36f013fdcd396
|
|
Change-Id: I2b28a94a5b27932e343952ba82e7e11c46f5e87d
|
|
Change-Id: I03b25c134553c620d3fa9d23a67ad39414546861
|
|
Change-Id: I3edd90be40555dd648e9f16db5b6040665a19a95
|
|
Add a char buffer of 1024 characters length as space for SDP to pass to /
receive from MNCC.
Actually support receiving MNCC without such an SDP tail. The main reason for
this is to avoid the need to adjust the ttcn3 implementation of MNCC: it would
stop working for older osmo-msc.
Older or non-SIP MNCC peers could operate the previous MNCC protocol unchanged
(save the protocol number bump) without having to implement SDP.
The SDP part in the MNCC protocol will be used in upcoming patch
I8c3b2de53ffae4ec3a66b9dabf308c290a2c999f.
This patch must be merged at the same time as osmo-sip-connector patch
Iaca9ed6611fc5ca8ca749bbbefc31f54bea5e925, so that both sides have a matching
MNCC protocol version number.
Change-Id: Ie16f0804c4d99760cd4a0c544d0889b6313eebb7
|
|
Rationale: in order to add full SDP to the MNCC protocol (upcoming patch
I8c3b2de53ffae4ec3a66b9dabf308c290a2c999f), we need to parse and compose SDP
messages. Obviously, libosmo-mgcp-client already contains similar code, but
that is unfortunately heavily glued to the actual MGCP implementation. The
simplest solution is to create this separate implementation, copy-pasting from
the existing libosmo-mgcp-client code as is convenient.
This API is added here to probe whether it works well. When it does, the
intention is to "move it up" to osmo-mgw and overhaul the SDP parsing in our
MGCP client and MGCP server APIs using this same API.
Change-Id: If3ce23cd5bab15e2ab4c52ef3e4c75979dffe931
|
|
Do not free the CC transaction when an MT subscriber is already being Paged.
Instead, invoke another paging request, which paging.c will correctly add to
the list of pending paging response callbacks to run.
A ttcn3 test is linked in the related patch (s.b.).
Related: OS#4240
Related: Ieeae6322d4e80893ea3408c6b74bf8e32bea8e46
Change-Id: Idd4537b5f4817d17e5c87d9a93775a32aee0e7be
|
|
Change-Id: I9d7d7d4073282abc6c02a6a297c807dc70c5154c
|
|
When the CRCX OK returns an invalid RTP address, abort the call; fixes
MSC_Tests.TC_invalid_mgcp_crash.
The original crash happened when adding this error handling without this commit
I08c03946605aa12e0a5ce8b3c773704ef5327a7a ("fsm: use deferred deallocation" for
osmo-mgw I7df2e9202b04e7ca7366bb0a8ec53cf3bb14faf3 "fix use-after-free: require
new fsm deferred dealloc, check for term"). With this error handling added,
even though avoiding a crash, the test does not pass yet, because instead of
rejecting the call, it currently composes an Assignment Command without a
Transport Layer Address. Fix that.
Change-Id: I00c3b5ff74c05bcc2b7c39375c33419916a57193
|
|
Fix typos and common misspellings in code comments and log messages.
Change-Id: Ie66b89065f2100c1d2125ce5a6c9b1d58df7c8ad
|
|
Actually decode the Codec List (BSS Supported) in BSSMAP, in both the Complete
Layer 3 Information and the Assignment Complete messages.
An upcoming patch improves codec negotiation and requires the BSS supported
codecs, which are so far ignored (which is/was a pity as osmo-bsc goes at great
lengths to compose those IEs).
Change-Id: I66c735c79e982388f06b5de783aa584c9d13569e
|
|
Substantial parts of the CC / MNCC call establishment were so far completely
missing from the msc_vlr_test_call.c tests. With my new insights on CC and MNCC
procedures, complete the tests.
Root reason: since I am going to re-order the sequence of events to enable
codec negotiation via SDP in MNCC, I want to have comprehensive tests of the CC
procedures to see the effect as diffs in the test output.
Change-Id: Ie995e264eb1e3dd9558a1753ff6f9b55c1d084e1
|
|
Use of this flag was dropped when adding inter-BSC and inter-MSC Handover
support, I forgot to remove it.
Change-Id: I5ec78e30eb36fbe78a3f7c46bfa44af5a4eb7bf2
|
|
Add voice_call_full.msc, generated from a real 2G<->3G voice call log fed to
msc_log_to_ladder.py.
The idea is to document how the voice call sequence of events changes in
upcoming patches.
Change-Id: I8a907d6a4ece1f3ad78da75a8c3e3e76afd5418d
|
|
Add script that reads in an osmo-msc log output and extracts the interesting
information for displaying a sequence chart of voice call log, in mscgen
format.
I want to visualize how the sequence of messages changes across patches. It is
error prone to do it manually, and re-doing the sequence chart for every patch
(and patch rework) would be prohibitively time consuming.
Change-Id: I2e4d8778f7b83dee558517a9b23450b817ee325d
|
|
Fix three 'FIXME: ERROR HANDLING' occurences in the code that reacts upon the
MGW providing (or failing to provide) an RTP port for the RAN side. From an
earlier stage of the code, the cleanup for this situation was extremely
complex, and hence the choice was to simply wait for the call to time out and
fail. But since we have implemented safe deallocation of nested FSMs in
libosmocore, the situation has become rather trivial: simply free the CC
transactions, and all the rest will immediately release, and terminate
correctly without crashing.
A ttcn3 test for this is MSC_Tests:TC_invalid_mgcp_crash, which actually also
needs the change to osmo_sockaddr_str_is_nonzero() in preceding patch
I53ddb19a70fda3deb906464e1b89c12d9b4c7cbd, so that a seemingly valid MGCP
message ends up causing a failure in the on_success() branch of
mgcp_client_endpoint_fsm.c.
Change-Id: I8313bed1d782100bebeac7d8fc040557c4cb653e
|
|
Also regard an RTP port as invalid if the IP address is 0.0.0.0.
Achieve this by using osmo_sockaddr_str_is_nonzero() instead of
osmo_sockaddr_str_is_set().
Depends: I73cbcab90cffcdc9a5f8d5281c57c1f87b2c3550 (libosmocore)
Change-Id: I53ddb19a70fda3deb906464e1b89c12d9b4c7cbd
|
|
libosmo-mgcp-client recently introduced osmo_mgcpc_ep_cancel_notify() to cancel
notification if a notify target FSM deallocates. Use it for sanity in
rtp_stream FSM cleanup, the notify target for endpoint FSMs.
Depends: I41687d7f3a808587ab7f7520f46dcc3c29cff92d (osmo-mgw)
I14f7a46031327fb2b2047b998eae6ad0bb7324ad (osmo-mgw)
Change-Id: I351bb8e8fbc46eb629bcd599f6453e2c84c15015
|
|
Since osmo-bsc uses the MGCP client FSMs, it is required to enable this new
feature to guarantee safe operation. The issue is described in detail in commit
logs linked below.
Notably, osmo-msc currently chooses to omit error handling during MGCP events
(marked "FIXME"). An upcoming patch implements this error handling, and would
make osmo-msc vulnerable to crash from unexpected MGCP messages without this.
Deferred FSM deallocation is a more general, simpler approach to
osmo_fsm_term_safely(), so we can switch that off now.
Depends: Ief4dba9ea587c9b4aea69993e965fbb20fb80e78 (libosmocore),
I0adc13a1a998e953b6c850efa2761350dd07e03a (libosmocore)
Related: I7df2e9202b04e7ca7366bb0a8ec53cf3bb14faf3 (osmo-mgw)
Change-Id: I08c03946605aa12e0a5ce8b3c773704ef5327a7a
|
|
Change-Id: I07b2b6c0ee33f5d3e0a060c10cf36d5c7c9f0d9b
|
|
Change-Id: I691025cb957e9b87c8af2dc8eb741dcba6ca26e2
|
|
Change-Id: Ib0e0630d775a28958ea86802f70cbeec07087f91
|
|
Before:
RAN decode: BSSMAP: Rx BSSMAP DT1 COMPLETE LAYER 3
After:
RAN decode: BSSMAP: COMPLETE LAYER 3
This caught my attention while I was writing up a script to parse osmo-msc
logging to produce ladder diagrams.
Change-Id: I387dde8f2eb3edb35d22ce52dc0ed580978dea36
|
|
If an incoming MNCC_SETUP_REQ ends up in Paging (as usually it does), the early
return so far skipped logging of that MNCC message. Add this logging.
Change-Id: I1495dd562a06cf6c1e9453a1fe111bdf8f4be081
|
|
Fix vty tests that are failing since libosmocore change
Ic225232fbfca49ba868427eaf898e1f6e34e1ca8. If OsmoMSC is built without
IU support, it fails with "cs7-instance-iu" in the config.
Change-Id: Ie56da9167badfd2399b566af91a345103f46c2a1
|
|
Change-Id: I46055a4f7a6ae517772c6794faad8c775454974a
|
|
So far, the logging said only "RAN encode: BSSMAP: DTAP", but not *which* DTAP
message, which is in fact a very interesting detail when reading osmo-msc logs.
Change-Id: I0cb8d1e3307737ffe53730c64bb984adacedb2da
|
|
For all CC type transaction logging, log the current trans->cc.state string for
all LOG_TRANS*() logging.
Change-Id: I67be12c74c679ce684f8c0b9b4e0d96299849dc6
|
|
The HLR might respond with a specific GMM cause code. E.g. roaming not
allowed which needs to be passed down the layers.
Change-Id: I9af515dc52834b7c57c42fc3a76ee2c682734e2a
|
|
To be used by vlr_auth_fsm
Change-Id: I9e13e756f359a9b9e6a2056ab37adf0af14afec1
|
|
When a vlr_subscr receives an Send Auth Info result, properly check whether the
subscriber has an auth_fsm.
Before, a missing auth_fsm would crash osmo-msc with:
vlr.c:762 Trying to dispatch event 1 to non-existent FSM instance!
Related: OS#4191
Change-Id: I1995d8f68cfde1140968fb9a97bd054de950de2e
|
|
When pagig for a CS-Call via SGs times out, the MME expects to be
informed about this via an SGsAP-SERVICE-ABORT-REQUEST, make sure this
message is sent, but only for CS-Fallback calls.
Change-Id: I3f8f153afe24cf2efa245713509bdc8488902877
Depends: osmo-ttcn3-hacks I99950a17ccf26aaa0eebded5480f33be4c57586a
Related: OS#3614
|
|
3GPP TS 29.118, chapter 7.5 states that unknown TLV elements should be
ignored rather than that the whole message is discarded a STATUS message
is sent. Lets turn the returncode check of the tlv_parse() call into a
log message and continue normally.
Change-Id: Ic6714451ad970043d4765f8420d753daf5294a44
Related: OS#4214
|
|
When an MS returns the IMEISV in the BSSMAP Cipher Mode Complete message in
the Layer 3 Message Contents IE, do not re-invoke the decode_cb() a second
time, but instead point to it from the ran_msg.cipher_mode_complete struct.
When the MSC-A decodes the Ciphering Mode Complete message, it always wants to
also decode the enclosed DTAP from the Layer 3 Message Contents IE. However,
when the MSC-I preliminarily decodes messages, it often just wants to identify
specific messages without fully acting on them, let alone dispatching RAN_UP_L2
events more than once. So leave it up to the supplied decode_cb passed to
ran_dec_l2() implementations to decide whether to decode the DTAP.
In msc_a.c hence evaluate the DTAP by passing a msgb to msc_a_up_l3(), which
will evaluate the RR Ciphering Mode Complete message found in the BSSMAP Cipher
Mode Complete's Layer 3 Message Contents IE.
Particularly, the previous choice of calling the decode_cb a second time for
the enclosed DTAP caused a header/length parsing error: the second decode_cb
call tried to mimick DTAP by overwriting the l3h pointer and truncating the
length of the msgb, but subsequently ran_a_decode_l2() would again derive the
l3h from the l2h, obliterating the intended re-interpretation as DTAP, and
hence the previous truncation caused error messages on each and every Cipher
Mode Complete message, like:
DBSSAP ERROR libmsc/ran_msg_a.c:764 msc_a(IMSI-26242340300XXXX:MSISDN-XXXX:TMSI-0xA73E055A:GERAN-A-77923:LU)[0x5563947521e0]{MSC_A_ST_AUTH_CIPH}: RAN decode: BSSMAP: BSSMAP data truncated, discarding message
This error was seen a lot at CCCamp2019.
Modifying the msgb was a bad idea to begin with, the approach taken in this
patch is much cleaner.
Note that apparently many phones include the IMEISV in the Cipher Mode Complete
message even though the BSSMAP Cipher Mode Command did not include the Cipher
Response Mode IE. So, even though we did not specifically ask for the Cipher
Mode Complete to include any identity, many MS default to including the IMEISV
of their own accord. Reproduce: attach to osmo-msc with ciphering enabled using
a Samsung Galaxy S4mini.
Related: OS#4168
Change-Id: Icd8dad18d6dda24d075dd8da72c3d6db1302090d
|