Subject: [Sipping] New Internet Draft for Caller Identity Blocking

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Mon, 2 Mar 2009 16:44:30 +0800

Hi All

I have just submitted an I-D on blocking caller identities during
ringing and call termination phases by extending SIP Reason header to be
included in SIP BYE and CANCEL methods.

Please review and comment

The URL of the draft is:
http://www.ietf.org/internet-drafts/draft-avasarala-sipping-reason-heade
r-dynamic-icb-00.txt

Thanks

Regards
Ranjit

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 2 Mar 2009 10:12:01 -0500

Hi Ranjit,
I like the purpose of your draft a lot, to let receiving users block future calls from the same source.  But I'm not sure the implementation of it is quite right.  It seems to me that if I want to block a user from calling me indefinitely, I'd want it to be known by more than the proxy chain sending it to me.  In particular, I'd probably want it to be known to the Registrar or at least some database multiple proxies of my provider can query.  That way if there are multiple proxies which can reach me, or the proxy is rebooted/replaced/whatever, or I move/roam and end up using another proxy, the block-list is not lost.

Obviously in a 3GPP-specific model you could have the S-CSCF or some other node perform such an update to the HSS or whatever, but then how would I unblock the user at some later time, if I changed my mind?  And how do I detect if my operation succeeded, in case the proxy couldn't process my block/unblock request?

This seems more like a use-case for an event-package, where one can send a PUBLISH to block/unblock users, or even a Subscribe to view the current list.  The tricky part with that is that for some incoming calls there is no caller-id/source-AoR for me to ask to be blocked or unblocked.  But since for that to be the case requires the proxy to essentially be a B2BUA (to provide privacy anonymization, or in 3GPP's case to remove and store the PAI), then one could argue the PUBLISH can be sent to that same upstream B2BUA which can insert that info if it still has it. (ugly, but possible)  Hmmm... I'll have to think about that issue more.

Some other comments on your draft:
1) You show the Reason header being removed by the Proxy.  While that may make sense for some cases, for being out on vacation it does not - I *want* the UAC to see it.
2) You describe the Reason header being inserted in BYE/CANCEL, but in the example it's in a 4xx.  Sending it in a 4xx failure response should be explicitly included, imho, even though I think the Reason-header RFC didn't allow it (for some whacky reason).
3) You add an Expires parameter (which should be lower-case, by the way), and say if it's value is "99999" then it's permanent, but meanwhile in one example a value of "604800" is used for being on vacation.  So clearly 99999 is not max.  Seems to me "99999" is a very small number, just slightly longer than a day. :)  Maybe just make it 4294967295 (an unsigned long, 2^32-1, 136 years).
4) In the security section, it mentions integrity protection to prevent snooping of messages when using this header.  AFAIK, integrity protection provides no eavesdropping protection (that would be encryption); not that I can see why it matters if someone snoops on this header anyway.  You also later cite TLS and S/MIME - I think you might as well remove S/MIME since it's a waste of 6 characters in toner/ink if anyone prints this draft out. ;)

-hadriel

________________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Avasarala Ranjit-A20990
Sent: Monday, March 02, 2009 3:45 AM
To: [email-masked]
Subject: [Sipping] New Internet Draft for Caller Identity Blocking

Hi All
I have just submitted an I-D on blocking caller identities during ringing and call termination phases by extending SIP Reason header to be included in SIP BYE and CANCEL methods.
Please review and comment
The URL of the draft is: http://www.ietf.org/internet-drafts/draft-avasarala-sipping-reason-header-dynamic-icb-00.txt
Thanks
Regards
Ranjit

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Mon, 2 Mar 2009 17:36:26 +0200

How is this draft different from previously investigated approaches? 
http://tools.ietf.org/html/draft-niccolini-sipping-spam-feedback-00

Ciao
Hannes
 
