osmo-mgw endpoint allocation

Hi all, we recently had some (verbal) discussions on how to handle endpoint allocations in a scenario where a single osmo-mgw shall be used by both osmo-bsc and osmo-msc (in a "NITB style" setup). There was some thinking about whether we should somehow divide fixed ranges of the rtp-bridge endpoints between the BSC and the MSC and how to avoid having to manually configure those. I think I now found the proper solution for this: The call agent must not even fully qualify the endpoint, but it can ask the MGW to allocate one! To quote from the MGCP RFC: EndpointId is the identifier for the connection endpoint in the gateway where CreateConnection executes. The EndpointId can be fully-specified by assigning a value to the parameter EndpointId in the function call or it may be under-specified by using the "any of" wildcard convention. If the endpoint is underspecified, the endpoint identifier SHALL be assigned by the gateway and its complete value returned in the SpecificEndPointId parameter of the response. When the "any of" wildcard is used, the endpoint assigned MUST be in- service and MUST NOT already have any connections on it. If no such endpoint is available, error code 410 (no endpoint available) SHOULD be returned. The "all of" wildcard MUST NOT be used. So in our concrete example, the BSC (or MSC) could simply ask for "rtpbridge/*@mgw" as end-point name in CRCX, and the MGW would then dynamically allocate a suitable free rtpbridge endpoint type and return it in the call agent in the BSC (or MSC). No shared knowledge about endpoint number allocations / ranges or the like required. Now we only need to implement this in osmo-mgw ;) Related: https://osmocom.org/issues/2631 Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)