[Please keep discussion of INFO to the SIP list. Copied to the SIPPING list because this message touches upon SPITSTOP. Please keep discussion of SPITSTOP to the SIPPING list.]
Let us take the case of Malicious Indicator. This is where a subscriber receives a call, realizes it is a malicious call (threatening, SPIT, etc.). They then press the SPIT button (or press *xx), which tells their service provider to mark the UAC as a bad actor. One framework proposed for this is the SPITSTOP Reference Scenario, draft-niccolini-sipping-spitstop-00.txt. One might be tempted to think that INFO would be a great option for this service. It follows the return path of the INVITE, and so the INFO will hit the caller's inbound proxy, which it can learn the caller is (statistically) a bad actor. That way the inbound proxy can do stuff like notify law enforcement, add a vote to "this is a SPIT source," or other useful action. However, consider a few issues. First, since INFO lives exclusively within an established dialog, there is no way to assert this message after the call completes. Second, this mechanism *relies* on an active service provider topology. If there is no proxy in the chain that will eat the INFO, the caller will see the "this is a bad guy" message, which may have consequences in the real world. Third, there is no a'priori way for the UAS to know whether or not it can issue the INFO. The caller CERTAINLY will not advertise, "please tell me if I am bad, particularly I know in advance that I *am* a bad actor." What is the correct way of doing this? Here is where we have theory and practice. Theory says the proxy needs to SUBSCRIBE for the SPIT event at the UAS. At this point, life is good, interoperable, and works across networks. This enables events after the dialog is torn down, as presumably the SPIT event will refer not to, "this dialog," which does not exist, but to "that dialog identifier," which exists (and is theoretically unique) forever. [PLEASE TURN YOUR FLAME THROWERS OFF AT THIS POINT] Practice is that service providers might be able to add value by providing proprietary phones or IAD's to their subscribers that just "know" they have an implicit subscription for this service. Yes, there is a whole host of problems with this, but if you are in a controlled, limited, no desire for inter-network connectivity, this mechanism will work. Moreover, by creating, in this case, a SPIT event package, it will even allow the *possibility* of interoperable interworking if the endpoints implement the full SUBSCRIBE protocol. This approach shuts down the, "Oh, but with INFO I can save 3 messages, even though this all happens after the call connects so it adds no user-visible delay" argument. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
