But isn't congestion caused by bytes and not number of packets? So, by that
argument, larger packets will fill the queue faster than smaller and thus have
a higher propensity to drop? And when it does, it is a bigger chunk of audio so
it could actually reduce quality rather than improve it.
Ag
> 1. For packets from the ITSP to the customer: override the default BGP
routing to choose an alternate route
Interesting idea. Who's doing this and how is it working for you? Are you
using static routes or altering BGP? Other?
> 2. Increase the ptime from 20 ms to 30-40 ms to reduce packet-drop
uding TF), but as you pointed out – if you
>> are using a Canadian number as the ANI and still can’t get through then
>> it’s a network based issue.
>>
>>
>>
>> Most of the time yes… TF to TF is still spotty.
>>
>>
>>
>> Best Regards,
>>
so I wouldn’t rely on this.
>
>
>
> Cheers.
>
>
>
> Best Regards,
>
>
>
> Ivan Kovacevic
>
> Star Telecom | www.startelecom.ca | SIP Based Services for Contact
> Centers
>
>
>
> *From:* VoiceOps [mailto:voiceops-boun...@voiceops.org] *On Behalf
Greetings VoiceOpers,
There are a handful of US SIP carriers who offer the promise of doing
business in Canada with Canadian DID's. The challenge we've seen is that
when you call some toll free numbers from those Canadian DID's the call
gets blocked by the far end, presumably because the switching
e
> >
> >> On Apr 22, 2014, at 8:59, Alex Balashov
> wrote:
> >>
> >> I'm hearing that something is very wrong up in Level3's network. A
> number of my customers and vendors have taken their Level3 peers down.
> >
Anyone seeing routing issues, primarily east coast? Seeing issues with at least
Comcast and Level3 so far
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops
Anyone have any issues with toll-free today? We saw a sporadic issue for
roughly 15 minutes but it was not correlated to any one carrier. Mostly just
east coast from what we can tell. Possible issue with SMS?
___
VoiceOps mailing list
VoiceOps@voiceops.
We are. 2 issues related to 6.5
1- in 6 RHEL decided to place a limit on threads (1024). Depending on your
system load you may find that limit pretty quickly. There is a patch for this
but you can also set it manually in the kernel as well as in one of the /etc
config files
2- also in six Red