| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This API is a bit unfortunate as the caller will also
access the endpoint directly. E.g. like this:
output = bsc_mgcp_rewrite(...,
mgcp_net_src_addr(endp),
endp->net_end.local_port, -1,
In terms of "terminology" the "net" was meant to be bad
internet and the "bts" is the local and trusted network
segment. With this terminology the "bts" would be the
call-agent/MGW and "net" where the BSCs will send data
to but that is not the case and terminology actuallys
refers to:
* net: The addresses exposed to the entity that
made the MGCP call
* bts: The system where we get our data for the
local audio flow.
Fix the method but leave the API as it is. Use the net_end
in the net_src method and the bts_end in the bts_src method.
|
|
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
|
|
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.
|
|
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.
|
|
This struct was removed when we switched to strtok_r for
parsing the data. Remove the left-over.
|
|
ENDPOINT_NUMBER takes the difference of two pointers. On 64bit
builds the difference is a long and the compiler then complains
about the usage of abs. We will never have thousands of endpoints
so silence the warning by casting the ENDPOINT_NUMBER to int.
mgcp_vty.c:1381:34: warning: absolute value function 'abs' given an argument of type 'long' but has parameter of
type 'int' which may cause truncation of value [-Wabsolute-value]
rtp_port = rtp_calculate_port(ENDPOINT_NUMBER(endp),
^
../../include/openbsc/mgcp_internal.h:206:31: note: expanded from macro 'ENDPOINT_NUMBER'
#define ENDPOINT_NUMBER(endp) abs(endp - endp->tcfg->endpoints)
^
mgcp_vty.c:1381:34: note: use function 'labs' instead
|
|
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
|
|
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 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.
|
|
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.
|
|
Just a cleanup, wrap around the osmux state information in a struct.
|
|
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
|
|
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
|
|
The filename is mgcp_internal.h but the define refers to MGCP_DATA.
Avoid having a potential clash by using the #pragma once option.
|
|
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.
|
|
Currently, when the SSRC changes within a stream and SSRC fixing is
enabled, the RTP timestamp between the last packet that has been
received with the old SSRC and the first packet of the new SSRC
is always incremented by one packet duration.
This can lead to audio muting (at least with the nanoBTS) when the
wallclock interval between these packets is too large (> 1s).
This patch changes the implementation to base the RTP timestamp offset
on the wallclock interval that has passed between these two packets.
Ticket: OW#466
Sponsored-by: On-Waves ehf
|
|
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
|
|
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 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
|
|
This forces the output timing to fulfill
dTS = dSegNo * fixedPacketDuration
where dSegNo = seqNo - lastSeqNo.
If timestamp patching is enabled, the output timestamp will be set
to lastTimestamp + dTS. This kind of relative updating is used to
handle seqNo- and timestamp-wraparounds properly.
The updating of timestamp and SSRC has been separated and the patch
field of mgcp_rtp_state has been renamed to patch_ssrc to reflect
it's semantics more closely. The offset fields are now used always
and will change the corresponding header field if they are != 0.
Ticket: OW#1065
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 patch adds a packet_duration field to mgcp_rtp_state which
contains the RTP packet's duration in RTP timestamp units or 0, when
the duration is unknown or not fixed.
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
|
|
The current implementation increments the seqno but does not increment
the RTP timestamp, leading to two identical timestamps following one
after the other.
This patch fixes this by adding the computed tsdelta when the offset
is calulated. In the unlikely case, that a tsdelta hasn't been
computed yet when the SSRC changes, a tsdelta is computed based on
the RTP rate and a RTP packet duration of 20ms (one speech frame per
channel and packet). If the RTP rate is not known, a rate of 8000 is
assumed.
Note that this approach presumes, that the per RTP packet duration
(in samples) is the same for the last two packets of the stream being
replaced (the first one).
Sponsored-by: On-Waves ehf
|
|
This patch modifies the patch_and_count() function to check for RTP
timestamp inconsistencies. It basically checks, whether dTS/dSeqNo
remains constant. If this fails, the corresponding counter is
incremented. There are four counter for this: Incoming and outgoing,
each for streams from the BTS and the net.
Note that this approach presumes, that the per RTP packet duration
(in samples) remains the same throughout the entire stream. Changing
the number of speech frames per channel and packet will be detected
as error.
In addition, the VTY command 'show mgcp' is extended by an optional
'stats' to show the counter values, too.
Ticket: OW#964
Sponsored-by: On-Waves ehf
|
|
This patch replaces the field 'is_transcoded' in the mgcp_endpoint
structure by the enum mgcp_type, that can be further extended with
new types.
|
|
In case of AMR one can specify the available codecs out-of-band. Allow
to configure this line statically in the configuration file.
|
|
MGCP is used over UDP and a response might be lost. The MGCP RFC
asks for keeping a list of responses and then using the previous
response to answer a duplicate request. I tried to conserve memory
and just wanted to remember the last transaction identifier and
result-code and re-generate the result from that. This made the
code look bad and this is why the entire response will now be stored.
It sadly increases the memory usage but can not be avoided at this
time.
Remove the msg->l3h pointer for the RQNT callback as strtok has
modified the content of it.
|
|
|
|
Use a usec timestamp for the local time. The seconds to usec will
swap over to the lower bits but this appears to be correct. The
CLOCK_MONOTONIC is used to fulfill the RFC 3550 requirement even
if it is a bit slower than the gettimeofday.
Make sure to initialize transit in a way that the first transit
time will be 0. Otherwise the jitter will contain the difference
of the localtime and the remote time.
|
|
Calculate the expected packages and packet loss as of RFC 3550.
The values should be clamped but our packet loss counter is 32
bits and not 24 and we should clamp at other values but I am
waiting for some issues first before dealing with that.
|
|
This is missing the probation and the dealing with a remote
restart. For the remote restart we will simply write a log
statement as this is unlikely to happen during a call or if
it does happen the call will be taken down by the BSC anyway.
|
|
Align the naming inside the mgcp_rtp_state with the naming inside
the 'source' struct of the appendix. Make first_seq_no/base_seq
a uint16_t. This is removing rules for alignments and reduces the
struct from 40 bytes to 36.
|
|
This information is required for calculating the packet loss at the
end of a phone call.
|
|
Count the received octets. This is encouraged by the MGCP specification.
Use a 32bit counter that is good enough for more than 12 hours of a EFR
call. This limit is good enough for the current configuration.
|
|
The RFC 3435 specifies a different formula for calculating the lost
packages. It involves the number of received packages and the delta
of the sequence number.
|
|
Instead of building complex manual byte-wise parsers, we simply use two
strtok_r loops: one iterating over all the lines, the next one
iterating over the invididual space-separated elements in the first line.
The benefit is that we now accept \r, \n or \r\n, or any multiple of
them as line ending. This works around incompliant MGCP implementations
like that of Zynetix MSC.
Addition: mgcp_analyze_header returns 0 when all out parameters have
been set.
Signed-off-by: Holger Hans Peter Freyther <zecke@selfish.org>
|
|
Summary of changes:
s/struct bsc_fd/struct osmo_fd/g
s/bsc_register_fd/osmo_fd_register/g
s/bsc_unregister_fd/osmo_fd_unregister/g
s/bsc_select_main/osmo_select_main/g
|
|
libosmogsm is a new library that is distributed in the libosmocore.
Now, openbsc depends on it. This patch gets openbsc with this
change.
This patch also rewrites all include path to the new
osmocom/[gsm|core]
Signed-off-by: Pablo Neira Ayuso <pablo@gnumonks.org>
|
|
A trunk will always have 32 endpoints to be used and we allow
a sparse allocation of endpoints.
|
