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