Call%20Completion%20using%20BFCP

1
Call Completion using BFCP

• draft-roach-sipping-callcomp-bfcp
• IETF 67 San Diego
• November 7, 2006

2
Overview

• Uses requirements from draft-poetzl-sipping-call-c
  ompletion-01
• Uses normal SIP option tags to indicate support
  and negotiate use
• Uses BFCP (hopefully RFC 4582 by now) to place
  callback requests in queue, and manipulate the
  queue
• Uses RFC 3087 techniques to prioritize incoming
  call completion calls over other calls, correlate
  caller with previous call attempt.
• Feedback so far has been strongly (although not
  unanimously) in favor of this general approach.

3
Why BFCP?

• Requirements from draft-poetzl- include specific
  semantics around queue management
• No existing SIP methods inherently deal with
  queue management
• BFCP is semantically congruent with the problem
  several users need to be granted exclusive access
  to a single resource in a controlled fashion

4
Issue 1 Conveying URIs

• Current draft uses Contact header field in a
  provisional response to indicate where to send
  INVITE for BFCP session.
• Current draft uses Contact header field in 200
  response to INVITE (for BFCP session) to indicate
  where to send INVITE for call re-attempt.
• The solution is intended to allow dedicated
  servers to provide the service, but the preceding
  behavior gets in the way.
• Also, this is arguably an abuse of what Contact
  was supposed to mean in the first place.

5
Whats This Server Stuff?
Caller
Proxy
Server
Callee
Proxy Forks INVITE
183 Conveys URI for BFCP Session
BFCP Session
Dialog Subscription
6
So, Whats the Problem, Then?
Caller
Proxy
Server
Callee
If this 200 Conveys Callee URI in Contact, then
ACK and BYE go to the wrong place
BFCP Session
Dialog Subscription
7
Issue 1 Options

• Convey re-attempt URI in BFCP
• Unfortunately, this doesnt fit well in with what
  BFCP does
• Add new header field (e.g. To-Recall)
• Service-specific header field is a bit outside
  the SIP way of doing things
• Recall Daves To-Explode-My-Phone rant.
• Put it in a REFER?

8
Issue 1 Proposal Use REFER
Caller
Proxy
Server
Callee
BFCP Session
Dialog Subscription
REFER Conveys Callee URI
9
Issue 2 Endpoint Queues vs. Server Queues
BFCP Session
BFCP Session
10
Issue 2 Endpoint Queues vs. Server Queues
Dialog Subscription
BFCP Session
Dialog Subscription
11
Issue 2 Endpoint Queues vs. Server Queues

• Current mechanism works with both User Agents and
  Servers maintaining call completion queues.
• User experience is identical or substantially
  similar regardless of where the queue lives, or
  how many queues exist
• We could artificially constrain solution by
  making an unnecessary MUST-strength prohibition
  against one of these modes of operation but why
  would we?
• In particular, keep in mind that we define
  protocols, not architectures. Artificial
  architectural prohibitions seem outside our
  jurisdiction.

12
Issue 3 Feature Creep

• Several people have raised additional potential
  requirements, beyond those expressed in
  draft-poetzl-, and well outside the capabilites
  of any solution offered so far e.g.
• What if the caller owns several devices? Is it a
  solution requirement to let all such devices know
  when a callee of interest is available?
• What is the callee owns several devices he hangs
  up one and then runs away from it but can be
  contacted on a different one? It is a solution
  requirement for the call completion call to track
  them down on a device other than the one that
  they just touched?
• How hard do we want to make this? We can continue
  to pile on requirements until the problem becomes
  unsolvable.

13
Issue 4a GRUUs

• The draft currently doesnt require GRUUs,
  although it suggests their use so as to allow
  callers to address individual callee terminals
  when setting up BFCP sessions.
• Apparently, the suggestion that the mechanism is
  compatible with, and even enhanced by, GRUUs is
  causing significant consternation.
• Do we need to do something here? I think this is
  just a matter of people not having enough time to
  read the draft carefully yet.

14
Issue 4b Caller Correlation

• Most of the issues people have raised with GRUUs
  isnt with the GRUUs themselves as much as the
  requirement to hold on to a URI that is used for
  the call re-attempt at some later point.
• This issue arises (only) in the PSTN interwork
  case which is one of the key drivers for the
  service.
• Currently, the URI lets the callee know two
  things
• That the incoming call is a call completion call,
  and
• That the caller is the same entity who was just
  granted permission to re-attempt their call.
• Without this, it is very easy for me to jump in
  line ahead of you. (Except in closed-garden
  networks)

15
Issue 4b Caller Correlation
The problem is that this IAM may go to
a different gateway than this one does.
16
Issue 4b Caller Correlation
Gateway
PSTN
Ring
Answer
Caller
Callee
Gateway
17
Issue 4b Is This Really a Problem?
Keep in mind that this issue arises only when
these gateways are in the same administrative
domain
Gateway
remoteUserFree
Stores URI
PSTN
Ring
Answer
Gets URI
Caller
Callee
which means that we can trivially put a shared
database here.
Gateway
18
Issue 4b Proposal

• Leave the mechanism as-is

19
Issue 5 GRID is gone from GRUU

• Because the called party uses the URI from a
  request to determine that it is a call-completion
  re-attempt and to correlate the attempt with the
  proper BFCP session, we need to have distinct
  URIs for each pending caller
• With non-GRUUs, this is easy to fix information
  can be squirreled away in the user portion of the
  URI
• GRUU user portions cant be fiddled with.

20
Issue 5 Options

• Get a new GRUU from the registrar every time
  someone calls, with the same contact for each
• Its a bit heavy weight
• While we can correlate users, we lose the ability
  to store state in the user portion that is, the
  registrar chooses the entire URI, instead of the
  user agent
• Requires callee to hold on to state between
  informing caller of availability and caller
  re-attempting call (so well need to run a
  timer).
• Get a new GRUU from the registrar every time
  someone calls, with a different contact for each,
  and use the user portion of the contact to store
  information (taking advantage of proposed loose
  routing semantics)
• Its a bit heavy weight
• I think it results in incoming calls to the
  users AOR forking off to the user agent multiple
  times.
• Add new cookie parameter to URI for use with
  GRUUs.
• Go back to having GRIDs