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/.
Harald Welte laforge at gnumonks.orgHi Vadim,
On Tue, Aug 06, 2019 at 12:38:09AM +0700, Vadim Yanitskiy wrote:
> > * The osmo-sip-connector should ask the HLR if the number
> > exists before forwarding the call to MNCC.
>
> I don't think it's a good idea to mix call related stuff
> with subscriber management in... MNCC <-> SIP converter.
>
> The same can be done by OsmoMSC on receipt of MNCC_SETUP_REQ,
> so if a subscriber is not in the VLR's cache, it would send
> OSMO_GSUP_MSGT_SEND_SUBSCR_INFO_REQ (not implemented) to the
> OsmoHLR, and respond to OsmoSIPCon depending on the result.
This is an interesting idea, though one would have to think
more about what kind of implications this has in terms of staying
as compatible as possible with what happens in MAP based traditional
networks. In the end, whatever we do should be "easily translateable"
to the MAP+ISUP domain, if ever needed.
There are many possible configurations, such as:
1) Full Osmocom CNI networks wanting to interact with external
entities / the SIP world
2) OsmoMSC with a GSUP-DIAMETER or GSUP-MAP converter attached
to a real HLR/HSS.
I don't think we have to consider non-Osmocom MSC with OsmoHLR, as that
doesn't make sense (we don't speak MAP and don't do most of what people
would exect from a real HLR
Lucikily, the RAN doesn't impact any of this, so it doesn't matter
whwether the BSC/RNC/HNBGW attached to the MSC is Osmocom or
non-Osmocom.
> > * There may be more than one MSC, in which case the HLR
> > would inform osmo-sip-connector about which MSC to use.
>
> In commercial networks this problem is solved by the gateway
> MSC, which is a kind of entry point for all mobile-terminated
> connections.
Well, only for MT calls arriving either via ISUP or SIP[-I], not
really for anything else. Not for SMS, not for MAP signaling.
> In Osmocom CNI we decided to turn the HLR into a
> kind of gateway for USSD and SMS, so it's responsible for the
> further routing to the target MSC.
This is natural as both USSD and SMS are transported over GSM signaling
plane and hence MAP in traditional networks.
It doesn't mean that this has to be the same for call control.
> We may probably want to encapsulate MNCC protocol into GSUP,
> like we do for SS/USSD (MAP payload) and SMS (SM TPDU), so
> OsmoHLR would take care about routing between the MSCs. This
> would require adding one more message type, similar to
> SS/USSD - OSMO_GSUP_MSGT_PROC_MNCC_{REQ,RES,ERR}.
I really don't like that idea, sorry. Way too far from how 3GPP
networks work.
> But then, again, we would have to overload the HLR with call
> related stuff, what is probably even worse than overloading
> OsmoSIPCon with subscriber management...
What about a dedicated G-MSC process as I suggested in my other mail?
Regards,
Harald
--
- Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)