Minutes of the DISPATCH WG Session at IETF 78
=================================================
Meeting chaired by: 

• Mary Barnes and Cullen Jennings

Minutes produced by Mary Barnes based on detailed notes (included below)  by Richard Barnes and Christian Martin.

In addition, the DISPATCH Adhoc for Telepresence are included below.

Jabber scribe: Marshall Eubanks - transcript at  http://jabber.ietf.org/logs/dispatch/

Slides presented included in the proceedings.

Tuesday, July 27, 2010
================

Topic: Agenda Bash

Discussion led by: Chairs

Topic: Session ID (SIPSCOTCH)

Discussion led by: Hadriel Kaplan 

Charter proposal: SIP Scotch

The problem was described as providing a mechanism for monitoring/debugging tools to correlate messages within a session.  A primary issue is that B2BUAs change call-ids, thus the need for a single identifier in the form of a Session-ID, which is a pseudo-random 128 bit value.  The intent is that a UAC or middlebox could add the header to all requests, responses and out-of-dialogue requests.  It was suggested that to ensure interoperability, the usage with various headers should be documented. The proposal was to form a WG to define a solution for the problem, however, there was little discussion on the charter specifics.  The scope of the problem was not well understood - for example, there is one view that this Session-ID could be used to correlated dialogues and not just for debug.  

Conclusion: There was consensus that this is a problem worth solving, however,  there is not yet clear consensus on the scope of the problem and relevant use cases. Discussion to continue on the mailing list - focus should be on the charter scope rather than on solutions at this point in time. 

Topic: Telepresence

Discussion led by:  Allyn Romanow

Charter proposal: Telepresence

Related Documents:

Initial discussions clarified the context for this work, in terms of other SDOs, proprietary protocols and existing IETF work.  The latter is included for consideration in the charter.   It was clarified that IMTC is bringing the problem so that it can be solved in IETF.  Concerns were raised with regards to extending TIP in the IMTC, however, it was clarified that there is no intention to do such.  As far as the ITU-T work item, there is already a note in the charter with regards to considering work in IETF and the ITU-T focus is H.323 and SIP Gateways and not SIP protocol specifics -i.e., IETF does the protocol and ITU-T defines the service.

Conclusion: The conclusion of the WG discussions and the adhoc were that the charter needs to be updated and discussion (on the charter) needs to continue on the DISPATCH WG mailing list. 

Topic: Tel-URI Enhancements

Topic: Verification Involving PSTN Reachability (VIPR)

=======================================================================================

DISPATCH WG minutes by Richard Barnes:

Hadriel Kaplan: SIP Session-ID
-- Problem: need a mechanism for monitoring/debugging tools to correlate messages within a session
  -> Howevere, many B2BUAs change Call-IDs (more than just SBCs)
  -- ... e.g., to hide IP addresses that show up in Call-IDs
-- Could we a more limited Call-ID?  draft-kaplan-sip-secure-call-id does topology hiding part
  -- Hard to get the many middle-boxes out there to not generate new Call-IDs
-- Proposed solution: Pseudo-random 128-bit value in a Session-ID header
  -- ... in all requests, responses related to a dialogue, even out-of-dialogue requests
  -- Can be inserted by UAC or a middlebox
  -- Extension to Refers-To header to indicate Session-ID that should be used
-- Proposal: Create a new WG to develop this proposal
-- What if evil users try to learn IP addresses using Session-ID?
  -- Not a real concern
-- Other open issues:    -- Use a single fixed, mandatory algorithm?  Or make it optional?
  -- What to do with Join header?  Not trying to address conferencing as a single sesion
-- Q(Keith Drage): You said "we don't need to document it unless it's necessary for interop"
  -- If people start using it for undocumented purposes, you can get boxed in from extension
-- Q(Christian Martin): Wouldn't this lead to the use of an opaque field for end-to-end communication?
       -- Maybe we should generically say "this is opaque e2e data, first type is session-ID
       -- A: One risk here is that middleboxes will now try to delete this header
       => We need to make this as innocuous as possible
-- Q(Marshall Eubanks): Looks like a nonce. What are the implications of collision?
       -- A: Just troubleshooting, shouldn't cause any dialogues to fail
       -- Guess this argues for making the algorithm mandatory
