Hi Keith, the "big" problem is not adding Osmux media handling here or there (whether fixing it in the new osmo-mgw, or adding it to freeswitch, or to whatever else). That's I think the comparatively the easy part. The bigger problem is how to *signal/* osmux between the various elements. The protocols that are used for signaling the media plane typically assume that each media flow * uses RTP/UDP * operates on its own port number for this flow whereas in osmux you now have multiple flows (unidirectional calls) sharing one UDP 5-tuple (src-ip/src-port/dst-ip/dst-port/l4). Instead, you have some internal ID to distinguish which of the media flows inside the osmux flow you are referring-to. So the non-trivial problem to solve is how to make the media-related signaling understand those differences, or what kind of mechanism to invent to map it to the existing presumptions that said implementations have on how media flows work. Implementing some kind of proxy (e.g. osmo-bsc_nat for old SCCPlite based A) is one option, as long as that proxy will handle translation of both the actual media (RTP/Osmux) as well as the signaling that is associated for those media flows (e.g. MGCP in old SCCPlite, or 3GPP AoIP in proper A interface). At that time, said proxy knows all the related state and can perform whatever mapping/translation. However, proxies work only good in 1:1 relationships. This means, you will be in trouble if you're looking for redundant systems (proxies would have to replicate state), or if you want to have a more "peer to peer" architecture between your villages/deployments, where any village would establish calls directly to any other village, and hence we're not just talking about a strict client-server model anymore. I'm not sure about the "burning of expensive bandwidth" in an "A backhaul" scenario. Sure, you'd have some location update traffic, but the actual media plane of local calls could stay local by means of LCLS, as Neels has pointed out. a media gateway is (as the name implies) not a signaling gateway. As MGCP is an interoperable protocol to control media gateways, you could use any switch that speaks MGCP to control it. yate offers some level of MGCP support, for example - as do many of the large/proprietary soft switches. This of course doesn't solve the question of how to represent OSMUX on MGCP/SDP side in the first place. I don't know anything about freeswitch internals. I would expect that the proper way to go about this is to actually have Freeswitch talk MGCP and use it to control OsmoMGW. That's how the concept of media gateways was intended to work, and it fits the architectural model. I don't know either, but I would be surprised if it wasn't possible. The biggest question I'd look into is the concurrency model. Osmocom code uses single-thread/single-process event-driven select() abstraction, which doesn't work well with heavily-multithreaded environments/applications. The question is: How can you represent a "trunk" of multiple calls between two systems sharing one UDP IP/port tuple, and how do you express that in SDP. Once that problem has been solved, you can signal OSMUX either via SIP or via MGCP. And once that signaling on the wire is clear, you have to think how you can fit that into the data model of whatever program you want to teach it I don't agree, sorry. In fact, I fail to see the connection. #2391 is only for annotating logs with more context, not about any functional changes. As Neels already hinted, the "proper" method of doing this is actually to extend the current LCLS implementation to go that way. So far, it only avoids media back-haul from BSC to MSC over the A interface. But with some extra logic, we could make RTP go directly between BTSs. Doing this with LCLS means that it's not a binary "bypass", but that you can actually change it at any point during the call. So you could start with media going all the way back to the core (for ringtone play-out, etc.) and then go to local switching during the call, only to later on going back through the core to play some "your balance is about to exceed" playback from a media playout server in the core, etc. So it's not an "either-or", but a very flexible system. Also, with LCLS enabled, the system will automatically figure out if local switching is possible, i.e. if both legs are going through the same BSC or not. I don't know off my head how complex that would be. My general preference is to modify MNCC in a way to either a) include SDP for media plane parameters in MNCC. This overcomes various restrictions in MNCC today, such as being only able to configure one codec, rather than a list of codecs permitted, or b) simply only handle the RAN/A side MGCP connection from OsmoMSC, and leave the CN side MGCP connection to the external MNCC entity. This way MNCC doesn't have to be "encumbered" with SDP etc. The problem with the external (SIP) world fiddling with too many low-level details of RTP media plans is that they don't have all of the information that is owned by the GSM side of things. What kind of codecs are supported and/or permitted by BTS/BSC/MSC/etc? What exactly was negotiated between the various elements? What if after a hand-over between different BTSs, the channel type and/or codec/rate are changing? A proper MGW (ours is lacking re-introduction of transcoding) exists to resolve all those bits by separating the GSM-network internals from the external side. Possible, but I don't think this is advisable. It's violating layering / network architecture all over the place. It assumes that your entiren network from CN to the BTS exist in a transparently routed network without any firewalls or NATs. And it would introduce special-purpose code which is not relevant to "normal" GSM network operation. That code needs to be maintained, and we'd need an entire different set of tests for all of this "non-standard" code. I would much rather want to see a system which is as closely aligned with the "normal" GSM network use case, which would mean going down the LCLS route for keeping media flows local. Currently within BSC-MGW, but with some easy patches you can get direct BTS-to-BTS. The hard problem to solve, as indicated, is how to express osmux in SDP, and then how to use SIP+OSMUX on the connections between OsmoMSCs of different vilalges and/or your central "public network gateway". Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

On 07.09.2018 10:15, Harald Welte wrote: Yes, I had some conversation with Pablo about this and he explained that to me, and I then assumed that there would be some way to extend the SDP with a field that specifies the internal stream ID to use. (as you say below) This might be relevant: https://tools.ietf.org/html/rfc5939 ? I don't really understand all that, to be honest, but not to worry, it is because i'm unfamiliar with these operational concepts. I haven't studied A or SCCP at all. (yet) :-/ I think it's probably unlikely that we would gain much from osmux for inter-village traffic anyway, and the volume of concurrent calls I observe is quite low. however, this can change, we could do something like carry the media stream for an inter-village call over osmux/vsat to a central switch and redistribute back to the other village either over terrestrial link if it has it, or into the other osmux stream via vSat. OK. Let's not dwell on it. As I said, I need to study 'A'. I seem to be assuming there is more traffic on it than in reality there is. Understood, I wasn't suggesting that is would signal anything, I said freeswitch would signal the MGW, over SIP, but again, as you say below better to have freeswitch speak MGCP. Hmm, interestingly, There's seems to be a bounty on offer for implementing freeswitch support for MGCP Given that rhizomatica might also need this for the ultimate vSat/osmux solution, in might make it even more attractive for somebody to implement. https://freeswitch.org/jira/browse/FS-2726 Look like one would have to get their hands on an "Adtran TA600 series IAD" https://portal.adtran.com/web/page/portal/Adtran/group/30 Right, I can't really evaluate that, but I suspected something like this would be an issue, and I wondered about how deep one might have to go into freeswitch to have it play well with the one 5-tuple per flow as opposed to the internal stream IDs per flow inside the one 5-tuple. Probably best not to go there. Um.. So in relation to #1683 where we are talking about bearer cap and knowledge of the lchans, I understand this is currently broken. see: http://osmocom.org/issues/1683#note-11 - "complete MNCC breakage in OsmoMSC" ?? But then.. as you are pointing out below, the /right/ way to do it is to isolate all this knowledge from SIP altogether. OK, so I understand then that my proposals are trying to implement things in sip-connector/freeswitch that should be done by the MGW. Freeswitch (in our case) should really just handle call control and be told to bypass media. Then the two co-located  MGWs work out the media stream. The MSC co-located MGW doesn't need to care about the channel type/codec used on the radio link. correct? So then we don't need these extension TLVs spoken of in #2391 OK, so in that case, what's your current thoughts on https://osmocom.org/issues/3142 ? Should it be closed as "won't implement"? I ask because even though it does not have to be necessarily related to this discussion, I was considering attempting to implement it as a way to dive into the MSC code. OK, Let's concetrate on that as the central problem to be solved here. Maybe Pablo can pick it up here with thoughts? (also Rafael, if you're listening, I think this response from Harald should clarify some concerns you had about media streams and signaling over vSAT) :)

On Fri, Sep 07, 2018 at 11:54:53AM +0200, Keith wrote: exactly. At the time the LCLS decision is made in OsmoBSC, you need to check if the codecs are compatible and then send the IPA MDCX to the two BTSs without keeping anythin on the MGW. To be fair, LCLS also contains use cases where the media in either uplink or downlink is bi-casted (for purposes including lawful intercept), but I think we can exclude those for now, and I think OsmoBSC currently doesn't advertise support for those anyway. LCLS needs a way to generate unique call references which are a) unique in the sense that the number space is divided between each element that generates GCRs and hence no two elements would ever end up generating identical GCRs b) signaling for *both legs of each call* have to contain that same, globally unique call reference. "elements" is basically anything that could/would ever initiate a call, so basically MSCs or any other switches (SIP or ISUP or whatever). It's needed if you want to locally switch media for calls whose both legs aren't handled by the same MSC. This includes more complex scenarios such as inbound roaming in classic networks. I strongly suggest to read the 3GPP LCLS specs, they have nice, colorful diagrams of all those use cases. I don't think it's what we're looking at in this discussion for now, but maybe only at a later step. Who takes those kinds of decisions? the central switch in the datacenter? If yes, then we'd need some SIP based signaling to switch the (downlink) media plane [temporarily] back to the core. LCLS permits for that, it's just that we have to implement those bits in OsmoMSC and osmo-sip-connector. I don't know the details of how 3GPP specified this for SIP, but I saw there are SIP related parts among those LCLS specs. -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

Hi all, Hi there, I'm listening. ; ) So are we trying to use OsMux for calls on different MSCs using SIP, right? So I should concentrate on making osmo-mgw, osmo-msc and osmo-sip-connector play nicelly with OsMux and SIP? Btw, why SIP if we can still use MGCP to control the media plane with OsMux multiplex? Cheers, Rafael Diniz