Subject: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01

From: <[email-masked]>
Date: Wed, 4 Jan 2017 22:35:43 +0000

Hi, 

I have the following comments on v01:

-Section 4 - 4rd paragraph:
	The actions described here do not depend on the nature of the SIP
   	URI, e.g., whether it describes a telephone number or not
but in the rest of the document only telephone numbers are mentioned. It would be good to reflect this by using "telephone number or address"? 

-Section 4 - last paragraph:
	We define a SIP feature-capability [RFC6809], sip.666, that allows
   	the registrar to indicate that the corresponding proxy supports this
   	particular response code.
I would suggest: "This document defines a new SIP feature-capability indicator [RFC6809] value, sip.666, that ...

-Section 4 general:
IMO, it would be good to have a paragraph addressing the question of the "calling party number" (mentioned several time in the document): indeed, this calling party number can be identified by the telephone number/address in the From header or the one in the P-Asserted-Identity header that may be different. Depending on the one displayed to the called UA, the 666 could concern only one or both addresses depending on service provider choices. If we take the example of a call-center or an IPBX having the head number and a range of private numbers, the service provider could interpret the 666 from the called user only for the private number (in the From header) or for the whole pool (P-Asserted-Identity). I suggest to have a paragraph to highlight this point. 

-Section 6:
calling party number / calling party address

Best regards,
Marianne

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 4 Jan 2017 19:51:20 -0500

On 1/4/17 5:35 PM, [email-masked] wrote:

> -Section 4 general:
> IMO, it would be good to have a paragraph addressing the question of
> the "calling party number" (mentioned several time in the document):
> indeed, this calling party number can be identified by the telephone
> number/address in the From header or the one in the P-Asserted-Identity
> header that may be different. Depending on the one displayed to the
> called UA, the 666 could concern only one or both addresses depending
> on service provider choices. If we take the example of a call-center or
> an IPBX having the head number and a range of private numbers, the
> service provider could interpret the 666 from the called user only for
> the private number (in the From header) or for the whole pool
> (P-Asserted-Identity). I suggest to have a paragraph to highlight this
> point.

Interesting point. If the PAID is different from the number displayed to 
the callee, and the callee rejects the call without answering, how 
should "blame" be assigned? From the calllee's perspective the complaint 
is *about* the number he saw, regardless of what the identity of the 
actual caller was.

	Thanks,
	Paul

---

From: Brett Tate <[email-masked]>
Date: Thu, 5 Jan 2017 07:53:36 -0500

Hi,

I also agree that adding such a paragraph would be useful.

For instance if someone desires a service to forward all received spam
calls to another set of victims, they would likely not use such a service
if the forwarding party might also get flagged as part of the 666
handling.

> -----Original Message-----
> From: sipcore [mailto:[email-masked]] On Behalf Of Paul
Kyzivat
> Sent: Wednesday, January 04, 2017 7:51 PM
> To: [email-masked]
> Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01
>
> > number/address in the From header or the one in the
> > P-Asserted-Identity header that may be different. Depending on the one
> > displayed to the called UA, the 666 could concern only one or both
> > addresses depending on service provider choices. If we take the
> > example of a call-center or an IPBX having the head number and a range
> > of private numbers, the service provider could interpret the 666 from
> > the called user only for the private number (in the From header) or
> > for the whole pool (P-Asserted-Identity). I suggest to have a
> > paragraph to highlight this point.
>
the
> callee, and the callee rejects the call without answering, how should
"blame"
> be assigned? From the calllee's perspective the complaint is *about* the
> number he saw, regardless of what the identity of the actual caller was.
>
> 	Thanks,
> 	Paul
>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 5 Jan 2017 15:22:55 +0000

I agree that defining what a "call" is a good idea but I have a different take on what it should say:

i-  A "call" in the context of this document is a communication session as perceived by a human agent, e.g. as in "I received a call from my grandmother.". It does not imply anything further as far as SIP information elements which usually are used to carry calling party identification, e.g. P-Asserted-Id, From headers, are concerned. It is up to the operator/network policy how to make associate further calls with the information/decision derived from unwanted calls.

ii- "None of the existing 4xx, 5xx or 6xx response codes signify that calls from this caller are unwanted by the called party."
==>
"None of the existing 4xx, 5xx or 6xx response codes signify that this call is unwanted by the called party."

I think ii- is needed to relive the end user from the burden of "knowing the actual caller".

Thanks,
Tolga

> From: sipcore [mailto:[email-masked]] On Behalf Of Brett Tate
> Sent: Thursday, January 05, 2017 7:54 AM
> To: [email-masked]
> For instance if someone desires a service to forward all received spam calls to
> another set of victims, they would likely not use such a service if the
> forwarding party might also get flagged as part of the 666 handling.
> 
> 
> > > P-Asserted-Identity header that may be different. Depending on the
> > > one displayed to the called UA, the 666 could concern only one or
> > > both addresses depending on service provider choices. If we take the
> > > example of a call-center or an IPBX having the head number and a
> > > range of private numbers, the service provider could interpret the
> > > 666 from the called user only for the private number (in the From
> > > header) or for the whole pool (P-Asserted-Identity). I suggest to
> > > have a paragraph to highlight this point.
> >
> > be assigned? From the calllee's perspective the complaint is *about*
> > the number he saw, regardless of what the identity of the actual caller was.
> >
> > 	Thanks,
> > 	Paul
> >

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 5 Jan 2017 22:45:15 +0000

I'm tempted to follow draft-ietf-stir-rfc4474bis-15 and use the term "caller identity" or "calling party identity", defined as

