[Sip] Example of NOTIFY instead of INFO

[Eric Burger <[e-mail]>]

[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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip