Hi Oliver,
I've already spent some time on a first draft for the new messages we will need to implement the E-interface via GSUP for inter-MSC handover. It would be excellent if you could take over from what I have so far.
I placed the draft in osmo-msc/doc/interMSC_HO_GSUP_msgs.txt on my branch neels/ho: http://git.osmocom.org/osmo-msc/tree/doc/interMSC_HO_GSUP_msgs.txt?h=neels/h...
Anyone else is also more than welcome to take a look and remark on anything that might seem a bad idea, etc.
This is the result of me reading a MAP trace of two MSCs negotiating inter-MSC handovers, and of reading the 29.002, 29.010,... specs. I'm not permitted to freely share the trace, let me know if you need details.
The most interesting bits in the draft are
- the new message types - the newly added IEs (see "Of which are newly added...")
The tasks for you would be:
- Spell out the protocol messages in common/chapters/gsup.adoc - Implement the definitions in gsup.h - Implement encoding and decoding, and tests
It is not so trivial to understand what goes with which message; maybe you don't even need to know in detail? But if any info is still missing for you to grok what's going on, don't hesitate to ask, as always.
Also interesting to figure out: Implement the IPA routing for which I added the source_name and destination_name IEs: N osmo-mscs connected to one osmo-hlr forward messages to each other via GSUP.
- Connect two GSUP clients (test programs?) to a running osmo-hlr instance, and to extend the gsup_server so that we can use the source_name/destination_name IEs to forward GSUP messages between the two clients. (I added these because I'm fairly certain there is no existing in-band IPA protocol bits that would allow such routing; but I only briefly skimmed it, wouldn't hurt if you could verify that again.) The aim is to have plain gsup_client API to allow me to "just send messages back and fort".
- The session_id/session_state: we still need to figure out how to avoid collisions in session_id numbers, as any peer may at any point re-use the same session_id. Vadim suggested using a TI flag that gets flipped between sender and receiver, but since there are more than two peers, I guess we should treat each session_id as subordinate to a Request's source_name. IOW, any peer owns the entire session_id number space itself for sending out Request message types, and a Response or Error message type echos this session_id back with the source_name then having become the destination_name; it is perfectly legal for two peers to use the same session_id and collisions are avoided by Request vs. Response/Error. Something like...
MSC-A MSC-B MSC-B' -------> FOO_REQUEST(source=alice, destination=bob, id=3, state=BEGIN) <------- FOO_RESPONSE(source=bob, destination=alice, id=3, state=CONTINUE) -------> BAR_REQUEST(source=alice, destination=bob, id=3, state=CONTINUE) <------- BAR_RESPONSE(source=alice, destination=bob, id=3, state=CONTINUE) ---------------> FOO_REQUEST(source=alice, destination=fred, id=4, state=BEGIN) <--------------- FOO_ERROR(source=fred, destination=alice, id=4, state=CONTINUE) ---------------> END_REQUEST(source=alice, destination=fred, id=4, state=END) -------> END_REQUEST(source=alice, destination=bob, id=3, state=END)
(We could possibly omit the source_name in Response/Error message types, because the Requestor already knows the peer from sending out the Request; but for sanity, maybe rather always keep both names.)
Does this make sense / am I missing something?
- And we need to make sure that we can freely re-use the session_id IE on the E-interface without conflicting with the Supplementary Services session_id / without confusing the gsup_client API.
Please create issues on osmocom.org for these tasks as you see fit.
There is no pressing need yet to get this done *right now*, I have yet to complete the inter-BSC HO in osmo-msc before I can start using GSUP. But it would be great to just build on working API once I need it.
I would be super grateful if you could relieve me of the burden of spelling out these details. From the meetings I assume that sysmocom agrees; please manage that, too, and let me know if any other tasks are more important...
Thanks!!
~N
On 1/14/19 3:03 AM, Neels Hofmeyr wrote:
There is no pressing need yet to get this done *right now*, I have yet to complete the inter-BSC HO in osmo-msc before I can start using GSUP. But it would be great to just build on working API once I need it.
Thanks for the detailed write-up! I'll get started with this once the save-IMEI-in-HLR related stuff I'm working on right now is in place (OS#2541).
Regards, Oliver
Hi Neels,
Anyone else is also more than welcome to take a look and remark on anything that might seem a bad idea, etc.
I had a brief look on your draft and have some remarks and thoughts about it (see below).
This is the result of me reading a MAP trace of two MSCs negotiating inter-MSC handovers, and of reading the 29.002, 29.010,... specs. I'm not permitted to freely share the trace, let me know if you need details.
The most interesting bits in the draft are
- the new message types
I briefly checked the operations in 29.002 (mainly whether they provide a result or not) and they seem to match your message types.
- the newly added IEs (see "Of which are newly added...")
[...]
Also interesting to figure out: Implement the IPA routing for which I added the source_name and destination_name IEs: N osmo-mscs connected to one osmo-hlr forward messages to each other via GSUP.
- Connect two GSUP clients (test programs?) to a running osmo-hlr instance, and to extend the gsup_server so that we can use the source_name/destination_name IEs to forward GSUP messages between the two clients. (I added these because I'm fairly certain there is no existing in-band IPA protocol bits that would allow such routing; but I only briefly skimmed it, wouldn't hurt if you could verify that again.) The aim is to have plain gsup_client API to allow me to "just send messages back and fort".
The following questions come to my mind while reading this:
* Why should this message router/server be part of the HLR? IMO these are completely separate things. So I'd rather put this functionality into a separate program/process.
* What about adding a separate IPA protocol id for routing (proxying might came closer for the case given), that itself just carries other IPA messages of a different type along with source/destination_name and possibly other IEs that just relate to proxying (and possibly the session stuff, unless that went to another layer)? This could then be used with every IPA protocol and won't mess with the application layer.
* What about security? Proxying will prevent conventional network monitoring tools and firewalls from working properly. Will it be possible to limit proxying to certain peers e.g. via configuration?
BTW, the source and destination name IEs correspond to the global titles in the SCCP layer of SS7. There also exist means to address a destination logically (e.g. send this to the HLR that is responsible for that IMSI, see the E.214 numbering plan).
- The session_id/session_state: we still need to figure out how to avoid collisions in session_id numbers, as any peer may at any point re-use the same session_id. Vadim suggested using a TI flag that gets flipped between sender and receiver, but since there are more than two peers, I guess we should treat each session_id as subordinate to a Request's source_name. IOW, any peer owns the entire session_id number space itself for sending out Request message types, and a Response or Error message type echos this session_id back with the source_name then having become the destination_name; it is perfectly legal for two peers to use the same session_id and collisions are avoided by Request vs. Response/Error. Something like...
To me this really sounds like re-implementing (parts of) TCAP (ITU T Q.770-779) . TCAP use transaction ids, one for every end of the 'connection' (origin and destination) where each tuple (origin, OTID) or (dest, DTID) identifies the transaction (note that in certain cases a peer can reply with a different origin, e.g. by replacing a E.214 by a E.164 GT). But TCAP is properly separated from the application layer stuff (MAP in that case).
[...]
While I like the idea to extend GSUP/IPA, I'm wondering whether at some point in the future it was better to just use the standard protocols (e.g. MAP/TCAP/SCCP, possibly on top of IPA, perhaps just MAP on IPA possibly combined with some restrictions concerning segmentation etc) instead of partly reimplementing all of them. At least I'd rather properly separate the session/proxying stuff from GSUP (still being a simplified MAP replacement).
Jacob
Many thanks for your input!
I don't really have strong opinions about any of these design questions. When extending the GSUP protocol I am mainly carrying out other people's ideas...
On Tue, Jan 15, 2019 at 01:28:42PM +0100, Jacob wrote:
- Why should this message router/server be part of the HLR? IMO these
are completely separate things. So I'd rather put this functionality into a separate program/process.
So far osmo-hlr is the GSUP server. We've already introduced the concept of osmo-hlr as a router-thing concerning USSD services, towards external USSD providers. Adding a router in-between would change the topology, sort of like we added the osmo-stp for the A and Iu interfaces. osmo-hlr would then also be a GSUP client to the router instance, and osmo-msc and osmo-sgsn would have to add routing information to reach the HLR... That's (probably) backwards incompatible, not sure if we want to open that box now.
- What about adding a separate IPA protocol id for routing (proxying
might came closer for the case given), that itself just carries other IPA messages of a different type along with source/destination_name and This could then be used with every IPA protocol and won't mess with the application layer.
Ok, that sounds like a sane idea. I wonder whether such a concept is already in use somewhere on the IPA protocol?
A drawback I see is that we currently have numerous IPA implementations flying around, IIRC in libosmocore, libosmo-netif, libosmo-sccp; and at least two in python... extending the libosmocore one would probably be enough.
possibly other IEs that just relate to proxying (and possibly the session stuff, unless that went to another layer)?
- What about security? Proxying will prevent conventional network
monitoring tools and firewalls from working properly. Will it be possible to limit proxying to certain peers e.g. via configuration?
I don't fully get the proxying idea. What's the purpose, to bridge messages for specific recipients through a NAT sort of thing?
BTW, the source and destination name IEs correspond to the global titles in the SCCP layer of SS7. There also exist means to address a destination logically (e.g. send this to the HLR that is responsible for that IMSI, see the E.214 numbering plan).
This is the first time I'm thinking about more than one HLR in Osmocom. I'm out of my depth here...
- The session_id/session_state: we still need to figure out how to avoid collisions in session_id numbers, as any peer may at any point re-use the same session_id. Vadim suggested using a TI flag that gets flipped between sender and receiver, but since there are more than two peers, I guess we should treat each session_id as subordinate to a Request's source_name. IOW, any peer owns the entire session_id number space itself for sending out Request message types, and a Response or Error message type echos this session_id back with the source_name then having become the destination_name; it is perfectly legal for two peers to use the same session_id and collisions are avoided by Request vs. Response/Error. Something like...
To me this really sounds like re-implementing (parts of) TCAP (ITU T Q.770-779) . TCAP use transaction ids, one for every end of the 'connection' (origin and destination) where each tuple (origin, OTID) or (dest, DTID) identifies the transaction (note that in certain cases a
Except that in TCAP, both sides invent an own ID for a dialogue. I'm planning to have just one ID sent back and forth, which the first Request specifies, and then remains the same from both sides.
peer can reply with a different origin, e.g. by replacing a E.214 by a E.164 GT). But TCAP is properly separated from the application layer stuff (MAP in that case). While I like the idea to extend GSUP/IPA, I'm wondering whether at some point in the future it was better to just use the standard protocols (e.g. MAP/TCAP/SCCP, possibly on top of IPA, perhaps just MAP on IPA possibly combined with some restrictions concerning segmentation etc) instead of partly reimplementing all of them.
IIUC the standard stack has quite a lot of duplicated information and is a lot more complex than GSUP/IPA, and that is precisely the idea: implement a simpler protocol with sufficient information to still allow translating into the more complex standard stack, but saving us all the gory details that we would need for the full stack.
I did not make this decision, which is probably also made on the grounds of getting something done in a reasonable time frame (this is work for a sysmocom customer).
Well, personally, I would enjoy myself more when staying with GSUP for now and keeping things as simple as possible :) (because I would rather concentrate on osmo-msc's handover code)
At least I'd rather properly separate the session/proxying stuff from GSUP (still being a simplified MAP replacement).
The session_id IE was already added for USSD. Proxying doesn't seem to be a goal at this point.
Routing messages between GSUP clients could be changed into routing messages between IPA clients. That would match well in the sense that we already send the MSC's name via IPA during the initial IPA ID exchange.
However, keeping routing within GSUP would make operations a bit simpler now, since all our patches modify just one protocol layer, and we have only one GSUP server implementation vs. the various IPA ones.
My first and final word on this is that I don't worry/care much about which way we do these things, because I personally don't have a larger scheming plan for IPA and GSUP, so I would like to hear other opinions.
Thanks again for your very interesting input!
~N
Hi!
On Tue, Jan 15, 2019 at 02:44:04PM +0100, Neels Hofmeyr wrote:
BTW, the source and destination name IEs correspond to the global titles in the SCCP layer of SS7. There also exist means to address a destination logically (e.g. send this to the HLR that is responsible for that IMSI, see the E.214 numbering plan).
This is the first time I'm thinking about more than one HLR in Osmocom. I'm out of my depth here...
The general policy is that OsmoSGSN and OsmoMSC always only talk to one GSUP server, which is [so far] OsmoHLR with its internal GSUP router.
If you want MAP connectivity, the strategy is to replace that OsmoHLR with its built-in GSUP router and swap in a GSUP-to-MAP gateway. This gateway then can do the normal E.214 translations etc.
But in a pure Osmo* setup (still the majority of our users) we want to avoid all the related complexity.
If one wanted multiple HLRs in a pure Osmo* network (like in the proposed Rhizomatica "distributed GSM"), then the GSUP router inside OsmoHLR (or some new proxy?) would have to do ISMI prefix matching and then forward the IP address of the HLR responsible for that IMSI-prefix.
Except that in TCAP, both sides invent an own ID for a dialogue. I'm planning to have just one ID sent back and forth, which the first Request specifies, and then remains the same from both sides.
I really like that. As an alternative, one could still have two identifiers but make sure they are present in all messages - like source and destination port numbers.
Hi Jacob,
great to read something from you here again. Thanks for your input!
On Tue, Jan 15, 2019 at 01:28:42PM +0100, Jacob wrote:
The following questions come to my mind while reading this:
- Why should this message router/server be part of the HLR? IMO these
are completely separate things. So I'd rather put this functionality into a separate program/process.
The HLR already contains a GSUP message router these days, which is used to route messages e.g. to "EUSE" (External USSD entities). The same is happening also for External SMS entities, as Vadim has enabled GSUP based SMS transport in OsmoMSC recently.
So yes, one can argue that the functionality is reasonably distinct and should be yet another program to run. However, as GSUP messages so far don't contain an explicit sender or recipient, OsmoHLR can perform message routing based on the IPA identities of the connected programs.
So if a LU comes from one given MSC, the IPA identity of that MSC is stored in the HLR as sort-of replacement of the global title of the MSC.
If a MO-USSD arrives at the MSC, we take a routing decision based on the USSD code and route it to an EUSE. The EUSE itself is again identified by its IPA identity as communicated over the related GSUP connection. Once the EUSE responds, we use the IMSI as lookup into the HLR database, and get the IPA identity of the MSC, to which we then route the response.
So unless we want to have an explicit "routing header" on the GSUP side, the GSUP router must be inside the HLR.
What was clear to me from the beginning is that we don't want OsmoMSC to have multiple GSUP connections and do the routing itself. The latter was proposed by Vadim, IIRC. However, this would make it only more difficult to introduce a central GSUP-to-MAP or GSUP-to-DIAMETER gateway.
- What about adding a separate IPA protocol id for routing (proxying
might came closer for the case given), that itself just carries other IPA messages of a different type along with source/destination_name and possibly other IEs that just relate to proxying (and possibly the session stuff, unless that went to another layer)? This could then be used with every IPA protocol and won't mess with the application layer.
It's an option, yes. However, we already introduced USSD and SMS over GSUP which add the SESSION_STATE and SESSION_ID, see http://git.osmocom.org/libosmocore/tree/include/osmocom/gsm/gsup.h#n182
So rather than changing everything again in an incompatible way, I think the safe approach is to add whatever needed to GSUP itself.
- What about security? Proxying will prevent conventional network
monitoring tools and firewalls from working properly. Will it be possible to limit proxying to certain peers e.g. via configuration?
I'm not sure I'm following you here.
BTW, the source and destination name IEs correspond to the global titles in the SCCP layer of SS7. There also exist means to address a destination logically (e.g. send this to the HLR that is responsible for that IMSI, see the E.214 numbering plan).
YYs. We basically thought that we'd treat the IPA ID as a binary blob, so that the HLR could potentially also simply store a SCCP-encoded GT later on, if ever required. Let's think for example some external SMSC registering itself in the waiting list to be informed once the subscriber is back online, ...
- The session_id/session_state: we still need to figure out how to avoid collisions in session_id numbers, as any peer may at any point re-use the same session_id. Vadim suggested using a TI flag that gets flipped between sender and receiver, but since there are more than two peers, I guess we should treat each session_id as subordinate to a Request's source_name. IOW, any peer owns the entire session_id number space itself for sending out Request message types, and a Response or Error message type echos this session_id back with the source_name then having become the destination_name; it is perfectly legal for two peers to use the same session_id and collisions are avoided by Request vs. Response/Error. Something like...
To me this really sounds like re-implementing (parts of) TCAP (ITU T Q.770-779) .
Ideally this is not the case. We just need the bare minimum that provides us with a separation of the indivivudal concurrent dialogues. I personally find the OTID/DTID approach of TCAP very difficult to follow, as there's normally only one of the two visible in each packet. Makes debugging hard, makes filtering in wireshark hard, ...
While I like the idea to extend GSUP/IPA, I'm wondering whether at some point in the future it was better to just use the standard protocols (e.g. MAP/TCAP/SCCP, possibly on top of IPA, perhaps just MAP on IPA possibly combined with some restrictions concerning segmentation etc) instead of partly reimplementing all of them. At least I'd rather properly separate the session/proxying stuff from GSUP (still being a simplified MAP replacement).
By now we're using (connection oriented) SCCP aleready on the AoIP interface between OsmoBSC and OsmoMSC (via OsmoSTP in between). So speaking connectionless SCCP is certainly not a problem in terms of available osmocom infrastructure.
TCAP, well, I once started a libosmo-tcap C implementation, which is still far from being complete. So lots of work would be required there.
Using "just" the MAP encoding/decoding for the messages is an option, but we'd have to standardize on one specific MAP version for each application context, and we'd have to exclude segmentation as you suggest. Also, technically there's no problem with this as MAP is using ASN.1 BER, which we can speak without any problems from Lev Walkins' asn1c.
The problem is that MAP doesn't contain the addresses (GTs) of the SCCP level, nor does it contain the session/dialogue notion of TCAP. So even if we used MAP as the inner messages, we'd still need the "routing" bits that were' talking about above. So switching to restricted-MAP-over-GSUP doesn't reduce the problem domain of SCCP+TCAP, responsible for routing and session/dialogue.
The fundamental struggle that we have is the compromise between
1) staying if possible as close as possible to the 3GPP architecture,
and
2) avoiding most of the complexities that go along with this. GSM is complex enough to set up, even without having to worry about SCCP etc. - Most of our users are not a public operator, and they have no SS7, no global titles, no point codes, etc.
We tried hard with the AoIP interface, where we introduced lots of "magic" such as dynamic routing key registratio in OsmoSTP, etc. to ensure people can run OsmoBSC and OsmoMSC without having to know and configure all those bits - while at the same time allowing those with the skills (and requirements to talk to other MSCs) to do so.
I don't think we did a perfect job on the A interface side, and I worry about introducing yet another of those interfaces.
Hi Neels,
I finally got a chance to catch up with various pending e-mails and hence this thread.
On Mon, Jan 14, 2019 at 03:03:56AM +0100, Neels Hofmeyr wrote:
I placed the draft in osmo-msc/doc/interMSC_HO_GSUP_msgs.txt on my branch neels/ho: http://git.osmocom.org/osmo-msc/tree/doc/interMSC_HO_GSUP_msgs.txt?h=neels/h...
Anyone else is also more than welcome to take a look and remark on anything that might seem a bad idea, etc.
I'm not the expert on Inter-MSC HO, but it looks fine to me, from what I know.
Also interesting to figure out: Implement the IPA routing for which I added the source_name and destination_name IEs: N osmo-mscs connected to one osmo-hlr forward messages to each other via GSUP.
- Connect two GSUP clients (test programs?) to a running osmo-hlr instance, and to extend the gsup_server so that we can use the source_name/destination_name IEs to forward GSUP messages between the two clients. (I added these because I'm fairly certain there is no existing in-band IPA protocol bits that would allow such routing; but I only briefly skimmed it, wouldn't hurt if you could verify that again.) The aim is to have plain gsup_client API to allow me to "just send messages back and fort".
the existing gsup router inside OsmoHLR already does half of the job: It checks the list of GSUP connections and can route a message by the IPA identity of the peer.
This is what's used for routing between OsmoMSC[s]s and EUSE[s].
The only difference AFAICT in this inter-msc HO scenario is that the destination identity would be read from a GSUP IE. But the actual route lookup would be just like the existing code, using gsup_route_find(), or even better: the osmo_gsup_addr_send() high level function to which you simply pass the IP identity to which you want to transmit to.
- The session_id/session_state: we still need to figure out how to avoid collisions in session_id numbers, as any peer may at any point re-use the same session_id. Vadim suggested using a TI flag that gets flipped between sender and receiver, but since there are more than two peers, I guess we should treat each session_id as subordinate to a Request's source_name. IOW, any peer owns the entire session_id number space itself for sending out Request message types, and a Response or Error message type echos this session_id back with the source_name then having become the destination_name; it is perfectly legal for two peers to use the same session_id and collisions are avoided by Request vs. Response/Error. Something like...
If that works: Great, problem solved!
(We could possibly omit the source_name in Response/Error message types, because the Requestor already knows the peer from sending out the Request; but for sanity, maybe rather always keep both names.)
It makes filtering in wireshark so much easier to have the context in every message, so please keep it.
- And we need to make sure that we can freely re-use the session_id IE on the E-interface without conflicting with the Supplementary Services session_id / without confusing the gsup_client API.
Using one common/shared allocator function inside OsmoMSC shouldn't be a problem.
Regards, Harald
On 1/14/19 3:03 AM, Neels Hofmeyr wrote:
I placed the draft in osmo-msc/doc/interMSC_HO_GSUP_msgs.txt on my branch neels/ho: http://git.osmocom.org/osmo-msc/tree/doc/interMSC_HO_GSUP_msgs.txt?h=neels/h...
In your draft, you describe the handover_number IE like this:
handover_number: (MSC-A <-- MSC-B, Handover Request Ack) extension: [Extension=0|NoExtension=1] (1 bit; should currently always be == 1) nature_of_nr: [GSM340_TYPE_NATIONAL|GSM340_TYPE_INTERNATIONAL|...] (3 bit) number_plan: GSM340_PLAN_ISDN (4 bit) msisdn: BCD
GSUP already has a msisdn IE:
https://git.osmocom.org/libosmocore/tree/include/osmocom/gsm/gsup.h?id=ae796... Can we use that, and simplify the handover_number to only have extension, nature_of_nr and number_plan?
Thanks, Oliver
Hi Oliver,
On Tue, Feb 05, 2019 at 10:34:04AM +0100, Oliver Smith wrote:
On 1/14/19 3:03 AM, Neels Hofmeyr wrote:
I placed the draft in osmo-msc/doc/interMSC_HO_GSUP_msgs.txt on my branch neels/ho: http://git.osmocom.org/osmo-msc/tree/doc/interMSC_HO_GSUP_msgs.txt?h=neels/h...
In your draft, you describe the handover_number IE like this:
handover_number: (MSC-A <-- MSC-B, Handover Request Ack) extension: [Extension=0|NoExtension=1] (1 bit; should currently always be == 1) nature_of_nr: [GSM340_TYPE_NATIONAL|GSM340_TYPE_INTERNATIONAL|...] (3 bit) number_plan: GSM340_PLAN_ISDN (4 bit) msisdn: BCD
GSUP already has a msisdn IE:
https://git.osmocom.org/libosmocore/tree/include/osmocom/gsm/gsup.h?id=ae796... Can we use that, and simplify the handover_number to only have extension, nature_of_nr and number_plan?
I would argue we should introduce a new "global title" IE which contains * BCD digits * nature of address / type of number * numbering plan indicator
This would basically correspond to a SCCP global title, see osmo_sccp_gt in sccp_sap.h This is the most flexible way to encode any MSISDN, IMSI, ...
just my thoughts...
Hi Harald,
On 2/5/19 11:13 AM, Harald Welte wrote:
I would argue we should introduce a new "global title" IE which contains
- BCD digits
- nature of address / type of number
- numbering plan indicator
This would basically correspond to a SCCP global title, see osmo_sccp_gt in sccp_sap.h This is the most flexible way to encode any MSISDN, IMSI, ...
just my thoughts...
this sounds good to me. But I'm also curious about Neels' opinion about the matter, since he had drafted all these new messages.
Where would the "extension" bit go, if we use the "global title" IE?
Oliver
On Tue, Feb 05, 2019 at 04:26:54PM +0100, Oliver Smith wrote:
Hi Harald,
On 2/5/19 11:13 AM, Harald Welte wrote:
I would argue we should introduce a new "global title" IE which contains
- BCD digits
- nature of address / type of number
- numbering plan indicator
This would basically correspond to a SCCP global title, see osmo_sccp_gt in sccp_sap.h This is the most flexible way to encode any MSISDN, IMSI, ...
just my thoughts...
this sounds good to me. But I'm also curious about Neels' opinion about the matter, since he had drafted all these new messages.
I thought I had modeled this after the ASN.1 in 3GPP TS 29.002 for handoverNumber, which says:
PrepareHO-Res ::= [3] SEQUENCE { handoverNumber [0] ISDN-AddressString
and
ISDN-AddressString ::= AddressString (SIZE (1..maxISDN-AddressLength)) -- This type is used to represent ISDN numbers. maxISDN-AddressLength INTEGER ::= 9
But my GSUP spec is certainly not an ISDN-AddressString. Instead, I got this from our live inter-MSC handover trace, where I see in wireshark:
handoverNumber: 91940000000032 1... .... = Extension: No Extension .001 .... = Nature of number: International Number (0x1) .... 0001 = Number plan: ISDN/Telephony Numbering (Rec ITU-T E.164) (0x1) E.164 number (MSISDN): 490000000023 Country Code: Germany (49)
Now I'm a bit confused about the discrepancy between the spec's ASN.1 and the trace we got (notably, also wireshark's dissector).
What we see in the trace seems to match this instead, also 29.002:
AddressString ::= OCTET STRING (SIZE (1..maxAddressLength)) -- This type is used to represent a number for addressing -- purposes. It is composed of -- a) one octet for nature of address, and numbering plan indicator. -- b) digits of an address encoded as TBCD-String.
-- a) The first octet includes a one bit extension indicator, a -- 3 bits nature of address indicator and a 4 bits numbering -- plan indicator, encoded as follows: -- bit 8: 1 (no extension) -- -- bits 765: nature of address indicator -- 000 unknown -- 001 international number -- 010 national significant number -- 011 network specific number -- 100 subscriber number -- 101 reserved -- 110 abbreviated number -- 111 reserved for extension -- -- bits 4321: numbering plan indicator -- [...]
Where would the "extension" bit go, if we use the "global title" IE?
I don't even know what this "1 = Extension: No Extension" is supposed to mean. Above, it simply defines that the bit should always be 1 and mean "no extension". wtf. If it's always 1 anyway, it wouldn't matter if we drop it.
Now you know all the facts that I know, I'm currently not certain what would be the best to do. Can you figure it out?
~N
On 2/6/19 12:52 AM, Neels Hofmeyr wrote:
Now you know all the facts that I know, I'm currently not certain what would be the best to do. Can you figure it out?
After looking into the Wireshark dissector code, I came to the conclusion that the ISDN-AddressString is exactly what you are seeing in the dump. Furthermore, it is the same as the MSISDN.
Then I've looked up the existing MSISDN IE in the GSUP spec [1]:
ISDN-AddressString / MSISDN / Called Party BCD Number
The MSISDN is encoded as an ISDN-AddressString in 3GPP TS 09.02 and Called Party BCD Number in 3GPP TS 04.08. It will be stored by the SGSN or VLR and then passed as is to the GGSN during the activation of the primary PDP Context.
(It also has a graph that looks like what you see in Wireshark.)
So my conclusion is, that we can just drop the handover_number IE and use the existing msisdn_enc IE instead.
Regards, Oliver
[1]: https://git.osmocom.org/osmo-gsm-manuals/tree/common/chapters/gsup.adoc?id=6...
-
Harald Welte -
Jacob -
Neels Hofmeyr -
Oliver Smith