From: Jonathan Rosenberg <[EMAIL PROTECTED]> 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.
From: Paul Kyzivat <[EMAIL PROTECTED]> 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. From: "Alexeitsev, D" <[EMAIL PROTECTED]> 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. There are a number of aspects to this issue. The current design is based on the idea that the PSTN enforces that a CC caller must have previously made a failed call to the callee in question. Within that concept, the design is intended to enforce a similar restriction, to ensure that SIP CC has privacy enforcement at least as strong as that of the PSTN. Recently, we have learned that the PSTN does not enforce this restriction, which may allow simplification of the CC design. However, if we desire to enforce the restriction that a CC subscription is only allowed if it is from the caller of a recently failed call to the callee, the callee's monitor must maintain a list of such callers. In principle this can require unlimited storage, but there are several mitigations: (1) no callee has to be recorded more than once, so repeated calls from a single callee are not significant (and are already subject to administrative action as abuse), (2) the amount of information needed to record a caller who does not have a CC subscription is just the caller's identification string, and (3) the design allows the monitor to limit the effective queue size according to any policy it chooses. Unfortunately, is impossible to depend on a call-info URI containing the needed state -- one design goal is to support "memoryless" UAs, gateways actually, where no information is retained between the original INVITE transaction and the subsequent CC SUBSCRIBE, so the call-info URI is available as an optimization, but can not be depended on. This might seem to be an excessively strict restriction, but SS7-to-SIP gateway systems seem to be mostly of this sort, because the gateway is actually a constellation of redundant devices that do not share call state. Dale _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