>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Hadriel Kaplan
>Sent: 02 March, 2009 17:12
>To: Avasarala Ranjit-A20990; [email-masked]
>Subject: Re: [Sipping] New Internet Draft for Caller Identity Blocking
>
>
>Hi Ranjit,
>I like the purpose of your draft a lot, to let receiving users 
>block future calls from the same source.  But I'm not sure the 
>implementation of it is quite right.  It seems to me that if I 
>want to block a user from calling me indefinitely, I'd want it 
>to be known by more than the proxy chain sending it to me.  In 
>particular, I'd probably want it to be known to the Registrar 
>or at least some database multiple proxies of my provider can 
>query.  That way if there are multiple proxies which can reach 
>me, or the proxy is rebooted/replaced/whatever, or I move/roam 
>and end up using another proxy, the block-list is not lost.
>
>Obviously in a 3GPP-specific model you could have the S-CSCF 
>or some other node perform such an update to the HSS or 
>whatever, but then how would I unblock the user at some later 
>time, if I changed my mind?  And how do I detect if my 
>operation succeeded, in case the proxy couldn't process my 
>block/unblock request?
>
>This seems more like a use-case for an event-package, where 
>one can send a PUBLISH to block/unblock users, or even a 
>Subscribe to view the current list.  The tricky part with that 
>is that for some incoming calls there is no 
>caller-id/source-AoR for me to ask to be blocked or unblocked. 
> But since for that to be the case requires the proxy to 
>essentially be a B2BUA (to provide privacy anonymization, or 
>in 3GPP's case to remove and store the PAI), then one could 
>argue the PUBLISH can be sent to that same upstream B2BUA 
>which can insert that info if it still has it. (ugly, but 
>possible)  Hmmm... I'll have to think about that issue more.
>
>1) You show the Reason header being removed by the Proxy.  
>While that may make sense for some cases, for being out on 
>vacation it does not - I *want* the UAC to see it.
>2) You describe the Reason header being inserted in 
>BYE/CANCEL, but in the example it's in a 4xx.  Sending it in a 
>4xx failure response should be explicitly included, imho, even 
>though I think the Reason-header RFC didn't allow it (for some 
>whacky reason).
>3) You add an Expires parameter (which should be lower-case, 
>by the way), and say if it's value is "99999" then it's 
>permanent, but meanwhile in one example a value of "604800" is 
>used for being on vacation.  So clearly 99999 is not max.  
>Seems to me "99999" is a very small number, just slightly 
>longer than a day. :)  Maybe just make it 4294967295 (an 
>unsigned long, 2^32-1, 136 years).
>4) In the security section, it mentions integrity protection 
>to prevent snooping of messages when using this header.  
>AFAIK, integrity protection provides no eavesdropping 
>protection (that would be encryption); not that I can see why 
>it matters if someone snoops on this header anyway.  You also 
>later cite TLS and S/MIME - I think you might as well remove 
>S/MIME since it's a waste of 6 characters in toner/ink if 
>anyone prints this draft out. ;)
>
>-hadriel
>
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Avasarala Ranjit-A20990
>I have just submitted an I-D on blocking caller identities 
>during ringing and call termination phases by extending SIP 
>Reason header to be included in SIP BYE and CANCEL methods.
>http://www.ietf.org/internet-drafts/draft-avasarala-sipping-rea
>son-header-dynamic-icb-00.txt
>Thanks
>Regards
>Ranjit
>_______________________________________________
>Sipping mailing list  https://www.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: Victor Pascual Ávila <[email-masked]>
Date: Mon, 2 Mar 2009 16:47:11 +0100

Hi Hadriel,
thanks a lot for your comments. Some comments inline.

> I like the purpose of your draft a lot, to let receiving users block future calls from the same source.  But I'm not sure the implementation of it is quite right.  It seems to me that if I want to…

When the proxy gets the blocking information, it should update the
"shared database" with this information.

> Obviously in a 3GPP-specific model you could have the S-CSCF or some other node perform such an update to the HSS or whatever, but then how would I unblock the user at some later time, if I changed…

This is something we have mentioned in the Open issues section
(Appendix B). Here I see two alternatives:
1) "Offline" mechanism for unblocking user identities (e.g. web
interface where one could remove blacklisted destinations)
2) "Online" mechanism for unblocking user identities. For this, I
believe the UA should retrieve the "blacklisted destinations", select
one or several destinations and send a F00B4r message with:

Reason: block; cause=1 or 2; text="unblock";
uri="sip:[email-masked]"; Expires=0
or
Reason: block; cause=3; text="unblock"; uri="sip:[email-masked]"; Expires=XYZ

