Elwell, John wrote:
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Paul Kyzivat
Sent: 28 July 2008 18:52
To: Jonathan Rosenberg
Cc: [email protected]
Subject: Re: [BLISS] thoughts on draft-ietf-bliss-call-completion
Lots of comments below.
Jonathan Rosenberg wrote:
A key part of the mechanism in here is that it focuses on
the 'server to
server' aspect of the problem. It defines only what would
need to flow
between domains or between organizations to accomplish this feature
between organizations. I think that aspect of it needs to
be emphasized.
For example, some diagrams which show this, including
different models
for how the agents can be co-located.
Very much related to that, ccbs has an effect of
introducing work in one
domain (the one of the callee) that primarily (if not exclusively)
benefits the other (the one of the caller). This provides
an unfortunate
negative incentive for implementing this in a callee
domain. I think we
need to take care to minimize the amount of work required on the
callee's side to support this. So for example, I am reluctant to
introduce requirements to do things like suspend/resume, as these
introduce additional work and state on behalf of the callee's agent.
While I agree that it is important to consider what the
incentives are
for implementing this stuff, I don't think this should be viewed as
primarily benefiting the caller at the expense of the callee.
At least
not if this is considered an *optional* feature at the callee.
A callee will offer this capability if he considers it advantageous -
namely if he considers the incoming calls to his benefit, and missing
them to be a loss. If the callee doesn't view incoming calls
that way he
is free to omit the feature.
[JRE] Or he may use some other capability, like call queueing / call
waiting.
Sure. And these things aren't necessarily mutually exclusive, though
they may be in the pstn.
(Why can't I have call waiting and cc too? This would however require
more explicit control at the receiving end - perhaps visibility to the
queue and the option to take another call from the queue even though I
am on a call already.)
To the caller who wants to get through, there are various potential
solutions. One is to simply repeatedly reattempt the call.
This can be
done manually by the UAC user, but it can also be implemented
in the UAC
itself.
Why isn't *that* a sufficient solution? Several reasons:
1) it increases signaling load on the network
2) there is no "fairness" - no guarantee that the first to try
is the first to get through, or even that the caller the
callee would most like to talk to gets through first.
3) the calling user has to stand by awaiting success. There
is no opportunity to do other things and be alerted when
the call can get through.
Who benefits varies for these:
1) the network carriers benefit. This may be incentive enough.
2) using repeat dialing, the UA that can generate call attempts most
frequently has the highest probablility of getting
through quickly.
The has the potential to aggrevate (1). (A clever UAC may even
initiate additional INVITEs before the earlier one has had a
response.) Its not clear if fairness for callers is of benefit
to the callee or not - perhaps if some callers get mad for having
had to wait a long time. To be effective, the queuing must
prevent people from getting through without entering the queue
so long as a queue exists. But that locks out callers that don't
have support for the queuing mechanism. That makes rollout of
the queuing support problematic.
Additional benefit can accrue to the callee if he is given the
opportunity to cherry pick the queue - choosing how it is
ordered.
3) this clearly is benefit to the caller. The benefit to the callee
is a happier caller. For instance, this might make long call wait
times be more palatable.
IMO the "caller" call completion service and the "callee" call
completion service are logically separate. As a caller, I just want a
way to complete my calls, and I want it regardless of what
capabilities
the callee does or doesn't have. So the UAC should have a bag
of tricks
that it can use to accomplish call completion. Repeat dialing and the
ccna/ccbs queing are two tricks in the bag. There may be other
possibilities. (E.g. probing with OPTIONS checking for busy.)
The "callee" call completion service is probably the callee
half of the
queuing mechanism, offered as an option to callers that
support it. It
is there if and when it suits the callee to offer it.
[JRE] For PSTN use, the callee generally does not have a say - it is up
to the network provider whether it operates CCBS on callee's behalf or
not.
In this case we at least pretend that the SP is carrying out the
callee's policy. That policy is decided when the callee enrolls for
service. Any perhaps there isn't a lot of choice. Yet it was the
callee's policy decision to enroll. :-)
Paul
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
