The only way to have a chain of trust is with the original shaken passport and each forwarding hop adding a div passport. A div passport alone is meaningless without a shaken passport, and a forwarded call with only the original shaken passport would fail verification because the dst claim no longer matches.
On Mon, Jan 12, 2026, 7:26 AM Kili Land <[email protected]> wrote: > Question – if you get a call in from your client’s PBX and it’s a forward, > do you ONLY supply the DIV passport? I mean, it’s the only thing you’d know > anything about as the originating number is from some offnet caller, so you > wouldn’t have a standard passport. But, all the examples I’ve seen show > both a standard passport and a DIV passport. How are you supposed to do > both in a situation where the client’s forward is handled by their PBX? > You’re not going to have the original passport to add on to. > > I am arguing that the DIV passport is what needs to be applied because > that’s all we know anything about...but, I’m getting pushback saying that > they are just going to do the standard passport – which makes no sense to > me for some rather obvious reasons, I would think. > > > > Thanks. > > Kili > > > > *From:* Calvin E. via VoiceOps <[email protected]> > *Sent:* Thursday, January 8, 2026 10:25 AM > *To:* Voiceops.org <[email protected]> > *Subject:* [VoiceOps] Re: Services that rely on Caller ID spoofing? > > > > *NOTE:* This is an external message. Please use caution when replying, > opening attachments or clicking on any links in this e-mail. > > > > *WARNING:* Replies to this message will go to > [email protected]. If you believe this is malicious or are > unsure if this is correct, please report it using the *Report Phish* > button and our analysts will investigate it. > > I can second this from a company that both receives forwarded calls and > forwards calls. It is perfectly normal and standard to forward the caller > ID that you received. This is exactly what the Diversion header and div > passport were designed to do. > > > > Diversion has been around forever as the SIP indication that a call was > forwarded. The major wireless carriers are now also using div passports now > when they forward calls. I know this because I receive forwarded calls from > them all day, every day. You should be completely in the clear, assuming > you signal correctly. Your platform will need to preserve the original > shaken passport and P-Asserted-Identity when appending your own div > passport and Diversion header. > > > > Some platforms may not be updated to the current div passport standard, so > you'll need to confirm that first. > > > > On Wed, Jan 7, 2026, 10:02 AM Kidd Filby via VoiceOps < > [email protected]> wrote: > > If memory serves me correctly, when I was testing all the variations of *Call > Forwarding* during FoA testing of *Caller ID* in the 90's, The only CF > feature that actually changed the calling number received by the > terminating party was RCF ( Remote Call Forwarding ). This was done > primarily for call vectoring. However, as I have mentioned before, there > are legit reasons for doing so. For instance, Shelters, who have a PRI, > will normally invoke Station ID Restriction in their PBX. This is done for > the callers' protection. > > > > JM2C from an old guy. > > > > On Tue, Jan 6, 2026 at 8:25 PM David Frankel via VoiceOps < > [email protected]> wrote: > > Aaron, > > > > If I understand you correctly, you are dealing with a fairly conventional > call-forwarding situation, and that is addressed in the SHAKEN standards. > It does not have anything to do with an FCC “crackdown.” > > > > The standards (ATIS 1000085) define something called a DIV passport – this > is an additional signature (IDENTITY header) that is generated by the > service provider responsible for forward (DIVerting) the call. It generally > is used in conjunction with the SIP DIVERSION header. > > > > Sansay has a nice write-up about it here: > > https://support.sansay.com/t/p8hctyw/diversion-div-passport > > > > I do see mention of the DIV passport on this Twilio page: > > https://www.twilio.com/docs/voice/trusted-calling-with-shakenstir > > > > Whether your systems (and those of the provider receiving the forwarded > call) support DIV ppt is another matter. > > > > Forwarding is (still) perfectly legal and you don’t need to “spoof” > anything when following the standards. > > > > David > > > > *From:* Aaron C. de Bruyn via VoiceOps <[email protected]> > *Sent:* Tuesday, January 6, 2026 3:54 PM > *To:* Mary Lou Carey <[email protected]> > *Cc:* Pinchas Neiman <[email protected]>; Mark R Lindsey, ECG < > [email protected]>; [email protected] > *Subject:* [VoiceOps] Re: Services that rely on Caller ID spoofing? > > > > Unfortunately in this situation the 3rd-party company expects us to > receive calls from patients and instead of sending them to voicemail > after-hours, we forward the call on to them. > > That would require us to get permission to "spoof" numbers from tens of > thousands of patients. > > > > ...or...if the 3rd-party company wasn't completely incompetent, have us > set up a SIP or IAX trunk directly to them that does allow us to pass the > call to them without going over the PSTN. > > > > -A > > > > > > On Tue, Jan 6, 2026 at 2:50 PM Mary Lou Carey <[email protected]> > wrote: > > There are certain circumstances where caller ID spoofing is allowed. For > example, in the situation where a doctor may be calling a patient after > hours. They can change the doctor's cell phone number to be the phone > number of the medical office the doctor works for. What people are not > allowed to do is to spoof a number that they do not have permission to use. > > What carrier "owns" the number is highly debatable these days because > there's multiple players. > > 1. The ILEC / CLEC / IPES / Wireless carrier that the NPA-NXX-X was > assigned to. > > 2. The carrier who manages the TN under their LRN. (In ported TN > situations) > > 3. The reseller who pays an upstream carrier for the DID service. (The DID > may have been resold multiple times so the OCN associated with the LRN does > not necessarily match the OCN of the carrier that manages the assignment of > TNs. > > Whoever has the direct connection with the end user customer has the > responsibility of ensuring that the TN is not spoofed in situations that > are illegal. > > > > MARY LOU CAREY > BackUP Telecom Consulting > Office: 615-791-9969 > Cell: 615-796-1111 > > > > On 2025-11-24 12:00 PM, Pinchas Neiman via VoiceOps wrote: > > I think it's pretty clear that we are victims of crediting the holder > instead of the owner, the definition of number ownership, the "Deed", must > be decoupled from holding it. This should not be a matter of provider to > provider verification, but a global record that entity X may use that phone > number for caller ID. > > > > Side note, hackers are hackers because they view themselves as experienced > troublemakers, the standard cowboy will not give up his career just because > a tech person earns more than him, although some smarter do, and some > hackers are getting smarter in prison. > > > > > > > > > > On Mon, Nov 24, 2025 at 3:30 PM Mary Lou Carey via VoiceOps < > [email protected]> wrote: > > I think the intent to block spoofing is to prevent people from using > telephone numbers they do not own. I once had a client that had the FBI > show up on his doorstep because they said they traced a call back to his > company. The number they were interested in was an unallocated TN in his > PBX. Apparently someone had gotten ahold of that TN and was using it for > nefarious purposes. > > Hackers are creative, I'll give them that. However, I'll never understand > why they can't use their skills to make money legally. Why does one need to > make mountains of money illegally when they can make enough to support > themselves legally? Many create such a boatload of damage within a small > amount of time that their poor innocent victims are detrimentally impacted > by. I guess they don't care who they hurt. One can only hope Karma comes > calling for them one day and reimburses them ten fold. > > MARY LOU CAREY > BackUP Telecom Consulting > Office: 615-791-9969 > Cell: 615-796-1111 > > > > On 2025-11-22 08:11 PM, Mark R Lindsey, ECG via VoiceOps wrote: > > "Spoofing" is the standard term, even used in FCC docs, to mean that a > person is placing a call from telephone number X using a voice service S, > where calls placed from the PSTN to X don't always traverse service S. > > > > Of course this happens in conventional SIP trunking and wholesale > interconnect *all the time. *It's so prevalent and normal that it's hard > to even wrap your telecom head around what the FCC and the US congress even > means. Why would you assume S is a symmetrical service for both placing and > receiving calls? Does someone really think UPS or Bank Of America or even > then local Memorial Hospital are seriously placing calls from exactly one > place, or using a different "phone line" for each outbound call? > > > > And they do understand that it's extremely common. Read some discussion in > the latest FNRPM from last month — > > https://docs.fcc.gov/public/attachments/FCC-25-76A1.pdf > > Attending conferences in this space and listening to FCC staffers, there > is actually no push that I perceive to eliminate spoofing. But, there IS a > push to eliminate the blind trust that anybody has the right to call from a > telephone number, simply because they use it to populate the From header. > In the latest suggestions from the FCC, what we might see are additional > steps of vetting to determine you do have the right to place calls from a > telephone number and the proper name that should be provided on that > number. > > > > As of today, the "Know Your Customer" policy and practices of legitimate > service providers will ensure the SP takes steps to confirm the right to > place calls from the telephone numbers they use as the calling part number > for outbound calls. > > > > In your example, Twilio was screening your calling party numbers. They > probably have a list of telephone numbers from which you can call. I'm > almost certain they have a process by which you can provide evidence you > have the right to call from those numbers, and they'll update the screen > list. > > > Mark R Lindsey > Member of Technical Staff / VP > +1-229-316-0013 > https://info.ecg.co/lindsey > > > > > > On Wed, Nov 19, 2025 at 11:13 Aaron C. de Bruyn via VoiceOps < > [email protected]> wrote: > > I'm not entirely up on the whole FCC Caller ID Spoofing crackdown that's > going on, but I just ran into a 3rd party service for medical offices that > expects us to spoof Caller ID. > > > > The service works like this: > > * I grab my cell phone (123-456-7890) and call my doctor/dentist/medical > office > > * It's after hours and they are busy with other calls > > * Their phone system turns around and forwards my call to a 3rd-party > number (say 111-222-3333) emitting my Caller ID info ("Aaron" <1234567890>) > > * They see a call come in on 111-222-3333 and know it's for "Dr. Bob's > Office", so their system accesses his patient database and looks for my > patient record with the phone number 123-456-7890 and someone answers the > call saying "Thanks for calling Dr. Bob's office". > > > > My understanding is the ability to spoof Caller ID info across the PSTN is > going away. > > > > I tested, and I certainly can't do it with a Twilio SIP trunk. > > > > The main reason I'm curious is I have a customer that has their own phone > system that I help them manage (FreePBX linked to Twilio). They just > purchased an office that uses a 3rd-party phone provider (Weave) along with > this 3rd-party answering service, and they are somewhat upset that I can't > make it work with their existing phone system. The third-party answering > service doesn't have any way of interconnecting other than spoofing Caller > ID over the PSTN to a random number they assigned to the medical office. > > > > Are services like this going the way of the dodo? Are they having to set > up private SIP trunks between clients to get this functionality? Do some > VoIP providers allow you to spoof Caller ID for this purpose under some > sort of agreement? > > > > Thanks, > > > > -A > > _______________________________________________ > VoiceOps mailing list -- [email protected] > https://lists.voiceops.org/postorius/lists/voiceops.voiceops.org/ > To unsubscribe send an email to [email protected] > > > > _______________________________________________ > VoiceOps mailing list -- [email protected] > https://lists.voiceops.org/postorius/lists/voiceops.voiceops.org/ > To unsubscribe send an email to [email protected] > > _______________________________________________ > VoiceOps mailing list -- [email protected] > https://lists.voiceops.org/postorius/lists/voiceops.voiceops.org/ > To unsubscribe send an email to [email protected] > > > > > > -- > > *Pinchas S. Neiman* > > Software Engineer At ESEQ Technology Corp. > > Providing you reliable software solutions for any matter. > > 845.213.1229 #2 > > > > _______________________________________________ > VoiceOps mailing list -- [email protected] > https://lists.voiceops.org/postorius/lists/voiceops.voiceops.org/ > To unsubscribe send an email to [email protected] > > _______________________________________________ > VoiceOps mailing list -- [email protected] > https://lists.voiceops.org/postorius/lists/voiceops.voiceops.org/ > To unsubscribe send an email to [email protected] > > > > -- > > Kidd Filby > 661.557.5640 (C) > http://www.linkedin.com/in/kiddfilby > > > > > > _______________________________________________ > VoiceOps mailing list -- [email protected] > https://lists.voiceops.org/postorius/lists/voiceops.voiceops.org/ > To unsubscribe send an email to [email protected] > > > *NOTICE: This e-mail is only intended for the person(s) to whom it is > addressed and may contain confidential information. Unless stated to the > contrary, any opinions or comments are personal to the writer and do not > represent the official view of GTT Communications Inc or any of its > affiliates. If you have received this e-mail in error, please notify us > immediately by reply e-mail and then delete this message from your system. > Please do not copy it or use it for any purposes, or disclose its contents > to any other person. All quotes, offers, proposals and any other > information in the body of this email is subject to, and limited by, the > terms and conditions, signed service agreement and/or statement of work* >
_______________________________________________ VoiceOps mailing list -- [email protected] https://lists.voiceops.org/postorius/lists/voiceops.voiceops.org/ To unsubscribe send an email to [email protected]
