Subject: [mediactrl] Comments on Media Server Request/Control Protocol

From: "Morgan, Dave" <[email-masked]>
Date: Thu, 11 Aug 2005 20:12:52 +0100 (BST)

Chris and Tim, 

I have some comments/questions on draft-boulton-media-server-control-00. 

The first comment is that I would suggest that you stick with the name media server control protocol, otherwise if you use “request” then the acronym would be MSRP, and I suspect you would want to avoid that confusion. I also notice that your page headers say “Media Server Control.”

In section 3, page 5, editor’s note, the discussion sounds like a resource allocation problem to me. You and Roni should get on the same page here. I would suggest letting the media server have a resource manager which tracks its active, available, and reserved media ports, and let the AS query resource manager(s). This can be done through an API, proprietary interface, or perhaps more appealing through a SIP Subscribe/Notify method. Then the AS can subscribe to the states of all ports in a MS, or just the states for the ports it has requested and subsequently reserved with the MS.

Here’s a use case that I’m interested in: I’d like to have on-demand video sessions that can be added to employee buddy lists. Suppose I have three media servers, in Boston, Dallas and Luxemburg. Suppose I had the following names for these on-demand sessions the number of endpoints in ():
Boston video (6) 

Boston video (4) 

Dallas video (12) 

Dallas video (24) 

London video (4) 

Lux video (4) 
I’d like to have these sessions show up on my buddy list as available or not available (busy/DND). So if I am having an operational issue with 7 guys from Dallas, I just say let’s join the Dallas video (12) session. We join and the session then becomes busy. Of course anyone else can join as well, up to 12 participants. When we all leave the “video room” it shows up as free. 

I bring up this example because I think that the trend of video use will match audio use, with increasing on-demand usage. So resource management is very important, as everyone wants high utilization with low blocking. 

In section 5 on control channel setup I didn’t see any references to the list of codecs supported on the media server. Are you just assuming existing mechanisms take care of that so you left it out?

I’m looking forward to reading the next revision to see how you’ve flushed it out. 

Dave 

------------------------------------------------------------------------

David P. Morgan, PhD

VP, Architecture & Planning

Fidelity Investments Systems Company - Telecom

Phone:  617 563-2178

Fax:      617 385 2122

Mailing: 82 Devonshire St, MZ V8C

            Boston, MA 02109-3614

Office:   245 Summer Street, 8th Floor