SPLICES meeting minutes By Simon Romano (spromano@unina.it) SPLICES session at IETF 81 can also be viewed in the form of a recording with synchronized video, audio, slides and jabber chat. To download such material, please go to the following URL: http://ietf81.conf.meetecho.com/index.php/Recorded_Sessions - Intro by the chair: Meetecho recording reference: http://77.238.22.57/Recordings/watch.jsp?recording=splices&chapter=Agenda Just a quick introduction to the two session presentations: (i) Disaggregated Media in the Session Initiation Protocol, by Salvatore Loreto; (ii) The Session Initiation Protocol (SIP) INVOKE Method, by R. Shekh-Yusef. - Presentation by Salvatore Loreto on the proposed Disaggregated Media framework. - Salvatore's talk: Meetecho recording reference: http://77.238.22.57/Recordings/watch.jsp?recording=splices&chapter=DisaggregatedMedia Some background on the framework document (which we have been discussing extensively during the last year). Consensus in Prague was to avoid putting requirements on the receiver's side. We are hence trying to make the role of the (3PCC-like) controller flexible enough to allow any of the federated parties to take that role at any time, with no need to implement any special mechanism. In order to implement such distributed call control feature, a number of requirements have to be met, as illustrated in draft-loreto-splices-disaggregated-media-02. Salvatore then presents a use case associated with the departure of one device, which highlights an open issue related to device departure discovery, as well as dialog replacement. This is something we have not yet discussed, but we do believe it is something that is feasible. We have discussed on the ML several scenarios, which however do not seem to present significant issues (so, they're not on the slides). No questions for Salvatore. - Second talk, from Rifaat Shekh-Yusef, about the SIP INVOKE method Meetecho recording reference: http://77.238.22.57/Recordings/watch.jsp?recording=splices&chapter=SIPInvokeMethod As per IETF80 in Prague, some background on SIP Action Referral, which uses the REFER method to invoke actions on a UA. Feedback from Prague was to define a new SIP method, since REFER is deemed to be overloaded. The SIP INVOKE method nicely fits RFC5850 (dealing with a framework for call control and multiparty usage of SIP). Its model concerns a call control method extending the already allowed REFER method actions. Open issue: can actions influence the state of some "physical features" on the remote UA (e.g. attach/detach a session to/from a transducer?). We think it should be allowed just in the context of that specific action. John Elwell at the mic: Can you clarify a bit on the scope of the method? Rifaat: What I'm saying is: if you have an incoming call and you want to answer that call, you can, e.g., instruct the remote UA to use the headset, or the speaker. John Elwell: What if during the call I want to change from headset to a different transducer? Rifaat: You're not allowed to do that with this mechanism. This is not a device control mechanism. John Elwell: I'm just concerned, aren't you just covering half of the problem? Rifaat: I don't think it is half, but, yes, it might :-). INVOKE is a non-dialog-creating method allowing a UA to invoke a well-defined action on a remote UA. Draft draft-yusef-splices-invoke-01 also defines a new event package specifically conceived for action monitoring purposes. Two categories of actions currently defined: call and conference. Rifaat also presents a Finite State Machine for an INVITE-based dialog, showing how most of the INVOKE actions fit into it. Andy Hutton at the mic: Are you saying that with this mechanism every action is going to result in a state change? Rifaat: Yes, that's what we are proposing right now. Robert Sparks at the mic: No, there are example sin the draft where things stay incative all the time. Andy Hutton: There seem to be some inonsistencies with what you stated earlier, things like "send to the other end...". Rifaat: I can send to the other end with a 302, I don't see the problem. And going back to Robert's comment, you can stay in the same state by seding a re-INVITE. Capabilities indication takes place through the use of both an option tag and a feature tag (for the supported actions). Dale Worley at the mic: The options tag "invoke" seems to be redundant, if you consider the use of the "Allow" header. Rifaat: Oh yes, sorry. Why SIP? SIP already solved network reachability problems. Thanks to the REFER method, it also allows a UA to invoke actions on a remote UA. Furthermore, it nicely fits into RFC5850 framework. People lining up at the mic... Jon Peterson: I'm familiar with some of the stuff you mention in your slide. I don't think 5850 is a document; I would rather call it an example of how SIP was supposed to operate. Its long and controversial history definitely acknowledges this perspective. (Talking to Alan Johnston): It's an informational document, a framework, not a protocol standard. So, I think all these things should be done in a media gateway control protocol. Robert Sparks: I'm going to repeat something that has been said previously about using REFER to a URN (as the editor of that document). The intent of the semantic for REFER was to hand a URI to something and have the thing done with that URI more or less be equivalent to what you'd get by clicking on it. You started down a different path. You started working on an approach whereby you have one method for one of these things that we want to do. Let's do a wrapper method and do all these things inside this wrapper method. And that's where we get into "why not SIP" in response to this slide. Because you really are looking for a lightweight activation protocol. You're trying to couple these actions to a SIP transaction with a single method. This is going to be impossible to implement, especially if you think of things like specialized INVOKE error responses. You really are talking about a small control protocol. So use SIP, set up a connection, do the small call control thing across that connection. Alan Johnston at the mic: I just came to the mic to argue about the call control framework, a document we worked on for many years. Doing call control operations with SIP is still something we're working on. I think 5850 does represent a consensus of the community. If people think 5850 is completely wrong, then open it up and see if there is consensus for changing it. In my view we can still do this with REFER. Tha approach Robert described is just way heavy weight and no one would do that. Adam Roach at the mic: I do want to respond briefly to the assertion that creating a new protocol guarantees that we are not going to have any standard and point out that we already have examples like BFCP, with people coming out with different implementations. Rifaat: Take this example: If you want to terminate a call you can use REFER and now if you want to decline a call you're saying you have to use a completely different protocol. Adam Roach: As Robert pointed out, you're gonna get into a situation where you eventually define a new protocol. The second point I'm gonna make concerns the two frameworks you cited. The argument you are making can be easily correlated with "you should use those protocols for conference control" and we've already as a community rejected that. Rifaat: That's different, since there you are extending the scope of SIP and letting it become much wider (see, e.g., the CCMP in XCON). We are not extending the scope. Adam: I can give you for granted that in the end you will go well beyond the scope of what's described in 5850. You're going closer and closer to the device, as opposed to just "call model". Dale Worley at the mic: I agree with what Robert said. SIP request/response is actually the one thing that you know can get through the system that you've got. Most of the things that you talk about in the draft bring you to a complexity problem if you really have the actions become more complex. It seems that you get stuck doing something like ECMA TR/87, that has all the precision you can possibly want. And the question is can you actually make a small set of operations that are sufficient? Mary Barnes at the mic: You can do all this with mediactrl. You just have to define a new control package and use it with the existing framework. Dean Willis at the mic: I kind like the approach that you're taking with the INVOKE. It recalls me of the SIP DO method, which basically says "do this"; or even the SOAP over SIP protocol. Just because we had these ideas (people laughing in the room...) we lost those arguments and we lost them for very good reasons which have to do with what is a SIP UA entitled to do. So if we go back to the hystory of those arguments, we can avoid repeating those arguments now. Robert Sparks at the mic: Well, the current proposal is even worse than SOAP over SIP because the SOAP over SIP was actually carrying commands. This approach is carrying a "string" that the commander has defined somewhere else. You can't ignore the basic point that what you have to do to do what you want will be a protocl tunneled inside SIP transactions. You're going to wrap another protocol and carry it inside SIP. When you're done, if you go down this path, that's what you'll have achieved; and that will not be easy. Cullen Jennings at the mic: I agree with most of the statements that have been made. But we're misisng a point: what we are talking here about is mainly a matter of incremental deployment. PBX manufacturers are using SIP between their PBXs and their phones and they will not look favourably at a new call control protocol. The approach proposed with the INVOKE is a deployable path. ?? (no name at the mic): First I have an existence proof of another protocol which wasn't in fact layered into SIP correctly, which was MRCP...and is widely deployed. Let's rewind back 11 years. The extensibility model for things like this wasn't in fact to invent new "generic" SIP methods. The problem with this is that we're not inventing a particular method to do a particular function. We're inventing a SIP method for an encapsulator for an unbounded set of functions and I think that's what scares everybody. Rifaat: Is the problem with the INVOKE method or is it with the semantics of invoking actions, which might also be done through the existing REFER method? ?? (same person as above): What I'm saying is that an action is an unbounded Turing machine. The original extensibility model of SIP was that if you needed it to do something specific and there was no specific method for this, then you designed a new method speficically tailored for that action. Robert Sparks: Let me put this a bit differently, so that you can understand. If you want to avoid the complexity of building a new protocol inside a SIP transaction, the only choice that you have if you're using SIP is to have one method per each of the actions that you define. Simon Romano (as an individual): Just some background on the recent history of the SIP INVOKE method, which was born as a simple extension of REFER and then designed form scratch as a new method (after the discussion we had in Prague at IETF 80). My personal opinion is that what Rifaat et al. are proposing is useful and does not fall in the wide category of device control approaches. As a mediactrl guy, I would say that the mediactrl approach is perhaps too heavy if what we want is to implement the simple mechanisms proposed in the INVOKE draft. There are people interested in the proposed approach, so why shouldn't we go ahead with this work? Andy Hutton: I really think this approach is not call control. You're really talking about device control. You'll have to model the device, to model the interations between the session and the device, etc.. Rifaat: You keep on talking about device control and we're clearly not working on that. Andy Hutton: I think you are. Cullen Jennings: There is a sort of narrow set of customers that I'm trying to find a solution for. It is a set of people with enterprise PBXs, B2BUAs and Proxies who are trying to find alternatives to CSTA. Paul Kyzivat: Andy said most of what I wanted to say. Rifaat: Same as above: you're talking about device control control, which is not our goal. Dale Worley: Three things: 1. I agree with Cullen that a single method has to do a single thing. This rule was violated well before I got into SIP (see the recent REFER method draft); 2. The difficulty on working on new methods in the IETF would be proportional to the number of methods that you define. We say: there are seven actions we want to do for call control and we introduce seven distinct methods for this purpose; 3. (following what Paul said) Are we tunneling a new protocol through SIP? In other words, are we introducing additional state that has to be kept track of in SIP transactions? In such case, that's a warning that you are really doing a new protocol. Jon Peterson: There is a better idea than designing separate methods per each action. The idea would be to get "some" straightforward actions and implement them through straightforward methods. This would be achievable in the IETF. Cullen Jennings: I just want to comment on the CSTA stuff. Again, the people that might be interested in the INVOKE stuff, are not looking at CSTA as a valid alternative, for business reasons. Final discussion on next steps for SPLICES. First question: is this work something that we deem worth doing in the IETF? Second question: if so, is SPLICES the right place for doing this work? Robert Sparks: You have got an answer to the second question already. Gonzalo had framed this discussion on the mailing list, and the idea is basically to bring this back to DISPATCH, since it was not in the intitial charter of the SPLICES wg. The same applies to the first question, since that is exactly the conversation that Gonzalo wants to be held inside DISPATCH. We had this conversation here today because of scheduling constraints. Simon Romano: So there's nothing we have to decide now. Robert Sparks; You can poll people for opinions... Simon Romano: I think that the people who wanted to discuss have already stated what they had in their minds. Adam Roach: I want to make sure that, if you have to ask the question, you're going to separate "what" you're doing (e.g., controlling a call or a device) from "how" you're doing it (e.g., inside or outside SIP). Cullen Jenings: the questions would be: should we bring this to the next meeting (probably inside DISPATCH)? Should we bring a set of drafts that is one method per action? Or should we just not bother with that? Mary Barnes: Just to clarify (as a chair of DISPATCH): you do not bring solutions to DISPATCH; you just bring there problems that you want to solve. Robert Sparks: I think that having a discussion about how to do this kind of control is far beyond what SPLICES was chartered to do. So I suggest that if you want to achieve this in the constraints of using SIP as a transport means, you can write down a charter proposal which takes into account all the discussions we had today in this room. There are, anyhow, other (alternative to the definition of multiple methods, one per action) potential ways of achieving the same goal. One of this would be the definition of a proper event package. Rifaat: Can I ask the group it they think that the one-method-per-action approach is feasible? Paul Kyzivat: I cannot answer that question in general; I can answer method per method. Simon Romano: I think that the message we got from the room is that we still have to discuss all of the items we touched upon today and there is no decision we can take right now. Besides, the right venue to discuss is is not SPLICES. So everything is going to be shifted to DISPATCH from now on. Dale Worley: Going back to Rifaat's question. We can certainly try one method per action, but I can figure out it can become way too complicated to manage. Paul Kyzivat: I've lost track of how all this relates to disaggregated media. Simon Romano: Me too! Paul Kyzivat: I think that SPLICES should still have the original goal of properly coordinating disaggregated media, which can be viewed as a separate problem, much narrower and which does not need a further pass through DISPATCH. Simon Romano: My personal feeling is that the original idea behind SPLICES was in some way much more revolutionary than what we have arrived at now. We decided in Prague not to work on that original idea with the approach that had been proposed by the authors of the disaggregated media document. Gonzalo Camarillo: Today in mmusic they were discussing a draft that actually might fit the current SPLICES charter. So I wouldn't say that there is nothing to do in SPLICES. There are still a few things that can be done. With respect to the discussion you had today, I'm not currently up to date at this point, since I was in a different room. Adam Roach: Are you saying that the work that has been done with the architecture has no value? Simon Romano: I'm saying that it had a huge value, but nonetheless it as been constrained quite a lot. Adam Roach: You're referring to the model that required far end support? Simon Romano: Yes. Adam Roach: But what I'm seeing in the model right now is useful, architecturally. Simon Romano: OK, we'll try and take your advice. See you all, perhaps, at IETF 82 in Taipei!