> This seems more like a use-case for an event-package, where one can send a PUBLISH to block/unblock users, or even a Subscribe to view the current list.  The tricky part with that is that for some…

The event-package seems to be a reasonable alternative. And yes, when
the called UA cannot resolve the calling identity, the server needs to
fetch the actual identity of the caller (See section 3.2). In other
words, the UA would ask the server to "blacklist the identity that
initiated dialog X".

> 1) You show the Reason header being removed by the Proxy.  While that may make sense for some cases, for being out on vacation it does not - I *want* the UAC to see it.

I believe the header can reveal sensitive information for an attacker:
permanent blocking vs temporal blocking (and the expires).

Cheers,
-- 
Victor Pascual Ávila

---

From: "Nils Ohlmeier" <[email-masked]>
Date: Mon, 2 Mar 2009 18:01:15 +0100 (CET)

Hello,

> http://www.ietf.org/internet-drafts/draft-avasarala-sipping-reason-heade

you and your draft are talking about allowing the terminating UA to give
some "feedback" for an incoming call. How is this related to CANCEL at
all? Maybe I'm missing here something but a CANCEL is only send by the
originator if the call was not yet established, right?!

And one more general comment very similar to Hadriels:
while I think the general idea of managing my white-/grey-/black-lists
instantenously is nice. But you are basically only proposing a way to add
something to a list and push the responsibility for removal to a timer. I
believe that managing such an important list needs a lot more complex
management capabilities (querying, removal, modification,...). If we have
a solution for that, we could look for an easy way how to combine that
technique with direct feedback on an incoming or terminated call.

Regards
  Nils Ohlmeier

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 2 Mar 2009 12:12:25 -0500

Ignoring the syntax differences, even semantically they're different.  One is about indicating spam, the other is about asking for call blocking.  Indicating spam might lead to call blocking, but not the other way around.  For example just because I'm on vacation or don't want to get calls from you in particular, does not mean your call is spam.  It should not affect your reputation, for example.  And semantically the spam one is an indication, whereas the blocking one is a command, fwiw.

Obviously the solution mechanism could be the same for both uses, I suppose. (which is probably more to your point :)

-hadriel

> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Monday, March 02, 2009 10:36 AM
> To: Hadriel Kaplan; 'Avasarala Ranjit-A20990'; [email-masked];
> [email-masked]
> Subject: RE: [Sipping] New Internet Draft for Caller Identity Blocking
>

---

From: Victor Pascual Ávila <[email-masked]>
Date: Mon, 2 Mar 2009 21:28:12 +0100

Hi Nils,
thanks for your comments.

> originator if the call was not yet established, right?!

IMHO it might make sense when dealing with B2BUAs (e.g. a 3pcc service).

Please, correct me if I'm wrong.

Cheers,
-- 
Victor Pascual Ávila

---

From: Nils Ohlmeier <[email-masked]>
Date: Mon, 02 Mar 2009 22:03:00 +0100

Hi Victor,

Am 02.03.2009 21:28 Uhr, schrieb Victor Pascual Ávila:
> On Mon, Mar 2, 2009 at 6:01 PM, Nils Ohlmeier<[email-masked]>  wrote:

I assume you mean that a B2BUA could cancel the outgoing call leg. But 
a) where does the B2BUA gets suddenly the information from (if it has 
the blocking information already it would reject the incoming call leg, 
so there is nothing to cancel) and b) how is this different from a 
forking proxy (which obviously needs to cancel the remaining forked call 
legs if the user has rejected the call at one of the legs)?

So I have to fealing that I'm still missing here something.
A CANCEL goes from originator to the receiver of a request. But you want 
to send the blocking information in the other direction. Or do you 
assume that an entity which processes the blocking information could sit 
at the terminating side of a call leg?

I fear that I would need an example or call flow to get the use case for 
a CANCEL.

Cheers
   Nils

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Tue, 3 Mar 2009 14:31:07 +0800

Hi Nils

A originator typically the UAC can send CANCEL if it does not want to accept the call. So the Reason header with block option can be sent while rejecting the call. While the Reason header with block option can be sent in BYE while terminating the call - i. e blocking after talking.

Regards
Ranjit

