Subject: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-01.txt

From: [email-masked]
Date: Wed, 04 Jan 2017 09:12:34 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Core of the IETF.

        Title           : A SIP Response Code for Unwanted Calls
        Author          : Henning Schulzrinne
	Filename        : draft-ietf-sipcore-status-unwanted-01.txt
	Pages           : 6
	Date            : 2017-01-04

Abstract:
   This document defines the 666 (Unwanted) SIP response code, allowing
   called parties to indicate that the call was unwanted.  SIP entities
   may use this information to adjust how future calls from this calling
   party are handled for the called party or more broadly.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sipcore-status-unwanted/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-sipcore-status-unwanted-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-status-unwanted-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Adam Roach <[email-masked]>
Date: Wed, 4 Jan 2017 12:55:16 -0600

[as chair]

I plan to request publication for this document next week. If you made 
comments during the WGLC, please check that they have been adequately 
represented in the current document in the next couple of days.

/a

On 1/4/17 11:12, [email-masked] wrote:
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 4 Jan 2017 17:22:24 -0500

I reviewed this latest version. IMO it has covered all the concerns I 
had. I have one new thought about it:

Given the discussion that has occurred, it does seem like 666 might 
validly be used with other dialog-establishing requests - notably 
SUBSCRIBE. In that case, it is possible that the SUBSCRIBE itself might 
be accepted, and then the rejection indicated in-dialog. Then it 
wouldn't be BYE, but rather NOTIFY that would carry the 666 as a Reason.

This is a little far fetched, but I would hate to see it excluded. I 
don't see anything that clearly does exclude this usage, so maybe 
nothing needs to be done. OTOH, it might be helpful to at least note 
that other usages, such as this, are possible and not excluded. What do 
others think?

	Thanks,
	Paul

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Wed, 4 Jan 2017 22:29:40 +0000

I agree with Paul, this applies to MESSAGE as well as SUB/NOT on the future

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 4, 2017, at 5:22 PM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:

I reviewed this latest version. IMO it has covered all the concerns I had. I have one new thought about it:

Given the discussion that has occurred, it does seem like 666 might validly be used with other dialog-establishing requests - notably SUBSCRIBE. In that case, it is possible that the SUBSCRIBE itself might be accepted, and then the rejection indicated in-dialog. Then it wouldn't be BYE, but rather NOTIFY that would carry the 666 as a Reason.

This is a little far fetched, but I would hate to see it excluded. I don't see anything that clearly does exclude this usage, so maybe nothing needs to be done. OTOH, it might be helpful to at least note that other usages, such as this, are possible and not excluded. What do others think?

   Thanks,
   Paul

/a

On 1/4/17 11:12, [email-masked]<mailto:[email-masked]> wrote:
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Session Initiation Protocol Core of
the IETF.

Abstract:

Please note that it may take a couple of minutes from the time of
submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

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

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

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 4 Jan 2017 22:41:29 +0000

Interesting corner case. Do you have a particular use case in mind? Would this be a consumer (subscriber) SUBSCRIBEing to a particular event and then not liking the NOTIFYs that follow?

In general, my sense is that we haven't been terribly specific about status code usage, except where the code had a very specific and narrow scope (e.g., on geolocation or resource-priority), and even there we have largely left the method question open, even if the examples or text implied usage with a small subset. For example, most of the status codes defined in 3261 probably never appear in response to a BYE (or CANCEL or OPTIONS). Thus, I wonder if simply having an escape clause similar to the job description "and other duties as assigned" avoids getting into the corner cases. Since an entity getting a 666 acts on it like any 6xx status, in general, there shouldn't be interoperability issues. If you return 666 in response to a CANCEL (not in a Reason), you shouldn't expect anything interesting to happen.

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Wednesday, January 04, 2017 5:22 PM
To: [email-masked]
Subject: Re: [sipcore] Commenters, please check draft-ietf-sipcore-status-unwanted-01.txt

	Thanks,
	Paul

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Thu, 5 Jan 2017 01:09:17 +0000

I do think the document should be clear as to whether there is consistent behaviour on reception of this response code for all methods, or whether it only applies to a subset (and treated as a 600 response in other methods).

I think this is needed so that the end user knows the impact of generating this response code in the first place.

Obviously the actual impacts on a receiving SIP entity are pretty much informational if specified at all, but I think we should know where those impacts are applied, be it only MESSAGE, BYE and INVITE, as the current introduction would apply, or to SUBSCRIBE as well, or indeed to any other dialog forming or stand alone transactions. 

Further if it does appear in a subsequent transaction within a dialog what is the action by the receiver in terms of dialog handling (unless we want to preclude it from subsequent transactions). Is it already covered by RFC 5057.

Keith

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Wednesday, January 04, 2017 5:22 PM
To: [email-masked]
Subject: Re: [sipcore] Commenters, please check draft-ietf-sipcore-status-unwanted-01.txt

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 5 Jan 2017 00:23:41 -0500

> Interesting corner case. Do you have a particular use case in mind? Would this be a consumer (subscriber) SUBSCRIBEing to a particular event and then not liking the NOTIFYs that follow?

I didn't have a particular case in mind. But thinking further...

I guess this could only occur in a case where a human is somehow 
involved in processing the subscription. I'm not sure when that might be.

> In general, my sense is that we haven't been terribly specific about status code usage, except where the code had a very specific and narrow scope (e.g., on geolocation or resource-priority), and e…

Agreed.

	Thanks,
	Paul

---

From: Brett Tate <[email-masked]>
Date: Thu, 5 Jan 2017 08:30:50 -0500

> Further if it does appear in a subsequent transaction within
> a dialog what is the action by the receiver in terms of dialog
> handling (unless we want to preclude it from subsequent
> transactions). Is it already covered by RFC 5057.

RFC 5057 does discuss 6xx handling.  However since note 17 indicates "6xx
unrecognized responses" and Table 1 indicates "unknown 6xx", I'm not
positive if Table 2's 6xx impact (Transaction) was intended to also apply
to known 6xx responses defined subsequent to RFC 5057.

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 05 Jan 2017 09:39:18 -0500

Henning Schulzrinne <[email-masked]> writes:
> Interesting corner case. Do you have a particular use case in mind?
> Would this be a consumer (subscriber) SUBSCRIBEing to a particular
> event and then not liking the NOTIFYs that follow?

The case that came immediately to mind is subscription to
call-completion events -- that can be used as a way to snoop the status
of a particular callee.  See RFC 6910's Security Considerations and
references to that within the RFC.  So a 666 response code to such a
SUBSCRIBE would be a sensible way to object to it as a potential privacy
violation.

Though now that I think about it, that response would almost certainly
be generated by an automaton, not an end-user.

Dale

---

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

[Trying to wrap this up...]

As written, SUBSCRIBE is mentioned, so hopefully your case is covered, leaving the Turing Test issue aside.

Let me know if you think additional wording is needed.

________________________________
From: Dale R. Worley <[email-masked]>
Sent: Thursday, January 5, 2017 9:39 AM
To: Henning Schulzrinne
Cc: [email-masked]
Subject: Re: [sipcore] Commenters, please check draft-ietf-sipcore-status-unwanted-01.txt

Dale

---

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

