Re: [VoiceOps] 8YY Traffic

[Paul Timmins]

How would you go about determining if a toll free number is intralata or not?



From: VoiceOps  on behalf of Mary Lou Carey 

Sent: Thursday, July 1, 2021 5:31 PM
To: Mike Hammett
Cc: voiceops
Subject: Re: [VoiceOps] 8YY Traffic

You should be able to route 8YY traffic over both but only IntraLATA 8YY
traffic over the Local IntraLATA trunk group.

MARY LOU CAREY
BackUP Telecom Consulting
Office: 615-791-9969
Cell: 615-796-

On 2021-07-01 10:20 AM, Mike Hammett wrote:
> Is there any reason I can't throw all 8YY traffic at my IXC tandem?
>
> In looking in my Metaswitch config, it appears that only 8YY traffic
> destined for my LATA (which doesn't really make any sense) goes to the
> tandem. Everything else goes out to a domestic termination provider.

___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] 8YY Traffic

[Mary Lou Carey]

You should be able to route 8YY traffic over both but only IntraLATA 8YY 
traffic over the Local IntraLATA trunk group.


MARY LOU CAREY
BackUP Telecom Consulting
Office: 615-791-9969
Cell: 615-796-

On 2021-07-01 10:20 AM, Mike Hammett wrote:

Is there any reason I can't throw all 8YY traffic at my IXC tandem?

In looking in my Metaswitch config, it appears that only 8YY traffic
destined for my LATA (which doesn't really make any sense) goes to the
tandem. Everything else goes out to a domestic termination provider.

-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

Midwest Internet Exchange
http://www.midwest-ix.com
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] question about stir/shaken - iat and DATE header

[John S. Robinson]

Date header has been part of RFC-3261 SIP 
 for 19 years now, 
but was not used all that much. IAT and Date are both part of the specs 
and more recent RFC's that define stir-shaken.   So the seldom-used but 
long time defined Date: header is now required.    Furthermore, IAT is 
part of the formal JSON in the Identity header and must be present, or 
the claims are not valid.


Normally, IAT would restate the Date with Unix Epoch date.   IAT is 
signed, but the Date header is not signed.


When a call is received and Verified, the the plain-text signed JSON is 
validated.   If verified IAT is stale, the call is rejected.   True, 
someone could mess with Date header along the route or SIP From header 
or PAI.   And for that matter, someone could mess with the JSON 
attributes that are signed.   But then the verification would fail, and 
the call should not be delivered.   That's part of the beauty of the 
system.


Best regards,

   John


On 7/1/2021 12:29, Joseph Jackson wrote:


I’ve heard that TNSi also counts on the date header being present.

So far we don’t see a lot of people passing tokens with the date header.

*From:*VoiceOps [mailto:voiceops-boun...@voiceops.org] *On Behalf Of 
*Matthew Yaklin

*Sent:* Thursday, July 01, 2021 12:25 PM
*To:* voiceops@voiceops.org
*Subject:* [VoiceOps] question about stir/shaken - iat and DATE header

All,

Pretty simple question here. When you do a verify request are you 
filling in the iat with your sbc’s current date/time or using the DATE 
information from the invite?


With Neustar the iat is currently optional. IQNT is basically removing 
the DATE header in a test we are doing by sending them a call and 
getting it back in a different region.


It really does not make sense to me to use the DATE header because it 
could be messed with by anyone in the path. It is untrusted. The iat 
is trusted so when you verify it makes more sense to use the current 
date/time of your SBC because the limitation is 60 seconds from AS to VS.


I imagine Neustar made it optional because their own system has some 
intelligence when it comes to this expiration of the AS.


On top of that Metaswitch is not prepared for this situation. They are 
basically counting on that DATE header to be there in their 
recommended perimeta SBC config. They plan to fix it by using the 
current date/time.


Just looking for how others are handling this. Just leaving it blank 
for now?


Matt


___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops


___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] question about stir/shaken - iat and DATE header

[Joseph Jackson]

I've heard that TNSi also counts on the date header being present.

So far we don't see a lot of people passing tokens with the date header.



From: VoiceOps [mailto:voiceops-boun...@voiceops.org] On Behalf Of Matthew 
Yaklin
Sent: Thursday, July 01, 2021 12:25 PM
To: voiceops@voiceops.org
Subject: [VoiceOps] question about stir/shaken - iat and DATE header

All,

Pretty simple question here. When you do a verify request are you filling in 
the iat with your sbc's current date/time or using the DATE information from 
the invite?

With Neustar the iat is currently optional. IQNT is basically removing the DATE 
header in a test we are doing by sending them a call and getting it back in a 
different region.

It really does not make sense to me to use the DATE header because it could be 
messed with by anyone in the path. It is untrusted. The iat is trusted so when 
you verify it makes more sense to use the current date/time of your SBC because 
the limitation is 60 seconds from AS to VS.

I imagine Neustar made it optional because their own system has some 
intelligence when it comes to this expiration of the AS.

On top of that Metaswitch is not prepared for this situation. They are 
basically counting on that DATE header to be there in their recommended 
perimeta SBC config. They plan to fix it by using the current date/time.

Just looking for how others are handling this. Just leaving it blank for now?

Matt
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

[VoiceOps] question about stir/shaken - iat and DATE header

[Matthew Yaklin]

All,

Pretty simple question here. When you do a verify request are you filling in 
the iat with your sbc's current date/time or using the DATE information from 
the invite?

With Neustar the iat is currently optional. IQNT is basically removing the DATE 
header in a test we are doing by sending them a call and getting it back in a 
different region.

It really does not make sense to me to use the DATE header because it could be 
messed with by anyone in the path. It is untrusted. The iat is trusted so when 
you verify it makes more sense to use the current date/time of your SBC because 
the limitation is 60 seconds from AS to VS.

I imagine Neustar made it optional because their own system has some 
intelligence when it comes to this expiration of the AS.

On top of that Metaswitch is not prepared for this situation. They are 
basically counting on that DATE header to be there in their recommended 
perimeta SBC config. They plan to fix it by using the current date/time.

Just looking for how others are handling this. Just leaving it blank for now?

Matt
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] TMobile Sending Calls to LRN not Called Number

[Paul Timmins via VoiceOps]

ugh, in the CalledPartyNumber field, not CallingParty. Have not had 
enough caffeine today. Might not be enough caffeine on the planet for today.


On 7/1/21 12:15 PM, Paul Timmins via VoiceOps wrote:
STIR/SHAKEN isn't implemented at all in TDM world. I've had problems 
on and off for years where a carrier will take SS7 traffic, send it 
over some janky arrangement that strips the GenericAddress parameter 
(where your actual destination number is hidden in the IAM - when you 
dip in SS7 you send the LRN as your CallingPartyNumber, set the flag 
indicating the call is dipped, and put the original TN in the 
GenericAddressParameter field) and then I get a pile of calls from 
specific carriers rocking into my LRN until I can get one of them to 
call their carrier and report the issue, which fixes it. 


___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] TMobile Sending Calls to LRN not Called Number

[Paul Timmins via VoiceOps]

STIR/SHAKEN isn't implemented at all in TDM world. I've had problems on 
and off for years where a carrier will take SS7 traffic, send it over 
some janky arrangement that strips the GenericAddress parameter (where 
your actual destination number is hidden in the IAM - when you dip in 
SS7 you send the LRN as your CallingPartyNumber, set the flag indicating 
the call is dipped, and put the original TN in the 
GenericAddressParameter field) and then I get a pile of calls from 
specific carriers rocking into my LRN until I can get one of them to 
call their carrier and report the issue, which fixes it.