-----Original Message-----
From: Nils Ohlmeier [mailto:[email-masked]] 
Sent: Tuesday, March 03, 2009 2:33 AM
To: Victor Pascual Ávila
Cc: Avasarala Ranjit-A20990; [email-masked]
Subject: Re: [Sipping] New Internet Draft for Caller Identity Blocking

Hi Victor,

Am 02.03.2009 21:28 Uhr, schrieb Victor Pascual Ávila:
>> you and your draft are talking about allowing the terminating UA to 
>> give some "feedback" for an incoming call. How is this related to 
>> CANCEL at all? Maybe I'm missing here something but a CANCEL is only 
>> send by the originator if the call was not yet established, right?!
>

I assume you mean that a B2BUA could cancel the outgoing call leg. But
a) where does the B2BUA gets suddenly the information from (if it has the blocking information already it would reject the incoming call leg, so there is nothing to cancel) and b) how is this different from a forking proxy (which obviously needs to cancel the remaining forked call legs if the user has rejected the call at one of the legs)?

So I have to fealing that I'm still missing here something.
A CANCEL goes from originator to the receiver of a request. But you want to send the blocking information in the other direction. Or do you assume that an entity which processes the blocking information could sit at the terminating side of a call leg?

I fear that I would need an example or call flow to get the use case for a CANCEL.

Cheers
   Nils

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Tue, 3 Mar 2009 03:00:10 -0500

>Sent: Tuesday, March 03, 2009 12:01 PM
>To: Nils Ohlmeier; Victor Pascual Ávila
>Cc: [email-masked]
>A originator typically the UAC can send CANCEL if it does not 
>want to accept the call. 
Originator typically initiates the call and the recipient accepts the call. How does originator accept it's own call?

Sanjay

> So the Reason header with block 
>option can be sent while rejecting the call. While the Reason 
>header with block option can be sent in BYE while terminating 
>the call - i. e blocking after talking.
> 
>
>
>Regards
>Ranjit
>
>a) where does the B2BUA gets suddenly the information from (if 
>it has the blocking information already it would reject the 
>incoming call leg, so there is nothing to cancel) and b) how 
>is this different from a forking proxy (which obviously needs 
>to cancel the remaining forked call legs if the user has 
>rejected the call at one of the legs)?
>
>A CANCEL goes from originator to the receiver of a request. 
>But you want to send the blocking information in the other 
>direction. Or do you assume that an entity which processes the 
>blocking information could sit at the terminating side of a call leg?
>

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Tue, 3 Mar 2009 16:07:18 +0800

Consider the scenario

Alice makes call to Bob. So Bob receives the INVITE from Alice. Now if Bob does not want to answer the call from Alice and instead wishes to block Alice, Bob can send a CANCEL with Reason header with protocol value as "block". Similarly say John calls Bob and Bob answers the call and after speaking realizes that John is a telemarketer or someone with whom Bob does not want to speak in future. Then Bob can send BYE and along with send Reason header with protocol value as "block".

So this way a particular caller identity can be blocked either during the ringing or call termination phase.

Regards
Ranjit

-----Original Message-----
From: Sanjay Sinha (sanjsinh) [mailto:[email-masked]] 
Sent: Tuesday, March 03, 2009 1:30 PM
To: Avasarala Ranjit-A20990; Nils Ohlmeier; Victor Pascual Ávila
Cc: [email-masked]
Subject: RE: [Sipping] New Internet Draft for Caller Identity Blocking

>A originator typically the UAC can send CANCEL if it does not want to 
>accept the call.

Sanjay

---

From: Michael Procter <[email-masked]>
Date: Tue, 03 Mar 2009 08:18:13 +0000

Avasarala Ranjit-A20990 wrote:
> Consider the scenario
>
> Alice makes call to Bob. So Bob receives the INVITE from Alice. Now if Bob does not want to answer the call from Alice and instead wishes to block Alice, Bob can send a CANCEL 

That is quite a large change from RFC 3261.  Can't Bob simply reject the
call with an appropriate response code?  That would seem less disruptive
than permitting backwards CANCELs!

