5 Aug
2019
5 Aug
'19
5:27 p.m.
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/
5 Aug
5 Aug
7:30 p.m.
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
10:40 p.m.
On Mon, Aug 05, 2019 at 06:30:14PM +0200, Neels Hofmeyr wrote:
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
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. 
8:11 p.m.
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)
8:38 p.m.
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.
10:05 p.m.
Hi Vadim,
On Tue, Aug 06, 2019 at 12:38:09AM +0700, Vadim Yanitskiy wrote:
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.
Well, only for MT calls arriving either via ISUP or SIP[-I], not
really for anything else. Not for SMS, not for MAP signaling.
* 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.
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
--
- 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)
10:50 p.m.
On 05/08/2019 19:11, Harald Welte wrote:
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?
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.
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.
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/
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.
1779
days inactive
1779
days old
6 comments
4 participants
participants (4)
-
Harald Welte -
Keith -
Neels Hofmeyr -
Vadim Yanitskiy