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.
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.
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.
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 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...
Thanks,
Jonathan R.
--
Jonathan D. Rosenberg, Ph.D. 499 Thornall St.
Cisco Fellow Edison, NJ 08837
Cisco, Voice Technology Group
[EMAIL PROTECTED]
http://www.jdrosen.net PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
