Change in osmo-mgw[master]: mgcp_protocol: refactor MGCP request handling

[dexter]

dexter has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-mgw/+/24941 )

Change subject: mgcp_protocol: refactor MGCP request handling
......................................................................


Patch Set 4:

(7 comments)

https://gerrit.osmocom.org/c/osmo-mgw/+/24941/1/src/libosmo-mgcp/mgcp_msg.c 
File src/libosmo-mgcp/mgcp_msg.c:

https://gerrit.osmocom.org/c/osmo-mgw/+/24941/1/src/libosmo-mgcp/mgcp_msg.c@186 
PS1, Line 186: 	pdata->trans = "000000";
> why doing this? it could be that trans was parsed correctly? or we don't use it anyway?
It is not used, I have oriented myself on the code that was already there. I think the reason why we reset the parameters on failure is historical. In any case, if parsing fails we don't care what the trans was and start over. So I think its better we remove this part.


https://gerrit.osmocom.org/c/osmo-mgw/+/24941/1/src/libosmo-mgcp/mgcp_protocol.c 
File src/libosmo-mgcp/mgcp_protocol.c:

https://gerrit.osmocom.org/c/osmo-mgw/+/24941/1/src/libosmo-mgcp/mgcp_protocol.c@372 
PS1, Line 372: 		LOGP(DLMGCP, LOGL_ERROR,
> ERROR? that's expected depending on message type right? print this conditionally based on req. […]
I have set the log level to ERROR but you are possibly right, its not an error. However, it is an error about to happen...


https://gerrit.osmocom.org/c/osmo-mgw/+/24941/1/src/libosmo-mgcp/mgcp_protocol.c@375 
PS1, Line 375: 		rate_ctr_inc(rate_ctr_group_get_ctr(rate_ctrs, MGCP_GENERAL_RX_FAIL_NO_ENDPOINT));
> Same, this is not necessarily a failure right?
yes and no, if the trunk is not overloaded or the request has a wrong endpoint name, then it is definitely an error. If the trunk is overloaded and the endpoint name is wild carded, we won't get an endpoint, but a DLCX would still be able to execute under those condition. In any case, it is not normal that we are able to resolve a trunk without getting an endpoint. If that happens the situation is already erroneous and the request handler must somehow recover from that (if it can).


https://gerrit.osmocom.org/c/osmo-mgw/+/24941/1/src/libosmo-mgcp/mgcp_protocol.c@386 
PS1, Line 386: 		rq.mgcp_cause = rc;
> rc is always 0 here?
in this case not 0, it still contains the cause code from mgcp_endp_by_name(). I have reorganized the code a bit so that it stores rc earlier in rq.mgcp_cause. Its probably more clear then.


https://gerrit.osmocom.org/c/osmo-mgw/+/24941/1/src/libosmo-mgcp/mgcp_protocol.c@392 
PS1, Line 392: 		if (pdata.trans && rq.endp->last_trans && strcmp(rq.endp->last_trans, pdata.trans) == 0) {
> so transactions without endpoint cannot be repeated? because they are under the "rq. […]
that is correct. Its also so that the repetition only makes sense when a specific endpoint is addressed. For wild carded requests this feature is of minor importance I think. This is probably a quirk, however the only solution would be to manage the transactions in a different location. Or search all endpoints for that specific transaction ID. In any case, this would be a different topic/patch anyway.


https://gerrit.osmocom.org/c/osmo-mgw/+/24941/1/src/libosmo-mgcp/mgcp_protocol.c@400 
PS1, Line 400: 		if (strncmp(mgcp_requests[i].name, rq.name, 4) == 0) {
> what about having "name" field be a char[4+1] and copy the first bytes of msgb in there? Looks more  […]
Done


https://gerrit.osmocom.org/c/osmo-mgw/+/24941/1/src/libosmo-mgcp/mgcp_protocol.c@413 
PS1, Line 413: 				     "%s: executing request handler \"%s\" for endpoint resource \"%s\"\n", rq.name,
> NOTICE here looks a level too high. […]
Done



-- 
To view, visit https://gerrit.osmocom.org/c/osmo-mgw/+/24941
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings

Gerrit-Project: osmo-mgw
Gerrit-Branch: master
Gerrit-Change-Id: I9f519d8a0ee8a513fa1e74acf3ee7dbc0991cdde
Gerrit-Change-Number: 24941
Gerrit-PatchSet: 4
Gerrit-Owner: dexter <pmaier at sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-CC: pespin <pespin at sysmocom.de>
Gerrit-Comment-Date: Fri, 16 Jul 2021 08:10:52 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: pespin <pespin at sysmocom.de>
Gerrit-MessageType: comment
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20210716/c9648aa2/attachment.htm>