An identity, for the purposes of this document, is
   defined as either a canonical address-of-record (AoR) SIP URI
   employed to reach a user (such as 'sip:[email-masked]'),
   or a telephone number, which commonly appears in either a TEL URI
   [RFC3966<https://tools.ietf.org/html/rfc3966>] or as the user portion of a SIP URI.

This avoids the awkward "number or address", particularly given that "address" isn't really a formal SIP term and "SIP URI" may not be generic enough.
________________________________
From: sipcore <[email-masked]> on behalf of [email-masked] <[email-masked]>
Sent: Wednesday, January 4, 2017 5:35 PM
To: [email-masked]
Subject: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01

Hi,

-Section 4 general:

-Section 6:

Best regards,
Marianne

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 5 Jan 2017 23:14:18 +0000

On (i), I agree that we don't want to get into what information is being used, given that the entity most likely to use the 666 information, i.e., the terminating carrier, is also the one deciding how caller identity is being presented to the user (PAI, From, etc.).

Tastes may differ, but I don't see how we can say much that's useful to implementors here, without getting into weeds that are already being explored by (say) the SHAKEN effort.

Also, I'm not convinced that defining "call" is needed here, given that we'd probably not go much beyond what's in RFC 3261:

Call: A call is an informal term that refers to some communication
         between peers, generally set up for the purposes of a
         multimedia conversation.

Also, given the discussion of usage for non-INVITE, I'll change "call" to "request" or "dialog" where the context is more than just an example of what is likely to be the most common case - INVITE for a phone call.

Henning

________________________________
From: sipcore <[email-masked]> on behalf of Asveren, Tolga <[email-masked]>
Sent: Thursday, January 5, 2017 10:22:55 AM
To: Brett Tate; [email-masked]
Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01

Thanks,
Tolga

> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_sipcore&d=DgICAg&c=y0h0omCe0jAUGr4gAQ02Fw&r=FJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=TyQ-YmiL8bcHpB4OB5sgh5Qx8F0S1zEJjPY8Hh04CPo&s=OZovdxDmrixSKbFJCEwMHyZojpU8uYeU9ko1LYaC5NY&e=
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_sipcore&d=DgICAg&c=y0h0omCe0jAUGr4gAQ02Fw&r=FJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=TyQ-YmiL8bcHpB4OB5sgh5Qx8F0S1zEJjPY8Hh04CPo&s=OZovdxDmrixSKbFJCEwMHyZojpU8uYeU9ko1LYaC5NY&e=

_______________________________________________
sipcore mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_sipcore&d=DgICAg&c=y0h0omCe0jAUGr4gAQ02Fw&r=FJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=TyQ-YmiL8bcHpB4OB5sgh5Qx8F0S1zEJjPY8Hh04CPo&s=OZovdxDmrixSKbFJCEwMHyZojpU8uYeU9ko1LYaC5NY&e=

---

From: "Asveren, Tolga" <[email-masked]>
Date: Fri, 6 Jan 2017 08:55:29 +0000

I think there is a difference between what "a call" means for end-user and for the network:
For the human agent, it is really nothing more than "Grandma called me". For the network, all the aspects you mentioned would come into play, e.g . which SIP information elements to use to identify the calling party etc.. It could be useful to state this clearly.

I agree that the definition of "Call" from RFC3261" seems adequate as far as human agent is concerned. I also agree that there is no need to artificially limit the applicability just to "calls" -although I believe this would cover 99%  [99.9% if I dare to say] of the use cases-. It could be good to continue using the term "call", reference RFC3261 definition of a "call" and add aa sentence along the lines of:
"It should be noted that "666 unwanted" response code can be used for any SIP request as long as it results a human agent observable stimulus, e.g. audial, visual or otherwise, on which the human agent can express his decision to classify it as "unwanted".

I think the proper meaning of "666 unwanted" is "the human agent considers this particular call as unwanted" rather than "the human agent does not want any further calls from this caller". It will be the network decision what actions will be taken based on this input. Therefore, I think the current wording in the draft should be changed as indicated in ii- below:
"None of the existing 4xx, 5xx or 6xx response codes signify that calls from this caller are unwanted by the called party."
==>
"None of the existing 4xx, 5xx or 6xx response codes signify that this call is unwanted by the called party."

On another note: Is there a need to supply additional information as far as different session types are concerned, e.g. audio call v.s. video call v.s. IM? There could be situations where this is useful, e.g. human agent is fine with IM but does not want voice calls from a certain calling party. OTOH, I think this again should be handled by the network itself and the change I suggested above would be helpful in this sense as well: 666 means that human agent considers this particular session as unwanted. It does not tell anything more as far as other sessions of the same type or of other session types are concerned. He would communicate his choices regarding how this information needs to be treated by other means, e.g. via a Web Portal, if such a a service is provided by the operator.

Thanks,
Tolga

From: Henning Schulzrinne [mailto:[email-masked]]
Sent: Thursday, January 05, 2017 6:14 PM
To: Asveren, Tolga <[email-masked]>; Brett Tate <[email-masked]>; [email-masked]
Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01

         multimedia conversation.

Henning

________________________________
From: sipcore <[email-masked]<mailto:[email-masked]>> on behalf of Asveren, Tolga <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, January 5, 2017 10:22:55 AM
To: Brett Tate; [email-masked]<mailto:[email-masked]>
Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01

Thanks,
Tolga

> To: [email-masked]<mailto:[email-masked]>
> > To: [email-masked]<mailto:[email-masked]>
> > On 1/4/17 5:35 PM, [email-masked]<mailto:[email-masked]> wrote:
> >
> > > -Section 4 general:
> > [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
sipcore mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_sipcore&d=DgICAg&c=y0h0omCe0jAUGr4gAQ02Fw&r=FJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=TyQ-YmiL8bcHpB4OB5sgh5Qx8F0S1zEJjPY8Hh04CPo&s=OZovdxDmrixSKbFJCEwMHyZojpU8uYeU9ko1LYaC5NY&e=

---

From: "Asveren, Tolga" <[email-masked]>
Date: Fri, 6 Jan 2017 11:57:42 +0000

As indicated on another thread, I don't think "technical" definition of a "caller identity" is needed -and actually misleading IMHO considering the purpose of "666 unwanted", but if it really goes through, Service-URN, 3GPP-URN (and possibly more) should be mentioned as well.

But I really do hope that we won't end up there.

Thanks,
Tolga

From: sipcore [mailto:[email-masked]] On Behalf Of Henning Schulzrinne
Sent: Thursday, January 05, 2017 5:45 PM
To: [email-masked]; [email-masked]
Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01

From: sipcore <[email-masked]<mailto:[email-masked]>> on behalf of [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>

Hi,

-Section 4 general:

-Section 6:

Best regards,
Marianne

---

From: <[email-masked]>
Date: Fri, 6 Jan 2017 15:28:23 +0000

I am in favor of terms "caller identity" or "calling party identity".

BR,
Marianne

De : Henning Schulzrinne [mailto:[email-masked]]
Envoyé : jeudi 5 janvier 2017 23:45
À : MOHALI Marianne IMT/OLN; [email-masked]
Objet : Re: Comments on draft-ietf-sipcore-status-unwanted-01

Hi,

-Section 4 general:

-Section 6:

Best regards,
Marianne

---

From: <[email-masked]>
Date: Fri, 6 Jan 2017 15:28:28 +0000

Hi,

To reflect the question of the interpretation of the 666 response interpretation when the caller has several identities used for this call (ie. From and P-Asserted-Identity are different) or call forwarding/call transfer use cases for which it has to be discussed which party should be considered has a fraudulent (ie. the calling party or the diverting party or both ?) ; I propose to add the following text:
This document defines a mechanism by which a called party can reject an unwanted call without consideration of the calling party identification that remain to the service provider policy. Indeed, the calling party identity may be reflected in different way for a direct call or after a diverting service in P-Asserted-Identity, From, History-Info or any concurrent header field that can be present at the same time in a SIP message.

Those questions are real issues for operators and implementors and they are a weakness that fraudulent callers could use to bypass the mechanism.

BR,
Marianne

De : sipcore [mailto:[email-masked]] De la part de Henning Schulzrinne
Envoyé : vendredi 6 janvier 2017 00:14
À : Asveren, Tolga; Brett Tate; [email-masked]
Objet : Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01

         multimedia conversation.

Henning

Thanks,
Tolga

---

From: Brett Tate <[email-masked]>
Date: Fri, 6 Jan 2017 12:32:17 -0500

Hi,

The draft potentially should also discuss the potential for the connected
party to change mid-dialog 1) without it being communicated and 2) with it
being communicate by RFC 4916, RFC 5876, et cetera.

>From a security considerations perspective, the wrong party might be
flagged by the 666 when the connected party changes.

The draft should potentially also discuss the potential for calling party
indicating 666.  Other than a way to attack someone, I’m not sure if are
any 3PCC, transfer, or other service situations where it might actually be
appropriate.

*From:* [email-masked] [mailto:[email-masked]]
*Sent:* Friday, January 06, 2017 10:28 AM
*To:* Henning Schulzrinne; Asveren, Tolga; Brett Tate; [email-masked]
*Subject:* RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01

Hi,

To reflect the question of the interpretation of the 666 response
interpretation when the caller has several identities used for this call
(ie. From and P-Asserted-Identity are different) or call forwarding/call
transfer use cases for which it has to be discussed which party should be
considered has a fraudulent (ie. the calling party or the diverting party
or both ?) ; I propose to add the following text:

This document defines a mechanism by which a called party can reject an
unwanted call without consideration of the calling party identification
that remain to the service provider policy. Indeed, the calling party
identity may be reflected in different way for a direct call or after a
diverting service in P-Asserted-Identity, From, History-Info or any
concurrent header field that can be present at the same time in a SIP
message.

Those questions are real issues for operators and implementors and they are
a weakness that fraudulent callers could use to bypass the mechanism.

BR,

Marianne

*De :* sipcore [mailto:[email-masked] <[email-masked]>] *De
la part de* Henning Schulzrinne
*Envoyé :* vendredi 6 janvier 2017 00:14
*À :* Asveren, Tolga; Brett Tate; [email-masked]
*Objet :* Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01

On (i), I agree that we don't want to get into what information is being
used, given that the entity most likely to use the 666 information, i.e.,
the terminating carrier, is also the one deciding how caller identity is
being presented to the user (PAI, From, etc.).

Tastes may differ, but I don't see how we can say much that's useful to
implementors here, without getting into weeds that are already being
explored by (say) the SHAKEN effort.

Also, I'm not convinced that defining "call" is needed here, given that
we'd probably not go much beyond what's in RFC 3261:

         multimedia conversation.

Also, given the discussion of usage for non-INVITE, I'll change "call" to
"request" or "dialog" where the context is more than just an example of
what is likely to be the most common case - INVITE for a phone call.

Henning
------------------------------

*From:* sipcore <[email-masked]> on behalf of Asveren, Tolga <
[email-masked]>
*Sent:* Thursday, January 5, 2017 10:22:55 AM
*To:* Brett Tate; [email-masked]
*Subject:* Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01

I agree that defining what a "call" is a good idea but I have a different
take on what it should say:

i-  A "call" in the context of this document is a communication session as
perceived by a human agent, e.g. as in "I received a call from my
grandmother.". It does not imply anything further as far as SIP information
elements which usually are used to carry calling party identification, e.g.
P-Asserted-Id, From headers, are concerned. It is up to the
operator/network policy how to make associate further calls with the
information/decision derived from unwanted calls.

ii- "None of the existing 4xx, 5xx or 6xx response codes signify that calls
from this caller are unwanted by the called party."
==>
"None of the existing 4xx, 5xx or 6xx response codes signify that this call
is unwanted by the called party."

I think ii- is needed to relive the end user from the burden of "knowing
the actual caller".

Thanks,
Tolga

> From: sipcore [mailto:[email-masked] <[email-masked]>]
On Behalf Of Brett Tate
> For instance if someone desires a service to forward all received spam
calls to
> > From: sipcore [mailto:[email-masked]
<[email-masked]>] On Behalf Of Paul

Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les
messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere,
deforme ou falsifie. Merci.

This message and its attachments may contain confidential or
privileged information that may be protected by law;

If you have received this email in error, please notify the sender and
delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have
been modified, changed or falsified.

Thank you.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 6 Jan 2017 12:43:27 -0500

On 1/6/17 10:28 AM, [email-masked] wrote:
> transfer use cases for which it has to be discussed which party should
> be considered has a fraudulent (ie. the calling party or the diverting
> party or both ?) ; I propose to add the following text:
>
> Those questions are real issues for operators and implementors and they
> are a weakness that fraudulent callers could use to bypass the mechanism.

ISTM there are two different cases here, and the identity implications 
differ between them:

1) the callee rejects the call without consideration of the content of 
the call. Instead, the rejection is based solely on metadata about the 
call that is available to the callee - e.g., callerid information 
presented, classification information, possibly time of day. It might 
also include information provided locally by the phone (e.g. from the 
local address book).

