[Sip] RE: [Sipping] Example of NOTIFY instead of INFO

["Christer Holmberg (JO/LMF)" <[e-mail]>]

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

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

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


_______________________________________________
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