On 05/08/2019 19:11, Harald Welte wrote:
Hi Keith,
thanks for getting this discussion started!
:)
[I don't recall participating in that discussion,
It was somewhat informal.
* 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.
In the rhizomatica world, the call arrives at the PBX, (freeswitch in
our case), on the "external" profile.
The simplest thing freeswitch can do is to just bridge the call to the
"internal" profile - the one facing the osmo-sip-connector, but in
between we do checking of the numbers, transcoding, accounting etc..
In our case, what freeswitch does is to call a python script which
ultimately tells freeswitch where to bridge the call to.
I see I'm getting a bit specific to rhizomatica use case, but do we have
a python GSUP client?
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?)
This python could be our G-MSC. it could ask the HLR for the MSRN, or
indeed do some funky ARP-style broadcast lookups that were discussed at
one point, and based on that, do as you say:
* forward the SIP INVITE to the MSC-colocated
osmo-sip-connector
but this G-MSC inside python, inside freeswitch would not have to store
the INVITE, but rather find out what the IP address is and then just
send this info back to freeswitch.
So yes, this creates a need to have some kind of PBX that's capable of
running scripts in between the SIP "world" and the osmo-sip-connector
but I do wonder sometimes about whether we should try to make something
that's going to be SIP facing that is expected to handle everything a
SIP UA might throw at it, given that there are already many tools out
there that one can (and probably wants to) use to help bridge SIP to the
core network.
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,
I don't think so. I may not have the right terminology here but I'm
pretty sure SIP is stateless.
(I restart kamailio all the time and it does not affect ongoing calls)
An in-dialog message can come from anywhere, as long as it has the
headers that identify the Call-ID.
I think this is what the Contact: header is for.
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.
Ah, I see. so that would be an
in-transaction request, and I'm not sure
about that being able to come from a different IP.
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.
OK, I think I'm already talking about too many things to also comment on
this case.
I think Vadim has an interesting proposal to deal with the MO case.
k/