Interim Meeting The SIP Working Group held an interim meeting on Nov 7, 1999 in the Empire Room of the Omni Shoreham Hotel in Washington DC, USA. The primary purpose of the meeting was to inform the SIP working group on the PacketCable Distributed Call Services (DCS) work. DCS is based on SIP, with some extensions and changes to support requirements identified by the developers. Many participants feel that the requirements identified by DCS may need to be addressed in the SIP standard in order to increase its utility and maintain interoperability. The meeting format included a presentation period followed by a discussion period. Attendees were asked to restrict questions during the presentation period to requests for clarification as opposed to exploration of alternatives. Tom Taylor provided note-taking support, and his detailed notes are posted on the unofficial SIP Working Group home at: http://www.softarmor.com/sipwg/meets/interim-nov-1999/ along with PDF copies of all presentations. The DCS submissions to the IETF are available from the IETF internet drafts collection at: http://www.ietf.org/ID.html, search key "dcsgroup". They will be archived at a later date on the unofficial WG home. The presentations included detailed discussion of the assumptions and service requirements underlying the DCS architecture and reviewed the DCS utilization of and proposed changes and extensions to SIP. Topics included: - DCS and DQoS Architecture, presented by K. K. Ramakrishnan - DCS Basic Call Flow, presented by Bill Guckel - DCS Resource Management, presented by Bill Marshall - DCS Authorization and QoS Establishment flow, presented by K. K. - Ramakrishnan - DCS Proxy-Proxy Signaling, as presented by Mike Manette - DCS Privacy, presented by Flemming Andreassen - DCS State, presented by Poornima Lalwaney Several hours of moderated discussion followed the presentations. Key points follow. Jonathan Rosenberg opened the discussion by asking whether the requirements noted by DCS should be applied to SIP work in the IETF. There seemed to be general consensus that the majority of requirements were generally applicable, but that some might require further review. Henning Schulzrinne noted that: - one useful feature of SIP is that one can make progress on agreed points while questioning others - this is not all-or-nothing. - a risk of text encoding is that everyone wants to express things their own way. We have to be concerned with integrity of the style. - it would be nice if other applications outside cable architecture could also use the capabilities added here - we must be concerned for interoperability with other SIP applications, running of multiple SIP-based applications on the same device, and avoid being too special-purpose. K.K. Ramakrishnan expressed general agreement with Henning's points. The ability of SIP to support features in an incremental way is a significant attraction for the DCS folks. It is the intent of the developers of the DCS work that the work and extensions be applicable in environments beyond the cable environment. Scott Petrack discussed the similarity of the DCS approach and legacy PSTN, noting that we need to assure this emulation doesn't create large amounts of work to break away from that model later. Dave Oran suggested attempting to emulate the PSTN user model and meet user expectations, rather than recreating the PSTN itself. It has all along been the intent of the DCS group to primarily focus on the user expectations of interactive voice communication. Jonathan Rosenberg noted that the user expectation model is a valuable basis for developing SIP. He expressed hopes to generalize the application of some of the various DCS concepts e.g., distributed state and to broaden the applicability of extensions so they can be reused. Lawrence Conroy suggested that we might be able to simplify the DCS operator services and break-in approach, asking whether issue is just whether an MTA is engaged in call. Bill Marshall proposed a counter-example: someone with heart attack, necessitating an operator to actually need to know if voice is active. Jonathan Rosenberg responded that this could be problematic if other media are flowing. This leaves a question: Can we rephrase the requirement to make it more generally applicable? Dean Willis noted security issues with operator services. Since the MTA has to cooperate to allow eavesdropping, how does it tell an operator break-in from a wiretap? Bill Marshall responded that it is not a requirement or an assumption that the MTA has to cooperate to allow eavesdropping/wiretap. In fact, it is an explicit assumption that the MTA cannot be expected to cooperate in this situation. Dean Willis noted that SDP limitations mean the source port for a session is not conveyed, making it hard to set firewall rules based on content of SDP and potentially difficult to define the parameters for an operator break-in which is not occurring on an MTA (a mid-flow tap). Bill Marshall responded that we agree that the source port is not available, and for operator break-in, the MTA is expected to cooperate in providing the media stream for operator services. Bill added add that DCS uses only partial classifiers (no match on source port) at the CMTS (wildcard the port number on the socket). Dean Willis discussed the controversiality of the DCS two-stage invite. The current approach uses an "invite, no ring" followed by an "invite with ring". Dean asked if it might be feasible to used nested sessions, wherein the outer session establishes QoS between the endpoints, and the inner session actually sets up the call. The idea may not have been expressed clearly as nobody seemed to get it, and Dean agreed to think about it and discuss it on the group mailing list someday. Someone later pointed out that this approach suffers from the same cascade failure in forking scenarios as does the DCS approach. This probably warrants mailing list discussion. Dean Willis pointed out that the behavior of DCS proxies is to blocking of 3xx responses in the proxy. This prevents passing back multiple contact points to the originator, thereby breaking a number of services including UAC controlled parallel search and menu selection of redirected contact. In fact, it pretty much breaks the entire redirect model. In discussion, it was pointed out that this approach arose from a privacy concern for hiding of forwarding. Jonathan Rosenberg suggested that the privacy requirement is OK, but that the solution shouldn't prevent other capabilities. Dean Willis suggested that use of a proxy that actually proxies, rather than redirects the call, is needed to assure privacy of forwarding, and that end points with this requirement should simply refrain from using redirects for forwarding. Dean Willis suggested that the group consider using the draft-antti tel: URL syntax to express telephone numbers and LNP status rather than adding LNP as a DCS-specific parameter. The DCS group agreed to look at this draft and incorporate necessary changes. Discussion then shifted to the point at which billing begins. Henning Schulzrinne discussed issues with the DCS approach: - per-minute billing doesn't encourage net-friendly behavior like silence suppression. - Routers will have to capture packet volumes. - It may be desirable to support uses such as use of packet connection for baby monitor. Hence a held resource charge plus a packet volume charge might be the appropriate structure. This makes the bill-upon-answer issue disappear. - Two-stage setup shouldn't be driven by a desire to preserve the PSTN billing structure. - The separation of reservation from commitment is valid. It applies on a per-stream rather than per-session basis. - there is a simpler way than two-phase to achieve user requirements if one gets rid of billing model preconceptions. Jonathan Rosenberg questioned the DCS requirement to establish QoS prior to answer response in order tot prevent first-utterance clipping. He pointed out that such clipping occurs in the PSTN today. He suggested that there may be enough "slack" in the network to support best-effort called party greeting before QoS kicks in. Bill Marshall counterpointed that this might mean that the first few packets are delivered with significantly more delay than the others, hence requiring adaptability in the playout buffer, and that this could be problematic given that DOCSIS delay adds 20 ms to best-effort latency. Jonathan responded that designing application layer protocols around layer 2 is a questionable approach. An attendee noted that dropping each proxy out of the signaling path after the first phase may block the operation of some call features. How does a proxy get back "in" when required? Bill Marshall answered that the UA has to explicitly call upon the proxy for further service. This leaves open the question: how does the endpoint know when to call in the proxy? e.g. user requires a specific proxy to be present at all stages of a call. Mike Mannette clarified the requirements and proposed solutions -- two-phase invite addresses the call defect issue; direct 200 OK (proxy bypass) and QoS transmission addresses clipping. There was general agreement that these are separate issues. The group then discussed concerns with the call state model. It may imply some dependence on UA reliability for the operation of some features such as malicious call trace. Mike Mannette stated that the DCS group assumption was that endpoint reliability is an engineerable item. Some parties expressed concern that this reintroduces the telco-supplied phone model, or that people might not realize the implications of buying a cheap phone. K.K. proposed that a service provider could offer a state recording service, to support features such as call trace even in the face of endpoint failure. Someone summarized that the phone should be able to keep state of active calls, but it may be easier for a network resource to keep history. Jonathan Rosenberg described this as a different fate sharing problem. There seemed to be general interest in the room toward expanding the DCS state model into a generalized cookie model. Henning Schulzrinne comment on trust and privacy, noting that it might be more efficient to certify UA-supplied info rather than always overwriting it, with an underlying assumption that people are usually honest. K.K. responded that this is not a fundamental decision and could change if good reason given. Wrap up: Jonathan Rosenberg suggested that the group first agree on requirements, then debate solutions. The DCS group has made the first part easy by breaking the requirements apart. Jonathan again argued that we should avoid special-case solutions to the extent possible, but that the solutions proposed by the DCS group should be given first consideration, as much of the work has already been done. The attendees expressed a strong consensus in favor of this approach. Several implementor groups agreed to offline talks, and numerous calls for list discussion of various topics were voiced. Open questions: 1) Can the operator services requirements be restated so as to make them more generally applicable to SIP-initiated sessions? What are the relevant security requirements? 2) Can the tel: URL syntax be used to meet DCS' needs for expressing phone numbers and LNP contexts? 3) Can we refine the statement of the requirements sufficiently to determine the general applicability of each? 4) Can we develop a reasonable compromise solution to the requirements addressed by two-stage invite without the liabilities presented by the two-stage invite process?