Agenda for Meeting

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
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
Performance Requirements from ATT 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 lt 10-5
• Call delivery (acceptable defect rate) gt 99.8
  of all calls
• Post Dial delay lt1 sec on 95 of calls
• Post Pickup Delay lt 100 ms (99.9)

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
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
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 2nd 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
What are our Options?

• Reservation to be performed before ringing the
  phone, dont allocate, use a temporary 1xx
  response to the initial INVITE
• will the 1xx response to INVITE carry SDP?
• source doesnt have complete information
  otherwise
• potential for clipping still exists, if Ring
  (eqvt. of 2nd 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 - dont 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
Critical DCS Signaling Messages and their
Relationship to Resource Allocation
9
Proposal
MTAO
MTAT
ERO
ERT
ProxyT
ProxyO
INVITE
INVITE
INVITE (SDP specifies precondition on reservationj
SDP, IPMTA-T
183
183, NOT early media
SDP, IPMTA-T
183
SDP, IPMTA-T
PACK(SDP)
PACK(SDP)
PACK(SDP)
timer
Resource Reservation (segmented or otherwise)
timer
(CONFIRM of resource reservation if necessary,
especially for segmented model, possibly in both
directions)
Ring phone
(180 RINGING, no SDP)
Commit for each media stream with flow spec
pickup
answer, optional flow spec, to indicate lower
commitment
Commit for each media stream
Commit Resources
200 OK
200 OK
Commit Resources
200 OK
Ack(maybe just end-end)
Ack
Ack
Call In Progress
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 dont (want) do resource
  reservation
• interworking of DCS clients that are PACK aware
  with SIP clients that do not do resource
  reservation.

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 dont
  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.