Re: [Last-Call] [stir] Last Call: <draft-ietf-stir-passport-divert-07.txt> (PASSporT Extension for Diverted Calls) to Proposed Standard

["David Frankel" <[e-mail]>]

A few last-minute thoughts:

Typo in 1. Introduction, "There are a number of potential ways for
intermediaries to indicate that such a forwarding OPERATION has taken
place."

Regarding the discussion in the Introduction, there is an alternative
perspective regarding a call initially directed to one number that is then
forwarded to another. The current text implies that this is ONE call (from A
to B and then forwarded to C.) Some would argue that traditional call
forwarding results in the creation of a second, new call, at least in terms
of the billing for both calls. The first call is from A to B and terminates
at B. The new second call, from B to C, is created with a DIVERSION header
containing B's number to show that it initiated the forwarding. The FROM
header (and/or P-ASSERTED-IDENTITY) in the second (B to C) call is
constructed from the original call (with A's number) specifically so that
the call recipient (at the forwarded-to endpoint C) sees the original
calling party (A) as the caller.

The current text says "The SIP Diversion header field [RFC5806], though
historic, is still used for this purpose by some operators today." My
experience is that the Diversion header is used by virtually every public
network operator, not just in the US but globally. Most properly-configured
VoIP PBX's also insert the Diversion header when they forward a call.

A call can trigger multiple forwards, so a call from A to B, which then
forwards to C and then D, would result in three distinct calls across the
network.

The comments above don't call for changes in the technical steps described
in the subsequent text. It might be helpful, though, to clarify how things
actually work, and to perhaps say something like: "When establishing a new
call in response to an incoming original call that the retargeting entity is
forwarding, that entity will copy (unaltered) the original Identity
header(s) contained in the original INVITE into a new INVITE, and will add a
new Identity header with a "div" PASSporT."

Typo in 3. "If the canonical form of the "dest" IDENTIFIER is not changed
during retargeting"

At 4.1, the text says: "The retargeting entity SHOULD act as a verification
service and validate the existing Identity header field value(s) in the
request before proceeding; in some high-volume environments, it may instead
put that burden of validating the chain entirely on the terminating
verification service." The text does not indicate what the different
outcomes would be in the three possible cases (retargeting entity acts as
verification service and the verification is successful; retargeting entry
acts as verification service and verification fails; retargeting entity does
not verify). If the call handling is the same in all these cases, then is
there a reason that the retargeting entity SHOULD act as a verification
service?

At 4.2, verification steps are detailed. It might be worth adding that if
the Diversion header is used for call processing, then the Verification
Service SHOULD insure that the value(s) in the Diversion header(s) match the
div values in the div PASSporT(s). My point here is that most voicemail
systems use the Diversion header to determine what subscriber voicemailbox
is being accessed; that number should be one that is actually in the
verified chain according to the PASSporTs.

This document doesn't discuss attestation level (or origid). I realize those
are SHAKEN extensions and perhaps not relevant in a "generic" document like
this. At some point, though, it will have to be determined how these notions
are propagated in forwarded-call scenarios. Today Diversion and Redirecting
Number are interworked between SIP and ISUP respectively so there will be
some interesting interactions.

David Frankel
ZipDXR LLC
Monte Sereno, CA USA
Tel: 1-800-FRANKEL (1-800-372-6535)
Visit My Robocall Blog at www.legalcallsonly.org