Cellular Network Infrastructure » Core Network (CN) » osmo-sip-connector

There are various counters and stats frameworks in Osmocom for historical reasons.
(libosmocore/src/vty/stats_vty.c gives a kind of overview what we have in terms of stats/counters.)

The latest greatest is apparently libosmocore/include/osmocom/core/rate_ctr.h.
This issue could be more specific on which stats kind is desired, I'm assuming rate_ctr.

For example, see

• osmo-bsc/include/osmocom/bsc/gsm_data.h

enum {
        BSC_CTR_ASSIGNMENT_ATTEMPTED,
        BSC_CTR_ASSIGNMENT_COMPLETED,
        BSC_CTR_ASSIGNMENT_STOPPED,
[...]
};

static const struct rate_ctr_desc bsc_ctr_description[] = {
        [BSC_CTR_ASSIGNMENT_ATTEMPTED] =        {"assignment:attempted", "Assignment attempts."},
        [BSC_CTR_ASSIGNMENT_COMPLETED] =        {"assignment:completed", "Assignment completed."},
        [BSC_CTR_ASSIGNMENT_STOPPED] =          {"assignment:stopped", "Connection ended during Assignment."},
[...]

};

static const struct rate_ctr_group_desc bsc_ctrg_desc = {
        "bsc",
        "base station controller",
        OSMO_STATS_CLASS_GLOBAL,
        ARRAY_SIZE(bsc_ctr_description),
        bsc_ctr_description,
};

• osmo-bsc/src/osmo-bsc/bsc_init.c

        /* init statistics */
        net->bsc_ctrs = rate_ctr_group_alloc(net, &bsc_ctrg_desc, 0);
        if (!net->bsc_ctrs) {
                talloc_free(net); 
                return NULL;
        }

and in bsc_vty.c bsc_vty_init()

osmo_stats_vty_add_cmds();

The rate_ctr are also exposed on the CTRL interface besides the VTY, by libosmocore/src/ctrl/control_if.c under CTRL command 'rate_ctr *' (see get_rate_ctr()).

There should also be a rate_ctr_init(), just now I notice osmo-bsc doesn't call that!? Bug!!

You can also look for examples in MSC, SGSN,...

Thanks for the detailed intro neels!

To make sure this is not already implemented, I've looked at how it is behaving in the current state first. When connecting to the VTY, there are show stats and show rate-counters commands. They don't output anything useful and it does not change when making calls.

> show stats
Ungrouped counters:
> show rate-counters
>

WIP in branch osmith/statistics.

useful feedback from whytek in IRC:

From my point of view of actual use, Probably it would be more interesting to see stats on failure causes than just "failed"
also, I'm not sure what "released calls" would really describe,
all calls (that are connected) will eventually be released.
so i guess, that any difference between connected calls and released calls would mean "calls still in connected state", or "something went wrong"
I think you might be able to stay out of sip.c, and rather work within the call control functions in call.c

also, I'm not sure what "released calls" would really describe,
all calls (that are connected) will eventually be released.
so i guess, that any difference between connected calls and released calls would mean "calls still in connected state", or "something went wrong"

Sounds reasonable, I'll leave that out unless zecke or laforge have a reason why that is needed.

From my point of view of actual use, Probably it would be more interesting to see stats on failure causes than just "failed"

That sounds more useful indeed. But which failures are actually relevant? If we would only catch the ones coming from call.c as you have suggested, then we have the following:

call.c:         LOGP(DAPP, LOGL_ERROR, "call(%u) with unknown leg(%p/%d)\n",
call.c:         LOGP(DCALL, LOGL_ERROR, "Failed to allocate memory for call\n");
call.c:         LOGP(DCALL, LOGL_ERROR, "Failed to allocate MNCC leg\n");
call.c:         LOGP(DCALL, LOGL_ERROR, "Failed to allocate memory for call\n");
call.c:         LOGP(DCALL, LOGL_ERROR, "Failed to allocate SIP leg\n");

we can not count the errors raised from sip.c (which may also be interesting):

sip.c:          LOGP(DSIP, LOGL_ERROR, "leg(%p) connected but leg gone\n", leg);
sip.c:          LOGP(DSIP, LOGL_ERROR, "leg(%p) incompatible audio, releasing\n", leg);
sip.c:          LOGP(DSIP, LOGL_ERROR, "No supported codec.\n");
sip.c:          LOGP(DSIP, LOGL_ERROR, "No supported codec.\n");
sip.c:          LOGP(DSIP, LOGL_ERROR, "Unknown from/to for invite.\n");
sip.c:          LOGP(DSIP, LOGL_ERROR, "leg(%p) no audio, releasing\n", leg);
sip.c:                  LOGP(DSIP, LOGL_ERROR, "leg(%p) unknown SIP status(%d), releasing.\n", leg, status);
sip.c:          LOGP(DSIP, LOGL_ERROR, "leg(%p) got bye, releasing.\n", leg);
sip.c:          LOGP(DSIP, LOGL_ERROR, "Canceled on leg(%p)\n", hmagic);
sip.c:  LOGP(DSIP, LOGL_ERROR, "%s(): Cause(%s) not found in map.\n", __func__, gsm48_cc_cause_name(cause));
sip.c:          LOGP(DSIP, LOGL_ERROR, "Failed to allocate leg for call(%u)\n",
sip.c:          LOGP(DSIP, LOGL_ERROR, "Failed to allocate nua for call(%u)\n",

Besides, there are also errors from other files.

keith: So does it make sense to only look at call.c then, or should we go through all error messages and decide which ones are useful to count and which ones are not?

Hi.
I would not be so interested in the errors that are "caught" and logged in the code, although this might be useful to a programmer, it is of little interest to the end user. Still, if you're going to do counters we should so them for everyone, so I concur with laforge.
All the same, most if not every one of those LOGP lines that you quoted means something went kind of (badly) wrong that should not have. I would not expect to see them, ever, in normal usage.
I'm not sure if that is a reason to not count them, or a very good reason TO count them! :)

example:

LOGP(DCALL, LOGL_ERROR, "Failed to allocate memory for call\n");

I've never seen this, and I guess if it happened, you are in trouble anyway!

What I might be more interested in is:
How many calls were;

• busy
• rang out (unanswered)
• unreachable,
• etc, etc...

This is all available in the MNCC cause and SIP status, but there's no if's and LOGing for them in the code.
You might need to write a switch statement or some such and increase the counters based on the cause values.

osmith,

http://git.osmocom.org/osmo-sip-connector/tree/src/call.h#n47

This is going to contain the reason for call termination^^^^^

You could print out stats of call terminations, based on this:
https://freeswitch.org/confluence/display/FREESWITCH/Hangup+Cause+Code+Table

So I guess you'ld see something like:

OsmoSIPcon> show stats

Call Termination Reasons:
xxx UNALLOCATED_NUMBER
xxx USER_BUSY
xxx NO_ANSWER

something like that..
We could extract the "Reason" and get call termination reason on the BYE as well. (it's going to be nearly always 16) I don't think we do that right now. Then maybe divide into "successful" and "unsuccessful" call terminations.

Although I learned recently while looking at some early media issues, that in the SIP world, "success" is not what a human might imagine. a busy call for example, is "successful"., i.e without error. :))

laforge Yep.. You're absolutely correct.

All the same, if Oliver wants to go ahead and do it here too, I guess that's OK ?

keith wrote:

All the same, if Oliver wants to go ahead and do it here too, I guess that's OK ?

I only want to go ahead with this if it is actually useful :)

keith: laforge mentioned, that you have the best practical feedback on this. So you can probably tell me if that makes sense.

What I might be more interested in is:
How many calls were;

• busy
• rang out (unanswered)
• unreachable,
• etc, etc...

One of the questions is if the osmo-sip-connector is the best place to collect such
[not straight sip relatd] stats, or if they shouldn't rather be in OsmoMSC.

Yep.. You're absolutely correct.

keith, laforge: how about I open a new issue, about adding these stats to OsmoMSC and start working on that?

New issue #3636 opened for the osmo-msc counters.

keith, laforge: should I reject this issue now?