Feb 8, 2006 DMSP Telecon

Present:  
Jonathan Engelsma (Motorola) 
Gregg Daggett (IBM)
Chris Cross (IBM)
George Refseth (Opera)
Andrew Wahbe (VoiceGenie)
James Ferrans (Motorola)

1. Chris circulated rev 3 of the DMSP draft charter - added a list of milestones to the end of the charter.

2. Chris has sent in an official request for the DMSP BoF at the March meeting in Dallas.
DMSP protocol is requested to be within the Real-Time Application area (where MRCPv2 now resides).
Approval for the BOF is still pending, but Chris expects we will get the approval.

3. Chris reported public IETF mailing list for DMSP has been established.
See https://www1.ietf.org/mailman/listinfo/dmsp

4. Jonathan reported that DMSP draft was re-posted on IETF website:
http://www.ietf.org/internet-drafts/draft-engelsma-dmsp-01.txt

5. Jonathan presented some of the DMSP performance-related data gathered at Motorola

Discussion:

A bit of discussion about java contribution on latency vs. network contribution to latency. Jonathan suggests that the former contributes some, but network is the bigger contributor.  Opera Mini is Java and performance is no worse (maybe better) than a lot of WAP browsers that are firmware.

George: Mini just renders, the "browser" is really in the network.  Suggests that the link between client and network-based proxy could be very domain specific.

Andrew: Mini is a distributed browser implementation - visual modality is on the client.

George: Yes, but very little is on the client, mostly in the network.

Chris: DMSP defines a certain level of events.  Are you implying its not the right level for Opera Mini?  More analysis needs to be done.

George: Not right for client to network-based render, but probably ok for renderer <-> voice server interface.

Jonathan: Suggests this will likely be the case with any clients on low bandwidth/hi latency wireless packet data at present.

Chris: But George is saying level of events in DMSP is ok, its more a matter of how the endpoints are defined. Mentions Interaction Manager from OMA arch. 

Andrew: IM is a separate issue, i.e. not needed here.  SIP separates media flow from control flow. You could have a network-based DMSP client that hides the fact it is actually distributed, so the DMSP protocol should not be impacted.

Chris: agrees.

Jonathan: Are we saying DMSP need not be concerned with network/client-specific constraints, and those are dealt with as implementors see fit?

Chris:  No, ecosystem needs to be completely standardized.  Define DMSP at logical level and companion specs can describe bindings onto various protocols.  For example, DSR frontends are standardized by ETSI, but IETF RFC's exist that define in detail how they get mapped into RTP payloads.

Jonathan: Right.  This is the sort of things we need to discuss and settle on up front as it impacts what we will do as a working group and what spec(s) we aim to write.

Jonathan: The consensus seems to be to keep the DMSP protocol itself simple (at logical level), and allow architecural variations and transport issues to be defined in companion IETF RFC's.

Jonathan: Suggests that in the short term we discuss various transport/payload options for DMSP, e.g. how DMSP might be carried over SIP.

Chris: Agrees to present some of IBM's prior work in this area on next call.

Next Call: February 22, 2006.  10AM Eastern Time