The function mgcp_write_response_sdp() generates the rtpmap lines in the
sdp response. Since we will likely support multiple codecs we will need
to generate several rtpmap lines. Therefore it makes sense to split up
that part in a separate function without altering the overall
functionality (yet)
- add static function add_rtpmap() to generate the rtpmap.
Change-Id: I520e2d40fe6294c88bae63dfcbc5238ef98101e2
Related: OS#3442
When we receive a packet, we do not really check the contents. However,
we should at least do some basic checks.
- Check for short RTP packets
- Check if the length field of RTCP packets seems plausible
- Check if the packet type of RTCP packets makes sense (IANA)
Change-Id: Id47b9eee2164c542e6b673db24974859dd0a7618
Related: OS#3444
At the moment all packets that are sent with mgcp_send are fed into
mgcp_patch_pt(). This functions corrects the payload type so that it
matches the codec configuration on the egress side. However, this
functions is only to be used with RTP packets and must not be used on
RTCP packets, which we currently do because we do not check if the
packet is RTCP or RTP.
- Check if the packet is RTP before running mgcp_patch_pt()
Change-Id: I55b8aa830e4e23f991373470bd04d4db12241c56
Related: OS#3444
The test function test_multilple_codec() in mgcp_test.c creates a
lot of connections, but it never releases them. Just freeing the
cfg object is not enough since the UDP ports stay open and this
may interfere with other tests that also create connections
(port numbers).
- Make sure all endpoints are released when test_multilple_codec()
is done.
Change-Id: Ic13b4368162149ec36c93f4188fa4c71166e08d5
The IETF has designated port 2727 for call agents (clients). This
works as long as only one call agent is running. As soon as two
call agents (e.g. osmo-bsc and osmo-msc) run on the same machine.
The port numbers will collide.
To avoid such a situation we will first try the IETF port and if
we fail to use it we increment the port number until we found a
usable port. However, we should only do this if the user has not
configured a non standard port. (The rationale behind this is that
if there is a non standard port configured the choice must have
been made conciously by the user and therefor we should fail hard
so that the user gets aware of the problem.)
Change-Id: Iaa5f41fdb43ec6bf4feaefa174fd82622e37d4d0
Related: OS#2874
At the moment the mgcp client uses an arbitrary port as sourceport to
exchange MGCP messages with the MGW. However, IETF has designated a
specific port as sourceport for MGCP clients (Call agents), which is
2727. See also RFC3435, capter 3.5 Transmission over UDP.
- Change MGCP_CLIENT_LOCAL_PORT_DEFAULT from 0 to 2727
Change-Id: I96de84df3a3bf623d98b057ec3f3f621a3330a8a
Closes: OS#2874
Since no transcoding is in place osmo-mgw forwards the incoming rtp
packets as they are (there may be minor modifications of the header) from
an ingress connection to an egress connection.
This works without problems as long as both connections use the same
payload type. For IANA defined fixed payload type numbers this is
usually the case, but for dynemic payload type numbers both ends may set
up the same codecs but with different payload type numbers.
When different payload type numbers are set up, and the packet is passed
through without modification, it will have the wrong payload type when
it is sent. The receiving end may then toss the packet since it expects
packets with the payload type it has configured.
The machanism, which is introduced with this patch looks up actual codec
inside the struct data of the ingress connection and then looks for the
matching codec in the struct data of the egress connection. When it
finds the codec there it looks up the payload type of this codec. The
header of the RTP packet is then patched with the correct payoad type.
- Add function mgcp_codec_pt_translate() to look up the payload type
- Add unit-test for function mgcp_codec_pt_translate()
- Add payload type translation to mgcp_network.c
Change-Id: I3a874e59fa07bcc2a67c376cafa197360036f539
Related: OS#2728
Related: OS#3384
The regular version of the mgcp_client supports the configuration of of
custom payload types. In case some corner cases require a specific
dynamic paylod type number that is not according to 3GPP standards has
to be used the user can override the standard settings. However the fsm
based variant of the mgcp_client does not have that feature but it
should have it as well.
- add struct members for ptmap config.
- pass configuration values down to the underlying magcp client.
Change-Id: If176a3719dd9e888da16196d5fc0bdb53cc2a5f2
Related: OS#2728
Related: OS#3384
Some distributions (archlinux) or versions of libgsm install gsm.h in
/usr/include/gsm/gsm.h
Since libgsm doesn't come with a pkfconfig, let's first check if gsm.h
and take the correct path in the build setup.
Change-Id: I07d3c03903e0d4bb80e843c7ed917a27b791ea53
This check is not in all our repos that use git-version-gen. Indeed it
seems to be a leftover of openbsc where I think it wanted to ensure
being called in the openbsc subfolder or something? libosmocore e.g.
doesn't have it.
In any case .git being a directory is not always true (if using git
worktree) so remove this check.
Change-Id: I83b84099c34d593a8a384f001a8131c2a8085606
We currently still patch over an RTP message to make it look like an IuUP
Initialization Ack specifically for the ip.access nano3G femto cell.
Be more specific about it:
- only patch over RTP in 'loopback' mode. osmo-msc specifically leaves the
endpoint in loopback mode for this hack, so if we're not in 'loopback', then
this hack is out of place.
- only patch over RTP if the header indicates an IuUP Initialization (check for
0xe4 byte).
Change-Id: Ia9ec4debc138b34f6ca6a871a8778eafa6c0ba21
The function setup_rtp_processing() in mgcp_protocol.c executes a
function pointer setup_rtp_processing_cb(). The function pointer
gets two struct mgcp_rtp_end pointers as parameter. To get those
parameters it has to dereference them from struct mgcp_conn_rtp
pointers. The variable conn_src is such a struct pointer and there
are conditions where this pointer may be NULL. The function at the
function pointer should get the conn pointers directly instead of
the dereferenced end (rtp) pointers. This also gives additional
flexibility to the implementation behind the function pointer,
which is not yet defined (the function pointer points always to
a stub function since we donot support transcoding yet.
- give conn pointers directly to setup_rtp_processing_cb() insed
of dereferencing conn_src->end
Change-Id: Id46e9bfba88613387026639eb4957221cce6820a
Closes OS#3406
When creating the mgcp statistics (DLCX) and also when printing
values in the VTY. The printf placeholder %lu is used. However,
this is not portable when the same code is compiled on a machine
with different integer size (e.g. armv7).
- Use PRIu64 when printing ->current value of the rate counters
Change-Id: Ifb8944cec83868845f74ad84551eb090f812daf8
In struct mgcp_rtp_end one finds unsigned int counters. Those should
be replaced with libosmocore rate counters
- replace packets_rx, octets_rx, packets_tx, octets_tx and
dropped_packets with libosmocore rate counters.
Change-Id: I47c5c9006df5044e59ddebb895e62adb849d72d5
Related: OS#2517
The struct member rtp_process_data in struct mgcp_rtp_end is
unused and should be removed
- remove rtp_process_data
Change-Id: I3a66d159ce32359621ff2e772ee3421340b78cd5
There has obviously been a misunderstanding on how the doxygen comments work.
A comment marked '<' is for placing a comment *after* a member, to point back
to the item before it, typically
enum foo {
thing, /*!< this is a thing */
a_bobby,
}
It does not make sense to place these above the item they are describing.
We actually don't use doxygen in the osmo-mgw build, but if we have doxygen
syntax, we might as well have the correct one.
Change-Id: I9e8ea0e3bd5ae5fcc0a6fae8e26e11baa8f35e27
The current implementation does not support any way to influence the
codec that is negotiated via SDP or LCO. The client statically
negotitates AMR on an invalid payload type number. Also we ignore
any codec information in the responses.
- Add struct members to allow setting of user defined codec information.
- Add struct members to retrieve parsed codec info from responses.
- Add code to generate codec information in SDP
- Add code to parse SDP codec info in MGCP responses
Change-Id: I78e72d41b73acfcb40599a0ff4823f17c3642059
Related: OS#2728
Related: OS#3334
The codec negotiation via SDP is currently in a neglected state. Also
osmo-mgw does some kind of codec decision wile the SDP is parsed, the
result is information for one codec, even when there are multiple codecs
negotiated. This is problematic because we loose all information about
alternate codecs while we parse. This should be untangled and the
information should be presevered. Also we are not really capable
picking a default. Wehen we do not supply any codec information (not
even LCO), then we should pick a sane default codec.
- separate the codec decision from the sdp parser and concentrate
codec related code in a separate c file
- add support for multiple codecs in one SDP negotiation
- do not initalize "magic" codec defaults during conn allocation
- do not allow invalid payload types, especially not 255. When
someone tries to select an invalid payload type, do not fail
hard, just pick a sane default.
- handle the codec decision in protocol.c, pick a sane default
codec when no (valid) codec has been negotiated (no LCO, no SDP)
Change-Id: If730d022ba6bdb217ad4e20b3fbbd1114dbb4b8f
Closes: OS#2658
Related: OS#3114
Related: OS#2728
Return the CI string allocated by the MGW and sent back during CRCX ACK.
So far the CI that identifies one connection of an MGW endpoint is "hidden"
behind mgcp_conn_* API. This CI string is however very interesting, for
logging, to be able to correlate with MGCP messages in network traces.
For osmo-bsc, there is an upcoming mgw_endpoint_fsm that will log the CI string
using this function.
Change-Id: I0c802c0cc3fa0aae9558bd7f15aad1cb9a8b12b2
At the moment osmo-mgw will accept multiple lco options. (e.g.
p:10, a:PCMU, p:10) If LCO appear multiple times, than the first
appearance of will be parsed and used, all following appearances
will be ignored. However, having multiple appearances of LCO is
illegal and affected requests should be rejected. Also osmo-mgw
should reject illegal formatted LCO strings
- make sure that multiple appearances of LCOs will be rejected
- make sure that illegal formated LCOs are rejected
- add testcases with garbeled LCO and valid LCO examples
Change-Id: Iae2fddfa5f2bcfc952f8ab217b3056694e5f7812
Closes: OS#3119
In the current implementation the LCO parameters are reset. This means
that an MDCX without LCO will reset the LCO that have previously set
via CRCX. But according to RFC 3435 6.8 LocalConnectionOptions, the
LCO parameters should be preserved or left at their defaults if missing.
- Make sure LCO are retained if no LCO string is present.
- Also preserve the values of individual parameters if missing.
Change-Id: Ia0d73f61516618317dcd1d49384818fd8de27aa6
in mgcp_rtp_codec_init() tallo_free is called after codec->subtype_name
and codec->audio_name are set to NULL. So talloc_free() always sees
NULL-pointers and never frees anything. This may cause a memory leak.
- call talloc_free() first, then set pointers to NULL
Change-Id: I7373819c3689d34811846f6f48f27568297b26e4
"unable to create connection resource error" sounds a bit strange.
Lets just output "unable to create connection".
Change-Id: Ibef16b455f2e122c8e5ff95240c4d7a654c56a39
It is legal to create connection without setting the destination
ip and port (this usually done later through MDCX). However, if
some other connection tries to deliver an RTP packet through a
a half open connection, then the fact that no destination ip is
set is logged as error even if it is a pretty normal situation.
- Check if destination ip and port are set to zero. If yes, we
assume that the destination connection details are intentionally
not set yet. Only when one value is set and the other one not,
we log an error. Otherweise we log a message to debug.
Change-Id: If96e5a60b8ab92259d3bddaa143121893bb6c525
Related OS#3104
Starting connections in loopback bode may cause confusion at the
receiving end when the connection is switched from looback into
an actual send-receive connection. The reason for this is by this
the SSRC of the RTP stream will suddenly change. For the majority
of usecases it is not necessary to loopback the incomming packets
back to the receiver in the beginning. So lets use receive-only
as a safe default.
- use MGCP_CONN_RECV_ONLY instead of MGCP_CONN_RECV_LOOPBACK
Change-Id: I44178434ee497bc1d5e9d5f6d92c13c1a09ae241
Related: OS#3104
The function allocate_port tryes at least 200 different ports when
a new port is allocated. Since after every allocation the port
number is incremented the allocation should be able to allocate
a port with the first attempt. However, the number 200 is an
arbitrary number and it will not cover the whole port range in
most cases.
- Make sure that in the worst case at each port in the range
is tryed once, not only the next 200
Change-Id: Ic47f09869eaddd4aea817bb2517362883d65d029
Related: OS#2825
The alt_codec field is not used anywhere in the code
- remove unused alt_codec field
Change-Id: I5ff2899e3e61f33eb86f284b50ad8a94a949ed16
Related: OS#3114
The VTY command that sets the RTP port range does not check if the data
entered by the user actually makes sens. Also it allwos to configur a
range that starts at 0.
- Make sure 0 can not be used as start or end of the range
- make sure the end port number is always greater then the begin
port number
- Autocorrect uneaven port range beginnings to one port number before to
ensure the range starts at an even port number
- Autocorrect even port range ends to the next odd port number to
ensure the range ends at an odd port number.
Change-Id: Ib1312acba4f03f378594dbbeb4f31afd891d68d7
Related: OS#2825
This commit actually doesn't fix the entire code, since anyway osmux
conns are not supported and mgcp_conn_get_rtp() will return NULL.
However, it makes the code more logical and easier to understand once
somebody refactors the code to make it work again.
Change-Id: Ib57e12e5a36b5842c40673c236907bbcbfc390f3
Older ones are being deprecated as they may generate interleaved
packets.
This commit is a forward-port of openbsc.git Change-Id
I189564fc63139c15314db8975afd423c7153ea32.
Change-Id: I9b8a19e5b8d62deaa9bbb92d49d99e8c33b7e345
Default usage values are defined in mgcp node, and can be per-BSC
overriden on each bsc node
This commit is a forward-port of openbsc.git Change-Id
Ibf3932adc07442fb5e9c7a06404853f9d0a20959.
Change-Id: Ie19a64ac09f9d51f2434ad0d7925610fc919a90e
The two counters: in_stream.err_ts_counter and out_stream.err_ts_counter
are still handcoded. To make them better accessible they should
be replaced with libosmocore rate counters.
- replace state.in_stream.err_ts_counter with libosmocore rate counter
- replace state.out_stream.err_ts_counter with libosmocore rate counter
Change-Id: I9fbd65bf2f4d1e015a05996db4c1f7ff20be2c95
Related: OS#2517
The struct state->out_stream.ssrc is initalized by first initalizing
state->in_stream and then copying state->in_stream over to
state->out_stream. This works as long as no pointers to other objects
are added to struct mgcp_rtp_stream_state but we may add pointers to
struct mgcp_rtp_stream_state in the future.
- Initalize out_stream and in_stream independently from each other
Change-Id: I5deb27e609448ee0b9f7034e644ae96f1e57887a
Related: OS#2517
The two counters: in_stream.err_ts_counter and out_stream.err_ts_counter
are still handcoded. To make them better accessible they should
be replaced with libosmocore rate counters.
- replace state.in_stream.err_ts_counter with libosmocore rate counter
- replace state.out_stream.err_ts_counter with libosmocore rate counter
Change-Id: I67aa7a8602f60366ef3ba2c5b1319b1b85719f64
Related: OS#2517