Add support for consumption reporting fields clientEndpointAddress and serverEndpointAddress as defined in TS 26512 17.7.0

[dsilhavy]

Addresses issue #65

An example report as created with these changes:

{
  "mediaPlayerEntry": "https://dash.akamaized.net/envivio/EnvivioDash3/manifest.mpd",
  "reportingClientId": "64cfef91-1abb-4a2a-ae9f-8bfc6de098f7",
  "consumptionReportingUnits": [
    {
      "mediaConsumed": "v7_257",
      "clientEndpointAddress": {
        "ipv4Addr": "192.168.2.4",
        "portNumber": 443
      },
      "serverEndpointAddress": {
        "domainName": "dash.akamaized.net",
        "ipv4Addr": "2.16.238.144",
        "portNumber": 443
      },
      "startTime": "2024-01-17T13:55:13Z",
      "duration": 9,
      "locations": []
    },
    {
      "mediaConsumed": "v4_258",
      "clientEndpointAddress": {
        "ipv4Addr": "192.168.2.4",
        "portNumber": 443
      },
      "serverEndpointAddress": {
        "domainName": "dash.akamaized.net",
        "ipv4Addr": "2.16.238.144",
        "portNumber": 443
      },
      "startTime": "2024-01-17T13:55:13Z",
      "duration": 9,
      "locations": []
    }
  ]
}

[dsilhavy]

@rjb1000 @davidjwbbc Do you see any issues in the example report above?

[rjb1000]

@rjb1000 @davidjwbbc Do you see any issues in the example report above?

The only unusual thing that stands out is the presence of domainName and ipv4Addr in the same EndpointAddress object. These properties were made mutually exclusive in TS 26.512 V17.6.0 – see the NOTE to table 6.4.3.9-1. This is not currently enforced by the YAML syntax, however, so your sample Consumption Report would pass any validating parser without complaint.

My formal implementation guidance for the time being would be to omit ipv4Addr when you have access to domainName.

However, I do see some value in populating both of these properties if the Media Session Handler has both pieces of information to hand since they may convey slightly different information in certain circumstances. It may be worth raising a new Standards issue to query this.

[dsilhavy]

@rjb1000 @davidjwbbc Do you see any issues in the example report above?

The only unusual thing that stands out is the presence of domainName and ipv4Addr in the same EndpointAddress object. These properties were made mutually exclusive in TS 26.512 V17.6.0 – see the NOTE to table 6.4.3.9-1. This is not currently enforced by the YAML syntax, however, so your sample Consumption Report would pass any validating parser without complaint.

My formal implementation guidance for the time being would be to omit ipv4Addr when you have access to domainName.

However, I do see some value in populating both of these properties if the Media Session Handler has both pieces of information to hand since they may convey slightly different information in certain circumstances. It may be worth raising a new Standards issue to query this.

Thanks @rjb1000 , I read the note to table 6.4.3.9-1 before implementation, but apparently I interpreted it the wrong way.

Quote:

Either domainName or at least one of ipv4Addr or ipv6Addr shall be present.

To me, it sounded like domainName is the preferred way to report the endpoint, but if no domainName is available, at least the ipv4Addr or ipv6Addr of the endpoint should be submitted. From the way this is written, I concluded that it is also valid to report both domainName and ipv4Addr or ipv6Addr.

Implementation wise, the restriction of only reporting one of these fields makes it easier. Currently, I am doing a DNS lookup for the domainName to retrieve the IP address. From what I understand, I can now simply check if the request URL to the media segment contains an IP or a DNS name and then populate the corresponding fields accordingly. In case of a DNS name, I should not do a lookup for the IP.

[dsilhavy]

Just to add to this, a report generated by the current implementation for a scenario in which the segments are fetched from an Application Server using the concrete IP. I assume putting the IP in the domainName field is wrong:

{
    "mediaPlayerEntry": "http://192.168.2.7/m4d/provisioning-session-02782f5e-b539-41ee-9f2f-0b380ee8ac65/bbb/2/client_manifest-common_init.mpd",
    "reportingClientId": "64cfef91-1abb-4a2a-ae9f-8bfc6de098f7",
    "consumptionReportingUnits":
    [
        {
            "mediaConsumed": "512x288p25",
            "clientEndpointAddress":
            {
                "ipv4Addr": "192.168.2.4",
                "portNumber": 80
            },
            "serverEndpointAddress":
            {
                "domainName": "192.168.2.7",
                "ipv4Addr": "192.168.2.7",
                "portNumber": 80
            },
            "startTime": "2024-01-17T14:12:01Z",
            "duration": 56,
            "locations":
            []
        },
        {
            "mediaConsumed": "1920x1080p25",
            "clientEndpointAddress":
            {
                "ipv4Addr": "192.168.2.4",
                "portNumber": 80
            },
            "serverEndpointAddress":
            {
                "domainName": "192.168.2.7",
                "ipv4Addr": "192.168.2.7",
                "portNumber": 80
            },
            "startTime": "2024-01-17T14:12:05Z",
            "duration": 52,
            "locations":
            []
        },
        {
            "mediaConsumed": "160kbps",
            "clientEndpointAddress":
            {
                "ipv4Addr": "192.168.2.4",
                "portNumber": 80
            },
            "serverEndpointAddress":
            {
                "domainName": "192.168.2.7",
                "ipv4Addr": "192.168.2.7",
                "portNumber": 80
            },
            "startTime": "2024-01-17T14:12:09Z",
            "duration": 48,
            "locations":
            []
        }
    ]
}

[rjb1000]

From what I understand, I can now simply check if the request URL to the media segment contains an IP or a DNS name and then populate the corresponding fields accordingly. In case of a DNS name, I should not do a lookup for the IP.

Yes. That's a nice shortcut, @dsilhavy.

Just to add to this, a report generated by the current implementation for a scenario in which the segments are fetched from an Application Server using the concrete IP. I assume putting the IP in the domainName field is wrong

Yes. That would be rather naughty. Again, it's not enforced by the YAML syntax, though. We could tighten this up at some point, though.

[dsilhavy]

Fixed the issue described above and now reporting only one of the fields domainName or ipv4Addr or ipv6Addr.

Two sample reports as generated with the local development server and a local version of the Application function:

{
  "mediaPlayerEntry": "https://livesim.dashif.org/livesim/testpic_2s/Manifest.mpd",
  "reportingClientId": "b3559848-df2b-4140-a373-4caccda31d00",
  "consumptionReportingUnits": [
    {
      "mediaConsumed": "A48",
      "clientEndpointAddress": {
        "ipv4Addr": "192.168.2.4",
        "portNumber": 443
      },
      "serverEndpointAddress": {
        "domainName": "livesim.dashif.org",
        "portNumber": 443
      },
      "startTime": "2024-01-18T13:35:22Z",
      "duration": 12,
      "locations": []
    },
    {
      "mediaConsumed": "V300",
      "clientEndpointAddress": {
        "ipv4Addr": "192.168.2.4",
        "portNumber": 443
      },
      "serverEndpointAddress": {
        "domainName": "livesim.dashif.org",
        "portNumber": 443
      },
      "startTime": "2024-01-18T13:35:22Z",
      "duration": 12,
      "locations": []
    }
  ]
}

{
    "mediaPlayerEntry": "http://192.168.2.7/m4d/provisioning-session-fb76a8e8-b5fb-41ee-9b55-71f16c62e9e4/bbb/2/client_manifest-common_init.mpd",
    "reportingClientId": "ff336e85-3342-4071-9632-4e8070b2d985",
    "consumptionReportingUnits":
    [
        {
            "mediaConsumed": "1920x1080p25",
            "clientEndpointAddress":
            {
                "ipv4Addr": "192.168.2.4",
                "portNumber": 80
            },
            "serverEndpointAddress":
            {
                "ipv4Addr": "192.168.2.7",
                "portNumber": 80
            },
            "startTime": "2024-01-18T13:31:08Z",
            "duration": 91,
            "locations":
            []
        },
        {
            "mediaConsumed": "160kbps",
            "clientEndpointAddress":
            {
                "ipv4Addr": "192.168.2.4",
                "portNumber": 80
            },
            "serverEndpointAddress":
            {
                "ipv4Addr": "192.168.2.7",
                "portNumber": 80
            },
            "startTime": "2024-01-18T13:31:09Z",
            "duration": 90,
            "locations":
            []
        }
    ]
}