Don't end a CM Service Request "lock" too indiscriminately. Trigger only on new
transactions that start.
Change-Id: I4f64b8d91cfb1e61be4563594b2d6b23144af5bc
Indeed the easiest way of ensuring all code paths can cause conn discarding
while still all code paths can check on whether a conn needs to be discarded.
Change-Id: I641fe36d9fa2077e3caf63cc583aaa380603bff0
The ip.access nano3G needs the first RTP payload's first two bytes to read hex
'e400', or it will reject the RAB assignment. Add flag
patched_first_rtp_payload to mgcp_rtp_state to detect the first RTP payload on
a stream, and overwrite its first bytes with e400. This should probably be
configurable, but seems to not harm other femto cells (as long as we patch only
the first RTP payload in each stream). Only do this when sending to the BTS
side.
Change-Id: If0887b0b7714fc204f2addab2d43d44bb283ba21
Ciphering Mode Command is an implicit CM Service Accept, if we're sending
both we're confusing the MS.
Change-Id: I3a04debe9b01c086e7f44b6139cb8796fcc71d38
To accomodate the ip.access nano3G without having to recompile, make the
RAB Assignment's Transport Layer Address IE's format configurable, in both
osmo-msc and osmo-sgsn.
The long term perspective is to somehow detect which address encoding a given
3G cell prefers, but for the time being just configure it globally and set each
ue_conn_ctx to the global setting upon creation.
Add VTY command to iu_vty.c, with args passed to iu_vty_init() to insert
at an arbitrary VTY node, so that it can be used both for osmo-msc and
osmo-sgsn. Add generic iu_vty_config_write() to write out the config.
Call iu_vty_init() from msc_vty_init(); msc_vty_init() is in libmsc,
hence linking of osmo-msc now needs libiu to come after libmsc, so move
that further down.
Change-Id: I93728314742b327336f3fb6de98e6457f687e1f9
The future perspective is to remember the preferred RAB Transport Layer Address
encoding for each 3G cell that is connected, so store per UE conn instead of
globally hardcoding.
Add rab_assign_addr_enc member to ue_conn_ctx. Thus the iu_rab_act_cs() and
iu_rab_act_ps() functions no longer need the explicit use_x213_nsap argument.
Add include/openbsc/common.h in order to define the enum nsap_addr_enc, in a
separate file to be able to easily include it in all of libmsc, libiu and
gprs/* without creating include cycles.
Set the rab_assign_addr_enc when an MM ctx is created for iu, and whenever the
ue_conn_ctx for an Iu MM ctx is updated. This looks a bit clumsy so far, the
hope is that there will be a nice way to setup the ue_conn_ctx prior to that.
Change-Id: I49bb5736df7bdfdd55d3e7b74ee559595cfd2f7d
Before, I confused asn_debug with asn1_xer_print. Have two distinct VTY
commands and fix documentation.
Put the asn_debug and asn1_xer_print implementations in iu.c.
Since they are globally defined, don't pass a pointer to iu_vty_init()
but just use it directly. Might be considered less clean, but is also less
bloat.
Change-Id: Iccbadfe1585ba224f74cdfb5273b5ce29b6d78f0
So far it was included only in files that also include all needed headers,
but make it so that it can be included on its own.
Change-Id: I08a756031b995bd01a6e15c678b845fd98de960b
Do the same as we do in 2G: release the connection as soon as nothing else
is pending for a given subscriber.
Before, osmo-msc would wait for the UE "to get bored" and send an Iu
release. But the CN should stay lean on connections. Also, 25.413[1] in section
7, 6th point states:
"While the Iu release is managed from the CN, the RNC has the capability to
request the release of all Iu connection resources from the corresponding Iu
connection."
So far we did not manage Iu release from osmo-msc at all.
Use the same mechanism we use in 2G: from msc_release_connection(), just before
freeing the gsm_subscriber_conn, invoke a CN initiated Iu Release command to
the UE.
This works around OS#1816 ("USSD only works when IuCS is released", on nano3G),
because the Iu conn is now released right after every signalling, so that
typically no two requests will use the same conn.
In iu.h/iu.c, add iu_tx_release(), absorbing almost all of the code from
ranap_handle_co_iu_rel_req().
Add stub to db_test.c, necessary to build it without linking libiu.
[1] 3GPP TS 25.413 v12.4.0 Release 12 / ETSI TS 125 413 V12.4.0 (2015-04)
Related: OS#1816
Change-Id: Ic12bd6f3666f6fd42bd6d9fdae1c93abee3b6786
Don't remove the gsm_subscriber_connection without an Iu Release.
The 2G paradigm is to close a subscriber connection as soon as nothing else is
pending.
In 3G however, the conn is often discarded even though the IuCS stays open and
valid, which confuses the situation: before the UE releases a bit later, we
would try to page the subscriber unsuccessfully, because the UE expects to
already be connected.
To first fix the discrepancy of Iu vs. subscr release, never discard
gsm_subscriber_connections when msc_release_connection() is called.
This creates a "lazy" CN that keeps connections open as long as the UE will
tolerate. It is really fast in sending many SMS in close succession, but is
certainly a bad CN design choice: we should rather stay lean on connections.
A subsequent commit will change this, but I decided to keep this commit as a
reference, for when we'd like to test situations that should re-use an
established connection.
Change-Id: I012378cfa432d791146db387554ec1909de05297
Send IuCS RAB Activation upon MNCC_CALL_PROC_REQ.
Implement function msc_call_assignment(): decide between sending A-iface BSSMAP
Assignment Request or IuCS RAB Assignment Request.
Implement iu_rab_act_cs() to send the IuCS RAB Assignment Request. The IP
address and port of the MGCPGW sent in the RAB Assignment are still hardcoded.
The A-interface extension is not implemented yet.
Declare ranap_new_msg_rab_assign_voice() to avoid including
ranap_msg_factory.h, which would require adding ASN1 CFLAGS to Makefile.am.
The mgcpgw_client as well as some more osmo-iuh functions are now linked from
libmsc, hence add some dummy stubs to libiudummy and db_test.c.
Change-Id: Iaae51d1fbbfc28fad1c0b85e161d53d80a420a19
Add an API to send MGCP messages to an MGCP GW, from the perspective of
an MSC instructing the GW to setup RTP streams.
Rationale: the mgcp_protocol.h is mostly for the MGCP GW itself, other
implementations forward incoming MGCP messages. So a simpler approach for an
MGCP GW client is useful.
Add general VTY commands that can be used to configure mgcpgw_client.
osmo-msc is going to use this to route RTP streams (for 3G at first).
Change-Id: I6fe365c4c89207f2172943cc456b508a207b1135
Add file mgcp_common.c to implement the value strings for the
mgcp_connection_mode.
Add in a separate file because of the upcoming mgcpgw_client.c implementation,
introducing a file that contains implementations commonly used in MGCP GW as
well as its clients.
Change-Id: I6fe365c4c89207f2172943cc456b508a207b1135
Rename gsm48_cc_tx_call_proc() to gsm48_cc_tx_call_proc_and_assign() to mark
the place where the A-interface will send a BSSAP Assignment Request / where
the IuCS-interface will send a RAB Assignment Request.
Add function msc_call_assignment() to decide between A-iface and IuCS
assignment, to be implemented in subsequent commit.
Change-Id: I0695e233d57d13658793b0e63bb7c3ff224909a0
Add libiu function to send a CommonID message down a UE connection,
iu_tx_common_id(); add also a corresponding stub to libiudummy for linking with
tests.
Add libmsc function msc_tx_common_id() to call the above. Add this mostly to
clearly indicate in msc_ifaces.h that libmsc is calling out of the MSC; also
to do conn->via_iface checking.
Call msc_tx_common_id() after ciphering is established, in
_gsm48_rx_mm_serv_req_sec_cb()'s GSM_SECURITY_SUCCEEDED case.
Change-Id: I576ddd5bbabfc989149debd2f8a9743db6d26043
From a human admin viewpoint it doesn't make sense to count the messages sent:
When we use TMSIs, we first send a LU Accept with a new TMSI, and then expect
the MS to respond with a TMSI Realloc Complete message. When that fails to come
through, the LU actually ends in failure, even though a LU Accept was sent.
In 3G, if a UE sends an Iu Release during LU (e.g. user enables flight mode),
we cancel the LU without sending any reply at all, so nothing would be counted.
Instead, count Location Updating results, i.e. completion and failures.
Neels Hofmeyr