1. 1 Agenda for Meeting  Purpose of Meeting –Motivation is to minimize (hope for 0) the SIP extensions in DCS spec –Discussion of 2-stage Invite and alternatives »resolution on a consensus approach –Discussion on Progress of DCS work in IETF/SIP Working Group  Two Stage Invite –Discussion on Requirements –Discussion on Alternatives examined –Discussion on other possible alternatives we come up with here –Resolution and next steps.  Progress of DCS –resolution of the 4 non-controversial drafts (privacy, state, proxy-proxy, authorization)

2. 2 Consumer Expectations, not Provider Dogma  [San Francisco Chronicle, C1, 11/29.] –As consumers, we have certain expectations. When we pick up the telephone, we expect to hear a dial tone. When we switch on the television, we expect to see flickering images. And when we turn up the furnace, we expect to feel heat. –Logging on to the Internet, however, is another story altogether. –In the early days of the commercial Internet, or about four years ago, most people would casually shrug off outages and temperamental connections. On the bright side, analysts believe that consumer expectations are steadily rising.

3. 3 Performance Requirements from AT&T Service Description  Traffic Engineering: –Average lines per customer: 2.5 –Grade of Service (GoS) during High Day Busy Hour: 1% blocking »Average traffic per line during HDBH: 0.137 Erlangs –GoS during Average Busy Season Busy Hour: 0.5% Blocking »Average traffic per line during ABSBH: 0.11 Erlangs –Take rate: 30%  Packet Loss: < 10 -5  Call delivery (acceptable defect rate): > 99.8% of all calls  Post Dial delay: <1 sec on 95% of calls  Post Pickup Delay: < 100 ms (99.9%)

4. 4 Service Requirements  Provide quality, support a range of billing models and features –Support near-toll quality of service that is equivalent to the PSTN network –Support local, intra and inter LATA calls with recording capabilities for IP voice services to support usage sensitive (per second), distance sensitive and flat rate billing plans on a per-line basis –Ability to generate records for usage of network resources, for billing as well as reporting of metrics, monitoring and capacity engineering. Usage recording will also need to include inter-network access recording –Support basic service features (411, 911, calling card/debit card, operator services, OSPS, Lawful intercept, TDD, unlisted(private) #, LNP, etc…) –Support at least the popular CLASS and custom calling features. –Control fraud, and enable account restrictions to block certain types of calls »e.g., 3rd number and collect calls etc.

5. 5 Where are we coming from?  We would like to offer a Telephony service to a majority of consumers to replace their current circuit switched telephone service –We have been willing to accept a large number of compromises »limited feature support  PacketCable 1.0 supports NCS ( a version of SGCP/MGCP) –NCS is a Central Switch implementation of Telephony service with packets –For SIP to be a viable replacement/alternative, we need to support at least a small subset of the service provided with 5ESS or NCS.  Performance requirements have to be met  As protocol designers, we do not want to be deciding what revenue models are reasonable or feasible

6. 6 What are our Options?  Use the 2-stage INVITE in conjunction with resource management –reserve resources before ringing the phone, avoiding call defects –avoid clipping by allowing final 200 OK to go end-end –provide indication of pickup that end-point cannot repudiate & avoid fraud –conserve resource usage by committing only when needed  Compromise on the “clipping” issue? –Is interactive voice the only application that will use this session setup »what about other possibilities? Games? Will clipping be more serious there? –Allow 2 nd stage of INVITE-200 OK response go via proxies? »Originator clipped for an amount of time dependent on network topology –Commit resources only on an explicit “commitment” from end-points »Fraud scenarios still covered by requiring the commit message

7. 7 What are our Options?  Reservation to be performed before ringing the phone, don’t allocate, use a temporary 1xx response to the initial INVITE –will the 1xx response to INVITE carry SDP? »source doesn’t have complete information otherwise –potential for clipping still exists, if Ring (eqvt. of 2 nd stage INVITE) and/or connect (200 OK response) go through proxies –200 OK is “connect”; used by end-point to request resource commitment  Allow for Reservation to be performed before ringing the phone and allocate resources for call at same time - don’t bother with 2-stage –initial INVITE causes resource reservation right away, and enable voice path –avoid clipping because QoS provided during ringing time itself »exposes potential for fraud ê an end-point can establish calls of limited duration to last within the ring time »reduces capacity significantly on the limited capacity access network

8. 8 Critical DCS Signaling Messages and their Relationship to Resource Allocation IP MTA-T INVITE MTA O MTA T ER O ER T Proxy T Proxy O Call In Progress INVITE IP MTA-T (RING) (RINGING) Commit Resources 200 OK IP MTA-T INVITE Resource Reservation Commit Resources

9. 9 Proposal SDP, IP MTA-T INVITE MTA O MTA T ER O ER T Proxy T Proxy O Call In Progress INVITE SDP, IP MTA-T ( CONFIRM of resource reservation if necessary, especially for segmented model, possibly in both directions) (180 RINGING, no SDP) Commit Resources 200 OK SDP, IP MTA-T INVITE (SDP specifies precondition on reservationj Resource Reservation (segmented or otherwise) Commit Resources 183183, NOT early media 183 Ring phone Commit for each media stream with flow spec “answer”, optional flow spec, to indicate lower commitment Commit for each media stream PACK(SDP) 200 OK Ack(maybe just end-end) Ack timer PACK(SDP) pickup

10. 10 Observations  We need PACK, which is already in the works for early media. We can use it as a result. –State in the proxy may be cleaned up at the time of the PACK for a transaction stateful proxy: is this reasonable? I think so. Then state is kept for same amount of time. –if the proxy is purely stateless, then it can put the state in the INVITE as it forwards (state blob is really included as part of the “via field”). The state gets put in between the proxies as well in the via, to carry the state with the INVITE. State retrieved back in the 183.  Answer message goes end-end and is an additional message –serves as a confirmation to prevent clipping (serves function of e-e Connect)  We all need to examine interworking with standard SIP endpoints that don’t (want) do resource reservation –interworking of DCS clients that are PACK aware with SIP clients that do not do resource reservation.

11. 11 Next Steps  Need to specify what is needed in the SDPs  Need to write the words behind this proposal. –Call flows with regular SIP clients that don’t support reservation and PACK (reliable provisional response)  Can the “confirm” be a simple UDP message, or can it be an RSVP message, or can it be an RSVP message encapsulated in UDP –address security  The “answer” message: can it be just a UDP message. –Similar issues as Confirm.  PacketCable DQoS may have to change!  Security implications for PacketCable.