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/.
Keith keith at rhizomatica.orgOn 07.09.2018 10:15, Harald Welte wrote: > Hi Keith, > > > The bigger problem is how to *signal/* osmux between the various elements. > > > 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. 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 ? > > 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), 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) :-/ > 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 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. > >> 1) This is a question that relates to voip traffic in and out of the >> autonomous communities over satellite. >> >> Currently this is what we HAVE to have in the local village to support >> autonomous operation): >> * BSC >> * MSC >> * HLR >> * Freeswitch (freeswitch is our call control, call routing, billing etc) >> >> We can't have any essential backhaul running over the satellite , like A >> for example as we would loose all functionality when the sat link is >> down, and we'd burn expensive bandwidth! > I'm not sure about the "burning of expensive bandwidth" in an "A > backhaul" scenario. 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. >> Maybe another freeswitch could signal the osmoMGW via some kind of >> SIP<->MGCP > translator. Or we teach the MGW to speak SIP? > a media gateway is (as the name implies) not a signaling gateway. 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. > 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. > >> Another option that I want to put on the table and see what people say >> is to look at implementing osmux as a codec in freeswitch. > 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. 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 > >> I don't know what that would mean in terms of effort. >> I don't know if the osmux code can be abstracted, if that is the right >> term, into it's >> own external includible library that could then be used to build a >> freeswitch codec. > 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. 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. >> I think though, that in 1683, we are stalled by >> https://osmocom.org/issues/2391 for the split setup. > 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. 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. > 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. 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 > >> * Implement a no media gateway mode in osmo-msc and have the MSC control >> the media stream using SIP via MNCC/osmo-sip-connector instead of >> controlling the MGW using MGCP. > Possible, but I don't think this is advisable. It's violating layering > / network architecture all over the place. 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. > > 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". 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) > > Regards, > Harald :)