This is more natural to most application code, so simply go for ASCII
string with NUL-termination rather than an array with explicit length.
Change-Id: I6312208cdfa83184be41157a473c96e9120c63db
A xua_msg_class repreents one xUA message class (like M3UA XFER
or SUA CL). A dialect is then something like SUA or M3UA, each
consisting of as many as 256 message classes. Each class contains
value_strings of the individual messages, as well as constraint
information on mandatory IEs for each message.
Change-Id: Ib538aca295b7b50132bc814b2d7b56cbe5d65bfc
A lot of IEIs are identical between the different xUA dialects, so let's
base the SUA definitions on the m3ua definitions.
Change-Id: I64c7166cf0b5c8a927ab7e14955100f8d13fe16a
Sometimes one already has the xua_msg_part and thus can avoid the
lookup that's done by xua_msg_get_u32().
Change-Id: Ie11c35f9528313d0b35786a361d853addd17364f
Move here unchanged first, so we're able to see the modifications in diffs.
Pending changes will follow in subsequent patches.
Moved from osmo-iuh 3da8608b6ad014fc74536dbb49019704fd425b8c, which was before
the rename of osmo_sua_link and osmo_sua_user to osmo_sccp_link and
osmo_sccp_user, so this will not compile.
Change-Id: Iae0c58c5f1eb00a685de70add0d5257e4316c6d5
... which can be resolved from the primitive call back prim_cb() by
calling osmo_sccp_link_get_user_priv().
Change-Id: If4c0f96f0621fb2adf4c78dc5994d3398431d92f
By accident, I already fixed this typo in osmo-iuh, breaking the build. Instead
of reverting there, fix it here.
Change-Id: I4076fb37c0d94be7adff46e76465884a61c54c9a
hwelte requested this change for the addition of libiu in openbsc. In a
conversation we came to the conclusion that a rename of these two opaque
structs would suffice.
This is the "upstream" rename and will require adaptation of:
* the sysmocom/iu branch in this repository
* the iu related branches in openbsc.git
* the hnbgw and dummy_cn code in osmo-iuh.git
See https://gerrit.osmocom.org/#/c/192/2/openbsc/src/libiu/iu.c@57
Change-Id: Icbf64dd96f8e0e27695df73d1144519b88360b94
143 is actually the SSN for RNSAP. Wireshark displayed a RNSAP message type
and malformed packet warning until I fixed this to 142. Now I get the proper
RANAP and id-Paging reported.
There has been a reallocation for RANAP and RNSAP SSNs, though the old SSN for
RANAP is apparently 32 (seen in a pcap from a real 3G network). When I send 32
instead of 142, wireshark also decodes the message as valid RANAP.
At the time a SCCP CREF is sent there is no context anymore
and the user of the API might not know where to return the
message to. Allow to specify the incoming context and use it
on the way out.
There are no more callers of _send_msg which passes a NULL
connection and a NULL context.
Harald Welte
Neels Hofmeyr
Neels Hofmeyr