DISPATCH NOTES
Tuesday, 9:00 – 11:00
NOTES BY JAMES McEACHERN
Summary of votes:
Vote: Should we form a working group for session recording. Consensus that we should form WG. No hums against.
Vote: Is there interest in chartering a WG for Disagregate Media, subject to getting enough interest on the mailing list. Result: Solid support for chartering.
Vote: Assuming that we resolve the issue of semantic representation on the list, is there interest in chartering a WG on Alert Info URNs. Result: Solid consensus.
Interest in writing drafts = 6
Interest in participating and reviewing = 10 – 15
Action: Go back to the list and resolve the issue of semantics for Disagregate Media on the list
Conclusion: Take Reason in Responses back to the list for further discussion cause there is no consensus.
Detailed Notes:
Session Recording
draft-rehor-dispatch-session-recording-req
Charter proposal: Session Recording Protocol
Presentation at http://www.ietf.org/proceedings/09nov/slides/dispatch-2.ppt
Review of the reasons why we need a recording capability. Noted that in many cases it is actually a user requirement, although they also sometimes want to the ability to turn recording off, or ensure it is not being recorded.
Showed a variety of pseudo call flows showing recording being initiated from any of a number of possible sources (e.g. application initiated, user initated).
Jon Peterson asked if the users would be notified when recording was initiated. Answer: Yes, they would have to be, because that is one of the already identified requirements.
Alan Johnson: could be a feature tag or even in the RTP.
Cullen Jennings (as an individual). Many of these diagrams are actually showing solutions rather than requirements. Pointed out that in the PSTN recording the call details and the media were largely the same (not sure I agree with that to be honest…) but in SIP they are very much separate. We really need to start thinking about these separately and clearly articulating which aspect(s) we are talking about.
Charter proposal was put out on the mailing list about 6 months ago. Reviewed the scope, output and timeline. Output includes updated requirements, use cases, and architecture draft.
Discussion: Previous discussion identified the need for adding privacy concerns. Things were added to address this – is it enough. Jon Peterson said that the current charter mentions privacy, but does not provide any details. Needs to be added for it to be acceptable.
Cullen: Notification. Will it apply to new devices built to this standard, or will it provide notification to existing devices. No concrete suggestions, but he believes that we must be very crisp on exactly what is being covered by it. If we don’t do that, it will fail IETF last call
Vote: Should we form a working group for session recording. Consensus that we should form WG. No hums against.
Disaggregated media
draft-loreto-dispatch-disaggregated-media
Charter Proposal: Disaggregate Media
Presentation material at: http://www.ietf.org/proceedings/09nov/slides/dispatch-1.ppt
WG proposal: develop framework for disaggregated media in loosely-coupled scenarios where no single device needs to be a master, or to remain in the session for the full duration.
WG deliverables are to describe a framework and to specify mechanisms per the framework.
Proposed charter was sent to the list:
Cullen: This is a big chunk of work. Who is going to put significant effort into this, author drafts, etc. A couple of hands raised, plus there are several other people who were active on the list, who are not here today. (Plus Simon’s team, when asked later.)
Vote: Is there interest in chartering a WG for Disagregate Media, subject to getting enough interest on the mailing list. Result: Solid support for chartering.
Cullen made a plea for slides being available early as they are very important for many people trying to follow.
Alert-Info URNs
draft-liess-dispatch-alert-info-urns
Charter proposal: SIP Alert-Info URN
Slides at http://www.ietf.org/proceedings/09nov/slides/dispatch-4.ppt
Charter proposal presented.
John Ewell: Should add something to the charter to make it clear that the URNs are semantic.
Adam Roach: Agrees that we probably want to go down the semantic path, but he is concerned that we may be closing paths that we might want to pursue later.
Cullen: Thinks that we need to explicitly decide on this later. It makes life very easy for the server, but can make it very hard for the UA. Therefore too early to arbitrarily decide.
Vote: Assuming that we resolve the issue of semantic representation on the list, is there interest in chartering a WG on Alert Info URNs. Result: Solid consensus.
Interest in writing drafts = 6
Interest in participating and reviewing = 10 – 15
Action: Go back to the list and resolve the issue of semantics for Disagregate Media on the list
Reason in Responses
draft-jesske-dispatch-reason-in-responses
Proposed Work item - Reason in Responses
Slides at: http://www.ietf.org/proceedings/09nov/slides/dispatch-0.ppt
Reviewing the requirements for this.
Presented use cases, in the form of call flows.
Question: does the group agree on the requirements and is there interest in starting work. What is the correct WG (BLISS, DISPATCH, SIPCORE?)
Daryl Malas: Why not SIP-T? Answer: That works for transit, but in the case where it is SIP end to end. Counter is that the use cases shown here all show PSTN GWs.
Jon Peterson: SIP-T philosophy includes encapsulation and translation. This is defining an encapsulation mechanism, but that is exactly what the encapsulation in SIP-T does. In fact this does less, cause it only encapsulates the reason header. Jon is confused as to exactly what is missing.
John Ewell: Is there some benefit in a SIP UAC receiving ISUP response codes? If that is the case, then there may be value. The second case is an ISUP GW that does not know if the end target will be an ISUP GW
Cullen: If we did translation, then how many new SIP response codes would we need to avoid the confusion. Answer was 15 – 20. But after we move to full SIP, he says that they are no longer needed. An analysis of the translation case would help us here a lot.
Adam Roach: SIP-T is designed to land on a native SIP terminal, and not care.
Crister: Arguing that the reason header is an existing SIP mechanism that we can use for this exact problem.
Daryl Malas: It is well known that 503 response codes are overloaded. You also have the same problem between ISUP networks.
Wolfgang: ISUP is restricted to licensed carriers.
Several interventions making the argument that this is the first step on a slippery slope.
Laura Liess: How many vendors can provide gateways that implement SIP-T? This is the only thing that they need from SIP-T.
Daryl Malas. If we are going to open the Reason Header, then we should be adding in many more things than Q.850 response codes.
Cullen: The syntax for mapping Q.850 response codes into the Reason Header exists, but this proposal is significantly expanding the semantics of where the Reason header can be used.
Dale Worley: Although the RFC does not specify Reason headers in response codes, many people think that it actually does, and in fact, many UAs already do it. It has been frequently spotted in the wild, and this is merely legitimizing what is often done, and that many people think already is legal.
This is a proposal to update RFC 3326 to allow the Reason header to be used in response codes.
Conclusion: Take Reason in Responses back to the list for further discussion cause there is no consensus.
NOTES BY JOHN ELWELL
Session recording protocol (draft-rehor-dispatch-session-recording-req)
Andy Hutton's presentation.
Alan Johnston (???? missed the question)
Cullen: Unclear in requirements whether to record what is heard or what is said - may not be the same.
Chair: Have earlier concerns been addressed to satisfaction of group.
Jon: Needs more explicit words
Andy: Charter itself is more explicit than slides.
Eric: Real life case where standards in this area would have been beneficial.
Cullen: Will notification be to existing devices as well as new devices?
Andy: Requirements cover indications within the media stream, which would cover existing devices. Agree this needs to be considered.
Alan: A clear indication in SIP would allow gateways to translate, e.g., using IVR.
Chair: hum whether we should set up a WG to work on this. Clear consensus to form WG.
Chair: Presenters asked to revise the charter in accordance with comments soon after meeting.
Disaggregated media
Salvatore Loreto's presentation.
John Elwell: Does charter make any reference to ability to work with remote devices that don't have explicit support for the new mechanism.
Chair: This has been discussed on the list and the WG can take this into consideration.
Cullen: Bug chunk of work. Who will put significant work into this.
Chair: Asked the question. About 4 in room, plus one or two more on list. Later Sal indicated willingness too.
Adam: Very large degree of overlap with might become a distributed conferencing system, and XCON might be interested.
Spencer: Should ask on mailing list who will work on it.
Wolfgang Beck: Supports the work.
Hum on whether we should charter this WG, subject to enough volunteers on mailing list to work on this. Clear consensus to set this up.
Robert: Warning that need commitment to work on this, including reviewing drafts.
Alert-Info URNs (draft-liess-dispatch-alert-info-urns)
Laura Lies's presentation.
Laura: What do people think about the interoperability?
John Elwell: Charter should have a few words to stress that URNs should be semantic.
Laura: Requirements draft already has it.
Chair: Agree charter should say it.
Alan: Agree.
Adam: Most existing systems don't express things in a semantic fashion. So limiting to semantic might shut off avenues we wish to follow in future.
Cullen: Does not agree on semantic. Need more discussion if we are to make this decision now.
Spencer: Thought it was an addition - should be able to avoid both.
Laura: Yes - URN + URI.
Spencer: So the semantic addition would not make it worse.
Chair: In view of Cullen's comment, go back on clarify on list, and once resolved, move forward with charter. Assuming that is addressed on list, hum on whether we should. Clear consensus.
Spencer: But what about the other options on slide (e.g., BLISS).
Chair: Yes. The important thing is that people want to do it.
Robert: Recommending the right venue is in DISPATCH's charter, so could make the decision to do something else. 6 would be interested in working on it, and 10-15 would review.
Reason header field in responses
Presentation by Roland Jesske.
Daryl Malas: Why not SIP-T? Also Reason header would be good for other applications, e.g., to indicate ENUM failure, but that would change the scope.
Roland: SIP-T only works for transit cases.
Daryl: Slides seem to show a case where SIP-T would indeed work.
Roland: But it wouldn't work in other situations.
Daryl: Don't need whole of ISUP stack just for passing reason.
Adam: Misunderstanding of SIP-T - does indeed provide interworking between SIP and ISUP. Also there is a bunch of other ISUP parameters, and don't want to go down path of adding them all in turn to the SIP header.
Jon: SIP-T has both encapsulation and translation. The slides demonstrate a weakness in translation that is addressed by the proposal. But why isn't using encapsulation? Slippery slope by adding this to SIP.
John Elwell: Can see two possible cases for augmenting the range or responses in a SIP response. First, where UAC is not an ISUP gateway but needs more information in the SIP response. Second where UAC does not use encapsulation in request because doesn't know it will encounter an ISUP UAS.
Xavier Marjou: Terminating party need not be an ISUP gateway.
Cullen: What would translation approach look like? How many new response codes?
Roland: But when everything is pure SIP wouldn't need these additional response codes.
Cullen: Hybrid networks will exist for some time, but trying to evaluate which is the best approach.
Adam: Agree with Cullen, needs clarification. Also pointed out that SIP-T doesn't care whether UAS is ISUP or not, so no reason SIP-T can't be used if UAC is ISUP.
Christer: We do have the Reason header RFC which has been around for a time and addresses cases SIP-T tunnelling doesn't address, and why not enhance this so that we can use one mechanism for all cases?
???? Missed something round about here to do with multipart.
Wolfgang: ISUP is restricted to licensed carriers, according to SIP-T. Replicating ISUP headers in SIP
Jim: If there is a use case for a native SIP UAC to receive these response codes, should augment native SIP range.
Daryl: The overloading of 503 problem also exists in a different form with ISUP, so conveying ISUP codes will not fully solve the problem. Also putting it into Reason header is one more thing for SBCs to remove.
Adam: Don't want to start taking steps of conveying ISUP information e2e.
Laura: Reason is the only thing we need from SIP-T - much simpler than SIP-T.
Daryl: If we do anything with Reason header, would like it to include other information in there too, not just Q.850 codes.
Chair: But the Reason header already includes Q.850, we are not proposing to add them.
Cullen: We are just extending where it is used, not enhancing the syntax.
Chair: Explained why Reason was defined only for requests.
Dale Worley: Proposal is to legitimise something that lots of people to already.
Chair: Need more mailing list discussion as to whether SIP-T or something else can be used. Don't see consensus.
Jim: If the problem had been stated in the way the chairs separated it (as just an enhancement to where this could be used), discussion would have been very different.
John: Discussion has been out of proportion to the simplicity of the proposal, and once we make decision on list, just do it.