Would it be helpful to indicate that 666 should be treated as 604 (as that seems most reasonable, given that 666 is probably a dialog killer. Tentative wording:

Following <xref="RFC5057"/>, the 666 response destroys the dialog.

________________________________
From: Brett Tate <[email-masked]>
Sent: Thursday, January 5, 2017 8:30:50 AM
To: Drage, Keith (Nokia - GB); Henning Schulzrinne; [email-masked]
Subject: RE: [sipcore] Commenters, please check draft-ietf-sipcore-status-unwanted-01.txt

---

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

Hi,

Yes; I think that it would be beneficial to discuss mid-dialog 666 in
relation to RFC 5057.

I don’t have a strong opinion about if 666 impacts Transaction Only,
Destroys Usage, or Destroys Dialog.  However even though I’m not sure
if/why someone would send a 666 response for mid-dialog request, it might
be better to only impact the transaction.  For example, media server might
want to return 666 for some mid-dialog requests while continuing to play
treatment associated with INVITE’s 666.

*From:* Henning Schulzrinne [mailto:[email-masked]]
*Sent:* Thursday, January 05, 2017 6:24 PM
*To:* Brett Tate; Drage, Keith (Nokia - GB); [email-masked]
*Subject:* Re: [sipcore] Commenters, please check
draft-ietf-sipcore-status-unwanted-01.txt

Would it be helpful to indicate that 666 should be treated as 604 (as that
seems most reasonable, given that 666 is probably a dialog killer.
Tentative wording:

------------------------------

*From:* Brett Tate <[email-masked]>
*Sent:* Thursday, January 5, 2017 8:30:50 AM
*To:* Drage, Keith (Nokia - GB); Henning Schulzrinne; [email-masked]
*Subject:* RE: [sipcore] Commenters, please check
draft-ietf-sipcore-status-unwanted-01.txt

---

From: Ranjit Avasarala <[email-masked]>
Date: Fri, 6 Jan 2017 13:51:55 -0600

what if the caller is an automata - like a softphone, etc then how does 666
response help in blocking the caller (ip or port may keep changing)

Regards
Ranjit

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 6 Jan 2017 19:57:00 +0000

Blocking would not be based on IP addresses or port numbers, for the reasons you hint at. Treatment is based on calling party number (however carried), recalling the discussion from a few weeks ago (and reflected in the draft) about potential impact of spoofing.

From: Ranjit Avasarala [mailto:[email-masked]]
Sent: Friday, January 06, 2017 2:52 PM
To: Brett Tate <[email-masked]>
Cc: Henning Schulzrinne <[email-masked]>; Drage, Keith (Nokia - GB) <[email-masked]>; SIPCORE <[email-masked]>
Subject: Re: [sipcore] Commenters, please check draft-ietf-sipcore-status-unwanted-01.txt

what if the caller is an automata - like a softphone, etc then how does 666 response help in blocking the caller (ip or port may keep changing)
Regards
Ranjit

On Fri, Jan 6, 2017 at 11:59 AM, Brett Tate <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Yes; I think that it would be beneficial to discuss mid-dialog 666 in relation to RFC 5057.

I don’t have a strong opinion about if 666 impacts Transaction Only, Destroys Usage, or Destroys Dialog.  However even though I’m not sure if/why someone would send a 666 response for mid-dialog request, it might be better to only impact the transaction.  For example, media server might want to return 666 for some mid-dialog requests while continuing to play treatment associated with INVITE’s 666.

From: Henning Schulzrinne [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, January 05, 2017 6:24 PM
To: Brett Tate; Drage, Keith (Nokia - GB); [email-masked]<mailto:[email-masked]>
Subject: Re: [sipcore] Commenters, please check draft-ietf-sipcore-status-unwanted-01.txt

________________________________
From: Brett Tate <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, January 5, 2017 8:30:50 AM
To: Drage, Keith (Nokia - GB); Henning Schulzrinne; [email-masked]<mailto:[email-masked]>
Subject: RE: [sipcore] Commenters, please check draft-ietf-sipcore-status-unwanted-01.txt

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

---

From: Adam Roach <[email-masked]>
Date: Mon, 9 Jan 2017 17:20:47 -0600

Quick comment on the draft based on my review of the changes:

This version added the phrase "or CANCEL", resulting in the phrase: "UAS 
issues a BYE or CANCEL request terminating an incoming call."

A funny story here... Back in the '90's, when I was involved in 
prototyping some mobile SIP clients, one of our prototype clients would 
actually display the reason phrase from any SIP error message it sent or 
received. Our call state machine had specific handling for every message 
type we could receive; and, when stepping through how we could *send* an 
INVITE and *receive* a CANCEL, we determined that it wasn't actually 
possible. So we added code to respond with a 481 and a distinctive 
reason code (to aid in debugging). But these were early days, and the 
implementation had some bugs to work out.

Fast forward to our Pre-IMS system demo for our local executive team -- 
someone managed to take a sequence of actions that actually *did* coax 
the client that was receiving an incoming call into sending out a 
CANCEL. At which point both terminals displayed an error box reading 
"481 Called Party Apparently On Crack."

They didn't appreciate the humor in the situation.

Anyway, these many years later, I'm still pretty sure that a called 
party can't reject an incoming call by sending a CANCEL. And I'm more 
circumspect about how error conditions are communicated to users as well.

/a

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 10 Jan 2017 23:10:22 +0000

What I was thinking of (but didn’t write) is whether it makes sense to include a Reason in the CANCEL with a 666, issued by the UAC. Basically, the call forks, one of the phones ringing gets picked up, the recipient presses the big red spam button and the other phones stop ringing with the indication that somebody just deep-sixed the call.

Is that useful?

From: Adam Roach [mailto:[email-masked]]
Sent: Monday, January 09, 2017 6:21 PM
To: Henning Schulzrinne <[email-masked]>
Cc: [email-masked]
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-01.txt

This version added the phrase "or CANCEL", resulting in the phrase: "UAS issues a BYE or CANCEL request terminating an incoming call."

A funny story here... Back in the '90's, when I was involved in prototyping some mobile SIP clients, one of our prototype clients would actually display the reason phrase from any SIP error message it sent or received. Our call state machine had specific handling for every message type we could receive; and, when stepping through how we could *send* an INVITE and *receive* a CANCEL, we determined that it wasn't actually possible. So we added code to respond with a 481 and a distinctive reason code (to aid in debugging). But these were early days, and the implementation had some bugs to work out.

Fast forward to our Pre-IMS system demo for our local executive team -- someone managed to take a sequence of actions that actually *did* coax the client that was receiving an incoming call into sending out a CANCEL. At which point both terminals displayed an error box reading "481 Called Party Apparently On Crack."

Anyway, these many years later, I'm still pretty sure that a called party can't reject an incoming call by sending a CANCEL. And I'm more circumspect about how error conditions are communicated to users as well.

/a

---

From: Adam Roach <[email-masked]>
Date: Tue, 10 Jan 2017 17:59:05 -0600

Ah, that does seem to make more sense. If you want to mention this case 
in the document, it seems congruent with the example given in section 
3.1 of RFC3326. You'd need to describe the use case more clearly in the 
document, but I see no problems with adding that.

If you do so, it's worth noting at the same time that the use of Reason 
in CANCEL is somewhat fragile due to the fact that RFC3261 places no 
requirement on proxies to copy it forward. Section 2 of RFC3326 does 
call this out at SHOULD strength, but this only reads on proxies that go 
out of their way to implement that RFC (which seems a little unlikely).

/a

On 1/10/17 17:10, Henning Schulzrinne wrote:
>
> What I was thinking of (but didn’t write) is whether it makes sense to 
> include a Reason in the CANCEL with a 666, issued by the UAC. 
> Basically, the call forks, one of the phones ringing gets picked up, 
> the recipient presses the big red spam button and the other phones 
> stop ringing with the indication that somebody just deep-sixed the call.
>
> Is that useful?
>
> *From:*Adam Roach [mailto:[email-masked]]
> *Sent:* Monday, January 09, 2017 6:21 PM
> *To:* Henning Schulzrinne <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [sipcore] I-D Action: 
> This version added the phrase "or CANCEL", resulting in the phrase: 
> "UAS issues a BYE or CANCEL request terminating an incoming call."
>
> prototyping some mobile SIP clients, one of our prototype clients 
> would actually display the reason phrase from any SIP error message it 
> sent or received. Our call state machine had specific handling for 
> every message type we could receive; and, when stepping through how we 
> could *send* an INVITE and *receive* a CANCEL, we determined that it 
> wasn't actually possible. So we added code to respond with a 481 and a 
> distinctive reason code (to aid in debugging). But these were early 
> days, and the implementation had some bugs to work out.
>
> Fast forward to our Pre-IMS system demo for our local executive team 
> -- someone managed to take a sequence of actions that actually *did* 
> coax the client that was receiving an incoming call into sending out a

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 11 Jan 2017 00:10:03 -0500

> out of their way to implement that RFC (which seems a little unlikely).

While the fragility is a problem, it still seems like a good idea.
We could *consider* whether it makes sense to update 3261 to recommend 
supporting this. (But it would take a long time to work its way through 
the ecosystem.)

Note that this isn't only relevant for 666 - it would be relevant for 
other reason codes as well.

	Thanks,
	Paul

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 11 Jan 2017 09:11:34 +0100

> On 11 Jan 2017, at 00:10, Henning Schulzrinne <[email-masked]> wrote:
> 
Yes, because the other phones can delete the call - or not add it - from the “missed calls” list. You don’t want to call back to that number.

/O

> From: Adam Roach [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Henning Schulzrinne <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/sipcore <https://www.ietf.org/mailman/listinfo/sipcore>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 11 Jan 2017 09:14:53 +0100

> On 11 Jan 2017, at 00:59, Adam Roach <[email-masked]> wrote:
> 
> Ah, that does seem to make more sense. If you want to mention this case in the document, it seems congruent with the example given in section 3.1 of RFC3326. You'd need to describe the use case more clearly in the document, but I see no problems with adding that.
> 
> If you do so, it's worth noting at the same time that the use of Reason in CANCEL is somewhat fragile due to the fact that RFC3261 places no requirement on proxies to copy it forward. Section 2 of RFC3326 does call this out at SHOULD strength, but this only reads on proxies that go out of their way to implement that RFC (which seems a little unlikely).
Many servers have implemented the “call answered elsewhere” reason code just to manage the “missed call” lists on the phones. I know
that both Asterisk and Kamailio support this today, so adding this reason would be very simple in those servers.

/O
>> To: Henning Schulzrinne <[email-masked]> <mailto:[email-masked]>

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 12 Jan 2017 15:57:27 +0000

Thanks -  I have added this case and the explanation you mentioned.

From: Olle E. Johansson [mailto:[email-masked]]
Sent: Wednesday, January 11, 2017 3:12 AM
To: Henning Schulzrinne <[email-masked]>
Cc: Olle E Johansson <[email-masked]>; Adam Roach <[email-masked]>; [email-masked]
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-01.txt

On 11 Jan 2017, at 00:10, Henning Schulzrinne <[email-masked]<mailto:[email-masked]>> wrote:

Is that useful?

/O

---

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

I have made the suggested change to “transaction”. Rather than repeating the text in 5057, I have noted that this is in accordance with the 6xx precedent described there. If you’d prefer text, please send. I suspect we agree that the example you give is somewhat contrived, but maybe I’m missing when this would occur in practice. (According to the discussion, 666 would be based on user action, so media servers probably shouldn’t return one…)

From: Brett Tate [mailto:[email-masked]]
Sent: Friday, January 06, 2017 1:00 PM
To: Henning Schulzrinne <[email-masked]>; Drage, Keith (Nokia - GB) <[email-masked]>; [email-masked]
Subject: RE: [sipcore] Commenters, please check draft-ietf-sipcore-status-unwanted-01.txt

Hi,