osmo-mgw[master]: MGCP endpoints: parse as decimal, not hex

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.org
Sat Dec 2 21:25:04 UTC 2017


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 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)



More information about the OpenBSC mailing list