3GPP Service Handler and HTTP URLs

[dsilhavy]

Feature description

3GPP TR 26.804 Section 5.13 deals with announcing media services in a portal application or service list and launching the URL of a media service entry point. The Android operating system allows a URL to be used by one application to launch a specific other application on the same UE by means of Android App Links. Consequently, we can start the Media Session Handler when selecting a media service entry point in the 5GMSd Aware Application.

This issue deals with a proof of concept implementation of the solution defined in Section 5.13.5 and 5.13.6.2.

[dsilhavy]

PoC

As a starting point / proof of concept, the following flow has been implemented:

1. Created a webpage with two sample URLs in the format http://ms.launch.3gppservices.org and https://ms.launch.3gppservices.org: https://dash.fokus.fraunhofer.de/tests/dsi/5gmag/http-handler/

2. Added an <intent-filter> in the AndroidManifest.xml of the Media Session Handler:

   <intent-filter android:autoVerify="true">
   <action android:name="android.intent.action.VIEW" />
   <category android:name="android.intent.category.DEFAULT" />
   <category android:name="android.intent.category.BROWSABLE" />
   
   <data android:scheme="http"/>
   <data android:scheme="https"/>
   <data android:host="ms.launch.3gppservices.org"/>
   </intent-filter>

3. Launched Chrome browser and accessed https://dash.fokus.fraunhofer.de/tests/dsi/5gmag/http-handler/
4. The Media Session Handler is started when one of the links on the demo page is selected

Short demo video:

https://github.com/5G-MAG/rt-5gms-media-session-handler/assets/2427039/ba14529e-e188-4417-aa63-ce16aff94adb

Next steps

As a next step, we can focus on the workflow defined in 5.13.6.2 and 5.13.6.2.3. I suggest adding a new view to the 5GMSd Aware application with a list of service URLs using the format defined in Table 5.13.6.2.2-1. Once a service URL is selected, the Media Session Handler is started and the streaming session begins. Similar to what we are doing today when the user selects an entry from the list of service URLs that are provided via M8. Alternatively we "convert" the entries from our m8.json to service URLs.

[haudiobe]

This is very nice Daniel. I agree that it would be excellent if the streaming service is started immediately. Also we need to basically extend further that the service/provisioning id is added in order to connect the Media Session Handler to the AF in a session. I also see that there is the need to accept the handling of the URL by the Media Session Handler. Finally, if the Media Session Handler is not launched, the message will go to the AF, and the AF may provide a redirect directly to the service.

[rjb1000]

Finally, if the Media Session Handler is not launched, the message will go to the AF, and the AF may provide a redirect directly to the service.

If there is no registered intent for the 3GPP Service URL https://ms.launch.3gppservices.org/, it needn't be the 5GMS AF that handles the fallback case: it could be any endpoint in the 5G System registered with that special domain name.

[haudiobe]

Finally, if the Media Session Handler is not launched, the message will go to the AF, and the AF may provide a redirect directly to the service.

If there is no registered intent for the 3GPP Service URL ms.launch.3gppservices.org, it needn't be the 5GMS AF that handles the fallback case: it could be any endpoint in the 5G System registered with that special domain name.

Yes, true. But the idea is that this function of URL handling in the network is at least "logically" assigned to the Media AF.

[dsilhavy]

I have to give this another thought with a fresh mind but currently I assume it is more complicated than I orginally thought. In the following I outline the current workflow and the problem I see when launching the Media Session Handler via a deeplink:

Current Workflow

1. Media Session Handler is started manually
2. 5GMS Aware Application is started
3. The 5GMS Aware Application which includes the Media Stream Handler as a library binds to the Media Session Handler. After this binding is completed we can exchange IPC messages back and forth
4. The Media Stream Handler registers with the Media Session Handler via a first IPC message. Each IPC message contains a unique sendingUid that is generated by the Android API. So this is not something we are generating ourself at this point.
5. For each sendingUid we maintain an instance of the ClientSessionModel class. This is saved via a HashMap HashMap<sendingUid, ClientSessionModel>. The ClientSessionModel saves sessions relevant information such as the ServiceAccessInformation. Moreover, we save the instance of the Messenger class that we can use to send messages to this specific application/Media Stream Handler. For instance, in case of metrics reporting we periodically query metrics from each connected Media Stream Handler.

   data class ClientSessionModel(
   var messenger: Messenger?,
   var serviceAccessInformation: ServiceAccessInformation? = null,
   var serviceAccessInformationApi: ServiceAccessInformationApi? = null,
   var serviceAccessInformationResponseHeaders: Headers? = null,
   var serviceAccessInformationRequestTimer: Timer? = null
   )

6. We set the M5 endpoint via IPC message from the application to the Media Session Handler
7. In the application, the user selects a stream from the dropdown
8. We send an IPC message from the application to the Media Session Handler including the following data:

   data class ServiceListEntry(
   val provisioningSessionId : String,
   val name: String,
   val entryPoints: ArrayList<EntryPoint>?
   ) : Parcelable

9. The Media Session Handler fetches the right ServiceAccessInformation and provides a list of valid mediaEntryPoints to the Media Stream Handler via an IPC message. This is a direct response to the previous message from step 7). We know who the sender was, so we can just respond.
10. The Media Stream Handler starts playback. Starting the metrics reporting in the Media Session Handler and similar tasks are all linked to a unique sendingUid.

Potential problems

