Re: [sipcore] draft on rich call data and Call-Info

["Gorman, Pierce A [CTO]" <[e-mail]>]

+1

-----Original Message-----
From: sipcore <[e-mail]> On Behalf Of Chris Wendt
Sent: Tuesday, August 4, 2020 8:59 AM
To: Paul Kyzivat <[e-mail]>
Cc: [e-mail]
Subject: Re: [sipcore] draft on rich call data and Call-Info

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.


> On Aug 2, 2020, at 2:34 PM, Paul Kyzivat <[e-mail]> wrote:
>
> On 7/31/20 1:36 PM, Peterson, Jon wrote:
>> Hello,
>> Chris Wendt and have a draft that has split off from our work toward delivering rich call data (RCD) in the STIR WG. This is for carrying data elements like a caller name, a jCard, call reason, and potentially related elements that will be rendered to the called party to help them decide if they should pick up the phone. We ultimately decided that, instead of doing a one-off for conveying RCD within the PASSporT object, we should instead focus on how that information is best relayed in baseline SIP, and keep the STIR part of the problem confined to signing over those fields as they appear in SIP requests.
>> So this draft is the core SIP part:
>> https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-wendt-sipcore-callinfo-rcd-03__%3B!!N14HnBHF!qN-QsYPq0MvWk7reTKb984Mry91INiEDfIoc4rQhKA_mMt9ysIG4-Yz2itA0%24&amp;data=02%7C01%7Cpierce.gorman%40sprint.com%7C2de13ee067c74874169908d8387e8a99%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C0%7C637321463448792201&amp;sdata=mp9bXhj0WqWo6jD1vpEYVbcSnFbNNDyiaG1879mMQYg%3D&amp;reserved=0
>> We'd be interested in the thoughts of the SIPCORE WG about the fundamental approach here, and ultimately if there's interest in adopting this as a WG item here.
>
> This seems to be a good start.
>
> I question the decision to add the "jCard" purpose. The existing "card" purpose is not bound to any particular representation. It makes perfect sense to use a purpose of "card" with content type of application/vcard+json.
>
> Similarly, I think it need do discuss the need for the "call-reason" parameter. As the draft notes, the contents of the Subject header could be used for this purpose. I would like to some some further in investigation of why it is unsuitable before giving up on it.
>
> There is a lot of overlap between jCard properties mentioned in section 6 and other sip header fields that are capable of carrying similar information. At the least I think there should be some discussion of how these do/don't interact and how a caller should choose which to use.

Valid comments, i guess one perspective is that we may want to have a more specific ‘rcd’ approach vs conflicts with existing usage of other headers/parameters and avoiding the potential confusion of what is being used for legacy purposes vs what should generally be signed.  But, i guess we sort of backed into this, first building ‘rcd’ PASSporT then defining Call-Info.

I’d hate to have a complex map of when you can and when you can’t use jCard fields, i see that as potentially a bit messy, but curious what others think.

-Chris


>
>       Thanks,
>       Paul
>
>       Thanks,
>       Paul
>
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsipcore&amp;data=02%7C01%7Cpierce.gorman%40sprint.com%7C2de13ee067c74874169908d8387e8a99%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C0%7C637321463448792201&amp;sdata=FRmhQaUpOnjuzTQ5xc1YmQG73j3gZCGn%2BVJTybkfoPg%3D&amp;reserved=0

_______________________________________________
sipcore mailing list
[e-mail]
https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsipcore&amp;data=02%7C01%7Cpierce.gorman%40sprint.com%7C2de13ee067c74874169908d8387e8a99%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C0%7C637321463448792201&amp;sdata=FRmhQaUpOnjuzTQ5xc1YmQG73j3gZCGn%2BVJTybkfoPg%3D&amp;reserved=0