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 Keith, I'm not sure I'm following your lines of thought completely. In any case, a media gateway is always co-located to a signaling element next to it, at the same level of the network. So the BSC controls its (local) MGW, whith the MSC controls its (local) MGW The split into call-agent and MGW was introduced conceptually simply to separate the control from the user plane. From the outside point of view, it's still a "MSC" logical network element, even though internally it has been split into the "MSS" (MSC Server) and the MGW internally. So any process from another domain / hierarchy controlling a media gateway directly sounds immediately like "HACK/UNCLEAN" to me. On Sat, Sep 08, 2018 at 08:10:50PM +0200, Keith wrote: > When you divide the OSMUX stream again and turn each circuit ID back > into individual RTP stream you have an associated port and IP, right? > (on the terrestrial side) osmux doesn't establish that relationship. Whoever decapsulates OSMUX must know where to send it to, and which dynamic payload type was allocated to it, etc. > * local msc, with two colocated mgws (we decide which one to signal > depending on if the call is local or needs the SAT stream) what's the advantage of having two separate MGWs, compared to having one? All the parameters related to this call/connection are signaled in the MGCP CRCX/MDCX commands. So whether or not a given set of endpoints/calls/connections is on one MGW or on different MGW doesn't really make a difference, IMHO. > another point here is I undertand we don't _really_ need two MGWs, so > maybe just one in the village, shared between bsc/msc and one in the > datacentre. OsmoBSC + OsmoMSC can already share a single MGW at this point. > so in the case of a call that is using sat/ osmux, the MSC in the > village is signalling the MGW in the datacentre, therefore this MSC > knows which IP/port combination to tell to osmo-sip-connector and on to > freeswitch, which then signals whatever SIP UA in the data centre again, sounds like "hack" to me. The MSC signals *its* media gateway, and not "somebody elses". Sure, it's possible to design a system architecture that way, but it's not how media gateways are intended to be used, I think - whether in the context of GSM or not. > So, the fact that osmux is used at all is completely transparent to the > SIP UAs I think if that's the goal, then you'd have to implement a proxy solution that proxies both the SIP as well as the RTP flows. At that point the protocol between the two proxies doesn't matter. The proxy would then re-write/re-generate any IP/port/payload-type/etc. information in the SIP/SDP to hide the presence of osmux. To me, that looks like a last resort kind of approach. -- - 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)