Hi Ranjit,
Am 03.03.2009 10:06 Uhr, schrieb Avasarala Ranjit-A20990:
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.
as far as I know IMS supplementary services are implemented by
application server and not by the CSCF.
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.
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
Regards
Ranjit
-----Original Message-----
From: sipping-bounces@xxxxxxxx [mailto:sipping-bounces@xxxxxxxx] On Behalf Of Christer Holmberg
Sent: Tuesday, March 03, 2009 1:53 PM
To: Victor Pascual Ávila; Hadriel Kaplan
Cc: sipping@xxxxxxxx
Subject: Re: New Internet Draft for Caller Identity Blocking
Hi,
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.
I believe the header can reveal sensitive information for an attacker:
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
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP
