HACK: for IuUP, we want to reply with an IuUP Initialization ACK upon the first RTP
message received. We currently hackishly accomplish that by putting the endpoint in
loopback mode and patching over the looped back RTP message to make it look like an
ack. We don't know the femto cell's IP address and port until the RAB Assignment
Response is received, but the nano3G expects an IuUP Initialization Ack before it even
sends the RAB Assignment Response. Hence, if the remote address is 0.0.0.0 and the
MGCP port is in loopback mode, allow looping back the packet to any source.
None of these are anything near nice, during call setup using a 3G femto cell,
we still lack a proper IuUP handling. See OS#2459, OS#1937. This is merely a
temporary hack to maintain 3G voice usability in a quick and dirty way.
Related: OS#3411
Change-Id: Ib25e6261855eae8ddb8d1c0b8838cc3e30332cf1
Make the 'domain NAME' vty doc more descriptive, and add the hint that '*'
means any domain.
In check_domain_name(), exit early in success if the configured domain name is
'*'.
(Do not implement other wildcard functionality for partial matches or the
like, just the single '*'.)
Related: OS#3490
Change-Id: Ie0220c88d2f5cee15f2a90390b3c4590ac61d5eb
If no endpoint was found, assert that the cause code indicates error, so that
the remaining code path doesn't assume finding an endpoint was successful.
Also fix find_endpoint() to return an error cause (not 0) in case it finds the
domain name to be wrong.
After this, the error described in OS#3488 simply results in a CRCX failure,
not in a program crash.
Related: OS#3488
Change-Id: I87e2d76c22603d6fef89907c3cf8f7965abf35a0
When the user has set a local port for the mgcp client we want the
client to exit if this port is already occupied. If no port is set the
IETF default port is configured automatically. When we find this port
occupied we try up to 100 times the next port to find a useable port.
Since the for loop that controls the attempts always sets the port
config it uses for its checks it will mistakenly assume that the user
has set a port on the second cycle.
- Make sure we only check for the default port in the first cycle
Change-Id: Ic1fd1018d68fcac94961321615bfdd726465532d
The function mgcp_write_response_sdp() is responsible to write the
audio port and the list with the supported payload type numbers to
the sdp response. At the moment it can only write exactly one payload
type number to the response, but in the future we may want to write
several payload type numbers to the response. Lets add a function
for that so that now.
- add add_audio() helper function to add multiple payload type
numbers, but keep the functionality as it is for now
Change-Id: I662c725f697b2ffb1e3ad4671a445f943cd79b63
Related: OS#3442
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 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
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
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 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
The function mgcp_conn_free() holds a few lines to de-initalize
members which are struct mgcp_conn_rtp specific. Since we already
have an mgcp_rtp_conn_init() that does the intialization, we should
have an mgcp_rtp_conn_cleanup() too.
- add function mgcp_rtp_conn_cleanup() and move rtp specific
code to that function.
Change-Id: Ib9bf6d2a3af4f1df1a4ab5ec789b39a2cee2532f
The function mgcp_rtp_codec_reset() is soley called from
mgcp_rtp_conn_init(), lets change the prefix here to _init too.
- rename mgcp_rtp_conn_reset() to mgcp_rtp_conn_init()
Change-Id: I246aabc896089c1f2b3d0409ec3422a85e43575c
The function mgcp_conn_alloc() calls mgcp_rtp_conn_init() to initalize
the RTP specific members (union u.rtp) but also touches u.rtp directly.
This should not be the case, only mgcp_rtp_conn_init() may touch the
union depending on which type of RTP connection is initialized
(currently there is only MGCP_CONN_TYPE_RTP).
- let mgcp_rtp_conn_init() set the backpointer to the generic
conn part.
Change-Id: I6f806f9bfa71b446c15bdc34ae59d2bc1cd10d7e
Note: This is merely a cosmetic change.
We do allocate connections dynamically and we initialize them
once by calling mgcp_rtp_conn_reset(). Calling this a reset
function implies that the reset happens multiple times while
the struct lives. This is not tha case, so lets change the
suffix to _init()
- rename mgcp_rtp_conn_reset() to mgcp_rtp_conn_init()
Change-Id: Ie48b575ff81c8f48afcc25f485967e011e90027b
The enum defining the event and state identifiers is prefixed with
"bsc_".
- coose a more conceise prefix
Change-Id: I662d8e4328911610e7d1943f1b623e96c3a8b3c1
The FSM lacks a proper definition of the FSM event names. This causes
problems when inspecting the FSM using the VTY.
- Add proper FSM Event names
Change-Id: Ic0990abea2e9fd92546e7b337b5ff3d6f0866321
Related: OS#2924
Call osmo_fsm_vty_add_cmds() to make osmo_fsm VTY commands available
in libosmo-mgcp-client's VTY interface.
Change-Id: If772edc304a9f342a57fb548f26908256cc9e6e5
Related: OS#2967
After call to mgcp_find_section_end(), actually check the proper variable to
evaluate its return value.
Show in mgcp_client_test output that the parsing errors are fixed, and enable
the assertion that no tests should fail.
Change-Id: I62a2453cd9e2e7d5408423161fa65ec9c9989f98
The mgcp_response_parse_params() is in a jumble. Straighten out these cosmetic
issues:
- Move assertion of r->body close to its first use.
- Instead of a talloc_zero and osmo_strlcpy dance, simply use talloc_strdup().
- Drop the first unused invocation of mgcp_find_section_end().
- Drop unused assignment of data_ptr = data.
- In the log, mention "SDP" to clarify.
- Add a comment clarifying how we skip the section marker.
Change-Id: Icf1df761270777a142bc8ace75f2a10918314f73
Otherwise we get Osmux stats during a session using RTP, which is
confusing.
Forward-ported from openbsc e39e18992a3b966581f06fa632d6342643996aaa.
Change-Id: I9031350242dd37ce255631c20eed33976887faa6
the client API is not very intuitive and requires a lot of extra
care when it is used from an osmo-fsm.
- Add an FSM that permits comfortable handling of an MGCP
connection.
Change-Id: I887ce0c15a831dffeb6251a975337b83942af566
Since we will support multiple different types of endpoints in the
future, all these endpoints will handle connections slightly different
and there will be possibly state that needs to be kept consistant
when a connection is deleted.
In mgcp_network.c where we implement the callback that is used to
create an rtp-bride-endpoint. In that callback we cache the pointer
of the connection we where we want to bride to (opposite connection).
When one of the connections is deleted using a DLCX operation, the
pointer is still there and the next incoming packet causes a use-
after-free segfault.
- introduce an endpoint specific callback function that is executed
before removing the connection.
- implement the endpoint specific callback for rtp bridge endpoints,
so that the use-after-free is prevented.
Change-Id: I921d9bbe58be1c3298e164a37f3c974880b3759f
When a wildcarded request is made with a DLCX or MDCX command
the MGW will search for a free endpoint and continues the command
execution with that endpoint.
- Catch the wildcarded request early on DLCX and MDCX and return
with an error code.
See also TTCN3 testcases:
MGCP_Test.TC_mdcx_wildcarded
MGCP_Test.TC_dlcx_wildcarded
Change-Id: Ia77d44a6a86083e62338e5845b553e5cf13ebd10
This is an internal library simmilar to 'libmsc' in osmo-msc, which
we don't expect to be used by other programs except osmo-mgw. Hence,
there's no need to install it as a shared library, which introduces
requirements about ABI/API stability and the like.
osmo-bsc_nat uses libosmo-legacy-mgcp, and once we should rewrite
osmo-bsc_nat, we might need some of the libosmo-mgcp related functions,
but at this point it's unclear what exactly would be needed and if
current libosmo-mgcp can provide that. As needed, we can introduce
a related shared library at that point.
Change-Id: Iba0a2c9c694e360356ac2ca584e97795281c6198
When a wildcarded CRCX is done flag "wildcarded_crcx" is set in the
endpoint struct. The flag tells other part of the code whether the
request was wildcarded or not since in some cases the behaviour
might be different for wildcarded requests. The implementation of
this mechanism is not entirely correct. The flag is set on wildcarded
requests but on non wildcarded requests it is not reset. Also the
name is misleading.
- rename wildcarded_crcx to wildcarded_req
- ensure the flag is refreshed with every new request
Change-Id: Ia5063ec65f5bc3a8a0943d1fd823aaeee20b8637
The connection mode setting (e.g. recvonly) is not checked on CRCX
and MDCX. This allows requests that set the connection mode to
sendrecv or sendonly without ever configuring the remote end of
the connection (half-open connection).
- reject sendrecv or sendonly on half open connections
See also TTCN3 Test:
MGCP_Test.TC_crcx_early_bidir_mode
Change-Id: I6ab01855d3b1faa36aebac357e7b97c563990678
Related: OS#2652
The final log lone in find_endpoint() lacks the \n causing a messed
up log output.
- Add missing \n
Change-Id: I97fca654b199dfb7aae2359322a56c6d0bae9599
When set_local_cx_options() returns an error code the MGCP command
execution is aborted and and the error code is returned, but on
CRCX the already seized eindpoint is not released.
- Do not generate the error response on the spot, jump to the
respective label and let the already existing error handling
do its work.
This patch is a follow-up page to:
Change-Id I02aaa3042f2a0e32eb4ec6b8753deab7082947a0
Change-Id: Iaef4ea6c6a2f24ac8b276966bda72d0b30f25cd5
Related: OS#2654
When an unsupported MGCP parameter (e.g. N) is used, then this
parameter is ignored and the command execution continues. However,
an MGCP command that contains an unsupported parameter should
be rejected.
- Make sure that MGCP commands DLCX, CRCX and MDCX are rejected,
when they contain unsupported parameters.
Change-Id: I8cd5987fc6befcd53a7c4916f77b1a24c904ba48
The short term of endpoint has always been "endp" througout the whole
project and not "ep".
- rename mcgp_ep.c to mgcp_endp.c
- rename mgcp_ep.h to mgcp_endp.h
Change-Id: Id52047bb2d0407655ac272c858ed3412b8ae9e6d
In order to allow clean prefixes for future endpoint related
functions the "rlease" should be moved to the end of the
function name.
- rename mgcp_release_endp to mgcp_endp_release
Change-Id: I22e938e702f57ad76d38c9f4a1370b110ac1ba11
The endpoint and the define that computes the endpoint number is
defined in mgcp_internal.h. Since we have a dedicated module for
endpoint related code it makes sense to move the endpoint related
parts there.
- move struct mgcp_endpoint to mgcp_ep.h
- move #define ENDPOINT_NUMBER(endp) to mgcp_ep.h
Change-Id: Ibae55e1859bd41e2d1918eda433418b4bf8365fe
The struct that holds the parsing results of the MGCP response is
allocated on the stack. However, it would make sense to allocate
the struct dynamically on the heap. This also would provide a
talloc context that is in reach on most places of the code.
- Allocate struct mgcp_response dynamically in mgcp_client_rx()
- Use struct mgcp_response as talloc context for temporary
allocated memory while parsing the response.
Change-Id: I5099abe68b580c75b47bc797bf93f01084f0c4db
The client library should be usable to all GPLv2/v3/AGPLv2/v3 programs,
so like our general project practises, let's put it under
GPLv2-or-later. I believe this was unintentional from the beginning.
Our general policy has been:
* libraries under GPLv2-or-later
* applications under AGPLv3-or-later
Change-Id: I29ed7edc510dba67d28b9247aecb4d6d5d25cc0c
When all endpoints are seized and a call agent tries to allocate
another one, then 500 is returned as response code, which means
that the endpoint was not found. This does not match.
- Return 403 which is defined as "Insufficient resources available
at this time"
Change-Id: Idf241b47e711e35e9f9b5a43f3cea5c0298ea30b
When a wildcarded CRCX is done, then the endpoint number is
returned as unsigned integer (%u). This results into problems
with endpoint numbers higher than 9.
- Return endpoint identifier with the endpoint number in
hexadecimal representation
Change-Id: I504f4658c193009347753b15256dbb46b32ad5a4
The function mgcp_msg_gen() does only check if the user supplied
an endpoint name or not. The user may still supply an endpoint
name that does not contain the separator (@) character.
- Refuse to generate the message if the endpoint name does not
contain any @ character.
Change-Id: I92dd1556e4a26b4bef8e1c8c57141552abf988ca
At the moment the client does not check if the endpoint identifier
that is returned from the MGW actually contains an @ character.
- Check if the endpoint id in the response contains an @ character.
Change-Id: I6073419a4b6cdcd31880672564f0861cb4bd02f5
When the client gets a specific endpoint identifier (Z) in a
MGCP response it just accepts the identifier even when it is
not specific (contsins wildcard characters). In those cases,
the client should refuse to parse the response.
- Check for wildcards in endpoint identifiers and stop
parsing when check is positive.
Change-Id: Ic94bd8c025b7b3eb006b639fecfd7282194e504a
When the local connection options in an MDCX or CRCX request
are parsed, then the packetization interval is not checked.
- Check if the packetization is a multiple of 20ms
see also TTCN3 test: MGCP_Test.TC_crcx_unsupp_packet_intv
Change-Id: I02aaa3042f2a0e32eb4ec6b8753deab7082947a0
Related: OS#2654
The parameter ordering of the client responses does not match the
ordering as proposed by by RFC2327, Chapter 6. SDP Specification
- reorder generated SDP parameters so that they match RFC2327
Change-Id: I63cac2ebc982ffead92703c22bf68c7aafa7936c
Some of the line breaks lack the \r character, which leads to an
inconsistancy. While our software and even wireshark does ignore
the problem, other third party implementations might reject those
messages.
- Add the missing \r characters to make the message format
consistant.
Change-Id: I0cd80afae65accd3b4ddc5d82e5d30385879141c
The SDP parameter block must be detached from the regular parameters
using an additional line break (empty line). At the moment this works
because the empty OSMOX variable is added and by this also adds a
line break. It breaks as soon as OSMUX is used again.
- Make clear that no OSMUX variable is added when OSMUX is not in
use.
- Add the extra line break independently
Change-Id: I6261971040db527b96fe79676520ccd7794bd327
While parsing the head of an MGCP response the r->body buffer is
manipulated in order to NUL terminate the extracted comment filed.
- Use a static buffer to store and manipulate the comment field.
Change-Id: Ib273c13d6fe7ee042fb4e3b8ed46ac02602226f6
The function mgcp_response_parse_params() that is used to parse the
SDP parameters edits the content of the r->body.
- Create a local copy of r->body and work on this copy to keep
the original r-body in its original state.
Change-Id: Ia475036f7f3802b1638e0511a5e9162fea1592eb
the virtual trunk is addressed without a prefix (just *@domain).
- reorganize find_endpoint() so that it accepts a prefix when
addressing the virtual trunk.
- do no longer accept wildcarded CRCX requests without prefix
(will not break anything, the feature of wildcarded CRCX is
not in use yet)
- keep the old prefix-less method but print a warning that it is
depreacted.
Change-Id: I2aac3ba0f1f3122dfbb3bf36f74198ecb2b21de5
The mgcp protocol in general allows wildcarded endpoints on CRCX.
osmo-mgw does not support this feature yet.
- when the endpoint name contains a wildcard character, search
a free endpoint automatically
- return the resulting endpoint name in the parameter section of
the mgcp response
- add parsing support for the returned endpoint names
- Be more concious about the parameters that are returned with
each response. Do not unnecessarily attach known parameters.
Return the connection ID only on CRCX commands. Only return
the endpoint ID on CRCX commands that are wildcarded.
Change-Id: Iebc95043569191b6f5fbc8fe266b13fcfcab2e48
related: OS#2631
The mcgp message generator function mgcp_msg_gen() lacks support
for the mandatory SDP fields (v)ersion, (o)rigin, (s)ession and
(t)ime.
- Automatically generate the missing fields when SDP is
generated.
Change-Id: I5fbc31a17e8ac10c7cc5dbc31357b61e8920aaa5
Related: OS#2837
An MDCX without call-id does not make much sense. The call-id is
an integral element of the MDCX message to ensure that the correct
call is modified.
- update the presence check bitmasks to mark the call-id field
mandatory for MDCX requests
Change-Id: Id2bcc3a68139e0d935790bcea2ef91eaf6291aa3
osmo-mgw does not display the IP/Port on which it is listening for
MGCP commands. However, this information can be very helpful when
working with multiple MGCP instances on one machine.
- print IP/Port on which we listen for MGCP commands on startup
Change-Id: Idf5e8b6a7344c4ebaf9b89940456a496b2c23334
The current implementation of mgcp_client.c requires MGCP
paragraphs to be separated wit a \n\n sequence. However,
when the client is used with servers other than osmo-mgcp,
the parapgraph may be formatted differently.
Also allow \n\r\n\r and \r\n\r\n as separator
Change-Id: Ie209fb71499e011e52f58575c6af118de2fdee88
Adding a NUL manually is a common idiom after calling strncpy() because
strncpy() does not always NUL-terminate the string. But snprintf() is
fine.
- remove NUL termination after snprintf in mgcp_send_reset_ep()
Change-Id: I5a1187b13b21b11674f13d3449c730616b0a4ddf
At the moment the MGW has a fixed domain name string that is not even
checked properly.
- Make domain name configurable, use the current "mgw" string as
defualt to maintain compatibility
- Check the domain name with each request. If the endpoint contains
an unexpected domain name, the request must be rejected.
Change-Id: Ia91ac428ba83ac1f9b52a0ec8dbf00ef7876da9e
there is a now obsolete constraint that endpoint numbers must
start at 1.
- remove the check to allow also endpoints starting at 0
Change-Id: Iec2f4e36e1ab01ff23875d99e4b0e04af7c1ad98
The osmo-mgw gerrit build is currently failing with the following error:
make[3]: Entering directory '/build/src/osmo-bsc_mgcp'
CC mgcp_main.o
In file included from ../../include/osmocom/legacy_mgcp/mgcp_internal.h:146:0,
from mgcp_main.c:36:
../../include/osmocom/legacy_mgcp/osmux.h:4:33: fatal error: osmocom/netif/osmux.h: No such file or directory
#include <osmocom/netif/osmux.h>
^
compilation terminated.
Let's make sure we're adding the required flags/libs for libosmonetif dependency
Related: OS#2829
Change-Id: I402314532590498a6340dc14101a32b605cd5e09
There's no need for us to use the sockets API directly: We have
pretty nice socket helper functions in libosmocore, let's make
use of them.
Change-Id: I39d47b8a27f683060a2facf2dbecff8d00c19ce9
Previously we
* did not distinguish between the cause of errors in mgcp_header_parse
* common errors were not handled in mgcp_handle_message() but in
individual per-verb functions
Let's centralize the handling of generating error responses and remove
that burden from the individual per-verb handler functions.
Change-Id: I463b27306e10ae3b021583ed102977e7299e5e66
Neels Hofmeyr
Pau Espin
Philipp Maier
Harald Welte