Chris, Thanks for pointing this out - I hadn't looked at the mediactrl-framework before and there is definitely overlap and a relationship between it and TOTE.
Here is my analysis on the similarities and differences: Both of them are about establishing connections between agents through an O/A exchange. Mediactrl uses comedia, whereas TOTE uses ICE-tcp. ICE-tcp will fall back to comedia when both sides are unnatted. TOTE, however, provides a layer of demux within the SDP signaling, allowing for negotiation of what runs over the channel as part of the O/A negotiation. In mediactrl, this is done within the control channel itself, by doing a supported kind of exchange over the mediactrl protocol. TOTE and media-ctrl framework both define a simple message protocol that runs over the connection. This is lighter weight in TOTE; its just for framing and purpose demux. mediactrl defines specific messages - control, report, synch, etc., transactions, response codes. Mediactrl solves the problem of binding a connection to a dialog by defining a SYNC message. TOTE solves this problem by using ICE, which provides this correlation as part of its normal operations. Mediactrl solves the problem of keepalives using its own keepalive message; TOTE uses the ICE keepalive mechanism. Since TOTE is a bit lower-layer than mediactrl, one model is to think of running mediactrl over TOTE. Mediactrl would then be a specific "purpose" parameter. When you do this, a bunch of features would get removed from mediactrl - all of the SDP stuff, connection establishment, synch mechanism. Mediactrl would continue to define the notion of control packages, control package negotiation, REPORT, CONTROl, response codes, transaction rules, etc. I think thats a good story - instead of each and every protocol (like mediactrl) needing to worry about this lower-layer connection management and connectivity stuff, we solve it once, and provide a framework for reusing connections across different protocols and applications. So that one tcp connection between me and my media server could be used for mediactrl messages, streaming commands, picture transmission, etc. -Jonathan R. Chris Boulton wrote: > On Feb 20, 2008, at 12:28 AM, Ted Hardie wrote: >> . If the idea is that the specification of >> "pic" or "name" is at the level of the specification of an event >> package, >> then we are dealing with something else entirely and the draft can >> be re-written to express that. But I would expect, in that case, >> for each >> of the registered purposes to be very carefully specified as to what >> the >> acting application would do with them. And I suspect pretty much >> everything like "name" would have to go. > > Ok, I think I agree with you here. Each "purpose" would need to be > very clearly specified, at roughly the same level of detail as is > required for an event package or would be required for an INFO package > if we were to go that way. And yes, the draft is a bit short on this > right now. > > [Chris Boulton] BUT then we are just recreating the Control Framework > (http://www.ietf.org/internet-drafts/draft-ietf-mediactrl-sip-control-fr > amework-01.txt) from the MediaCtrl work group - just called a different > name. I'm not sure why we can't just use that. > > Chris. > > > -- > Dean > > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use [EMAIL PROTECTED] for questions on current sip > Use [EMAIL PROTECTED] for new developments on the application of sip > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use [EMAIL PROTECTED] for questions on current sip > Use [EMAIL PROTECTED] for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group [EMAIL PROTECTED] http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
