Subject: [Sip] 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.

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

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Sat, 21 Jul 2007 20:51:24 +0200

Hi, 

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

This is an example of a special case, where you don't want to INFO to go
"all the way back", ie you want it to be terminated somewhere along the
dialog path, and I don't think that is a valid justification why you
couldn't use INFO in cases where you don't have that issue.

I don't even think this behavior would be allowed according to the proxy
rules, so the proxy would more or less be a B2BUA in this case. So, if
the outbound proxy supports this mechanism, and DOES want to use INFO,
it can insert application/mal-ind in the Accept header before forwarding
it towards the UAS (since it is acting as a B2BUA, it is allowed to do
so).
 
>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 
>[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.

I am a little confused. I thought YOU have been saying that we shall
define mechanisms which are NOT based on behavior in controlled and
limited networks...

Regards,

Christer