-- Q(Parthasarathi Ravindran): Do you really need an ID for this?  Things are already correlated on each hop by Call-ID
       -- A: That only works in very limited scenarios, in particular not in peering situations
-- Q(Jonathan Lenox): The boundary between B2BUA and conference server is kind of fuzzy; what if the B2BUA adds a leg
       -- A: Think that's another Session-ID
-- Q(Spencer Dawkins): In SIPCLF, we discussed something like this, and in/out Call-ID as an alternative
       -- But that require you be able to observe all the Call-ID changes
-- Mary Barnes: Ok, HUM on charter?
-- Cullen Jennings: We haven't had the discussion
-- HUM: Is there a problem here worth solving in the IETF?
       -- Strong in favor, few (single digits) against
-- HANDS: Who is willing to work on this?
       -- 6-8 people
       -- Spencer, Dale, Musgrave, Roland, Hutton, Elwell, Laura, Drage
-- Robert Sparks: Is anybody here still thinking that this has anything to do with correlating dialogues?
       -- Some people are shaking their heads 'yes'
       -- Not sure that people really understand the scope here
       -- Cullen: So it's not fate sharing; what's the definition of what we're identifying here?
       -- Hadriel: It's what Call-ID would be if it weren't being changed
               -- It's for troubleshooting, since it's not used in the session
-- Daryl Malys: Concerned about creating another header ID      -- Rather than creating a new Session-ID, should we just say "B2BUAs shouldn't change Call-ID"
       -- Hadriel: That was secure-call-id, doesn't really work
-- Simon Romano: Robert's point is valid; I was thinking this could be useful in SPLICES
-- Hadriel: There hasn't been a whole lot of discussion on the list
       -- Ben Campbell: That should tell you something
-- Mary: Chairs are not sensing clear consensus on the scope of the problem
-- Elwell: Thought we were coming close to consensus on the list
       -- If we can't come to consensus here, let's make a plan to do this quickly
       -- Cullen: To be clear, discussion should be of charter, not mechanism/draft

Allyn Romanow: Telepresence multi-streams
-- Trying to standardize handling of multiple media streams for telepresence
-- How is this different from other video conference use cases?
       -- More requirements for immersive experience
-- Scenario: Three screens/cameras, three microphones/speakers on each side
       -- Need to know which streams go to which displays
       -- Asymmetric screens: 1-to-N is easy, but N-to-1 needs to choose a camera
       -- Multi-point sessions, each participant has a different configuration
-- Ad-hoc meeting at lunch today, discuss use cases, requirements
-- Keith Drage: Presumably this is going to build on something, what is that?
       -- Mary Barnes: Current draft charter says that it will re-use things
       -- Drage: Want something more specific, e.g., from XCON
       -- Mary: Yes, XCON, MEDIACTRL, we can add that in the charter
       -- Allyn: First task for WG is to see if you can do it with existing
       -- Drage: Should do some of that before chartering WG
-- John Elwell: The fact that the charter doesn't show any protocol work implies that they're going to use stuff
       -- That's OK with me
       -- Just seems a little heavy on informational RFCs, shades of SPEERMINT
-- Roni Even: We need a little more specificity in what we're trying to do before we can say if protocols apply
-- Harald: Have you looked at VWRAP work to see if it's relevant
-- Stefan Wenger (?): How does this relate to Cisco-proprietary TIP protocol?
       -- Allyn: TIP is Cisco's way of doing this, other vendors have others
       -- Cisco have given ownership of TIP to the IMTC, so it's under IMTC control now
-- Steve Botzko: TIP doesn't actually solve all the problems here, it still has some Cisco specifics
       -- E.g., doesn't address continuous presence
       -- So even standardizing TIP wouldn't completely solve the problem
-- Jonathan Rosenberg: Sounds a little like standards shopping
       -- Cullen: Does Cisco have any intention of submitting TIP as an I-D
       -- Allyn: No!
       -- JDR: What happens when IMTC comes up with a partial solution, then we do
               -- Don't we end up with two solutions?
       -- Allyn: Our focus is on this group; our intention is to implement the standard
               -- Opening up of TIP is an intermediate step, while standard is being worked
       -- Botzko: There current plan in IMTC is not to change TIP
               -- Desire is to build a new solution for interoperable telepresence
       -- JDR: Still seems strange to me, possible conflict
