[VoiceOps] Call Quality

[Mike Hammett]

"Then there's the popularity of anchoring media to mask downstream providers" 

I configure all of my sessions to not re-invite, but I do so because most of the VoIP providers only run mediocre IP networks. I build my IP networks to ensure good performance to both my providers and my customers. I can't ensure that anyone else has built their network the same. 


Others do so to mask which carriers they use? That seems awfully immature. On inbound, it's a simple LRN lookup. On outbound, okay, that is a lot harder to figure out. It still doesn't make any sense. 




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



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



----- Original Message -----

From: "Calvin Ellison" <calvin.ellison at voxox.com> 
To: "Mike Hammett" <voiceops at ics-il.net> 
Cc: "VoiceOps" <voiceops at voiceops.org> 
Sent: Tuesday, June 15, 2021 5:28:15 PM 
Subject: Re: [VoiceOps] Call Quality 


VoIP termination still has the same 20th-century PSTN problems with low-cost/quality carriers worming their way into wholesale LCRs. Then there's the popularity of anchoring media to mask downstream providers, and the SIP/RTP trapezoid becomes a hairball of jitter, latency, and possible dead air from packet TTL hitting zero. 


If your clients want you to do something about the robocalls they are getting, there are many caller reputation services out there who can help. TransNexus/ClearIP is fairly turnkey, or you can get data directly from people like YouMail, Hiya, and First Orion to do your own analytics. 


Is RingCentral really paying the IP transit to duplicate their media streams just in case of some problem, or is it more likely they have multiple peers and use standard tricks like BGP and path monitoring to drop routes as needed? 
















Calvin Ellison 
Systems Architect 
calvin.ellison at voxox.com 
+1 (213) 285-0555 





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 14, 2021 at 9:16 AM Mike Hammett < voiceops at ics-il.net > wrote: 




I should add that my initial intent was the voice ecosystem, aside from the end-users. For those, usually it's one of the things we all already know. 


Why would carrier A have "good quality", while carrier B didn't? 




I had a conversation with a customer about quality being more important than price. A lot of things come to mind right away (such as diversity, latency, jitter, packet loss, etc.), but I'm looking for what I don't know. 






orrrr 




Are there just that many poorly ran companies where the low-hanging fruit I'm brushing aside is where almost all of the problems occur? 




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



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





From: "Mike Hammett" < voiceops at ics-il.net > 
To: "VoiceOps" < voiceops at voiceops.org > 
Sent: Sunday, June 13, 2021 1:11:30 PM 
Subject: [VoiceOps] Call Quality 


I've heard a variety of complaints and concerns over the years about call quality. How are these quality issues introduced? As long as pipes and equipment aren't overloaded, where is a quality issue to come from? 




Obviously, the closer you are to the handsets, the less opportunity there is for issues. What else is there to take into account? 




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



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




_______________________________________________ 
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 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20210616/89359359/attachment.htm>