Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-callinfo-spam-00.txt

From: Souma Badombena <[email-masked]>
Date: Sun, 2 Apr 2017 08:38:09 -0700

--------------------
On Further Collaborative implications for communications and telephony
Mobile Applications (3GPP/MMTEL/IMS, RCS/GSMA etc..)

As I'm going over this draft about SIP Call Info headers, I'm led to think
about related implications and applicabilities it has with respect to
telephony applications such a Rich Communications Services where the
concept of Enriched Calling is available and involves such call operations
versatilities and feasabilities as setting the subject or topic of calls in
a pre-call phase feature along with being able to identify call types and
decide whether to respond, defer, put on hold or reject etc... So I am
wondering whether there could be some protocol specification application
reference and examplification related to these SIP calling applications or
if there could be possible a further draft upgrade which could discuss
those specific cases and scenarios.
I'm suspecting that various application developers and service providers
may want to implement this specification and reference it for compliance
and standard alignment. So I will try to follow this up with some specific
examples and cases that we can discuss in details in the light of the
proposed draft.

Thanks,
-- 
Souma Badombena-Wanta

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 3 Apr 2017 01:23:28 +0000

I'm not sure I'm quite following what you had in mind, so please feel free to amplify if I missed the intent of your comment. At the recent IETF SIPCORE meeting, we briefly discussed that there is indeed a need for users to configure call behavior independent of the call, e.g., whether to block certain categories of calls, make this dependent on the time of day, or whether to apply other call treatments such as auto-forwarding to voicemail. (Given that speech-to-text is actually quite good these days, I find that I can often simply glance at the text rendition to see if a call needs follow-up or not.)

However, since this type of setup is likely to be web-based and somewhat specific to the capabilities offered by each service, it's not clear that standards would be helpful here.

That said, I do believe there's a gap that needs to be filled, namely per-call type identification by the called party, included in the "Unwanted" response. I'm considering using a new parameter, using the same call types as for this draft, for the Reason parameter, since Call-Info is a request-only header.

Again, please let me know if I missed the intent of your comment.

Henning

________________________________
From: sipcore <[email-masked]> on behalf of Souma Badombena <[email-masked]>
Sent: Sunday, April 2, 2017 11:38:09 AM
To: [email-masked]
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-callinfo-spam-00.txt

--------------------
On Further Collaborative implications for communications and telephony Mobile Applications (3GPP/MMTEL/IMS, RCS/GSMA etc..)

As I'm going over this draft about SIP Call Info headers, I'm led to think about related implications and applicabilities it has with respect to telephony applications such a Rich Communications Services where the concept of Enriched Calling is available and involves such call operations versatilities and feasabilities as setting the subject or topic of calls in a pre-call phase feature along with being able to identify call types and decide whether to respond, defer, put on hold or reject etc... So I am wondering whether there could be some protocol specification application reference and examplification related to these SIP calling applications or if there could be possible a further draft upgrade which could discuss those specific cases and scenarios.
I'm suspecting that various application developers and service providers may want to implement this specification and reference it for compliance and standard alignment. So I will try to follow this up with some specific examples and cases that we can discuss in details in the light of the proposed draft.

Thanks,
--
Souma Badombena-Wanta