Re: [sipcore] [stir] draft-ietf-sipcore-callinfo-04 (call-reason)

Generalizing further:

  *   For real-time interactive communications (mainly voice/video), prior to responding (answering the call) the recipient can only determine the credibility of the content they are about to receive based on the "call metadata".
  *   The best we can ever do in technical specifications is to ensure correct conveyance of ID information in that metadata from the call origination point to the termination point.  That can be done in a chain manner, which is relatively easy to break (e.g. due to lack of applicable specs/standards, or their application), but is better achieved on an end-to-end basis.
  *   The recipient can use a verified ID to look up reputational information on the caller (& that may include the reputation of the ID supplier).  Provision & verification of reputational information is way outside the remit of any technical group.

If we consider the above it is relatively easy to determine how any addition to a technical specification will result in better achievement of the ultimate goal, which to create/restore trust in, or at least to enable the recipient to make judgement on, the validity of the content of real-time communications.

/David

David Holmes  (He/Him/His)
Industry Forums & Relations
T-Mobile USA
Direct 425.256.7082 | Mobile 425.260.1868  | david.holmes@t-mobile.com<mailto:david.holmes@t-mobile.com>
T-Mobile.com<http://www.t-mobile.com/> | Follow T-Mobile on Twitter<https://twitter.com/tmobile>, Facebook<https://www.facebook.com/TMobile> and Instagram<http://instagram.com/tmobile>

From: stir <stir-bounces@ietf.org> On Behalf Of Henning Schulzrinne
Sent: Friday, March 18, 2022 1:05 PM
To: Chris Wendt <chris-ietf@chriswendt.net>
Cc: stir@ietf.org; SIPCORE <sipcore@ietf.org>
Subject: Re: [stir] [sipcore] draft-ietf-sipcore-callinfo-04 (call-reason)

[External]

Generalizing a bit, we are trying to provide information that allows a called party to decide whether to (1) accept the call; (2) trust the caller in some sense ("this is a real charity; this is actually a real bank; this call is important enough to answer"), with both (1) and (2) probably outsourced to your favorite ML/AI/robot service in some cases, whether enterprise phishing/fraud prevention or some service for residential users.

We use a variety of means for this:
* information about the telephone identity (usually, TN) of the caller -> STIR "classic", using From, mostly, but also the various P-Asserted-Identity, verstat and similar headers
* information about the caller's "real world" identity -> RCD
* information about the nature of the call -> SDP and others ("sorry, no video calls"); possible the Subject header and the call-reason field

All of these have different sources and change periods:
* TNs often don't change for decades and are best provided (or validated) and, where available, signed by the OSP, but may also be inserted by intermediaries, e.g., in SS7-to-SIP gateways.

* RCD may change more frequently (people move, businesses change names), but are also best provided by the OSP, at least for most users, e.g., based on billing addresses and the KYC process. This will be pretty much required for the JWT version. This means there's relatively little opportunity for inappropriate content, for example.

* The nature of the call is, by necessity, provided by the caller, on a call-by-call basis. Unless one creates another API from the UA to the local PBX (or carrier), it would have to be either merged with the RCD data or carried in two Call-Info headers. If the carrier merges it, this blurs the responsibility - it makes it look like the carrier vouches for the call purpose, which they presumably want nothing to do with. Given the potential for abuse, you probably need to provide the called party with an opportunity to suppress this. (This new text channel is a perfect way to harass people or businesses with messages, at no cost and none of the SMS campaign registration and cost overhead.)

Also, for regulated businesses such as banks, the call purpose information would need to be recorded and possibly filtered - you don't want this to be used to bypass content filters and flagging. ("Buy T at $100"). Putting this in the same header as the RCD is not helpful - it just makes it messier.

Thus, the call-purpose information is much more akin to a new messaging channel - after all, the caller can just make a bunch of calls, each with a new call-purpose (or Subject).

Thus, RCD and call-purpose share very little in terms of responsibility, spam risks and method of generation. Combining them in one header offers little advantage and just blurs responsibility.

Providing a reason for the call was the original motivation for the Subject header. This hasn't been too successful, but the new proposal, in my view, makes things worse and addresses none of the likely reasons for the Subject non-success.