In this case the actual caller may be blameless. So care must be taken 
in associating the rejection with the caller.

2) the callee rejects the call after answering, based on the media 
content of the call.

In this case the rejection clearly applies to the caller even if the 
callee doesn't know the caller's identity.

It may be difficult to distinguish between these. Certainly using 666 as 
a response code must be case (1). But using 666 as a reason isn't 
necessarily case (2) - the callee may be slow and reject based on 
metadata after answering, or may use a combination of content and 
metadata in making that decision.

This is not something that can be resolved in this document, but it may 
be worthwhile to identify that these issues exist and must be considered 
by those who act on 666 responses.

	Thanks,
	Paul

---

From: "Asveren, Tolga" <[email-masked]>
Date: Sat, 7 Jan 2017 19:53:50 +0000

Inline...

Thanks,
Tolga

> From: sipcore [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Friday, January 06, 2017 12:43 PM
> To: [email-masked]
> > interpretation when the caller has several identities used for this
> > call (ie. From and P-Asserted-Identity are different) or call
> > forwarding/call transfer use cases for which it has to be discussed
> > which party should be considered has a fraudulent (ie. the calling
> > party or the diverting party or both ?) ; I propose to add the following text:
> >
> > This document defines a mechanism by which a called party can reject
> > an unwanted call without consideration of the calling party
> > identification that remain to the service provider policy. Indeed, the
> > calling party identity may be reflected in different way for a direct
> > call or after a diverting service in P-Asserted-Identity, From,
> > History-Info or any concurrent header field that can be present at the
> > same time in a SIP message.
> >
> > Those questions are real issues for operators and implementors and
> > they are a weakness that fraudulent callers could use to bypass the
> mechanism.
> 
> ISTM there are two different cases here, and the identity implications differ
> between them:
> 
> 1) the callee rejects the call without consideration of the content of the call.
> Instead, the rejection is based solely on metadata about the call that is
> available to the callee - e.g., callerid information presented, classification
> information, possibly time of day. It might also include information provided
> locally by the phone (e.g. from the local address book).
> 
> In this case the actual caller may be blameless. So care must be taken in
> associating the rejection with the caller.
> 
> 2) the callee rejects the call after answering, based on the media content of
> the call.
> 
> In this case the rejection clearly applies to the caller even if the callee doesn't
> know the caller's identity.
> 
> It may be difficult to distinguish between these. Certainly using 666 as a
> response code must be case (1). But using 666 as a reason isn't necessarily
> case (2) - the callee may be slow and reject based on metadata after
> answering, or may use a combination of content and metadata in making that
> decision.
> 
> This is not something that can be resolved in this document, but it may be
> worthwhile to identify that these issues exist and must be considered by
> those who act on 666 responses.
[TOLGA] Even not that IMHO. It seems to me a better option to keep the document "clean" as far as its intention is used.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 12 Jan 2017 20:31:18 +0000

I’m afraid I don’t quite follow what text you are suggesting and I’m suspecting we’re well into the weeds at this point. My general inclination is to only state things where 666 differs from 6xx handling, rather than try to capture all possible status code issues that are generic to (most) 6xx codes. This avoids creating inadvertent contradictions or the need to update the document should there be changes in the generic handling. In other words, 666 should be treated like 6xx unless otherwise noted.

Thus, can you provide suggested text?

I’m not sure why the calling party would indicate 666. After receiving a re-INVITE? In response to a BYE? I admit that I lack the imagination as to how this would occur and why this would cause anything other than what would happen for a generic 6xx response in those circumstances.

Stretching the imagination, I could imagine the case where I’m misled into dialing a number (e.g., as part of a spam email) that turns out to be a robot peddling time shares. I could send a BYE, with a 666 Reason.

Is that the case you have in mind?

Henning

From: Brett Tate [mailto:[email-masked]]
Sent: Friday, January 06, 2017 12:32 PM
To: [email-masked]; Henning Schulzrinne <[email-masked]>; [email-masked]
Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01

Hi,

The draft potentially should also discuss the potential for the connected party to change mid-dialog 1) without it being communicated and 2) with it being communicate by RFC 4916, RFC 5876, et cetera.

From a security considerations perspective, the wrong party might be flagged by the 666 when the connected party changes.

The draft should potentially also discuss the potential for calling party indicating 666.  Other than a way to attack someone, I’m not sure if are any 3PCC, transfer, or other service situations where it might actually be appropriate.

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, January 06, 2017 10:28 AM
To: Henning Schulzrinne; Asveren, Tolga; Brett Tate; [email-masked]<mailto:[email-masked]>
Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01

Hi,

BR,
Marianne

De : sipcore [mailto:[email-masked]] De la part de Henning Schulzrinne
Envoyé : vendredi 6 janvier 2017 00:14
À : Asveren, Tolga; Brett Tate; [email-masked]<mailto:[email-masked]>
Objet : Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01

         multimedia conversation.

Henning

Thanks,
Tolga

Thank you.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 12 Jan 2017 20:41:02 +0000

Any suggested wording? I think, in general, it will be impossible for the called party's carrier to know what the decision is based on. Even content can be misleading - I might think it's a sales call, but it turns out to be a product defect recall. (I suspect you've gotten calls starting with "This is not a sales call.", which usually means that I definitely don't want to talk to the non-sales-caller since it's most likely a scam instead...)

If the 666 is used for statistical call filtering, we have to rely on the wisdom of the crowd, and assume some fraction of both false negatives and positives. As Martin has indicated earlier, maybe experience will indicate that mid-call 666's are better indicators, but that's all guesswork so far.

Thus, to avoid too many "in some cases, but in other cases" sentences, please send text if you have specific actionable implementer guidance.

Note that the text currently already alludes to the difference ("Receiving system could decide to treat..."), so I think the general angle has been covered.

Henning

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Friday, January 06, 2017 12:43 PM
To: [email-masked]
Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01

On 1/6/17 10:28 AM, [email-masked] wrote:
> they are a weakness that fraudulent callers could use to bypass the mechanism.

ISTM there are two different cases here, and the identity implications differ between them:

1) the callee rejects the call without consideration of the content of the call. Instead, the rejection is based solely on metadata about the call that is available to the callee - e.g., callerid information presented, classification information, possibly time of day. It might also include information provided locally by the phone (e.g. from the local address book).

