OsMux + MGW + SIP

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 Whyte keith at rhizomatica.org
Thu Sep 6 13:32:00 UTC 2018


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/

 







More information about the OpenBSC mailing list