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

From: Brett Tate <[email-masked]>
Date: Fri, 13 Jan 2017 15:48:58 -0500

Hi,

Concerning calling party sending BYE with 666, I just thought that it
potentially should be discussed.

However, RFC 3725 figures 4 and figure 7 do show how a “calling party”
might get replaced by a “called party”.  Thus if the controller doesn’t
strip the Reason while relaying the BYE, it definitely would be possible
since both are called parties.

If the “calling party” gets replaced before “called party” sends BYE with
666, who should be flagged: 1) calling party indicated within original
INVITE or 2) newest connected party?

Thanks,

Brett

*From:* Henning Schulzrinne [mailto:[email-masked]]
*Sent:* Thursday, January 12, 2017 3:31 PM
*To:* Brett Tate; [email-masked]; [email-masked]
*Subject:* RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01

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] <[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]]
*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

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 15 Jan 2017 20:48:53 +0000

How likely is any of this going to happen for unwanted robocalls? For figure 4, the one scenario I can think of is the "evil" controller leveraging a service A to call B, and B 666'ing the call or sending a BYE with Reason(666). But that would seem to be pretty standard, even if the final recipient of the 666 or BYE is A (who is likely to ignore it).

I think it would help if you could identify the roles of the third parties and see if that causes the recipient of the unwanted call to do something that's harmful to innocent bystanders.

Henning

________________________________
From: Brett Tate <[email-masked]>
Sent: Friday, January 13, 2017 3:48:58 PM
To: Henning Schulzrinne; [email-masked]
Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01

Hi,

Concerning calling party sending BYE with 666, I just thought that it potentially should be discussed.

However, RFC 3725 figures 4 and figure 7 do show how a “calling party” might get replaced by a “called party”.  Thus if the controller doesn’t strip the Reason while relaying the BYE, it definitely would be possible since both are called parties.

If the “calling party” gets replaced before “called party” sends BYE with 666, who should be flagged: 1) calling party indicated within original INVITE or 2) newest connected party?

Thanks,
Brett

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

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.

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.

Henning

From: Brett Tate [mailto:[email-masked]]
Sent: Friday, January 06, 2017 12:32 PM
To: [email-masked]<mailto:[email-masked]>; Henning Schulzrinne <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[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,

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

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Sun, 15 Jan 2017 20:53:38 +0000

Action on the 666 will be at the called party end in the terminating carrier and not back at the calling party end

Martin C. Dolly
Lead Member of Technical Staff
Core & Government/Regulatory Standards
AT&T
Cell: +1.609.903.3360<tel:+1.609.903.3360>
Email: [email-masked]<mailto:[email-masked]>

On Jan 15, 2017, at 3:49 PM, Henning Schulzrinne <[email-masked]<mailto:[email-masked]>> wrote:

Henning

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

Hi,

Thanks,
Brett

Henning

Hi,

Hi,

BR,
Marianne

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

---

From: Brett Tate <[email-masked]>
Date: Tue, 17 Jan 2017 11:37:18 -0500

Hi,

Concerning the likelihood, I assume that it would depend upon if there is a
convenience, business, or mischievous reason to do it.

As I’ve mentioned, I find the concept of who gets impacted by 666 somewhat
vague within the draft because of the variety of call services (3PCC, call
forwarding, transfer, et cetera) and ways to update the connected identity.
However, I assume that the draft can proceed without needing to clarify
that stuff.

If anyone knows the answers to the following, please let me know.

If the "calling party" gets replaced before "called party" sends BYE with
666, who should be flagged: 1) calling party indicated within original
INVITE or 2) newest connected party?

Should the connected party be flagged if the "calling party" sends BYE with
666?

Should the call forwarding party be flagged when flagging the "calling
party"?  I assume no since potentially innocent bystander.

Should the call transferring party be flagged when flagging the "calling
party"?

Thanks,

Brett

*From:* Henning Schulzrinne [mailto:[email-masked]]
*Sent:* Sunday, January 15, 2017 3:49 PM
*To:* Brett Tate; [email-masked]
*Subject:* Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01

How likely is any of this going to happen for unwanted robocalls? For
figure 4, the one scenario I can think of is the "evil" controller
leveraging a service A to call B, and B 666'ing the call or sending a BYE
with Reason(666). But that would seem to be pretty standard, even if the
final recipient of the 666 or BYE is A (who is likely to ignore it).

I think it would help if you could identify the roles of the third parties
and see if that causes the recipient of the unwanted call to do something
that's harmful to innocent bystanders.

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

*From:* Brett Tate <[email-masked]>
*Sent:* Friday, January 13, 2017 3:48:58 PM
*To:* Henning Schulzrinne; [email-masked]
*Subject:* RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01

Hi,

Thanks,

