Age | Commit message (Collapse) | Author | Files | Lines |
|
Related: SYS#6481
Change-Id: I9395cd526cf626974fb0e2ed93ff5d95a433d8c0
|
|
Change-Id: Ib0462228cece29952c91b4d18ebe2d89fed70c03
Related: OS#5572
|
|
Change-Id: Ibc46888b1b7913d399c79ab735841844ff0487ad
|
|
Related: SYS#5063
Change-Id: I79415c385e89fe859854430bb20940f078fccea0
|
|
Change-Id: I1212abd31f6a4758105675908a1b7cb841caa3dd
|
|
Split f_mgcp_find_param_entry() out of f_mgcp_find_param() to be able to act on
an MgcpParameterList without an enclosing MgcpMessage.
Will be used by upcoming I8b82476f55a98f7a94d5c4f1cd80eac427b2d20f
Change-Id: I90f213d2a1be979afa024e0faa25d532f9858636
|
|
Change-Id: Ibcb82d1a2d570c6c0ad0c3b6504bffe2244eccd9
|
|
Test verifies once osmux is enabled in osmo-bsc, BSSMAP RESET (ACK)
contains Osmux Support IE and that it correctly handles BSSMAP ASsign
Req with Osmux CID.
Related: OS#2551
Depends: osmo-bsc 6de754cdde5319af3059d8fc6abf85037ec7eacc
Depends: titan.ProtocolModules.BSSMAP Iaf1e137269c0da20b2c96fd104b57edf336693af
Change-Id: If69c716dc06d61d810c32d1720a237c7535baca8
|
|
Depends: osmo-mgw.git Iac073f1db46569b46eddeaecc9934a2986bd50f1
Change-Id: Ibb58b2a4e08d6f30cfe347c217794d0d1310954f
|
|
Both f_mo_call_establish() and f_mt_call_establish() were testing barely half a
voice call setup. For example, f_mo_call_establish() used to be satisfied with
just two CRCX, but no actual RTP connections being made.
Add numerous MNCC and MGCP messages more closely resembling an actual call.
The main reason is to achieve a state that passes both current osmo-msc master
as well as the upcoming inter-MSC Handover refactoring.
Add log markers to f_*_call_*(): often when a test halts, it is not at all
clear why. With these log markers it is saner to figure out what has happened
and what hasn't.
Change-Id: I162985045bb5e129977a3a797b656e30220990df
|
|
When creating an RTP flow, there is currently no way to set SDP fmtp
parameters. Lets add a template and a parameter in order to be able to
set those parameters.
Change-Id: Ic1840d5023cb3888a17980f4ed08c19175864896
Related: SYS#4470
|
|
This will prevent subsequent failures from overwriting the verdict so we
can easily see the root cause of the test failure.
Using testcase.stop instead for errors internal to our test
infrastructure to mark them as test errors instead of failed.
Change-Id: Idc6819aaf0b01e70c38fad828dd44dcec6bdd778
|
|
When a CRCX without an LCO option (codec) is sent, then older versions
of osmo-mgw will omit the port number in the SDP part of the response.
Also no default codec is selected and reported back. This testcase
pinpoints the problem.
Change-Id: Ie16cdab936ce468fe378d4ec9e1c61f81c07fb4e
Related: OS#2658
|
|
The existing MGW tests were entirely on the MGCP side. Let's start
some tests that exchange RTP frames with the MGW and validate that
the MGW can actually act on what is configured via MGCP.
Change-Id: If620d5f8927d0e3584e90a7a8f785c6fdd7c2d17
|
|
MGCP permits for the CallAgent to send a wildcarded endpoint name,
at which point the MGW itself must allocate an endpoint name and
return it as SpecificEndpointId parameter in the CRCX response.
Change-Id: I704bbe4e11b27e83a6ae6a71aa6a715dc8301f34
|
|
Change-Id: I2fc121b1d90327c879a096773ecc5c04faad07d7
|
|
This is for patch https://gerrit.osmocom.org/#/c/4980 in osmo-msc
Change-Id: Ieec52d5e0da776d35d6a473bd726b368af9d5c66
|
|
All relevant parameters are passed in in form of a CallParameters
record, and the bulk of the work has been moved to
BSC_ConnectionHandler.
Change-Id: I932c6c9f7a48b6a1f1ec399e8bba6a413c8bc69e
|
|
* re-introduce connection table
* introduce unitdata_cb for connectionless MGCP messages (like AUEP)
* rename MGCP_Emulation_CT members to avoid clashes with other similar
component names when using "multiple inheritance"
* Use HostName/PortNumber types on MGCP_conn_parameters
* allow "bind to local UDP port only, permit any UDP source port" behavior
* implement expect matching criteria + expect matching only on CRCX
* add helper function f_create_mgcp_expect() like in other Emulations
Change-Id: I953a91e663648715fa4fe98acacca393c8747001
|
|
Change-Id: Id934d7a763b619d52cbec7de439b3708225b81f3
|
|
Both codes are valid as response to a DLCX, see RFC3661 Ch 2.2:
"""
The 250 response code can be used to acknowledge a successful completion
of a DeleteConnection command. However, a 200 response code is also
appropriate.
"""
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|