> with Reason header with protocol value as "block". Similarly say John calls Bob and Bob answers the call and after speaking realizes that John is a telemarketer or someone with whom Bob does not want to speak in future. Then Bob can send BYE and along with send Reason header with protocol value as "block".
>
>>> On Mon, Mar 2, 2009 at 6:01 PM, Nils 
>>>       
>> Ohlmeier<[email-masked]>  wrote:
>>     
>>>> CANCEL at all? Maybe I'm missing here something but a 
>>>>         
>> CANCEL is only 
>>     
>>> IMHO it might make sense when dealing with B2BUAs (e.g. a 
>>>       
>> 3pcc service).
>>     
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 3 Mar 2009 09:22:34 +0100

Hi, 

>permanent blocking vs temporal blocking (and the expires).

How does I know that there will be a proxy that supports the extension in the first place, and that would remove the header from the CAN/BYE/4xx? If no proxy supports the extension the Reason header may be passed all the way to the UAC...

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 3 Mar 2009 09:23:56 +0100

Hi,

The draft talks alot about 3GPP, and the work on IMS supplementary
services. Why? Is your intention to bring this to 3GPP? If so, why can't
the existing service configuration mechanisms in 3GPP be used for this?

Regards,

Christer
 
> http://www.ietf.org/internet-drafts/draft-avasarala-sipping-re
> ason-header-dynamic-icb-00.txt
> Thanks
> Regards
> Ranjit
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Tue, 3 Mar 2009 16:27:44 +0800

Hi Christer

The mechanism of dynamic blocking of caller identities got approved in
3GPP. The text got included in the latest version of 22.173. 

Regards
Ranjit

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: Tuesday, March 03, 2009 1:54 PM
To: Avasarala Ranjit-A20990; [email-masked]
Subject: RE: [Sipping] New Internet Draft for Caller Identity Blocking

Hi,

Regards,

Christer
 
> ringing and call termination phases by extending SIP Reason header to 
> be included in SIP BYE and CANCEL methods.
> [email-masked] for questions on current sip Use 
> [email-masked] for new developments of core SIP
>

---

From: Victor Pascual Ávila <[email-masked]>
Date: Tue, 3 Mar 2009 09:31:41 +0100

> So this way a particular caller identity can be blocked either during the ringing or call termination phase.

I wouldn't use a CANCEL here, simply reject the call with 4xx
-- 
Victor Pascual Ávila

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 3 Mar 2009 09:41:46 +0100

Hi, 

So, why can't you use the existing mechanisms in 3GPP (XCAP etc)?

Regards,

Christer

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 3 Mar 2009 10:54:52 +0200

That's something I have asked as well. 

We even have the policy mechanisms in place and they are implemented. 

>[mailto:[email-masked]] On Behalf Of ext Christer Holmberg
>Sent: 03 March, 2009 10:42
>> services. Why? Is your intention to bring this to 3GPP? If so, why 
>> can't the existing service configuration mechanisms in 3GPP be used 
>> for this?
>> 
>> Regards,
>> 
>> Christer
>>

---

From: Nils Ohlmeier <[email-masked]>
Date: Tue, 03 Mar 2009 10:01:37 +0100

Am 03.03.2009 9:07 Uhr, schrieb Avasarala Ranjit-A20990:
> Consider the scenario
>
> Alice makes call to Bob. So Bob receives the INVITE from Alice. Now if Bob does not want to answer the call from Alice and instead wishes to block Alice, Bob can send a CANCEL with Reason header with protocol value as "block".

Sure Bob could send such a CANCEL, but nothing would happen if all other 
SIP network elements have implemented the SIP related RFCs which I know.
As you wrote in your previous mail only the originator of an INVITE 
sends a CANCEL to terminate a not yet established call, so Alice in this 
scenario.
Bob would/should send simply send a 4xx response to reject the incoming 
call.

After reading the mails again I thought maybe your intention was to use 
a CANCEL in the following scenario:
a 3PCC application, lets say a conference service, calls Alice at a 
given time to initiate the scheduled call. When Alices picks up the 
phone the 3PCC application will call Bob (and maybe more participants). 
But now Alice is currently in a more important meeting and wants to 
block this conference call for 30 minutes.
As the 3PCC acts on behalf of Alice you could think that Alice would 
need to send a CANCEL here to prevent that the call gets established. 
But this assumption is wrong. Again only the 3PCC application could send 
a CANCEL in this scenario. Alice would simply reject the incoming call 
with 4xx reponse to block it for some time.

