Transcript Call Completion using BFCP draft-roach-sipping-callcomp-bfcp – San Diego IETF 67

Call Completion using BFCP
draft-roach-sipping-callcomp-bfcp
IETF 67 – San Diego
November 7, 2006
Overview
• Uses requirements from draft-poetzl-sipping-callcompletion-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.
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
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 reattempt.
• 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.
What’s This Server Stuff?
Caller
Proxy
INVITE
Server
INVITE
Proxy Forks
INVITE
Initial
Call
Attempt
Callee
INVITE
183
480
ACK
183
183 Conveys
URI for BFCP
Session
486 Busy Here
486 Busy Here
ACK
INVITE (for BFCP)
200
CCBS
Service
Activation
ACK
BFCP Session
Dialog Subscription
BYE
200
Call
Re-Attempt
INVITE
INVITE
Something
in here must
Convey URI
For INVITE
re-attempt
So, What’s the Problem, Then?
Caller
Proxy
INVITE
Server
Callee
INVITE
INVITE
Initial
Call
Attempt
183
480
ACK
183
486 Busy Here
486 Busy Here
ACK
INVITE (for BFCP)
200
CCBS
Service
Activation
ACK
BFCP Session
Dialog Subscription
BYE
200
Call
Re-Attempt
INVITE
INVITE
If this 200 Conveys
Callee URI in
Contact, then ACK
and BYE go to the
wrong place
Issue 1: Options
1. Convey re-attempt URI in BFCP
– Unfortunately, this doesn’t fit well in with
what BFCP does
2. Add new header field (e.g. “To-Recall:”)
– Service-specific header field is a bit outside
“the SIP way” of doing things
– Recall Dave’s “To-Explode-My-Phone” rant.
3. Put it in a REFER?
Issue 1 Proposal: Use REFER
Caller
Proxy
Server
Callee
INVITE (for BFCP)
200
CCBS
Service
Activation
ACK
BFCP Session
Dialog Subscription
REFER
200
REFER
Conveys
Callee URI
BYE
200
Call
Re-Attempt
INVITE
INVITE
Issue 2: Endpoint Queues vs.
Server Queues
BFCP Session
BFCP Session
Issue 2: Endpoint Queues vs.
Server Queues
Dialog
Subscription
BFCP Session
Dialog
Subscription
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.
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.
Issue 4a: GRUUs
• The draft currently doesn’t 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.
Issue 4b: Caller Correlation
•
•
•
Most of the issues people have raised with GRUUs isn’t
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:
1) That the incoming call is a call completion call, and
2) 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)
Issue 4b: Caller Correlation
MGCF
(Caller)
Callee
PSTN/
PLMN
IAM
INVITE URI B
486 Busy
Supported: callcomp
Contact: GRUU B
REL
(CCBS possible)
ACK
RLC
INVITE GRUU B
Required: callcomp
[BFCP]
200 OK
Contact: GRUU B; GRID b
[BFCP]
TC-BEGIN
ccbsRequest invoke
TC-CONT
ccbsRequest return result
ACK
BFCP Stuff
Happens Here
TC-CONT
remoteUserFree
IAM
(ccss-Indication)
INVITE GRUU B, GRID b
200 OK
ANM
ACK
BYE [BFCP]
200 OK
The problem is that
this IAM may go to a
different gateway than
this one does.
Issue 4b: Caller Correlation
Correlation URI is sent
here during call
Gateway
completion
service
activation
remoteUserFree
Ring
PSTN
Caller
Callee
How does the correlation
URI get back here?
Answer
IAM
Gateway
Issue 4b: Is This Really a Problem?
Correlation URI is
sent here during
Gateway
call completion
service
Stores
activation
URI
Keep in mind that this issue
arises only when these
gateways are in the same
administrative domain…
remoteUserFree
Ring
PSTN
Gets
URI
Callee
Correlation URI
Conveyed
Caller
IAM
Gateway
Answer
…which means
that we can
trivially put a
shared database
here.
Issue 4b: Proposal
• Leave the mechanism as-is
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 can’t be fiddled with.
Issue 5: Options
1. Get a new GRUU from the registrar every time someone calls, with
the same contact for each
– It’s 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 we’ll need to run a timer).
2. 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)
– It’s a bit heavy weight
– I think it results in incoming calls to the user’s AOR forking off to the
user agent multiple times.
3. Add new “cookie” parameter to URI for use with GRUUs.
4. Go back to having GRIDs