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

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 28 Jul 2008 09:45:46 -0400

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-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
BLISS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bliss

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 28 Jul 2008 13:51:58 -0400

Lots of comments below.

Jonathan Rosenberg wrote:
>  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 

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.

> 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 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.

> 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.

> Indeed, doing so may be incentive to properly deploy a sub/not solution 

I discussed this above, ad nauseum. :-)

	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 29 Jul 2008 10:26:16 +0100

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Jonathan Rosenberg
> Sent: 28 July 2008 14:46
> To: [email-masked]
> Subject: [BLISS] thoughts on draft-ietf-bliss-call-completion
> 
[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.

> routed to appropriate servers based on event packages.
[JRE] I agree.

> 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

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 29 Jul 2008 10:33:47 +0100

> On Behalf Of Paul Kyzivat
> Sent: 28 July 2008 18:52
> To: Jonathan Rosenberg
> Cc: [email-masked]
> Subject: Re: [BLISS] thoughts on draft-ietf-bliss-call-completion
> 
> Lots of comments below.
> 
[JRE] Or he may use some other capability, like call queueing / call
waiting.

> 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.

John

---

From: "Alexeitsev, D" <[email-masked]>
Date: Tue, 29 Jul 2008 14:38:37 +0200

Comments on some of the points inline:

critical design issue. I seem to recall that this was discussed
previously.

[DA] It was disussed previously and one option was to create the queue
state not at the time of busy recognition for the initial INVITE but at
the suscription time. In this case the caller would be interested to
SUBSCRIBE as fast as possible that there will be as less possible delta
between busy and queue creation time. Subscription also consumes
resources on the caller side and the resource consumption is not that
unballanced for caller and callee.

[DA] This is the question, that has no ultimative unswer. One view is
that it is easier to control the correlation if the call completion wit
call forwarding is done at the B side. And as you said B is the one A
really wanted. Things get even more complicated bacause of the different
types of call forwarding. Here is one of the PSTN BCPs:

For CFU (B):

	already established bevor the CCxx request:

		If present it means that B is not available anyway, then
independent from the C CCxx indication, no CCxx is
presented from B to A

	established after the CCxx request:
	
		CCxx monitoring continues, but change of the state of
the B-party is not signalled to A. If CFU is taken off while
the CCxx contol timer did not run out, then recall possible is indicated
to A, otherwise termination of 				the queue entry.
	
For CFNR (B):

	already established bevor the CCNR request:

		If C provides any of the CCxx indications, than the CCNR
is indicated to A from B
		If C provides no CCxx indications, no CCxx is indicated
to A from B
	
	established after the CCNR request:
	
		CCNR monitoring continues, but change of the state of
the B-party is not signalled to A. If CFNR is taken off
while the CCNR contol timer did not run out, then recall possible is
indicated to A, otherwise termination 		of the queue entry.

For CFB (B):

	already established bevor the CCBS request:

		If C provides any of the CCxx indications, than the CCBS
is indicated to A from B
		If C provides no CCxx indications, no CCxx is indicated
to A from B
	
	established after the CCBS request:
	
		CCBS monitoring continues, but change of the state of
the B-party is not signalled to A. If CFB is taken off while
the CCBS contol timer did not run out, then recall possible is indicated
to A, otherwise termination of 				the queue entry.

No CCxx (B):

In there is no CCxx service for the B available, then independent from
the B's CFx and C's CCxx indication, no CCxx is presented from B to A

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 29 Jul 2008 09:27:11 -0400

> [JRE] Or he may use some other capability, like call queueing / call

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 network provider whether it operates CCBS on callee's behalf or

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