In this case the actual caller may be blameless. So care must be taken in associating the rejection with the caller.

2) the callee rejects the call after answering, based on the media content of the call.

In this case the rejection clearly applies to the caller even if the callee doesn't know the caller's identity.

It may be difficult to distinguish between these. Certainly using 666 as a response code must be case (1). But using 666 as a reason isn't necessarily case (2) - the callee may be slow and reject based on metadata after answering, or may use a combination of content and metadata in making that decision.

This is not something that can be resolved in this document, but it may be worthwhile to identify that these issues exist and must be considered by those who act on 666 responses.

	Thanks,
	Paul

_______________________________________________
sipcore mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_sipcore&d=DgICAg&c=y0h0omCe0jAUGr4gAQ02Fw&r=FJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=w6-F-EQyZVD_u9zlhZF0qJKOYhLoEynLstyHM8ce6lk&s=x7kUOPzC2LyOOaY-S0KpNT5m0dU-lrQgNXq2eiQpWpE&e=

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 12 Jan 2017 21:34:58 +0000

I have added a sentence in the SIP URI paragraph:

"The calling party may be identified in different locations in the SIP header, e.g., the From header field, P-Asserted-Identity or History-Info, and may also be affected by diverting services."

Henning

From: [email-masked] [mailto:[email-masked]]
Sent: Friday, January 06, 2017 10:28 AM
To: Henning Schulzrinne <[email-masked]>; Asveren, Tolga <[email-masked]>; Brett Tate <[email-masked]>; [email-masked]
Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01

Hi,

BR,
Marianne

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 12 Jan 2017 21:38:36 +0000

The term "caller identity" is now used instead of "number".

From: [email-masked] [mailto:[email-masked]]
Sent: Friday, January 06, 2017 10:28 AM
To: Henning Schulzrinne <[email-masked]>; [email-masked]
Subject: RE: Comments on draft-ietf-sipcore-status-unwanted-01

BR,
Marianne

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 12 Jan 2017 21:46:53 +0000

