So far, both osmo-msc and osmo-bsc always pass endpoint names of the form
'...@mgw' to osmo-mgw. Allow configuring the 'mgw' part.
Note that the actual way to pass a differing name is to pass a composed
'rtpbridge/*@foo' to mgcp_msg_gen() in the struct mgcp_msg. So this merely adds
a common VTY config for the domain name part, changes to clients are necessary.
- add mgcp_client_rtpbridge_wildcard() (useful for AoIP endpoints)
- add mgcp_client_endpoint_domain() (useful for SCCPlite endpoints)
- add mgcp client vty cfg 'mgw endpoint-domain NAME'
Rationale: reading pcaps becomes so much easier when each of osmo-bsc and
osmo-msc address their MGW with differing domain names. Otherwise, both will
have a '0@mgw' endpoint and it gets really confusing.
Also: our MGCP clients osmo-bsc and osmo-msc use code dup to compose the
initial 'rtpbridge/*@mgw' rtpbridge wildcard. It should be defined by this API
instead.
This will be used by:
* osmo-msc I87ac11847d1a6d165ee9a2b5d8a4978e7ac73433
* osmo-bsc I492023e9dca0233ec0a077032455d9f2e3880f78
After these, with according configuration, there can be a '0@bsc' and a '0@msc'
endpoint on two separate osmo-mgw instances:
osmo-mgw-for-bsc.cfg:
mgcp
domain bsc
osmo-bsc.cfg:
msc 0
mgw endpoint-domain bsc
osmo-mgw-for-msc.cfg:
mgcp
domain msc
osmo-msc.cfg:
msc
mgw endpoint-domain msc
There can also be '0@bsc' and '1@msc' endpoints on one single osmo-mgw instance with:
osmo-mgw.cfg:
mgcp
domain *
and same osmo-{bsc,msc}.cfg as above.
(By default, everything will still use '@mgw')
Change-Id: Ia662016f29dd8727d9c4626d726729641e21e1f8
Fix typos, use osmo_sock_get_name2() to show the tx source and target IP:port,
shorten some wording.
Depends: I8ad89ac447c9c582742e70d082072bdd40a5a398 (libosmocore)
Change-Id: Iae728192f499330d16836d9435648f6b8ed213b6
Remove public API that makes no sense anymore and is dead code.
I see the dropped API as a dead-end initial misconception of the early mgcp
client, and it doesn't really make sense to drag this stuff along. It has not
been used by osmo-msc,-bsc for a long time now, and just confuses the reader.
It is public API, yes, and older versions of osmo-msc / osmo-bsc will not be
able to compile against this, but even if it did, the resulting MGCP client
would not work with the current osmo-mgw: this API is still based on the
premise that the MGCP client dictates the MGW endpoint numbers, a concept that
cannot be used with the current osmo-mgw. Instead, osmo-mgw expects a
wildcarded endpoint upon CRCX and assigns its own endpoint names.
Also, the bts-base configuration is unused and a legacy of when osmo-bsc_mgcp
had explicit BTS and CN sides.
Change-Id: I98a9f1f17a1c4ab20cea3b08c7d21663592134d6
If the vty client enters multiple local / remote addresses, that leaks talloc
memory of the previously set addresses. Free those first, if any, using
osmo_talloc_replace_string().
Change-Id: I331b3d53b5eb330b87d798f952077a043674d409
Add the expected domain name, and move the error log to where the expected
domain name is compared.
Change-Id: I59f40dc9263f686852f103ca904fc0a6702d7c8e
Half of those are obviously zero, but I'd rather print the raw data instead of
adding string constants, even if the condition must always lead to 0.0.0.0:0.
Rationale: I had osmo-mgw listen on 0.0.0.0 and got the error message
DRTP ERROR endpoint:0x1 destination IP-address is invalid
which didn't convey that 0.0.0.0 is regarded as invalid.
Change-Id: I9e98d464a27038904797c5c10735a98ef5b7b9c3
mgcp_do_write() is the final stage of writing data towards the MGCP server
(MGW). In that function, drop an unconditional iteration and copy of the MGCP
message to a static string buffer for no apparent reason besides debug logging.
Instead, use osmo_escape_str() with a limited length, which can just be an
inline format argument in the LOGP() statement. This way, the string mangling
is simpler and only gets run when DMGCP is actually on debug log level.
Change-Id: Id6877ed7fd7dbe009b2ece8792d5160d040c1aaa
Add new environment variables WITH_MANUALS and PUBLISH to control if
the manuals should be built and uploaded. Describe all environment vars
on top of the file.
When WITH_MANUALS is set, install osmo-gsm-manuals like any other
dependency and add --enable-manuals to the configure flags (for "make"
and "make distcheck"). Add the bin subdir of the installed files to
PATH, so osmo-gsm-manuals-check-depends can be used by ./configure.
Related: OS#3385
Change-Id: I24179b21ce4ff182649243e286c87c824b889454
Set AM_DISTCHECK_CONFIGURE_FLAGS in Makefile.am instead of
DISTCHECK_CONFIGURE_FLAGS. This is the recommended way from the
automake manual, as otherwise the flag can't be changed by the user
anymore.
Related: OS#3718
Change-Id: Ie9db1519e89d2a8ca1e403e480f57d72fc25ab75
Jenkins currently runs the build twice, once with
MGCP="--enable-mgcp-transcoding" and once with
MGCP="--disable-mgcp-transcoding". The configure.ac does not have this
parameter, so let's remove the confusing variable.
This is in preparation for describing all environment variables used in
jenkins.sh (follow up commit).
Change-Id: I6223afef0f34d90170a691d7d5b1d9542c34c6b0
Moved to doc/manuals/, with full commit history, in preceding merge commit.
Now incorporate in the build system.
Build with:
$ autoreconf -fi
$ ./configure --enable-manuals
$ make
Shared files from osmo-gsm-manuals.git are found automatically if
- the repository is checked out in ../osmo-gsm-manuals; or
- if it osmo-gsm-manuals was installed with "make install"; or
- OSMO_GSM_MANUALS_DIR is set.
Related: OS#3385
Change-Id: I504f05a49721f2dfe105b6c5fd1995c4e7a0be9c
See also Ia6fe5ead4b601931c1bf41b29fc1b237aac37d2c in osmo-mgw.git, which
changes the initial single-character implementation to match this specification
of string tokens separated by spaces.
Change-Id: If15a88c3b5b40fd1d24ad0f94f3231f678669ab1
This is the first update since the libosmocore changes to the 'show
online-help' generated output. Hence the produced document now benefits from
the structural improvements:
- not repeating common commands for every node;
- using section names that match the VTY prompt.
Change-Id: I79804ec0e61cc19a679f079a083a5ea2ea3ee2de
Add a counter group for DLCX commands. The group contains counters for
successful connection processing as well as various error conditions.
This provides a quick overview of DLCX failures on each trunk throughout
the lifetime of the osmo-mgw process.
The counters are displayed by 'show mgcp stats' and 'show rate-counters'
While here, rename MGCP_MDCX_FAIL_DEFERRED_BY_POLICY to
MGCP_MDCX_DEFERRED_BY_POLICY; we have decided that deferred connections
aren't failures, and this keeps names used by DLCX and MDCX in sync.
Also remove some allocation failure checks with OSMO_ASSERT(); such
checks aren't en vogue anymore.
Change-Id: Ie0dde2faf02fd68a69f986973d39b1bea367039b
Depends: I80d36181600901ae2e0f321dc02b5d54ddc94139I
Related: OS#2660
Even though osmo-mgw advertises the -s option, the getopt configuration lacks
-s and that option does not work. Thus the osmo-mgw.service file that uses -s
was unable to start.
Add 's' to the getopt configuration, fix -s and hence also fix the .service
file.
Change-Id: I6f298aef73eb3486d04706910e9fdbaaebaf2481
The function that parses the LCO uses an internal buffer to store the
codec name that has been issued via LCO. This buffer is only 9 byte
long, this means an 8 character string can be stored. If a codec name
exceeds this limit it gets chopped. For example "GSM-HR-08" becomes
"GSM-HR-0", which may mess up the codec negotiation.
- Increase the buffer from 9 to 17 byte.
Change-Id: I17ce7acde1f23ab1394227d74214fe2a55cd2264
Related: OS#3673
Add a counter group for aggregated RTP connection statistics.
This group contains RTP counters which aggregate values of the
ephemeral RTP counters maintained per connection (mgcp_conn).
This provides a global overview of RTP processing for each
trunk throughout the lifetime of the osmo-mgw process.
The counters are displayed by 'show mgcp stats' and 'show rate-counters'.
While here, fix a typo in an item of the mgcp_conn_rate_ctr_desc array:
"rtp:octets_rx" was displayed for outbound packes; now says "_tx".
Change-Id: I80d36181600901ae2e0f321dc02b5d54ddc94139
Related: OS#2660
Add a counter group for MDCX commands. The group contains counters for
successful connection processing as well as various error conditions.
This provides a quick overview of MDCX failures on each trunk throughout
the lifetime of the osmo-mgw process.
The counters are displayed by 'show mgcp stats' and 'show rate-counters'.
Change-Id: I79c27425ba40c3a85edc6cd846cba325d847298c
Depends: Ia2004f8063f3a50b5d7a838ebe8a784a47fcc50d
Related: OS#2660
Add counters for error conditions which I overlooked in
commit 1e174875bf
Change-Id: Ia2004f8063f3a50b5d7a838ebe8a784a47fcc50d
Depends: If4f097c5e441914eaa24c7657813ebb3f9a49916
Related: OS#2660
Use a local variable to shorten the length of rate counter names.
Cosmetic only; no functional change.
Change-Id: If4f097c5e441914eaa24c7657813ebb3f9a49916
Related: OS#2660
Make the 'mgcp show stats' VTY command display TX/RX counters
for an RTP stream. This command was already showing the counter
for dropped packets from the same counter group, so it seems
natural to display other relevant counters in the group as well.
Change-Id: I1313e64d7d8b49964f21fc8d213cba6c9fb6c7cf
Related: OS#2660
Add a counter group for CRCX commands. The group contains counters for
successful connection processing as well as various error conditions.
This provides a quick overview of CRCX failures on each trunk throughout
the lifetime of the osmo-mgw process.
For example, after running the TTCN3 mgw test suite, the counters show
the following values:
OsmoMGW> show rate-counters
crxc statistics:
crcx:success: 88 (0/s 88/m 0/h 0/d) CRCX command processed successfully.
crcx:bad_action: 0 (0/s 0/m 0/h 0/d) bad action in CRCX command.
crcx:unhandled_param: 1 (0/s 1/m 0/h 0/d) unhandled parameter in CRCX command.
crcx:missing_callid: 1 (0/s 1/m 0/h 0/d) missing CallId in CRCX command.
crcx:invalid_mode: 1 (0/s 1/m 0/h 0/d) connection invalid mode in CRCX command.
crcx:limit_exceeded: 0 (0/s 0/m 0/h 0/d) limit of concurrent connections was reached.
crcx:unkown_callid: 0 (0/s 0/m 0/h 0/d) unknown CallId in CRCX command.
crcx:alloc_conn_fail: 0 (0/s 0/m 0/h 0/d) connection allocation failure.
crcx:no_remote_conn_desc: 1 (0/s 1/m 0/h 0/d) no opposite end specified for connection.
crcx:start_rtp_failure: 0 (0/s 0/m 0/h 0/d) failure to start RTP processing.
crcx:conn_rejected: 0 (0/s 0/m 0/h 0/d) connection rejected by policy.
OsmoMGW>
These same counters are now also shown by 'show mgcp stats'
in the context of the trunk which they belong to.
With input from Philipp Maier.
Change-Id: Ida82fc340d5c66180e5fe9a0d195e9be6dc64c61
Related: OS#2660
in_addr consists only of s_addr, which is an integer type that
can be compared directly. By avoiding memcmp() here we would have
been able to catch Coverity CID#188874 even without Coverity, and
make the code more compact...
Change-Id: Ic6105d39ae2fb4b301f87448b16763fe9f695621
We were comparing 16 bytes (sockaddr_in) in memcmp() rather than using
four bytes (struct in_addr in mgcp conn end).
This is a good example why we should actually simply use the == (equals)
operator rather than using memcmp which treats everything as void.
Change-Id: Ic64256619ef893d625400e8b1b573ea2c629ed9c
Fixes: Coverity CID#188874
* Refactor code to have unified checks on all paths activating Osmux.
* Improve checkings at activation time and add logging.
* Code now enforces endp osmux status to be enabled before processing
the frame through endp->osmux.out. Before, a delayed or bad pkt could
arrive and be processed by an endp with osmux not enabled, using
endp->osmux.out that was not initialized and ended up crashing:
libosmo-netif/src/osmux.c:281:3: runtime error: member access within null pointer of type 'struct msgb'
This could also happen if a BSC started sending or we received (non legacy dummy) osmux
frames before we received the BSC CRCX ACK agreeing on osmux negotiation
and switching to ACTIVATING state.
Related: SYS#4350
Port from openbsc 4a2cc9eb0a0f9424c16b26fcb757483a39d67482.
Includes fixup from openbsc I438349bffaa46a10ad8983090a4b17aed7e00d82.
Change-Id: Iac11e447ec0d76e4e74ec982a6e3f63b35548978
State ACTIVATING is set once negotiation between the 2 parts went
successfuly.
Port from openbsc 96bd7b075a59eb051079152241b127ca944b0781.
Change-Id: Ic56eda1251be41369d869e687a1cf955df2c6d61
Prior to this commit, the check was only done on legacy dummy frames.
Port from openbsc a42d4584fd01c9cd1021fab609bdaaafe859c13a.
Change-Id: I5b6606d72a9f5ae593a8e3ab5fbbe7e1e5a0ae11
Otherwise we end up in a weird state where we have timers set up but
osmux is still flagged as not enabled.
Cherry-picked from openbsc cad739d2386640a68c24e3d470ddacdcaf377561.
Change-Id: I0a334842463d311bc80a980e60fb702a0a9ad610
Since that define is already used to allocate size of osmux_cid_bitmap,
let's use it here too instead of hardcoding its value.
Change-Id: Ib2e4febee8bc6bcc035ad0a65c5c1eb94ef5e6fb
Right now it's not a big issue since OSMUX_CID_MAX is 255, so 255+1 is
256 which fits array boundaries correctly (multiple of 8). However, if
for example OSMUX_CID_MAX was modified to be 12, 12+1/8 = 1, so we'd
have an undesired memory access when accessing last 4 CIDs.
A +1 should be kept on top, because OSMUX_CID_MAX specified the maximum
number used by a CID, that is (0,OSMUX_CID_MAX), and as a result we
require OSMUX_CID_MAX+1 slots.
Change-Id: Iaf9b93712dbd2a862b01e70dd8e11893bfa6b24c
osmo-bsc-mgcp was removed recently from osmo-mgw.git as it belongs to
openbsc.git.
This symlink was a leftover from that time.
Change-Id: Ifdcb266efd821eac9d90aff186400f85751e8f42
When the peer address is still 0.0.0.0, the endpoint is not yet configured.
This commonly happens before bridging a call is complete, so instead of ERROR
logging about an invalid packet, rather INFO-log this as "early media".
Related: OS#3539
Change-Id: I335f6453bd599be76eef08fcf9e5daed071e5b6d
The Connection Identifier is defined as a hex string, so clients may send the
ID back with or without leading zeros. Ignore all leading zeros when comparing.
A specific SCCPlite MSC is observed to DLCX with Connection Identifier with
leading zeros removed, which would mismatch pefore this patch.
Extend test_conn_id_matching() in mgcp_test.c to include leading zero tests.
Now, mgcp_conn_get() would match a valid id with *any* amount of leading zeros,
even if that far surpasses the permitted conn id length. Valid lengths of
incoming conn ids should be and is checked elsewhere.
Related: OS#3509
Change-Id: If55a64a2da47b6eff035711c08e4114d70dbec91
The Connection Identifier is defined as a hex string, so clients may send the
ID back in lower case. Convert to upper case before comparing.
A specific SCCPlite MSC is observed to DLCX with Connection Identifier in lower
case, which would mismatch pefore this patch.
Add test_conn_id_matching() in mgcp_test.c to verify case insensitivity.
Cosmetic: use strcmp(), not strncmp(). In the presence of a terminating nul as
we can assume here, this makes no functional difference, but it clarifies the
code.
Related: OS#3508
Depends: Ib0ee1206b9f31d7ba25c31f8008119ac55440797 (libosmocore)
Change-Id: I8e52278c3abe9e9c8c848c2b1538bce443f68a43
Reduce the number of hex chars generated as Connection Identifier from 32 to 8.
According to RFC3435 2.1.3.2 "Names of Connections", the maximum length is
indeed 32 characters, but there isn't really a benefit of using IDs of that
size. That, and:
A specific SCCPlite MSC is seen to be able to store conn IDs of up to 8 hex
characters of length. If given more than that, it will later send 'ffffffff' as
ID, e.g. in the DLCX message, causing mismatches and rejected DLCX.
Conn IDs need to be unique only within the context of one endpoint, so
producing 32 characters of ID is far beyond overkill, especially if we
currently expect exactly two IDs per endpoint.
Notice that the maximum length of conn ID that can be handled by the message
parsing and composition doesn't change, only the length that an osmo-mgw will
generate upon CRCX does.
Related: OS#3507
Change-Id: Ia290c22a91fca0e5aa44515fca6df00064aff100
MGCP_CONN_ID_MAXLEN actually includes a terminating nul, so we need to compare
strlen() against MGCP_CONN_ID_MAXLEN-1.
Log the length if it is too long.
Add MDCX_TOO_LONG_CI test to mgcp_test.c, testing a conn id of 33 characters.
Before this patch, the test returns error code 515 meaning "not found", while
now it returns 510 meaning "invalid", showing the off-by-one. Same is
illustrated by the error log ("not found" before, "too long" now), but the
error log is not verified by mgcp_test.c.
Change-Id: I8d6cc96be252bb486e94f343a8c7cae641ff9429
Instead of just -1, return RFC3435 error codes that can be used to compose a
FAIL message response. Note that the return value stays compatible in that it
returns 0 on a valid Connection Identifier, nonzero otherwise.
The idea is to be able to distinguish between "Conn ID not found" and "Conn ID
invalid" in mgcp_test.c's expected output, in upcoming change
I8d6cc96be252bb486e94f343a8c7cae641ff9429.
Change-Id: Ifc17f2893cc4b9a865f3ffcb9888bbf1039337a6
So far, MGCP_CONN_ID_LENGTH was often used as exactly the length of the
Connection Identifier. To indicate this length as a maximum, introduce the
MGCP_CONN_ID_MAXLEN and use it everywhere. Keep the old name as an alias.
Change-Id: I1117003c7614e98535d5c201d002e459c01bdc3f
Instead of just silently truncating the conn ID if it is too long, rather
verify its length and return an error where applicable.
Adjust expected test output.
Change-Id: If2a1aab1f13e771a6705c430e3c75bd42477a23b
Add a full length (32 characters according to spec) conn ID in a CRCX response,
as well as a too long one.
The too long one is currently silently truncated, a subsequent patch will
improve on that (If2a1aab1f13e771a6705c430e3c75bd42477a23b).
Change-Id: I5f2d52f086ea2d330fcce88a176488ace972bf79
The separator between MGCP and SDP section is typically "\r\n\r\n". For some
reason the test so far used "\n\n" instead, rather use the standard separator.
Change-Id: I41c73722e5fae00663bcf96de0b57b7155809a06
I want to test arbitrary length Conn IDs ('I:'), and hence don't want to pass
the conn_id as int, but rather just include it in the message string. Prepare
for that by eliminating the extra conn_id arg and just pass a params string.
Change-Id: Ib2e718dda3aa1f6e9979dee823d973dd002e2318
The .tarball-version file should contain the *source version* uniquely
identifying the git commit, and not the Debian package name.
With https://gerrit.osmocom.org/#/c/osmo-ci/+/10343/ there is a correct
.tarball-version file in the .tar.xz of the nightly source packages.
Change-Id: I4bf7b6124c747a0cff5562187a099c33525e109e
Related: OS#3449
This function is set on conn ID length of 32 characters. Make it detect a
shorter length also when parsing 'o=-' headers. Before, this failed to
recognize a space as the end of the conn ID, now sees any non-hex char as end.
Related: OS#3507
Change-Id: I762c273bac172acb6d0aae6ea6267603ab654cbf
Flip logic to accurately log whether an 'I:' is included, instead of logging
the opposite.
Note that it isn't possible to log the actual conn ID, because they are random
and differ in every test run, which would collide with the fixed expected
output file mgcp_test.ok.
Change-Id: Idcd731b9daf618b97d8f7e6a776266071cd29e08
The change Ie51cc86e90ffeca5b66bcb8f6db0d389241abe57 has replaced the
functions make_crcx_msg_bind() and make_crcx_msg_bind_connect() with
make_crcx_msg() and add_audio(). When a bidirectional connection is
needed, the user calls add_audio() to add the remaining connection
details. Unfortunately add_audio() leaves the conn_mode struct member
unchanged. Which means the connection is still at MGCP_CONN_RECV_ONLY,
which will instruct the MGW not to forward any of the received packets.
- Make sure that conn_mode is set to MGCP_CONN_RECV_SEND when
add_audio() is called.
Change-Id: Id12de37797de5af5cc447642d2fbb1af7de680df
Closes: OS#3511
Adjust the X-Osmo-IGN parsing to use string tokens instead of parsing single
characters.
Reconsidering the first implementation as a poor choice, rather specify the
format of X-Osmo-IGN as any-length string tokens separated by spaces, which is
more flexible and more future proof.
See also osmo-gsm-manuals If15a88c3b5b40fd1d24ad0f94f3231f678669ab1 which
defines the X-Osmo-IGN format as string tokens, matching this patch.
In mgcp_test, add an unknown X-Osmo-IGN item. Though the output is not checked
by the testsuite.at, running manually shows the error log about the unkown
X-Osmo-IGN item.
Change-Id: Ia6fe5ead4b601931c1bf41b29fc1b237aac37d2c
Add VTY commands "show mgcp endpoint NAME" and
"show mgcp trunk <0-64> endpoint NAME" which
show information about specific endpoints.
Change-Id: I5330e697ec34bf215de91d44209048a8dc226d51
Related: OS#2660
The format is
CRCX ...
C: ...
M: ...
X-Osmo-IGN: C
So far the only ignorable element is C, i.e. the CallID. Any other items may be
added in the future.
(I initially intended to also add '@' to ignore the endpoint name's domain
part, but in the osmo-mgw code base the domain part is verified long before any
additional headers are even parsed, so sparing that refactoring for now.)
The intention is that osmo-bsc will issue "X-Osmo-IGN: C" for all SCCPlite
calls, because we are unable to retrieve the CallID that the MSC sends to
osmo-mgw for the network side of the endpoint.
Testing with a specific SCCPlite MSC, I actually observe that all CallIDs are
1, even for concurrent calls. So, an alternative hacky solution would have been
to always pass CallID == 1 for SCCPlite connections from osmo-bsc.
Related: I257ad574d8060fef19afce9798bd8a5a7f8c99fe (osmo-bsc)
Change-Id: Id7ae275ffde8ea9389270cfe3db087ee8db00b51
Both make_crcx_msg_bind() and make_crcx_msg_bind_connect() were mostly
identical. Rather, compose the CRCX bits in one common function and just add
the audio bits in another.
Prepares cosmetically for adding X-Osmo-IGN header.
Change-Id: Ie51cc86e90ffeca5b66bcb8f6db0d389241abe57
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 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
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
Provide a sane means of adding the -Werror compiler flag.
Currently, some of our jenkins.sh add -Werror by passing 'CFLAGS="-Werror"',
but that actually *overwrites* all the other CFLAGS we might want to have set.
Maintain these exceptions from -Werror:
a) deprecation (allow upstream to mark deprecation without breaking builds);
b) "#warning" pragmas (allow to remind ourselves of errors without breaking
builds)
As a last configure step before generating the output files, print the complete
CFLAGS and CPPFLAGS by means of AC_MSG_RESULT.
Change-Id: Ia66aa48e957f4dcbdf8a7df3010b84f472c33f76
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
To show how the current code fails, add test_sdp_section_start() to
mgcp_client_test.c, and temporarily accept failing output. This will be fixed
in change I62a2453cd9e2e7d5408423161fa65ec9c9989f98.
Change-Id: I5c6d3566b8f6dbf04c0cd8b127423f5295c19f8d
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
MGCP_ENDPOINT_MAXLEN is currently only defined for the mgcp client,
since this is in general a common parameter it should be moved to
mgcp_common.h so that both sides can use it.
Change-Id: I9e1c52aa5ebd83b2d9e5178ea24cb27d96cb7ddd
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
The MGCP client uses hex numbers, while the server side parses it
as decimal. This results in the first 10 calls succeeding, but from
0x0a onwards it of course fails :/
Change-Id: I006f5f5325f0a5069d02fec8912a38d943cfc552
Closes: OS#2784
When a connection is created in loopback mode all incoming
packets should be reflected back to their origin. If the
user did not supply a destination address with the CRCX
command all incoming packets will be tossed because no
destination address is officially known yet.
If there is no destination address set and the connection
is in loopback mode. Then use the originating address of
the incoming packet as destination address.
Change-Id: I3d1abe56d016e28c97f60635eb574679d36e2c52
mgcp_msg_gen() does not check the contents of the prameters that
are handed over with the struct. This may lead to invalid mgcp
messages sent to the MGW, which can be difficult to debug.
Add some additional checks to make a possible problem
noticeable in an early stage.
- verify that the endpoint is not a nullstring
- verify that the connection id is not a nullstring
- verify that the ip-address is not a nullstring
- verify that the port number is a value greater 0
Change-Id: I15c464c4bcdf6e524f68acc62f44186dd7ad19a7
The returncode of get_conn_id_from_response() is unchecked, which
is intentional since some of the test messages will intentionally cause
this function to fail (the response does not inclde a connection
identifier). This means it makes no sense to assert this function
to a fixed value.
In order to spot regressions better print a log message depending
on the return code.
Change-Id: I9bce9ca39b7751b557374b7ab57c6c9005bcdb7d
Fixes: Coverity CID#180534
The CRCX string parameter lacks the quotes and the result of
the function call is not checked against zero. Also the
return code of get_conn_id_from_response() is not asserted.
Fixes: Coverity CID#180534
Change-Id: If4f3ed2c3572da196160569a9705b7a302b700a9
the assertions in the code that handles the connection
lists introduce a lot of unnecessary bloat.
Change-Id: I7badc729e97b76701abbce6a73a1ad1e46d3fee0
The test that tests the cancelation of a pending mgcp message
uses an integer as connection identifier, which leads to a
segfault since connection identifiers are represented as strings.
Use a string as connection identifier.
Change-Id: I395a23c1828cf216031d69d481ad35dd458ee7d4
So far, if an MGCP message is sent, the transaction gets enqueued, but there is
no way to end the transaction other than receiving a valid reply. So, if the
caller decides that the transaction timed out and tears down the priv pointer
passed to mgcp_client_tx, and if then a late reply arrives, the callback will
dereference the invalid priv pointer and cause a segfault. Hence it is possible
to crash an mgcp_client program by sending a late response.
Furthermore, if no reply ever arrives, we would keep the pending response in
the list forever, amounting to a "memory leak".
Add mgcp_client_cancel() to discard a pending transaction. The caller can now
decide to discard a pending response when it sees fit (e.g. the caller's
timeout expired). This needs to be added to OsmoMSC and OsmoBSC.
Add mgcp_msg_trans_id() to provide an obvious way to obtain the transaction id
from a generated MGCP message.
No public API is broken; but refine the negative return code from
mgcp_client_rx(): return -ENOENT if no such transaction ID is found, and still
-1 if decoding failed. This is mainly for mgcp_client_test.
Implement a test for mgcp_client_cancel() in mgcp_client_test.c.
Tweak internal mgcp_client_response_pending_get() to take only the transaction
id as argument instead of the entire mgcp message struct.
Found-by: dexter
Related: OS#2695 OS#2696
Change-Id: I16811e168a46a82a05943252a737b3434143f4bd
OsmoMSC is in the odd situation that it is already using the new
libosmo-mgcp-client, which is targeted at osmo-mgw, to configure talking to the
old osmo-bsc_mgcp. By removing the bts_base, we break current OsmoMSC.
Removing bts_base makes sense, but let's revert this until OsmoMSC is ready
after merging Ieea9630358b3963261fa1993cf1f3b563ff23538 (which moves the
osmo-msc over to osmo-mgw).
This reverts commit 0be3ce66c0.
Change-Id: Ibce214c2bfc35623097abbb647619426ef3dcc94
The log prints the endpoint numbers as hexadecimal numbers, but
it does not prefix them with "0x".
Add "0x" prefixes to all endpoint number outputs in the log
Change-Id: I284627de02cd140a894445375e9152ff007a71e6
The MGCP connection identifier is allocated by the MGW while processing
the CRCX, see RFC3435 2.1.3.2:. Including/Accepting a connection
identifier in CRCX is "forbidden" as per RFC3435 Section 3.2.2.
So the MGW side must *reject* a CRCX message with 'I' parameter, and
allocate a connection identifier which is subsequently returned in the
response.
Closes: OS#2648
Change-Id: Iab6a6038e7610c62f34e642cd49c93d11151252c
The MGCP spec in RFC3435 is quite clear: Connection Identifiers are
hexadecimal strings of up to 32 characters. We should not print and
parse them as integers on either client or server.
Change the internal uint32_t representation of connection identifiers
to a string representation in the client and also in the server.
Closes: OS#2649
Change-Id: I0531a1b670d00cec50078423a2868207135b2436
There should not be any BTS base port to be configured at an MGCP client.
Possibly this is related to the legacy behavior of libosmo-legacy-mgcp, and
certainly has no place in libosmo-mgcp-client.
Further changes may be needed to follow up on removal of the BTS base port
concept, at least drop it from the VTY for now.
Change-Id: I36e46208d7b75611e5ade3c74d8e1c25870de511
The variable number_endpoints is used as a length indicator
for the array that contains the trunk endpoints at all times.
When osmo-mgw is startet up, the variable is set and osmo-mgw
will allocate the memory for the endpoints. However, it is
still possible to manipulate the variable via the telnet
interface. When the value is increased osmo-mgw might start
using unallocated memory at some point.
Store subsequent changes of number_enspoints in a separate
variable in order to write them to the config file. The
changes will then take effect after a restart.
Closes: OS#2632
Change-Id: I3994af016fb96427263edbba05f560743f85fdd4
mgcp_parse_config() uses a helper function allocate_trunk() to
perform the trunk allocation. This helper function only calls
mgcp_endpoints_allocate() and checks the return code.
Call mgcp_endpoints_allocate() directly from mgcp_parse_config()
Change-Id: Iefdc5b905d76d2cd97f26584261fe5cbefb699cf
osmo-mgw currently uses VTY port number constant of osmo-bsc_mgwp,
however, libosmore now offers a constant specifically for osmo_mgw,
which has the same value, but is intended to be used by osmo-mgw
use the new port number constant for osmo-mgw
Closes: OS#2628
Change-Id: I63c3b300cc9287d1755a3f2c5b5ade7fc6398f6e
Depends: libosmocore I1770787e697906322ce5815fcaadba06c01ddee9
Ensure that all msgb were cleaned up, then free the overall msgb_ctx, in order
to not leave any memory leaks the sanitizer build complains about.
Change-Id: I53373023a6c3f490d6d6cb1c283db5dfb915882c
Ensure that all msgb were cleaned up, then free the overall msgb_ctx, in order
to not leave any memory leaks the sanitizer build complains about.
Change-Id: I84e0ac7f0928f04ffddd7da18200466841589c25
The copyright statement and contribution notices were copied 1:1
from OpenBSC, which is of course not correct for OsmoMGW.
Change-Id: I6143becdd0da589451efcbda530a78f655b7ce0b
sysmocom (specifically Philipp) was doing all the new osmo-mgw
development, but that is not yet reflected in the Copyright statement
for some reason. Let's fix it.
Change-Id: I4cad29daaabec1caec1bd09088414e59fa15a17e
mgcp_conn.c: In function ‘mgcp_conn_dump’:
mgcp_conn.c:248:30: warning: ‘/rtp, id:’ directive output may be truncated writing 9 bytes into a region of size between 0 and 255 [-Wformat-truncation=]
snprintf(str, sizeof(str), "(%s/rtp, id:%u, ip:%s, "
^~~~~~~~~~~~~~~~~~~~~~~~~
mgcp_conn.c:248:30: note: directive argument in the range [0, 65535]
mgcp_conn.c:248:30: note: directive argument in the range [0, 65535]
mgcp_conn.c:248:3: note: ‘snprintf’ output 32 or more bytes (assuming 295) into a destination of size 256
snprintf(str, sizeof(str), "(%s/rtp, id:%u, ip:%s, "
as mgcp_conn->name can already be up to 256 bytes, a total buffer size
of 256 is insufficient!
Change-Id: I5d48132b1358d19fe72e3901117737b09a42c69c
When the library version was bump, the dependency of osmo-mgw
was forgotten.
Change-Id: I3eeafa3c294d9ec71a72fb2833fe3b2bdef05a50
Fixes: e7d27aeae1 ("Tag/Release Version 1.2.0")
Parse the endpoint index from the MGCP messages as base-10, not 16.
If osmo-mgw parses the endpoint IDs as base-16 numbers while OsmoMSC and
OsmoBSC pass in decimal endpoint numbers, the consequence is, for example:
- I configure 32 endpoints in osmo-mgw,
- I tell OsmoBSC to use endpoint range 1-32,
- At some point OsmoBSC may pass in, say, "30@mgw",
- "30" is parsed base-16 and ends up being endpoint index 48, instead of 32,
- OsmoMGW sees that 48 > number_endpoints and barfs.
Related: OS#2633
Change-Id: Ic18608ff23303c1564548a86d5f6bfa539fe555e
There the prefix "net" is a leftover from the time when
there was a bts and a net side. Now we do not distinguish
anymore between the two.
remove prefix "net"
Change-Id: Id627e2ef6f725979ed52a585ca09686e1a049adf
Since currently osmux is not available we decided to lock down the
respective VTY command with an early return CMD_WARNING, making
the code after this line unreachable.
Guard the dead code with an ifdef
Fixes: Coverity CID#178648
Change-Id: I2ad9579453f52fe129cf120801a2efa19a26304e
in point_lookup() the connection pointer is determined using
mgcp_conn_get_rtp() this function may return 0. At the moment
there are no nullpointer checks implemented
Add checks to test for nullpointer.
Fixes: Coverity CID#178662
Change-Id: If9a3c1ac002bc8adc90ca1c1c3dd1db4feea07ac
The function that forwards the tapped (voice ebug) traffic returns
its status (sendto) to the caller. However, none of the callers
seem need this info.
Remove the return code and print an error message on failure
Fixes: Coverity CID#178666
Change-Id: I16c12c4565bccbc0d75c412b43469bf70b6b7ea5
When sending rtp packets sizeof(buf) is used as length. This causes
all RTP packets to be the size of the buffer (4096) containing the
rtp payload and random excess data from previoes memory usage
Use the actual length of the received RTP data, rather then the
full buffer size.
Change-Id: I47a15701f9a7e7a492df183b67ec971f5be61069
Fix errors like "remote bind address", mention 'MGW' instead of 'MGCP gateway',
minor typos and wording tweaks.
Change-Id: Ie1a408f9e651c5fb3424a84ceaaa603e20ad595c
Commit 87203f2a37 renamed some cmds to use
mgw instead of mgcpgw, and added deprecated alias for the old commands,
but forgot to add one for 'mgcpgw bts-base'. This commit fixes
backawards compatibility with old config files that mentioned commit
introduced.
Change-Id: Ib1c58945f4203b05d79f367afb3082b9a6a2c4e3
'mgcpgw' was a working title for the osmo-mgw. Before this takes hold out
there, let's rename the VTY commands to 'mgw'. I'd rather have some local
fallout in our testing environments now than drag the stupid name along.
Keep deprecated 'mgcpgw' commands for backwards compat.
Change-Id: I1d43d42929dc9162e57640499526fb7cadbcfbe6
Currently there are two ways to set the rtp bind ip-address (local
ip address where the rtp streams are bound to). It is possible to
set no set an rtp bind ip, if none no address is configured, then
the ip address where the mgcp service is bound to is used.
On a system with multiple network interfaces it is likely that
there are the remote end is not reachable through the interface
that has been configured. In this case rtp ip-probing can be
enabled via vty option in order to automatically detect the
ip address of the interface that points towards the remote end.
The autodetection can only work if the ip-address is known when
a CRCX is performed. For this the remote entity must include the
remote ip address in the sdp trailer.
Implement probing to determine te right local ip address
Add debug log to display which ip address is actually used
Add a VTY option for the probing functionality.
Change-Id: Ia57cf7dab8421fd3ab6e1515727db0080373485e
The way how osmo-mgw decides when to send a dummy packet and
when not is not very obvious.
use more explicit if statements, and define constants. Also add
comments that explain how it works.
Change-Id: Ie7ee9409baec50a09fb357d655b5253434fae924
the network (mgcp_network.c) part and the protocol part
(mgcp_protoocl.c) share a single loglevel DLMGCP. This
makes debuging hard because when debugging the protocol
we also get the log output from the RTP packets.
assign the network part a private loglevel and keep DLMGCP
for the directly MGCP related code
Change-Id: I55a2711798d1d1c2c9ef2f3b7ebb8fdd78bd6ea2
the functions rtp_calculate_port(), mgcp_timeslot_to_endpoint(),
mgcp_endpoint_to_timeslot() were a hack to map CIC addresses
to endpoints and ports. This is no longer needed.
Remove the affected functions.
Change-Id: I9ef14396dc9f97e570d9bcfb4d9b4a94e650ad46
In many cases it is simpler to instruct the mgcp-gw to drop all
connections at once instead of removing each connection
individually.
drop all connections and release the endpoint in when no connection
id is supplied with the DLCX command.
Change-Id: Ib5fcc72775bf72b489ff79ade36fb345d8d20736
currently the only way to generate MGCP messages is to use
mgcp_msg_crcx(), mgcp_msg_mdcx() and mgcp_msg_dlcx(). All
three function take a fixed set of parameters via their
parameter list. There is no way to add or leave away optional
parameters.
add function mgcp_msg_gen(), this function takes a unified
message struct. The struct features a presence bitmask which
allows to enable and disable parameters as needed. It is also
possible to add new parameters in the future without breaking
the API.
Depends: libosmocore I15e1af68616309555d0ed9ac5da027c9833d42e3
Change-Id: I29c5e2fb972896faeb771ba040f015592487fcbe
When testing the file name and the line numbers are output to
stderr, this causes the test to fail when change moves the
lines.
Disable line numbers in the stderror log when testing, also
disable timestamps and colors. Make sure the log category
is print.
Change-Id: I7f1bd9454188f0ca869dada1fcc2877b789cc0ac
move SDP generator function write_response_sdp() from mgcp_protocol.c
to mgcp_sdp.c and use msgb_printf() instead of snprintf()
move prototypes for mgcp_parse_sdp_data() and mgcp_set_audio_info()
to mgcp_sdp.h
change parameter list of mgcp_parse_sdp_data() so that it takes the
rtp conn directly, rather than struct mgcp_rtp_end.
add doxygen comments to all public functions
Change-Id: I9f88c93872ff913bc211f560b26901267f577324
vty_install_default() and install_default() will soon be deprecated.
Depends: I5021c64a787b63314e0f2f1cba0b8fc7bff4f09b
Change-Id: I246853156c4bd2a47690e580e647105eb838ca92
See osmo-ci change I2409b2928b4d7ebbd6c005097d4ad7337307dd93 for rationale.
Depends: I2409b2928b4d7ebbd6c005097d4ad7337307dd93
Change-Id: I5a64b305dff5387cbe2462b564051f807061086d
This marks the first release that includes the new libosmo-mgcp
as well as some updates to libosmo-mgcp-client. Hence, all programs
using those libraries can now depend on a proper minimum version
Change-Id: I1748ed230041930b4e9f49deb03341772ab02144
This fixes the following dpkg-shlibdeps warnings:
Change-Id: I648bbda50520808afcf2a6ce64fe710df918936c
dpkg-shlibdeps: warning: symbol install_element_ve used by debian/libosmo-legacy-mgcp0/usr/lib/x86_64-linux-gnu/libosmo-legacy-mgcp.so.0.0.0 found in none of the libraries
dpkg-shlibdeps: warning: symbol argv_concat used by debian/libosmo-legacy-mgcp0/usr/lib/x86_64-linux-gnu/libosmo-legacy-mgcp.so.0.0.0 found in none of the libraries
dpkg-shlibdeps: warning: symbol vty_out used by debian/libosmo-legacy-mgcp0/usr/lib/x86_64-linux-gnu/libosmo-legacy-mgcp.so.0.0.0 found in none of the libraries
dpkg-shlibdeps: warning: symbol vty_install_default used by debian/libosmo-legacy-mgcp0/usr/lib/x86_64-linux-gnu/libosmo-legacy-mgcp.so.0.0.0 found in none of the libraries
dpkg-shlibdeps: warning: symbol vty_read_config_file used by debian/libosmo-legacy-mgcp0/usr/lib/x86_64-linux-gnu/libosmo-legacy-mgcp.so.0.0.0 found in none of the libraries
dpkg-shlibdeps: warning: symbol install_element used by debian/libosmo-legacy-mgcp0/usr/lib/x86_64-linux-gnu/libosmo-legacy-mgcp.so.0.0.0 found in none of the libraries
dpkg-shlibdeps: warning: symbol install_node used by debian/libosmo-legacy-mgcp0/usr/lib/x86_64-linux-gnu/libosmo-legacy-mgcp.so.0.0.0 found in none of the libraries
This fixes the following dpkg-shlibdeps warning:
Change-Id: I1eb079aa74a56b75e881b7abae0e5d9b4d7ae9c4
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/osmo-bsc-mgcp/usr/bin/osmo-bsc_mgcp was not linked against libosmonetif.so.4 (it uses none of the library's symbols)
This fixes the following dpkg-shlibdeps warning:
Change-Id: If60583b2bec344fc674af6f129787206540bc9fc
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/libosmo-mgcp-client0/usr/lib/x86_64-linux-gnu/libosmo-mgcp-client.so.0.0.0 was not linked against libosmonetif.so.4 (it uses none of the library's symbols)
This addresses the following dpkg-shlibdeps warnings:
Change-Id: I737c36402b7b88634b56725f2caab4f5f971ac51
dpkg-shlibdeps: warning: symbol install_element used by debian/libosmo-mgcp-client0/usr/lib/x86_64-linux-gnu/libosmo-mgcp-client.so.0.0.0 found in none of the libraries
dpkg-shlibdeps: warning: symbol vty_out used by debian/libosmo-mgcp-client0/usr/lib/x86_64-linux-gnu/libosmo-mgcp-client.so.0.0.0 found in none of the libraries
This addresses the following dpkg-shlibdeps warnings:
Change-Id: I518eb5e19cef5f261711b034d28337265c69f443
dpkg-shlibdeps: warning: symbol install_element_ve used by debian/libosmo-mgcp0/usr/lib/x86_64-linux-gnu/libosmo-mgcp.so.0.0.0 found in none of the libraries
dpkg-shlibdeps: warning: symbol vty_read_config_file used by debian/libosmo-mgcp0/usr/lib/x86_64-linux-gnu/libosmo-mgcp.so.0.0.0 found in none of the libraries
dpkg-shlibdeps: warning: symbol vty_install_default used by debian/libosmo-mgcp0/usr/lib/x86_64-linux-gnu/libosmo-mgcp.so.0.0.0 found in none of the libraries
dpkg-shlibdeps: warning: symbol install_element used by debian/libosmo-mgcp0/usr/lib/x86_64-linux-gnu/libosmo-mgcp.so.0.0.0 found in none of the libraries
dpkg-shlibdeps: warning: symbol install_node used by debian/libosmo-mgcp0/usr/lib/x86_64-linux-gnu/libosmo-mgcp.so.0.0.0 found in none of the libraries
dpkg-shlibdeps: warning: symbol vty_out used by debian/libosmo-mgcp0/usr/lib/x86_64-linux-gnu/libosmo-mgcp.so.0.0.0 found in none of the libraries
dpkg-shlibdeps: warning: symbol argv_concat used by debian/libosmo-mgcp0/usr/lib/x86_64-linux-gnu/libosmo-mgcp.so.0.0.0 found in none of the libraries
Change-Id: Ic62efeb3c139016aa8a1e68651442edf2044eeef
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/osmo-mgw/usr/bin/osmo-mgw was not linked against libosmonetif.so.4 (it uses none of the library's symbols)
This is the safe choice, as in absence of automatic testing we don't
know if we actually still build against the [sometimes] ancient
dependencies.
Change-Id: I8118defcd270bb487d9fd674fe30a74d379fda18
mgcp.h includes mgcp_ep.h but does not use anything from it. This
does not hurt the mgcp code internally, but when mgcp.h is included
by an application compilation fails because mgcp_ep.h is not
installed.
remove mgcp_ep.h from include list in mgcp.h
add mgcp_ep.h to include list in mgcp_conn.c where it is needed.
Change-Id: Ib58a8ed64f729055282c2b9673f7684cdfdb5936
The sendto() override in mgcp_test sends rtp packets out. This
might be a problem for some test hosts. e.g. on OBS, sending packets
fails with an error message, which exits sendto() early and hence fails
to send the expected amount of "Dummy Packets". Interestingly enough
calling the real sendto is not necessary to run the test at all.
Remove the execution of the real_sendto and just return len.
Related: OS#2561
Change-Id: Ia8fa0770f9bc75725cc6b0cd445e753f7e029ca5
I thought the BUILT_SOURCES also enters the files to CLEANFILES, but 'make
clean' leaves the copied header behind for me. Add to CLEANFILES to get it
removed.
Change-Id: I5a56f83289e32a09643047f0e779c9de3e4b39a6
Remove mgcp_common.c and replace with mgcp_common.h.
Move mgcp_common.h from mgcp_client/ to mgcp/;
Place a compile-time copy of it back in mgcp_client/.
Add builddir/include to compiler -I paths to find generated header.
Rationale:
- Keep separate copies of the file for each of the library to not require
debian dependencies between the two libraries.
- Avoid code dup by copying during 'make' (think: a generated header, BUILT_SOURCE).
- The copy does not have implications for linking (like mgcp_common.c did) nor
is it a source for build confusion or fallout in other projects, because it
does not reach across several git source trees (like gsm_data_shared.h did).
mgcp_connection_mode_strs are not actually used in libosmo-mgcp, so drop them.
(It would make semantic sense to have then in mgcp, but we can add it when it
is needed. A similar value string array remains in libosmo-mgcp-client.)
Change-Id: I7a5d3b9a2eb90be7e34b95efa529429f2e6c3ed8
Leave the old osmo-bsc_mgcp and libosmo-legacy-mgcp as it is; on a copy thereof
(added by a previous commit), apply changes to initially implement the new
osmo-mgw.
Adjust build system and debian packaging to accomodate the new libosmo-mgcp and
osmo-mgw.
The main differences:
*) use a list to manage rtp connections.
Aggregate all rtp related information inside a single struct.
Use a linked list to manage the both connections (net and bts).
The idea behind using a list is that we might support conference
calls at some later point.
Store the linked list in struct mgcp_endpoint, have a private linked
list for each endpoint. The list contains connection items which are
implemented in struct mgcp_conn. A connection is allocated and freed
using the functions in mgcp_conn.c. A connection is allocated on the
reception of a CRCX command and freed with the reception of a DLCX
command.
*) remove external transcoder feature
Fortunatelly the external transcoder feature is not needed
anymore. This patch removes the related code.
*) vty: get rid of CONN_BTS and CONN_NET
Since the new connection model does not make a difference
between BTS and NET connections the VTY should not use
the fixed CONN_BTS and CONN_NET constants.
- Handle the conns list inside the endpoint directly
- introduce function to dump basic rtp connection info
- introduce human readable names for connections
Parts of the code adjusted to use generalized connections instead of explicit
BTS/NET ones:
- teach mgcp_send_dummy() to send dummy packets to any RTP connection
- network: generalize mgcp_bind_net/bts_rtp_port()
- network: generalize mgcp_send()
- tap: generalize call tapping feature
- stat: generalize statistics
- Replace rtp_data_net() and rtp_data_bts() with generalized rtp_data_rx()
*) mgcp_protocol.c fixes:
- check ci string before it is converted:
In case of missing ci, a nullpointer is delivered to strtoul().
Add a function that takes ci, checks it and converts it to an
uint32_t. Use the return code to react on missing ci.
- output error message on missing CI.
- when parsing the mode, print log message when mode is missing.
- use mode_orig when mode is missing.
- fix ptime formatstring to use %u rather than %d.
- cosmetic: log when connection is deleted on DLCX.
- change loglevels of CRCX, MDCX, DLCX events from DEBUG to NOTICE.
*) mgcp_test
- apply rename of strline_r() to mgcp_strline().
- MGCP command macros:
- Add 'I: 1' parameters.
- Use proper port numbers:
from m=audio 0 RTP/AVP 126
to m=audio 16002 RTP/AVP 128
- Change ptime to 'a=ptime:40' because this is what the MGW currently
returns. CRCX generally feed a ptime:40 and this is expected to be
returned.
- struct mgcp_test: Use only one ptype, there are no explicit BTS and NET
endpoints anymore.
Hence remove one column from tests[].
- test_messages():
- Enable: remove '#if 0'
- Remove concept of BTS and NET endpoints: test only one conn, as they are
now interchangeable anyway.
- remove endpoint init, now done internally.
- add false asserts in error cases.
- test_retransmission():
- remove endpoint init, now done internally.
- add false asserts in error cases.
- test_packet_error_detection():
- Remove concept of BTS and NET endpoints: test only one conn, as they are
now interchangeable anyway. Use arbitrary conn ids (e.g. 4711).
- remove endpoint init, now done internally.
- add false assert in error case.
- Assert that a conn really vanishes on DLCX, previously the conn would
remain and just be unused, now it is actually discarded.
- test_no_cycle()
- Remove concept of BTS and NET endpoints: test only one conn, as they are
now interchangeable anyway. Use arbitrary conn ids (e.g. 4711).
- test_no_name()
- Enable: remove '#if 0'.
- remove endpoint init, now done internally.
- add false assert in error case.
- mgcp_test.ok: adjust expected results to status quo:
- We now see two dummy packets instead of one, now sent to both sides because
we don't know of BTS or NET side. (maybe drop dummy packets later...)
- packet duration, conn mode: now sane defaults show instead of unset.
- various whitespace and formatting changes from lindent.
Change-Id: Ie008599136c7ed8a0dfbb0cf803188975a499fc5
This a cosmetic commit, copying libosmo-legacy-mgcp to libosmo-mgcp and
osmo-bsc_mgcp to osmo-mgw 1:1 at first, to provide a basis for next patches
that highlight the changes from legacy to new code.
Until osmo-msc and osmo-bsc are adjusted to operate with the new code, we will
keep the legacy code alongside the new code. The legacy code might be dropped
later.
Change-Id: Idf54481754a1765bdb2d0d7033bc0d7dc2018024
libosmo-legacy-mgcp was not linked against libgsm
when built with --enable-mgcp-transcoding.
When afterwards a binary such as osmo-bsc is built and
tries to link against it, it will fail with an error
like the one below:
/home/pespin/dev/sysmocom/bin/../build/new/out/lib/libosmo-legacy-mgcp.so: undefined reference to `gsm_create'
Tested that building with this patch fixes the issue.
Also tested that it still builds fine without --enable-mgcp-transcoding.
Change-Id: I5ed356ac0c8f476e263fc6dcc5613d594890dfcd
With the upcoming addition of libosmo-mgcp, when we try the same scheme
of wildcards there, it would also include all of the other libraries:
*mgcp*.so.*
There we will have to clarify that we mean exactly:
libosmo-mgcp.so.*
This is a cosmetic change to also be less ambiguous for the current libs:
I prefer to state exactly which parts of the file names may vary, so that
we have a firmer understanding of what is being installed.
Change-Id: I6a3f3b9efa08eb9c5cdca3e02f8fab4a96c28ad5
Add mgcp_common.h to libosmo-mgcp-client, to not need to share a header file
with libosmo-legacy-mgcp (nor the upcoming libosmo-mgcp). Both libraries use
the enum mgcp_connection_mode (and a for-loop macro and a string mangling
function), so far declared in mgcp.h, and both mgcp-dev and mgcp-client-dev
debian packages would require this header file to be installed. So far the
mgcp-client-dev lacks this header file, which causes the osmo-msc debian
package to fail building. Ways to solve:
- If both -dev debian packages installed the same header file in the same
place, they would conflict if ever installed at the same time.
- mgcp-client-dev can depend on mgcp-dev, but it seems bad to keep such a large
dependency for just one enum and two helpers.
- Instead, this patch solves this by copying the few definitions to
libosmo-mgcp-client.
Once libosmo-mgcp-client has its own copy of those definitions, it is
fully self-contained and depending builds (osmo-msc deb) will succeed.
Copy the few actually common definitions to new header
<osmocom/mgcp_client/mgcp_common.h>. The nature of this .h is that it may be
shared with future libosmo-mgcp without causing linking problems.
Remove libosmo-legacy-mgcp/mgcp_common.c file from the build of
libosmo-mgcp-client, no longer needed.
Add to new mgcp_common.h:
- enum mgcp_connection_mode;
- for_each_non_empty_line() macro.
- mgcp_msg_terminate_nul() as static function. Its complexity is just above
your average static inline, but being inline is a way to use it in both mgcp
and mgcp_client without linking problems.
Replace for_each_line() use in mgcp_client with for_each_non_empty_line()
(for_each_non_empty_line() replaces for_each_line() and uses strtok_r() instead
of a local reinvention).
mgcp_connection_mode_strs are actually only used in libosmo-mgcp-client, so
rename to mgcp_client_ prefix and move to mgcp_client.c.
BTW, the future plan for upcoming libosmo-mgcp is to use the identical header
file, and keep only one copy in the git source tree. The second copy may be
generated during 'make', to avoid code dup while having two distinct headers.
Related: I8e3359bedf973077c0a038aa04f5371a00c48fa0 (fix osmo-msc after this),
I7a5d3b9a2eb90be7e34b95efa529429f2e6c3ed8 (mgcp_common.h)
Change-Id: Ifb8f3fc2b399662a9dbba174e942352a1a21df3f
Roll back the LIBVERSIONs to 0:0:0 -- the bumps so far have been confused and
wrong. Let's start over from scratch with API-current of 0 while we still can.
Rename the mgcp_client debian .install files back to 0 to match the API
version.
Change-Id: I3d81853f811f412b186621c3657bab6af397a980
Let's track the API/ABI changes in libosmo*mgcp the same way we do it in
other libosmo* libraries.
Change-Id: Id0b8d55ea58bdb3d72b4c131ac983d8895b55ef8
Use one space to indent mgcp.cfg, like all the other osmo*.cfg examples.
Tweak the header comment.
Remove the password and line vty commands.
Change-Id: I52e481dbf4778dd187ce6b67d879a04ef61e8b47
The name "mgcpgw_client" referred to an MGCP gateway, which is rather an MGW
(Media Gateway). But this client code is more generally a client for the MGCP
protocol, independently from what the server program is called.
Rename the files as well as the function prefixes to drop the "gw". It is
purely cosmetic and not strictly necessary, but a good point in time for fixes
like this.
osmo-msc build will be adjusted by I093ad02ca0e532f659447c785e09678b3e6f220d.
osmo-bsc build will be adjusted by I6402c7cbe58dacae7630f7f03819f8102e54c699.
These should be applied right after this here is merged to avoid fallout.
Change-Id: I99f7faab637cfcc22ece64a1dbcbe590f2042187
When osmo-mgw is built --with-mgcp-transcoding, linking the mgcp library
also requires linking libgsm, even though e.g. osmo-msc never use it.
Separate the MGCP client code from the MGCP server code to avoid this dep.
The mgcp client code does use some definitions from mgcp.h and mgcp_common.c.
For simplicity, link mgcp_common.c in both libosmo-legacy-mgcp as well as
libosmo-mgcp-client. That means it is not possible to link both
libosmo-legacy-mgcp and libosmo-mgcp-client in the same binary because of
duplicate symbols, but currently that is sufficient. (An alternative would be
code dup or yet another libosmo-mgcp-common library.)
Add libosmo-mgcp-client to debian packaging.
Related: OS#2488
Change-Id: I8e0b2d2a399b77086a36606f5e427271c6242df1
These either remain from openbsc.git or slipped in while applying recent
patches from openbsc.git and do not belong in osmo-mgw.
The ctrl_test_runner.py from openbsc.git still sticks around, but osmo-bsc_mgcp
has no CTRL interface (yet). If it gets one, we can re-add the
ctrl_test_runner.
Change-Id: I623ba8c053bef91a327e58de214e05f0d6768605
When a duplicate command is sent, the MGCP-GW will interpret this
as a retramsmission and will send the response of the already
executed command again. This response is not printed in the log.
Make sure that also responses, which are retrsnamitted are
displayed in the log
Change-Id: Ic41c2defb521e2f81762d932f8e29f7c8fed06a9
Add vty and logging previously used from libcommon
Rename libmgcp to libosmo-legacy-mgcp and install.
Use DLMGCP, not DMGCP.
Slim down the public mgcpgw_client API, move all elements not actually used by
current callers to private headers / static c.
Depends: libosmocore I09c587e2d59472cbde852d467d457254746d9e67
Change-Id: I71a0a16ebaaef881c34235849601fc40aa12cfd7
Remove libiu here, use the functions from libosmo-ranap instead, by applying
the ranap_ / RANAP_ prefix.
Corresponding change-id in osmo-iuh.git is I6a3f7ad15be03fb94689b4af6ccfa828c25f45c0
To be able to run the msc_vlr tests for RAN_UTRAN_IU without Iu client headers
available, add iu_dummy.h, containing mere function signatures that match
iu_dummy.c and a mostly empty struct ranap_ue_conn_ctx.
Make sure we can build with and without --enable-iu: include osmo-iuh headers
only with --enable-iu.
Change-Id: Ib8c4fcdb4766c5e575618b95ce16dce51063206b
In SGSN, actually place the port in the SGSN config by default, so that the
gsup port may now be omitted in the VTY config (the IP address suffices).
Adjust the osmo-sgsn.cfg example.
Depends: I4222e21686c823985be8ff1f16b1182be8ad6175 (libosmocore)
Change-Id: I50f2040e2eb0baacb43849e93cfed10cbc2fc156
Currently the force_realloc feature is turnd on and of in a
hardcoded way. This patch makes the option available via VTY.
Change-Id: Ic8740512c5ea0766ff6ceb1c28b9c2b3fe46e75f
This was originally a long series of commits converging to the final result
seen in this patch. It does not make much sense to review the smaller steps'
trial and error, we need to review this entire change as a whole.
Implement AoIP in osmo-msc and osmo-bsc.
Change over to the new libosmo-sigtran API with support for proper
SCCP/M3UA/SCTP stacking, as mandated by 3GPP specifications for the IuCS and
IuPS interfaces.
From here on, a separate osmo-stp process is required for SCCP routing between
OsmoBSC / OsmoHNBGW <-> OsmoMSC / OsmoSGSN
jenkins.sh: build from libosmo-sccp and osmo-iuh master branches now for new
M3UA SIGTRAN.
Patch-by: pmaier, nhofmeyr, laforge
Change-Id: I5ae4e05ee7c57cad341ea5e86af37c1f6b0ffa77
When somebody kills the process, it's best to handle the signal
and to use the opportunity for some cleanup. We always did this
in the NITB on SIGINT, but never on SIGTERM. Let's change it.
Change-Id: Iea6804325a6575ceab5edfd28dd20249462f143b
This option was present in very early versions of the NITB, but
at least since 2011 it is no longer supported. It's still listed
in --help output, which is wrong.
Change-Id: I1d2cceb588ec5fb34ec5e2c05a7d8c93310bee88
Set the time on the status report to the time the message was delivered, as
this may not be the same as the time when we are delivering the report to the
originating MS.
Change-Id: I9056429d40bf02731f004b7833f1de45a0d1add8
libsmpp34 already converts received TLV integer values to native
endianess in libsmpp34_(un)pack.
Converting them again at receive time swaps the 2 bytes of
user_message_reference, then using a wrong value. As GSM03.40 spec
uses only 1 byte for the id, then only the high byte of the initial
value is used and eventually sent back to the ESME. Again, at that time,
htons() is not needed because libsmpp34 already handles that part.
See OS-#2429 for more details.
Change-Id: If748548a4a223e529a1110c89e483b599b406e8b
I already stumbled into 2 compilation environments which had Werror
enabled for -Wmaybe-uninitialized and the build failed, so let's
workaround this warning.
| smpp_openbsc.c: In function 'handle_smpp_submit':
| smpp_openbsc.c:216:9: error: 'sms_msg_len' may be used uninitialized in this function [-Werror=maybe-uninitialized]
| memcpy(sms->user_data, sms_msg, sms_msg_len);
| ^
| smpp_openbsc.c💯15: note: 'sms_msg_len' was declared here
| unsigned int sms_msg_len;
| ^
| cc1: some warnings being treated as errors
Change-Id: I0901ddadb5f72e1585cb1797ac22c8ab95e83146
Commit 058cd573d8 added 2 new pointer parameters to
gprs_subscr_request_auth_info, but forgot to update wraps of the
function in sgsn_test.
I catched this today because openbsc build test sgsn_test was failing.
Closed look up to the logs showed:
Assert failed (auts != NULL) == (auts_rand != NULL) openbsc/openbsc/src/gprs/gprs_subscriber.c:791
Change-Id: Ie9e4af6da0339536fb20ca0b7bbcf6f485bd522c
gsm_04_11.c sms_report_alloc()
Use the sms->text, not the sms->user_data to construct the report body.
This also prevents the potential output of non printable characters to
the log and or vty.
Change-Id: Id51bc9483ad6f52d6da74135605cfd12434c7c96
gsm_04_11.c: gsm340_gen_sms_status_report_tpdu()
When we construct the status report PDU, use sms->src
instead of sms->dst as the destination address
This way we tell the MS that the message was delivered
to the destination and not to itself.
This is relevant for phones that display a textual
representation of the delivery report.
Change-Id: I2d4f87ac777465de9bfb5a775a789a2691755ee9
Use new definitions in libsmpp34 to set the registered_delivery field
accordingly, as provided by I5b3afff1b3b77cccd949e0606914c7ac3ba6114c.
Moreover, do not set this header field to zero if status reports are
off, the deliver_t structure has been already zeroed so this not
required.
Change-Id: Ie78e17323796120f576b9c0e1bc5ccc32da8ee12
In 2015, Jacob moved/copied related functions to libosmocore, but
for some reason didn't remove the copies here. Let's follow-up on
that and remove duplicated code.
The libosmocore commit introducing osmo_apn_to_str() was
8114294bf29ac6e44822c0ae43d4b0819f11b022
Change-Id: I7315ffcbed8a54cca2056f313bb7783ad82d0ee9
We can only print libgtp pdp information if a library context is
attached to this pdp context. This is not always the case,
particuarly during some teardown scenarios.
Change-Id: Ia3184877f9709db65f5f93a98403f2ef5b04a8ca
When converting from GSM_PCHAN_PDCH, we should generate
a RSL channel number IE with the osmocom extension
RSL_CHAN_OSMO_PDCH rather than claiming it is a regular
TCH/F channel.
This is important as this function is used by
osmo-bts, too - and it decides which channel number IE is
put in the GSMTAP header for both GSMTAP tracing as well
as the GSMTAP based osmo-bts-virtual.
In order to avoid any unintended effect on libbsc,
we make sure to modify rsl_ipacc_pdch_activate() to
always use GSM_PCHAN_TCH_F in related RSL message.
Change-Id: Ie34219e64a6d89da4a79f2db8ec73d1909fb8280
In the PDP Context Create from SGSN to GGSN, we include information
about the RAN type (GERAN/UTRAN) and the Cell of the MS. This was
all hard-coded to GERAN, and wasn't updated when we added UTRAN
support to the SGSN.
Change-Id: I6c79e42c5e08b28fe8182555302a5505fbbaa313
Commit 5754206379 introduced
OSMUX_STATE_NEGOTIATING to fix a race condition present in osmo-bsc_nat.
However, after this change osmo-bsc_mgcp cannot switch to
OSMUX_STATE_ACTIVATING anymore, which means during osmux_send_dummy time
it won't call osmux_enable_endpoint(), which in turn won't set endp type
to MGCP_OSMUX_BSC.
If MGCP_OSMUX_BSC is not set, uplink streams are sent using regular RTP
instead of Osmux not matter it is enabled in config or not.
Change-Id: Ibcb59aa1ca25408f82cc88c2d5b81177b5f276dc
In case of successful completion of handover gsm_subscriber_connection could be moved from one bts to another,
so connection link to bts should be replaced by link to bts, which owns new_lchan.
This bug was detected, because conn->bts->nr is used in call control log messages
and wrong number of bts was observed in these messages after handover.
Change-Id: Idc7dd412b7580c451e716b73ef7549826c60b0d9
Fixes regression probably introduced in c696cc28.
For bts>0 logging doesn't show bts number correctly when printing lchan
identification string - it will always show it as "bts=0". The reason for
this is that the identification string is cached before bts->nr value is
set to a proper value.
This patch sets bts->nr as part of the first step of the bts structure
initialization, before caching happens thus making sure the cached
identification string is cached with the correct values.
Change-Id: I61c18a7f021fcb1ec00d34a745f4e3ab03416c2d
Replace magic numbers by esm_class definitions, which
have been added to latest libsmpp34 in Change-Id
I91afd8b462b8fd3b2c4c5b54f4eeb7ec5b730b65
Change-Id: I6c458690da60c8f3637680efbd718f6e8c6feb4c
submit_to_sms() now handles two TLVs, so find_tlv() is suboptiomal and
it can be removed, since it would result in two passes on the TLV list.
Use new smpp34_tlv_for_each() helper to iterate over the list of TLVs
that is available since I446929feed049d0411e1629ca263e2bc41f714cc.
Change-Id: I53a65164a6cc4abc6bf57d9a8dc275cf21c90222
The change-id I7276d356d805a83ebeec72b02c8563b7135ea0b6 added msg_ref to
the databse but forgot to remove the comment stating it's not being
stored.
Change-Id: I204f098c8f2a480405446113e2181b2c53700cf3
gsm340_gen_oa() returns a negative value if the output buffer that the
caller passes is too small, so we have to check the return value of this
function.
Fixes: CID 174178
Fixes: CID 174179
Change-Id: I47215d7d89771730a7f84efa8aeeb187a0911fdb
This patch adds gsm340_sms_send_status_report_tpdu() to build a
status-report. Moreover, set sms->report field if we see a SMPP
SUBMIT_SM with Delivery Acknowledgment esm_class, so this identifies
that this is a delivery report.
MS GSM 03.40 SMSC SMPP 3.4 ESME
| | |
| | SUBMIT-SM |
| | esm_class = Delivery Ack |
| |<-------------------------------|
| | SUBMIT-SM-RESP |
| |------------------------------->|
| | |
| SMS-STATUS-REPORT | |
|<----------------------------| |
| GSM 04.11 RP-ACK | |
|---------------------------->| |
| | |
There is a FIXME message in this patch, that I just copied from
gsm340_gen_sms_deliver_tpdu() since TP-MMS is not supported by OpenBSC.
Change-Id: Ib70e534840308ed315f7add440351e649de3f907
Simple patch to test the new status-report support code, remove previous
code before Delivery Acknowledgement support was in place. Use
LOGL_DEBUG for logging messages here as suggested by Neels and Harald.
Change-Id: I877e228d8e174430f700631edbf9955972da7892
SMPP DELIVER_SM messages with esm_class = Delivery Receipt need to send
this message reference (that the mobile phone allocates) to the ESME.
Thus, the ESME propagates it via SUBMIT_SM with esm_class = Delivery
Acknoledgment so that the SMSC sends the GSM 03.40 status-report to the
origin including this. Given this field is useful for status-reports, we
need to store it in the HLR database.
Moreover, we need a new field that specifies if the entry represents a
SMS status-report, to do the right handling from the gsm411_send_sms() -
such new handling comes in a follow up patch entitled "libmsc: handle
delivery ack via SMPP SUBMIT SM / send GSM 03.40 status report".
This patch includes the migration routines to the new database schema
revision 5, it's quite a bit of dbi boilerplate code - copied-pasted and
adapted.
Change-Id: I7276d356d805a83ebeec72b02c8563b7135ea0b6
If the mobile phone requests a status report via SMS, send a DELIVER_SM
with esm_class = Delivery Receipt to ESME to indicate that the SMS has
been already delivered to its destination.
MS GSM 03.40 SMSC SMPP 3.4 ESME
| | |
| SMS-DELIVER | |
|<----------------------------| |
| GSM 04.11 RP-ACK | |
|---------------------------->| |
| | DELIVER-SM |
| | esm_class = Delivery Receipt |
| |------------------------------->|
| | DELIVER-SM-RESP |
| |<-------------------------------|
| | |
This patch implements "Appendix B. Delivery Receipt Format" as specified
in the SMPP 3.4 specs. This string is conveyed in the SMS message as
data, and it is only meaningful to the ESME, for logging purposes. The
"submit date" and "done date" are not yet set, and other fields are just
sent with dummy values, so they are left to be finished as future work.
The new SMPP TLV tag TLVID_user_message_reference is added to the SMPP
messages inconditionally now since this information is required by
delivery-reports to associate the status-report with the original SMS.
Change-Id: Ic1a9023074bfa938099377980b6aff9b262fab2a
Just munch and log SMPP delivery receipts by now, don't mirror this, it
is going to break things in openbsc.
Follow up patch removes this and mirrors this SMPP message as a
SUBMIT_SM with esm_class = Delivery Acknowledgement.
Change-Id: I78e93bc4034679e238c8642ccf6a0e844b1d6d8b
Propagate the status report request field to the SMPP message through
the registered_delivery field, so the ESME knows that the mobile phone
is asking for explicit delivery acknowledgment is required. See SMPP 3.4
specs section 5.2.17.
Change-Id: I59af60fa89cd10ae973c5e122789e3e03e3728ee
Rationale: allows seeing all timer defaults at once by doing
OsmoBSC(config-net)# timer ?
Before, defaults are visible only by doing on each timer:
OsmoBSC(config-net)# timer t1234 <tab>
Change-Id: I8259234e5c62e058dde56d531071440bbab11462
The VTY parsing already ensures the parameter range being 1..65535, no need to
check the range again.
Change-Id: I1cffa5b01cd5c589f1e42998e32135f1da8c960b
Move the sms message-type-identifier (mti) handling away from the
routing logic. This patch allows us to reuse the sms_route_mt_sms()
function in a follow up patch for sms reports send through SMPP
DELIVER_SM with esm_class = Delivery Receipt whose Change-Id is
Ic1a9023074bfa938099377980b6aff9b262fab2a.
Change-Id: I3f3d30e0762b91e2099243b0be1a4b67cbb5e9c0
No need to cache the sms object, just cache what we need into the
smpp_cmd structure. This simplifies what that I introduced in
93ffbd0029 ("libmsc: send RP-ACK to MS after ESME sends SMPP
DELIVER-SM-RESP").
Change-Id: Iba5f864f9bb963baff95969e306b1b7cff00c1e3
The following branch:
if (!rc && !gsms->receiver)
rc = GSM411_RP_CAUSE_MO_NUM_UNASSIGNED;
at the end of sms_route_mt_sms() always evaluates false.
Just a bit before, in such function, we have this:
if (!gsms->receiver) {
...
#ifdef BUILD_SMPP
...
#else
...
#endif
return rc;
}
So, if there is no receiver, we just stop running code and return the RP
cause via the rc variable. Same applies to the smpp_first check under
the BUILD_SMPP ifdef (that I have removed in this snippet to keep this
commit message small).
Change-Id: Ic3502b5b169bc7a73a67fd6ff53d8b6c0dc045c8
libgtp is calling gtpie_tv2 which will convert this uint16_t from host
to network order. So far libosmogsm and the sgsn treated the charging
characteristics as opaque data. So when moving from byte array to the
uint16_t do the swapping.
Change-Id: I977aec2e2f8d57802e45f591754e5733562d5c2a
We no longer permit timers with a 0 value, so this case can never
happen. Also, if it should happen, I'd rather have a timter expiring
immediately (and breaking something) than not being started in the
first place.
Change-Id: Ibfcdd3ddc0155caee89c501498329bde247621a0
It typically doesn't make sense to configure any of the GSM RR timer
to 0 (Seconds). In fact, accidentially configuring any of the timers
to zero might have severe side effects, such as "stuck channels"
described in https://osmocom.org/issues/2380
Change-Id: I517828f2f0c80ec01cb63648db2626f17a67fe57
A number of the GSM timers (including T3109) had no reasonable
default values if not specified in the VTY / config file. Together
with unconditional writing to the config file, this created
config files with a persistent setting for important timers as '0'.
To make things worse, many of our example cofig files suffered from the
same problem.
Let's avoid this from happening by
* having reasonable defaults if nothing specified in the config file
* conditionally savingg timers only if they differ from default
* reject any timer values that state zero during start-up (see previous
commit)
Change-Id: Iaac0bfca423852b61d8b9eb1438157ef00d0d8c8
Closes: OS#2380
Using this new command (introduced in OsmoBSC + OsmoNITB), you can
simulate the generation of TRAP events for testin purposes.
start the control interface monitor as an example client program:
./openbsc/contrib/bsc_control.py -m -d localhost -p 4249
then start OsmoBSC or OsmoNITB, telnet to the VTY and enter 'enable'
mode and issue the following (example) command:
ctrl-interface generate-trap my.foo.var 2342
As a result, on the bsc_control.py you will see:
Got message: TRAP 0 my.foo.var 2342
Change-Id: Ib1d2ec38290dc94797c1b365d9b733e5215ab7d1
In case the counter group allocation fails, we must handle this
gracefully and fail the allocation of the parent object, too.
The recent change (Id I7dad4a4d52fe05f6b990359841b4408df5990e21) seems
to have missed one instance, so let's follow-up.
Change-Id: I1ee9e3d26dcc18e7f979fd9a786162cbcc50942c
Related: OS#2361
If we previously had a given SI present/active, we must send a
zero-length BCCH FILLING for that SI type to the BTS to stop it from
further transmitting this SI.
Change-Id: I33e356e2fa3a69efac9080813e3e9ef4e6438ed1
Closes: OS#2368
If we want to instruct the BTS to stop sending a given SI, we must be
able to send the respective BCCH INFO / SACCH FILLING with a header but
without any L3 data IE. This patch enables the related functions to do
this whenever their data argument points to NULL.
Change-Id: I88b85614951a108574f05db3b706884afe7e87a9
In commit 8b1a2f8cd7 we started to
initialize bts->si_valid to 0. This means we are skipping the manually
configured static system information.
Instead, we have to initialize bts->si_valid to bts->si_mode_static,
i.e. start with those that are static and not to be auto-generated.
Found while developing
http://git.osmocom.org/osmo-ttcn3-hacks/tree/sysinfo
Change-Id: Iab9cc93cf6d54560a72cc393cc3721a8d10e04bf
Closes: #2367
In case the counter group allocation fails, we must handle this
gracefully and fail the allocation of the parent object, too.
RelateD: OS#2361
Change-Id: I7dad4a4d52fe05f6b990359841b4408df5990e21
This is useful if you are updating some configuration parameters which
affect the content of the SYSTEM INFORMATION messages. Currently, we
only send them at the time the RSL connection is established (i.e. when
the BTS is initialized), so if you change something, you need to bring
down and re-start the BTS.
Using the newly-introduced "bts <0-255> resend-system-information"
command, you can re-generate + re-send SYSTEM INFORMATION without
bringing the BTS down, i.e. without any radio carrier downtime.
Change-Id: I326df47de98f6d36c9a4d2d5475225d1e62bafb5
A valid subscriber is indespensible when allocating a new
transaction. Return NULL if no subscriber is supplied. This
will cause unidentified subscribers to be rejected.
Note: Under normal conditions, the problem does not occour,
but it is still possible that a misbehaving MS might trigger
the problem by sending a SETUP command before authenticating
the subscriber. (unencrypted networks)
Change-Id: Ia8739b6e329ab02c0064270d02ad1d6ee245520d
* fix BTS numbers: use 0 to indicate given BTS and 0xFF to indicate all
BTS' as it's explained in 3GPP TS 52.021 §9.3.
* only request attributes from supported (OsmoBTS) types
Change-Id: I8f43055c38000248033a8ff9ddaf0910d68d794b
Related: OS#2317
TS 04.14 (TS 44.014) specifies a series of commands specific to
conformance testing. Let's add some VTY commands to play (at least
initially) with closing and opening voice loops in the MS.
Change-Id: I38b1ee9dbf26f5689c38cb83b1b3c5e9eaad7678
For some GGSNs we need to insert the PDP Charging Characteristics
that were returned. We receive these values from GSUP and will
fill them into the tlv structure when finding the ggsn context.
Change-Id: I1725bfd2403d29ce3550bfcd6fcc1498426ef906
Necessary since libosmocore I513835be2d931d0a931cdfc996f361a451bc1a15
removes the script from libosmocore/contrib.
Change-Id: I02d7e1c0151c687fd9341d21a09ca15cbf5a1938
For the vty tests, add osmo-sgsn-accept-all.cfg (that does not need an HLR) and
use in vty_test_runner.py, otherwise the 'show sgsn' command will reply that it
could not connect to the HLR, failing the vty test which expects empty.
Change-Id: Ie3b2013198d3e2b780a4e31c36b89b58129dcacd
This helps in providing 3G software packages for the sysmoNITB hardware, which
uses 10.23.24.1 for SGSN and 10.23.24.2 for GGSN.
However, in order to not break the python tests, the osmo-sgsn.cfg example
still uses 127.0.0.1 as local address.
Change the GGSN address to 127.0.0.2, because SGSN and GGSN cannot co-exist on
the same address (the GTP port number is fixed by spec: no IE to communicate a
differing port, so it has to be the standard GTP port for both).
Change-Id: Ie3a25f6771ed6e620cb2b315638c622a9a24e530
On incoming 04.08 messages, we log only the protocol discriminator in
decimal. Enhance: log pdisc and message type in hex, and also log the
protocol and message type as human readable string.
Also adjust the msc_vlr tests' log statements for wrapped rx/tx functions
of dtap from/to the MS.
Adjust the expected output of msc_vlr_tests.
Change-Id: Ida205d217e304337d816b14fd15e2ee435e7397d
Depends: libosmocore change-id I0fca8e95ed5c2148b1a7440eff3fc9c7583898df
The ip.access nano3G needs the first RTP payload's first two bytes to read hex
'e400', or it will reject the RAB assignment. Add flag
patched_first_rtp_payload to mgcp_rtp_state to detect the first RTP payload on
a stream, and overwrite its first bytes with e400. This should probably be
configurable, but seems to not harm other femto cells (as long as we patch only
the first RTP payload in each stream). Only do this when sending to the BTS
side.
Related: OS#2459
Change-Id: I5eff04dcb0936e21690e427ae5e49228cd459bd4
libosmocore change-id I4efdb1eaae43aced33961b64d4f14b0040321c10 changes the
gsm340_gen_scts() from gmtime to localtime, meaning that by feeding a mere zero
as timestamp, we get different results depending on the local machine's
timezone setting. Instead of calling gsm340_gen_scts() with zero, simply write
a bunch of bytes as time so that the tests get identical SMS bytes every time.
Change-Id: I8a50e8963dce80609749571b61fc6ffe1c54660c
osmo-nitb becomes osmo-msc
add DIUCS debug log constant
add iucs.[hc]
add msc vty, remove nitb vty
add libiudummy, to avoid linking Iu deps in tests
Use new msc_tx_dtap() instead of gsm0808_submit_dtap()
libmgcp: add mgcpgw client API
bridge calls via mgcpgw
Enable MSC specific CTRL commands, bsc_base_ctrl_cmds_install() still needs to
be split up.
Change-Id: I5b5b6a9678b458affa86800afb1ec726e66eed88
In an upcoming commit, sgsn_vty_init() will require access to the global sgsn
config struct to initialize a generic VTY command with the proper config
destination address, see Change-Id I5b5b6a9678b458affa86800afb1ec726e66eed88.
Change-Id: Ie6b6e5422987586531a898e0c5b867623dbecb0f
Disable large parts of the code that depend on BSC presence. The code sections
disabled by #if BEFORE_MSCSPLIT shall be modified or dropped in the course of
adding the A-interface.
Don't set msg->lchan nor msg->dst.
Don't use lchan in libmsc.
Decouple lac from bts.
Prepare entry/exit point for MSC -> BSC and MSC -> RNC communication:
Add msc_ifaces.[hc], a_iface.c, with a general msc_tx_dtap() to redirect to
different interfaces depending on the actual subscriber connection.
While iu_tx() is going to be functional fairly soon, the a_tx() is going to be
just a dummy for some time (see comment).
Add Iu specific fields in gsm_subscriber_connection: the UE connection pointer
and an indicator for the Integrity Protection status on Iu (to be fully
implemented in later commits).
Add lac member to gsm_subscriber_connection, to allow decoupling from
bts->location_area_code. The conn->lac will actually be set in iu.c in an
upcoming commit ("add iucs.[hc]").
move to libcommon-cs: gsm48_extract_mi(), gsm48_paging_extract_mi().
libmsc: duplicate gsm0808 / gsm48 functions (towards BSC).
In osmo-nitb, libmsc would directly call the functions on the BSC level, not
always via the bsc_api. When separating libmsc from libbsc, some functions are
missing from the linkage.
Hence duplicate these functions to libmsc, add an msc_ prefix for clarity, also
add a _tx to gsm0808_cipher_mode():
* add msc_gsm0808_tx_cipher_mode() (dummy/stub)
* add msc_gsm48_tx_mm_serv_ack()
* add msc_gsm48_tx_mm_serv_rej()
Call these from libmsc instead of
* gsm0808_cipher_mode()
* gsm48_tx_mm_serv_ack()
* gsm48_tx_mm_serv_rej()
Also add a comment related to msc_gsm0808_tx_cipher_mode() in two places.
Remove internal RTP streaming code; OsmoNITB supported that, but for OsmoMSC,
this will be done with an external MGCP gateway.
Remove LCHAN_MODIFY from internal MNCC state machine.
Temporarily disable all paging to be able to link libmsc without libbsc.
Skip the paging part of channel_test because the paging is now disabled.
Employ fake paging shims in order for msc_vlr_tests to still work.
msc_compl_l3(): publish in .h, tweak return value. Use new libmsc enum values
for return val, to avoid dependency on libbsc headers. Make callable from
other scopes: publish in osmo_msc.h and remove 'static' in osmo_msc.c
add gsm_encr to subscr_conn
move subscr_request to gsm_subscriber.h
subscr_request_channel() -> subscr_request_conn()
move to libmsc: osmo_stats_vty_add_cmds()
gsm_04_08: remove apply_codec_restrictions()
gsm0408_test: use NULL for root ctx
move to libbsc: gsm_bts_neighbor()
move to libbsc: lchan_next_meas_rep()
move vty config for t3212 to network level (periodic lu)
remove unneccessary linking from some tests
remove handle_abisip_signal()
abis_rsl.c: don't use libvlr from libbsc
gsm_subscriber_connection: put the LAC here, so that it is available without
accessing conn->bts. In bsc_api.c, place this lac in conn for the sake of
transition: Iu and A will use this new field to pass the LAC around, but in a
completely separate OsmoBSC this is not actually needed. It can be removed
again from osmo-bsc.git when the time has come.
Siemens MRPCI: completely drop sending the MRPCI messages for now, they shall
be added in osmo-bsc once the A-Interface code has settled. See OS#2389.
Related: OS#1845 OS#2257 OS#2389
Change-Id: Id3705236350d5f69e447046b0a764bbabc3d493c
libvlr now delegates subscriber management to osmo-hlr, so the database no
longer represents a HLR. It basically only stores SMS, so reflect that fact in
the default database name.
Change-Id: I3289d68d3eb63aff940b48a25b584d5e83cd0197
Original libvlr code is by Harald Welte <laforge@gnumonks.org>,
polished and tweaked by Neels Hofmeyr <nhofmeyr@sysmocom.de>.
This is a long series of trial-and-error development collapsed in one patch.
This may be split in smaller commits if reviewers prefer that. If we can keep
it as one, we have saved ourselves the additional separation work.
SMS:
The SQL based lookup of SMS for attached subscribers no longer works since the
SQL database no longer has the subscriber data. Replace with a round-robin on
the SMS recipient MSISDNs paired with a VLR subscriber RAM lookup whether the
subscriber is currently attached.
If there are many SMS for not-attached subscribers in the SMS database, this
will become inefficient: a DB hit returns a pending SMS, the RAM lookup will
reveal that the subscriber is not attached, after which the DB is hit for the
next SMS. It would become more efficient e.g. by having an MSISDN based hash
list for the VLR subscribers and by marking non-attached SMS recipients in the
SMS database so that they can be excluded with the SQL query already.
There is a sanity limit to do at most 100 db hits per attempt to find a pending
SMS. So if there are more than 100 stored SMS waiting for their recipients to
actually attach to the MSC, it may take more than one SMS queue trigger to
deliver SMS for subscribers that are actually attached.
This is not very beautiful, but is merely intended to carry us over to a time
when we have a proper separate SMSC entity.
Introduce gsm_subscriber_connection ref-counting in libmsc.
Remove/Disable VTY and CTRL commands to create subscribers, which is now a task
of the OsmoHLR. Adjust the python tests accordingly.
Remove VTY cmd subscriber-keep-in-ram.
Use OSMO_GSUP_PORT = 4222 instead of 2222. See
I4222e21686c823985be8ff1f16b1182be8ad6175.
So far use the LAC from conn->bts, will be replaced by conn->lac in
Id3705236350d5f69e447046b0a764bbabc3d493c.
Related: OS#1592 OS#1974
Change-Id: I639544a6cdda77a3aafc4e3446a55393f60e4050
Original libvlr code is by Harald Welte <laforge@gnumonks.org>,
polished and tweaked by Neels Hofmeyr <nhofmeyr@sysmocom.de>.
This is a long series of trial-and-error development collapsed in one patch.
This may be split in smaller commits if reviewers prefer that. If we can keep
it as one, we have saved ourselves the additional separation work.
Related: OS#1592
Change-Id: Ie303c98f8c18e40c87c1b68474b35de332033622
Enable various components according to the build matrix during make distcheck.
Add python tests, osmo-bsc, nat, ...
Change-Id: Ic724cf61d44409337414dc58c8795896b4b97a8a
- bscs.config needed by the vty tests was not picked up as a dist file, because
its suffix is not 'cfg'. Rename to *.cfg. Apply this rename in
vty_test_runner.py and osmo-bsc_nat.cfg.
- Remove restart counters after external tests, otherwise distcheck complains
about uncleaned files.
- Add contrib/ipa.py to EXTRA_DIST, hence add a Makefile.am to contrib/.
Otherwise the python tests cannot find that dependency.
Change-Id: I42b55cb1125099afc3a8e3f87c0e398426b2e2a9
Before, each GSUP client would contact the HLR with an identical unit id, i.e.
"SGSN-00-00-00-00-00-00", with the result that some messages were sucked off by
the wrong client.
Pass explicit unit name from each gsup client user, so that OsmoMSC is "MSC"
and OsmoSGSN is "SGSN". Hence the HLR can properly route the messages.
Todo: also set some values instead of the zeros.
Unrelated cosmetic change while editing the arguments: gsup_client_create()'s
definition's oap client config arg name mismatched the one used in the
declaration. Use oapc_config in both.
Change-Id: I0a60681ab4a4d73e26fe8f0637447db4b6fe6eb2
This is the first step in creating this repository from the legacy openbsc.git.
Like all other Osmocom repositories, keep the autoconf and automake files in
the repository root. openbsc.git has been the sole exception, which ends now.
Change-Id: I9c6f2a448d9cb1cc088cf1cf6918b69d7e69b4e7
We are building with libosmo-sccp tag 'old_sua' until the new sigtran has
been applied. Since osmo-iuh commit
0f88c110093935305143987638e46dc6db304a3e
"migrate osmo-hnbgw to libosmo-sigtran's SCCP/M3UA"
osmo-iuh requires libosmo-sccp master. A similar 'old_sua' tag is in place in
osmo-iuh.git, to match libosmo-sccp 'old_sua'. Do that to fix the jenkins
build of --enable-iu.
Change-Id: I70f731db0b74ed48ae6dd713ed4c3247222ef0de
echo -e "/*\n\n DO NOT EDIT THIS FILE!\n THIS IS OVERWRITTEN DURING BUILD\n This is an automatic copy of <osmocom/mgcp/mgcp_common.h>\n\n */" > mgcp_common.h
p.add_argument('-t','--token',default='osmocom',help="Token to be used by SSE client in URL e. g. http://127.0.0.1:8888/poll/osmocom where 'osmocom' is default token value")
p.add_argument('-k','--keepalive',type=int,default=5000,help="Timeout betwwen keepalive messages, in milliseconds, defaults to 5000")
args=p.parse_args()
random.seed()
tornado.netutil.Resolver.configure('tornado.netutil.ThreadedResolver')# Use non-blocking resolver
print"Sent all messages... check wireshark for the last response"
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
