Commit Graph

6938 Commits (master)

Author SHA1 Message Date
Neels Hofmeyr 5d0e07112f mgcp_client_test: fix function name
Change-Id: I213f9b2713ff80a16603b8342c204cb546cc782d
2023-12-08 05:57:37 +00:00
Pau Espin a5acaa68db mgcp-client: Transmit remote IP addr in CRCX if known and port=0
A client may know the IP address during CRCX but not yet the port, or it
may simply want to hint an initial IP address so that the MGW can better
guess when allocating a local IP address.

Related: SYS#6657
Change-Id: I30165dbac5e484011d0acf46af36f105954a501d
2023-12-07 11:14:53 +00:00
Pau Espin 7787a3aeae IuUP: Allow Initialization with set rem IP address and unset rem port
Do not refuse IuUP Initialization messages coming in on an RTP port if
the remote port is not yet known.
If an IUFP conn is not yet configured (pre-Initialization), allow rx
from any address or port.

An osmo-mgw client (eg. osmo-hnbgw) may wish to initially set a remote
IP address as a hint during CRCX, hence the IP address may already be
set while the port may be unset.

Related: SYS#6657
Change-Id: Idd833997abce46886e9664505b2776fa5dadc8db
2023-12-05 13:50:42 +01:00
Neels Hofmeyr dd1ddf74fc check_rtp_origin: drop special case for legacy IuUP hack
We have proper IuUP support and everything about this legacy hack should
be purged.

The purpose of this function is to validate that RTP is coming from the
expected address and port. To allow that legacy IuUP hack, which is no
longer needed, we punched a hole into this validation, by adding this
special case for loopback mode (suddenly we don't care who or what sends
RTP and bounce it back to anyone). So let's get rid of this hole that
was only needed for very early 3G voice hacking.

Instead, we permit RTP for IuUP Initialization regardless of the RTP
loopback/send/recv mode since I6c365559a7bd197349f0ea99f7a13b56a4bb580b

Related: SYS#6657
Change-Id: I158dd046fdfcb10392cde3de8cc88dd095a05b40
2023-12-05 13:50:42 +01:00
Neels Hofmeyr 5e101c9fed IuUP: allow Initialization from any address if not yet set
Do not refuse IuUP Initialization messages coming in on an RTP port if
the remote IP address is not yet known.
If an IUFP conn is not yet configured (pre-Initialization), allow rx
from any remote address if the remote IP address is not yet known.

If we refuse the IuUP Initialization, a 3G RNC may fail to set up a RAB.
We will know the remote address only *after* assigning a RAB succeeded.
So the IuUP Initialization must be allowed before knowing all addresses.

At the time of writing, CRCX for IUFP are sent to osmo-mgw in either
- current osmo-msc: recvonly
- osmo-msc <= v1.10.0: loopback
- osmo-hnbgw: loopback
IuUP Initialization should work regardless of that.
See also next patch I158dd046fdfcb10392cde3de8cc88dd095a05b40

IuUP is one layer below the loopback/send/recv decision for RTP; IuUP is
always terminated at the MGW, while the AMR payload carries through.

Related: alternative patch Idd833997abce46886e9664505b2776fa5dadc8db
Related: SYS#6657
Change-Id: I6c365559a7bd197349f0ea99f7a13b56a4bb580b
2023-12-05 13:49:10 +01:00
Pau Espin f6db465082 cosmetic: Fix line indentation
Change-Id: I85e47894aa0ed54dbf22a7a88d8cbeadaad4b248
2023-12-05 13:35:41 +01:00
Pau Espin a7e6fbc220 mgcp_network: Improve err logging when rtp pkt from unexpected origin comes in
Change-Id: Id9b60395df667ae9898c23cbc2afe56ac7e8b0e5
2023-12-04 11:21:53 +01:00
Neels Hofmeyr cd132126ef systemd,manual: set LimitNOFILE=65536
A typical OS imposed limit is 1024 open FD, which can bee too low when
there are hundreds of concurrent voice calls.

In systemd service file, set a super high limit of 65536.

In osmo-mgw's user manual, add section 'Configure limits' describing
this in detail.

