[{"author": "Tony Przygienda", "text": "awful echo BTW
", "time": "2022-03-21T09:01:46Z"}, {"author": "Tony Li", "text": "Me too. I'm guessing the mic is picking up the in-room speakers.
", "time": "2022-03-21T09:02:38Z"}, {"author": "Tony Przygienda", "text": "take a cavernous room, 3 people in it, prototype voice IETF tool and here ye' go ...
", "time": "2022-03-21T09:03:18Z"}, {"author": "Tony Li", "text": "I don't think it's the tool.
", "time": "2022-03-21T09:03:44Z"}, {"author": "Tony Przygienda", "text": "good encoder should kill it or have option but agree, unlikely, it's mostly acustics ... bunch of perforareted pannels or at least wooly carpet on the floor would kill it. anyway ... ;-)
", "time": "2022-03-21T09:06:10Z"}, {"author": "Joel Halpern", "text": "Reminder that folks in the room should uses the in room tool to queue.
", "time": "2022-03-21T09:07:07Z"}, {"author": "Tony Li", "text": "Turning off the in-room speakers would probably do it.
", "time": "2022-03-21T09:10:14Z"}, {"author": "Tony Li", "text": "Better yet, a more directional mic.
", "time": "2022-03-21T09:10:41Z"}, {"author": "Joel Halpern", "text": "If they turn off the in-room speaker, people in the room (assume there were a decent number of them (not this case) would have trouble hearing.
", "time": "2022-03-21T09:11:07Z"}, {"author": "Tony Li", "text": "I think 10 feet would be ok. :) But they would have trouble hearing remote people, so ok, that doesn't work.
", "time": "2022-03-21T09:11:46Z"}, {"author": "Tony Li", "text": "Notice that this mic has less echo.
", "time": "2022-03-21T09:14:21Z"}, {"author": "Susan Hares", "text": "Keyur - which draft did you promise I would look at?
", "time": "2022-03-21T09:14:44Z"}, {"author": "Joel Halpern", "text": "Keyur, you can lower your hand :-)
", "time": "2022-03-21T09:15:56Z"}, {"author": "Jeffrey Haas", "text": "I will follow up to email, Jorge, but the issue with RD rewrite is that you must be very careful about loop prevention.  The route no longer has the same key and can loop across domains when you transform route from RD1 to RD2.
", "time": "2022-03-21T09:28:30Z"}, {"author": "Jeffrey Haas", "text": "The question was whether this procedure is done anywhere else in bess procedures.
", "time": "2022-03-21T09:29:17Z"}, {"author": "Joel Halpern", "text": "That is impressive audio breakup.
", "time": "2022-03-21T09:50:09Z"}, {"author": "Tony Li", "text": "Buffer bloat?
", "time": "2022-03-21T09:50:24Z"}, {"author": "Haibo Wang", "text": "I CAN HERE
", "time": "2022-03-21T09:50:45Z"}, {"author": "Jorge Rabadan", "text": "Thanks @Jeff. We are suggesting the use of D-PATH to identify loops... I agree with your statement, hence the use of D-PATH is needed...
", "time": "2022-03-21T09:50:46Z"}, {"author": "Jeffrey Haas", "text": "Understood, Jorge.  I'll review it in that context.  The general issue is when you transform routes, it can be problematic even if you're not otherwise losing path loop detection.  Such detection is usually only helpful when you have routes that remain comparable.
", "time": "2022-03-21T09:52:07Z"}, {"author": "Jorge Rabadan", "text": "OK, let us know if you see any issues with the use of D-PATH in this context. We think it should be enough for a given ethernet tag id, which is part of the key and what it is used at the evpn level to program the data path..
", "time": "2022-03-21T09:55:26Z"}, {"author": "Jim Uttaro", "text": "D-PATH is/was intended to provide loop protection when state was being advertised between signaling domains. That semantic seems to be overloaded here to accomplish service considerations in certain topologies. Do I have that right?
", "time": "2022-03-21T09:57:29Z"}, {"author": "Jorge Rabadan", "text": "@Jim, in a way it is the same thing, loop protection, only for EVPN L2 services, instead of IP-VRFs that was the original spec
", "time": "2022-03-21T10:00:30Z"}, {"author": "Jim Uttaro", "text": "I will take a read on the drat and comment on the list.. Thanks
", "time": "2022-03-21T10:01:34Z"}, {"author": "Jorge Rabadan", "text": "thanks!
", "time": "2022-03-21T10:02:07Z"}, {"author": "Joel Halpern", "text": "If this draft is defining the endpoint behaviors, shouldn't it at least be socialized (if not managed) in SPRING?
", "time": "2022-03-21T10:11:17Z"}, {"author": "Dan Voyer", "text": "@Joel, perhaps the archtiecture draft
", "time": "2022-03-21T10:12:24Z"}, {"author": "Joel Halpern", "text": "#Dan I have tried reading the dmm architecture draft.  That looks like it is careful to describe the mobile approach (and seems to avoid changing the 3GPP architecture.)  As such, I would expect that to belong in DMM.  It is the behavior definition that spring usually discusses.
", "time": "2022-03-21T10:13:49Z"}, {"author": "Tony Przygienda", "text": "keyur is arguing well. if 3GPP wants to be carried over IP it's kind of interesting to talk \"how\". whether it's SRv6 or some tunnel or BGP signalling is arguably to be argued ;-)
", "time": "2022-03-21T10:14:58Z"}, {"author": "Tony Przygienda", "text": "now how \"BGP is a fabric\" here eludes me ;-)
", "time": "2022-03-21T10:15:32Z"}, {"author": "Tony Li", "text": "Yeah, BGP is a dump truck, not a fabric.
", "time": "2022-03-21T10:16:23Z"}, {"author": "Joel Halpern", "text": "@Tony Li :-)
", "time": "2022-03-21T10:16:47Z"}, {"author": "Gyan Mishra", "text": "Keyur have you worked with the IETF 3GPP liaison for this solution that 3GPP is open to this solution
", "time": "2022-03-21T10:18:14Z"}, {"author": "Keyur Patel", "text": "I havent as of now and reason was as Tony P said. No changes to 3gpp
", "time": "2022-03-21T10:19:46Z"}, {"author": "Keyur Patel", "text": "@Tony L :  :)
", "time": "2022-03-21T10:20:24Z"}, {"author": "Keyur Patel", "text": "@Joel: Happy to do that if needed
", "time": "2022-03-21T10:20:56Z"}, {"author": "Tony Przygienda", "text": "closer to mike, echo is killing the sound
", "time": "2022-03-21T10:22:02Z"}, {"author": "Joel Halpern", "text": "@Keyur for now, please ssend a notice about the behavior definition drafts to the spring list.  Thanks.
", "time": "2022-03-21T10:22:09Z"}, {"author": "Keyur Patel", "text": "ack will do
", "time": "2022-03-21T10:22:25Z"}, {"author": "Keyur Patel", "text": "thanks
", "time": "2022-03-21T10:22:28Z"}, {"author": "Jeffrey Haas", "text": "Please note there's a bess-sbfd thread on the bfd mail list:https://mailarchive.ietf.org/arch/msg/rtg-bfd/Weo6kjz6uohx4fGNTygoonNoD-c/
", "time": "2022-03-21T10:39:31Z"}, {"author": "Daniam Henriques", "text": ":
", "time": "2022-03-21T10:52:41Z"}, {"author": "Tony Li", "text": "Just a wee bit o' echo.
", "time": "2022-03-21T10:52:58Z"}, {"author": "Andrew Alston", "text": "OUCH
", "time": "2022-03-21T10:53:03Z"}, {"author": "Martin Vigoureux", "text": "submarine like echo
", "time": "2022-03-21T10:53:05Z"}, {"author": "Andrew Alston", "text": "wow that was headache inducing :)
", "time": "2022-03-21T10:53:24Z"}, {"author": "Jeffrey Haas", "text": "It's at times like these that I give side-eye to all of the people that claim that modern codecs can handle open-air mics.
", "time": "2022-03-21T10:53:44Z"}, {"author": "Andrew Alston", "text": ":) He needs to go headset on his side to avoid the feedback I think
", "time": "2022-03-21T10:54:04Z"}, {"author": "Jeffrey Haas", "text": "^
", "time": "2022-03-21T10:54:13Z"}, {"author": "Jie Dong", "text": "thank you
", "time": "2022-03-21T11:02:52Z"}]