Subject: [Sipping] Example of NOTIFY instead of INFO

From: Eric Burger <[email-masked]>
Date: Fri, 20 Jul 2007 16:41:16 -0400

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

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Adam Roach <[email-masked]>
Date: Fri, 20 Jul 2007 17:27:45 -0500

With the caveat that I haven't read the draft in question yet, I have an 
opinion on the specific issue Eric raises. (In fact, I have dozens -- 
but I'll stick to a small set of them in this response).

> *possibility* of interoperable interworking if the endpoints implement the

Why is this a SIP operation at all? SIP seems like the wrong tool.

Subscriptions, in particular, feel like completely the wrong way to do 
this -- the authority that needs to find out about the bad actors isn't 
monitoring the ongoing state of something. It simply needs to be 
contacted in the very rare circumstance that the call is in some way 
deemed by the caller to be abusive. (If it *is* a subscription, how long 
does the authority subscribe to the called party? Only while the call is 
ongoing? For a minute after the call ends? An hour? One day?). Further, 
you end up with the unfortunate set of circumstances that these poor 
things need to set up as many subscriptions as they do calls, when 
(hopefully) the vast, vast majority of them will never actually return 
any useful state.

INFO has the shortcomings you describe and a host of others that I won't 
bother going into here.

It seems to me that you want something that communicates to the called 
party, "hey, if this call (or instant message, or what have you) is 
abusive, here's the entity to contact." In other words, the authority 
could insert a header field like:

    Report-Abuse: <http://www.example.com/cgi-bin/abuse.pl>

or

    Report-Abuse: <mailto:[email-masked]?subject="Abusive Call
    Report">

Then, you define a MIME type for conveying the information about the 
offending dialog (or maybe even re-use application/dialog-info+xml from 
RFC 4235), and email the abuse report to the email address indicated or 
PUT (POST?) it to the http/https URL indicated.

Or, maybe even...

    Report-Abuse: <sip:[email-masked];method=MESSAGE>

If you're just hellbent on using SIP for some reason.

/a

P.S. Hey! Don't look at me like that. It's *rendered* to the 
administrator. Eventually.

---

From: Eric Burger <[email-masked]>
Date: Fri, 20 Jul 2007 18:47:31 -0400

I like it!  In fact, if there is another draft, I'd like to put this in to
show that not every nail needs to be hit with the SIP hammer.