I'd like to re-raise this patch I merged for discussion, it's about whether or not OsmoMGW endpoint identifiers are in hex. My patch might have gone in the wrong direction after all.
https://gerrit.osmocom.org/4780
~N
On Sat, Dec 02, 2017 at 06:53:39PM +0000, Neels Hofmeyr wrote:
Patch Set 2:
elsewhere it seems we are confirming the hex nature of endpoint IDs (or was that a connection identifier?) ... Possibly this needs to be fixed the other way, by libosmo-mgcp-client translating the number-of-endpoints to a hex representation?
-- To view, visit https://gerrit.osmocom.org/4780 To unsubscribe, visit https://gerrit.osmocom.org/settings
Gerrit-MessageType: comment Gerrit-Change-Id: Ic18608ff23303c1564548a86d5f6bfa539fe555e Gerrit-PatchSet: 2 Gerrit-Project: osmo-mgw Gerrit-Branch: master Gerrit-Owner: Neels Hofmeyr nhofmeyr@sysmocom.de Gerrit-Reviewer: Harald Welte laforge@gnumonks.org Gerrit-Reviewer: Holger Freyther holger@freyther.de Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: Neels Hofmeyr nhofmeyr@sysmocom.de Gerrit-HasComments: No
Hi Neels,
On Sat, Dec 02, 2017 at 07:56:06PM +0100, Neels Hofmeyr wrote:
I'd like to re-raise this patch I merged for discussion, it's about whether or not OsmoMGW endpoint identifiers are in hex. My patch might have gone in the wrong direction after all.
MGCP endpoint names are strings. I don't particularly care whether any existing legacy code is treating them as decimal or as hex numbers - both are wrong, so we shouldn't spend time on changing either way (unless there's a clear, simple bugfix/inconsistency).
All code - particularly important on the mgcp client side - should treat MGCP endpoint names as opaque strings and not interpret them as something different.
A MGW may very well internally use integer numbers into an array of endpoints (such as an array of E1 slots, or RTP-Bridge endpoints).
As mentioned before, the best way to go about endpoint naming is to adopt something like an "class/instance@do.main" notation, where we have something like rtpbridge/23@mgw.sysmocom.de for RTP-bridge and dahdi/L0/S0@mgw.sysmocom.de for E1 timeslot 0 at line 0 of a DAHDI card, or dahdi/L1/S5/SS2@mgw.sysmocom.de for E1 sub-slot 2 in timeslot 5 at line 1 of a DAHDI card
The mgcp client can then simply request something like "rtpbrige/*@mgw.sysmocom.de" which will trigger the MGW to allocat an unused RTP bridge endpoint and respond with that in the CRCX response.
Contrary to RTP, the mgcp client in the BSC for E1 will have a-priori knowledge which E1 line/slot/subslot is to be used, as there is a 1:1 mapping from air-interface-channel to E1 slot/subslot, which is configured in the BSC configuration. So in that case, no "*" notation would be used.
Regards, Harald
Excellent summary, which wasn't entirely clear to me before; I still had the concepts of rtpbridge/* vs dahdi/<fixed> mixed up.
So that patch was acceptable because it solved an inconsistency between config and endpoint use of the currently anyway incomplete/wrong endpoint interpretation. It won't matter as soon as endpoint strings are overhauled.
IIUC until now we have a '*' in the Connection Id field, still need to implement the class/instance@domain, particularly rtpbridge/*@domain.
~N
On Sat, Dec 02, 2017 at 10:25:04PM +0100, Harald Welte wrote:
As mentioned before, the best way to go about endpoint naming is to adopt something like an "class/instance@do.main" notation, where we have something like rtpbridge/23@mgw.sysmocom.de for RTP-bridge and dahdi/L0/S0@mgw.sysmocom.de for E1 timeslot 0 at line 0 of a DAHDI card, or dahdi/L1/S5/SS2@mgw.sysmocom.de for E1 sub-slot 2 in timeslot 5 at line 1 of a DAHDI card
The mgcp client can then simply request something like "rtpbrige/*@mgw.sysmocom.de" which will trigger the MGW to allocat an unused RTP bridge endpoint and respond with that in the CRCX response.
Contrary to RTP, the mgcp client in the BSC for E1 will have a-priori knowledge which E1 line/slot/subslot is to be used, as there is a 1:1 mapping from air-interface-channel to E1 slot/subslot, which is configured in the BSC configuration. So in that case, no "*" notation would be used.
-
Harald Welte -
Neels Hofmeyr