This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgHi 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 at do.main" notation, where we have something like rtpbridge/23 at mgw.sysmocom.de for RTP-bridge and dahdi/L0/S0 at mgw.sysmocom.de for E1 timeslot 0 at line 0 of a DAHDI card, or dahdi/L1/S5/SS2 at 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 -- - Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)