Hi all,
Doing some testing recently with osmo-sip-connector, I noticed a few things that seem to be important regarding the user experience of a network with osmo-sip-connector.
* The osmo-sip-connector is an external MNCC handler interface for one MSC. The MSC doesn't have any information about what is in the HLR.
When the osmo-sip-connector sends a call towards the MSC, the msc does a VLR lookup: vlr_subscr_find_by_msisdn() in gsm_04_08_cc.c around line 1860.
if that returns false we are doing mncc_release_ind() with GSM48_CC_CAUSE_UNASSIGNED_NR. That is getting translated into a SIP 404, which informs the caller that the number was not found. Logical but it's not correct if the subscriber does actually exist in the HLR.
Actually the same problem exists when using the internal MNCC, If you call a subscriber that has just switched off their phone, you'll get an Un Assigned Number error cause. That would be incredibly confusing for the users. In rhizomatica's case, the audio played back to the caller would be "The number you have dialed does not exist, please verify it", while it should obviously be "The number you have dialed is temporarily unavailable, please try again later."
What we have done there is send the caller to go physically ask ask the callee why they canceled their phone service, when all they did was switch off the phone.
SO:
There was some discussion about this at the devcon, I want to outline some points here, hopefully I understand it right.
* The osmo-sip-connector should ask the HLR if the number exists before forwarding the call to MNCC.
* 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?
and then.. still a doubt:
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" ?
thanks!
k/
On Mon, Aug 05, 2019 at 04:27:56PM +0200, Keith wrote:
a) one osmo-sip-connector per SIP UA, sip-connector talks to HLR, and has multiple connections to MSCs (UDP then, not Unix Socket?)
Changing to an IP protocol reminds me of jolly's proposal we talked about in december, a kind of all-new osmo-sip-connector-and-more called osmo-cc. Can't seem to find a mail reference to that ATM...
I haven't heard about it since December, but even if nothing has happened, would probably be worthwhile to take a look at the protocol that jolly already has mapped out in pretty high detail.
The point is that the unix domain socket connection can take assumptions that the other side is on the same CPU and simply dump (packed) data structs into it, being sure that they come out intact on the other side. If we're talking UDP there should instead be a well defined protocol involved to properly encode and decode different sized integers (and so on and so on). Simply pasting the current mncc structs into UDP would be a pretty bad hack that is guaranteed to be unportable.
Related, if I'm going to incorporate proper SDP codec negotiation in the osmo-sip-connector, I should probably keep that modularly separated from the unix domain socket protocol, and we should coordinate with this idea.
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" ?
Yes, these are leftovers of the OsmoNITB paradigm, being "I am the entire core network". If a subscriber isn't attached, it doesn't exist. You are right that there should be a distinction between "exists" and "is currently attached", and the latter part is simply not implemented. I'm currently not sure what 3GPP spec'd mechanisms the MSC or VLR have to query the mere existence of an unattached MSISDN, but you're correct to assert that that is missing.
~N
On Mon, Aug 05, 2019 at 06:30:14PM +0200, Neels Hofmeyr wrote:
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" ?
Yes, these are leftovers of the OsmoNITB paradigm, being "I am the entire core network". If a subscriber isn't attached, it doesn't exist.
Let me rephrase: back then the subscriber database was in the OsmoNITB and non-attached subscribers did exist. The inability to recognise unattached subscribers as existing crept in during the separation of the HLR.
~N
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
Hi 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.
Hi Vadim,
On Tue, Aug 06, 2019 at 12:38:09AM +0700, Vadim Yanitskiy wrote:
- 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.
This is an interesting idea, though one would have to think more about what kind of implications this has in terms of staying as compatible as possible with what happens in MAP based traditional networks. In the end, whatever we do should be "easily translateable" to the MAP+ISUP domain, if ever needed.
There are many possible configurations, such as:
1) Full Osmocom CNI networks wanting to interact with external entities / the SIP world
2) OsmoMSC with a GSUP-DIAMETER or GSUP-MAP converter attached to a real HLR/HSS.
I don't think we have to consider non-Osmocom MSC with OsmoHLR, as that doesn't make sense (we don't speak MAP and don't do most of what people would exect from a real HLR
Lucikily, the RAN doesn't impact any of this, so it doesn't matter whwether the BSC/RNC/HNBGW attached to the MSC is Osmocom or non-Osmocom.
- 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.
Well, only for MT calls arriving either via ISUP or SIP[-I], not really for anything else. Not for SMS, not for MAP signaling.
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.
This is natural as both USSD and SMS are transported over GSM signaling plane and hence MAP in traditional networks.
It doesn't mean that this has to be the same for call control.
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}.
I really don't like that idea, sorry. Way too far from how 3GPP networks work.
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...
What about a dedicated G-MSC process as I suggested in my other mail?
Regards, Harald
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/
-
Harald Welte -
Keith -
Neels Hofmeyr -
Vadim Yanitskiy