Our usual trick is the LRNs are routed to the NOC, so they have a 
procedure where if they start getting calls from all over the place 
looking for our customers, that they ask the caller to reach out to 
their phone company and have them write down a little spiel to put in 
their trouble ticket with their carrier ("Clear Rate says they are 
getting the calls without the generic address parameter, which is 
related to failure of local number portability in your switch or tandem 
provider" or something to that effect), which is typically pretty effective.


How often? Happens probably once a year since I set up the network in 
2007 we'll have a spate of them for a day.


-Paul

On 7/1/21 11:42 AM, Mary Lou Carey wrote:
I'm not an expert in how STIR/SHAKEN is implemented in the TDM world, 
but I've never heard of this happening until recently. I've heard 
anything sent over the SS7 network has issues with the token being 
dropped. Maybe the problem is bigger than just the token being 
dropped.maybe what they are doing is causing the called number to 
be dropped as well! That's the only reason I can come up with as to 
why one would get the LRN but not the called number.


Just a thought,

MARY LOU CAREY
BackUP Telecom Consulting
Office: 615-791-9969
Cell: 615-796-

On 2021-07-01 10:15 AM, Mark Timm wrote:

It’s not just T-Mobile, it’s Verizon, US Cell and Lumen
originations.  I believe it is traffic that Inteliquent back hauls.

 [1]

    Mark Timm​

    Switch Engineer

    Aureon

7760 Office Plaza Drive South

West Des Moines

    ,

IA

50266

    mark.t...@aureon.com

515‑830‑0478

 [2]

    www.Aureon.com [2]

 [3]

 [4]

 [5]

 [6]

This message contains confidential information and is intended only
for the intended recipients. If you are not an intended recipient you
should not disseminate, distribute or copy this e-mail. Please notify
the sender immediately by e-mail if you have received this e-mail by
mistake and delete this e-mail from your system. E-mail transmission
cannot be guaranteed to be secure or error-free as information could
be intercepted, corrupted, lost, destroyed, arrive late or incomplete,
or contain viruses. The sender therefore does not accept liability for
any errors or omissions in the contents of this message, which arise
as a result of e-mail transmission. If verification is required please
request a hard-copy version.

From: VoiceOps  On Behalf Of Matthew
Sutton
Sent: Thursday, July 1, 2021 10:08 AM
To: voiceops@voiceops.org
Subject: [VoiceOps] TMobile Sending Calls to LRN not Called Number

Anyone else seeing calls from TMobile coming in with the LRN as the
called number? The ISUP doesn't show the actual called number so we
can't route the calls.

-Matthew

Links:
--
[1] https://www.aureon.com/
[2] http://www.aureon.com/
[3] https://www.facebook.com/aureon
[4] https://www.youtube.com/channel/UCv6xwRKJCouZM6FPQEJ6CMA
[5] https://www.twitter.com/aureon
[6] https://www.linkedin.com/company/aureon
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops



--
Paul Timmins
Clear Rate Communications
Direct: (248) 556-4532
Customer Support: (877) 877-4799
24 Hour Repair: (866) 366-4665
Network Operations: (877) 877-1250
www.clearrate.com

This message contains confidential information intended only for the use of the 
intended recipient(s) and may contain information that is privileged. If you 
are not the intended recipient, or the person responsible for delivering it to 
the intended recipient, you are hereby notified that reading, disseminating or 
copying this message is strictly prohibited.

If you have received this message by mistake, please immediately send 
notification by replying to the message, indicate the message was received by 
mistake, and then delete the original message immediately thereafter. Thank you.

Clear Rate Communications, Inc. 2600 W Big Beaver, Suite 450, Troy, MI 48034.

___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] TMobile Sending Calls to LRN not Called Number

[Joseph Jackson]

Agreed.

From: VoiceOps [mailto:voiceops-boun...@voiceops.org] On Behalf Of Alex Balashov
Sent: Thursday, July 01, 2021 10:43 AM
To: VoiceOps
Subject: Re: [VoiceOps] TMobile Sending Calls to LRN not Called Number

I periodically have to explain to vendors of various things, including quite 
reputable vendors, that you can’t route based on the To header in any way, and 
the value in it matters for nothing, and it doesn’t need to align with the 
RURI, and in many cases won’t and shouldn’t.

