| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Holger reports that the bitmap that accounts for available Osmux circuit
IDs is limited to 128, when the maximum number of circuit IDs are
determined by the uint8_t field in the header (ie. 256 circuits).
[hfreyther: Update the testcase now that we have more ids to allocate]
|
|
For a setup with multiple network interfaces be able to pick
the one that osmux should be used/visible.
|
|
There appears to be a leak of CIDs:
<000b> mgcp_osmux.c:544 All Osmux circuits are in use!
There are paths that a CID had been requested and never released
of the NAT. Remember the allocated CID inside the endpoint so it
can always be released. It is using a new variable as the behavior
for the NAT and MGCP MGW is different.
The allocated_cid must be signed so that we can assign outside
of the 0-255 range of it.
Fixes: OW#1493
|
|
sizeof(uint8_t) == 1 and there is no need to create an array
with 16 bytes and then only use the first two of them. This
means the CID range is from 0 to 127 and we should be able
to extend this to 256 by changing the array size to 32. Update
the testcase now that we can have more than 16 calls with Osmux.
|
|
* Test that one can get an id
* That they are assigned predicatble right now
* That returning them will make the number of used ones go down
* That allocating more will fail
|
|
Iridium is a satellite network which operates a GPRS-like that allows you to
get speeds up to 128kbit/s. However, it takes from 5 to 6 secs to get the
bandwidth allocated, so the conversation is garbled during the time.
This patch uses the new dummy padding support in libosmo-netif that is
controlled through the osmux osmux_xfrm_input_open_circuit().
This includes a new VTY option for osmux.
|
|
Honor the IP_TOS settings for Osmux as well. Re-use the RTP
setting as it makes sense to classify the audio packets the
same way.
Fixes: OW#1369
|
|
This allows us to know what number of messages and bytes has been
received per active osmux endpoint.
Note that an Osmux message is composed of several chunks. Each chunk
contains an osmux header plus several voice data frames.
P: PS=385, OS=11188, PR=195, OR=5655, PL=0, JI=49
X-Osmo-CP: EC TIS=0, TOS=0, TIR=0, TOR=0
X-Osmux-ST: CR=51, BR=3129
The new 'X-Osmux-ST:' notifies the received chunks and bytes.
|
|
Use struct mgcp_rtp_end statistics to account the RTP messages
that has been extracted from the osmux batch and transmitted.
|
|
This allows you to specify the osmux batch frame size. If zero, the
library uses the default value.
|
|
|
|
The callback is responsible for releasing the batch message that
libosmo-netif builds.
|
|
mgcp_send() needs some initialized address when printing a log message.
Nothing really serious but let's calm down valgrind.
|
|
So we can easily identify in the log message what refers to
libosmo-netif and what to libmgcp.
|
