interfacing core network to SIP world

[Keith]

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/