You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We're in the process of implementing the Simple Edge Discovery API (v0.9.3) and attempting to reconcile some issues we see with the proposed usage:
The API returns the closest MEC platform to a given device, so that device needs to be identifiable by the network:
* if you call the API from a server, you must explicitly pass one or more device identifiers in the HTTP request header:
* `IP-Address`. This is the public IP address of the user device: this can be obtained by an application hosted on that device calling a public IP address API (e.g. GET https://api.ipify.org?format=json)
* `Phone-Number` . The international E.164 format (starting with country code), e.g. +4407123123456
* `Network-Access-Identifier` (where available from the API host operator)
* if you call the API from a device attached to the operator network, you _may_ omit the explicit device identifier(s)from the request header. If such a request fails with a `404 Not Found` error then retry the request but this time include a device identifier.
How does the group suggest implementations identify that a request was generated by a server, as opposed to a device attached to the network? Our current approach is purely IP based, we look for the IP-Address header, and if not provided fall back to the remote client IP address (assuming parties in between are handling X-Forwarded-For etc headers appropriately). We don't really know if the original client is a server or device attached to the network. Because of this we don't really see how we can support both server requirements 'you must explicitly pass one or more device identifiers' and device requirements 'you may omit the explicit device identifier(s)'. Any ideas greatly welcomed :)!
The text was updated successfully, but these errors were encountered:
Thanks for pointing this out, I'll make it clearer on 0.9.4.
If an IP-Address parameter is provided then the operator should assume the request is coming from a developer's server rather than a device attached to the network. In which case the developer server is expected to have been provided with the device public IP address (e.g. by the application client on that device signaling it back to the server)
If neither the IP-Address parameter nor any other device identifier is provided in the API request header, then the operator should assume the request is from a device attached to their network, and attempt to use the public IP source address to determine which packet gateway issued it (and hence the closest edge to that gateway).
If no IP-Address header is provided, but another device identifier(s) is provided, then the operator should assume the request is coming from a device attached to their network and should make use of one or both of the public IP source address (from the IP packet header) and the other device identifier(s).
Kevsy
changed the title
Question: device/server distinction for Simple Edge Discovery API usage
Documentation: Clarify distinction between device/server usage of Simple Edge Discovery API
Feb 16, 2024
Hi folks,
We're in the process of implementing the Simple Edge Discovery API (v0.9.3) and attempting to reconcile some issues we see with the proposed usage:
How does the group suggest implementations identify that a request was generated by a server, as opposed to a device attached to the network? Our current approach is purely IP based, we look for the IP-Address header, and if not provided fall back to the remote client IP address (assuming parties in between are handling X-Forwarded-For etc headers appropriately). We don't really know if the original client is a server or device attached to the network. Because of this we don't really see how we can support both server requirements 'you must explicitly pass one or more device identifiers' and device requirements 'you may omit the explicit device identifier(s)'. Any ideas greatly welcomed :)!
The text was updated successfully, but these errors were encountered: