IETF
Wish
wish@jabber.ietf.org
Tuesday, March 9, 2021< ^ >
Room Configuration
Room Occupants

GMT+0
[11:50:03] Alexandre Gouaillard_web_355 joins the room
[11:50:03] Lorenzo Miniero_web_995 joins the room
[11:50:03] Sean Turner_web_174 joins the room
[11:50:03] Alexandre Gouaillard_web_355 leaves the room
[11:50:10] Alexandre Gouaillard_web_168 joins the room
[11:50:42] Juliusz Chroboczek_web_790 joins the room
[11:52:24] Alexandre Gouaillard_web_168 leaves the room
[11:52:29] Alexandre Gouaillard_web_293 joins the room
[11:52:39] Alexandre Gouaillard_web_293 leaves the room
[11:53:42] Renan Krishna_web_662 joins the room
[11:54:23] Alessandro Amirante_web_951 joins the room
[11:54:34] Florent Castelli_web_700 joins the room
[11:55:15] Harald Alvestrand_web_823 joins the room
[11:56:14] Mike English_web_994 joins the room
[11:57:44] Timothy Panton_web_551 joins the room
[11:58:23] Hannu Flinck_web_133 joins the room
[11:58:40] Adam Roach_web_243 joins the room
[11:58:43] Samuel Weiler_web_121 joins the room
[11:59:10] Samuel Weiler_web_121 leaves the room
[11:59:13] Samuel Weiler_web_522 joins the room
[11:59:29] Rohit Abhishek_web_283 joins the room
[11:59:47] Timothy Panton_web_551 leaves the room
[11:59:47] Alexandre Gouaillard_web_444 joins the room
[11:59:50] Alan Ford_web_737 joins the room
[11:59:52] Alan Ford_web_737 leaves the room
[11:59:59] Xavier de Foy_web_768 joins the room
[11:59:59] Frode Kileng_web_328 joins the room
[12:00:01] Alan Ford_web_861 joins the room
[12:00:19] Timothy Panton_web_586 joins the room
[12:00:24] Jonathan Lennox_web_748 joins the room
[12:00:54] Greg Wood_web_285 joins the room
[12:00:55] Stephan Wenger_web_689 joins the room
[12:00:55] Sergio Garcia Murillo_web_302 joins the room
[12:00:55] Stephan Wenger_web_689 leaves the room
[12:00:58] Stephan Wenger_web_270 joins the room
[12:01:05] frodek joins the room
[12:01:11] Alexandre Gouaillard_web_444 leaves the room
[12:01:14] Alexandre Gouaillard_web_542 joins the room
[12:01:26] Sean Turner_web_174 leaves the room
[12:01:29] Sean Turner_web_276 joins the room
[12:01:46] Chunshan Xiong_web_590 joins the room
[12:02:16] Cullen Jennings_web_711 joins the room
[12:03:56] Oh Seokbeom_web_834 joins the room
[12:04:06] Lucas Pardue_web_289 joins the room
[12:04:15] Murray Kucherawy_web_370 joins the room
[12:04:16] Cullen Jennings_web_711 leaves the room
[12:04:26] Cullen Jennings_web_924 joins the room
[12:04:34] <Mike English_web_994> I can act as scribe
[12:04:44] Umberto Fattore_web_664 joins the room
[12:04:51] Timothy Panton_web_586 leaves the room
[12:04:54] Kazuhisa Matsuzono_web_109 joins the room
[12:04:55] Timothy Panton_web_163 joins the room
[12:05:28] <Sean Turner_web_276> 15:00 to 17:00 CET
[12:05:35] <Sean Turner_web_276> https://codimd.ietf.org/notes-ietf-110-wish#
[12:06:49] Greg Wood_web_285 leaves the room
[12:07:11] Juliana Guerra_web_494 joins the room
[12:07:35] Ali Begen_web_321 joins the room
[12:07:35] Oh Seokbeom_web_834 leaves the room
[12:07:54] Lucas Pardue_web_289 leaves the room
[12:07:54] <Jonathan Lennox_web_748> Did I?  Gosh, I'm insightful.
[12:07:55] <Juliusz Chroboczek_web_790> Question: does "HTTPS based" explicitly exclude WebSocket, or does WS count as part of HTTPS?
[12:07:58] Lucas Pardue_web_287 joins the room
[12:08:06] Hannu Flinck_web_133 leaves the room
[12:09:06] cm-msk@jabber.org joins the room
[12:09:45] <Mike English_web_994> I think that's a fair question Juliusz.
[12:10:26] Umberto Fattore_web_664 leaves the room
[12:11:53] Kaustubh Inamdar_web_388 joins the room
[12:12:53] Hannu Flinck_web_373 joins the room
[12:12:53] Kazuhisa Matsuzono_web_109 leaves the room
[12:13:15] Sanjay Mishra_web_318 joins the room
[12:13:41] Kazuhisa Matsuzono_web_903 joins the room
[12:15:23] <Juliusz Chroboczek_web_790> That's RFC 8853, right?
[12:18:11] <Mike English_web_994> I believe RFC 8853 is one of the recently published documents Harald mentioned, yes.
[12:18:12] Kaustubh Inamdar_web_388 leaves the room
[12:19:30] <Cullen Jennings_web_924> Juliusz, you should ask that
[12:19:32] Suhas Nandakumar_web_274 joins the room
[12:19:35] Sanjay Mishra_web_318 leaves the room
[12:19:38] Sanjay Mishra_web_486 joins the room
[12:20:20] Chris Wendt_web_765 joins the room
[12:20:24] <Mike English_web_994> Reminder, I can relay messages or questions to the mic if anyone wants. Just prefix with "mic:"
[12:21:32] <Juliusz Chroboczek_web_790> Will do, at the end of the presentation.
[12:26:22] hta joins the room
[12:27:05] Roland Jesske_web_429 joins the room
[12:27:05] Josh Cohen_web_631 joins the room
[12:28:32] <Juliusz Chroboczek_web_790> +1
[12:28:35] Bastiaan Wissingh_web_979 joins the room
[12:28:41] Roland Jesske_web_429 leaves the room
[12:28:50] <Cullen Jennings_web_924> 100% agree with ATA
[12:28:53] Roland Jesske_web_271 joins the room
[12:28:54] <Cullen Jennings_web_924> WIht HTA
[12:30:41] Lixia Zhang_web_689 joins the room
[12:31:58] <Juliusz Chroboczek_web_790> I would appreciate some reading pointers on the subject, Re "REST is probably the better architecture".
[12:32:14] Lixia Zhang_web_689 leaves the room
[12:33:20] <Juliusz Chroboczek_web_790> (If REST is the better architecture, I don't want to know what it is better than.)
[12:33:48] Sean Turner_web_276 leaves the room
[12:34:07] Sean Turner_web_193 joins the room
[12:34:16] <Cullen Jennings_web_924> It seems to me we should sort out if we have a need for the type of notifications  HTTP does not support
[12:35:29] <Juliusz Chroboczek_web_790> I think everyone is convinced that anything can be layered over HTTP with enough hacking.  I'm pretty sure that a number of people will agree with me, though, that using WS (or some other message-oriented bidirectional connected transport) simplifies a *lot* of things, and makes the apps way more responsive.
[12:35:34] <hta> I would prefer to leave notifications to an extension mechanism. One of Adam's verb->endpoint list members could easily be wss:
[12:36:19] <Cullen Jennings_web_924> The BYE in SIP was a huge argument. Need to repeat here :-)
[12:39:28] <Cullen Jennings_web_924> Don't most REST API start with a base URL and add things a formulatic way ?
[12:39:43] Li Jianfei_web_576 joins the room
[12:40:30] Li Jianfei_web_576 leaves the room
[12:40:36] Li Jianfei_web_475 joins the room
[12:40:51] Kazuhisa Matsuzono_web_903 leaves the room
[12:40:55] Kazuhisa Matsuzono_web_669 joins the room
[12:41:10] <Mike English_web_994> I think the main thing that makes WSS appealing (to consider fitting within "HTTPS") are these proposed session management constraints.
[12:41:51] Murray Kucherawy_web_370 leaves the room
[12:41:56] Murray Kucherawy_web_438 joins the room
[12:41:58] Li Jianfei_web_475 leaves the room
[12:42:04] Li Jianfei_web_972 joins the room
[12:42:43] Suhas Nandakumar_web_274 leaves the room
[12:42:46] Suhas Nandakumar_web_682 joins the room
[12:43:54] James Gruessing_web_212 joins the room
[12:44:18] James Gruessing joins the room
[12:44:27] <Juliusz Chroboczek_web_790> Adam, please mute your mike when you type.
[12:44:39] <Mike English_web_994> Cullen: so if we go this "REST" route, you'd propose we use something like https://spec.openapis.org/oas/v3.0.3 to define our interface?
[12:45:33] Li Jianfei_web_972 leaves the room
[12:47:17] <Cullen Jennings_web_924> yes ( or something like it )
[12:47:36] Roland Jesske_web_271 leaves the room
[12:47:42] Roland Jesske_web_490 joins the room
[12:47:50] englishm-xmpp2 joins the room
[12:52:57] Li Jianfei_web_276 joins the room
[12:54:23] James Hurley_web_187 joins the room
[12:54:56] Steve Donovan_web_345 joins the room
[12:56:39] <Juliusz Chroboczek_web_790> Not for mic.  I disagree with Sergio — if the signalling channel goes down, you want to give a hard failure so the user is notified rather than keep going.
[12:56:58] <Juliusz Chroboczek_web_790> Otherwise, you end up with situations in which a user is getting just part of the media and is not aware of that.
[12:57:30] <Cullen Jennings_web_924> I think this would be clear if we were clear on why we needed a singnalling channel *after* setup
[12:57:35] <Suhas Nandakumar_web_682> we probably need a way for media server to detect timeout of a session and let the signaing server  know  as well
[12:57:38] <Chris Wendt_web_765> Maybe I'm confused about the use case for WISH, but I thought this was mostly about media ingest for broadcast use-cases, not for individual participants of a video conference.
[12:58:03] Li Jianfei_web_276 leaves the room
[12:58:34] Brad Gorman_web_184 joins the room
[12:58:37] <hta> for the broadcast case, the need would be for the broadcaster to tell the media producer (which may be a remote camera, for instance) "the show is over, go away".
[12:58:47] <Juliusz Chroboczek_web_790> Think broadcasting a talk with slides.  The user must be aware if just the talk goes through and he's missing the slides.
[12:58:51] Roland Jesske_web_490 leaves the room
[12:58:54] <Mike English_web_994> If we want the media session to survive a failure of the signaling channel, why do need the signaling channel? Do we need the signaling channel?
[12:59:09] <Sergio Garcia Murillo_web_302> +1 to cullen and mike
[12:59:23] Brad Gorman_web_184 leaves the room
[12:59:28] Juliana Guerra_web_494 leaves the room
[12:59:30] <hta> I was wondering whether we could satisfy all the post-setup signalling by doing something on a datachannel, together with the media.
[12:59:35] Juliana Guerra_web_660 joins the room
[12:59:55] <Juliusz Chroboczek_web_790> hta, won't work for an ICE restart triggered by ICE failure.
[13:00:23] <Sergio Garcia Murillo_web_302> i would prefer not to have to implement datachannels on my media server :grinning:
[13:00:39] <Suhas Nandakumar_web_682> if a media session survives sigaing failure,  how do we ensure that a end point is still authorized to be in the session (?)
[13:00:41] <Sergio Garcia Murillo_web_302> also, would be hard to get ffmpeg to implement DC :wink:
[13:00:42] Josh Cohen_web_631 leaves the room
[13:00:43] <Mike English_web_994> hta: We've considered that as well, but since non-browser clients weren't previously feasible, we already had a browser session and WSS was simpler to implement in that context.
[13:01:16] Hannu Flinck_web_373 leaves the room
[13:01:22] Hannu Flinck_web_801 joins the room
[13:01:22] Samuel Weiler_web_522 leaves the room
[13:01:33] <Mike English_web_994> Lost Adam's audio - just me?
[13:01:39] <Sergio Garcia Murillo_web_302> @sushas you have ice authentication & consent fresnesh and
[13:01:48] <Cullen Jennings_web_924> I have heard it  argued that one of the worse design decision in the "Session Initiation Protocol" was making it do more than session initiation
[13:01:51] Luke Curley_web_573 joins the room
[13:02:01] Chris Wendt_web_765 leaves the room
[13:02:07] Chris Wendt_web_971 joins the room
[13:08:00] <Cullen Jennings_web_924> I feel that way about wbertc :-)
[13:08:13] <Chris Wendt_web_971> +1 to simple JSON protocol over WSS or other persistent channels in future
[13:08:17] <Juliusz Chroboczek_web_790> Make sure people don't realise it's WebRTC until it's too late ;-)
[13:08:21] <Mike English_web_994> I agree with Timothy - RTMP ingest as a point of reference for comparison would be useful, imo
[13:08:32] <hta> as soon as people see the SDP blob, they know...
[13:09:02] <Juliusz Chroboczek_web_790> Mandate processing SDP with ROT-13, so they don't notice ;-)
[13:09:15] <Cullen Jennings_web_924> SDP, making everything other than ICE look easy
[13:11:58] <Cullen Jennings_web_924> +1 on RTPM is a clear idea of the MVP requirements are
[13:12:13] <Juliusz Chroboczek_web_790> Sergio, that was helpful, it clarifies your position to me.
[13:15:08] <Ali Begen_web_321> Students almost never turn on their webcam in classes!
[13:16:02] <Cullen Jennings_web_924> MPEG dash is not low latency enough for this
[13:16:18] <Mike English_web_994> ^ this
[13:16:26] <Chris Wendt_web_971> Agree there should be at least a base mode that is essentially the RTMP case, not even sure it needs to be more complex than that, but would like to see something simple at a minimum
[13:16:48] <Mike English_web_994> Otherwise, yes, dash or hls are good options for broadcast
[13:16:56] <Cullen Jennings_web_924> +1 chris
[13:17:06] <Ali Begen_web_321> Just curious: what is the latency requirement here?
[13:17:37] <Sergio Garcia Murillo_web_302> <1s
[13:17:51] <Juliusz Chroboczek_web_790> I'm happy with this answer.
[13:17:56] <Juliusz Chroboczek_web_790> Yep.
[13:18:16] <Sean Turner_web_193> and the fun begins ;)
[13:21:04] <Juliusz Chroboczek_web_790> Don't use AWS, then ;-)
[13:21:20] James Gruessing_web_212 leaves the room
[13:21:26] James Gruessing_web_827 joins the room
[13:22:04] Asad Saeed_web_351 joins the room
[13:23:00] Asad Saeed_web_351 leaves the room
[13:23:04] <Mike English_web_994> "You will never need a TURN server" <- not necessarily true if clients are on networks that block UDP
[13:23:14] Asad Saeed_web_352 joins the room
[13:23:34] <Juliusz Chroboczek_web_790> Well, there's TCP-ICE, in principle.
[13:24:04] <Juliusz Chroboczek_web_790> But yes, you cannot function without a TCP fallback.
[13:24:50] <hta> The server will have to send a TCP candidate.
[13:25:28] <Luke Curley_web_573> you don't need that STUN candidate actually
[13:25:39] <Juliusz Chroboczek_web_790> Not for mic.  Am I correct in my remembering that ICE-Lite doesn't do failures?
[13:26:06] <Mike English_web_994> Do we need to support TCP fallback? (partly asking myself this)
[13:27:37] <Juliusz Chroboczek_web_790> Mike, please see page 32 of https://www.eduroam.org/wp-content/uploads/2020/02/GN3-12-192_eduroam-policy-service-definition_ver28_26072012.pdf
[13:29:11] <Cullen Jennings_web_924> Good point from Lenox.
[13:32:37] <Chris Wendt_web_971> Is there a requirement to support servers that are behind NATs?  I assumed not. But in general i think need TCP fallback. (People broadcasting from hotels, etc.) This is why RTMP just works, so anything that can't be as ubiquitous as RTMP would be a fail.
[13:35:48] <hta> RFC 8835 (rtcweb-transport) mandates support for ICE-TCP candidates.
[13:36:09] <Mike English_web_994> Juliusz, yes, scheduled and unscheduled maintenance requirements. From an operational perspective, we also appreciate approaches that give us flexibility to direct clients to other endpoints as gracefully (or as quickly) as possible.
[13:38:45] <Jonathan Lennox_web_748> Chris: I don't think there's a requirement for servers that are behind NATs they don't have an intimate relationship with -- i.e. a NAT is fine, but only so long as the server has a way to discover its external address in advance and advertise it.
[13:39:36] <Chris Wendt_web_971> Right makes sense, thanks Jonathan
[13:40:37] Alan Ford_web_861 leaves the room
[13:40:38] <Cullen Jennings_web_924> The network just described is far more common than you might hope for
[13:40:41] Alan Ford_web_242 joins the room
[13:40:45] <Mike English_web_994> To be clear, we need the server to be aware of not only it's public IP address, but also whatever UDP port(s) are appropriate for a given client session to use, right?
[13:41:05] <Jonathan Lennox_web_748> Yeah.
[13:41:33] <Luke Curley_web_573> I would say that we should support the client's IP address changing (roaming or NAT rebinding), but the server should remain static
[13:42:01] <hta> If the client makes the offer, I thought it was obvious that the client could propose what it wants.
[13:42:21] <Juliusz Chroboczek_web_790> mic: I disagree with this assessment.  You stream video + audio + slides + virtual blackboard.
[13:42:33] <Jonathan Lennox_web_748> "The" server remains static, but some provision for server failover (for HA purposes) is probably a good thing.
[13:43:02] <Cullen Jennings_web_924> @Juliusz - would be awesome if you wrote an email to the list about the network problems. 100% agree and seems like great set of requirements for this group
[13:43:12] <Juliusz Chroboczek_web_790> Cullen, will do.
[13:43:30] <Luke Curley_web_573> yeah, it would be bonus if we could migrate a connection to another server
[13:43:32] <Mike English_web_994> Juliusz - did you want me to relay that at the mic, or are you just responding the voiced comments?
[13:44:03] <Juliusz Chroboczek_web_790> I wanted you to relay it to the mic, at your leisure.
[13:44:13] <Juliusz Chroboczek_web_790> I can do it myself if you prefer.
[13:44:18] <Mike English_web_994> will do, I'm in the queue
[13:44:32] Hannu Flinck_web_801 leaves the room
[13:46:32] <Mike English_web_994> Luke: session migration (to another host) is one thing that a persistent signaling channel is useful for
[13:47:01] <Jonathan Lennox_web_748> Though in a lot of cases session migration needs to happen because the signaling channel has failed.
[13:49:46] <hta> Isn't that application specific?
[13:49:47] <Mike English_web_994> Ahh, this makes sense now. Multiple streams complicates our SDP story.
[13:50:19] <Cullen Jennings_web_924> Adam just said what I want
[13:52:15] Alexandre Gouaillard_web_542 leaves the room
[13:52:22] Alexandre Gouaillard_web_373 joins the room
[13:52:53] <Sergio Garcia Murillo_web_302> 5.  The Content Attribute
   This specification defines a new media-level value attribute,
   'content'.  Its formatting in SDP is described by the following ABNF
   (Augmented Backus-Naur Form) [2]:
       content-attribute   = "a=content:" mediacnt-tag
       mediacnt-tag        = mediacnt *("," mediacnt)
       mediacnt            = "slides" / "speaker" / "sl" / "main"
                             / "alt" / mediacnt-ext
       mediacnt-ext        = token
