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

[Henning Schulzrinne <[e-mail]>]

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