m.call.* events are sent with the version as a string

[zecakeh]

Steps to reproduce

1. Open a conversation
2. Initiate a voice/video call
3. Hangup
4. Look at the source of one of the m.call.* events sent by Element Android, for example:

{
  "room_id": "!roomid:matrix.org",
  "type": "m.call.invite",
  "content": {
    "lifetime": 60000,
    "offer": {
      "type": "offer",
      "sdp": "..."
    },
    "capabilities": {
      "m.call.transferee": false,
      "m.call.dtmf": false
    },
    "org.matrix.msc3077.sdp_stream_metadata": {
      "{1234-xyz}": {
        "purpose": "m.usermedia",
        "audio_muted": false,
        "video_muted": true
      }
    },
    "version": "1",
    "call_id": "abcdef456",
    "party_id": "XXXXX"
  }
}

Outcome

What did you expect?

The event should follow the definition in MSC2746 and serialize version as a number.

It would then be backwards-compatible with libraries with strong types (ruma in this case) that don't implement this MSC yet, allowing clients that depend on it to handle this event.

What happened instead?

The events fails to deserialize because it expects a number instead of a string.

Your phone model

N/A

Operating system version

Android 11.1

Application version and app store

Element v1.4.14, olm v3.2.10 from F-Droid

Homeserver

matrix.org

Will you send logs?

No

[zecakeh]

Actually this implementation follows the current state of MSC2746, but it still breaks backwards compatibility.

[ouchadam]

I'm not entirely sure what the consensus is from the MSC conversation, if we should be using strings or numbers. From a client consumption standpoint It seems risky to switch from String to Int as there may be unstable - stable interop between different android client versions

[zecakeh]

The JS SDK now sends this as a string too (matrix-org/matrix-js-sdk#2471) so the current behavior seems to be the consensus.

As a result I'm closing this.