1. Now if we use a deeplink to start the Media Session Handler from the 5GMS Aware Application we do not have a binding between these two. From my understanding there is no direct way to know if the Media Session Handler was successfully started. This means we can try to establish a binding but can not be sure this is successful. This is similar to when we start the 5GMS Aware Application before the Media Session Handler is running.
2. The main issue I am seeing is how to provide a list of mediaEntryPoints from the Media Session Handler to the Media Stream Handler (see step 9 above). We started the Media Session Handler via a Deeplink that contains all the relevant information about media-entry-point, af-host-address URL etc. (see Table 5.13.6.2.2 1). But at this point we don't know to which IPC client/Media Stream Handler we should send the valid mediaEntryPoints. Even if the IPC connection has been established we might have multiple Media Stream Handlers connected to the same Media Session Handler. How do we trigger the "right" Media Stream Handler? Similar, how do we persist the ServiceAccessInformation we just received. This has to be mapped to the streaming session of a specific Media Stream Handler.

Potential solutions

• Should the 5GMS Aware Application extend the deeplink with a unique identifier that is also used for each IPC message (instead of the built in sendingUid)? That way we can also register new clients, see step 4 above. However, in this case all messages need to be enriched by this new unique identifier.
• Maybe the intent itself contains a unique application ID that can also be used as an ID in the IPC messages.

[dsilhavy]

Based on our discussion in the call I checked whether it is possible to provide information back from the Media Session Handler to the entity that triggered the intent.

From what I found, there is no direct way to send a message back to the specific application (e.g. a Chrome tab that launched the intent) from our Android application.

However, there is a workaround as we can launch another intent from our Media Session Handler which then gets picked up by the corresponding application. As an example, based on the previous comment.

1. We start Chrome and click on one of the URLs
2. We select the Media Session Handler as the application to open the link with
3. The Media Session Handler processes the intent and starts another intent:

    private fun handleActionViewIntent(intent: Intent) {
        val data = intent.data
        if (data != null) {
            val message = data.getQueryParameter("message")
            if (message != null) {
                // Create an intent to send the message back to the Chrome browser
                val returnIntent = Intent(Intent.ACTION_VIEW)
                returnIntent.data = Uri.parse("https://dash.fokus.fraunhofer.de/tests/dsi/5gmag/http-handler/?message=Hello this is the Media Session Handler")

                // Start the intent to send the message back
                startActivity(returnIntent)
            }
        }
    }

In this case we call the original URL that started the intent and pass a message via query parameters: message=Hello this is the Media Session Handler

4. We use JavaScript on the website to parse the message and display it.

This is more a workaround though, as we don't have information about the app that launched the Media Session Handler originally. We only know the scheme, the host and the queryparameters that are defined in the intent filter, e.g: https://ms.launch.3gppservices.org?message=helloworld

What we can do in addition is specify the orginal URL ("https://dash.fokus.fraunhofer.de/tests/dsi/5gmag/http-handler/") as another query parameter, e.g: https://ms.launch.3gppservices.org?message=helloworld&url=https%3A%2F%2Fdash.fokus.fraunhofer.de%2Ftests%2Fdsi%2F5gmag%2Fhttp-handler%2F

A short demo video:

https://github.com/5G-MAG/rt-5gms-media-session-handler/assets/2427039/d87ae44c-ca90-42e5-8e3d-ce76207e456e

[haudiobe]

More background:

• https://www.branch.io/resources/blog/how-to-open-an-android-app-from-the-browser/
• https://developer.chrome.com/docs/android/intents
• https://www.vogella.com/tutorials/AndroidIntent/article.html
• This seems to be addressing the question: https://stackoverflow.com/questions/34197933/how-do-you-call-an-android-app-and-get-a-result-back-from-a-web-page-in-chrome

[haudiobe]

I also checked Co Pilot

To achieve this, you can use deep linking to open your Android app from a web page. Deep linking allows you to seamlessly transition users from a website to specific in-app content. Here are the steps to create Android App Links:

Create Intent Filters in Your Manifest: In your Android app’s AndroidManifest.xml, define intent filters for incoming links. These filters specify how your app should handle URLs associated with your website domain. The following elements and attributes are needed within your <activity> tag: <action>: Specify the VIEW intent action so that the intent filter can be reached from web link clicks. <data>: Include the android:scheme attribute. The data tags represent a URI format that resolves to the activity. BROWSABLEcategory: Required for the intent filter to be accessible from a web browser. Without it, clicking a link in a browser won’t route users to your app. DEFAULT category: Allows your app to respond to implicit intents.

Example of an intent filter for deep linking using the URI “https://www.example.com/gizmos”: XML

<activity android:name=".YourActivity">
    <intent-filter>
        <action android:name="android.intent.action.VIEW" />
        <category android:name="android.intent.category.DEFAULT" />
        <category android:name="android.intent.category.BROWSABLE" />
        <data
            android:scheme="https"
            android:host="www.example.com"
            android:pathPrefix="/gizmos" />
    </intent-filter>
</activity>

AI-generated code. Review and use carefully. More info on FAQ.

Configure Your Mobile Website: To ensure the best user experience, configure your mobile website to handle the App Link. This prevents users from viewing a 404 page when they don’t have your app installed. When users click a link associated with your app, they’ll be taken directly to the relevant content within your app. Remember that deep linking can be complex, but using tools like Branch can simplify the process by handling deep links, hosting them, and providing analytics behind clicks and app opens. I recommend exploring such tools to avoid rebuilding everything from scratch1.

[dsilhavy]

This seems to be addressing the question: https://stackoverflow.com/questions/34197933/how-do-you-call-an-android-app-and-get-a-result-back-from-a-web-page-in-chrome

This seems to correspond to what I did in https://github.com/5G-MAG/rt-5gms-media-session-handler/issues/37#issuecomment-1790607670. Basically, the intent filter URL contains a callback URL and possible a custom string that tells the application to trigger another intent with some payload. However, I don't think there is a way to directly respond to the caller that triggered the first intent.