The suggested wording for the "None" sentence has been included (with the other change that we're now talking about SIP requests).

As to the IM vs. call, I admit that I find it hard to conjure up a realistic use case. I do sometimes tell charities to send me their pitch by postal mail (to avoid being scammed by impostors, among other reasons), but I doubt that a button would be useful, or that I'd want to hear from them by IM.

On the other hand, a facility to only be contacted by IM and never by voice will be welcomed by all teenagers, so maybe there's an opportunity here for future work.

Henning

From: Asveren, Tolga [mailto:[email-masked]]
Sent: Friday, January 06, 2017 3:55 AM
To: Henning Schulzrinne <[email-masked]>; [email-masked]
Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01

Thanks,
Tolga

From: Henning Schulzrinne [mailto:[email-masked]]
Sent: Thursday, January 05, 2017 6:14 PM
To: Asveren, Tolga <[email-masked]<mailto:[email-masked]>>; Brett Tate <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01

         multimedia conversation.

Henning

Thanks,
Tolga

---

From: Richard Shockey <[email-masked]>
Date: Thu, 12 Jan 2017 17:14:35 -0500

+1

It would be very helpful if we could get one simple thing actually done.  

— 

Richard Shockey

Shockey Consulting LLC

Chairman of the Board SIP Forum

www.shockey.us

www.sipforum.org

richard<at>shockey.us

Skype-Linkedin-Facebook rshockey101

PSTN +1 703-593-2683

From: sipcore <[email-masked]> on behalf of Henning Schulzrinne <[email-masked]>
Date: Thursday, January 12, 2017 at 4:46 PM
To: "Asveren, Tolga" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01

The suggested wording for the “None” sentence has been included (with the other change that we’re now talking about SIP requests).

As to the IM vs. call, I admit that I find it hard to conjure up a realistic use case. I do sometimes tell charities to send me their pitch by postal mail (to avoid being scammed by impostors, among other reasons), but I doubt that a button would be useful, or that I’d want to hear from them by IM.

On the other hand, a facility to only be contacted by IM and never by voice will be welcomed by all teenagers, so maybe there’s an opportunity here for future work.

Henning

I think there is a difference between what “a call” means for end-user and for the network:

For the human agent, it is really nothing more than “Grandma called me”. For the network, all the aspects you mentioned would come into play, e.g . which SIP information elements to use to identify the calling party etc.. It could be useful to state this clearly. 

I agree that the definition of “Call” from RFC3261” seems adequate as far as human agent is concerned. I also agree that there is no need to artificially limit the applicability just to “calls” -although I believe this would cover 99%  [99.9% if I dare to say] of the use cases-. It could be good to continue using the term “call”, reference RFC3261 definition of a “call” and add aa sentence along the lines of:

“It should be noted that “666 unwanted” response code can be used for any SIP request as long as it results a human agent observable stimulus, e.g. audial, visual or otherwise, on which the human agent can express his decision to classify it as “unwanted”. 

I think the proper meaning of “666 unwanted” is “the human agent considers this particular call as unwanted” rather than “the human agent does not want any further calls from this caller”. It will be the network decision what actions will be taken based on this input. Therefore, I think the current wording in the draft should be changed as indicated in ii- below:

==>

Thanks,

Tolga

Henning

Thanks,
Tolga

_______________________________________________ sipcore mailing list [email-masked] https://www.ietf.org/mailman/listinfo/sipcore

---

From: "Asveren, Tolga" <[email-masked]>
Date: Fri, 13 Jan 2017 06:25:40 +0000

Agreed.

Arguably there is nothing to do anyhow: 666 tells that *this particular* session is unwanted. Network logic can determine what to do based on this indication, e.g. use it as input only for this particular session type v.s. for all session types. This is not something in scope of “status unwanted” -and is the right mentality IMHO-.

Thanks,
Tolga

From: Richard Shockey [mailto:[email-masked]]
Sent: Thursday, January 12, 2017 5:15 PM
To: Henning Schulzrinne <[email-masked]>; Asveren, Tolga <[email-masked]>; [email-masked]
Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01

+1

—

Richard Shockey

Shockey Consulting LLC

www.shockey.us<http://www.shockey.us>

www.sipforum.org<http://www.sipforum.org>

richard<at>shockey.us

PSTN +1 703-593-2683

From: sipcore <[email-masked]<mailto:[email-masked]>> on behalf of Henning Schulzrinne <[email-masked]<mailto:[email-masked]>>
Date: Thursday, January 12, 2017 at 4:46 PM
To: "Asveren, Tolga" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01

Henning

From: Asveren, Tolga [mailto:[email-masked]]
Sent: Friday, January 06, 2017 3:55 AM
To: Henning Schulzrinne <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01

Thanks,
Tolga

         multimedia conversation.

Henning

Thanks,
Tolga

_______________________________________________
sipcore mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_sipcore&d=DgICAg&c=y0h0omCe0jAUGr4gAQ02Fw&r=FJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=TyQ-YmiL8bcHpB4OB5sgh5Qx8F0S1zEJjPY8Hh04CPo&s=OZovdxDmrixSKbFJCEwMHyZojpU8uYeU9ko1LYaC5NY&e=
_______________________________________________ sipcore mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 13 Jan 2017 17:07:11 -0500

> Note that the text currently already alludes to the difference ("Receiving system could decide to treat..."), so I think the general angle has been covered.

Having talked this through, and after reading the latest version, I 
can't think of anything more to say that belongs in this document.

	Thanks,
	Paul