Subject: [sipcore] Fwd: New Version Notification for draft-burger-sipcore-rejected-00.txt

From: Eric Burger <[email-masked]>
Date: Mon, 16 Jul 2018 16:41:41 -0400

As promised, here is the official submission. This version includes a mechanism for interoperability with legacy networks, including the PSTN. It only ~ doubled the length of the draft :0!

As before, please comment on the sipcore list.

See you in Montreal.
- Eric

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-burger-sipcore-rejected-00.txt
> Date: July 16, 2018 at 4:29:53 PM EDT
> To: "Eric W. Burger" <[email-masked]>, "Eric Burger" <[email-masked]>
> 
> 
> A new version of I-D, draft-burger-sipcore-rejected-00.txt
> has been successfully submitted by Eric W. Burger and posted to the
> IETF repository.
> 
> Name:		draft-burger-sipcore-rejected
> Revision:	00
> Title:		A Session Initiation Protocol (SIP) Response Code for Rejected Calls
> Document date:	2018-07-16
> Group:		Individual Submission
> Pages:		15
> URL:            https://www.ietf.org/internet-drafts/draft-burger-sipcore-rejected-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-burger-sipcore-rejected/
> Htmlized:       https://tools.ietf.org/html/draft-burger-sipcore-rejected-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-burger-sipcore-rejected
> 
> 
> Abstract:
>   This document defines the 608 (Rejected) SIP response code.  This
>   response code enables calling parties to learn their call was
>   rejected by an intermediary and will not be answered.  As a 6xx code,
>   the caller will be aware that future attempts to contact the same UAS
>   will be likely to fail.  The present use case driving the need for
>   the 608 response code is when the intermediary is an analytics
>   engine.  In other words, the rejection is by a machine or other
>   process, as opposed to a human at the target UAS indicating the call
>   was not wanted.  This document also defines the use of the Call-Info
>   header in 608 responses to enable rejected callers to contact
>   entities that blocked their calls in error.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 19 Jul 2018 20:39:11 +0000

Hi Eric,

Just a few comments:

i-
1.  Introduction

In the call handling ecosystem, users can explicitly reject a call or

   later mark a call is being unwanted by issuing a 607 SIP response

   code (Unwanted) [RFC8197<https://tools.ietf.org/html/rfc8197>].  Figure 1 shows the operation of the 607

   SIP response code.  The UAS indicates the call was unwanted.  As

   RFC8197<https://tools.ietf.org/html/rfc8197> explains, not only does the called party desire to reject

   that call, they wish to let their proxy know they do not ever want to

   get calls from that source.

I think “do not ever want to get calls from the source” is not accurate.

“RFC8719   4.  Behavior of SIP Entities” doesn’t have any text supporting this strong statement AFAICS.

ii-
3.2.  UAC Operation

  A UAC conforming to this specification MUST include the sip.608

   feature capability tag in the INVITE request.

I assume this will be done based on RFC3840 and not on RFC6809. If so, this needs to be clarified and relevant IANA registry needs to be updated.

iii-
7.  Acknowledgements

Tolga’s suggestion to provide a mechanism for legacy

   interoperability served to expand the draft by 50%.

I never felt this honored in my entire life ;-)

Thanks,
Tolga

Thanks,
Tolga

From: sipcore <[email-masked]> On Behalf Of Eric Burger
Sent: Monday, July 16, 2018 4:42 PM
To: [email-masked]; [email-masked]
Subject: [sipcore] Fwd: New Version Notification for draft-burger-sipcore-rejected-00.txt

________________________________
NOTICE: This email was received from an EXTERNAL sender
________________________________

_______________________________________________
sipcore mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sipcore

---

From: Eric Burger <[email-masked]>
Date: Fri, 20 Jul 2018 12:45:03 -0400

inline:

> From: "Asveren, Tolga" <[email-masked] <mailto:[email-masked]>>
> Subject: RE: [sipcore] Fwd: New Version Notification for draft-burger-sipcore-rejected-00.txt
> Date: July 19, 2018 at 4:39:11 PM EDT
> To: Eric Burger <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> 
> Hi Eric,
> 
> Just a few comments:
> 
> i-
> 1.  Introduction
> 
>    code (Unwanted) [RFC8197 <https://tools.ietf.org/html/rfc8197>].  Figure 1 shows the operation of the 607
>    RFC8197 <https://tools.ietf.org/html/rfc8197> explains, not only does the called party desire to reject

Good point. How about, “As RFC8197 explains, not only does the called party desire to reject that call, they may wish to let their proxy know they might consider future calls from that source unwanted.”

> I assume this will be done based on RFC3840 and not on RFC6809. If so, this needs to be clarified and relevant IANA registry needs to be updated.

Using RFC3840 means proxies might be hacking the Contact header.  That just does not feel right.  Conversely, using RFC6809 means a proxy can use its power to insert (and remove) Feature-Caps headers as it sees fit.

What do others think about RFC3840 vs. RFC6809 for signaling this capability?

---

From: "Asveren, Tolga" <[email-masked]>
Date: Fri, 20 Jul 2018 17:28:57 +0000

What I meant about use of RFC3840 was limited to the end-device UAC. Network elements should use RFC6809, no disputes there (actually maybe not black/white for B2BUAs)

“As RFC8197 explains, not only does the called party desire to reject that call, they may wish to let their proxy know they might consider future calls from that source unwanted.”
Looks good.

Thanks,
Tolga

inline:

> From: "Asveren, Tolga" <mailto:[email-masked] <mailto:[email-masked]>>
> To: Eric Burger <mailto:[email-masked] <mailto:[email-masked]>>, mailto:&quot;[email-masked] <mailto:[email-masked]>" <mailto:[email-masked] <mailto:[email-masked]>>
> 
> Hi Eric,
> 
> Just a few comments:
> 
> i-
> 1.  Introduction
> 
>    code (Unwanted) [RFC8197 <https://tools.ietf.org/html/rfc8197%3E%5d.>].  Figure 1 shows the operation of the 607
>    RFC8197 <https://tools.ietf.org/html/rfc8197%3E explains, not only does the called party desire to reject