<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Aptos;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:Aptos;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#467886;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#96607D;
text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.EmailStyle17
{mso-style-type:personal;
font-family:Aptos;
color:windowtext;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link="#467886" vlink="#96607D"><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I'm growing more and more confused by the problem description, and feel like we are missing some crucial details...<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>If the calls are truly being terminated over the carrier's own IMS core, then NAT actually should not be involved in the slightest. Most U.S. carriers run single-stack IPv6 on their IMS APN. So the leg of the call between end-user device and IMS core is 100% IPv6-native. If the call is then getting passed to you via IPv4, the carrier must have some kind of SBC + media proxy at their edge that sits between the IPv6 IMS network and however the peering is set up between you and the carrier(s) in question (over IPv4 public internet, or private IPv4 point-to-point circuit, or perhaps VPN over IPv4 public internet with IPv4 also used within the tunnel?).<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Also, if the call is genuinely coming from carrier's IMS core, I don't see what the UC app you keep referencing that the end-user might happen to be running has to do with anything. If the same caller were to call a DID of yours from the iPhone's native phone app, I'd expect/assume you would experience the same.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Finally, if this is truly a call coming from the carrier's IMS core, then the WiFi handoff scenario I postulated earlier isn't even applicable, which is why I said that that theory only makes sense in the context of "scenario #2"; that is, when the call is made by an app over regular internet data directly to a SIP server or proxy that *you* run, and does *not* touch the carrier's IMS core at all. In that scenario, the user's public internet address would be changing each time it bounced between the mobile network and WiFi. But actual WiFi Calling / VoWiFi works by having the phone establish an IPsec VPN tunnel between itself (while connected to a WiFi network) and the carrier's internet-facing ePDG gateway, over which it communicates directly with the carrier's native IPv6 IMS core. Thus whether a mobile voice call is happening via a mobile radio tower or over WiFi, the phone itself is still talking directly to the carrier's P-CSCF, not to your servers.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>It seems inescapable to me that either these calls are not actually touching the carrier's IMS core at all, or if they are, that the carrier is doing something weird with how they are proxying media between themselves and you. In either case, I still don't see how it can be anything but a carrier issue, which still leads me back to concluding that you must be seeing this issue only with calls made from a specific carrier...and also still raises the question of how the heck it is at all relevant that this is an "iPhone" and not just any smartphone.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>If you are reluctant to name the "UCaaS" app or vendor here, feel free to shoot me a message off-list with the name. I'm wondering if that detail might be a possible key to the puzzle.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>-- Nathan<o:p></o:p></span></p><p class=MsoNormal><a name="_MailEndCompose"><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></a></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-family:"Tahoma","sans-serif"'> Richard Jobson [mailto:richard@teraquant.com] <br><b>Sent:</b> Monday, June 3, 2024 7:32 PM<br><b>To:</b> Nathan Anderson; voiceops@voiceops.org<br><b>Subject:</b> Re: [VoiceOps] Has anyone seen this? Voice UCaaS application on iPhone generated call: switching source IP address mid-call with no SIP signaling to indicate<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span style='font-size:12.0pt'>Hi Nathan<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Thank you for your analysis & especially your “Hmm, maybe with scenario #2”, - roaming off Wi-Fi on to cellular ..<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>I thought this might be of interest to the community as there are only so many Wireless IMS Network operators & UC/CCaaS apps are so popular, this might be a systematic problem of wider interest.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>these iPhone-originated calls are made by a vendor UC/CCaaS app over standard VoLTE/IMS Network via our ITSP softswitch/feature svr (same vendor as the UC App) our UCaaS core. It might be internet on the access/mobile side (as you say Wi-Fi) but its the carrier's IMS core/private network to us.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>It is NAT & IPv4<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt;font-family:"Calibri","sans-serif";color:black'>Many Thanks & Best Regards,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt;font-family:"Calibri","sans-serif";color:black'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'>For your convenience, please click </span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><a href="https://calendly.com/richard-406/30min"><span style='color:blue'>here</span></a><span style='color:black'> to schedule a time for us to talk.</span><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt;font-family:"Calibri","sans-serif";color:black'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt;font-family:"Calibri","sans-serif";color:black'>Richard Jobson<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt;font-family:"Calibri","sans-serif";color:black'>Teraquant Corporation<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt;font-family:"Calibri","sans-serif";color:black'>ph: 719 488 1003<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt;font-family:"Calibri","sans-serif";color:black'>d/l: (719) 766-8523<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt;font-family:"Calibri","sans-serif";color:black'><a href="http://www.teraquant.com/"><span style='color:blue'>www.teraquant.com</span></a><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt;font-family:"Calibri","sans-serif";color:black'><a href="mailto:richard@teraquant.com">richard@teraquant.com</a><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><a href="https://www.linkedin.com/in/uc-expert-monitoring/"><span style='color:blue'>https://www.linkedin.com/in/uc-expert-monitoring/</span></a><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt;font-family:"Calibri","sans-serif";color:black'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt;font-family:"Calibri","sans-serif";color:black'>Network Monitoring and Service Assurance - Speech Quality Experts (PESQ/POLQA) and Active Testing - Reporting – HPBX - Session Border Controllers – SASE and SD-WAN - Big Data Analytics, fraud detection and protection.</span><b><span style='font-family:"Calibri","sans-serif";color:black'> </span></b><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt;font-family:"Calibri","sans-serif";color:black'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt;font-family:"Calibri","sans-serif"'>--</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt;font-family:"Calibri","sans-serif"'>NOTICE: This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying, or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail.</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><div id=mail-editor-reference-message-container><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in'><b><span style='font-size:12.0pt;color:black'>From: </span></b><span style='font-size:12.0pt;color:black'>VoiceOps <<a href="mailto:voiceops-bounces@voiceops.org">voiceops-bounces@voiceops.org</a>> on behalf of Nathan Anderson via VoiceOps <<a href="mailto:voiceops@voiceops.org">voiceops@voiceops.org</a>><br><b>Date: </b>Monday, June 3, 2024 at 6:46</span><span style='font-size:12.0pt;font-family:"Arial","sans-serif";color:black'> </span><span style='font-size:12.0pt;color:black'>PM<br><b>To: </b><a href="mailto:voiceops@voiceops.org">voiceops@voiceops.org</a> <<a href="mailto:voiceops@voiceops.org">voiceops@voiceops.org</a>><br><b>Subject: </b>Re: [VoiceOps] Has anyone seen this? Voice UCaaS application on iPhone generated call: switching source IP address mid-call with no SIP signaling to indicate<o:p></o:p></span></p></div><div><p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Slightly confused (based on your references to "Wireless IMS Network SBC") whether these iPhone-originated calls are just standard VoLTE/IMS calls being made by the native phone app and being carried by the carrier's IMS core, or whether these are SIP calls being sent to your own UCaaS core by your app over the carrier's regular internet/data APN.</span><span style='font-size:12.0pt'><o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><span style='font-size:12.0pt'><o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>If you are saying that you have direct-IP voice peering with one or more wireless carriers, and that iPhone users on those networks are calling numbers of yours & you are seeing the source IP of RTP traffic change mid-call, then I don't see how that can be anything *but* a carrier issue. That said, I also don't see how that can be an iPhone-specific problem, either, or how you managed to arrive at that conclusion. If you were to more closely look at logs related to calls where this is happening, I'd expect that you would find that 1) the problem is specific to a particular carrier, not a particular phone model, and 2) you'll find many calls coming from that one carrier across multiple phone models exhibiting the issue. As to WHY the carrier might be doing this...I haven't the foggiest.</span><span style='font-size:12.0pt'><o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><span style='font-size:12.0pt'><o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>If you are saying you have iPhone users running an app of yours that is making outgoing SIP calls directly through your ITSP network over the carrier's internet APN, then ...I don't see how that could be anything but a carrier issue, either, honestly. You didn't mention whether this was IPv4 or IPv6 though. I'd be surprised if you saw this happening when the traffic is arriving to you via IPv6. However, for IPv4 traffic, it would not surprise me. Vast majority of carriers in the U.S. are handing out RFC1918 space IP addresses to end-user devices & putting them behind a masquerading NAT. You'd expect that the NAT would try to retain the same source IP for the duration of a given session, but I would not be shocked to discover that the NAT configuration or the NAT engine itself is broken in some way, leading to this symptom. (I'd also not be surprised to learn that the carriers simply couldn't care less if SIP traffic over the internet to their subscribers is unreliable, even though they've largely gotten to the point where voice services are no longer their primary money-maker...industry inertia and all that.) If you don't already have your own ITSP service natively reachable over IPv6 yet, you might consider finally getting around to doing so...most of the major mobile carriers in the U.S. are dual-stacking these days, so if carrier-side IPv4 NAT is the cause, this would work around it for vast majority of users I'd think.</span><span style='font-size:12.0pt'><o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><span style='font-size:12.0pt'><o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Maybe you are trying to describe a different scenario than either of these, but I'm having trouble coming up with another one. And in either case, I'm confused how you narrowed it down to iPhones, and not to a particular carrier?</span><span style='font-size:12.0pt'><o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><span style='font-size:12.0pt'><o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>(Hmm, maybe with scenario #2, is it possible the customer's phone is moving between the mobile data network and a local WiFi network while in the middle of a call? You'd hope the phone would be smart enough to either keep the existing session on the same network interface that it began on [though that might be difficult in the case where it *started* on WiFi & the WiFi network disappeared / moved out of range], or at least properly notify the app that the network interface is changing, in which case the app could have a fighting chance of getting a re-INVITE sent out? If you look at the source IPs involved, are they always the carrier's IPs, or are you seeing the traffic move between completely unrelated networks/ASes?)</span><span style='font-size:12.0pt'><o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><span style='font-size:12.0pt'><o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>-- Nathan</span><span style='font-size:12.0pt'><o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><span style='font-size:12.0pt'><o:p></o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='margin-left:.5in'><b><span style='font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-family:"Tahoma","sans-serif"'> VoiceOps [<a href="mailto:voiceops-bounces@voiceops.org">mailto:voiceops-bounces@voiceops.org</a>] <b>On Behalf Of </b>Richard Jobson via VoiceOps<br><b>Sent:</b> Monday, June 3, 2024 11:08 AM<br><b>To:</b> <a href="mailto:voiceops@voiceops.org">voiceops@voiceops.org</a><br><b>Subject:</b> [VoiceOps] Has anyone seen this? Voice UCaaS application on iPhone generated call: switching source IP address mid-call with no SIP signaling to indicate</span><span style='font-size:12.0pt'><o:p></o:p></span></p></div></div><p class=MsoNormal style='margin-left:.5in'><span style='font-size:12.0pt'> <o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:12.0pt'>Just curious as to whether the community thinks this is a network configuration issue or a Mobile app issue<o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:12.0pt'> <o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:12.0pt'> <o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:12.0pt;color:#212121'>This is either …</span><span style='font-size:12.0pt'><o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:12.0pt;color:#212121'><br>1. Something to do with the app on the iPhone</span><span style='font-size:12.0pt'><o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:12.0pt;color:#212121'>2. Or is the Wireless IMS Network SBC that is changing the srce IP Addr mid-call</span><span style='font-size:12.0pt'><o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:12.0pt;color:#212121'>3. Or RTP has been routed to a different Wireless IMS Network SBC mid-call</span><span style='font-size:12.0pt'><o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:12.0pt'> <o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:12.0pt'>this behavior is totally noncompliant to the RFC.<o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:12.0pt'> <o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:12.0pt'>The Oracle SBC in our ITSP network maintains the call up because the SSRC remains the same. However, when this happens, a second or third time it gets complicated .<o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:12.0pt'> <o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:10.5pt;font-family:"Calibri","sans-serif";color:black'>Many Thanks & Best Regards,</span><span style='font-size:12.0pt'><o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:10.5pt;font-family:"Calibri","sans-serif";color:black'> </span><span style='font-size:12.0pt'><o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'>For your convenience, please click </span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><a href="https://calendly.com/richard-406/30min"><span style='color:blue'>here</span></a><span style='color:black'> to schedule a time for us to talk.</span></span><span style='font-size:12.0pt'><o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:10.5pt;font-family:"Calibri","sans-serif";color:black'> </span><span style='font-size:12.0pt'><o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:10.5pt;font-family:"Calibri","sans-serif";color:black'>Richard Jobson</span><span style='font-size:12.0pt'><o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:10.5pt;font-family:"Calibri","sans-serif";color:black'>Teraquant Corporation</span><span style='font-size:12.0pt'><o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:10.5pt;font-family:"Calibri","sans-serif";color:black'>ph: 719 488 1003</span><span style='font-size:12.0pt'><o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:10.5pt;font-family:"Calibri","sans-serif";color:black'>d/l: (719) 766-8523</span><span style='font-size:12.0pt'><o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:10.5pt;font-family:"Calibri","sans-serif";color:black'><a href="http://www.teraquant.com/"><span style='color:blue'>www.teraquant.com</span></a></span><span style='font-size:12.0pt'><o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:10.5pt;font-family:"Calibri","sans-serif";color:black'><a href="mailto:richard@teraquant.com">richard@teraquant.com</a></span><span style='font-size:12.0pt'><o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><a href="https://www.linkedin.com/in/uc-expert-monitoring/"><span style='color:blue'>https://www.linkedin.com/in/uc-expert-monitoring/</span></a></span><span style='font-size:12.0pt'><o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:10.5pt;font-family:"Calibri","sans-serif";color:black'> </span><span style='font-size:12.0pt'><o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:10.5pt;font-family:"Calibri","sans-serif";color:black'>Network Monitoring and Service Assurance - Speech Quality Experts (PESQ/POLQA) and Active Testing - Reporting – HPBX - Session Border Controllers – SASE and SD-WAN - Big Data Analytics, fraud detection and protection.</span><b><span style='font-family:"Calibri","sans-serif";color:black'> </span></b><span style='font-size:12.0pt'><o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:10.5pt;font-family:"Calibri","sans-serif";color:black'> </span><span style='font-size:12.0pt'><o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:10.5pt;font-family:"Calibri","sans-serif"'>--</span><span style='font-size:12.0pt'><o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:10.5pt;font-family:"Calibri","sans-serif"'>NOTICE: This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying, or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail.</span><span style='font-size:12.0pt'><o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:12.0pt'> <o:p></o:p></span></p></div></div></div></div></body></html>