During development of the counters, they were first added to the same
RTP counter group and later on split, but some places still used the
RTP related functions to increment the counters.
Let's add a seaprate set of helpers to update the correct osmux counter
group.
Fixes: 582c2bf7b0
Change-Id: Ia2e5601c7d476b79afd95032dbc019517f8209af
So far the implementation only allowed the remote CID being the same as
the one dynamically implemented internally.
Related: SYS#6138
Change-Id: I6b03eabc0305580c9788c529bec7dda9044a008f
struct osmux_handle, which is shared by several rtp_conn, is
attached to the trunk object, since the socket also attaches to it.
Related: SYS#5987
Change-Id: If4980424cdb8e3dc26a23e9ee419c0a38912f38f
It makes sense to handle one osmux socket per trunk. Since we only so
far operate one RTP/osmux trunk, let's stick to that only one for
simplicity.
Change-Id: I173266c4058d5db9479d773d7dec1304bc8f1f99
The struct osmux_handle is a shared structure which goes together 1-1
with libosmo-netif's struct osmux_in_handle, which is common to all CIDs
to be muxed together. Hence, it makes no sense to store a specific conn
object to it, since it actually manages several of them. Hence, all the
conn specific stuff must be handled beforehand, not at osmux deliver
time.
Related: SYS#5987
Change-Id: Ie739b556e9eb7d3133e798831a09728c7cc87135
This cleans up all the code, and makes it a lot easier to add IPv6 support
later on (mostly only a matter of adding an IPv6 bind address in VTY).
Similar changes were done to the Osmux code being added to osmo-bts.
Related: SYS#5987
Change-Id: I5a100fc654f88d29b2bcd85889a5a92aef3d576d
This way we don't need to worry about implementation details (struct
size) in the future in case they change (they will).
Related: OS#5987
Requires: libosmo-netif.git Change-Id Ie8df581f375c9a183a7af60b431561bda82f6e34
Change-Id: I2d0d8c152b8f1234ddfcd74d6cb04b1818b41510
There is no obvious reason why we would want to complicate the code by
caching pointers, since pointer traversal is probably not a performance
bottleneck, and if it is we should rather take a look at our dozens of
linked lists first..
Change-Id: I2456ba63598f76200d53e00223abf60bb36a49c0
The constant MGCP_DUMMY_LOAD is used ambigously. Sometimes it is used as
initalizer for an array, sometimes it is used as a single byte. Also the
name is not very expressive. Lets refactor this.
Change-Id: I21d96cefeeb647958bfa1e22a0ea030884746fad
Related: OS#4005
This is useful for affecting the 802.1Q PCP value without any separate
external packet filter rules for classification.
Change-Id: I69136c6dd114c24b1dace034e75dba5157bac37e
Depends: libosmocore.git I89abffcd125e6d073338a5c6437b9433220e1823
libosmocore If22988735fe05e51226c6b091a5348dcf1208cdf introduces
an even more convenient mechanism for specifying the DSCP of
an IP socket via OSMO_SOCK_F_DSCP()
Change-Id: If0b11dea08716ed3952a25b546b2a9bd013857bf
We have VTY options that allow to set the DSCP value. However, we
then call a function to set the TOS bits in the kernel. This is
very wrong. The DSCP is only the upper 6 bits of the 8-bit TOS
value, and hence we are mussing that translation.
As libosmocore now has a helper function osmo_sock_set_dscp(),
let's make use of it and don't care about the low-level details.
However, this means we need to finally remove the deprecated
alias for "rtp ip-tos <0-255>".
Closes: OS#5137
Change-Id: I9c18c90273be97aedd2ad212b82f650e35c32851
Depends: libosmocore.git Ia4ba389a5b7e3e9d5f17a742a900d6fd68c08e40
It is currently done upon receival of RTP packets in rx_rtp for pure RTP
conns, but nothing similar is done for Osmux conns, which eventually
trigger a connection time out.
Change-Id: Id592d7db7b9399a497176e0d28cc826b3bce48c0
This commit contains the bulky work of moving all address parsing to
support IPv6 together with IPv4.
Some specific patches required for full IPv6+IPv4 support requiring
behavioral changes come after this one.
Full Osmux IPv6 support is left out of the scope of this patch.
Depends: libosmocore.git Ie07a38b05b7888885dba4ae795e9f3d9a561543d (> 1.4.0)
Depends: libosmocore.git I59bf4b4b3ed14766a5a5285923d1ffa9fc8b2294 (> 1.4.0)
Change-Id: I504ca776d88fd852bbaef07060c125980db3fdd7
The file mgcp_internal.h still contains mostly definitions and types
that are relevant for mgcp_network.c and mgcp_protocol.c. Lets give
the network and protocol module its own header files, also move stuff
that does not relate to protocol and network to the appropiate places.
Change-Id: I837eaad771ed7252304db4a81c37953b70766fff
Instead of numerous arguments (buf, len and context data), use a msgb, like
most other osmo programs do, with a msb->cb pointing at a context data struct.
This opens the future for adding/stripping IuUP header data from the msgb
easily.
(Checked to pass current ttcn3-mgw-tests.)
Change-Id: I3af40b63bc49f8636d4e7ea2f8f83bb67f6619ee
The function mgcp_trunk_by_num() is used to directly pick a specific
trunk that is known by its id number (sometimes called "index").
Traditionally the virtual trunk will reside under id number 0 and all
consecutively created E1 trunks will be created under number 1 to 64.
This works fine, but puts a limitation on us should we ever introduce an
aditional trunk type (e.g. T1). Since the numbers must be unique
regardless of the trunk type one could not have an E1 trunk number 1 and
e.g. a T1 trunk number 1 at the same time. So we should pick the trunk
not only by its number, but also by its type to allow different trunk
types to carry the same number. The trunks will still be distinguishable
by its type along with the respective endpoint prefix.
Change-Id: I7af1e9ce601babd4a51e88201a98319e03945f83
Related: OS#2659
The virtual trunk is a pre-configured trunk that always exists. It is
kept separate from the trunk list using a separate pointer. This makes
thinks unecessarly complicated. Lets organize the trunk in the trunk
list like any other trunk, except that we automatically create it on
startup and assign it always the trunk id number 0.
Change-Id: I81934fbd211b225ab7920e78510729c8e22607b3
Related: OS#2659
The trunk and endpoint handling in osmo-mgw is still very complex and
implemented in various places (mostly mgcp_protocol.c). Also we use
still integers for endpoint identification, which is not flexible enough
to address timeslots/subslots on an E1 trunk. Some refactoring is needed.
- get rid of integers as endpoint identifiers, use strings instead and
find the endpoint based on its string name on the trunk.
- identify the trunk based on the trunk prefix given in the endpoint
name.
- refactor trunk and endpoint allocation. Aggregate functionality in
in mgcp_endp.c and mgcp_trunk.c. Also remove non-reusable code that
relates to the still exisiting, but unfinished E1 trunk support.
- refactor rate counters, put them into a separate module and do no
longer allocate them per trunk. Allocate them globally instead.
Change-Id: Ia8cf4d6caf05a4e13f1f507dc68cbabb7e6239aa
Related: OS#2659
There were two code paths that were supposed to do exactly the same,
but then in Change-Id I3994af016fb96427263edbba05f560743f85fdd4 only
one of the two was modified, resulting in OS#4034
Let's
* dynamically allocate the virtual trunk
* rename mgcp_config.trunk to mgcp_config.virt_trunk to clarify
* as a result, abolish copy+pasted code for trunk initialization
Change-Id: I54762af6d417b849a24b6e71b6c5c996a5cb3fa6
Related: OS#4034
New define is available since libosmocore 1.1.0, and we already require
1.1.0, so no need to update dependenices.
Let's change it to avoid people re-using old BSC_FD_* symbols when
copy-pasting somewhere else.
Change-Id: I9b6463af713f76c06a144bdbf202c0d91eef4d21
That MGCP_DUMMY_LOAD is an old hack prior to Osmux spec update, and it's
not nice since it cannot be 100% distinguished from a usual AMR ft
frame.
Let's use the correct DUMMY ft type and build it according spec. Allow
handling differently the old format for a while until we are sure no old
implementations (like bsc-nat) exist sending that kind of message.
Change-Id: Ib17d20b87b28aade49ba60519b56a96e694819af
Remove old BTS/NET no longer in use and meaningless. Use new osmo-mgw
APIs to inject payload RTP<->Osmux on the correct socket and conn.
Change-Id: I60b6ba3ffdc74efff945ba13a0b736798bdf5d8c
Previously the local one was used but nobody cared because probably
everybody was using default 1984 on different IP addresses.
Change-Id: I01e590465fa247185d74103578681e9041249099
We also update code to allow setting up RTP related fields to succeed
during CRCX. We also update code to allow setting up RTP related fields to
succeed during CRCX.
Change-Id: Ia6e723d9a28ba38fc3382a4fb35ea6e5bab30c09
osmux_xfrm_input_open_circuit returns 0 on success and -1 on error.
Confusion comes from that function being implemented by calling
osmux_batch_add_circuit which returns NULL on error.
cherry-picked from: openbsc.git ac1b03c8e59408336d07527e2597171cb99ed654.
Change-Id: Iba018aa57901642ea4c486526a973fe6023e10cf
* Cleanup naming to make it far more clear
* Drop 2 variables holding CID values (allocated_cid, cid), in favour of
1 value holdinf the value and one bool stating whether the value is
used.
* Change conn_osmux_allocate_cid to allow allocating either next
available CID or a specific one, in preparation for forthcoming patches.
This commit can be merged straight away because anyway osmux cannot be
enabled in current status (blocked by vty config) and
(conn_)osmux_allocate_cid was/is not called anywhere. However, it helps
improving code base for future re-introduction of Osmux as it is
envisioned.
Change-Id: I737a248ac6c74add8e917fe2e2f36779d0f1d685
Pau Espin
Eric Wild
Philipp Maier
Harald Welte
Neels Hofmeyr