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

From: Paul Kyzivat <[email-masked]>
Date: Sun, 2 Aug 2020 14:34:13 -0400

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://urldefense.com/v3/__https://tools.ietf.org/html/draft-wendt-sipcore-callinfo-rcd-03__;!!N14HnBHF!qN-QsYPq0MvWk7reTKb984Mry91INiEDfIoc4rQhKA_mMt9ysIG4-Yz2itA0$
> 
> 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.

	Thanks,
	Paul

	Thanks,
	Paul

---

From: Chris Wendt <[email-masked]>
Date: Tue, 4 Aug 2020 09:58:50 -0400

> On Aug 2, 2020, at 2:34 PM, Paul Kyzivat <[email-masked]> wrote:
> 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Brian Rosen <[email-masked]>
Date: Tue, 4 Aug 2020 10:21:51 -0400

I prefer the JCard fields.  Everything together, in a format other systems can reasonably deal with.

Brian

> On Aug 4, 2020, at 9:58 AM, Chris Wendt <[email-masked]> wrote:
> 
>> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/sipcore <https://www.ietf.org/mailman/listinfo/sipcore>

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 5 Aug 2020 16:01:14 +0000

Thanks for taking a glance Paul. Just to the matter of call reason and Subject:

Broadly I imagine that call reason might eventually call for structured data to handle cases like internationalization (display the Spanish version if the UE indicates a native Spanish speaker) or broad categories of subject types ("appointment/reservation confirmation" or "IVR callback") that might be handled programmatically in some way. I guess I look at the Subject header as pretty syntactically poor, and moreover something that legacy implementations might expect to treat already in some unhelpful way (most likely by stripping/ignoring it). But I'm interested to hear what people think about this one.

Jon Peterson
Neustar, Inc.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 5 Aug 2020 12:16:37 -0400

> Broadly I imagine that call reason might eventually call for structured data to handle cases like internationalization (display the Spanish version if the UE indicates a native Spanish speaker) or…

This all makes sense to me. It just needs to make it into the document.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 5 Aug 2020 12:23:32 -0400

I had more thoughts after hitting send. So elaborating:

While it makes sense to me that you might want a syntactically richer 
call reason than what fits in the Subject header, as defined it isn't 
any richer - it is still just a string.

	Thanks,
	Paul

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Tue, 4 Aug 2020 14:16:50 +0000

+1

-----Original Message-----
From: sipcore <[email-masked]> On Behalf Of Chris Wendt
Sent: Tuesday, August 4, 2020 8:59 AM
To: Paul Kyzivat <[email-masked]>
Cc: [email-masked]
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.

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

-Chris

> 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
[email-masked]
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