Minutes of the SIP Interim Meeting Held Sunday, Nov. 7, 1999 at the Omni Shoreham Hotel, Washigton D.C. Chaired by Jonathan Rosenfeld. Reorted by Tom Taylor. KK Ramakrishnan: Introduction ============================= Slides are in file Agenda for presentation ----------------------- Architectural framework: KK Call walkthrough -- DCS enhancements: Integeration of resource management Call authorization: ex. DQoS flow using RSVP, COPS Proxy-Proxy communication Privacy Communication of call state info to untrusted entities Why use SIP? ------------- Various VoIP opportunities But have to provide role for service provider to make revenue DOSA ---- End-to-end signalling architecture for PacketCable Intellignet endpoints DCS proxies as scalable transaction servers Resource management protocols Gates at edge of network control access to services CableLabs Thrusts ----------------- Initially: SGCP/MGCP -- black telephone equivalent Subsequent: Distributed Call Services -- SIP profile with minimal extensions Separate Dynamic QoS protocol -- per-flow access management on access network Proposed SIP Extensions ----------------------- Positive finding: SIP useful and flexible, can accommodate needs of service provider. Minimize local cable-specific extensions Extensions needed for -- resource management -- privacy, anonymity -- Local Number Portability -- PacketCable Layered Architecture -------------------------------- Layer 2: DOCSIS Above: layers of network functions Hybrid Fiber-Coax Medium Capabilities ------------------------------------- Asymmetric bandwidth: downstream multiple 27 Mb/s channels. Upstream limited number of 2.0-2.5 Mb/s channels, limited by environmental noise. Shared medium up to fiber access point. Layer 2 -- DOCSIS ----------------- DOCSIS 1.0 Media Access Protocol supports best-effort service -- CMTS scheduling -- delay to transmit packet can be substantial and is highly variable -- request-grant mechanism DOCSIS 1.1 provides support for isochronous service, fragmentation -- "unsolicited" grants -- periodic re-grants Delay Calculations ------------------ -- enumeration of sources of delay -- charts of voice packet size vs. delay show that it will be a challenge to keep round-trip delays tolerable -- calculations based on worst case -- approach questioned General conclusions: have to keep packets to 10 ms Moving up from layer 2: ----------------------- Enumerated requirements motivating DCS development -- provide for needs of both existing and new services -- require differentiated QOS -- authenticate and authorize per-call ... Design themes flowing from requirements ... Traffic grade of service measures ... Charts showing what state is kept where -- call state for stable calls in endpoints -- access state in proxies -- bearer state in CMTS Allow different QOS solutions in access vs. core Two-phase resource management -- resource avalible before ringing, but billing starts after answer "Gates" in edge routers opened for individual calls -- particular range of traffic parameters for a given duration -- packet filters Gate controller contains policy -- has no state once call is stable Call flow: stage 1 -- end-to-end via DCS proxies 200 OK response completes the information needed for resource reservation Then resource management is done -- two phases: first do the RSVP resourvation -- initiated by the originator. Commit resources when second INVITE is issued and answered. Point: if original 200 OK contains options, what happens? Answer: even though selection not complete until ACK is passed, resource reservation is done based on the information available from the 200 OK -- provides for all the options. Basic idea: authorization sets an envelope -- committment can choose anything inside this envelope. Billing based on committed resources. Series of enhancements to RSVP framework. Basically each client sends a PATH to reserve bidirectional resources in the access network at its side. The CMTS intercepts the PATH and returns a RESV when it has completed allocation via DOCSIS. SIP/DCS Call Flow ================= Bill Guckel First message has three new headers: Caller: required, gives user name (opt.), calling number -- DCS Proxy authenticates number vs. orig. MTA -- makes no assumption on usefulness of From: header -- Anonymity on | off Stage 1: -- Originating Proxy adds billing headers -- Terminating proxy treats Caller header per anonymity wishes of caller, removes Anonymity hdr -- Saves Billing-Info: hdr and removes it -- Multiple service providers can work on this scheme if there is a trust relationship between them -- Adds Gate: header, State: header. -- UAS saves state information, sends 200 OK -- Originating proxy adds gate and state to 200 OK before passing it back to orig. UA Normal SIP call thereafter. Question: how billing terminated. Answer: by RSVP operations. Not automatic on call cleardown. Billing id from SIP exchanges is sent to edge router which records events against them. Back office operation to assemble all records for given billing ID. Could be feature invocations where proxies have to register billable events. Observation: first stage could be preparatory to running a variety of applications requiring QOS, not just SIP-signalled voice telephony. Resource Management Bill Marshall =================== Preliminary remark: Integration of resource mgmt and call signalling was especially controversial at last meeting. Motivation: high-speed data service -- flat-rate per-month voice and data service won't provide enough revenue to stay in business. Can't do anything directly, but superior (toll-grade telephony compatible) QOS could attract revenues. Looking at business models -- require policy restrictions on RSVP Basically trying to preserve current telephony billing model as long as possible -- have to do it at least for international calls because of settlements required. Differentiate: call blocking vs. call defects. Latter are failures after ringing/ringback. FCC regulation requires 0.00001% (failures affecting multiple calls have to be reported to FCC => public exposure). Discussion: will FCC reporting regulations have to be different for VoIP to take account of different behaviour? Looking at call defects vs. prevention of theft of service: -- have to assume customer equipment will be programmed to serve customer's interests if they can get away with it. Hence key billing events must be captured elsewhere. -- can't bill residential (do bill businesses) during ringing -- if one-way pre-billing connections offered, cooperating endpoints could turn them into two-way connections Conclusion: needed trusted control point, need way to limit packets to only the authorized destination and bandwidth, need way to prevent one-way calls being put together. End up needing four steps for call establishment: alternating call signalling and resource reservation/committment. Post pick-up delay requirements conditioned by possibility that answering end is operator with headset, IVR system. Current PSTN requirement is 100 ms cut-through of voice path. Provided timeline analysis for voice, signalling paths. Optimistic 70 ms on voice path until first packet of called party greeting gets to far end. Signalling path assumes 200-OK goes via proxies. How many proxies in path a matter of how many security associations each can support. Assuming 4 proxies, orig-MTA gets 200-OK after 260 ms. Difference of 190 ms between voice packet arrival and 200-OK arrival. Possibilities: discard all until 200-OK received (190 ms of called party clipped); process, but discard calling party's response until 200-OK received (210 ms of calling party response clipped); take caller greeting as evidence of call completion (not considered acceptable). Above is basis of argument for two-stage invite -- need 200-OK to follow same path as INVITE Call forward no answer turns into transfer. Final item: knowledgable proxy can convert between two-stage and single-stage invite. Call flows shown working in both directions. End up with clipping possibilities. Only syntactic change to SIP is addition of "Stage 1:" header. QOS Signalling (KK) =================== No draft submitted. Messaging from DCS Proxies to edge routers uses modified COPS. "Gateset message" results from preliminary INVITE. Characteristics of local get, plus identity of remote gate. Latter to eliminate two half-call possibility. RSVP runs only between MTA and CMTS. Have to add opaque objects to RSVP PATH message to allow bidirectional reservation in one pass. Basically used own interpretation of RSVP message contents to achieve intent. Provide for unidirectional resource reservation on traditional routers in the path. Commit message goes from MTA to CMTS when second 200-OK comes through. o-CMTS coordinates gate opening with t-CMTS. COMMIT enables local filter for both directions. GateOpen coordinates the two ends to ensure bidirectional flow. Flow allowed at o-CMTS only if responding GateOpen received from called end (timer limits flow duration if GateOpen not received). Prevents unidirectional paths to evade charging. (Potential hole set up by timer) Exchange of GateOpens followed by Commit-ACK to MTA. MTA send Release message to CMTS to clear resource reservations. CMTS send GateClose to far end to propagate. Provision for mutual authentication between CMTSs. Details -- Extensions and Changes Mike Manette User field: add dcs-user-parameter User = telephone-subscriber *("," dcs-user-parameter) or list of dcs-user-parameter or string telephone-subscriber includes provision for addressing special services like conference bridges dcs-user-parameter can cache result of LNP lookup. Gate: header details -- ID, key, possible security info to secure proxy-router link Billing-Info: has account data, record keeper ID, security key for messages to record-keeping server. Billing-ID: globally unique call identifier Question: why not just use Call-ID. Response: not sure Call-ID unique. Call-ID is supplied by the UA and can therefore be set to sabotage billing. Call forward unconditional: record multiple instances of Billing-Info to carry info relating to each leg of call, allowing billing per PSTN practice. Redirection responses are intercepted, do not go all the way back to the orig UA. Question: is proxy involved in call fwd no answer (Yes) Question: how is billing info populated on collect calls? Answer: billing info can be inserted into the 200 OK response. Extensions for caller identity, privacy, some operator services Flemming Andreasen ================================================================ Calling identity: Various uses in PSTN Need trusted intermediary to validate identifying info Used at far end for call trace, calling identity delivery service But need privacy support to regulate latter. "From" header may be encrypted, and cannot be modified in any event because it is part of Call-Id. Motivation for separate Caller: field. DCS-Proxy validates and completes Caller info passed from UA. But UA may not wish to pass this info -- need it anyway for call trace. Basically: Calling Name, Calling Number, IP Address all may need protection for privacy -- for IP addresses, have to have indirection to anonymize => extra delay -- observation that this adds delay to voice path Need means to indicate degree of privacy required. A number of other items to fix to support complete anonymity: From: display-name; Contact: header field; Via: header fields; Call-ID; SDP address fields; RTCP Discussion on whether to support case similar to ISDN, where user sets calling number display info and network simply pronounces on the validity Support of operator services: -- reuse existing facilities -- PSTN operator may be unaware of IP routing of call Busy Line Verify, Emergency Interrupt requirements: -- "no test trunk" capability -- busy not returned -- restricted to operator use Proposed new OSPS header to signal an operator services operation. Remark: terminating end has to trust that header was inserted at an authorized/trusted point in the signalling path. Query: if multiple calls active at an endpoint, what are the semantics of operator break-in? Which call is barged in on? Question: what happens if MTA refuses barge-in? Not different from current situation in PSTN -- subscribers can request no barge-in. Managing State -- distribution of call state to untrusted endpoints =================================================================== Poornima Lahuaney Various kinds of state. Desirable to minimize state in the network to reduce complexity. Basic principle: keep state at the endpoints. But UAs cannot be trusted, hence encryption needed. DCS-Proxies send it to the endpoint during initial INVITE processing. Has correlators with the other two types of state. State: header with token. Stored call state can be used to execute Call Transfer, Call Return, Call Trace -- passed back with INVITE e.g. Call Transfer -- call walkthrough -- showed in which headers the state info appears at each point. Some discussion of the difference between state and cookie Question: why not keep call state in the edge router along with everything else. Response: some features are implemented at the endpoints, so they need the state info to initiate the follow-on signalling. Noted that call return has issues if anonymity info is in state. Discussion =========== Jonathan suggested we first consider whether we accept the requirements. Henning remarks: -- 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. Have to be concerned with integrity of style -- WBN if other applications outside cable architecture could also use the capabilities added here -- must be concerned for interoperability with other SIP applications, running of multiple SIP-based applications on the same device -- avoid being too special-purpose. KK response: points of resonance with Henning's remarks. Scott Petrack: have to make sure attempt to emulate PSTN doesn't create large amounts of work to break away from that model later. Dave Oran: attempting to emulate the user model, meet user expectations, rather than recreate the PSTN itself. Jonathan: user expectation model a valuable basis for developing SIP. Also hopes to generalize application of some of the various concepts e.g. distributed state. Broaden the applicability of extensions so they can be reused. Lawrence Conroy: might be able to simplify BLV -- issue is just whether MTA is engaged in call. Counter-example: someone with heart attack -- actually need to know if voice is active. Jonathan: currently BLV problematic if other media are flowing. Can we rephrase to make more generally applicable? Dean: security issues with BLV -- MTA has to cooperate to allow eavesdropping. How does it tell operator break-in from wiretap? Dean: SDP limitations mean source port not conveyed --[missed the implications] [Dean note: means it is hard to set firewall rules based on content of SDP] Dean: alternative proposal -- call within call -- will be described on the list. Dean: blocking of 3xx responses in proxy prevents passing back multiple contact points which originator can choose to search for in parallel. Issue arose from desire to carry over hiding of forwarding. Jonathan: requirement OK, solution shouldn't prevent other capabilities. Dean suggestion: add LNP parameter to tel: URL rather than DCS-Parameter Discussion on point at which billing begins. Henning: per-minute billing doesn't encourage net-friendly behaviour like silence suppression. Routers will have to capture packet volumes. 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. Henning argues that there is a simpler way than two-phase to achieve user requirements if one gets rid of billing model preconceptions. Jonathan: clipping is still a problem in the PSTN. Another thought: may be enough slack in network to support best-effort called party greeting before QOS kicks in. Bill M. point -- means first few packets are delivered with significantly more delay than the others -- hence need adaptability in playout buffer. DOCSIS delay adds 20 ms to best-effort. Jonathan concern: designing application layer protocols around layer 2 characteristics doesn't seem right. xxx: dropping proxy out of signalling path after first phase may block the operation of some call features. How does proxy get back when required? Bill: UA has to explicitly call upon the proxy for further service. 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 M.: two-phase addresses call defect issue; direct 200 OK transmission addresses clipping. General agreement that these are separate issues. Some concern with dependence on UA reliability for operation of some features such as malicious call trace. Mike M.: DCSgroup assumption was that endpoint reliability is an engineerable item. Some concern that this reintroduces the telco-supplied phone model. Alternatively, people don't realize the implications of buying a cheap phone. KK agreement that service provider could offer a state recording service. Henning comment on trust -- might be more efficient to certify UA-supplied info rather than always overwriting it. (People are usually honest.) KK: not a fundamental decision -- wobbled themselves -- will change if good reason given. What next? Jonathan: agree on requirements, then debate solutions. DCS group has made first part easy by breaking the requirements apart. On solutions, Jonathan would like to get rid of special-case solutions as much as possible. Adjourned. 5:30