Brett

Henning

Hi,

Hi,

BR,

Marianne

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 17 Jan 2017 23:05:29 +0000

As I mentioned before, it seems somewhat unlikely that 3PCC scenarios occur for unwanted calls, except by accident or because of forward-on-busy or forward-on-vacation. (Admin assistant transfers a call from “Marriott Hotels” to his boss, thinking that this is about an upcoming hotel reservation, but the call turns out to be spam.) As you note, the forwarding party should not be flagged.

But since it’s the content of the call is deemed objectionable (unwanted) by the recipient, the goal should be to identify the party that is generating that content, even if they try to hide behind somebody else.

I’m probably lacking imagination, but can you explain how these scenarios would occur in the typical robocall, beyond the accidental forwarding case above? I can see incentives for bad actors to hide behind innocent third parties, but I’m not sure that’s what you have in mind for the scenarios below.

Is there a definable notion of the “original” calling party since that seems most likely to be the bad actor?

Henning

From: Brett Tate [mailto:[email-masked]]
Sent: Tuesday, January 17, 2017 11:37 AM
To: Henning Schulzrinne <[email-masked]>; [email-masked]
Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01

Hi,

Concerning the likelihood, I assume that it would depend upon if there is a convenience, business, or mischievous reason to do it.

As I’ve mentioned, I find the concept of who gets impacted by 666 somewhat vague within the draft because of the variety of call services (3PCC, call forwarding, transfer, et cetera) and ways to update the connected identity.  However, I assume that the draft can proceed without needing to clarify that stuff.

If the "calling party" gets replaced before "called party" sends BYE with 666, who should be flagged: 1) calling party indicated within original INVITE or 2) newest connected party?

Should the connected party be flagged if the "calling party" sends BYE with 666?

Should the call forwarding party be flagged when flagging the "calling party"?  I assume no since potentially innocent bystander.

Should the call transferring party be flagged when flagging the "calling party"?

Thanks,
Brett

