SPLICES meeting minutes
By Simon Romano (spromano@unina.it)
SPLICES session at IETF 80 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://ietf.conf.meetecho.com/
- Intro by the chair, just to introduce the two session presentations, dealing with the framework and theAction Referral, respectively.
- Presentation by Salvatore Loreto on the proposed Disaggregated Media framework.
- Salvatore's talk:
Salvartore says that he is aware of the fact that 3PCC can solve some of the issues analyzed. Should we leverage existing mechanisms, or should we go for a brand new mechanisms?
We need two things:
1. How to coordinate different devices involved in a call and associated with a single user;
2. How to let the other side of the call understand that all the signalling that it is receiving pertains to the same session?
- Q&A session after Salvatore's talk:
Gonzalo Camarillo: We had a lot of discussions before chartering the group. The main point is whether we can do this with multiple dialogs or with a single dialog. Paul (Kyzivat) was arguing against the single-dialog option; other people were arhuing in favor of it.  So let's  try and get the feeling in this room.
Cullen Jennings: the current draft states there is a need for a "correlator" of some sort. What is this correlator, actually. We don't have a clear definition of this concept as of yet.
Salvatore's answer: Actually we had some discussion in SPLICES and reasoned about the Session-ID as a potential correlator. But it is not yet clear whether we need such session id, or we can do something different and perhaps re-use already existing solutions.
Cullen: Right..so let's figure out what we really need.
Dale Worley: There must be a requirement for this group, which states that the far end of the call does not have to be changed in order to support the disaggregated media mechanisms.
Salvatore: This might be preferable, but in some sense stops any innovation that you might be willing to introduce.
Dale: Let me propose that I could solve the stated problem within that requirement.
Salvatore: You mean by using some 3PCC-related mechanism?
Dale: Yes.
Paul Kyzivat: For the basic issue, as I get it,  I think 3PCC is enough. Think of the slide about "Scenarios not covered by existing mechanisms". There's no free lunch! There at least has to be some device that knows that there are other devices with which it would like to establish some kind of correlated session. If you postulate that such device has the mentioned capability, you can also postulate that it has 3PCC capability. Hence, it remains to be demonstrated that one is dramatically harder to do than the other.
Salvatore: We are not complaining about the difficulty of doing 3PCC. We're just saying that there might a possibility that one might want to do this stuff in a different way.
Paul: You need one guy that is able to set this correlated session up; and another guy who is able to "keep" it up. And now the question is which technology do we use to implement these two parts (initiating part and continuing part) of the system and in which box do they reside. And it is ovious to say that 3PCC is not sufficient to give a complete solution to the stated problem. That's why I think that the other thing you're discussing in this group (namely the Action Referral thing) is definitely relevant, since it is really complementary to 3PCC for doing all this.
Salvatore: I think that this group might also be in charge of seeing how we can improve 3PCC.
Paul: I fully agree that 3PCC, by itself, won't give the full user experience. Something like the action referral might be complementary and together they might solve the general issue.
Andy Allen: I have a similar comment as Paul. It sounds like you don't want to change the end devices involved in a distributed session. You talk about a controller functionality, but you don't want to rely on 3PCC. That's why we're having the discussion as introduced by Paul. I think this is a bit misleading.
Gonzalo: Actually we have had this discussion many times. The most important thing today is to come out with a decision shared by all WG members. In summary, the issue is whether or not to upgrade the end-points. The other important point that PAuo was making is about who is the controller. Sometimes it is actually the final human user who is coordinating the different devices; in such case, you cannot easily think to solve the issue by simply adding   3PCC functionality to the user agent. So, we have discussed this a lot and we haven't agreed on a hunanimous answer. At some point I would like to see that we make a decision and know where this working group is going. I don't want to lose this momentum and make the WG be stalled. Even if they are rough decisions, we need consensus in order to go one way or the other.
Brian Rosen: I had this exact discussion with three other WGs in various circumstances. We want to solve this problem, but please let us solve it in the simplest way. And I think you have to take into consideration that the other end does not have to upgraded in functionality. It's much better to only have one end which has to change. So, I'm more or less in line with the 3PCC party.
Jonatan Rosenberg: I'm gonna make this comment for what it is worth. Think about this: in amodel like RTC-WEB, where the client is simply a "slave" (from a complete UI control from the server), then we are done and you don't need this working group even at all. I leave you with that (and he also leaves the room...).