If there's a need to provide more call-specific information that can't be handled by Subject, this seems best to be a new Call-Info purpose. It is then clear that this is of a different nature than the business card information in jCard.

Henning

On Fri, Mar 18, 2022 at 10:16 AM Chris Wendt <chris-ietf@chriswendt.net<mailto:chris-ietf@chriswendt.net>> wrote:
Hi Henning,

This is good feedback, you are correct there really hasn't been a lot of discussion on the callinfo-rcd draft, most of the mind share has been toward the passport-rcd, now that i think that document has mostly stabilized on issues not related to your comments or the specifics of how we do callinfo, it's a good time to engage on that and appreciate you starting the discussion.

I'd be curious to think what others think about using Subject for call-reason vs callinfo.

I think the thought process as you sort of indicate sort of went a bit back in forth about whether jcard would be the extensible object we all put information about caller into, we seemed to have backed off of that for what has emerged to be the initial minimum use of RCD which is name, TN, icon, call reason.  The first three is info about the caller, the call reason is info that is likely specific to the call intent, not information about the caller. So in that sense Subject may make sense because after all that is what it was created for, but also we weren't sure if there would be other categories of information that we may want to extend in call-info. For example, URL to relevant info about the intent of the call, or other call specific info.

Beyond your point, but related and maybe just validation for me, do we want to protect call-reason as part of RCD?  I think we sort of said, yes why not protect/sign it because we view RCD as an extensible set of claims, as long as we make that a claim that is not part of the "rcd" claim that is specifically about the calling party identity, which we did with "crn".

I do also think we need to address when callinfo and other SIP headers/parameters are used to carry info vs in RCD claims.  Should they be mutually exclusive, that you should either do one or the other depending if you want the signature/integrity protection for your use-case?

-Chris

> On Mar 17, 2022, at 11:49 PM, Henning Schulzrinne <hgs@cs.columbia.edu<mailto:hgs@cs.columbia.edu>> wrote:
>
> There was a brief discussion on this in August 2020, but now that the draft is stabilizing, I'd like to comment on the call-reason parameter. I'm not sure I found all the discussions, with only an August 2020 discussion (from Paul Kyzivat and Chris Wendt) popping up. In any event, as drafted, this seems to be exactly duplicating the Subject header. Having two header fields that do pretty much the same thing seems unwise.
>
> There was discussion on structured content, but this doesn't seem possible to add without breaking backwards-compatibility. You really don't want to add JSON to an existing string, or other parameters.
>
> There seems to be no obvious reason why systems that drop Subject would treat call-reason with more care (or deliver it to the UA). Indeed, richer information is likely to make the handling more challenging - the more stuff the UA can embed, the more likely that this will cause security concerns. (You really don't want to include full HTML with JavaScript here...)
>
> It is also a poor addition to the callinfo header, as the RCD will likely be generated by a trusted entity, such as the carrier or the enterprise PBX, while the call-reason has to be generated, on a call-by-call basis, by the UA, either via human input or via the robot generating the (hopefully wanted) calls.
>
> I think there are three reasons that Subject has not seen much use:
>
> (1) For person-to-person phone calls, there seems to be little appetite to add more overhead to making calls. If I want to text ahead ("I'll call you shortly about the vet"), people will likely do that instead. Call-reason or Subject are not substitutes for texting-ahead.
>
> (2) For enterprise-to-consumer calls, this seems like an opportunity for potential abuse and spam.
>
> (3) SIP headers provided by the end system or end user don't seem to survive the paranoia of B2BUAs and various other in-call entities.
>
> All of these would likely apply to call-reason, with the additional issue of who-generates-what added for complexity. If the landscape has changed, i.e., there's a willingness to deliver information UA-to-UA, then this would apply to the Subject header as well.
>
> Henning
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org<mailto:sipcore@ietf.org>
> https://www.ietf.org/mailman/listinfo/sipcore<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsipcore&data=04%7C01%7Cdavid.holmes%40t-mobile.com%7Cbb87c967d7d9432dc42e08da091ab62d%7Cbe0f980bdd994b19bd7bbc71a09b026c%7C0%7C0%7C637832307608208318%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=S1jVvqHFUsdcP%2FtQuLu8OJeyjWfgFte4WaX%2BTePFnJE%3D&reserved=0>