-- Stefan Wenger (?): Also some concerns about patents
       -- Would make me more comfortable if the charter said TIP will not be a baseline
-- Brian Rosen: What are we being asked to do at this meeting?
       -- Mary: Think there's been some feedback that we need to use to update the charter
-- Hasna Mustafa: How does this relate to ITU activity on telepresence?
       -- Botzko: SG16 ad-hoc on telepresence is a little broader
       -- Of course, ITU would still be responsible for H.323
       -- Charter includes coordination with IETF -- no more conflict than is usual
       -- Expect IETF to define telepresence for SIP; hope to make simple for SIP/H.323 gateways
       -- Cullen: A lot of it isn't specific to SIP or H.323, is there overlap?
       -- E.g., stuff dealing with geometry, etc.
       -- Botzko: Would hope that this work moves forward and ITU can just reference RFC
-- Marshall Eubanks: Was part of IMTC group that led to this.   -- Think discovery of existing work
-- Stefan Wenger (?): IETF is lousy at overall system/service design, ITU is a little better
       -- Vice-versa when it comes to protocol design
       -- So this could be a sensible work split
-- Brian Rosen: Think the charter is currently too open-ended
       -- There is work to be done, but it needs to be better specified
       -- They've described the problem, but not how they want to solve it
       -- James Polk: Maybe what comes out of this is just guidelines, not protocol
       -- JDR: Solution to me to be an SDP thing, so I was surprised by XCON connection
-- Roni Even: Think the idea was to find a simple solution-- [... missed a couple of people ...]
-- HANDS: Who's interested in work in this area?
       -- ~20 hands

Milan Patel: Tel-URI enhancements
-- Provide slots in SIP for ISUP parameters that provide additional information about caller
-- DAI in draft-yu-tel-dai in progress since 2006, now in 3gpp (rel8) and PacketCable specs
       -- Indicates where the "cic" parameter came from; used for billing, reconciliation
-- Jon Peterson: Is DAI only applicable to TEL URI?
       -- Draft only considers applicability to TEL URI right now
       -- Jonathan Rosenberg: This has been killed before
       -- Continued effort to pile everything from ISUP into Tel URI parameters
       -- A lot of this is describing UA characteristics
       -- A lot of these things completely ignore security problems
       -- If you're just documenting deployment, make it informational
-- Brian Rosen: Need the result of this, but not the syntax
       -- Need info from ISUP carried in SIP
       -- Many things from ISUP don't make sense in SIP -- DAI is a good example
       -- What we need to do is reliably transport those bits between gateways
       -- JDR: That's a completely different problem
-- Milan: Liaison statement from 3GPP saying that focus is on interworking with ISUP
       -- JDR: Original use case was actually from CableLabs, where origin was not ISUP
       -- Brian Rosen: CPC and OLI are actually not between gateways, but it's still transport
       -- JDR: Just trying to clarify whether we're focused on actual ISUP messages
       -- Brian: In my cases, there's always one end that's ISUP
-- John Haluska: There are cases where SIP calls terminate in ISUP?
       -- JDR: But you can also end up terminating to non-ISUP
-- Jon Peterson: We've had this ongoing tension between translation and encapsulation
       -- This seems redundant with other encapsulation schemes already around
-- Milan: Focused on origination, added by trusted entity in origin network
       -- Brian Rosen: I have use cases that don't match this, but in private networks
-- Paul Kyzivat: JDR mentioned earlier that security has never been addressed
       -- The environment in which this is imagined to work have all these trust relationships
       -- This is basically a P-header without the limited domain of applicability
       -- Adam Roach: Right, this is not a tel URI, it really is a header field
               -- Leakage, e.g., via history-info
-- Cullen: It sounds like there is a problem to be solved here
       -- Everyone at the mic says "not tel URI"
       -- So should we continue list discussion on how to do it?
       -- Brian Rosen: Yes, but we need this to happen, let's push this in some direction
       -- JDR: The argument for moving quickly is bogus, because it's been around forever and keeps coming back
       -- Sumanth: To be clear, this is not originated in CableLabs; let's discuss the problem
       -- Gonzalo: There's a common complaint that we don't know how to say 'no' and we don't document negative decisions
               -- That might be what we need to do here
