[BLISS] thoughts on draft-ietf-bliss-call-completion

[Jonathan Rosenberg <[e-mail]>]

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
[e-mail]
http://www.jdrosen.net                         PHONE: [phone]
http://www.cisco.com
_______________________________________________
BLISS mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/bliss