I tried sending this in early December and it disappeared. Given that there are still some comments floating around on this draft, I'm trying again. 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 -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
