://www.ietf.org/archive/id/draft-ietf-avtcore-multi-party-rtt-mix-17.html
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-multi-party-rtt-mix-17
Regards
Gunnar
--
Gunnar Hellström
GHAccess
gunnar.hellst...@ghaccess.se
Den 2021-05-07 kl. 21:14
t; feels most familiar, so I
propose to change the sentence to:
"When a participant on the RTP side is disconnected from the multiparty
session, the corresponding T.140 data channel(s) SHOULD be closed."
Thanks,
Gunnar
--
Gunnar Hellström
GHAccess
gunnar.hellst...@ghaccess.se <
(when discussing -14 only): change “Cucherawy” to
“Kucherawy” unless we’re talking about someone else. Yeah, I know these will
all be deleted upon publication, but it caught my eye. I have not reviewed the
remainder of the change history entries.
Thanks again for the thorough review. I have
d to provide higher
level conference functions e.g. for blocking and expelling
participants."
to:
"Counteractions should be to require authentication, secure session
signaling and secure media. Higher level conference functions should
also be used e.g., for blocking and expelling
ch for the explanation.
>
>Do you mean WebRTC data channel is used as Transport mechanism for real-time
>text, >but Audio and Video of T140 still use RTP or SRTP?
I am not sure what you mean by "Audio and Video of T140". In WebRTC Audio and
Video use SRTP, whi
bar
>
> _______
> mmusic mailing list
> mmu...@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
--
+ + + + + + + + + + + + + +
Gunnar Hellström
Omnitor
gunnar.hellst...@omnitor.se
+46 708 204 288
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
at a different level (typically SDP, especially in the emergency
calling cases), making it easier to have mismatches (such as where
the media modality negotiated in SIP don't match what was
negotiated
using SDP).
"the media modality and language