For some reason, the idea that the To URI has some non-cosmetic value just 
won’t die. I don’t know what it is. Maybe the mind just can’t get past the name 
and the way it intimates a destination. But, in 3261, it’s a purely cosmetic 
commentary on the intended logical destination. It’s a cue for humans. It means 
absolutely nothing else and should never, ever, ever, ever be used for routing, 
nor compared to the RURI in a way that has bearing on routing, nor anything 
else functional.
—
Sent from mobile, with due apologies for brevity and errors.


On Jul 1, 2021, at 11:26 AM, Joseph Jackson  wrote:

We’ve seen this on Ribbon SBCs running their 8.2.x code.   If a forwarded call 
comes in (where the number on the RURI is not the same as the To) when the PSX 
does an LNP dip it will rewrite the RURI to the LRN.  Which of course causes 
the call to fail.

I have no idea if this is the same issue but we’ve been working through that 
issue on one of our SBCs and they said it would be resolved in the latest 
V08.02.06R000 release.According to Ribbon TAC this issue is also present in 
their V9.X train as well and will have a fix released on july 23rd.

Joseph


From: VoiceOps [mailto:voiceops-boun...@voiceops.org] On Behalf Of Matthew 
Sutton
Sent: Thursday, July 01, 2021 10:08 AM
To: voiceops@voiceops.org
Subject: [VoiceOps] TMobile Sending Calls to LRN not Called Number


Anyone else seeing calls from TMobile coming in with the LRN as the called 
number? The ISUP doesn't show the actual called number so we can't route the 
calls.

-Matthew
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] TMobile Sending Calls to LRN not Called Number

[Mark Timm]

Those are exactly my thoughts but legitimate customers are being caught up in 
it.


MARK TIMM
Switch Engineer
515-830-0478
-Original Message-
From: Mary Lou Carey 
Sent: Thursday, July 1, 2021 10:42 AM
To: Mark Timm 
Cc: voiceops@voiceops.org
Subject: Re: [VoiceOps] TMobile Sending Calls to LRN not Called Number

[External Email] This message was sent from outside the company with a URL. 
Please do not click links unless you recognize the source of this email and 
know the content is safe.


I'm not an expert in how STIR/SHAKEN is implemented in the TDM world, but I've 
never heard of this happening until recently. I've heard anything sent over the 
SS7 network has issues with the token being dropped. Maybe the problem is 
bigger than just the token being dropped.maybe what they are doing is 
causing the called number to be dropped as well! That's the only reason I can 
come up with as to why one would get the LRN but not the called number.

Just a thought,

MARY LOU CAREY
BackUP Telecom Consulting
Office: 615-791-9969
Cell: 615-796-

On 2021-07-01 10:15 AM, Mark Timm wrote:
> It’s not just T-Mobile, it’s Verizon, US Cell and Lumen originations.
> I believe it is traffic that Inteliquent back hauls.
>
>[1]
>
>   Mark Timm​
>
>   Switch Engineer
>
>   Aureon
>
> 7760 Office Plaza Drive South
>
> West Des Moines
>
>   ,
>
> IA
>
> 50266
>
>   mark.t...@aureon.com
>
> 515‑830‑0478
>
>[2]
>
>   www.Aureon.com [2]
>
>[3]
>
>[4]
>
>[5]
>
>[6]
>
> This message contains confidential information and is intended only
> for the intended recipients. If you are not an intended recipient you
> should not disseminate, distribute or copy this e-mail. Please notify
> the sender immediately by e-mail if you have received this e-mail by
> mistake and delete this e-mail from your system. E-mail transmission
> cannot be guaranteed to be secure or error-free as information could
> be intercepted, corrupted, lost, destroyed, arrive late or incomplete,
> or contain viruses. The sender therefore does not accept liability for
> any errors or omissions in the contents of this message, which arise
> as a result of e-mail transmission. If verification is required please
> request a hard-copy version.
>
> From: VoiceOps  On Behalf Of Matthew
> Sutton
> Sent: Thursday, July 1, 2021 10:08 AM
> To: voiceops@voiceops.org
> Subject: [VoiceOps] TMobile Sending Calls to LRN not Called Number
>
> Anyone else seeing calls from TMobile coming in with the LRN as the
> called number? The ISUP doesn't show the actual called number so we
> can't route the calls.
>
> -Matthew
>
> Links:
> --
> [1] https://www.aureon.com/
> [2] http://www.aureon.com/
> [3] https://www.facebook.com/aureon
> [4] https://www.youtube.com/channel/UCv6xwRKJCouZM6FPQEJ6CMA
> [5] https://www.twitter.com/aureon
> [6] https://www.linkedin.com/company/aureon
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] TMobile Sending Calls to LRN not Called Number