- Second talk, from Rifaat Shekh-Yusef, about SIP Action Referral
Current limitations of the REFER method. How to extend REFER in order to allow for the request of an Action on a UA. Definition of the sip-action namespace. Rifaat asked for: (i) adoption of the draft from the WG; (ii) de-coupling of the draft from the other WG documents.
Open issue: REFER vs new SIP method.
Discussion:
Brian Rosen: If you hadn't raised that, I would have done it for you. I think the semantics of REFER restirct you. What you are talking about is NEW behavior. I would encourage you to think about a new header.
Paul Kyzivat: I can go either way on that. I like some things of this. Some other things scare me a lot. I'm fine with this thing as long as actions specify things whose behavior is clearly defined. And that's gonna be hard, harder than most of the SIP stuff. You basically need a framework to speficy all these things. In summary: this is potentially useful and powerful, but is not easy.
Rifaat:  I agree and we want to hear from you more on this.
Dale Worley: A series of related observations. First is linked to what Paul just said. He makes a reference to his draft about the five meanings of the REFER method..
Rifaat (using backup slides, one of which is right on the target): REFER method already overloaded. Should a new method be defined to address this limitation?
Dale: I feel a certain annoyance here with respect to all the things that you might want to define as actions and which are not protocol operations.
Miguel garcia: This reminds me some methods that were proposed in the past. I'm wondering if you're aware of the consequences if you go along this path. How are we going to identify all these actions that we are doing remotely. Are we creating a registry? Are we going to somehow discover them? What are the security implications?
Rifaat: Some of those have been addressed in the draft...IANA registry, security and the like.
Miguel: I'm worried about the path we are taking. I think it is almost undoable.
Cullen: Everything that is added as an action has to have very clear semantics. Everything we are going to do has to be amazingly clear.
Andy Allen: I would lean towards coming out with a new method.
Keith Drage: Very simple question: why did you choose SIP in thefirst place?
Rifaat: What do you have in mind, HTTP?
Keith, mentioning an old discussion about using SIP to switch a tosater on :-).  -- The sense of the comment is about finding a good answer on why SIP should be the right choice here.
Cullen: Good question from Keith. The things is that we have phones (or, in general, SIP-enabled devices) and we want to control them. That's what SIP provides. From my point of view it is pretty clear that SIP is the right choice for this work.
Andy Allen: Why don't you define an INFO package for this?
Rifaat: We had that discussion before
Andy: I don't think SIP is the right chice here, to be honest.
Keith Drage, responding to Cullen: I'm not saying SIP is not the right choice...I'm arguing that what you're defining is something completely unbounded and which might have little to see with SIP.
Adam Roach: I'm a bit confused about this hypothetical SIP state machine that Cullen is mentioning and which can be accessed only thorugh a SIP stack. We're talking about an application which is going to have other interfaces. As an example, MBUS was designed for this; now there is nothing like this in the world because nobody decided to use it.
Cullen: You're right. These can be different interfaces. I think there's an issue with messaging. I also agree with what Keith said.
Adam: One of the things that SIP is good at doing is setting up sessions.
Rifaat: Actually we're trying to define this stuff in order to sharply indicate what you can do and what you cannot do.
Mary Barnes: I have a more general question: do people believe that this problem is relevant?
Simon Romano (as an individual): I'm definitely convinced there is a need for solving this kind of issues and I would personally like to have a quick follow-up discussion on the mailing list around the topics we talked about today. I do believe we can converge quite rapidly on a restricted set of agreed-upon items and proceed with work, in order to arrive at a successful completion of SPLICES' mission. 
Cullen: I'm happy to see many people here today. I did not see that much activity on the mailing list during the last months, though.
Mary: We dispatched this WG long time ago. It was officially formed in July 2010. Since then, little to no activity has taken place on the list. It is important that we decide here now what people want to do with this group. 
Gonzalo: We discussed this. If the WG doesn't get momentum between now and next IETF, we just close it down. I don't like to leave things in limbo.
Simon: Taking a hum on the following question: "Do people believe that all the burden of this service should be on the side implementing the sevice itself?"
The sense of the room by "majhum" (majority by humming) was clearly in favor of this solution. So, we cannot touch the far end of the session when designing the SPLICES solution.