Filip/matrix-spec
1
0
Fork 0
mirror of https://github.com/matrix-org/matrix-spec synced 2026-02-04 05:13:42 +01:00
Code Issues Actions 3 Packages Projects Releases Wiki Activity

Tense, typos & grammar

Browse source 
Co-authored-by: Hubert Chathi <hubertc@matrix.org>
This commit is contained in:
David Baker 2023-05-17 09:45:25 +01:00 committed by GitHub
parent 1fda1ec52c
commit a6c2cf2515
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
2 changed files with 5 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

8
content/client-server-api/modules/voip_events.md
View file

@ -30,7 +30,7 @@ lowercase alphanumeric characters is recommended. Parties in the call are identi
The client adds a `party_id` field containing this ID to the top-level of the content of all VoIP events
it sends on the call, including `m.call.invite`. Clients use this to identify remote echo of their own
events: since a user may now call themselves, they can no longer ignore events from their own user. This
events: since a user may call themselves, they cannot simply ignore events from their own user. This
field also identifies different answers sent by different clients to an invite, and matches `m.call.candidates`
events to their respective answer/invite.
@ -115,7 +115,7 @@ The same behaviour applies when a client is looking at historic calls.
#### Supported Codecs
The Matrix spec does not mandate particular audio or video codecs, but instead defers to the
WebRTC spec. A compliant matrix VoIP client will behave in the same way as a supported 'browser'
WebRTC spec. A compliant Matrix VoIP client will behave in the same way as a supported 'browser'
in terms of what codecs it supports and what variants thereof. The latest WebRTC specification
applies, so clients should keep up to date with new versions of the WebRTC specification whether
or not there have been any changes to the Matrix spec.
@ -154,7 +154,7 @@ Or a rejected call:
Calls are negotiated according to the WebRTC specification.
In response to an invoming invite, a client may do one of several things:
In response to an incoming invite, a client may do one of several things:
* Attempt to accept the call by sending an `m.call.answer`.
* Actively reject the call everywhere: send an `m.call.reject` as per above, which will stop the call from
ringing on all the user's devices and the caller's client will inform them that the user has
@ -180,7 +180,7 @@ with respect to presenting such streams and tracks is undefined.
##### Invitees
The `invitee` field should be added whenever the call is intended for one
specific user , and should be set to the Matrix user ID of that user. Invites
specific user, and should be set to the Matrix user ID of that user. Invites
without an `invitee` field are defined to be intended for any member of the
room other than the sender of the event.

2
data/event-schemas/schema/m.call.negotiate.yaml
View file

@ -2,7 +2,7 @@
type: object
description: |
Provides SDP negotiation semantics for media pause, hold/resume, ICE restarts
and voice/video call up/downgrading. Clients should implement & honour hold
and voice/video call up/downgrading. Clients should implement and honour hold
functionality as per WebRTC's recommendation:
https://www.w3.org/TR/webrtc/#hold-functionality