Related: OS#6256
Related: osmo-bsc I26c4058484b11ff1d035a919bf88824c3af14e71
Change-Id: I46512517bc3b5bb90cac7643e7ac73afba398d36
2023-12-03 02:20:48 +00:00
Andreas Eversberg 249d21eb1e Use uniform log format for default config files
Related: OS#6272
Change-Id: I82ee4ce3c961976526a792862061c237a372e31b
2023-12-01 12:48:09 +01:00
Neels Hofmeyr 0127a0608d client: replace two assertions with graceful error handling
A user reports crashes of osmo-bsc upon EV_MDCX. It turns out that there
is a lot of error reporting and a distinct possibility to get a NULL
return value because of external input. Terminate the FSM instead.

FSM termination is the proper way to report a bad error, it signals the
parent_term_evt to the FSM parent, which will then be able to act on the
failed MGCP operation.

Related: SYS#6632
Change-Id: Ia5d8a9aff565399a85a5b116d7029fedcab234e0
2023-11-30 02:31:53 +00:00
Neels Hofmeyr 8b663e4d7c mgcp_parse_audio_port_pt(): fix buffer overflow
Change-Id: I18c78d15eb1593f404b4741248225b68878b463f
2023-11-15 22:09:55 +00:00
Keith Whyte 5e5c7bc176 vty and log: also show local port for RTP conns

    CONN: (1226/rtp, id:0xD94316AD, ip:, rtp:2344 rtcp:2345)


    CONN: (1226/rtp C:D94316AD r=<->l=

While changing that string, also include these changes for consistency
and readability:

- use the same r:...<->l:... format as osmo_sock_get_name().
- Instead of 'id:0x' use the actual MGCP format 'C: 9B686BE3'.
- drop the commas
- drop RTCP port: it is always RTP+1 and always an odd number.

The CONN pairs associated with each endpoint show remote RTP
ports. When osmo-mgw is being used by both BSC and MSC, one
side of the pair is showing the internal loop connection inside
osmo-mgw, while my intuition suggested this connection pair
is showing me the RTP port tuple of a single RTP stream. Adding
the local port to the display makes it more clear, IMHO.
Seeing the local port can also help to correlate the MGW vty
dump with a capture of RTP.

I first tried directly using osmo_sock_get_name_buf() on
conn->u.rtp.end.rtp.fd, but that might hide already known information
when the fd is not actively used yet (before SDP): the local address and
port would then be shown from the fd, not from
conn->u.rtp.end.local_addr/_port == hidden before the fd is set up.

Patch-By: whytek, nhofmeyr
Change-Id: Ib89a6779e1d68c6600f00699d4303f6c0ee07132
2023-11-02 18:44:16 +00:00
Neels Hofmeyr c695e9f972 add mgcp_conn_rtp_type_names[]
First use in upcoming Ib89a6779e1d68c6600f00699d4303f6c0ee07132

Change-Id: If3d8bc68a3b26d3aa0ba7eedeab67b820889ed54
2023-11-01 21:30:29 +01:00
Oliver Smith 2bdad960ff Bump version: → 1.12.1
Change-Id: Iefb000582a139ff53c4afbf94e1299e26ceeac44
2023-09-28 15:58:57 +02:00
Pau Espin 58d5b97831 mgw: Configure IuUP if codec set during MDCX
The mgcp client may first configure the connection to use RTP-AMR, but
after setting up another call leg may find out that both legs are IuUP
and hence want to forward the IuUP between the 2 connections instead.
In that case, an MDCX with codec VND.3GPP.IUFP would be set.

Until now, osmo-mgw didn't take that scenario into account, and it was
only upgrading the rtp conn to iuup internally during CRCX.
As a result, in the mentioned scenario osmo-mgw would continue to
output RTP instead of IuUP after the MDCX with VND.3GPP.IUFP, which is

Related: SYS#6578
Change-Id: Ic94bf90f54d8ba3e65a2cd52734867847f3a60c2
2023-09-27 16:25:58 +02:00
Pau Espin 6225b5cecb mgcp-client: Introduce API osmo_mgcpc_ep_local_name()
Change-Id: I18d7bdf650c0ec87ae16ed4944aed9f495400137
2023-09-26 12:44:11 +02:00
Pau Espin c415ed5113 mgcp-client: Fix missing include in mgcp_client_pool.h
struct vty is used as a param but it is never defined.

Change-Id: Ia27bb20a79966cb90e04720462d24a236a168ada
2023-09-22 18:03:02 +02:00
Pau Espin 730a1f28d2 Bump version: → 1.12.0
Change-Id: I9b1272cacaeaf1213f9a372eda52aac560cfbde5
2023-09-12 14:48:51 +02:00
Andreas Eversberg af67178581 ASCI: Support conference briding with 1..n connections
For each RTP packet that is received from a connection, the mode is
checked whether receiving is allowed or not. If not it is discarded.

In case of "confecho" mode, the RTP is also sent by the receiving

Then a loop is used to send RTP to all sending endpoints except the one
that received the packet.

Because we have a loop that allows to have 1..n connections, we have no
maximum number of allowed connections anymore.

Change-Id: Ic99a55ab5a3a6170e940403fadd52697e99f2f3a
Related: OS#4853
2023-07-10 12:14:05 +02:00
Andreas Eversberg dc7dfd0bbd ASCI: Add new mode for voice group/broadcast call
The new mode "confecho" is similar to "sendrecv", except that it also
echoes back RTP towards the sender. This is required for voice group or
broadcast calls. Talker and listeners use the same timeslot, so that
audio must be echoed from the talker to the listeners.

It is different from "loopback", because a loopback only echoes back RTP
towards the sender, but does not forward audio through the endpoint to
the other connections. Also it does not forward RTP from senders of
other connections.

The current implementation of MGW does not support transcoding and
mixing. This means that a sending connection must not send RTP that has
been received by multiple receiving connections. The application that
uses the MGW has to set the connection modes, so that only one
connection receives RTP in case of a conference.

Change-Id: I0639c663e119d85bef1010c7aa45e2f133a9daf0
Related: OS#4853
2023-07-10 11:54:16 +02:00
Neels Hofmeyr c364f4ab5a mgcp_client: tweak extract_codec_name() implementation
Instead of calling strlen() for every loop iteration, just use strchr()
to find the position of '/'.

Change-Id: Ifc7302b6c5f9288a622e33c3e8b5fe0e7037dbdc
2023-06-30 05:25:12 +02:00
Neels Hofmeyr e9989b9e76 mgcp: fix "L: a:" header parsing: heed ";" separator
In the "L: a:" header, read the first codec name only up to the ";"
separator, and ignore the rest.

According to RFC-2705, the "L: a:" header may include multiple codecs
like "GSM-EFR;GSM" in:

  L: p:20, a:GSM-EFR;GSM, nt:IN

osmo-mgw can handle only a single codec here. Since recently, osmo-msc
is our first client that may actually send more than one codec. This
uncovered a bug that leads to failing voice calls:

* osmo-mgw parses the entire list "GSM-EFR;GSM" as a single codec name,
* puts that into the ptmap without scrutiny,
* and even sends it back in the OK response, in the *SDP* part, as a
  single "GSM-EFR;GSM" codec entry.

We do not care very much about the "a:" codec list, because we always
establish codecs via SDP later. So all we need to fix this is: parse the
first codec done correctly, and ignore the rest.

Related: OS#6081
Change-Id: I0342e85b32ed89f3a1fdb6131c3c8ded8f47a455
2023-06-30 05:25:12 +02:00
Oliver Smith 9423817311 mgcp_client: check rc of map_str_to_codec
Abort with error log when map_str_to_codec is -1, instead of writing it
as unsigned integer into ptmap[i].codec.

Related: OS#6074
Change-Id: I08b91c849d810fe3cdb72c0f6f2a558b7377deab
2023-06-28 12:21:30 +00:00
Oliver Smith 292ba1bdb1 Cosmetic: fix a typo
Change-Id: I49f72acc3a42f6c7d50aeffdb1aef312c469d9f3
2023-06-28 11:49:45 +00:00
Pau Espin 10d9f8dcf4 mgcp-client: Mark client as UP when keepalive request-interval/timeout is disabled through VTY
This way if keepalive becomes disabled for an MGW, it can be selected
again (otherwise it would become non-selectable forever, and we already
have a "blocked" config for that).

Fixes: 563386e8bb
Related: SYS#6481
Change-Id: I263d23885a1a967f844033f9810b96691b8e3b30
2023-06-27 17:38:35 +02:00
Pau Espin 4c0658955e mgcp-client: Always mark client as UP if keepalive request-interval disabled
In the previous logic, if "keepalive request-interval" was disabled
(value 0, default), then if the client was configured to send a DLCX on
startup it would end up in state UP or DOWN depending on whether the MGW
answered to that request.
As a result, an MGW that wouldn't answer would be left forever in DOWN
state since it would have been selected no more and there would be a
keepalive configured to re-mark it as UP.

Fixes: 563386e8bb
Related: SYS#6481
Change-Id: I290f7436f48418ee25179951359c76208796e279
2023-06-27 17:38:27 +02:00
Pau Espin e9164c295d mgcp_client: pool: Only pick clients with an MGCP link considered to be UP
This way the user ends up picking a working MGW instance instead of one
which is not reachable around the time.

Related: SYS#6481
Change-Id: Ia3f451d3cd97851f65074408812b1ddc68f67056
2023-06-15 16:46:50 +02:00
Pau Espin 563386e8bb mgcp-client: Add keepalive feature
The `keepalive` feature in libosmo-mgcp-client allows scheduling periodical
queries on the MGCP layer in order to make sure it is reachable and hence
obtain information on the state of the MGCP link.
This patch only uses it to print the status on the VTY, but it will be used
too in a follow-up commit by the MGW Pool when picking an MGW from the pool:
MGWs whose link is considered to be DOWN are skipped.

The feature consists of:
- A `keepalive request-interval` which will trigger a transmission of an MGCP
  AuditEndpoint command targeting endpoint with name `keepalive request-endpoint`.
  This interval is updated every time any message is transmitted in the MGCP
  link, meaning the MGCP AuditEndpoint message is only triggered if no message
  has been transmitted since `keepalive request-interval` seconds ago.
- A `keepalive timeout` considering the MGW to be non-reachable (link DOWN) if
  no message is received over that amount of time.

The `keepalive` parameters are to be preferrably configured so that
"keepalive request-interval" * 2 < "keepalive timeout".

Example VTY configuration of `keepalive` feature in libosmo-mgcp-client:
 mgw 0
  keepalive request-interval 20 <1>
  keepalive request-endpoint null <2>
  keepalive timeout 50 <3>

<1> Transmit an MGCP AuditEndpoint message to the MGW if no message has been
    sent to it over last 10 seconds
<2> The MGCP AuditEndpoint targets the `null` endpoint. This is a special
    endpoint available at OsmoMGW for those purposes, but any available
    endpoint can be configured and used instead.
<3> Consider the MGCP link to be DOWN if no message is received from the
    MGW over the last 50 seconds

NOTE: The `keepalive` feature is disabled by default, and must be explicitly
      configured in order to enable it.

Related: SYS#6481
Change-Id: I3dc74c78548d017f272da863d5282dc5e0020ca3
2023-06-15 16:46:46 +02:00
Pau Espin af0f58fac7 mgw: Allow auditing speciall 'null' endpoint
This is a special endpoint which can always be audited. This is useful
for clients who wish to submit requests to osmo-mgw periodically to find
out whether the MGW is still reachable. This endpoint will be used by
libomso-mgcp-client as default target endpoint to implement such
This "null" Endpoint is osmo-mgw specific, not described in MGCP specs.

Related: SYS#6481
Change-Id: Ia409b16e9211e6261e2e0f21288544289d6f3733
2023-06-15 11:08:50 +02:00
Pau Espin 2e411f33a0 mgcp-client: Move some static functions further above
This is a preparation commit for follow-up one, where some of these
functions need to be used in other static functions.

Related: SYS#6481
Change-Id: I3a00d8c47ec773390d9626364c4c75ca579f1508
2023-06-14 13:04:15 +02:00
Pau Espin 8e8d59ff0e mgcp_client: Introduce mgcp_client_conf_alloc(), deprecate mgcp_client_conf_init()
So far, the users of the old non-pooled API were in charge of allocating
the struct mgcp_client_conf by themselves, then init them using
mgcp_client_conf_init(). This causes a major problem, since it makes it
difficult to extend the struct mgcp_client_conf structure to add new
features, which may happen frequently.

The MGW pool API doesn't have this problem, because the struct
mgcp_client_conf is allocated as parts/fields of private structs defined
in internal headers. Only pointers to it are used in public headers.
Since it still has to internally initialize the conf fields, we still
need the API to initialize it internally, and hence why is it marked as

While some programs already moved to the new MGW pool infrastructure,
they still use the old APIs to accomodate for old config files in order
to be back-compatible, hence most users of libosmo-mgcp-client are

Introduce an API to allocate the conf struct internally, which, while
still breaking the ABI, allows for a more relaxed update path where it's
possible to extend the struct mgcp_client_conf at the end.

Eventually the non pooled API should be gone and the struct
mgcp_client_conf can then be moved to a private header, but for now
let's add this small feature to avoid major ABI breakage.

Change-Id: Iba0853ed099a32cf1dde78c17e1b34343db41cfc
2023-06-14 10:59:50 +02:00
Philipp Maier 14da3a33cb mgcp_client.h: also add spec ref to the other 3gpp defined payload types
Some payload type numbers are defined in 3GPP TS 48.103, let's put the
spec reference between all of those so that it is immediately clear
where those numbers come from.

Change-Id: Ie9d949ee72286ee4de7590c99acc740011208466
2023-06-11 19:28:10 +00:00
Pau Espin ea2035326d mgcp-client: Drop unused struct mgcp_client field
Change-Id: I0b2c4a83ca0e59e54bf5e2af289e4e1fe4f0cf27
2023-06-09 11:38:00 +02:00
Philipp Maier 2bfa708527 mgcp_codec: be sensitive about IuFP when checking codecs
When two codecs are checked for convertibility we insist that
subtype_name and rate are equal since normally when those are different,
we assume a completely different codec that will require a transcoder,
which we do not have yet.

However when IuFP is used, the call agent will always negotiate IuFP as
VND.3GPP.IUFP with a rate of 16000, even though the IuFP payloads
contain regular AMR at a rate of 8000.

This means that if we detect IuFP on one side of the call leg and AMR on
the other side of the call leg, we must not insist on equal subtype_name
and rate.

This fixes the following TTCN3 testcases:

Related: OS#5461
Change-Id: I6bc1e6022efe21cb893ef213f3da35017960357d
2023-05-31 09:34:14 +00:00
Oliver Smith 72f911513e systemd: depend on
Related: SYS#6400
Change-Id: Ib6c78c76c5f13b9482428ce653a61b03b2aca1d3
2023-05-26 14:10:46 +02:00
Philipp Maier 3d0676a791 mgcp_network: do not deliver RTP packets with unpatched PT
When a call leg is set up, then the call agent (e.g. BSC, MSC, etc.)
will also negotiate a codec along with a payload type number. When
sending RTP packets, each RTP packet must also contain the negotiated
payload type number. To prevent the emission of RTP packets with an
incorrect payload type number, ensure that no packet is sent when
mgcp_patch_pt() fails.

Change-Id: I013a24c1e0f853557257368cfab9192d4611aafa
Related: OS#5461
2023-05-22 11:18:45 +02:00
Philipp Maier 4c4d227624 mgcp_codec: fix codec decision
Unfortunately OsmoMGW was never really tested with multiple different
codecs on either side of the connection. While OsmoMSC and OsmoBSC only
assign exactly one codec on each side this has never been a problem,
however it might become a problem when a call agent assigns multiple
codecs on one side. This has been observed in a setup where OsmoMGW had
one leg towards an external call agent. Also due to recent upgrades to
the TTCN3 tests we are now able to simulate different codecs on both
sides to pinpoint issues.

Testing has shown that OsmoMGW has difficulties with multiple codecs.
The reason for this is that the function that makes the codec decision
was not fully finished. So let's finish the codec decision function and
let's also use that decision when patching the payload type of outgoing
RTP packets.

Related: OS#5461
Change-Id: I6c3291f825488e5d8ce136aeb18450156794aeb5
2023-05-22 11:18:45 +02:00
Philipp Maier 0e8310fa6c mgcp_codec: move mgcp_codec_decide down
In a follow up patch we intend to fix mgcp_codec_decide, since the
fixed version of mgcp_codec_decide will use some functions below its
current position let's move it down before fixing it to make reviewing
the changes easier.

Related: OS#5461
Change-Id: I2f2538ff912eae4d80d3b74b766e18c4da94d6b6
2023-05-22 10:24:57 +02:00
Vadim Yanitskiy e3624562dc copyright: fix typo: sysmocom s/s.m.f.c./s.f.m.c./ GmbH
Change-Id: I0de7650ad119d9a5d2585e2af981c5f1ff8e7058
2023-05-18 17:22:26 +07:00
Oliver Smith d5057ec7b8 debian: set compat level to 10
Related: OS#5958
Change-Id: If00d77a3b83fa7ba000a346f087a6baf1966fdff
2023-04-25 16:48:29 +02:00
Philipp Maier 72761b312b mgcp_vty: add warnings for deprecated config options
We normally warn in case someone uses a deprecated config option

Change-Id: I182f6579930a4e5ed79c8eb87501578ce7e89c15
2023-04-21 12:09:28 +02:00
Oliver Smith a312523be4 Cosmetic: mgcp_client: fix typo
Change-Id: I8e44b4bb853ebac881cb51b9546505874cf8fa45
2023-04-18 16:11:03 +02:00
Neels Hofmeyr 45fe47cea7 mgcp_client: simpler error handling
add_sdp(), add_lco():

- do not msgb_free() within these functions. Just return error, and move
  the msgb_free() to the caller.

- when failing to write to the msgb, directly return error.

Change-Id: I904d56f56053952c2ebbbe5dca744fafa32b333e
2023-04-15 00:56:06 +02:00
Neels Hofmeyr ce356eec1f mgcp_find_section_end(): skip spaces at start of SDP
Change-Id: I015e0347a268b61c0ca45d40754942f87b461c09
2023-04-15 00:10:19 +02:00
Philipp Maier cca1d180f5 mgcp_network: fix apidoc
Change-Id: I358e21e9a9ab33beb07a9adfd4a53145aadb997d
2023-04-13 14:38:31 +02:00
Oliver Smith 833ab4b083 mgcp_client_pool: add mgcp_client_pool_empty()
Check if the private struct mgcp_client_pool has an empty member_list.

Clients that support both the legacy config and the pool config can
use this to properly exit with error if pool members are configured,
but no connection to any of the pool members can be established.

Currently clients can't distinguish a config without pool members and a
config with pool members that is broken and will fall back to using the
defaults of the legacy config in both cases.

Related: OS#5993
Change-Id: I009483ac9dfd6627e414f14d43b89f40ea4644db
2023-04-04 14:27:04 +02:00
Vadim Yanitskiy d358ca14a9 tests: $(BUILT_SOURCES) is not defined, depend on osmo-mgw
Change-Id: I951ce2410614993a855336e6bb408cae1823ef9a
2023-03-31 11:56:02 +00:00
Philipp Maier 3699ef06a4 mgcp_codec: cosmetic: remove line break in api-doc
We usually do not make a final line break on our api-doc strings.

Change-Id: I025bbf36287ef014e294cc18a6435d7e2f9c1bff
2023-03-27 17:50:18 +02:00
Philipp Maier 9dd80ca1f8 mgcp_codec: refactor payload type converstion
in mgcp_codec.c we have a function mgcp_codec_pt_translate that is used
to find the equivalent payload type number on an opposite connection.
This is quite specific and the resulting payload type number may still
belong to a codec that might require some form of conversion.

Lets refactor this so that the function just finds a convertible codec
for a given connection. This also opens up other usecases. The payload
type conversion like we did it before can then be done with a few lines
in mgcp_network.c

Related: OS#5461
Change-Id: I085260a2ca8cfecdb58656b7a046c536189e238d
2023-03-27 17:50:18 +02:00
Philipp Maier 621e8666ff mgcp_codec: fix oa/bwe comparison in mgcp_codec_pt_translate()
The function mgcp_codec_pt_translate is very strict when comparing the
codecs to each other to find a matching payload type number to be used
on the egress side.

This poses a problem when one side uses AMR in bandwith-efficient, while
the other side uses AMR in octet-aligned payload type format. To the pt
translate function the difference in the payload format will appear as
if the codec were different and eventually the payload type number
cannot be translated.

since osmo-mgw offers conversion between the payload type format it
would be no problem to ignore the payload type format when making the
translation decision. The only exception here would be if one side would
announce AMR two times, the first time with octet-aligned and the second
time with bandwith-efficient format. Then we would have to use the
payload type number from the exact match. (and skip any formatconversion)

To archive such an optimized decision we will first go through the codec
lists and perform an exact match. If we don't get a match we go through
the codec lists a second time, but this time we ignore the payload

Change-Id: Ifbd201a2749009a4644a29bd77e1d0fc0c124a9d
Related: OS#5461
2023-03-27 13:12:50 +02:00