> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Jonathan Rosenberg > Sent: 28 July 2008 14:46 > To: [email protected] > Subject: [BLISS] thoughts on draft-ietf-bliss-call-completion > > 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. [JRE] In PSTN (or at least enterprise equivalents of PSTN) one practice is to make it depend on the conditions for call forwarding. If it is call forwarding because of busy or no reply, it makes sense for CCBS/CCNR to operate on B, rather than C, because there is just as much chance of B becoming available as C becoming available. And after all, B is really the person A wants to communicate with. For unconditional call forwarding (where B is out of the office for a day, say), it might make sense for CCBS/CCNR to operate on C. However, I don't think we want to impose rigid rules of this nature on our SIP solution. In some respects behaviour should be based on the policy of B, but I am not sure how to realise that.
> > 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. [JRE] I agree. > > 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. [JRE] Yes, I have proposed in the past (on the BLISS-CC list, I think) that the NOTIFY from the monitor should provide the URI for the callback INVITE. I think people had concerns that this would be a problem for PSTN interworking, however. John > > 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 > _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
