The linked document describes how an intercepting tunneler - including Ziti Mobile Edge - decides which service to connect based on the packet that was intercepted. FYI The tunneler-sdk project is used by Ziti Mobile Edge/Ziti Desktop Edge as well as ziti-edge-tunnel (which is used directly by Ziti Desktop Edge for Windows. So most of the tunnelers are using the same codebase as far as packet processing is concerned.
But you're right, the doc doesn't explain what happens once the service is determined. Let me try to explain that with a sequence diagram:
First, the intercepting tunneler (ZME in this case) establishes the hostname to IP mappings for any hostnames in the intercept.v1 address list when it receives the service configurations from the controller.
Wildcard domains (those with a leading '*') are handled a little differently because we don't know what the hostnames will be until we see a query that matches the wildcard domain. So hostname to IP mappings for hostnames in wildcard domains are assigned as the queries are processed by the internal DNS server.
At some point you want to hit "https://host.ziti" from your browser. The browser looks up the hostname (probably using getaddrinfo). If we've set the host's DNS resolver up correctly then the DNS query will be intercepted by ZME, which will give an answer like "100.64.0.3". The browser initiates a connection by sending TCP SYN, and if we've set up a route for that IP to the tun device that ZME is reading then ZME will get the packet and look for the best matching service as described above. Once the service is determined, ZME will "dial" the OpenZiti network for that service.
Previously on another host, a tunneler (ziti-edge-tunnel for the sake of this example) received the same service, but the identity running this tunneler has bind permission so ziti-edge-tunnel is operating as a "hosting" tunneler - meaning that it will accept connections from other OpenZiti identities for the "ziti-hostname" service. When an incoming connection arrives, ziti-edge-tunnel will connect to the address specified in the host.v1 configuration. The status of this connection is reported to the initiating client (ZME in this example).
The intercepting tunneler completes the TCP handshake with the browser only when the hosting tunneler has established a connection on its end. The browser then communicates with ZME as if it was connected with httpd.
Note that only the TCP payloads are sent over the OpenZiti network. The tunnelers on either end of the connection are having separate and distinct conversations with their peers. In other words the tunnelers do not forward the TCP or UDP headers over OpenZiti (as most VPN solutions do).