Hi 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(a)gnumonks.org>
http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)