Age | Commit message (Collapse) | Author | Files | Lines |
|
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
|
|
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
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
We want to fail theallocation of an endpoint in case the
transcoding can't be configured.
Manually verified with:
./src/osmo-bsc_mgcp/osmo-bsc_mgcp -c doc/examples/osmo-bsc_mgcp/mgcp.cfg
$ ./contrib/mgcp_server.py
0000 32 30 30 20 33 30 36 39 200 3069
0008 31 20 4F 4B 0D 0A 1 OK.. ('127.0.0.1', 2427)
0000 34 30 30 20 35 39 30 36 400 5906
0008 39 20 46 41 49 4C 0D 0A 9 FAIL.. ('127.0.0.1', 2427)
0000 34 30 30 20 33 35 34 36 400 3546
0008 33 20 46 41 49 4C 0D 0A 3 FAIL.. ('127.0.0.1', 2427)
0000 34 30 30 20 36 32 31 37 400 6217
0008 30 20 46 41 49 4C 0D 0A 0 FAIL.. ('127.0.0.1', 2427)
Verified by not sending L: in the CRCX and then failing on the
MDCX.
|
|
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 7b1d25a11e44bbc1cb0d2acd9f1a3d4a16ec7c90.
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
|
|
Equipment like AudioCode appears to get upset when we use a
builtin type and then assign a name to it. Allow to completely
omit the name.
|
|
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 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.
|
|
** CID 1232804: Unchecked return value (CHECKED_RETURN)
/src/libmgcp/mgcp_protocol.c: 888 in mgcp_parse_osmux_cid()
|
|
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.
|
|
Just a cleanup, wrap around the osmux state information in a struct.
|
|
Jacob pointed out that "free_endp" refers to the memory of
the endpoint being freed. What we want is actually a way to
release an endpoint (and the resource it allocated) or in
the case of the testcase/testapp initialize the data structure
correctly. Introduce two names for that.
|
|
Make sure to re-use the right method for nat traversal. Found
by Roch while looking at traces.
|
|
Currently when ftmp_extra is set, a doubled a=rtpmap line is emitted
instead of the fmtp_extra info.
This patch fixes replaces the formerly copied and pasted but not
modified snprintf parameters by the correct ones.
Fixes: Coverity CID 1220873
Sponsored-by: On-Waves ehf
|
|
Currently, if there is no SDP data in the MGCP message received from
the net, the fields containing audio encoding information are not set
in net_end. So in recvonly mode transcoding would not be set up
correctly.
This patch changes the implementation of the code handling CRCX and
MDCX to use the codec signalled in the MGCP local connection options
(field 'a:') if there isn't any SDP data. This is only halfway
negotiation, because the codec is used blindly and not matched
against the supported ones.
Sponsored-by: On-Waves ehf
|
|
The current transcoder implemenation always does a 1:1 recoding
concerning the duration of a packet. So RTP timestamps and sequence
numbers are not modified.
This is not sufficient in some cases, e.g. when the BTS does only
allow for a single fixed ptime.
This patch decouples encoding from decoding and moves the decoded
samples to the state structure so that samples can be combined or
drain according to the packaging of incoming and outgoing packets.
This patch incorporates parts of Holger's experimental fixes in
0e669e05^..9eba68f9.
Ticket: OW#1111
Sponsored-by: On-Waves ehf
|
|
Don't show media related lines if the payload type has not been set.
Don't show a 'a=rtpmap' line if the audio_name has not been set.
This patch unifies the SDP generation of create_response_with_sdp()
and send_msg().
Sponsored-by: On-Waves ehf
|
|
This patch adds the get_net_downlink_format_cb() callback to provide
payload_type, subtype_name, and fmtp_extra suitable for use in a MGCP
response sent to the network. Per default, the BTS side values are
returned since these must be honoured by the net peer when sending
audio to the media gateway (unless transcoding is done).
Sponsored-by: On-Waves ehf
|
|
This patch adds the fields channels, subtype_name, and audio_name to
the struct. The field audio_name contains the full string that has
been used for the last part of a SDP a=rtpmap line. The others contain
decoded parts of that string. If no a=rtpmap line has been given
(e.g. because dynamic payload types are not used), values are
assigned when the payload type matches one of the predefined ones
(GSM, G729, PCMA).
The patch also moves the audio_name parsing code to a dedicated
set_audio_info() function.
Sponsored-by: On-Waves ehf
|
|
This patch adds the callbacks rtp_processing_cb and
setup_rtp_processing_cb to mgcp_config to support arbitrary RTP
payload processing.
Sponsored-by: On-Waves ehf
|
|
Use the right size for scanf.
=================================================================
==6106== ERROR: AddressSanitizer: unknown-crash on address 0xbffff4b0 at pc 0xb69d87fd bp 0xbffff248 sp 0xbffff21c
WRITE of size 65 at 0xbffff4b0 thread T0
#0 0xb69d87fc (/usr/lib/i386-linux-gnu/libasan.so.0.0.0+0xa7fc)
#1 0xb69d9239 (/usr/lib/i386-linux-gnu/libasan.so.0.0.0+0xb239)
#2 0xb69d92d6 (/usr/lib/i386-linux-gnu/libasan.so.0.0.0+0xb2d6)
#3 0x804f151 (/home/ich/source/gsm/openbsc/openbsc/tests/mgcp/mgcp_test+0x804f151)
#4 0x80531e8 (/home/ich/source/gsm/openbsc/openbsc/tests/mgcp/mgcp_test+0x80531e8)
#5 0x8051e6f (/home/ich/source/gsm/openbsc/openbsc/tests/mgcp/mgcp_test+0x8051e6f)
#6 0x8049b0a (/home/ich/source/gsm/openbsc/openbsc/tests/mgcp/mgcp_test+0x8049b0a)
#7 0x804bd9e (/home/ich/source/gsm/openbsc/openbsc/tests/mgcp/mgcp_test+0x804bd9e)
#8 0xb6778a62 (/lib/i386-linux-gnu/i686/cmov/libc-2.18.so+0x19a62)
#9 0x8049330 (/home/ich/source/gsm/openbsc/openbsc/tests/mgcp/mgcp_test+0x8049330)
Address 0xbffff4b0 is located at offset 416 in frame <parse_sdp_data> of T0's stack:
This frame has 8 object(s):
[32, 36) 'audio_payload'
[96, 100) 'payload'
[160, 164) 'channels'
[224, 228) 'ptime'
[288, 292) 'port'
[352, 368) 'ipv4'
[416, 480) 'audio_name'
[512, 576) 'audio_codec'
HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
(longjmp and C++ exceptions *are*
|
|
In ae1997248ccb4fba1394267d3051082dfd85448a the handwritten tokenizer
was replaced with strtok_r. As part of this change the structural
checking of MGCP parameters was stopped. This means that a code like
"line + 3" might access beyond the first NUL and be possibly behind
the msgb. Manually add size checking again. Manually jumping to the
error label is not possible anymore as it has been removed. The result
is that invalid lines will be skipped. This is matching the general
approach by the IETF RFCs to be permissive in data being received.
|
|
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.
|
|
This patch changes implementation and the mgcp_connection_mode enum
in a way that net_end.output_enabled (bts_end.output_enabled) flag
always matches the MGCP_CONN_SEND_ONLY (MGCP_CONN_RECV_ONLY) bit of
conn_mode.
Based on this, the conn_mode bits are then used instead of the
output_enabled fields within mgcp_protocol.c.
Sponsored-by: On-Waves ehf
|
|
Currently RTP output_enabled is set to 1 on initialisation, which
does not semantically match the initial value of conn_mode
(MGCP_CONN_NONE).
This patch changes this initial value to 0.
Sponsored-by: On-Waves ehf
|
|
So far, a single dummy packet has been sent immediately after the
reception of a MDCX message. There is no dedicated keep alive
mechanism (it just worked because the audio from the MS has always
been forwarded to the NAT until the 'mgcp: Set output_enabled flags
based on the MGCP mode' patch).
This patch adds explicit, timer based keep alive handling that can be
enable per trunk. A VTY command 'rtp keep-alive' command is added for
configuration which can be used to set the interval in seconds, to
send a single packet after the reception of a CRCX/MDCX when RTP data
from the net is expected ('once'), or to disable the feature
completely ('no rtp keep-alive'). In 'send-recv' connections, only
the initial packet is sent if enabled (even when an interval has been
configured). The default is 'once'.
Note that this removes the mgcp_change_cb() from mgcp_main.c.
Sponsored-by: On-Waves ehf
|
|
This patch enhances parse_conn_mode() to set the output_enabled flags
of each end based on the MGCP mode.
Ticket: OW#1044
Sponsored-by: On-Waves ehf
|
|
This patch make it possible to have a valid endpoint that drops all
outgoing RTP packets. The number of dropped packets is shown by the
VTY 'show mgcp' command. By default, this feature is disabled. To
enable packet dropping, the corresponding output_enabled field must
be set to 0.
Ticket: OW#1044
Sponsored-by: On-Waves ehf
|
|
Currently, all timestamps are force to SeqNo*d + C which is more than
required by the nanoBTS which seems to be sensitive to alignment
errors only (dTS != k*d, d = ptime * rate = 160).
This patch replaces the force_constant_timing feature by a
force_aligned_timing feature. The timestamp offset will only be
changed (and timestamp errors counted) when the alignment does not
match to the raster based on ptime (default 20ms).
The VTY interface does not change.
Sponsored-by: On-Waves ehf
|
|
Currently the SDP 'ptime' media attribute is never set in generated
MGCP responses.
This patch optionally includes the 'ptime' attribute if
packet_duration_ms is != 0. This behaviour can be enabled/disabled
by using the VTY command "sdp audio-payload send-ptime" (enabled by
default).
Sponsored-by: On-Waves ehf
|
|
This patch parses the 'ptime' and 'maxptime' SDP attributes, and the
SDP rate information and sets up packet_duration_ms accordingly. If
the packet duration is unknown or allows for different values (e.g.
because 'ptime' uses a range or 'maxptime' allows for more than one
frame) the duration is set to 0.
Sponsored-by: On-Waves ehf
|
|
Currently the local connection options have been stored as a string.
This patch replaces this string by a struct (that still contains a
string) along with the parsed fields (only the packetization period
at the moment).
It also re-adds the calls to set_local_cx_options() to the
handle_create_con() and handle_modify_con() functions. Except for
the test program this has no side effects, since the LCO values
aren't used yet.
|
|
Since the packet duration is given in ms with the 'ptime' RTP media
attribute and also with the 'p' MGCP local connection option, the
computation is changed to use this value (if present). The
computation assumes, that there are N complete frames in a packet and
takes into account, that the ptime value possibly had been rounded
towards the next ms value (which is never the case with a frame length
of exact 20ms).
Sponsored-by: On-Waves ehf
|
|
Currently the output SSRC is always forced to be the same if SSRC
patching is enabled.
This patch modifies this to optionally restrict the number of SSRC
changes that will be corrected.
Note that the configuration only allows for the 'once' mode and 'off'.
Sponsored-by: On-Waves ehf
|
|
This adds datastructures and a VTY frontend to configure the
different type of RTP header patching: SSRC and timestamp.
Note that timestamp patching is not yet implemented.
Sponsored-by: On-Waves ehf
|
|
So far the SDP part of the CRCX message has been ignored by the MGW.
This patch adds SDP parsing for this case, eventually updating the
net end's payload type and connection parameters.
Sponsored-by: On-Waves ehf
|
|
The MGCP message isn't always NUL-terminated when arriving at
mgcp_handle_message(). This may lead to undefined results.
This patch ensures that the message text is NUL-terminated by
setting *msg->tail to '\0' in mgcp_handle_message().
Addresses:
<000b> mgcp_protocol.c:642 Unhandled option: 'r'/114 on 0x3
<000b> mgcp_protocol.c:593 Unhandled SDP option: '='/61 on 0x3
<000b> mgcp_protocol.c:871 Unhandled option: '.'/46 on 0x2
Sponsored-by: On-Waves ehf
|
|
This patch separates the SDP parsing from the (message specific) MGCP
parsing.
Sponsored-by: On-Waves ehf
|
|
This patch add the for_each_line macro based on a strline_r()
function (similar to strtok_r()), that is also part of this patch.
This strline_r() function is tolerant with respect to line endings,
it supports CR-only, CRLF, and LF-only and any combinations thereof
(note that a CRLF is always detected as a single line break).
Similar to for_each_non_empty_line (the former for_each_line) where
the 'save' pointer needed to be initialised by a call to strtok_r(),
the new for_each_line macro expects, that the 'save' pointer has been
initialised by a call to strline_r(). Also note, that
for_each_line/strline_r and for_each_non_empty_line/strtok_r may use
the 'save' pointer differently, so calls to them can not be mixed.
Sponsored-by: On-Waves ehf
|
|
The implementation of for_each_line is based on strtok() and skips
any sequence of CR and LF. Thus empty lines are never detected. There
exists code which tests for an empty line to detect the beginning of
the SDP part which is dead code currently (the parser works
nevertheless due to other reasons). So the semantics of this macro
have been misunderstood at least once.
This patch renames the macro to reflect the semantics more precisely.
Sponsored-by: On-Waves ehf
|