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.
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.
Also related, I think we need to consider the security implications of
this. So, if a malicious caller calls a busy user many times, they can
cause state to build up in the callee's agent. Indeed I think an
implementation would almost be required to construct the call-info URI
in a way that allowed it to contain all of the needed state, moving the
burden to the caller. This isn't discussed at all, afaict, and its a
critical design issue. I seem to recall that this was discussed previously.
Its my understanding that the server managing the queue is free to prune
the queue as desired. For instance, it will almost certainly only keep a
single entry from any particular caller. And it can just stop queuing
when the queue gets as big as it desires to handle.
On the HERFP problem, I think the issue is really deeper than that. The
issue is really targeting/re-forwarding. The question is, if A calls B
and this is retargeted to C, does it make sense to call complete on B or
on C? C kind of makes sense; but what if C is busy for a while and
during that time, the forwarding rules change and calls to B no longer
forward to C. Now, if A called B back they would reach B (who was the
person they REALLY wanted to call anyway), but a call completion request
would in fact go to C. This seems wrong to me. One might even argue that
call completion and forwarding are incompatible. Frankly, if our initial
solution basically didn't support it (no Call-Info passed back at all
when a call is forwarded), I think that is arguably a feature. I suspect
experts on feature interaction have looked at this one; would be curious
on the best practices around this in the PSTN.
Some discretion on the part of B and C could make this work better:
If the forwarding is due to NA or BS, then it can be treated as forking,
so that the CC requests go both places. Then whichever gets it first wins.
Conversely, C can notice that the call was forwarded from B, and can
make a policy decision not to support queuing of calls forwarded from B.
I also think its a mistake to require 199 or 130 or any other 'HERFP'
response - again, making this too complicated. Simplicity is key for
this feature IMHO.
I have a practical worry on using the Call-ID as a correlator for the
subscription. The reality of deployments are many B2BUAs exist, and this
is no longer a reliable e2e correlator for things. Anyway its not
needed; the URI should be sufficient (and unlike call-id, is reliable).
Also, I would NOT assume that SUBSCRIBE and INVITE to the same URI are
routed identically; this is not even true in theory as proxies are
allowed to do method-based routing. Indeed, typically SUBSCRIBE are
routed to appropriate servers based on event packages.
I think one must trust that proxies are configured to route SUBSCRIBE
for *this* event package in a way that is conducive to its intended use.
I think the callback INVITE needs to be to a different SIP URI. I
suspect it will need different treatment on both sides; i.e., that call
should not go to voicemail (I suspect). Using the philosophy embraced in:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-service-identification-02.txt
a service URI is absolutely the right thing to differentiate here.
I do not understand the usage or need for the 'm' and 'monitor'
attributes. Monitor shows up as a URI param, in fact. Not at all sure
why that is needed.
What does a calling domain do when it wants to invoke this service and
the terminating side doesn't support it. Do we have a recommended 'poor
mans' version of this that requires no additional support? i.e., I am
aware of implementations that actually periodically send INVITEs.
Indeed, doing so may be incentive to properly deploy a sub/not solution
to avoid such deluge...
I discussed this above, ad nauseum. :-)
Paul
Thanks,
Jonathan R.
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
