On 09/09/18 16:08, Harald Welte wrote:
Hi Keith,
I'm not sure I'm following your lines of thought completely.
Hi Harald, thanks for taking the time to reply to my thoughts!
So any process from another domain / hierarchy controlling a media gateway directly
sounds immediately like "HACK/UNCLEAN" to me.
Yes.
What we are doing; GSM with no centralised core network and no reliable
backhaul is kind of HACK-ish though, isn't it?
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.
OK, but isn't it going to be a MGW that decapsulates OSMUX?
And then, isn't the MGW going to communicate to it's controlling MSC
over MGCP which port it is going to send the decapsulated stream for
circuit ID (x) to? (and where it expects the other direction stream)
SO therefore, isn't it the MSC, via osmo-sip-connector that has to
communicate this info to the SIP UA so it can react accordingly?
* 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?
One is in the
village, one is in the data centre.
I /think/ I can be concise here and say that what I am proposing is that
to use OSMUX with MSC/MGW, you have two MGW processes, one on either end
of the satellite link and the one MSC signals both of them. I get that
it's a horrific departure from standards, but so is the use case, no? :)
Before we shoot it down for that, can we discuss if it would work?
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.
Yeah, I entered confusion into my last email by mentioning the two MGW
for BSC and MSC in the same breath as this other hacky thing..
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.
Right, good.
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".
:) Yep. It's a hack. but it wouldn't be somebody else's media gateway .
it'd be an orphan!
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.
Ok so i'm can agree and we can argue away this proposal, but if we don't
teach freeswitch to understand osmux...
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.
then what? if not write a proxy, then how to communicate from the
demuxing MGW to the SIP UA where to read/send the streams??
thanks!
k/