OsMux + MGW + SIP

[Keith]

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/