Call rejected reason 404
CLTGreg:
Quote from: intelafone on February 04, 2014, 11:00:43 am
Quote from: mgsnell on February 03, 2014, 05:26:41 pm
I get the automated message that the call was rejected and reason 404.
If you are manually configuring your Obihai device, I recommend following the steps on this tutorial to resolve this issue.
Can you explain to me under what circumstances would a 404 condition be caused by the Obi? I'm frustrated with the "reboot and reconfig" "troubleshooting" when it comes to an intermittent problem. There's no way to verify and Support has refused to state that they even looked at the calls on your end during the time.
VM is picking up immediately when there's a bad incoming call and caller ID is not registering on bad incoming. I do not see how the device can be to blame for this and Support will not provide an explanation. The config is to forward on error and not pick up for 60 seconds so why would VM pick up sooner?
The problem with generic troubleshooting is there's no way to know if it works if it's intermittent. You are asking me to trust you without any confidence as to what the problem is. You should at least be able to say "we have checked our logs and we are 100% certain that the problem is with your Obi device" which would also imply that there's something flaky with Obis in general. And I absolutely do not understand how re-entering the exact details in Obi setup for SIP can change anything.
I want to support you because I'm all for what you are doing and the voice quality is great. But before you tell me to reboot a device not currently in error state you need to at least take the step by telling me that your end sees that the problem is on my end and if that's true why didn't it call forward?
None of these questions have been answered when asked in e-mail so far.
Lavarock7:
You should know that most of us responding are not Obihai employees, but users such as yourself.
As for rebooting a device that may be intermittent, it is a common practice of troubleshooting electronic devices, especially those with computer code in them.
It is not uncommon to see comments in code that say "we should have never gotten to this place, but since we did, we have no idea what is wrong".
The 1st Shuttle was sitting on the launchpad and the liftoff was on hold because neither of the 3 command computers were acting correctly. I mentioned to a newsman next to me that they needed to start each computer one at a time. Minutes later launch control announced that they were going to restart each command computer, one at a time. It appears that they all came up at the same time, broadcast a message saying "I'm here" and then all 3 waited for the others to announce they were online, but they had already. In later versions, a random wait was added to avoid any over-talk issues.
If a reboot is good enough for a multi billion dollar Shuttle, I'm guessing Obis would be in good company. :-)
CLTGreg:
Quote from: Lavarock7 on February 19, 2014, 02:09:12 pm
The 1st Shuttle was sitting on the launchpad and the liftoff was on hold because neither of the 3 command computers were acting correctly. I mentioned to a newsman next to me that they needed to start each computer one at a time. Minutes later launch control announced that they were going to restart each command computer, one at a time. It appears that they all came up at the same time, broadcast a message saying "I'm here" and then all 3 waited for the others to announce they were online, but they had already. In later versions, a random wait was added to avoid any over-talk issues.
If a reboot is good enough for a multi billion dollar Shuttle, I'm guessing Obis would be in good company. :-)
The question wasn't to Obihai and while I appreciate your reply I have to disagree in this case. Obivoice is unwilling to give any clues as to where a problem may be. Do you personally think that an Obi device can cause Obivoice to pickup a call and send it to voice mail when it is programmed to call forward if error?
All I asked for is for them to check what it looks like on their side. Simply wanting to know what was in their logs. Their reply never changed from "reboot your device".
You know far more about these things than I ever will but when a vendor refuses to provide any other data I feel that it is a blow off. Mainly I feel this way because a reboot for a seemingly random problem cannot be proven to be a solution. If it happens again and there is no real troubleshooting then they can just say do it again.
Two questions if you don't mind considering your experience. Could an OBI device disrupt the incoming caller ID of a call that as it is recorded at the SIP provider? What role does the OBI have in manipulating caller ID for calls that do not connect?
Have you seen where redoing the automated setup on an Obi fixes something if the values are exactly the same? If so then that points to the Obi as being flaky in general and that is not my experience. For it to be flaky with one provider that includes refusing to follow call forward instructions and missing caller ID in their logs does not sound like an Obi issue.
intelafone:
Quote from: CLTGreg on February 19, 2014, 08:07:03 am
None of these questions have been answered when asked in e-mail so far.
CLTGreg,
Your support email stated that you were unable to receive any calls. This was an issue with the device and was resolved.
In regards to caller ID, it is recorded in your Call Log as it is received from the carrier of the caller. The only way we "assign" Caller IDs to incoming calls is if you give specific numbers Caller IDs using the My Phonebook feature.
To set up Failover Forwarding successfully on your account, log into your web portal and navigate to the Settings page of the Account menu. Add the Call Forwarding Number first and then set the Forwarding Strategy to Failover Forward. This will only forward calls when the servers detect your device as disconnected.
CLTGreg:
I did not state that I was "unable to receive any calls". The support ticket stated that two calls had errors and an outbound call failed immediately afterwards.
There was no issue with the device and nothing was resolved. The only support offered was reboot and reprogram.
All I asked was for logs to be checked or further explanation besides reprogramming the adapter. The call log shows two calls with no caller ID (these were reported to me as immediate voice mail pickups) which should not have happened because failover call forwarding was configured properly and time to answer was set to 60 seconds. Therefore any voice mail pickup did not obey instructions which you have not stated is a failure of the Obi device.
I don't want to argue about it. If it was a fluke then fine. I want you to succeed. But if your policy is going to be to tell me to flash my device when calls are picked up against instructions before they reach my device then we've got a problem.
Instead of going back and forth I'd just ask that you consider this further and just be able to say "we checked our end and everything is OK" which it wasn't. For the time being I will not use the service for incoming calls.
I assume it was a fluke because I don't see anyone else reporting this kind of problem presently. But since I could not get an understanding of how the error was the Obi's fault, I saw this thread and asked mostly for educational reasons.
Navigation
[0] Message Index
[*] Previous page