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/.
Vadim Yanitskiy axilirator at gmail.comHi Keith, Neels, Harald,
> * 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.
> * 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. 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.
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}.
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...
> [...] sip-connector talks to HLR, and has multiple connections
> to MSCs (UDP then, not Unix Socket?)
Rather TCP then. We already have OsmoTRXC (Control protocol)
working over UDP, so we have to deal with retransmissions
ourselves. We can lose a burst, or we can lose an RTP frame,
but losing call related messages is critical IMHO.
With best regards,
Vadim Yanitskiy.