Without this commit it is possible that osmux is disabled again on links with
high jitter. This happens when an MGCP response without X-Osmux header is
received before the NAT receives an Osmux dummy frame from the other side.
Ticket: SYS#2628, SYS#2627
Sponsored-by: On-Waves ehf
Change-Id: Id624b0279aee5e2412059a10296ce7896e2d4628
mgcp_transcode.c: In function 'decode_audio':
mgcp_transcode.c:332:4: warning: format '%d' expects argument of type 'int', but argument 7 has type 'size_t' [-Wformat=]
LOGP(DMGCP, LOGL_ERROR,
^
mgcp_transcode.c:332:4: warning: format '%d' expects argument of type 'int', but argument 8 has type 'long unsigned int' [-Wformat=]
mgcp_transcode.c: In function 'encode_audio':
mgcp_transcode.c:390:4: warning: format '%d' expects argument of type 'int', but argument 7 has type 'size_t' [-Wformat=]
LOGP(DMGCP, LOGL_INFO,
^
mgcp_transcode.c:390:4: warning: format '%d' expects argument of type 'int', but argument 8 has type 'size_t' [-Wformat=]
mgcp_transcode.c: In function 'mgcp_transcoding_process_rtp':
mgcp_transcode.c:542:5: warning: format '%d' expects argument of type 'int', but argument 9 has type 'size_t' [-Wformat=]
LOGP(DMGCP, LOGL_NOTICE,
^
mgcp_transcode.c:571:4: warning: format '%d' expects argument of type 'int', but argument 7 has type 'size_t' [-Wformat=]
LOGP(DMGCP, LOGL_NOTICE,
^
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]
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
Some systems only want to use Osmux. In case only Osmux
should be used fail if it has not be offered/acked.
Client:
Verified On, Off and Only with X-Osmux: 3 and without this field.
<000b> mgcp_protocol.c:823 Osmux only and no osmux offered on 0x14
<000b> mgcp_protocol.c:884 Resource error on 0x14
NAT:
Not tested and implemented
Fixes: OW#1492
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
The log message does not help and says where the data is
being sent to. This is because we have both a RTP and RTCP
port. Remember if we failed with RTCP or RTP and improve
the log message.
I was searching a case where the port was bound to a local
address (e.g. 127.0.0.1) and tried to send the data to a
public one (e.g. 8.8.8.8).
Mike's patch included clean-ups I want to apply separately and
change them a bit. If we return from an else we don't need to
put the else.
* Try the E1 trunk first
* Then try a local virtual trunk
* Fail if none of the above returned
Remove the host portion of the endpoint Id. This requires less
configuration and we are probably fine to trust that MGCP only
received messages designated for it.
When using multiple interfaces on a system one can now configure
which will be served for the BTS ports and which will be served
for the network. The direct usage of source_addr is now only to
initialize the MGCP receiving port itself.
Make it possible to bind the call-agent to a specific IP address
and the network and bts end to different ip addresses. Begin by
clarifying which source ip address we want to have.
Use the existing ulaw encode/decode to support PCMU as well.
The MERA VoIP switch has some severe issues with the GSM codec
and it appears easier to enable transcoding for it.
The mera switch doesn't appear to cope with codec change
between a SIP 180 trying and the 200 ok connection result.
Inserting the codec is touching too many places. Ideally we
should have the transcoding function as pointer in the struct
as well but the arguments differ.. so it is not a direct way
forward.
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.
The NAT sends an incomplete SDP file for the purpose of informing
the BSC about the remote IP/PORT early. The case of an incomplete
SDP file was not considered. Check if there is a codec and if not
skip it.
TODO: We need to have a better end-point life cycle test.
We have a lot of legacy that I am afraid to break. We have
everything in place to make a good codec selection (e.g. if
we can avoid transcoding, pick the one with best quality or
the lowest speed). Right now I have a specific case where
from all options I want to pick GSM. Guard the codec compat
check behind the disallow transcoding option to make sure
to not break legacy application.
First collect everything we know and the mapping. E.g. a genuis
could remap "3" to "AMR" so we only know the codecs once we are
at the end of the SDP file. Once we have collected everything we
can select the audio codecs. The current code is compatible in
that two codecs will be selected regardless of if they make any
sense or not.
mgcp_set_audio_info could re-use some of our codec information
but then the caller in the MGCP protocol needs to be updated as
well as we use the "I: GSM" information to derive the codec from
there.
The SDP file handling will get more complicated in terms of
codec selection so let's remove it from the protocol handling
before we start blowing it up in size.
Currently the src_codec const variable is set to &src_end->codec
before src_end is checked against NULL. Since the assigment is just
an address operation and the memory where it points to is only
accessed after the NULL check, this does not harm technically.
Nevertheless this is potential source for errors if that code is
changed.
This commit moves the definition below the NULL check. This does not
comply with the coding style, but it cannot be split into definition
and a later assignment due to the const qualifier.
Sponsored-by: On-Waves ehf
We might have compiled transcoding into the MGW but
we don't want to enable it for a given user. Add a new
switch that should allow that.
I had manually tested the allow-transcoding/no allow
VTY interface for the primary interface and a new trunk
using show running-config.
It is unlikely that GSM, gsm and GsM refer to different codecs.
The mera mvts does send the audio codecs in lower case even if
RFC 3551 has them in upper case (but copy and paste is sometimes
too hard).
Most of the "fixes" have nothing to do with gcc-4.9.2 but are a
question of ABI/Architecture (e.g. x86 vs. AMD64). Revert these
for now.
This partially reverts commit 7b1d25a11e.
abis_test.c: In function ‘test_simple_sw_config’:
abis_test.c:68:2: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 2 has type ‘int’ [-Wformat=]
printf("Start: %ld len: %zu\n", descr[0].start - simple_config, descr[0].len);
^
abis_test.c: In function ‘test_dual_sw_config’:
abis_test.c:111:2: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 2 has type ‘int’ [-Wformat=]
printf("Start: %ld len: %zu\n", descr[0].start - dual_config, descr[0].len);
^
abis_test.c:115:2: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 2 has type ‘int’ [-Wformat=]
printf("Start: %ld len: %zu\n", descr[1].start - dual_config, descr[1].len);
^
abis_test.c: In function ‘test_sw_selection’:
abis_test.c:132:2: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 2 has type ‘int’ [-Wformat=]
printf("Start: %ld len: %zu\n", descr[0].start - load_config, descr[0].len);
^
abis_test.c:136:2: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 2 has type ‘int’ [-Wformat=]
printf("Start: %ld len: %zu\n", descr[1].start - load_config, descr[1].len);
The session name must be present in a SDP file. The RFC proposes
to use a space for it but the other equipment is using the dash
so I have picked that as well.
RFC 4566:
The "s=" field is the textual session name. There MUST be one and
only one "s=" field per session description. The "s=" field MUST NOT
be empty and SHOULD contain ISO 10646 characters (but see also the
"a=charset" attribute). If a session has no meaningful name, the
alue "s= " SHOULD be used (i.e., a single space as the session
name).
Fixes: RT#2196
For jitter, transit and packet loss we should count the data
that arrived and not the data we send towards the remote. This
is changing the jitter timings to what they were before the
re-factoring.
For forced timing we might willingly add jumps in the sequence
number but for jitter and packet loss we are more interested
in the data that traveled through the wire/air.
The Annex A code has a probation period but we don't have it. When
starting with seq_no==0 do not assume that the sequence numbers
have wrapped. Do it by moving the entire checking code into the
else.
mgcp_patch_and_count has grown due supporting linearizing timestamps,
ssrc and other things for equipment like the ip.access nanoBTS. Fight
back and move the Annex A code into a dedicated method.
The result is updated as we now count after all the patching and for
the Annex A code no change in SSRC can be detected.
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.
In case we get offered G729 and G711 we might have selected
G729 as the audio codec. The first packet we receive might be
G711 though. In that case we will need to change. But only if
we have a matching alternate codec payload_type. E.g. in the
case of comfort noise we will receive the PT=11 and we don't
want to change.
In case of some RTP proxy from time to time we are offered both
G729 and G711 but only one of them will work. I intend to adjust
the codec at runtime in case we receive the wrong codec.
We might be offered multiple codecs by the remote and need to
switch between them once we receive data. Do this by moving it
to a struct so we can separate between proposed and current
codec. In SDP we can have multiple codecs but a global ptime.
The current code doesn't separate that clearly instead we write
it to the main codec.
Use the rtp_hdr structure. The basic alignment issue remains
and I need to merge/cherry-pick Jacob's getters for the ts,
sequence number and other attributes.
The library allows to indicate zero as batch size if you want to use
the default size, however openbsc saves 'osmux batch-size 0' which is
not good as input.
Use OSMUX_BATCH_DEFAULT_MAX to explicitly initialize the batch size
from mgcp_parse_config().
Harald Welte
Alexander Huemer
Daniel Willmann
Holger Hans Peter Freyther