GSUP: E-interface messages for inter-MSC HO

[Harald Welte]

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/ho
> 
> 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
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)