We've recently been discussing on-list the relationship between SIP,  
MEDICATRL, and possible architectural decisions about the  
extensibility model for SIP that probably should have been made long  
ago but weren't.

Following a call today with the SIP, SIPPING, and MEDIACTRL chairs and  
AD Cullen Jennings, I have a proposal I'd like to make.

SIP needs to make some decisions about the extensibility model. I  
personally suspect we're going to find we have a cases where new SIP  
request types are needed, cases where new SIP header fields and values  
are needed, cases where we need to use events, cases where we need to  
use INFO, and cases where we need to convey stuff in a negotiated  
session using some sort of session/transport protocol. And we're going  
to need to give clear guidance about differentiating those cases to  
the developers of future specifications.

If we come to this agreement, then we're going to have a second  
question related to the session/transport protocol. Do we always use  
application-specific protocols (MSRP, MEDIACTRL control channel, etc.)  
or do we gain value by offering a multipurpose session/transport  
protocol that leverages SIP's negotiation mechanism (like TOTE).

I expect that it will take a while to reach consensus here, and that  
if we decide to pursue a multipurpose session/transport protocol that  
the work of specifying it will be outside of the SIP working group. We  
might have a responsibility to feed in requirements and clear  
architectural guidance.

Given that this will probably take more than a meeting cycle or two,  
and that none of us can see any way that MEDIACTRL as currently  
specified would "break" any of the potential future directions (after  
all, we can already negotiate lots of different session types), I see  
no reason to block MEDIACTRL from proceeding. Further, our assigned  
expert reviewer, Paul Kyzivat, found nothing in MEDIACTRL that raised  
an issue (outside of the architectural principles for SIP) that  
required consideration in the SIP working group.

Once we get our house in order, and if we decide to recommend a  
multipurpose session/transport protocol approach and somebody has  
specified it, then I can see a future version of MEDIACTRL possibly  
running on that protocol.

What do you folks think?

--
Dean Willis
SIP co-chair



_______________________________________________
Sip mailing list  https://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

Reply via email to