Last Call Review of draft-ietf-sipcore-rejected-08

Request Review of draft-ietf-sipcore-rejected
Requested rev. no specific revision (document currently at 09)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2019-06-04
Requested 2019-05-21
Authors Eric Burger, Bhavik Nagda
Draft last updated 2019-06-03
Completed reviews Genart Last Call review of -08 by Ines Robles (diff)
Secdir Last Call review of -08 by Nancy Cam-Winget (diff)
Assignment Reviewer Ines Robles 
State Completed
Review review-ietf-sipcore-rejected-08-genart-lc-robles-2019-06-03
Posted at
Reviewed rev. 08 (document currently at 09)
Review result Ready
Review completed: 2019-06-03


I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at


Document: draft-ietf-sipcore-rejected-08
Reviewer: Ines Robles
Review Date: 2019-06-03
IETF LC End Date: 2019-06-04
IESG Telechat date: Not scheduled for a telechat


I believe the draft is technically good. This document is well written.

The document defines the 608 (Rejected) SIP response code, that  enables calling parties to learn that an intermediary rejected their call attempt.  

I have some minor questions.

Major issues: none

Minor issues: none

Nits/editorial comments:

Section 1- I think it would be nice to expand SIP and add a reference to RFC3261 the first time that SIP is mentioned in the Introduction.


1- Section 1. "...a user (human)..."

  A user could be as well a smart device, right?. For example, in a smart home scenario, we have Alexa rejecting a call from a supermarket. The call rejection is ordered by a human or ordered by another device (e.g. a fridge with temporal calling-management functions that can send commands to Alexa to accept, reject calls from supermarket ). In the latter case the user is not a human, but a smart device.  In this case, Alexa would be the UAS?

  2- In Figure 2 is not clear to me if the INVITE command goes as well to the "call analytics engine" entity, since the arrow goes directly to the UAS. 
  Should this image indicate arrows to the "call analytics engine" entity, to be aligned with figure 1?

  3- Figure 5: 

+---+         +-----+          +---+         +-----+         +-----+           |Called|
|UAC+--->+Proxy+--->+SBC+--->+Proxy+--->+Proxy+--->+Party |
+---+          +-----+           +---+        +-----+         +-----+          |Proxy |

  3.1- The arrows of the UAC to the Called Party Proxy are unidirectional.
  Should be bidirectional? Since there are messages from the Called Party Proxy entity to the SBC, and then to the UAC.

  3.2- Should the "Proxy" entities be identified for example with Proxy A, Proxy B and Proxy C, to indicate that they are different Proxy entities?

  3.3- Should be added in the figure the flow of messages that the "Proxy" entities goes through, or at least mentioned when explaining figure 5.

  Thank you for this draft,