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

[Eric Burger <[e-mail]>]

Tolga - As always, thanks for your review!
Thoughts inline.

> On Dec 30, 2018, at 9:26 AM, Asveren, Tolga <[e-mail]> wrote:
> 
> 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?

607 is explicit user request, vs. 608 which is only a guess as to the user’s desire. In many jurisdictions, carriers have an obligation to complete (not block) calls, unless they are obviously illegal or the user explicitly requests blocking the call.

What if we put this into active voice?

This document describes a new SIP response code, 608, which allows calling parties to learn an intermediary rejected their call. 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, an intermediary can only block calls calls if there is an explicit user request. By giving legitimate callers the ability to correct blocks in error, some jurisdictions may decide to allow for intermediaries to block calls with implicit user request.


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

I was thinking ‘intermediary’ in the SIP sense. I was struggling what to call it. Technically, it’s just the UAS, because that’s where the INVITE terminates. However, that is too easy to confuse with the UAS of the INVITE target. I didn’t want to use ‘Proxy’ or B2BUA, because who knows if that’s what it will be.

Do you (or anyone else) have a better term?


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

Well… If you write code to explicitly deal with sip.608, as opposed to just generically handling 6xx), you get to support a JWT encoding of a jCard, including all the PKI support that implies. I.e., the jCard part is the least of your worries. Saying “contact your Originating SP” will be as useful as “Configure your STUN server [to electrocute yourself].” I.e., that will be meaningless information to Joe Average User. That’s also why I didn’t bother to include a multipart/alternate with a text version of the jCard. Either you understand sip.608 or you don’t.

Am I being too strict here?

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

I like the idea. If it is a legal caller, then it’s likely a call center, and one announcement should be enough. If it is a spammer reusing the same calling-id, then who cares if they don’t get the message?

> 
> 
> Thanks,
> Tolga
> 
> 
> 
> [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.