[Alex Balashov]

I periodically have to explain to vendors of various things, including quite 
reputable vendors, that you can’t route based on the To header in any way, and 
the value in it matters for nothing, and it doesn’t need to align with the 
RURI, and in many cases won’t and shouldn’t. 

For some reason, the idea that the To URI has some non-cosmetic value just 
won’t die. I don’t know what it is. Maybe the mind just can’t get past the name 
and the way it intimates a destination. But, in 3261, it’s a purely cosmetic 
commentary on the intended logical destination. It’s a cue for humans. It means 
absolutely nothing else and should never, ever, ever, ever be used for routing, 
nor compared to the RURI in a way that has bearing on routing, nor anything 
else functional.

—
Sent from mobile, with due apologies for brevity and errors.

> On Jul 1, 2021, at 11:26 AM, Joseph Jackson  wrote:
> 
> 
> We’ve seen this on Ribbon SBCs running their 8.2.x code.   If a forwarded 
> call comes in (where the number on the RURI is not the same as the To) when 
> the PSX does an LNP dip it will rewrite the RURI to the LRN.  Which of course 
> causes the call to fail.
>  
> I have no idea if this is the same issue but we’ve been working through that 
> issue on one of our SBCs and they said it would be resolved in the latest 
> V08.02.06R000 release.According to Ribbon TAC this issue is also present 
> in their V9.X train as well and will have a fix released on july 23rd.
>  
> Joseph
>  
>  
> From: VoiceOps [mailto:voiceops-boun...@voiceops.org] On Behalf Of Matthew 
> Sutton
> Sent: Thursday, July 01, 2021 10:08 AM
> To: voiceops@voiceops.org
> Subject: [VoiceOps] TMobile Sending Calls to LRN not Called Number
>  
> 
> Anyone else seeing calls from TMobile coming in with the LRN as the called 
> number? The ISUP doesn't show the actual called number so we can't route the 
> calls. 
>  
> -Matthew
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] TMobile Sending Calls to LRN not Called Number

[Mary Lou Carey]

I'm not an expert in how STIR/SHAKEN is implemented in the TDM world, 
but I've never heard of this happening until recently. I've heard 
anything sent over the SS7 network has issues with the token being 
dropped. Maybe the problem is bigger than just the token being 
dropped.maybe what they are doing is causing the called number to be 
dropped as well! That's the only reason I can come up with as to why one 
would get the LRN but not the called number.


Just a thought,

MARY LOU CAREY
BackUP Telecom Consulting
Office: 615-791-9969
Cell: 615-796-

On 2021-07-01 10:15 AM, Mark Timm wrote:

It’s not just T-Mobile, it’s Verizon, US Cell and Lumen
originations.  I believe it is traffic that Inteliquent back hauls.

 [1]

Mark Timm​

Switch Engineer

Aureon

7760 Office Plaza Drive South

West Des Moines

,

IA

50266

mark.t...@aureon.com

515‑830‑0478

 [2]

www.Aureon.com [2]

 [3]

 [4]

 [5]

 [6]

