Subject: [lemonade] Lemonade Streaming and Media-Server Discovery

From: Neil Cook <[email-masked]>
Date: Wed, 2 May 2007 21:17:48 +0100

I'm just finishing off updating the lemonade streaming draft, and as  
part of that I've been looking at how best to provide media server  
discovery features to clients.

In draft-ietf-lemonade-streaming-01.txt I had the media server  
information represented by a simple host/port tuple. However, Dave  
Cridland suggested using URIs instead, and I agree - I propose to use  
URIs to represent the media servers.

For example:

ABNF (this is not formal, just indicative)

media-servers = ms-tuple *("separator1" ms-tuple)
ms-tuple = uri [ "separator2" authuser ]

This would have the following benefits:

- SIP URIs contain a "service indicator" that contains the protocol  
supported by the media server, thus reducing the amount of "fishing"  
that client have to do. For example "sip:[email-masked]" and  
"sip:[email-masked]" are valid SIP uris that tell the client  
which protocol to use.
- Extensibility is built in, since new URI forms in the future would  
allow for completely different streaming mechanisms

Issues might be:

- A single media server would potentially have multiple entries: one  
for each service that would be supported.
- When configuring media server information on the IMAP server, the  
adminsitrator has to know more than just host/port information, they  
also have to know the service type(s) supported by that media server.  
This could potentially go out of date, or be subject to incorrect  
configuration due to lack of knowledge.

Any comments?

Neil.

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: "Ben Last" <[email-masked]>
Date: Thu, 3 May 2007 08:16:50 +0100

>From: Neil Cook [mailto:[email-masked]] 
>Subject: [lemonade] Lemonade Streaming and Media-Server Discovery
>I propose to use URIs to represent the media servers.
One big benefit is that it's usually possible (i.e.: possible on all the mobile OS's I'm aware of) to hand URIs off to the OS to deal with.  Thus the email client has no need to wire in complex rules on URI handling.

>Issues might be:
>- A single media server would potentially have multiple entries: one for each service that would be supported.
Not sure that's a big deal - is there really any concept of a single media server, given that an FQDN in a URI would very probably map to a cluster of actual servers (or an Akamai-style cloud) anyway?

You may also have a single service represented by multiple entries, if the same stream is accessible via different service types.

>- When configuring media server information on the IMAP server, the adminsitrator has to know more than just
>host/port information, they also have to know the service type(s) supported by that media server.
Agreed, but surely the client must have to know that anyway, otherwise it doesn't know what protocol to use to talk to the server?

Regards
Ben

Ben Last
R&D Manager
EMCC Software

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 04 May 2007 11:19:47 +0100

> ms-tuple = uri [ "separator2" authuser ]

This seems fine, as long as syntax is unambiguous (e.g. the optional 
authuser can't be confused with subsequent URI).

> for each service that would be supported.

I surely hope that the number of services would be relatively limited, 
otherwise interoperability can be a pain.

> configuration due to lack of knowledge.

I agree with Ben that somebody has to keep this information up-to-date.

> Any comments?

I think the benefits outweigh the disadvantages.