W3C home > Mailing lists > Public > ietf-discuss@w3.org > September 2000

Re: Mobile Multimedia Messaging Service

From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Date: Sat, 16 Sep 2000 21:49:05 -0400
Message-ID: <39C42311.DED00FFE@cs.columbia.edu>
To: vint cerf <vcerf@MCI.NET>
CC: Patrik Fältström <paf@cisco.com>, "James P. Salsman" <bovik@best.com>, Jim.Mathis@Motorola.com, ned.freed@INNOSOFT.COM, discuss@apps.ietf.org, ietf-mmms@imc.org, ietf@ietf.org
Depending on the assumptions, it seems that either capability discovery
integrated with the actual protocol or a separate protocol (as in
rescap) makes sense. (Among other considerations, this depends on
requirements for setup delay, number of message exchanges or
restrictions on information access.) For interactive multimedia
communications, there is a nascent SDPng effort to describe
capabilities, with the current version of SDP being used in RTSP, SIP,
SAP and Megaco/MGCP. This work is still in the requirements stage, but
it may well borrow from the content negotiation work, but some
requirements differ somewhat.

vint cerf wrote:
> patrik,
> would it be useful, in the context of establishing peer-to-peer communications
> (or even client/server communications) with limited-function mobile devices,
> to use SIP as a framework for negotiating the parameters that should guide the
> nature of the exchange? I'm thinking, for instance, of a web server that may
> usefully discover the functional limits of a mobile before it starts to send
> content to that device. The mobile uses SIP to report to the server that it
> has X amount of memory, Y amount of display area, color or not, average
> data rate it can send or receive, and so on. This information would be used
> by the server to configure what it sends to be compatible with the receiving
> unit.
> perhaps this is an idea that is already being pursued in an IETF working group?
Received on Saturday, 16 September 2000 21:50:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:08:09 UTC