Hi community!
I'd like here to set out a few issues that we have identified for going forward with the rhizomatica autonomous networks and the osmocom split stack.
Some of this has been very briefly discussed between myself and Pablo, and I bring it to the mailing list so hopefully there will be feedback, ideas and suggestions :)
I am cherry picking from previous emails here, (mostly mine) please excuse any repetition. I hope others will post their previous comments on this thread, either verbatim of edited to be relevant to the current discussion.
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!
One option to use osmux from autonomous community (village) is to teach osmo-mgw to speak osmux, then we have a co-located bsc/msc/mgw in the village, and the media transport is osmux to another mgw in our datacentre that is demuxing and converting to RTP suitable to be forwarded to our upstream VoIP provider. The question here is what is signalling the MGW in the data centre?
Maybe another freeswitch could signal the osmoMGW via some kind of SIP<->MGCP translator. Or we teach the MGW to speak SIP?
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 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 looked some implementations of AMR codec for freeswitch, and really it looks like a boiler plate codec with registration, setup and then it calls the encoding and decoding functions in the opencore amr library.
Maybe, we can do the same with osmux? Then we could have two freeswitchs signalling and transcoding to/from osmux? - then we are not really working on osmo solution and others in the osmo community might prefer to see osmux fully implemented in MGW before anything else?
Here are a number of related tickets from Harald on osmux integration: http://osmocom.org/issues/1683 and http://osmocom.org/issues/2832 as well as https://osmocom.org/issues/2909
I think though, that in 1683, we are stalled by https://osmocom.org/issues/2391 for the split setup.
2) Another question relates to this proposal of a media gateway less mode:
https://osmocom.org/issues/3142
I think this suits us, because really our call signalling is all happening in freeswitch and we would prefer I think not to have the media gateway at all most of the time. and in fact for local Mobile to Mobile calls on the same BTS, we would in fact prefer the RTP be local on the sysmobts, or indeed BTS<->BTS! Freeswitch has a "bypass media" parameter, in fact you can even activate this at call processing time before bridging the call, depending on whether it makes sense in terms of direct connection being possible and the lack of transcoding. There's also a "bypass media after bridge" parameter that is automatically using SIP (re)-INVITES to switch the RTP stream from passing through freeswitch or going directly from end point to end point.
Using "bypass media" in our profile works nicely; of course, as all it is doing is using the IP address(es) of the osmo-bts in the SDP, so the rtp stream loops on lo in the sysmobts. It would help with something that I mentioned at Osmodevcon, Harald, which was that in some cases we might like to avoid having our RTP go over the (sometimes variable quality) Wifi links between the BTS and the BSC.
A problem is that if you use "bypass media" you have no early media and no audible ringing signal, you don't get any audio stream until the B leg picks up. This is what "bypass media after bridge" is for. Unfortunately, osmo-nitb (at least, and I don't believe anything has been done in osmo-bsc related) plus LCR or osmo-sip-connector combinations do not react correctly to the SIP reINVITES, you end up with multiple calls. So all that needs to be fixed / implemented.
I noticed mention of implementation of MNCC_RTP_MODIFY on fairwaves branches of OpenBSC and LCR. I've compiled and tested this, but as far as I can see it is still not working, as issuing a SIP reINVITE from freeswitch is still setting up new calls, not just changing the RTP streams. Maybe I also need a fairwaves osmo-bts.
So this is something I think I would like to see:
* Full support for SIP reinvite in osmo-sip-connector which would then send a MNCC_RTP_MODIFY which ends up sending (I think it's called a IPAC_CRCX?) to osmo-bts which will then switch the stream endpoints. This I believe is also necessary for handover to function with an MNCC socket setup and we don't currently have it, not even in the osmo-nitb.
* 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.
K/
On Thu, Sep 06, 2018 at 03:32:00PM +0200, Keith Whyte wrote:
was that in some cases we might like to avoid having our RTP go over the (sometimes variable quality) Wifi links between the BTS and the BSC.
Reminds me of the LCLS feature recently implemented -- Local Call Local Switch. I think the idea of LCLS is to take out the MSC's MGW, and instructing the BSC's MGW to loop directly back to the BTS. But I guess it's only a tiny step from there to switching BTS directly back to BTS. osmo-bsc has full control over that.
A problem is that if you use "bypass media" you have no early media and no audible ringing signal
IIUC LCLS happens after bridge. IIUC we instruct the MS to generate a ringing signal anyway?
- Full support for SIP reinvite in osmo-sip-connector which would then
send a MNCC_RTP_MODIFY which ends up sending (I think it's called a IPAC_CRCX?) to osmo-bts which will then switch the stream endpoints.
IPAC_CRCX is a CReate ConneXion, I think you mean IPAC_MDCX, a MoDify. In the MDCX you can tell the BTS where to send its RTP stream.
Feels wrong to me to let osmo-sip-connector mess around with the BTS' IPAC_MDCX, I think that's firmly osmo-bsc's realm. And sounds like LCLS is the thing.
As so often LaF0rge will know a lot more about it...
- 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.
Currently we need an MGW both from MSC and from BSC. Again it seems to me LCLS is the answer to take out the MSC's MGW, and osmo-bsc's LCLS decision might then end up bypassing the BSC's MGW, if it doesn't do that yet?
I think osmo-msc doesn't support LCLS though, only osmo-bsc? And also I think the MSC doesn't need to do much for LCLS anyway.
But before I ramble on about things I'm not sure about, I'm shutting up now.
~N
Hi Neels,
On Fri, Sep 07, 2018 at 02:27:27AM +0200, Neels Hofmeyr wrote:
Reminds me of the LCLS feature recently implemented -- Local Call Local Switch. I think the idea of LCLS is to take out the MSC's MGW, and instructing the BSC's MGW to loop directly back to the BTS. But I guess it's only a tiny step from there to switching BTS directly back to BTS. osmo-bsc has full control over that.
LCLS actually doesn't specify how far you go inside the RAN. We chose to simply keep the stream local to the BSC's MGW as this was simple and matched the requirements at the time. As stated before, it's just some additional logic inside osmo-bsc to take the BSC-MGW out of the local loop entirely.
IIUC LCLS happens after bridge.
ack.
IIUC we instruct the MS to generate a ringing signal anyway?
Yes, but it's known that not all phones really like to do that, in violation of the GSM specs.
Feels wrong to me to let osmo-sip-connector mess around with the BTS' IPAC_MDCX, I think that's firmly osmo-bsc's realm. And sounds like LCLS is the thing.
Agreed.
Currently we need an MGW both from MSC and from BSC. Again it seems to me LCLS is the answer to take out the MSC's MGW, and osmo-bsc's LCLS decision might then end up bypassing the BSC's MGW, if it doesn't do that yet?
It doesn't do that last step, but it's just some additional logic inside the BSC to do that.
I think osmo-msc doesn't support LCLS though, only osmo-bsc? And also I think the MSC doesn't need to do much for LCLS anyway.
It's correct that osmo-bsc implements LCLS, but osmo-msc doesn't enable LCLS yet. See https://osmocom.org/issues/2487
But indeed, all that's needed in osmo-msc is: * generate a global call reference for each call, include it in the BSSMAP signaling * permit the BSC to use LCLS (expressed in BSSMAP signaling)
From that point onwards, the work entirely focuses around the logic if and when you would
like to permit LCLS, or break LCLS again, etc. - and that depends on your use cases.
The basic use case "switch locally whenever possible" is very easy to achieve. Also, a simple use case "switch locally only after the CC CONNECT" is equally easy to achieve, and that way you get your ringtone from the core network.
If you want to switch it on and of conditionally at whatever other points during a call, more logic is needed. But I think this is not Rhizomatica's use case, is it?
There are 3GPP specs how LCLS paramters are signaled via SIP. This is what is used in "real" LCLS-using GSM networks between the MSCs. The specs should be referenced from https://osmocom.org/projects/cellular-infrastructure/wiki/Local_Call_Local_S...
But I don't think we need to go there. The "basic use case" should be sufficient.
The hard problem, as stated in my other mail, is how to signal OSMUX, and how to handle this in the existing notion/data model/... of SIP implementations on how the media plane works.
On 07.09.2018 10:27, Harald Welte wrote:
Hi Neels,
On Fri, Sep 07, 2018 at 02:27:27AM +0200, Neels Hofmeyr wrote:
Reminds me of the LCLS feature recently implemented -- Local Call Local Switch. I think the idea of LCLS is to take out the MSC's MGW, and instructing the BSC's MGW to loop directly back to the BTS. But I guess it's only a tiny step from there to switching BTS directly back to BTS. osmo-bsc has full control over that.
LCLS actually doesn't specify how far you go inside the RAN. We chose to simply keep the stream local to the BSC's MGW as this was simple and matched the requirements at the time. As stated before, it's just some additional logic inside osmo-bsc to take the BSC-MGW out of the local loop entirely.
OK. So we could compare codecs and endpoints and make a switching decision for internal BTS media?
IIUC LCLS happens after bridge.
ack.
IIUC we instruct the MS to generate a ringing signal anyway?
Yes, but it's known that not all phones really like to do that, in violation of the GSM specs.
Yep. I noticed that :-/
Feels wrong to me to let osmo-sip-connector mess around with the BTS' IPAC_MDCX, I think that's firmly osmo-bsc's realm. And sounds like LCLS is the thing.
Agreed.
Currently we need an MGW both from MSC and from BSC. Again it seems to me LCLS is the answer to take out the MSC's MGW, and osmo-bsc's LCLS decision might then end up bypassing the BSC's MGW, if it doesn't do that yet?
It doesn't do that last step, but it's just some additional logic inside the BSC to do that.
I think osmo-msc doesn't support LCLS though, only osmo-bsc? And also I think the MSC doesn't need to do much for LCLS anyway.
It's correct that osmo-bsc implements LCLS, but osmo-msc doesn't enable LCLS yet. See https://osmocom.org/issues/2487
But indeed, all that's needed in osmo-msc is:
- generate a global call reference for each call, include it in the BSSMAP signaling
In the case of a SIP originated call, you will get a uniq call ref there. Just wondering if there would be any reason to have it passed over the MNCC?
The basic use case "switch locally whenever possible" is very easy to achieve. Also, a simple use case "switch locally only after the CC CONNECT" is equally easy to achieve, and that way you get your ringtone from the core network.
If you want to switch it on and of conditionally at whatever other points during a call, more logic is needed. But I think this is not Rhizomatica's use case, is it?
We do play back "You're credit is about to expire" messages. We would have to switch the stream back to do that. We could just hang up I suppose, but that's not so nice for the user.
On Fri, Sep 07, 2018 at 11:54:53AM +0200, Keith wrote:
On 07.09.2018 10:27, Harald Welte wrote:
On Fri, Sep 07, 2018 at 02:27:27AM +0200, Neels Hofmeyr wrote:
Reminds me of the LCLS feature recently implemented -- Local Call Local Switch. I think the idea of LCLS is to take out the MSC's MGW, and instructing the BSC's MGW to loop directly back to the BTS. But I guess it's only a tiny step from there to switching BTS directly back to BTS. osmo-bsc has full control over that.
LCLS actually doesn't specify how far you go inside the RAN. We chose to simply keep the stream local to the BSC's MGW as this was simple and matched the requirements at the time. As stated before, it's just some additional logic inside osmo-bsc to take the BSC-MGW out of the local loop entirely.
OK. So we could compare codecs and endpoints and make a switching decision for internal BTS media?
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.
But indeed, all that's needed in osmo-msc is:
- generate a global call reference for each call, include it in the BSSMAP signaling
In the case of a SIP originated call, you will get a uniq call ref there.
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).
Just wondering if there would be any reason to have it passed over the MNCC?
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.
The basic use case "switch locally whenever possible" is very easy to achieve. Also, a simple use case "switch locally only after the CC CONNECT" is equally easy to achieve, and that way you get your ringtone from the core network.
If you want to switch it on and of conditionally at whatever other points during a call, more logic is needed. But I think this is not Rhizomatica's use case, is it?
We do play back "You're credit is about to expire" messages. We would have to switch the stream back to do that.
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.
On 07/09/18 13:29, Harald Welte wrote:
On Fri, Sep 07, 2018 at 11:54:53AM +0200, Keith wrote:
We do play back "You're credit is about to expire" messages. We would have to switch the stream back to do that.
Who takes those kinds of decisions? the central switch in the datacenter?
The local switch in the village. Each local village is totally autonomous in terms of supporting local calls. So the local freeswitch has to take care of this.
(in reality, if there's no IP uplink, then there is no chargable call either, but never mind that, point is we don't have any centralised switch.)
If yes, then we'd need some SIP based signaling to switch the (downlink) media plane [temporarily] back to the core.
Yes, that would be the SIP re-INVITE. This is kind of what I was talking about before. in the freeswitch console, one can just type media_uuid + [uuid of the call] to switch the media in and out of bypass mode. FS then send an INVITE and SDP with the updated ip/port currently, osmo-sip-connector (and LCR + nitb and the fairwaves versions that are supposed to work but I could not get it to work), do not respond correctly and you end up with new call setup and chaos.
LCLS permits for that, it's just that we have to implement those bits in OsmoMSC and osmo-sip-connector.
Right.. I hoped to gain something from the nitb stuff to port, but looks like not, so that would be a good part of this to table for getting done then.
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.
- 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. 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.
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. 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.
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.
I looked some implementations of AMR codec for freeswitch, and really it looks like a boiler plate codec with registration, setup and then it calls the encoding and decoding functions in the opencore amr library.
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
Here are a number of related tickets from Harald on osmux integration: http://osmocom.org/issues/1683 and http://osmocom.org/issues/2832 as well as https://osmocom.org/issues/2909
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.
- Another question relates to this proposal of a media gateway less mode:
https://osmocom.org/issues/3142
I think this suits us, because really our call signalling is all happening in freeswitch and we would prefer I think not to have the media gateway at all most of the time. and in fact for local Mobile to Mobile calls on the same BTS, we would in fact prefer the RTP be local on the sysmobts, or indeed BTS<->BTS! Freeswitch has a "bypass media" parameter, in fact you can even activate this at call processing time before bridging the call, depending on whether it makes sense in terms of direct connection being possible and the lack of transcoding. There's also a "bypass media after bridge" parameter that is automatically using SIP (re)-INVITES to switch the RTP stream from passing through freeswitch or going directly from end point to end point.
Using "bypass media" in our profile works nicely; of course, as all it is doing is using the IP address(es) of the osmo-bts in the SDP, so the rtp stream loops on lo in the sysmobts. It would help with something that I mentioned at Osmodevcon, Harald, which was that in some cases we might like to avoid having our RTP go over the (sometimes variable quality) Wifi links between the BTS and the BSC.
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.
So this is something I think I would like to see:
- Full support for SIP reinvite in osmo-sip-connector which would then
send a MNCC_RTP_MODIFY which ends up sending (I think it's called a IPAC_CRCX?) to osmo-bts which will then switch the stream endpoints. This I believe is also necessary for handover to function with an MNCC socket setup and we don't currently have it, not even in the osmo-nitb.
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.
- 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. 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
On 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.
- 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
:)
Hi all,
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)
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
Because SIP is the one manage to voice gateway via osmo-sip-connector,
Correct me if im wrong.
On Tue, Sep 11, 2018, 20:07 Rafael Diniz rafael@riseup.net wrote:
Hi all,
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)
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
-
Harald Welte -
Keith -
Keith Whyte
-
Neels Hofmeyr -
Rafael Diniz -
Sandi Suhendro