Change in osmo-mgw[master]: mgcp_protocol: add support for wildcarded DLCX

historical

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

Change subject: mgcp_protocol: add support for wildcarded DLCX
......................................................................

Patch Set 3:

(4 comments)

Hello Neels,

> Could you give an example of such a wildcard DLCX command?
> Like, is it "DLCX rtpbridge/*"?
> and it removes all 1 at mgw, 2 at mgw, ... endpoints, each releasing two RTP conns?

Here is an example: DLCX 1210 rtpbridge/*@mgw MGCP 1.0, see also see also RFC3435 Annex F.7. Yes it clears all RTP conns on all endpoints at once.

> So does such a wildcarded DLCX clear out the entire MGW state?
> In practice we would then damage the use case of multiple programs using the same osmo-mgw.
> 
> E.g. if one osmo-mgw is shared between MSC and BSC, a wildcard DLCX from the BSC would also clear the MSC's conns?
> 
> Or imagine two BSCs are using the same osmo-mgw.
> If one crashes and restarts, the other also gets all calls dumped.

Yes this is true, it indeed clears the entire trunk. The usecase were BSC and MSC are sharing one osmo-mgw instance is critical indeed, but other than for small test setups I do not see any practical application for this usecase. Usually BSC and and MSC are not on the same machine. Also osmo-mgw is currently single threaded so that it is even a disadvantage not to have two separate osmo-mgw instances, even if BSC and MSC are on the same machine. However, when I do the osmo-bsc/osmo-msc part I will make it configurable via VTY.

> For a while now I've been having the idea on my mind that osmo-mgw should have an inactivity timeout on endpoints.
> When we didn't see any RTP nor MGCP for a long long time (one hour?) then we discard the endpoint implicitly. That would not need a clean wipe from any client program.
> one hour: I'd pick a really long time for cases where a call is on hold / mute, or with local-call-local-switch, so that an endpoint can remain inactive for some time to support those use cases.

We already have that feature but it is probably interfering with LCLS. I think the solution to the problem we see here depends on the usecase.

> As I'm writing I'm also getting another idea: we already support using distinct domain names from MGCP clients. For example, I often configure my osmo-msc to use "1 at msc" and the osmo-bsc to use "1 at bsc" domain names in endpoints. If each client of an osmo-mgw has a distinct name (say "@bsc1" and "@bsc2"), it could clear out all its own endpoints like "DLCX *@bsc2" and leave the others intact.

I think we should allow the configuration of additional virtual trunks. Than we can have rtpbridge_bsc, and rtpbridge_msc, in case it has to be a single osmo-mgw instance. This would have the same effect and would be more spec compliant I think. (don't know if an MGW can have two distinct domain names, but it would definetly a hack if applied to our architecture).

> Is there a redmine issue describing this? (add "Related:" to commit log?)

It refers to SYS#5392. There was the problem that the BSC was restarted severeal times but the MGW was not restarted, so over time all the endpoint resources got filled. I want to make sure that if osmo-bsc restarts that it also resets the endpoints on the MGW.

> code wise i'm confused about the role of 'endp' in this patch.
> Isn't 'endp' one single "123 at mgw" endpoint? Why does MGCP like "DLCX *@mgw" then go through an 'endp'?

The architecture of osmo-mgw has a quirk. To do the wildcarded DLCX it first gets a free endpoint and from that endpoint it gets to the trunk. This could be fixed by adding a trunk member to struct mgcp_parse_data, that at least holds a trunk. What basically happens is that the endpoint is resolved when mgcp_parse_data is created. After the parsing handle_delete_con() is called, but by then the endpoint is already resolved. We get any endpoint that is free. This does not matter unless the trunk is fully used, then everything is locked up because we can't get a free endpoint anymore. I can try to fix this in a follow up patch.

Best regards.
Philipp

https://gerrit.osmocom.org/c/osmo-mgw/+/24823/2//COMMIT_MSG 
Commit Message:

https://gerrit.osmocom.org/c/osmo-mgw/+/24823/2//COMMIT_MSG@9 
PS2, Line 9: At the moment osmo-mgw does not support wildcarded DLCX requests that
> oh wow, i thought we were already using them
I was surprised about this too. I remember that I was trying some methods to clear the MGW state some years ago, but non of it was working satisfactory.

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

https://gerrit.osmocom.org/c/osmo-mgw/+/24823/2/src/libosmo-mgcp/mgcp_protocol.c@1278 
PS2, Line 1278: 	if (!endp->wildcarded_req && llist_count(&endp->conns) <= 0) {
> how can llist_count return < 0? I don't think it can. […]
Done

https://gerrit.osmocom.org/c/osmo-mgw/+/24823/2/src/libosmo-mgcp/mgcp_protocol.c@1341 
PS2, Line 1341: trank
> trunk
Done

https://gerrit.osmocom.org/c/osmo-mgw/+/24823/2/src/libosmo-mgcp/mgcp_protocol.c@1350 
PS2, Line 1350: 		return create_ok_response(endp, 200, "DLCX", p->trans);
> isn't endp released already in here since you released all the endpoints in the loop above?
The endp is still there, it just got rid of all its connected and the state is reset. The memory still exists. mgcp_endp_release() does not free the endp struct.

I have set endp to NULL now since the request does not refer to a specific endpoint anyway.

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

Gerrit-Project: osmo-mgw
Gerrit-Branch: master
Gerrit-Change-Id: I0770cf46d93ab09efe9cafdd56d2e3f1132db189
Gerrit-Change-Number: 24823
Gerrit-PatchSet: 3
Gerrit-Owner: dexter <pmaier at sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-CC: neels <nhofmeyr at sysmocom.de>
Gerrit-CC: pespin <pespin at sysmocom.de>
Gerrit-Comment-Date: Wed, 07 Jul 2021 11:04:21 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: neels <nhofmeyr at sysmocom.de>
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/20210707/0e5e8df9/attachment.htm>