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

dexter gerrit-no-reply at
Fri Jul 16 08:10:52 UTC 2021

dexter has posted comments on this change. ( )

Change subject: mgcp_protocol: refactor MGCP request handling

Patch Set 4:

File src/libosmo-mgcp/mgcp_msg.c: 
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. 
File src/libosmo-mgcp/mgcp_protocol.c: 
> 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... 
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). 
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. 
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. 
PS1, Line 400: 		if (strncmp(mgcp_requests[i].name,, 4) == 0) {
> what about having "name" field be a char[4+1] and copy the first bytes of msgb in there? Looks more  […]
PS1, Line 413: 				     "%s: executing request handler \"%s\" for endpoint resource \"%s\"\n",,
> NOTICE here looks a level too high. […]

To view, visit
To unsubscribe, or for help writing mail filters, visit

Gerrit-Project: osmo-mgw
Gerrit-Branch: master
Gerrit-Change-Id: I9f519d8a0ee8a513fa1e74acf3ee7dbc0991cdde
Gerrit-Change-Number: 24941
Gerrit-PatchSet: 4
Gerrit-Owner: dexter <pmaier at>
Gerrit-Reviewer: Jenkins Builder
Gerrit-CC: pespin <pespin at>
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>
Gerrit-MessageType: comment
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the gerrit-log mailing list