[13:53:14] <Suhas Nandakumar_web_682> a=content was there to support it
[13:53:17] <Jonathan Lennox_web_748> (RFC 4796)
[13:54:08] <Sergio Garcia Murillo_web_302> the only thing is if we can support this in webrtc w3s apis without a sdp mangling
[13:54:24] <Jonathan Lennox_web_748> As SDP mangling goes this is an easy one
[13:55:03] <Juliusz Chroboczek_web_790> Do we want to mandate SDP mangling?
[13:55:12] <Juliusz Chroboczek_web_790> Even in an easy case?
[13:55:15] <Sean Turner_web_193> https://datatracker.ietf.org/group/wish/about/
[13:55:21] <hta> FWIW, I think we haven't successfully designed a service since SMTP. But our components are all over the place.
[13:55:29] <Sean Turner_web_193> see the above link for how to join the WG's mailing list
[13:55:40] cm-msk@jabber.org leaves the room
[13:56:35] <Juliusz Chroboczek_web_790> IETF without weak coffee in styrofoam cups doesn't feel like IETF.
[13:56:46] <hta> Cookies!
[13:57:07] Murray Kucherawy_web_438 leaves the room
[13:57:09] Alan Ford_web_242 leaves the room
[13:57:10] <Jonathan Lennox_web_748> Juliusz: feel free to provide your own styrofoam.
[13:57:11] Juliana Guerra_web_660 leaves the room
[13:57:11] Harald Alvestrand_web_823 leaves the room
[13:57:12] <Juliusz Chroboczek_web_790> Thanks to the chairs!
[13:57:12] Adam Roach_web_243 leaves the room
[13:57:14] James Gruessing_web_827 leaves the room
[13:57:15] Florent Castelli_web_700 leaves the room
[13:57:15] Sean Turner_web_193 leaves the room
[13:57:16] Kazuhisa Matsuzono_web_669 leaves the room
[13:57:17] Timothy Panton_web_163 leaves the room
[13:57:18] Ali Begen_web_321 leaves the room
[13:57:18] Asad Saeed_web_352 leaves the room
[13:57:20] Chris Wendt_web_971 leaves the room
[13:57:24] Juliusz Chroboczek_web_790 leaves the room
[13:57:24] Jonathan Lennox_web_748 leaves the room
[13:57:24] Sergio Garcia Murillo_web_302 leaves the room
[13:57:25] Sanjay Mishra_web_486 leaves the room
[13:57:29] Suhas Nandakumar_web_682 leaves the room
[13:57:33] Cullen Jennings_web_924 leaves the room
[13:57:34] James Hurley_web_187 leaves the room
[13:57:34] Lorenzo Miniero_web_995 leaves the room
[13:57:36] Xavier de Foy_web_768 leaves the room
[13:57:38] Mike English_web_994 leaves the room
[13:57:41] Renan Krishna_web_662 leaves the room
[13:57:41] Alessandro Amirante_web_951 leaves the room
[13:57:42] Rohit Abhishek_web_283 leaves the room
[13:57:42] Chunshan Xiong_web_590 leaves the room
[13:57:42] Frode Kileng_web_328 leaves the room
[13:57:42] Bastiaan Wissingh_web_979 leaves the room
[13:57:42] Stephan Wenger_web_270 leaves the room
[13:57:42] Steve Donovan_web_345 leaves the room
[13:57:42] Lucas Pardue_web_287 leaves the room
[13:57:42] Luke Curley_web_573 leaves the room
[13:57:42] Alexandre Gouaillard_web_373 leaves the room
[14:02:44] frodek leaves the room
[18:06:21] James Gruessing leaves the room
[20:20:49] zulipbot leaves the room: Disconnected: closed
[20:24:33] zulipbot joins the room
[20:25:06] zulipbot leaves the room: Disconnected: closed
[20:38:40] zulipbot joins the room
[20:38:57] zulipbot leaves the room: Disconnected: closed
[20:39:00] zulipbot joins the room
[20:39:23] zulipbot leaves the room: Disconnected: closed
[20:39:31] zulipbot joins the room
[20:39:52] zulipbot leaves the room: Disconnected: closed
[20:42:32] zulipbot joins the room
[20:43:36] zulipbot leaves the room: Disconnected: closed
[20:52:04] zulipbot joins the room
[21:32:53] englishm-xmpp2 leaves the room: Disconnected: BOSH client silent for over 60 seconds
[21:35:24] englishm (xmpp) leaves the room: Disconnected: BOSH client silent for over 60 seconds
Powered by ejabberd - robust, scalable and extensible XMPP server Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!