[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lemonade] WGLC streaming Comments


On 27 Mar 2007, at 16:42, Vaudreuil, Greg M (Greg) wrote:

Resending... The policy filter ate my message.

Greg V.


2nd paragraph of section 1.  SIP does not stream media!  Meda can be
streamed using RTP or RTSP.  SIP invites such.  Wordsmithing needed


Agreed!

text following figure 1.

Bullet 0 should make it clear how the client knows whether there is a
media server and whether the media can be streamed.   Maybe just a
forward pointer to section 2.3x


Ok.

General comment. I'm not comfortable with the amount of "go fish" in
the protocol. The server is not required to support both IVR and NETANN
protocols, so the client is instructed to first try one, and if it
fails, then try the other protocol. Further, the client given a choice
of separate audio and video media servers (for example) may have to play
go fish across the set. It would be better to specify at some useful
level (top-level content-type would be sufficient for my needs) the
capabilities of the media server in the IMAP metadata, and to require
the superset IVR service. Is the idea that media server vendors
don't want to implement IVR to be LEMONADE compliant? They already have
a bunch of work to support IMAP and the expanded SIP headers (and
corresponding CTE processing).

Hmm, I wouldn't like to specify the capabilities of a particular media server in the metadata, as that information could quickly go out of date, e.g. a media server could be upgraded to support new media types and the IMAP server would not necessarily (imo almost certainly not) be updated with that new information.

The issue is not that media server vendors wouldn't want to implement IVR to be LEMONADE compliant, the issue is more about how to discover, without "fishing" as you put it, the capabilities of a set of LEMONADE compliant media servers from a LEMONADE compliant IMAP server. I would assert that static configuration is bad, in fact potentially worse than fishing.

In my experience, although the document gives the example of an audio- only media server as an example to show how negotiation could be done, in practice all the media servers I have worked with in the recent past actually support a wide range of audio and video codecs.

Content-transfer-encoding. I should be more up-to-date on IMAP
binary... I don't have a version in my cache and this is an airplane
message. But could we not simplify things by requiring the media server
to always use a binary fetch and requring the IMAP server to strip the
CTE to binary? Saves a SIP extension and teaching media servers about
CTE. IMAP server already has to do binary for LEMONADE... My memory
suggests we required the ability for the server to unwrap CTE's for
client-server BW savings. 

IMAP URL doesn't support binary fetch. If it did I would be happy.

Section 3.

Why should a client trust a particular media server? "Bad news, your lab
results show you are....." The client authenticates to the submission
server, so there is some reasonable expectation that the server is
authorized to see message content. There does not seem to be any
equivalent for the media server. Maybe there is more trust if you found
the media server identity in METADATA from the IMAP server? I don't
know if this needs a fix, but it needs a mention in section 3.

I will mention it. I think if you get the media server identity from the IMAP server then there is implicit trust. Otherwise, the media server is configured by out of band means, and I have no way to determine the security or otherwise of such a method, other than to mention it.

Section 4.

This discussion seems to be limited to Forward-Lock DRM. Crypto-based
DRM may use separate solutions that are between the media server and the
client, where the client provides necessary gunk to unlock the blob
fetched by the media server. Such solutions don't require any extension
to URLAUTH.


I will re-work the DRM discussion. Further comments on suggested text are welcome, as it is not a particular area of expertise for me.

Neil.




_______________________________________________
lemonade mailing list
lemonade at ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade