DCS notes -- 19991107 -------------------- Jonathan opens with discussion of agenda and ground rules. KK -- DCS and DQoS Architecture overview. Walk through basic call flow Integration of resource management Call authorization, DQos Example with RSVP and COPS Proxy-Proxy comm with aditional material Why SIP: usual reasons. Started with DOSA. Intent to encourage featues and services in intelligent end points where feasible. DCS proxies designd to be scalable transaction severs. Resource management protocol, etc. Architecture moved to PacketCable, CableLabs. Focus on consumer telephony. Effort divided into Distributed Call Signaling Protocol and Dynamic Quality of Service Protocol. SIP Changes: Resource Mgmt Privacy and anonymity LNP Billing, operator services, law enforcement call state movement to end points Layered Architecture: Services Codecs, Signaling, Interconnect Common Services OSS DOCSIS IP backbone Physical constraints of cable network downstream -- multiple 27Mb channes in 50 to 70 MHz upstrea, -- limited number of 2 to 2.5 Mb channels, typically 6 to 10 per shared HFC cable. Initial development supported best effort internet, with newer mods providing limited classification. DOCSIS 1.0 MAC: cable modem requests upsteam using contention slots, CMTS schedules and sends down slot maps. DOCSIS 1.1 adds isochronous servce and real-time polling. This allows CMTS to grant a periodic slot with minimal jitter to the modem. 1.1 also adds acket fragmentation and negotiated MTU sizes. Delay Sources: packetization, modem, cable plant, backbone. Typical end-to-end of 96. With 10ms packetizatio, reaches 199ms rtt. 5ms packetization produces 172ms. Optimum trade off poin between number of channels and quality is at 10ms samples. Requirments: -- enable new services, meet current needs. -- differentiated qos -- auth/auth on a call by call basis -- no trust for CPEs -- assure privacy and accuacy of featue info -- protect network fom fraud and theft of service -- operate in large scale, cost effectively Result: Enhance SIP with resource mgmt, privacy, distribute call state Tight coupling with signaling and resouces. State management: -- Transaction state in proxies -- Bearer path state in CMTS -- Stable call state in end points DQOS: Net has multiple segments, with separate resource mgmt approaches. Access network likely to be resouce constrained two-phase resource management assures resources allocated before call completion. Enhancements to RSVP spec: many changes, some questionable. SIP Calls Flows -- Bill Beser ----------------------------- Resource Management -- Ed Miller -------------------------------- Goal is to preserve current telephony billing model and user experience. Design target call blocking rate at .1% with typical ranging from .1% to 1%. Design target defect rate 0.00001% Discussion of theft-of-service issues. Bogus assumption on the difference between preventable and detectable theft. Post Pick-up-Delay discussion. Cable QoS mechanism requires 30ms to establish and activate path for first packet. With coast-to-coast delay, this expands to 70ms. Signaling path is much longer -- on the order of 260 ms. This means that there is a race condition between returning voice and returning signaling on answer -- a race that is always lost by the signaling. Design goal is to be able to transport voice within 100ms of pickup. Call Authorization and QoS Details -- K. K. ------------------------------------------- Detailed Signaling -- Mike Manette ---------------------------------- Changes -- DCS user parameters, Gate:, Billing-Info User part of URI extended telephone-subscriber to add dcs-user-param which can indicate lnp or private numbering plan indicators Gate: gate:/hostport/gated;gate-key;gate-ciphersuite Billing-info: Billing-Info:hostport"<"acct-data">" Billing-ID: globally unique, timestamp,IP of assigner, event count Privacy -- Fleming Andreasan ---------------------------- Very complex requirments demonstrate conflict between privacy requirements and performance requirements. For example, MTA to MTA 2nd stage invite cannot be reconciled with IP-level privacy. Distributing Call State to Endpoints ------------------------------------ State: header is used to actuate service-specific features such as callback, etc. A non-compliant MTA will not be able to access these features. This seems pretty much harmless. The usage of call control is very different from the current call control draft. Discussion Topics: ------------------ Stage 1 invite -- would it be reasonable to to a first invite with SDP which describes a QoS request, then issue an invite witin this qos for the call? Security implications of operator services Getting through additional proxy firewalls Split resource reservation appears to be questionable, assumes symmetric paths and symmetric rsvp setup on single path-resv Caller: header is to be changed by proxies for privacy. This is because the From: header cannot be changed. Why not have anonymous From: field from MTA if anonymity is "on"? Apparently the caller field is used somehow for authentication. Caller: field appears to be the authentication ID. URL: Use of tel url seems appropriate ISSUE: DCS Proxies do not pass 300-class messages back to MTAs. How does this play with "multiple choice" redirects? Issue: Assume customer originated trace requirement must be met on IP. This is bogus -- it must be met from the gateway down. The way to do this is to have the egress gateway authenticate the call. Issue: The DCS idea of the calling party ID service is to block the "from" line unless somebody pays extra to receive it. Bogus. Call Control: The DCS usage of call control is completely "out there". Discussion: ---------- Jonathan intros with mission - -DCS has brought in requirements and suggestions. We must analyze the requirements, see if they should be met in SIP, and then consider the DCS suggestions as starting points. Ideas: Willis: Two-phase invite replaced with an "invite QoS" -- "Invite RTP" aproach. Willis: Use TEL URL Schulzrinne: separate resource holding from resource using. This is useful for allowing a distinction between reserved and commited resource. The point is that the current assumptions has a "no charge" fo holding during ringing phase. This phase ends when the ringing ends and a control message is sent. Suggestion is to end the phase when the first real data is sent. Reservation changes should be made on a stream-by-stream basis rather than on a session-by-session basis. Response: all that is defined is a set of mechanisms that specify the recording capability. Discussion about reservervation -- Jonathan wonders if you really have to have the closing 200 ok directly between the endpoints. Donovan wonders about impact of two-stage invite on proxy-mediated call services. KK -- don't care, get the proxies out. Oran: what makes you assume you want the same proxies to provide the network features? Manette: comment on two-phase. Phase 1 addresses blocking, phase 2 prevents clipping. Rosenburg asks if clipping is really an issue? Discussion on state storage in client. What are the implications of client state loss on critical services such as call tracing? KK -- clearly the simple model of storing state on the endpoint can be used to provide some features. Discussion -- the phone should be able to keep state of active calls, but it may be easier for a network resource to keep history. Jonatahn -- it's a different fate sharing problem. Henning -- talk about anonymity services . . .