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 <pma...@sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-CC: pespin <pes...@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 <pes...@sysmocom.de> Gerrit-MessageType: comment
