This call-back can for example be used as segmentation call-back
for libosmo-netif stream_cli/stream_srv or directly for osmo_io.
Related: OS#5755
Change-Id: I5e922c54b3431d759b38e81e55076125c5a34008
PCO - Protocol Configuration Options 3GPP TS 24.008 / 10.5.6.3.
The PCO will be used by the osmo-epdg to pass PCO internally.
The PCO will be passed towards to the PGW in the Session Request.
Related: OS#6369
Related: osmo-gsm-manuals.git Change-Id Id912ead4e1205f84a40af6505a5ddf050d1e086d
Change-Id: I0f9de90c7c67fe194b441a9d118eba70f09afb5e
The previous PDP-Type IE should have been a PDP-Address from the
start, since having only PDP-Type with no address is only a specific
case (dynamic addressing).
This becomes clear by looking at other similar protocols like:
* MAP: APN-Configuration IE has servedPartyIP-IP{v4,v6}-Address IEs
* Diameter S6b, 3GPP TS 29.272 7.3.35 APN-Configuration contains
Served-Party-IP-Address AVPs
* Diameter SWx, 3GPP TS 29.273 APN-Configuration.
* GTPv1C Ts 29.060 7.7.29 PDP Context containing PDP Address.
Since PDP-Type on its own really makes no sense, being it a special case
of PDP-Address, let's keep the IE by renaming it (keeping old name too
for API backward compat) and extend it to support lengths > 2 bytes.
Old implementation of libosmogsm gsup actually ignored lengths > 2
bytes, so we are safe acting against older implementations here, both
on the sending and receiving side on the wire.
The big drawback of this commit is that it breaks ABI compatibility due
to adding "struct osmo_sockaddr pdp_address[2];" to struct
osmo_gsup_pdp_info, which in turn affects shift of fields in struct
osmo_gsup_message. Unfortunately, there's not much that can be done to
improve the situation when adding the missing field, due to existing API
having the same struct for all messages. Ideally we'd have 1 union with
structs per message type inside, this way the ABI break would be far
less pronounced.
The GSUP test output change is becaue we now accept some of the len>2
cases for PDP-Type/Address IE which were being rejected since a couple
commits ago.
libosmogsm gsup code is now disabled in EMBEDDED mode, since it nows
depends on core/socket.h (struct osmo_sockaddr) which is not available
in EMBEDDED, and hence fails during build:
"""
In file included from /build/include/osmocom/gsm/gsup.h:45,
from /build/src/gsm/gsup_sms.c:28:
/build/include/osmocom/core/socket.h:15:10: fatal error: arpa/inet.h: No such file or directory
15 | #include <arpa/inet.h>
| ^~~~~~~~~~~~~
"""
Related: OS#6091
Change-Id: I775ff9c3be165d9f30d6ab55d03f99b6104eadd6
Having both fields in an uin16_t integer makes it difficult and
confusing for users for no good reason. Let's have separate fields for
each of them.
The new fields are defined so that they are ABI compatible with previous
uin16 field.
Change-Id: Ie31c6080c90e468c01186259f2c42621e39b5cc6
As documented in gsup.adoc, this field is expected to be 2 bytes.
This is only a intermediate step to showcase the related test scenarios
submitting IE with len > 2. The logic will be changed in a follow-up
patch when changing the IE to also encode/decode the missing Address
part.
Change-Id: I0d024a9a4fb10beeff39ac33a9d2ed02f88f4580
This code predates 2cbe25f4, adding osmo_strbuf API and so using its
own append-to-strbuf implementation. Let's use the new generic API.
Change-Id: Ifdfd18eeef6a0932995063259f9f179b22e781de
The code so far only supported 240bit RLP frames; Add support for
576bit in this patch. We still only support versions 0+1 and not
version 2.
Change-Id: Idfdcabb19fe8733fb9c5ee76a39b0bf4cdf60c2c
This code implements a decoder and encoder for the RLP (Radio Link
Protocol) as used in the bearer channel of GSM CSD (Circuit Switched
Data).
Change-Id: I2d9bd8eb4f0cd0f72c436996767b199429596917
RTS based polling in LAPDm code is disabled by default. Make libosmogsm
stay compatible with existing applications that do not use RTS based
polling.
This patch fixes the issue that LAPDM_ENT_F_POLLING_ONLY did enable RTS
based polling too, which breaks existing applications like older
versions of osmo-bts.
Change-Id: I2a75c192bbc24e85bfc1656b2be21cea7a92814a
The CEIA interface is an interface between osmo-epdg and
strongswan.
It is used by the osmo-epdg to synchronize state.
Related: OS#6091
Change-Id: I6f7c20340c99f94b1326a8a7dc99c86cf6a0dbc3
This behaviour was default in earlier versions of LAPDm/LAPD. Because it
is only required for osmocom-bb, a flag is added to enable it there.
Related: OS#5969
Change-Id: I93994dbbd1fc2c9edb8f3015c6b18ecd0fce0565
The extra queue is used to transmit the UI frame only when there is no
frame in the regular TX queue. This allows to give LAPD frames prioity
over UI frame.
Related: OS#4074
Change-Id: I00c8ee73be8b7c564a4dee3fca3e893484f567da
The lower layer must set the 'POLLING_ONLY' flag and provide frame
number when polling a frame. If T200 is pending, it is started with a
timeout frame number in advance to given frame number.
The lower layer must call lapdm_t200_fn() after a frame has been
received or if a frame has not been received. Also it must be called
after a TCH frame has been received. LAPDm uses this to check the T200
timeout condition.
A new function is used to set the frame number based timeout values.
Related: OS#4074
Change-Id: I6ebe83f829d7751ea9de1d90eb478c7a628db64c
The outcome of the update function is still used to indicate if an RR
frame must be sent or not. Only if there is no I frame in the TX queue,
RR frame must be sent.
Related: OS#4074
Change-Id: I71676c709878105bfd18b9370fecc61b92796a6f
Outgoing CSD calls were previously encoded with the
Bearer Capability 1 - Octet 4 "Structure" field set to
3 - Unstructured. Many Nokia, Sony Ericsson and Huawei devices
won't accept incoming CSD calls with these bits set.
Set them to 0 - Service data unit integrity for now, which
seems to work and make all tested devices happy.
Change-Id: Ieb5bca3d3578abd28e18808752e1c312ce7c4ce0
GSM48_BCAP_ITCAP_3k1_AUDIO should be handled just like fax or
unregistricted digital CSD calls. The transfer capability just
indicates that an (external) interworking function should convert
the call into an analog modem call on the network edge.
The CSD call is still regular V.110/RLP non-transparent data.
Change-Id: I44b76be0f6a891bc1d8f55ede1ef140ea0a19e3d
BCC and GCC share same call states, except for two states that have same
value, but different state names and conditions.
Related: OS#5364
Change-Id: I2180b43b940542565188f52c554c960858fe2a95
This allows uses accessing the updated fields such as fn from the l3_cb
when receiving a msg from CCCH, eg: "le->datalink[DL_SAPI0].mctx.fn;"
Related: OS#3626
Change-Id: Icabc3759c47b0f7cfe61f1b7a96f08f36714262e
This reverts commit 54b1b3be37.
osmo-bts is forwarding the msgbs as they come from lapdm to the RSL on
the wire, which means we end up sending the osmocom-specific IEs on the
wire, something which was not envisioned when adding this IE.
Change-Id: Id9029ef378970322063478e9ce888daf335d6103
Related: OS#6142
This reverts commit d981794113.
osmo-bts is forwarding the msgbs as they come from lapdm to the RSL on
the wire, which means we end up sending the osmocom-specific IEs on the
wire, something which was not envisioned when adding this IE.
Change-Id: I0ab0d5b545b4862e72eb1842edd07ca2e4955311
Related: OS#6142
This makes it possible to track GSM time in the upper layers.
The existing RSL_IE_FRAME_NUMBER and RSL_IE_STARTNG_TIME cannot be used
there, since those are 16bit fields containing Relative FN values.
The IE needs to be added before the L3_INFO one, because user code
usually assumes the msgb->l3 pointing to L3_INFO value extends until the
end of the message, using msgb3_len(msg). Regarding having an extra IE
at the middle, it's not a big problem since the libosmocore version
submitting this commit to the upper layers is the same which will also
be parsing it through rsl_tlv_parse() later on by the app.
Related: OS#3626
Change-Id: Id62c18f49f270449067b25b7104eb8b47f1955ec
This will be used in RSLms to provide Absolute Frame Number information
of the primitive indications being sent to upper layers, so that it's
possible to track GSM time in the upper layers.
The existing RSL_IE_FRAME_NUMBER and RSL_IE_STARTNG_TIME cannot be used
there, since those are 16bit fields containing Relative FN values.
Related: OS#3626
Change-Id: Ia28caa24dd141b1162b6e11500d753353fe6500d
Implementation ported from osmo-pcu.git
e98b315d12fb009359410809f4169f9380f3d933, function bts_rfn_to_fn().
This functionality can be used by osmo-pcu, libosmo-gprs or any other
related code which needs to handle RFNs.
Change-Id: Ib71e8da976f6cc84c3a4ab17b0a8c2101492e243
This field will be used in follow-up commits to provide FN information
in RSLms primitives towars upper layers. This is needed for instance on
the MS side when a CCCH_DATA.ind is received containing a TBF ImmAss
with a relative FN indicating the Starting Time. Without tracking FN
advance, the uppers layers are not capable of figuring out the absolute
FN of the TBF Starting time.
The struct lapdm_msg_ctx is not really used outside of libosmocore, so
we are safe extending it.
Related: OS#3626
Change-Id: Icf986f4202703eb452bedc1b749bb8ce0c73706f
Currently this function is hard-coding the "Connection element (octet
6c)" (see Table 10.5.101h/3GPP TS 24.008) to "Transparent" (0). This
breaks non-transparent data calls.
Use the value from bcap->data.transp. The decoding equivalent of
this function needs no changes, it does populate this field already.
Change-Id: I7339908864e8a2aef6f2b48a108650167e413c7f
Related: OS#6110, OS#4394
As per 3GPP TS 48.008, section 3.2.2.103, the "Codec Type" field may
contain either a certain 3GPP Speech Codec Type directly (4 bit value),
or the so called "Codec Extension" = 0xFh, in which case the real Codec
Type follows in the next octet as "Extended Codec Type".
CSD is such an example, the encoding is defined as follows:
8 7 6 5 4 3 2 1
+----+----+----+----+-------------------+
| -- | PI | PT | -- | 0xFh |
+----+----+----+----+-------------------+
| Extended Codec Type (CSData) |
+----+----+-----------------------------+
| R2 | R3 | |
+----+----+-----------------------------+
CSData is coded with 0xFDh or '1111 1101' (0xfd).
Let's have the "Codec Extension" value clearly defined in the header
file, but intentionally separate from the other GSM0808_SCT_* values.
Change-Id: Iafaa25070684d2ba400c75fa33e803651a5ce857
Related: OS#6110, OS#4393, OS#4394
It has been decided that the segmentation callback be changed
and moved to libosmo-netif, so we remove it here.
This reverts commit 2c59d1285e.
Related: OS#5753
Change-Id: I9b380326c63587fc79d6a5d8cd458188074fc55d
The spec isn't super clear, but basically the conv coding is done
in two blocks of 72 bits.
The way it's currently implemented isn't "wrong" in the sense it will
produce correct output given no bit errors, but it's better to do the
decoding in two blocks because this then it makes use of the fact we
know the state of the encoder after the 72 bits, which improves the
corrective ability of the code.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: Id2551ffe2a0ebfd0a6df0e1d288a6f0af7e1eda7
gsm48.c provides a function to decode mobile identity from various
messages. TALKER INDICATION is sent by the talking subscriber of a voice
group call to idenitfy the current talker. The mobile identity is
required to distinguish between calling subscriber and other subscribers.
Related: OS#4854
Change-Id: I331fac82e3c15abb01f554b2e70576100f2eea2d
This API is useful for checking whether a Downlink CCCH block belongs
to PCH or AGCH. We need this API in osmo-bts.git and osmocom-bb.git.
Change-Id: I8cbd31226754e95887358ed83a928e2f567f4cf3
Related: OS#5500
Add segmentation callback to be used by the streaming backend of libosmo-netif
Related: OS#5753, OS#5751
Change-Id: I3a639e6896cc3b3fc8e9b2e1a58254710efa0d3f
If tx_ph_data_enqueue() is called, frames will be written into a queue,
if there is a pending frame or if polling of TX frames is used. In
this case the return value must be 0.
Sending a RSL_MT_UNIT_DATA_REQ from upper layer causes a call to
tx_ph_data_enqueue(). The return code is returned to the sender. The
sender must not get an error returned, if the message is enqueued.
Change-Id: Iaeaf7c66cb3cf5cc81bc8e15d468e8e7704c1407
Bter frames may be used on downlink of a main DCCH or SACCH channel.
It applies to SAPI 0 and UI frames only. It includes a short layer 2
header with 2 bits only. All other bits are used for the message. The
message size is 23 bytes on main DCCH and 21 bytes on SACCH.
The length of the L3 messsage is used to distinguish between Bter frames
and other (UI) frames.
Note that the L3 message header is different, so that the length of the
UI frame will determine which header is used.
Change-Id: Ia3a25c009d1ff09f83258bdb226a85b81466d7a1
Code review for [1] has asked for providing proper API for struct
osmo_routing_area_id.
For historical reasons, we have struct gprs_ra_id and
struct osmo_routing_area_id serving the exact same purpose: represent a
decoded 3GPP TS 24.008 § 10.5.5.15 Routing area identification.
The "better" one is struct osmo_routing_area_id: it allows using API
like osmo_plmn_cmp(), because it is made up of meaningful sub-structs.
Implement de/coding using the functions already available for the
sub-struct osmo_location_area_id, and simply add the RAC.
Add a test in gsm0408_test.c.
Note that other utility functions are already available for struct
osmo_routing_area_id: osmo_rai_name2(), osmo_rai_cmp().
There is no real need to deprecate struct gprs_ra_id, because there is
not really anything wrong with it. It just isn't as well integrated with
other utility API as struct osmo_routing_area_id is. Just add comments.
[1] osmo-hnbgw.git:
cnpool: extract Mobile Identity from RANAP payload
https://gerrit.osmocom.org/c/osmo-hnbgw/+/33133
I373d665c9684b607207f68094188eab63209db51
Change-Id: Ic5e0406d9e20b0d4e1372fa30ba11a1e69f5cc94
Harald Welte
Alexander Couzens
Pau Espin
Vadim Yanitskiy
Manawyrm
Sylvain Munaut
Neels Hofmeyr