Calling problems 5-7-09 AM

Removed because I am sure Tim will take care of this.

Scott, is your outgoing working? I cannot make calls, but can receive them. I sniffed the traffic and saw my invites being ignored, so the outbound times out. I opened a ticket but was told that they were able to make a call using my credentials so it must be at my end.

Quote:

---

Originally Posted by dswartz

Scott, is your outgoing working? I cannot make calls, but can receive them. I sniffed the traffic and saw my invites being ignored, so the outbound times out. I opened a ticket but was told that they were able to make a call using my credentials so it must be at my end.

---

Currently no known network issues, if you open a ticket or shoot me a PM I can grab a network trace and see whats going on, thanks!

Quote:

---

Originally Posted by Xponder1

Well... thats how I would of handled it. While I was at it I would put a note on the account in case said customer contacted support so my peers knew what was going on so they could help this customer.

On a side note if my X-Lite setting somehow caused 1000's of customers service to have issues for a moment I apologize for their inconvenience. I was unaware of the problem which should be obvious from reading this thread.

---

What basically happened is that a VM notification went out from our VM servers and since the system detected you were on two servers, it would send to one and that one would send to the other, on and on.

This used to not happen, but since the VOIPo to VOIPo internal calling fix, things are organized a little differently in terms of how on network packets are handled and this was an unforseen effect of that.

The loop created some sporadic behavior on central01 and central02 since those were the servers involved. In a situation like this, the top priority is to minimize impact and restore service as a whole. From what I understand they put the temporary block on was they were concerned that once they stopped the loop, the ATA and softphone would be "fighting with each other" to re-register and both would end up doing so then if a VM MWI notification was triggered somehow, it'd just happen again. So that's why they blocked it.

I agree though that you should have been notified and am going to look into it a little more to make sure this stuff is handled better in the future. Sorry for the inconvenience.

We also have a few changes that are being finalized/tested in terms of the way multiple registrations are handled and also how we deal with softphone/grandfathered BYOD accounts so that they're not able to impact the "general population" as a whole.

Quote:

---

Originally Posted by VOIPoTim

What basically happened is that a VM notification went out from our VM servers and since the system detected you were on two servers, it would send to one and that one would send to the other, on and on.

This used to not happen, but since the VOIPo to VOIPo internal calling fix, things are organized a little differently in terms of how on network packets are handled and this was an unforseen effect of that.

The loop created some sporadic behavior on central01 and central02 since those were the servers involved. In a situation like this, the top priority is to minimize impact and restore service as a whole. From what I understand they put the temporary block on was they were concerned that once they stopped the loop, the ATA and softphone would be "fighting with each other" to re-register and both would end up doing so then if a VM MWI notification was triggered somehow, it'd just happen again. So that's why they blocked it.

I agree though that you should have been notified and am going to look into it a little more to make sure this stuff is handled better in the future. Sorry for the inconvenience.

We also have a few changes that are being finalized/tested in terms of the way multiple registrations are handled and also how we deal with softphone/grandfathered BYOD accounts so that they're not able to impact the "general population" as a whole (whether intentionally or unintentionally).

---

Thank you for taking the time to reply Tim. I feel better about it already.
Have a great day.

Quote:

---

Originally Posted by dswartz

Scott, is your outgoing working? I cannot make calls, but can receive them. I sniffed the traffic and saw my invites being ignored, so the outbound times out. I opened a ticket but was told that they were able to make a call using my credentials so it must be at my end.

---

Everything is working as normal for me. I was having some break up on some calls which is not normal but I believe it is cleared up.

One thing I noticed on my asterisk box, with inbound calls they used to come from a Level3 IP address 4.68.250.xxx and now incoming calls show a 192.168.27 address? I think calls used to be handed off to Level3 and my box would talk to Level3's media gateway directly and now the audio is going through VOIPo's IP's when I look at connections on my firewall. This started around 9:00 this morning.
Scott

Quote:

---

Originally Posted by scott2020

Everything is working as normal for me. I was having some break up on some calls which is not normal but I believe it is cleared up.

One thing I noticed on my asterisk box, with inbound calls they used to come from a Level3 IP address 4.68.250.xxx and now incoming calls show a 192.168.27 address? I think calls used to be handed off to Level3 and my box would talk to Level3's media gateway directly and now the audio is going through VOIPo's IP's when I look at connections on my firewall. This started around 9:00 this morning.
Scott

---

That's about the time my service went out and apparently caused issues for 1000's of people. They probably made some kind of change when they were trying to figure it out.

Quote:

---

Originally Posted by scott2020

Everything is working as normal for me. I was having some break up on some calls which is not normal but I believe it is cleared up.

One thing I noticed on my asterisk box, with inbound calls they used to come from a Level3 IP address 4.68.250.xxx and now incoming calls show a 192.168.27 address? I think calls used to be handed off to Level3 and my box would talk to Level3's media gateway directly and now the audio is going through VOIPo's IP's when I look at connections on my firewall. This started around 9:00 this morning.
Scott

---

Scott,

That 192.168.27 address you are seeing is the local CLEC that is delivering your origination (for that phone number). As for your media path being directed to our gateway, this change has been for quite some time now (since we've had better reports of us handling the audio). This is not a result from any changes this morning.

Are you continuing to see any call quality issues? Please submit a ticket and do let us know if you are so we can further look into this for you.

Thanks!

I see. The local CLEC used to send the 4.68.250.xxx address and that is what would connect to me, but it changed this morning. On the audio path, I am almost positive my audio was always going direct to the provider media gateway but maybe I was wrong. The audio quality is fine now. thanks!

192.168.x.x is a Class C private network and it is not routable on the internet. Unless your ISP is sending it or your ATA is trying to contact, you should not be seeing 192.168.x.x address.