So if you do not come up with some other scenario where the originator 
transfers blocking information via a CANCEL I would strongly recommend 
to remove the CANCEL from your draft (despite my other concerns from my 
first mail).

Greetings
   Nils

> Similarly say John calls Bob and Bob answers the call and after speaking realizes that John is a telemarketer or someone with whom Bob does not want to speak in future. Then Bob can send BYE and along with send Reason header with protocol value as "block".
>

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Tue, 3 Mar 2009 17:06:42 +0800

Hi Christer

The caller identity blocking could be offered as a supplementary service - something like Enhanced Incoming Communication Barring.  The users can subscribe to this just as they subscribe to any other service.
So as part of this service execution, the proxy or CSCF needs to look for the Reason header in the incoming CANCEL or BYE requests and if found should pick the mentioned identity and add the identity to the user's black list.

Now say based on this service Alice blocks Bob and the proxy parses the BYE message with Reason header, then the proxy adds Bob's identity to Alice's black list. Now when Bob calls Alice, then Proxy looks into Alice's black list and since Bob's identity is present, sends a 4xx (e.g blocked user) response to Bob indicating that Alice blocked Bob.

In the CR I submitted to 22.173 for enhanced ICB, I mentioned that the Proxy or server can store details like Actual Identity, Published Identity, Reason for block, duration of block for a particular user. Now these details can be standardized as part of a event package and then can be used to notify the users of blocked calls using SUBCRIBE / NOTIFY procedures and XCAP. 

Regards
Ranjit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Tuesday, March 03, 2009 1:53 PM
To: Victor Pascual Ávila; Hadriel Kaplan
Cc: [email-masked]
Subject: Re: [Sipping] New Internet Draft for Caller Identity Blocking

Hi, 

Regards,

Christer
_______________________________________________
Sipping mailing list  https://www.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: Nils Ohlmeier <[email-masked]>
Date: Tue, 03 Mar 2009 10:20:14 +0100

Hi Ranjit,

> So as part of this service execution, the proxy or CSCF needs to look for the Reason header in the incoming CANCEL or BYE requests and if found should pick the mentioned identity and add the identi…

as far as I know IMS supplementary services are implemented by 
application server and not by the CSCF.

> In the CR I submitted to 22.173 for enhanced ICB, I mentioned that the Proxy or server can store details like Actual Identity, Published Identity, Reason for block, duration of block for a particul…

If you want to use SUBSCRIBE and NOTIFY any way, why can't we use the 
draft Hannes mentioned before (we only need to extend it to support 
temporary blocking/blacklisting)?
By pressing exactly the same "red blocking button" on the user interface 
of his device the UA would then simply reject or terminate the call (by 
sending 4xx or BYE) and send a NOTIFY to his blocking/spam server 
immediately. Besides the slight burden of creating two transactions, 
this would have the advantage of being able to route the notification 
seperately from the messages realted to the call.

Regards
   Nils

---

From: Victor Pascual Ávila <[email-masked]>
Date: Tue, 3 Mar 2009 11:01:58 +0100

Hi Nils,

On Tue, Mar 3, 2009 at 10:01 AM, Nils Ohlmeier <[email-masked]> wrote:
> After reading the mails again I thought maybe your intention was to use a
> CANCEL in the following scenario:
> a 3PCC application, lets say a conference service, calls Alice at a given
> time to initiate the scheduled call. When Alices picks up the phone the 3PCC
> application will call Bob (and maybe more participants). But now Alice is
> currently in a more important meeting and wants to block this conference
> call for 30 minutes.
> As the 3PCC acts on behalf of Alice you could think that Alice would need to
> send a CANCEL here to prevent that the call gets established. But this
> assumption is wrong. Again only the 3PCC application could send a CANCEL in
> this scenario. Alice would simply reject the incoming call with 4xx reponse
> to block it for some time.

Yes, I was actually considering scenarios described in rfc3725. An
incoming 4xx or a BYE on legA could represent an outgoing CANCEL on
legB.

Cheers,
-- 
Victor Pascual Ávila

---

