Age | Commit message (Collapse) | Author | Files | Lines |
|
It may print a debug line every 20ms, so disable this. We can still
compile this extra spamming debug from the libosmo-netif library.
|
|
Instead of the hardcoded OSMUX_PORT.
|
|
via mgcp section from the configuration file.
|
|
|
|
This patch adds a missing goto err. While at it, reword log message.
|
|
Not very useful:
<000b> osmux.c:163 Osmux uses CID 1 from endpoint=7 (active=1)
Get rid of it.
|
|
Use osmux_xfrm_input_fini() to release the internal state of the osmux
input handle.
|
|
This patch includes several osmux fixes that are interdependent:
1) This adds Osmux circuit ID, this is allocated from the bsc-nat. This
announces the circuit ID in the CRCX MGCP message. This aims to resolve
the lack of uniqueness due to the use of endp->ci, which is local to
the bsc. This ID is notified via X-Osmux: NUM where NUM is the osmux
circuit ID.
2) The dummy load routines are now used to setup osmux both in bsc and
bsc-nat to resolve source port NAT issues as suggested by Holger. The
source port that is used from the bsc is not known until the first
voice message is sent to the bsc-nat, therefore enabling osmux from
the MGCP plane breaks when a different source port is used.
3) Add refcnt to struct osmux_handle, several endpoints can be using the
same input RTP osmux handle to perform the batching. Remove it from the
osmux handle list once nobody is using it anymore to clean it up.
4) Add a simple Osmux state-machine with three states. The initial state
is disabled, then if the bsc-nat requests Osmux, both sides enters
activating. The final enabled state is reached once the bsc-nat sees
the dummy load message that tells what source port is used by the bsc.
5) The osmux input handle (which transforms RTP messages to one Osmux batch)
is now permanently attached to the endpoint when Osmux is set up from the
dummy load path, so we skip a lookup for each message. This simplifies
osmux_xfrm_to_osmux().
After this patch, the workflow to setup Osmux is the following:
bsc bsc-nat
| |
|<------ CRCX ----------|
| X-Osmux: 3 | (where 3 is the Osmux circuit ID
| | that the bsc-nat has allocated)
|------- resp --------->|
| X-Osmux: 3 | (the bsc confirm that it can
| | use Osmux).
. .
| |
setup osmux |----- dummy load ----->| setup osmux
| Osmux CID: 3 |
In two steps:
1st) Allocate the Osmux Circuit ID (CID): The bsc-nat allocates an unique
Osmux CID that is notified to the bsc through the 'X-Osmux:' extension.
The bsc-nat annotates this circuit ID in the endpoint object. The bsc
replies back with the 'X-Osmux:' to confirm that it agrees to use Osmux.
If the bsc doesn't want to use Osmux, it doesn't include the extension
so the bsc-nat knows that it has to use to RTP.
2nd) The dummy load is used to convey the Osmux CID. This needs to happen
at this stage since the bsc-nat needs to know what source port the bsc
uses to get this working since the bsc may use a different source
port due to NAT. Unfortunately, this can't be done from the MGCP signal
plane since the real source port is not known that the bsc uses is not
known.
This patch also reverts the MDCX handling until it is clear that we need
this special handling for this case.
|
|
In the bsc-nat side, the osmux socket initialization can be done from
the vty. This ensure that the osmux socket is available by the time the
bsc-nt receives the dummy load that confirms that the osmux flow has
been set up.
This change is required by the follow up patch. This change ensures that
the Osmux socket in the bsc-nat is already in place by the time this
receives the dummy load.
|
|
This is a cleanup to allow the reuse of the new functions
osmux_handle_find_get() and osmux_handle_alloc().
|
|
Just a cleanup, wrap around the osmux state information in a struct.
|
|
Avoid creating a bogus state that will never go away.
|
|
For our usecase several different systems might be behind the
same firewall so we need to distinguish the remote by more than
the IPv4 address.
|
|
Set the remote port for the endpoint. Somehow this needs to propagate
all the way to the handle.
|
|
We need to discover the remote port as we are likely behind a NAT.
Right now the NAT code will just send to port 1984 on the BSC but
this might not arrive at the BSC. Include the CI (in the future we
need to include the endpoint address or send the dummy to the net
port). This is just an interim solution.
|
|
The CI is a MGCP value that is counted from 0 upwards. The code
is comparing a uint8_t with a uint32_t. This will only work for
up to UINT8_MAX calls and then will silently break. The code should
probably work with the endpoint number and not the CI. For now
truncate things and hope things work.
|
|
|
|
|
|
|
|
<000b> osmux.c:177 Cannot find endpoint with cid=7
!
<000b> osmux.c:253 Cannot find an endpoint for circuit_id=7
The extra newline and '!' do not provide any extra value and
make reading the output more difficult. Just remove it.
|
|
|
|
This patch adds the voice muxer. You can use this to batch RTP
traffic to reduce bandwidth comsuption. Basically, osmux transforms
RTP flows to a compact batch format, that is later on decompacted
to its original form. Port UDP/1984 is used for the muxer traffic
between osmo-bsc_nat and osmo-bsc_mgcp (in the BSC side). This
feature depends on libosmo-netif, which contains the osmux core
support.
Osmux is requested on-demand via the MGCP CRCX/MDCX messages (using
the vendor-specific extension X-Osmux: on) coming from the BSC-NAT,
so you can selectively enable osmux per BSC from one the bsc-nat.cfg
file, so we have a centralized point to enable/disable osmux.
First thing you need to do is to accept requests to use Osmux,
this can be done from VTY interface of osmo-bsc_nat and
osmo-bsc_mgcp by adding the following line:
mgcp
...
osmux on
osmux batch-factor 4
This just initializes the osmux engine. You still have to specify
what BSC uses osmux from osmo-bsc_nat configuration file:
...
bsc 1
osmux on
bsc 2
...
bsc 3
osmux on
In this case, bsc 1 and 3 should use osmux if possible, bsc 2 does
not have osmux enabled.
Thus, you can selectively enable osmux depending on the BSC, and
we have a centralized point for configuration from the bsc-nat to
enable osmux on demand, as suggested by Holger.
At this moment, this patch contains heavy debug logging for each
RTP packet that can be removed later to save cycles.
The RTP ssrc/seqnum/timestamp is randomly allocated for each MDCX that
is received to configure an endpoint.
|