Subject: [sipcore] I-D Action: draft-ietf-sipcore-rejected-02.txt

From: [email-masked]
Date: Fri, 28 Dec 2018 13:46:07 -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 WG of the IETF.

        Title           : A Session Initiation Protocol (SIP) Response Code for Rejected Calls
        Author          : Eric W. Burger
	Filename        : draft-ietf-sipcore-rejected-02.txt
	Pages           : 21
	Date            : 2018-12-28

Abstract:
   This document defines the 608 (Rejected) SIP response code.  This
   response code enables calling parties to learn an intermediary
   rejected their call attempt.  The call will not be answered.  As a
   6xx code, the caller will be aware that future attempts to contact
   the same UAS will likely fail.  The present use case driving the need
   for the 608 response code is when the intermediary is an analytics
   engine.  In this case, the rejection is by a machine or other
   process.  This contrasts with the 607 (Unwanted) SIP response code,
   which a human at the target UAS indicated the call was not wanted.
   In some jurisdictions this distinction is important.  This document
   defines the use of the Call-Info header in 608 responses to enable
   rejected callers to contact entities that blocked their calls in
   error.

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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-sipcore-rejected-02
https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-rejected-02

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

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: Eric Burger <[email-masked]>
Date: Fri, 28 Dec 2018 16:54:49 -0500

[Cross-posted to IP-NNI, NNI, and STIR lists; please keep any discussion on the SIPCORE list]

What do we have here? This version is resistant to replay attacks. It also lets us trace jCards, if we wish.

I think it’s done, but I’m sure there are glaring holes that could be filled.

Please review.

Thanks, and Happy New Year.

> On Dec 28, 2018, at 4:46 PM, [email-masked] wrote:
> 
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: "Asveren, Tolga" <[email-masked]>
Date: Sun, 30 Dec 2018 14:26:59 +0000

Looks good to me with a few comments:

i-
1. Introduction

As
   described below, we need a distinct indicator to differentiate
   between a user rejection and an intermediary's rejection of a call.
   In some jurisdictions, calls, even if unwanted by the user, may not
   be blocked unless there is an explicit user request.
[TOLGA] I agree with the intend but the wording could be improved IMHO to clarify that 607 is not an “explicit user request”. Maybe by just adding “by other means” to the end of the last sentence?

Specifically, this code informs the UAC an

   intermediary blocked the call and provide a redress mechanism,

   specifically how to contact the operator of the intermediary.
[TOLGA] Couldn’t blocking be done also by the terminating SP and 608 still would be applicable AFAICS. “Intermediary” may cause confusion. It could be an idea to replace it with “an operator on the call path including intermediary operators”.

However, things get more complicated if an intermediary, such as a

   third-party provider of call management services that classify calls

   based on the relative likelihood the call is unwanted, misidentifies

   the call as unwanted.
[TOLGA] Similar comment as the previous one.

ii-
3.3.  UAC Operation

A UAC conforming to this specification MUST include the sip.608

   feature capability tag in the INVITE request.
[TOLGA]What about other requests?
What about a registering end point indicating support in REGISTER Contact? I think the idea is that it still adds sip.608 to the request as well. It could be good to add a clarification about this case.
I think sip.608 means support for jCard as well. That IMHO is a taller order than just supporting a new response code. IMHO it could be good that always “Your calling number is blocked. Please contact the blocking organization based on the following information. Please contact your Originating SP if you don’t see any additional information” is displayed on the UAC upon receipt of 608.

iii-
3.4.  Legacy Interoperation
[TOLGA] A malicious UAC may drain Operator announcement resources by placing many calls with a blocked calling-Id and not signaling sip.608. This can be remedied by playing announcement only once for each blocked calling-Id, or for every nth call, or only when announcement resources are idle. Granted, this could cause some hiccups if the same calling-Id is used by many UACs but still worth mentioning IMHO.

Thanks,
Tolga

Please review.

> On Dec 28, 2018, at 4:46 PM, [email-masked]<mailto:[email-masked]> wrote:
>
>

From: sipcore <[email-masked]> On Behalf Of Eric Burger
Sent: Friday, December 28, 2018 4:55 PM
To: [email-masked]
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-rejected-02.txt

________________________________
NOTICE: This email was received from an EXTERNAL sender
________________________________

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

-----------------------------------------------------------------------------------------------------------------------
Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. that
is confidential and/or proprietary for the sole use of the intended recipient.  Any review, disclosure, reliance or
distribution by others or forwarding without express permission is strictly prohibited.  If you are not the intended
recipient, please notify the sender immediately and then delete all copies, including any attachments.
-----------------------------------------------------------------------------------------------------------------------