-- Brian: We're discussing syntax here, what do we need to do?
       -- Cullen: Need to ask 3GPP whether anything other than a TEL URI will be useful to them
       ** ACTION: Chairs will contact 3GPP to figure this out
-- Milan: We can revise the drafts; alternative path forward
       -- Drage: If you do it with a TEL URI, you'll need a Standards Track RFC => need a WG
               -- If it's a header, you can do it as Informational
       -- JDR: If you just want an RFC stamp, you can just send it to the RFC Editor
               -- Otherwise, we need to start from requirements, find a header
       -- Adam Roach: +1 to JDR
       -- Drage: Nobody wants a rubber stamp, but we need to do something

Cullen Jennings: VIPR
-- Why phone numbers?
       -- Lots of UI
       -- Lots of existing systems use numbers
       -- Lots of social conventions
       -- JDR: Lots of established social *connections* (address book entries)
-- Why route via Internet?
       -- Lose all the new features when you have to transit the PSTN
       => Islands of rich features (enterprise, iPhone 4, etc.)
-- Why not the obvious solution?        -- Public ENUM has failed: Failure of incentive alignment
-- Overview of VIPR drafts
       -- Relies on forward routing properties of the PSTN
       -- Establish a shared secret using some property of the PSTN
       -- Use validation instead of delegation
-- Bernard: Wondering about reliance on PSTN
       -- What happens to security properties if the PSTN is replaced by SIP trunks?
       -- Cullen: Security is only as good as the PSTN [baseline bootstrap network]
       -- JDR: Security properties are primarily based on an entity providing good forward routing
               -- Not necessarily PSTN
               -- Don't expect this facility to go away
       -- Jonathan Lenox: The validation requires not only that forward routing works,
       -- ... but also privacy of start/stop times
       -- Cullen: Yes, but you're already trusting those entities to route your call
       -- Ekr: PSTN routing and confidentiality of traffic properties are not the same as call-duration properties
               -- E.g., crypto in cell network
       -- Adam: Also social approaches to determining call timings
       -- Peterson: Might not protect you from major world governments, but it has kind of an SSH-y character
       -- JDR: You can also use multiple calls to add entropy;
               -- In-band media solutions/steg are probably better, but more complex
               -- Let's not let the perfect be the enemy of the good
-- Roni: There is a problem here, OK with charter
-- David Bryan: Generally like the idea of what we're doing here
       -- Little bit bigger question: Could you also use this DHT to assert IDs?
       -- Would like to enable eventual integration with people who "own" phone #s
       -- Cullen: Wasn't our initial focus, but could probably be done
       -- Also, can look at sharing contacts among friends
       -- Nonetheless, out of initial scope
       -- David: Need to keep focused, with some openness for the future
-- Hadriel: Don't quite understand the problem.  What's the motivation?
       -- Cullen: The motivation is having two video phones do video
       -- If every service provider upgraded, then it could work
       -- Parallel to SPEERMINT/SIP Forum sort of work
       -- Hadriel: So focused on video?
       -- Cullen: No, all the benefits of IP multimedia
-- Hadriel: Are you worried about the havoc that might result from direct p2p communications?
       -- High rate of failure could cause people to fix things
       -- Cullen: Expect many people will deploy SBCs at the enterprise edge
-- Hadriel: Can we just do this in P2PSIP?
-- Ekr: Don't like the threat properties of the current algorithm
       -- Not perfect being enemy of good, it's about risk of making things worse
-- JDR: It's not that SPs are slow to add features, it's also the chaining of carriers
       -- All of the carriers between the two endpoints need IP connectivity && all features
       -- This is a fundamental consequence of PSTN architecture vs end-to-end principle
       -- Want to be able to work at IP speed instead of PSTN speed
-- David Bryan: Do you see extensions/changes to SIP proper that will be needed?
       -- ... or is most of this applications/mechanisms using the DHT?
       -- Cullen: Spam part has a header to carry a token, but any WG can define a header
-- HUM: Should we work on this problem of allowing a call controller to organically build up a contact DB
       -- Strong in favor, none against

DISPATCH WG minutes by Christian Martin: