Re: [stir] [sipcore] New Version Notification for draft-ietf-sipcore-rejected-03.txt

“I might have been thinking of the US situation where it is likely to be the terminating provider providing the blocking service. In the US, it’s trivial to look up the terminating provider from the number. For a carrier, its the LERG and NPAC. For a consumer, there are tons of free Web directories.”
Yes, technically definitely possible. I just think of the practical aspects. It is even cumbersome to deal with one’s own operator let alone a 3rd party.

“If there is a central phone number to call in a country for remediation, there’s no need for Call-Info, because presumably the callers will know the central phone number to call.”
Exactly, and I would think this is not something unlikely.

Nonetheless, I think what matters is that it is spelled out clearly that Call-Info may be omitted. I just would prefer that the “central number” option is cited as well.

Thanks,
Tolga

From: Eric Burger <eburger@standardstrack.com>
Sent: Monday, February 4, 2019 6:53 PM
To: Asveren, Tolga <tasveren@rbbn.com>
Cc: stir@ietf.org Mail List <stir@ietf.org>
Subject: Re: [stir] [sipcore] New Version Notification for draft-ietf-sipcore-rejected-03.txt

I might have been thinking of the US situation where it is likely to be the terminating provider providing the blocking service. In the US, it’s trivial to look up the terminating provider from the number. For a carrier, its the LERG and NPAC. For a consumer, there are tons of free Web directories.

If there is a central phone number to call in a country for remediation, there’s no need for Call-Info, because presumably the callers will know the central phone number to call.

On Feb 4, 2019, at 5:32 PM, Asveren, Tolga <tasveren@rbbn.com<mailto:tasveren@rbbn.com>> wrote:

Looks good to me with a single comment:

“Since the decision of whether to include Call-Info in the 608
   response is a matter of policy, one thing to consider is whether a
   legitimate caller can ascertain whom to contact without such
   information being included in the 608.  For example, in some
   jurisdictions, if the terminating service provider is the
   intermediary, the caller can lookup who the terminating service
   provider is based on the routing information for the dialled number.
   As such, the Call-Info jCard could be redundant information.
   However, the factors going into a particular service provider's or
   jourisdiction's choice of whether or not to include Call-Info is
   outside the scope of this document.”

The example confused me. How would the caller know that the intermediary is the terminating network? How would caller know which number to call? The use case of potentially not including Call-Info/jCard I had in mind was:

  *   Caller calls his own operator, which follows up the issue on his behalf
  *   There is a single, nation-wide number for the caller to contact (and that may be provided to caller party)

Thanks,
Tolga

1. Addressed /most/ of Tolga's nits. I decided to leave ‘intermediary’ as is. If the WG disagrees, I won’t fall on my sword for it and will do a global substitution.

2. Fixed some unclear language Bhavik found when implementing the draft.

3. BTW, that means we have an open-source prototype at https://github.com/nagdab/608_Implementation<https://github.com/nagdab/608_Implementation>

I think we’re done. What do *you* think?

- Eric

>> On Feb 3, 2019, at 2:50 PM, internet-drafts@ietf.org<mailto:internet-drafts@ietf.org> wrote:
>>
>>
>> A new version of I-D, draft-ietf-sipcore-rejected-03.txt
>> has been successfully submitted by Eric W. Burger and posted to the
>> IETF repository.
>>
>> Name:                            draft-ietf-sipcore-rejected
>> Revision:        03
>> Title:                                A Session Initiation Protocol (SIP) Response Code for Rejected Calls
>> Document date:         2019-02-03
>> Group:                            sipcore
>> Pages:                             22
>> URL:            https://www.ietf.org/internet-drafts/draft-ietf-sipcore-rejected-03.txt<https://www.ietf.org/internet-drafts/draft-ietf-sipcore-rejected-03.txt>
>> Status:         https://datatracker.ietf.org/doc/draft-ietf-sipcore-rejected/<https://datatracker.ietf.org/doc/draft-ietf-sipcore-rejected/>
>> Htmlized:       https://tools.ietf.org/html/draft-ietf-sipcore-rejected-03<https://tools.ietf.org/html/draft-ietf-sipcore-rejected-03>
>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-rejected<https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-rejected>
>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-rejected-03<https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-rejected-03>
>>
>> Abstract:
>>  This document defines the 608 (Rejected) SIP response code.  This
>>  response code enables calling parties to learn that 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
>>  also defines the use of the Call-Info header in 608 responses to
>>  enable rejected callers to contact entities that blocked their calls
>>  in error.  This provides a remediation mechanism for legal callers
>>  that find their calls blocked.
>>
>>
>>
>>
>> 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/>.
>>
>> The IETF Secretariat
>>
>

________________________________
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.
________________________________
_______________________________________________
stir mailing list
stir@ietf.org<mailto:stir@ietf.org>
https://www.ietf.org/mailman/listinfo/stir<https://www.ietf.org/mailman/listinfo/stir>