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
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
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
For all 3G calls, convert IuUP <-> plain AMR/RTP on the MSC's MGW hop
like this:
Before this patch:
hNodeB <--IuUP--> MGW@hnbgw <--IuUP--> MGW@msc <--IuUP--> other call leg
After this patch:
hNodeB <--IuUP--> MGW@hnbgw <--IuUP--> MGW@msc <--AMR--> other call leg
^
This allows, in principle, 2G to 3G calls without expensive transcoding,
like this:
hNodeB <--IuUP--> MGW@hnbgw <--IuUP--> MGW@msc <--AMR--> MGW@msc <--AMR--> MGW@bsc <--AMR--> 2G-BTS
^
(So far only proven to work with AMR-FR at 12k2.)
3G to 3G calls now look like this:
hNodeB <--IuUP--> MGW@hnbgw <--IuUP--> MGW@MSC <--AMR--> MGW@MSC <--IuUP--> MGW@hnbgw <--IuUP--> hNodeB
^
Implementatino: get rid of the shim that was put in place to still send
IuUP (VND.3GPP.IUFP) to the CN. So now, for all 3G voice, the IuUP gets
decapsulated to plain AMR/RTP at the MSC's MGW hop.
What is proven to work with this patch:
successful voice call between 2G and 3G with these conditions:
- a hNodeB that stubbornly accepts only 12k2 AMR;
- a 2G BTS configured to use only TCH/F and only FR3, with only 12k2 as
allowed AMR rate.
We have not yet seen a call working for TCH/H HR3 <-> 3G, because of the
lab hNodeB's limitation to 12k2.
Future work we probably need:
- properly request and negotiate AMR rates via SDP fmtp:mode-set.
- request more RFCIs in our RANAP RAB Assignment requests
(see I61e0e9e75e3239662846fd797532acdefa9f73dc).
- Convert IuUP to AMR already at the HNBGW's MGW?
Solving this is not part of this patch.
Related: SYS#5092
Change-Id: I386a6a426c318040b019ab5541689c67e94672a1
In msc_vlr_test_call, we fail to send the right MNCC struct for
MNCC_RTP_CREATE. We should pass a struct gsm_mncc_rtp. Fix that.
Change-Id: Ia0b3253f85c716e45f925da3f58f025af1f15ec9
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
Transmit and receive full SDP information via MNCC, to accurately pass
codecs choices between the call legs.
In msc_vlr_test_call.c test_call_mt(), show that when receiving MNCC,
the codec information in SDP overrules the Bearer Cap codec information
-- we expect to still receive inaccurate Bearer Cap from e.g.
osmo-sip-connector, because we have chosen to add SDP to MNCC instead of
trying to fix the codecs represented in Bearer Cap.
For internal MNCC, the MT call leg now knows which codec the MO has
chosen and assigned.
For external MNCC, osmo-sip-connector receives SDP about our codecs
choices and sends it in SIP messages, and we also receive the full SDP
information from the remote SIP leg.
Update the SDP in codec_filter every time it is received, to always have
the latest SDP information from the remote leg.
CC MNCC
| ---ALERTING--> | add local side SDP to MNCC msg
| <--ALERTING--- | store remote side SDP
| <--SETUP-RESP- | store remote side SDP
| --SETUP-CNF--> | add local side SDP to MNCC msg
| -RTP-CREATE--> | use codec_filter, add local side SDP to MNCC msg
| <-RTP-CONNECT- | store remote side SDP
There still is one problem: when initiating MNCC, we do not yet know the
RTP address and port to be used for the CN side, because the CN CRCX
happens later. So far we send 0.0.0.0:0 as RTP endpoint in the SDP,
until the CN CRCX is done. A subsequent patch moves CN CRCX to an
earlier time, adding proper RTP information right from the start.
Related: SYS#5066
Change-Id: Ie0668c0e079ec69da1532b52d00621efe114fc2c
So far, patches have set up rtp_stream to allow setting multiple codecs,
and collected the codecs information into the codecs filter struct.
Now actually use the codecs filter result to choose a codec.
Setting up the call leg FSMs and codecs still looks rather confusing in
this patch, because this is an incremental step in a larger series. The
upcoming patch 'do CN CRCX first' clarifies this substantially.
The resulting codecs behavior is tested in upcoming patch
I879ec61f523ad4ffc69a0b02810591f7c0261ff9. (The test ideally should have
come before this patch, but my time to rework this branch is up.)
With the codecs filter in place, we are ready for sending and receiving
full SDP via MNCC, see upcoming Ie0668c0e079ec69da1532b52d00621efe114fc2c
and Ie433db1ba0c46d4b97538a969233c155cefac21c
Related: SYS#5066
Change-Id: I66e7c8c5e401f4f3a7d3d42b9525b2c6e99691d9
So far, we just forwarded the Bearer Capabilities received in MNCC from
the remote MO call leg, and omitted Bearer Cap if the remote call leg
did not provide any.
Instead, always include Bearer Cap, and compose it from the codecs
filter result. Hence the Bearer Cap is now an intersection of MS, BSS
and remote call leg, instead of just the remote call leg.
Related: SYS#5066
Change-Id: I9586221ef56352b7ce4b2604ae0dc04554145a78
Do not convert to enum mgcp_codecs, but directly pass the
gsm0808_speech_codec IE from the A interface to codecs handling.
For Iu:
- RAN side: use ran_infra.force_mgw_codecs_to_ran to keep the MGW
endpoint towards RAN on IUFP.
- CN side: introduce flag ran_msg.assignment_complete.codec_with_iuup,
so to decide whether to forward IUFP towards CN, we don't need to test
the RAN type, but use the flag from the ran_msg implementation.
In msc_vlr_tests, use the SDP codec string instead of enum
mgcp_codecs.
So far limit to intra-MSC related messaging, adjusting inter-MSC
handover follows in a separate patch.
Change-Id: Ia666cb697fbd140d7239089628faed93860ce671
Allow configuring MGW conns with multiple codecs. The new codecs filter
can have multiple results, and MGCP can configure multiple codecs. Get
rid of this bottleneck, that so far limits to a single codec to MGW.
On Assignment Complete, set codec_filter.assignment to the assigned
codec, and use that to set the resulting codec (possibly multiple codecs
in the future) to create the CN side MGW endpoint.
Related: SYS#5066
Change-Id: If9c67b298b30f893ec661f84c9fc622ad01b5ee5
I noticed by chance that the Assignment Complete message generated in
the test lacks a remote RTP address for the RAN side.
Make the test more realistic by adding a remote RTP address and port. It
doesn't have any bearing on the tests besides more accurately showing
RTP stream setup in the logs.
Change-Id: Ia428762a16dcc17f036d725a00e0b3767418289b
Collect either the SDP or the Bearer Capabilites in the incoming
MNCC in the new codecs filter.
So far just collect the info and do not change the behavior, using the
filter result will follow in a subsequent patch.
Related: SYS#5066
Change-Id: I84d9bbca3e4061da622b1b2fc0bde8868e7e3521
For MT call, initialize the codecs filter and apply the
Codec List (BSS Supported) from Compl L3.
Related: SYS#5066
Change-Id: I530409a64d11da48518a3dc60aa3a4e47c384663
Omit "in state FOO", because LOG_TRANS() already logs the state.
Most MNCC "rx" logging was duplicated. Log "rx" only once.
If there is RTP information passed with the MNCC message, log it:
- if there is SDP, log the SDP information.
- if there is no SDP, log the legacy MNCC RTP fields, if any.
One motivation to do this is to get RTP information in ladder diagrams
generated by msc_log_to_ladder.py without the need to add udtrace MNCC
logging to osmo-msc; and also to get RTP info for internal MNCC, where
udtrace doesn't apply, because no unix domain socket is involved in
internal MNCC operation.
Change-Id: I4b916cb482ed441b508c6295de211a21c49cd5c1
Previous patch added the AUTH_FAILURE event, which means that the
AUTH_RES event now only signals success. Reflect that in the name.
No functional change.
Related: OS#4830
Change-Id: I7124a3591fcf36cee06d7488eeb94f9b85af5dc2
Since call_leg_fsm_releasing_onenter() calls immediatelly
osmo_fsm_inst_term(), it meant we couldn't receive any event in that
state because osmo_fsm disables event dispatching to FSMs being
terminated.
As a result, CALL_LEG_EV_MGW_ENDPOINT_GONE was never received and hence
call_leg_mgw_endpoint_gone() was never called, which means the
mgcp_client used in cl->mgw_endpoint was never put back to the pool.
By first freeing all the children (rtp_streams), we make sure
cl->mgw_endpoint ends up with no conns and sends us the GONE event
before we go ourselves into termination state.
Related: SYS#5987
Change-Id: I2126578c4e64c9f336e8a1f6ee98de970866b8dc
This way the MGW knows it has to handle IuUP in that connection (answer
IuUP Initialization, etc.).
Depends: osmo-mgw.git 1de5ed6f979bd4c1380789c9a82f8e396f05c5f8
Change-Id: I7aca671e00ed27ac03f0d106b5a6b665a9bed4c1
The log output of libosmo-mgcp-client has changed. This change causes
the unit tests to fail because the log output does not match anymore.
Lets disable the DLMGCP log output since it is of minor importance
for VLR testing anyway.
Change-Id: Id197e4ab9ba12e284299ef520edee9c362513bf1
Related: SYS#5091
Calling gsm48_cc_tx_release() before mncc_release_ind() has a side
effect: the former may change CC state to GSM_CSTATE_RELEASE_REQ.
This makes the later send MNCC_REL_CNF instead of MNCC_REL_IND, so
if one of the call leg disconnects due to RF failure, the other one
will not be terminated correctly.
Makes both TC_{mo,mt}_call_clear_request TTCN-3 test cases pass.
Change-Id: I3ad4a99757878de3796027325627c87d9a4e93f1
Related: Id16969fe0de04445d1320a96d35cf1d48cc8cf09
Related: SYS#5340
The msc_vlr_tests verify whether any of the tests run contain msgb or
talloc memory leaks. So far they did so by fixating a specific number of
talloc blocks, which may break by library implementations changing.
Instead, verify that the test leaks no allocations by comparing talloc
blocks before and after each test.
When a leak is detected, print the full talloc report to stderr, which
makes the expected output mismatch the actual output and fails the test.
Related: OS#4311
Change-Id: I8537fa76d460c951302932a1bad4299f7fe398c9
So far, the cmdline argument was the only way to set a database file.
Add a similar config to VTY as 'msc' / 'sms-database'. The cmdline arg is stronger
than the 'database' cfg item. DB is not reloaded from VTY command.
Change-Id: I18d954c30fcceb0b36a620b927fd3a93dcc79f49
This patch served for a manual testing counterpart for osmo-bsc to implement
MSC pooling.
This enables a basic MSC pooling setup, but for a production setup, osmo-msc
would still lack various features related to unloading subscribers to another
MSC as explained in 3GPP TS 23.236.
Change-Id: Iafe0878a0a2c8669080d757b34a398ea75fced36
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
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
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
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
GSM 04.08 10.5.4.11
The Release indication needs to have the Coding Standard set.
For phones that would display a message on screen, such as
"Number not in use", if the coding standard is not defined,
the display may show "Error in Connection"
Change-Id: Ib28b62a41d433e231cff5910d19455296b284df6
osmo_counter will be soon deprecated. Use the newer and more flexible
osmo_stat_item instead.
Depends on: Id2462c4866bd22bc2338c9c8f69b775f88ae7511 (libosmocore)
Change-Id: I6a20123b263f4f808153794ee8a735092deb399e
When 'check-imei-rqd 1 early' is set in the config, send the IMEI to
the HLR before doing the location update with the HLR.
The OsmoHLR documentation referenced in the code will be added in
osmo-hlr.git's Change-Id I2dd4a56f7b8be8b5d0e6fc32e04459e5e278d0a9.
Related: OS#2542
Change-Id: I88283cad23793b475445d814ff49db534cb41244
3GPP TS 49.008 '4.3 Roles of MSC-A, MSC-I and MSC-T' defines distinct roles:
- MSC-A is responsible for managing subscribers,
- MSC-I is the gateway to the RAN.
- MSC-T is a second transitory gateway to another RAN during Handover.
After inter-MSC Handover, the MSC-I is handled by a remote MSC instance, while
the original MSC-A retains the responsibility of subscriber management.
MSC-T exists in this patch but is not yet used, since Handover is only prepared
for, not yet implemented.
Facilitate Inter-MSC and inter-BSC Handover by the same internal split of MSC
roles.
Compared to inter-MSC Handover, mere inter-BSC has the obvious simplifications:
- all of MSC-A, MSC-I and MSC-T roles will be served by the same osmo-msc
instance,
- messages between MSC-A and MSC-{I,T} don't need to be routed via E-interface
(GSUP),
- no call routing between MSC-A and -I via MNCC necessary.
This is the largest code bomb I have submitted, ever. Out of principle, I
apologize to everyone trying to read this as a whole. Unfortunately, I see no
sense in trying to split this patch into smaller bits. It would be a huge
amount of work to introduce these changes in separate chunks, especially if
each should in turn be useful and pass all test suites. So, unfortunately, we
are stuck with this code bomb.
The following are some details and rationale for this rather huge refactoring:
* separate MSC subscriber management from ran_conn
struct ran_conn is reduced from the pivotal subscriber management entity it has
been so far to a mere storage for an SCCP connection ID and an MSC subscriber
reference.
The new pivotal subscriber management entity is struct msc_a -- struct msub
lists the msc_a, msc_i, msc_t roles, the vast majority of code paths however
use msc_a, since MSC-A is where all the interesting stuff happens.
Before handover, msc_i is an FSM implementation that encodes to the local
ran_conn. After inter-MSC Handover, msc_i is a compatible but different FSM
implementation that instead forwards via/from GSUP. Same goes for the msc_a
struct: if osmo-msc is the MSC-I "RAN proxy" for a remote MSC-A role, the
msc_a->fi is an FSM implementation that merely forwards via/from GSUP.
* New SCCP implementation for RAN access
To be able to forward BSSAP and RANAP messages via the GSUP interface, the
individual message layers need to be cleanly separated. The IuCS implementation
used until now (iu_client from libosmo-ranap) did not provide this level of
separation, and needed a complete rewrite. It was trivial to implement this in
such a way that both BSSAP and RANAP can be handled by the same SCCP code,
hence the new SCCP-RAN layer also replaces BSSAP handling.
sccp_ran.h: struct sccp_ran_inst provides an abstract handler for incoming RAN
connections. A set of callback functions provides implementation specific
details.
* RAN Abstraction (BSSAP vs. RANAP)
The common SCCP implementation did set the theme for the remaining refactoring:
make all other MSC code paths entirely RAN-implementation-agnostic.
ran_infra.c provides data structures that list RAN implementation specifics,
from logging to RAN de-/encoding to SCCP callbacks and timers. A ran_infra
pointer hence allows complete abstraction of RAN implementations:
- managing connected RAN peers (BSC, RNC) in ran_peer.c,
- classifying and de-/encoding RAN PDUs,
- recording connected LACs and cell IDs and sending out Paging requests to
matching RAN peers.
* RAN RESET now also for RANAP
ran_peer.c absorbs the reset_fsm from a_reset.c; in consequence, RANAP also
supports proper RESET semantics now. Hence osmo-hnbgw now also needs to provide
proper RESET handling, which it so far duly ignores. (TODO)
* RAN de-/encoding abstraction
The RAN abstraction mentioned above serves not only to separate RANAP and BSSAP
implementations transparently, but also to be able to optionally handle RAN on
distinct levels. Before Handover, all RAN messages are handled by the MSC-A
role. However, after an inter-MSC Handover, a standalone MSC-I will need to
decode RAN PDUs, at least in order to manage Assignment of RTP streams between
BSS/RNC and MNCC call forwarding.
ran_msg.h provides a common API with abstraction for:
- receiving events from RAN, i.e. passing RAN decode from the BSC/RNC and
MS/UE: struct ran_dec_msg represents RAN messages decoded from either BSSMAP
or RANAP;
- sending RAN events: ran_enc_msg is the counterpart to compose RAN messages
that should be encoded to either BSSMAP or RANAP and passed down to the
BSC/RNC and MS/UE.
The RAN-specific implementations are completely contained by ran_msg_a.c and
ran_msg_iu.c.
In particular, Assignment and Ciphering have so far been distinct code paths
for BSSAP and RANAP, with switch(via_ran){...} statements all over the place.
Using RAN_DEC_* and RAN_ENC_* abstractions, these are now completely unified.
Note that SGs does not qualify for RAN abstraction: the SGs interface always
remains with the MSC-A role, and SGs messages follow quite distinct semantics
from the fairly similar GERAN and UTRAN.
* MGW and RTP stream management
So far, managing MGW endpoints via MGCP was tightly glued in-between
GSM-04.08-CC on the one and MNCC on the other side. Prepare for switching RTP
streams between different RAN peers by moving to object-oriented
implementations: implement struct call_leg and struct rtp_stream with distinct
FSMs each. For MGW communication, use the osmo_mgcpc_ep API that has originated
from osmo-bsc and recently moved to libosmo-mgcp-client for this purpose.
Instead of implementing a sequence of events with code duplication for the RAN
and CN sides, the idea is to manage each RTP stream separately by firing and
receiving events as soon as codecs and RTP ports are negotiated, and letting
the individual FSMs take care of the MGW management "asynchronously". The
caller provides event IDs and an FSM instance that should be notified of RTP
stream setup progress. Hence it becomes possible to reconnect RTP streams from
one GSM-04.08-CC to another (inter-BSC Handover) or between CC and MNCC RTP
peers (inter-MSC Handover) without duplicating the MGCP code for each
transition.
The number of FSM implementations used for MGCP handling may seem a bit of an
overkill. But in fact, the number of perspectives on RTP forwarding are far
from trivial:
- an MGW endpoint is an entity with N connections, and MGCP "sessions" for
configuring them by talking to the MGW;
- an RTP stream is a remote peer connected to one of the endpoint's
connections, which is asynchronously notified of codec and RTP port choices;
- a call leg is the higher level view on either an MT or MO side of a voice
call, a combination of two RTP streams to forward between two remote peers.
BSC MGW PBX
CI CI
[MGW-endpoint]
[--rtp_stream--] [--rtp_stream--]
[----------------call_leg----------------]
* Use counts
Introduce using the new osmo_use_count API added to libosmocore for this
purpose. Each use token has a distinct name in the logging, which can be a
globally constant name or ad-hoc, like the local __func__ string constant. Use
in the new struct msc_a, as well as change vlr_subscr to the new osmo_use_count
API.
* FSM Timeouts
Introduce using the new osmo_tdef API, which provides a common VTY
implementation for all timer numbers, and FSM state transitions with the
correct timeout. Originated in osmo-bsc, recently moved to libosmocore.
Depends: Ife31e6798b4e728a23913179e346552a7dd338c0 (libosmocore)
Ib9af67b100c4583342a2103669732dab2e577b04 (libosmocore)
Id617265337f09dfb6ddfe111ef5e578cd3dc9f63 (libosmocore)
Ie9e2add7bbfae651c04e230d62e37cebeb91b0f5 (libosmo-sccp)
I26be5c4b06a680f25f19797407ab56a5a4880ddc (osmo-mgw)
Ida0e59f9a1f2dd18efea0a51680a67b69f141efa (osmo-mgw)
I9a3effd38e72841529df6c135c077116981dea36 (osmo-mgw)
Change-Id: I27e4988e0371808b512c757d2b52ada1615067bd
Start using osmo_fsm_term_safely(true), the recently added feature of
libosmocore's fsm.c. Deallocates in slightly changed order and with slightly
modified logging. Adjust test expectations.
Depends: I8eda67540a1cd444491beb7856b9fcd0a3143b18 (libosmocore)
Change-Id: I195a719d9ec1f6764ee5a361244f59f0144dc253
ran_conn_get_conn_id(): instead of a talloc allocated string, return a static
buffer in ran_conn_get_conn_id(). So far this function had no callers.
Refactor ran_conn_update_id() API: during early L3-Complete, when no subscriber
is associated yet, update the FSM Id by the MI type seen in the L3 Complete
message: ran_conn_update_id_from_mi(). Later on set the vsub and re-update.
Call vlr.ops->subscr_update when the TMSI is updated, so that log context
includes the TMSI from then on.
Enrich context for vlr_subscr_name and ran_conn fi name.
Include all available information in vlr_subscr_name(); instead of either IMSI
or MSISDN or TMSI, print all of them when present. Instead of a short log,
rather have more valuable context.
A context info would now look like:
Process_Access_Request_VLR(IMSI-901700000014706:MSISDN-2023:TMSI-0x08BDE4EC:GERAN-A-3:PAGING_RESP)
It does get quite long, but ensures easy correlation of any BSSAP / IuCS
messages with log output, especially if multiple subscribers are busy at the
same time.
Print TMSI and TMSInew in uppercase hexadecimal, which is the typical
representation in the telecom world.
When showing the RAN conn id
GERAN_A-00000017
becomes
GERAN-A-23
- We usually write the conn_id in decimal.
- Leading zeros are clutter and might suggest hexadecimal format.
- 'GERAN-A' and 'UTRAN-Iu' are the strings defined by osmo_rat_type_name().
Depends: I7798c3ef983c2e333b2b9cbffef6f366f370bd81 (libosmocore)
Depends: Ica25919758ef6cba8348da199b0ae7e0ba628798 (libosmocore)
Change-Id: I66a68ce2eb8957a35855a3743d91a86299900834
For each conn, set a default logging category, to distinguish categories for
BSSMAP and RANAP based conns.
LOG_RAN_CONN(): log with the conn's default category,
LOG_RAN_CONN_CAT(): log with a manually set category (mostly for keeping
previous DMM logging on the same category).
In some places, replace LOGP() using manual context with LOG_RAN_CONN(), and
remove the manual context info, now provided by the conn->fi->id.
This is loosely related to inter-BSC and inter-MSC handover: to speed up
refactoring, I want to avoid the need for manual logging context and just use
this LOG_RAN_CONN().
Change-Id: I0a7809840428b1e028df6eb683bc5ffcc8df474a
Neels Hofmeyr
Andreas Eversberg
Oliver Smith
Pau Espin
Philipp Maier
Vadim Yanitskiy
Keith Whyte