From: Victor Pascual Ávila <[email-masked]>
Date: Tue, 3 Mar 2009 11:26:56 +0100

Hi Nils,

On Tue, Mar 3, 2009 at 10:20 AM, Nils Ohlmeier <[email-masked]> wrote:
> why can't we use the draft
> Hannes mentioned before (we only need to extend it to support temporary
> blocking/blacklisting)?
> By pressing exactly the same "red blocking button" on the user interface of
> his device the UA would then simply reject or terminate the call (by sending
> 4xx or BYE) and send a NOTIFY to his blocking/spam server immediately.
> Besides the slight burden of creating two transactions, this would have the
> advantage of being able to route the notification seperately from the
> messages realted to the call.

You are right-- being able to route the feedback information
separately from the call could be an advantage.

I did not follow the discussion on
draft-niccolini-sipping-spam-feedback. Has this work been
discontinued?

Cheers,
-- 
Victor Pascual Ávila

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 3 Mar 2009 12:06:39 +0100

Hi,

Please also keep in mind that CANCEL is hop-to-hop, so if someone inserts a Reason header in the request there is no guarantee that the next hop will forward it.

Regards,

Christer 

> Sent: 3. maaliskuuta 2009 11:07
> To: Christer Holmberg; Victor Pascual Ávila; Hadriel Kaplan
> Cc: [email-masked]
> The caller identity blocking could be offered as a 
> supplementary service - something like Enhanced Incoming 
> Communication Barring.  The users can subscribe to this just 
> as they subscribe to any other service.
> So as part of this service execution, the proxy or CSCF needs 
> to look for the Reason header in the incoming CANCEL or BYE 
> requests and if found should pick the mentioned identity and 
> add the identity to the user's black list.
> 
> Now say based on this service Alice blocks Bob and the proxy 
> parses the BYE message with Reason header, then the proxy 
> adds Bob's identity to Alice's black list. Now when Bob calls 
> Alice, then Proxy looks into Alice's black list and since 
> Bob's identity is present, sends a 4xx (e.g blocked user) 
> response to Bob indicating that Alice blocked Bob.
> 
> In the CR I submitted to 22.173 for enhanced ICB, I mentioned 
> that the Proxy or server can store details like Actual 
> Identity, Published Identity, Reason for block, duration of 
> block for a particular user. Now these details can be 
> standardized as part of a event package and then can be used 
> to notify the users of blocked calls using SUBCRIBE / NOTIFY 
> procedures and XCAP. 
> 
> 
> Regards
> Ranjit
> 
> [mailto:[email-masked]] On Behalf Of Christer Holmberg
> How does I know that there will be a proxy that supports the 
> extension in the first place, and that would remove the 
> header from the CAN/BYE/4xx? If no proxy supports the 
> extension the Reason header may be passed all the way to the UAC...
> 
> Regards,
> 
> Christer

---

From: Henry Sinnreich <[email-masked]>
Date: Tue, 3 Mar 2009 07:57:57 -0800

>draft-niccolini-sipping-spam-feedback.
>Has this work been discontinued?

I agree with this sentiment (and have not followed the discussions either).

The biggest problem to address in public telephone networks are IMO unwanted telemarketing calls and various fund driving calls.
Voice spam calls can be detected by the network operator by their very short duration, since most called parties just hang up.

So is a  "correct" blocking protocol the most effective tool?
Rushing to write one more protocol solution before comparing the alternatives based on measurements...

On a related topic: Such discussions may be better conducted on a Wiki, if the IETF RAI
would extend our toolset beyond the mid 90's technology: Email and RFC .txt I-D only.

Henry

On 3/3/09 4:26 AM, "Victor Pascual Ávila" <[email-masked]> wrote:

Hi Nils,

Cheers,

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 4 Mar 2009 14:55:51 +0100

22.173 is a stage 1 description (i.e. as seen by the end user), and it is a great leap of faith to say that 3GPP therefore need your mechanism rather than any other mechanism.

Keith 

> Sent: Tuesday, March 03, 2009 8:28 AM
> To: Christer Holmberg; [email-masked]
> The mechanism of dynamic blocking of caller identities got 
> approved in 3GPP. The text got included in the latest version 
> of 22.173. 
>  
> 
> 
> Regards
> Ranjit
>