What's the consensus on signing calls that don't leave your own network? Are operators bothering with this, or generally only computing & attaching PASSporTs to calls that terminate off-net? Thanks, -- Nathan
The rough consensus I've observed is that you only compute the PASSporT as the call is leaving the network. This is a helpful article about one form of intra-network tagging. Verizon is a customer of Metaswitch, and hints at SIPNOC presentations suggest that they're doing things the way it's described here with Attestation-Info and Origination-ID. https://www.metaswitch.com/blog/stir-shaken-how-do-i-tag-calls-in-my-network To hear a bit more recent news, you can watch the briefings here: https://www.sipforum.org/news-events/sipnoc-2022-overview/schedule/ This presentation <https://register.gotowebinar.com/register/7021235385788740876> would be a good one to start with. Mark R Lindsey | SMTS | +1-229-316-0013 | mark at ecg.co Schedule a meeting <https://ecg.co/lindsey/schedule>
On Jun 27, 2022, at 06:51, Nathan Anderson <nathana at fsr.com> wrote:
What's the consensus on signing calls that don't leave your own network? Are operators bothering with this, or generally only computing & attaching PASSporTs to calls that terminate off-net?
Thanks,
-- Nathan _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Will your customers be comfortable answering calls that are not attested as being valid? Not against any standard to not attest. Calls may not get answered. Sent from my iPhone
On Jun 27, 2022, at 10:31 AM, Mark Lindsey <lindsey at e-c-group.com> wrote:
? The rough consensus I've observed is that you only compute the PASSporT as the call is leaving the network. This is a helpful article about one form of intra-network tagging. Verizon is a customer of Metaswitch, and hints at SIPNOC presentations suggest that they're doing things the way it's described here with Attestation-Info and Origination-ID.
https://www.metaswitch.com/blog/stir-shaken-how-do-i-tag-calls-in-my-network
To hear a bit more recent news, you can watch the briefings here: https://www.sipforum.org/news-events/sipnoc-2022-overview/schedule/
This presentation would be a good one to start with.
Mark R Lindsey | SMTS | +1-229-316-0013 | mark at ecg.co Schedule a meeting
On Jun 27, 2022, at 06:51, Nathan Anderson <nathana at fsr.com> wrote:
What's the consensus on signing calls that don't leave your own network? Are operators bothering with this, or generally only computing & attaching PASSporTs to calls that terminate off-net?
Thanks,
-- Nathan _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
I suppose it?s a naive question, but why would equipment necessarily mark an on-net call as un-attested to the end-customer? Customers don?t see PASSportTs, they just get a ?verified? attribute or whatnot, as I understand it. If PASSporTs are an intra-industrial concept, why can?t the ?verified? attribute be set on the outgoing leg anyway, i.e. why can?t the equipment be configured to effectively attest all on-net calls? Or are we talking about customers who do get the full attestation headers and interrogate them? ? Alex -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Alex Balashov wrote:
Or are we talking about customers who do get the full attestation headers and interrogate them?
Precisely this. If we ever get such a customer, and if at that time we've finally arrived at a world where it's expected that 100% of inbound calls [at least at provider's edge] are attested, and thus this customer's expectations have been calibrated to expect the same of calls that they receive via us (and they're planning on dropping any inbound calls without a valid PASSporT) even though they are paying us for SIP trunking and aren't a "peer" of ours, if a different customer of ours calls them, are we supposed to generate & transmit an Identity header for that INVITE? It seems weird to do so, but I could potentially see such a scenario playing out, eventually. -- Nathan
It's important to note that if there is any call forwarding involved, you'd want to start off with a properly signed call to support the additional div passport(s). Calvin Ellison Systems Architect calvin.ellison at voxox.com +1 (213) 285-0555 <http://voxox.com> <https://www.facebook.com/VOXOX/> <https://www.instagram.com/voxoxofficial/> <https://www.linkedin.com/company/3573541/admin/> <https://twitter.com/Voxox> The information contained herein is confidential and privileged information or work product intended only for the individual or entity to whom it is addressed. Any unauthorized use, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify me immediately. On Mon, Jun 27, 2022 at 3:01 PM Nathan Anderson <nathana at fsr.com> wrote:
Alex Balashov wrote:
Or are we talking about customers who do get the full attestation headers and interrogate them?
Precisely this. If we ever get such a customer, and if at that time we've finally arrived at a world where it's expected that 100% of inbound calls [at least at provider's edge] are attested, and thus this customer's expectations have been calibrated to expect the same of calls that they receive via us (and they're planning on dropping any inbound calls without a valid PASSporT) even though they are paying us for SIP trunking and aren't a "peer" of ours, if a different customer of ours calls them, are we supposed to generate & transmit an Identity header for that INVITE? It seems weird to do so, but I could potentially see such a scenario playing out, eventually.
-- Nathan _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
You may also need to sign your intra-net/inter-customer calls to support your customers' Delegate Certificates and future Rich Call Data. Calvin Ellison Systems Architect calvin.ellison at voxox.com +1 (213) 285-0555 <http://voxox.com> <https://www.facebook.com/VOXOX/> <https://www.instagram.com/voxoxofficial/> <https://www.linkedin.com/company/3573541/admin/> <https://twitter.com/Voxox> The information contained herein is confidential and privileged information or work product intended only for the individual or entity to whom it is addressed. Any unauthorized use, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify me immediately. On Mon, Jun 27, 2022 at 3:01 PM Nathan Anderson <nathana at fsr.com> wrote:
Alex Balashov wrote:
Or are we talking about customers who do get the full attestation headers and interrogate them?
Precisely this. If we ever get such a customer, and if at that time we've finally arrived at a world where it's expected that 100% of inbound calls [at least at provider's edge] are attested, and thus this customer's expectations have been calibrated to expect the same of calls that they receive via us (and they're planning on dropping any inbound calls without a valid PASSporT) even though they are paying us for SIP trunking and aren't a "peer" of ours, if a different customer of ours calls them, are we supposed to generate & transmit an Identity header for that INVITE? It seems weird to do so, but I could potentially see such a scenario playing out, eventually.
-- Nathan _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Yes, you also need the ID headers in order to pass RCD. Most customers will (hopefully) be expecting to see this on calls someday. ~Glen
On Jun 27, 2022, at 15:01, Nathan Anderson <nathana at fsr.com> wrote:
?Alex Balashov wrote:
Or are we talking about customers who do get the full attestation headers and interrogate them?
Precisely this. If we ever get such a customer, and if at that time we've finally arrived at a world where it's expected that 100% of inbound calls [at least at provider's edge] are attested, and thus this customer's expectations have been calibrated to expect the same of calls that they receive via us (and they're planning on dropping any inbound calls without a valid PASSporT) even though they are paying us for SIP trunking and aren't a "peer" of ours, if a different customer of ours calls them, are we supposed to generate & transmit an Identity header for that INVITE? It seems weird to do so, but I could potentially see such a scenario playing out, eventually.
-- Nathan _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
That?s a good point. But I wonder how close RCD is to light of day.
On Jun 28, 2022, at 12:36 AM, Glen Gerhard <glen at cognexus.net> wrote:
Yes, you also need the ID headers in order to pass RCD. Most customers will (hopefully) be expecting to see this on calls someday.
~Glen
On Jun 27, 2022, at 15:01, Nathan Anderson <nathana at fsr.com> wrote:
?Alex Balashov wrote:
Or are we talking about customers who do get the full attestation headers and interrogate them?
Precisely this. If we ever get such a customer, and if at that time we've finally arrived at a world where it's expected that 100% of inbound calls [at least at provider's edge] are attested, and thus this customer's expectations have been calibrated to expect the same of calls that they receive via us (and they're planning on dropping any inbound calls without a valid PASSporT) even though they are paying us for SIP trunking and aren't a "peer" of ours, if a different customer of ours calls them, are we supposed to generate & transmit an Identity header for that INVITE? It seems weird to do so, but I could potentially see such a scenario playing out, eventually.
-- Nathan _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
-- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
participants (6)
-
abalashov＠evaristesys.com -
calvin.ellison＠voxox.com -
dfrigen＠wabash.net -
glen＠cognexus.net -
lindsey＠e-c-group.com -
nathana＠fsr.com