Bug #2660
closedosmo-mgw has no proper introspection via VTY + CTRL
0%
Description
osmo-mgw should be able to show us all relevant information about each endpoint (and each connection on each EP) in the VTY
Checklist
- proper "show mgcp endpoint" command
- show endpoint connection details in vty
- show RTP and RTCP statistics / diagnostics information
Updated by stsp over 5 years ago
The 'show mgcp' VTY command already does most of what is being asked for in this issue.
I have added a VTY command which allows filtering the information shown by 'show mgcp' for a specific endpoint:
https://gerrit.osmocom.org/#/c/osmo-mgw/+/10022/
Such filtering could be quite useful for non-human VTY users, such as automated tests etc.
osmo-mgw does not seem to have a CTRL interface yet so nothing could be implemented there for this issue.
Updated by stsp over 5 years ago
This is waiting for a response from Neels in code review. I am unsure if I need to take further action or if the patch is fine as proposed.
Updated by laforge over 5 years ago
ping? the patch has been meged. please keep this ticket updated (percent done, checklist items, ...) and take care of any missing bits.
Updated by stsp over 5 years ago
Sorry. I forgot about updating this ticket after discussing this further with Neels.
I only recorded the result of our conversation in gerrit:
https://gerrit.osmocom.org/c/osmo-mgw/+/10022/#message-0ec211fc491919f3dadd03553d8e57f92f2d5bfc
Neels and I discussed this face-to-face today, and I've updated the patch set accordingly.
The main changes are:
There are now two new VTY commands, with and without a trunk number.
Endpoint names are printed without a 0x prefix.
I'll update this ticket's checklist now.
Updated by stsp over 5 years ago
- Checklist item proper "show mgcp endpoint" command set to Done
Updated by stsp over 5 years ago
There are now two new commands:
- show mgcp endpoint NAME
- show mgcp trunk <0-64> endpoint NAME
Endpoint connection details (RTP stream IP addresses and ports) and be viewed with 'show mgcp stats'.
So the first two checklist items can be considered resolved.
It seems there remains some work to be done for the last checklist item (RTP and RTCP stats).
Updated by stsp over 5 years ago
- Checklist item show endpoint connection details in vty set to Done
Updated by stsp over 5 years ago
No further work has been done here yet.
I plan to discuss with Philip which RTP/TCP stats would be useful to collect and display.
Updated by stsp over 5 years ago
I discussed this issue with dexter today. There are some RTP statistics in OsmoMGW already, however they are lost when the connection is closed.
We put some thought into what global counters might be useful, and came up with the following list:
- mgw: RTP/RTCP connections (sockets) current and total
- mgw: new RTP connections rejected
- mgw: RTP connections aborted
- mgw: bytes+packets transferred
- mgw: RTP packets discarded (e.g. wrong port, wrong IP, wrong payload type, ...)
- mgcp: which codecs were used by how many connections
Updated by stsp over 5 years ago
Also related to this, I have submitted a patch which makes 'show rate-counters' on OsmoMGW's VTY more useful:
https://gerrit.osmocom.org/c/osmo-mgw/+/11439
('show rate-counters' displays the per-connection stats mentioned above, which are discarded when the connection is closed)
Updated by laforge over 5 years ago
On Tue, Oct 23, 2018 at 01:08:37PM +0000, stsp [REDMINE] wrote:
I discussed this issue with dexter today. There are some RTP statistics in OsmoMGW already, however they are lost when the connection is closed.
hopefully the "lost" here only refers to "lost from osmo_[rate]_ctr". Any RTP implementation
should send aggregated statistics to the peer using RTCP on teardown.
- mgw: RTP/RTCP connections (sockets) current and total
- mgw: new RTP connections rejected
what's a "rejected connection" in the context of RTP? As RTP is UDP, each packet
can get rejected?
- mgw: RTP connections aborted
what is an "aborted connection" in the context of RTP?
- mgw: bytes+packets transferred
I presume that means, separatee rx + tx counters for bytes + packets, like in SGSN.
And also (not RTP-related):
- mgcp: which codecs were used by how many connections
great idea. I presume you're referring to the codecs negotiatated during MGCP CRCX/MDCX?
The MGCP/SDP protocol actually doesn't choose one codec, but choose a list of codecs, each
mapped to a given RTP payload type (PT). But sure, in such situations one simply bumps the counter
for each of the codecs in that list?
Updated by stsp over 5 years ago
Sorry for not using the correct terms.
My comments should probably have said "MGCP connection".
And yes, "lost" just means that when an mgcp connection is freed, the rate counters maintained for that connection are freed as well.
Updated by stsp over 5 years ago
This proposed patch adds statistics for MGCP CRCX command failures: https://gerrit.osmocom.org/c/osmo-mgw/+/11463
Updated by stsp over 5 years ago
More related patches have been proposed:
show RTP TX/RX stats in 'mgcp show stats' output
https://gerrit.osmocom.org/c/osmo-mgw/+/11494
use local variable for rate counters in handle_create_con()
https://gerrit.osmocom.org/c/osmo-mgw/+/11495
add more mgcp crxc error counters
https://gerrit.osmocom.org/c/osmo-mgw/+/11496
add MDCX command statistics to osmo-mgw
https://gerrit.osmocom.org/c/osmo-mgw/+/11499
Updated by stsp over 5 years ago
Above patches have been merged.
dexter and I would still like to implement aggregation of counters maintained per RTP connection.
We'd introduce a global instance of these counters and aggregate stats from all connections there.
The reason is that per-connection counters are ephemeral; they can only be viewed on the VTY while the connection is live.
Updated by stsp over 5 years ago
More proposed patches:
add aggregated rtp connection stats to osmo-mgw
https://gerrit.osmocom.org/c/osmo-mgw/+/11519
add DLCX command statistics to osmo-mgw
https://gerrit.osmocom.org/c/osmo-mgw/+/11521
Updated by stsp over 5 years ago
- Checklist item show RTP and RTCP statistics / diagnostics information set to Done
Updated by stsp over 5 years ago
- Status changed from In Progress to Resolved
Above patches have been merged as well.
I'm calling this issue done. If there's more to do here, please re-open.