Subject: [dispatch] Notes from Dispatch Meeting IETF 79

From: Cullen Jennings <[email-masked]>
Date: Thu, 11 Nov 2010 02:20:15 -0700

Chair slides 

Discussion of RTC Web workshop. More info at http://rtc-web.alvestrand.com/

Dates for IETF-80 Dispatch topics are in flux. These data are soon. Start soon. Draft dates are available on the wiki at http://trac.tools.ietf.org/wg/ dispatch/trac/wiki 

---------------------------------------------------
Telepresence

James Polk: Would like to make sure the framework covered the overall system. 

Peter: Rephrase that we are not “changing” existing protocols, we are “extending” them 

Counted 25 people who are interested in working on it. 

Looked like 15 or so are willing to work on it. 

The HUM to move forward with this charter was unanimous
. 

----------------------------------------
Info Event Package for DTMF

Keith Drage: Suggested use the independent stream to create an Info Package. 

Hadriel does now want to do an Info Package. He wants to document what people do today for Info-Relay which is not an Info Package. 

Paul Kyzivat: If we could go back in time he would do Info, but if we do Info-Package today it will just make yet one more so he is not in favour of doing an Info-Package. 

Andy Hutton: Not keen on IETF rubber stamping the hack that is out there. Unlikely people would implement implement an Info-Relay. 

Christer: Assume we will get a registration for the 3GPP package in next few weeks. 

When Mary says IETF, she does not mean the ISE. 

Does anyone think Hadriel should go define an Info-Event package in IETF. Not a single person was in favour of this. 

Who thinks the IETF should not do anything with this (meaning some solution solution in general): 

Who believes we should document the historic usage of info: 1 hand 

Conclusion was that  RAI area  has no interest in working on DTMF. 

---------------------------------------
BFCP for UDP

Adam Roach: UDP won’t interoperate with TCP. (Okay, he said a bunch more but I think that was the key assumption). Doing two things is not a good plan. TCP can be made to work. 

Spencer Dawkins: Will be do one or both. Answer from Tom - depends on use case but lots will support both.  Spencer leaning direction as Adam. 

Spencer: what is a large packet? Tom: bigger than MTU

Keith Drage: [ The audio was a bit hard and I messed up the questions and answers of this ] 
1) You are creating a new protocol. 
2) What about MSRP 
3) Precludes a TCP only implementation (now you have to do both) 

Roni said it was real problem. 

Hadriel: Is there no group for this. ANswer Tom: XCON is closing and this is being brought to DISPATCH. 

Gonzalo: Was discussed in XCON, then taken to transport, then to Dispatch. Not seeing doing a WG for this. The technical details are not hard. 

Hadriel: Questioned if this really solved the problem. Hadriel supports this work. Question if either end could be ebhind a NAT. Current draft does not solve this. Tom: could traverse with H.460. hadreil explaned that this gets through middle boxes too. Issues of how to open the pin holes. 

Keith Drage: Keith explained why BFCP was TCP only. 

Peter Musgrave: This is a hack, hack we need, hack we plan to impement. 

Gonzalo as Individual: Surprised they have not addressed the fragmentation thing. You should do this. Need to address things like Toeredo. 
Tom: about fragmentation. Proposed in draft to set maximum. 

Hadriel: What you mean there would be a max size. 

Some strange conversation about fragmentation ensued with very little worth preserving for posterity. 

Hadriel suggest using an Info-Package for this. Tom, that was considered and did not want to use it

Alan Johnston: Supports having a solution to this problem. As co-chair of XCON, would like to confirm we had discussion about multi protocol and decided to remove it. 

Spencer: If this has fragmentation, will not work ell through NATs.

Gonzalo: You need to do our homework.  We need to know if Toeredo work. 
If this for nats, Is this for media servers. I would like to move forward with this - it is a relevant problem. 

Adam: If you are worried about speed of ICE of TCP, go to mmusic and help it move faster. 

9 people wanted to work on UDP variant of BFCP. 6 people said we should not work on it. 

Mary said: there is not consensus. Suggested Tom update the draft and resolve the issues that have been raised. 

Andrew Allen: Need an analysis of what the problem is. If this does not solve the general problem, it not worth doing. 

Hadriel: Does not understand how it work when server is behind a NAT. Clearly the use case about if what sort of SBC scenarios this work with. 

Adam: Places this work, are places where ICE TCP also work. To make it work more places, we should make it work in the more general way. 

??? : What makes us think this will be done sooner than ICE TCP?

Conclusion: Ther ewere very significant concerns raised about how well this would work, why we would do  it, and why this was better than the more generalized solution of ICE TCP.