From: Henning Schulzrinne [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Sunday, January 15, 2017 3:49 PM
To: Brett Tate; [email-masked]<mailto:[email-masked]>
Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01

Henning

Hi,

Thanks,
Brett

Henning

Hi,

Hi,

BR,
Marianne

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 18 Jan 2017 11:39:46 +0000

Looking to this on a “philosophical” level:

I don’t think the right approach is to use calling/called definitions as used in technical specifications. In the context of “666 unwanted”, I am the “caller” if I dial a number. I am the “called” if I receive the call (meaning my UE alerts me) , and this is where this new response code comes into play. It doesn’t matter what (possibly complex) call scenario caused alerting.

I don’t think there is an issue pertaining to draft-ietf-sipcore-status-unwanted on this topic, at least not on a level where text needs to be added/changed.

Thanks,
Tolga

From: sipcore [mailto:[email-masked]] On Behalf Of Henning Schulzrinne
Sent: Tuesday, January 17, 2017 6:05 PM
To: Brett Tate <[email-masked]>; [email-masked]
Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01

Henning

From: Brett Tate [mailto:[email-masked]]
Sent: Tuesday, January 17, 2017 11:37 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

Hi,

Thanks,
Brett

Henning

Hi,

Thanks,
Brett

Henning

Hi,

Hi,

BR,
Marianne

---

From: Brett Tate <[email-masked]>
Date: Wed, 18 Jan 2017 09:04:54 -0500

Hi,

Sometimes those left within the call dialed no digits.  For instance within
RFC 5589 section 6.1’s basic transfer, the transferor could have originally
called transferee.  If transfer target releases call with BYE containing
666, the transferee may or may not be an innocent victim being flagged.
The same could be true concerning section 7.3’s attended transfer; and
there is potentially also race condition exposure concerning desire to send
BYE with 666 on dialog 1 but replaces occurs which causes it to be sent on
dialog 2.

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

I don’t think the right approach is to use calling/called definitions as
used in technical specifications. In the context of “666 unwanted”, I am
the “caller” if I dial a number. I am the “called” if I receive the call
(meaning my UE alerts me) , and this is where this new response code comes
into play. It doesn’t matter what (possibly complex) call scenario caused
alerting.

I don’t think there is an issue pertaining to
draft-ietf-sipcore-status-unwanted on this topic, at least not on a level
where text needs to be added/changed.

Thanks,

Tolga

*From:* sipcore [mailto:[email-masked] <[email-masked]>]
*On Behalf Of *Henning Schulzrinne
*Sent:* Tuesday, January 17, 2017 6:05 PM
*To:* Brett Tate <[email-masked]>; [email-masked]
*Subject:* Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01

As I mentioned before, it seems somewhat unlikely that 3PCC scenarios occur
for unwanted calls, except by accident or because of forward-on-busy or
forward-on-vacation. (Admin assistant transfers a call from “Marriott
Hotels” to his boss, thinking that this is about an upcoming hotel
reservation, but the call turns out to be spam.) As you note, the
forwarding party should not be flagged.

But since it’s the content of the call is deemed objectionable (unwanted)
by the recipient, the goal should be to identify the party that is
generating that content, even if they try to hide behind somebody else.

I’m probably lacking imagination, but can you explain how these scenarios
would occur in the typical robocall, beyond the accidental forwarding case
above? I can see incentives for bad actors to hide behind innocent third
parties, but I’m not sure that’s what you have in mind for the scenarios
below.

Is there a definable notion of the “original” calling party since that
seems most likely to be the bad actor?

Henning

*From:* Brett Tate [mailto:[email-masked] <[email-masked]>]
*Sent:* Tuesday, January 17, 2017 11:37 AM
*To:* Henning Schulzrinne <[email-masked]>; [email-masked]
*Subject:* RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01

Hi,

As I’ve mentioned, I find the concept of who gets impacted by 666 somewhat
vague within the draft because of the variety of call services (3PCC, call
forwarding, transfer, et cetera) and ways to update the connected
identity.  However, I assume that the draft can proceed without needing to
clarify that stuff.

Thanks,

Brett

---

From: Brett Tate <[email-masked]>
Date: Wed, 18 Jan 2017 12:39:33 -0500

Hi,

I’m not sure if there is a definable notion of "original" calling party.
I’m also not sure if BYE 666 should impact connected party or original
calling party.

My questions were not necessarily associated with a typical robocall.  They
were just questions to help me/others understand who should, should not, or
unintentionally might be flagged when receive the 666 within response or
BYE.

For instance, I’m working remotely at 9999 and missed a call from 8888.  I
use a 3PCC client to click-to-call number stored for missed call.  The
controller first uses 7777 (calling party) to call my remote number 9999;
it then reconnects me so calling 8888.  After they answer, I realize that
it was a spam call.  I release the call with BYE 666.  Based upon the
draft, I’m concerned that 7777 might unintentionally only/also get flagged
while attempting to flag 8888.

However using a similar example, 3PCC fraudster robocaller (7777) first
attempts to reach a live fish (9999).  After fish answers, 3PCC reconnects
fish to the fisherman (8888).  Fish releases the call with BYE 666.  This
is a situation where it would be desirable to flag 7777 while attempting to
flag 8888.

Another example of 3PCC is the potential to send INVITE to answer an
incoming call.  The called party is notified of an incoming call.  The
called party sends INVITE to controller to answer the incoming unwanted
call.  The called party sends BYE 666 to controller (unless something
prevents it).  The controller can handle the 666 as desired (even though
appears within dialog to be from caller) and potentially relay it.

As an fyi, I don’t want to slow the draft progression.  Thus unless others
think good enough as-is, adding something like the following to section 4
or 6 might be adequate.

"Some call services such as 3PCC [RFC3725] and call transfer increase the
complexity of identifying who (if anyone) should be impacted by the receipt
of 666 within BYE.  Such services might causes the wrong party to be
flagged or prevent flagging the desired party."

Thanks,

Brett

Henning

Hi,

Thanks,

Brett

Henning

Hi,

Thanks,

Brett

Henning

Hi,

Hi,

BR,

Marianne

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 18 Jan 2017 22:13:50 +0000

I will add the caveat to the Security Considerations, along with any other IETF LC and IESG comments.

Sent: Wednesday, January 18, 2017 12:39:33 PM

Hi,

I’m not sure if there is a definable notion of "original" calling party.  I’m also not sure if BYE 666 should impact connected party or original calling party.

My questions were not necessarily associated with a typical robocall.  They were just questions to help me/others understand who should, should not, or unintentionally might be flagged when receive the 666 within response or BYE.

For instance, I’m working remotely at 9999 and missed a call from 8888.  I use a 3PCC client to click-to-call number stored for missed call.  The controller first uses 7777 (calling party) to call my remote number 9999; it then reconnects me so calling 8888.  After they answer, I realize that it was a spam call.  I release the call with BYE 666.  Based upon the draft, I’m concerned that 7777 might unintentionally only/also get flagged while attempting to flag 8888.

However using a similar example, 3PCC fraudster robocaller (7777) first attempts to reach a live fish (9999).  After fish answers, 3PCC reconnects fish to the fisherman (8888).  Fish releases the call with BYE 666.  This is a situation where it would be desirable to flag 7777 while attempting to flag 8888.

Another example of 3PCC is the potential to send INVITE to answer an incoming call.  The called party is notified of an incoming call.  The called party sends INVITE to controller to answer the incoming unwanted call.  The called party sends BYE 666 to controller (unless something prevents it).  The controller can handle the 666 as desired (even though appears within dialog to be from caller) and potentially relay it.

As an fyi, I don’t want to slow the draft progression.  Thus unless others think good enough as-is, adding something like the following to section 4 or 6 might be adequate.

"Some call services such as 3PCC [RFC3725] and call transfer increase the complexity of identifying who (if anyone) should be impacted by the receipt of 666 within BYE.  Such services might causes the wrong party to be flagged or prevent flagging the desired party."

Thanks,
Brett

Henning

Hi,

Thanks,
Brett

Henning

Hi,

Thanks,
Brett

Henning

Hi,

Hi,

BR,
Marianne

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 19 Jan 2017 12:07:05 +0000

I am not denying such -and many other- complex scenarios, which may require a carefully crafted analysis logic (analysis logic should be aware of the actual flow -directly or indirectly-) in the network but it is not something directly concerning status-unwanted draft. I think we just should have generic/short warning without going into details and it seems we are having a consensus on that. FWIW, I even wouldn't specifically mention about 3PCC etc... and just would indicate that "some calls may require knowledge about actual message flow for efficient interpretation of 666 response code".

Thanks,
Tolga

From: sipcore [mailto:[email-masked]] On Behalf Of Henning Schulzrinne
Sent: Wednesday, January 18, 2017 5:14 PM
To: Brett Tate <[email-masked]>; [email-masked]
Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01

Hi,

I'm not sure if there is a definable notion of "original" calling party.  I'm also not sure if BYE 666 should impact connected party or original calling party.

For instance, I'm working remotely at 9999 and missed a call from 8888.  I use a 3PCC client to click-to-call number stored for missed call.  The controller first uses 7777 (calling party) to call my remote number 9999; it then reconnects me so calling 8888.  After they answer, I realize that it was a spam call.  I release the call with BYE 666.  Based upon the draft, I'm concerned that 7777 might unintentionally only/also get flagged while attempting to flag 8888.

As an fyi, I don't want to slow the draft progression.  Thus unless others think good enough as-is, adding something like the following to section 4 or 6 might be adequate.

Thanks,
Brett

As I mentioned before, it seems somewhat unlikely that 3PCC scenarios occur for unwanted calls, except by accident or because of forward-on-busy or forward-on-vacation. (Admin assistant transfers a call from "Marriott Hotels" to his boss, thinking that this is about an upcoming hotel reservation, but the call turns out to be spam.) As you note, the forwarding party should not be flagged.

But since it's the content of the call is deemed objectionable (unwanted) by the recipient, the goal should be to identify the party that is generating that content, even if they try to hide behind somebody else.

I'm probably lacking imagination, but can you explain how these scenarios would occur in the typical robocall, beyond the accidental forwarding case above? I can see incentives for bad actors to hide behind innocent third parties, but I'm not sure that's what you have in mind for the scenarios below.

Is there a definable notion of the "original" calling party since that seems most likely to be the bad actor?

Henning

Hi,

As I've mentioned, I find the concept of who gets impacted by 666 somewhat vague within the draft because of the variety of call services (3PCC, call forwarding, transfer, et cetera) and ways to update the connected identity.  However, I assume that the draft can proceed without needing to clarify that stuff.

Thanks,
Brett

Henning

Hi,

However, RFC 3725 figures 4 and figure 7 do show how a "calling party" might get replaced by a "called party".  Thus if the controller doesn't strip the Reason while relaying the BYE, it definitely would be possible since both are called parties.

Thanks,
Brett

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.

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.

Henning

Hi,

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

Hi,

BR,
Marianne

---

From: Eric Burger <[email-masked]>
Date: Thu, 19 Jan 2017 06:40:32 -0500

I would be very careful about solving today's problem and missing tomorrow's if we can see it. If there is a way for bad actors to turn 666 into the next ransomeware attack or make 666 useless because innocents get blocked, you can be guaranteed that in Internet time you will find Internet criminals taking advantage of it.

--
Sent from a mobile device. Thank LEMONDADE for that at http://www.standardstrack.com/ietf/lemonade/index.html

> On Jan 18, 2017, at 6:39 AM, Asveren, Tolga <[email-masked]> wrote:
> 
> From: Henning Schulzrinne [mailto:[email-masked]] 
> To: Brett Tate; [email-masked]
> From: Henning Schulzrinne [mailto:[email-masked]] 
> To: Brett Tate; [email-masked]; [email-masked]
> To: [email-masked]; Henning Schulzrinne <[email-masked]>; [email-masked]
> From: [email-masked] [mailto:[email-masked]] 
> To: Henning Schulzrinne; Asveren, Tolga; Brett Tate; [email-masked]
> [email-masked]