This message contains confidential information and is intended only
for the intended recipients. If you are not an intended recipient you
should not disseminate, distribute or copy this e-mail. Please notify
the sender immediately by e-mail if you have received this e-mail by
mistake and delete this e-mail from your system. E-mail transmission
cannot be guaranteed to be secure or error-free as information could
be intercepted, corrupted, lost, destroyed, arrive late or incomplete,
or contain viruses. The sender therefore does not accept liability for
any errors or omissions in the contents of this message, which arise
as a result of e-mail transmission. If verification is required please
request a hard-copy version.

From: VoiceOps  On Behalf Of Matthew
Sutton
Sent: Thursday, July 1, 2021 10:08 AM
To: voiceops@voiceops.org
Subject: [VoiceOps] TMobile Sending Calls to LRN not Called Number

Anyone else seeing calls from TMobile coming in with the LRN as the
called number? The ISUP doesn't show the actual called number so we
can't route the calls.

-Matthew

Links:
--
[1] https://www.aureon.com/
[2] http://www.aureon.com/
[3] https://www.facebook.com/aureon
[4] https://www.youtube.com/channel/UCv6xwRKJCouZM6FPQEJ6CMA
[5] https://www.twitter.com/aureon
[6] https://www.linkedin.com/company/aureon
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] TMobile Sending Calls to LRN not Called Number

[Mark Timm]

It’s not just T-Mobile, it’s Verizon, US Cell and Lumen originations.  I 
believe it is traffic that Inteliquent back hauls.



Mark Timm
Switch Engineer
Aureon
7760 Office Plaza Drive South
West Des Moines
, IA

50266
mark.t...@aureon.com
515-830-0478
www.Aureon.com
This message contains confidential information and is intended only for the 
intended recipients. If you are not an intended recipient you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this e-mail by mistake and delete 
this e-mail from your system. E-mail transmission cannot be guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or contain viruses. The sender therefore 
does not accept liability for any errors or omissions in the contents of this 
message, which arise as a result of e-mail transmission. If verification is 
required please request a hard-copy version.
From: VoiceOps  On Behalf Of Matthew Sutton
Sent: Thursday, July 1, 2021 10:08 AM
To: voiceops@voiceops.org
Subject: [VoiceOps] TMobile Sending Calls to LRN not Called Number


Anyone else seeing calls from TMobile coming in with the LRN as the called 
number? The ISUP doesn't show the actual called number so we can't route the 
calls.

-Matthew
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] TMobile Sending Calls to LRN not Called Number

[Joseph Jackson]

We’ve seen this on Ribbon SBCs running their 8.2.x code.   If a forwarded call 
comes in (where the number on the RURI is not the same as the To) when the PSX 
does an LNP dip it will rewrite the RURI to the LRN.  Which of course causes 
the call to fail.

I have no idea if this is the same issue but we’ve been working through that 
issue on one of our SBCs and they said it would be resolved in the latest 
V08.02.06R000 release.According to Ribbon TAC this issue is also present in 
their V9.X train as well and will have a fix released on july 23rd.

Joseph


From: VoiceOps [mailto:voiceops-boun...@voiceops.org] On Behalf Of Matthew 
Sutton
Sent: Thursday, July 01, 2021 10:08 AM
To: voiceops@voiceops.org
Subject: [VoiceOps] TMobile Sending Calls to LRN not Called Number


Anyone else seeing calls from TMobile coming in with the LRN as the called 
number? The ISUP doesn't show the actual called number so we can't route the 
calls.

-Matthew
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

[VoiceOps] 8YY Traffic

[Mike Hammett]

Is there any reason I can't throw all 8YY traffic at my IXC tandem? 


In looking in my Metaswitch config, it appears that only 8YY traffic destined 
for my LATA (which doesn't really make any sense) goes to the tandem. 
Everything else goes out to a domestic termination provider. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 



Midwest Internet Exchange 
http://www.midwest-ix.com 



___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

[VoiceOps] TMobile Sending Calls to LRN not Called Number

[Matthew Sutton]

Anyone else seeing calls from TMobile coming in with the LRN as the called
number? The ISUP doesn't show the actual called number so we can't route
the calls.

-Matthew
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops