Comments on some of the points inline:
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.
[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.
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.
[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
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
