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 Keith,
thanks for getting this discussion started!
On Mon, Aug 05, 2019 at 04:27:56PM +0200, Keith wrote:
> There was some discussion about this at the devcon, I want to outline
> some points here, hopefully I understand it right.
[I don't recall participating in that discussion, so my feedback is
just general in terms of "this is how it's supposed to be"]
> * The osmo-sip-connector should ask the HLR if the number exists before
> forwarding the call to MNCC.
ACK. In the MAP world, the external call arrives at the G-MSC which
then sends a "SendRoutingInfo" message to the HLR, which responds with
all kinds of data, but most importantly the IMSI and the MSRN. The MSRN
is a temporarily-allocated (land line) phone number at the MSC serving the
subscriber.
And before the HLR can return the MSRN, it requests that MSRN from the
VLR/MSC (using the PROVIDE_ROAMING_NR request). See Section 21.2.1 of
3GPP TS 29.002 for the detailed ladder diagram. Steps 3..6 are
optional, so it's 1 (IAM == INVITE) /2/7/8/9
> * There may be more than one MSC, in which case the HLR would inform
> osmo-sip-connector about which MSC to use.
>
> * The osmo-sip-connector could either be SIP associated, or MSC
> associated, that is to say:
>
> a) one osmo-sip-connector per SIP UA, sip-connector talks to HLR, and
> has multiple connections to MSCs (UDP then, not Unix Socket?)
>
> or
>
> b) one osmo-sip-connector per MSC, in which case the SIP UA would have
> to somehow query the HLR to ask where to send the call.
>
> Does that all sound correct?
It all sounds correct to me. Given that MNCC is a local unix domain
socket interface, osmo-sip-connector always has to be MSC-colocated. So
I'm for option 'b'.
We'd basically need a new instance which plays the role of the G-MSC:
* receive the SIP INVITE, temporarily store it
* ask HLR which VLR/MSC is serving that MSISDN
* wait for HLR to return IMSI + MSRN (or rather in our case, instead of
MSRN maybe in our case the IP address of the osmo-sip-connector
serving that MSC/VLR?)
* forward the SIP INVITE to the MSC-colocated osmo-sip-connector
Not sure if it would have to sit in between the extenal SIP UA and
osmo-sip-connector for the remaining duration of the call, or if it's
possible in SIP that the response to the INVITE is originating from
a different IP/Port than the INVITE was sent to. Probably it's
possible in theory, but it will confuse the hell out of other
implementations and/or state-tracking firewalls, NAT, etc.
> IIUC, in the traditional core network. When an MSC receives a MO SETUP
> from a local MS, and it does not have this number in the VLR, it should
> be querying HLR for routing info, (which may subsequently query another
> HLR) no? why are we only doing VLR lookup in the MSC? Is it simply "To
> be implemented" ?
What happens in a traditional core network is that the call will
be routed like any other land-line (non-mobile) phone call. So
basically the IW-MSC (the MO counterpart of the G-MSC) will use the
SS7/ISUP or SIP network to tr to route the call to the "B" subscriber.
If that subscriber happens to be another mobile subscriber, it will end
up at the G-MSC of that B-network, and the MT procedure described above
will happen inside the B network.
So, if we implement the G-MSC functionality that you originally
described, we should get that part solved, too.
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)