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