News:

On Tuesday September 6th the forum will be down for maintenance from 9:30 PM to 11:59 PM PDT

Main Menu

RESOLVED ! Unable to dial out of PSTN line from a remote Obi throuh AA

Started by Obitalk, March 12, 2011, 09:10:22 AM

Previous topic - Next topic

RonR

Quote from: Obitalk on March 14, 2011, 10:20:36 PMMy auto attendant digit map is as follows:

([1-9]|[1-9][0-9]|<00:$1>|0|(Mpli)|**1(Msp1)|**2(Msp2)|**8(Mli)|**9(Mpp))

And my outbound call route is as follows:

{0:ph},{(Mpli):pli},{(<**1:>(Msp1)):sp1},{(<**2:>(Msp2)):sp2},{(<**8:>(Mli)):li},{(<**9:>(Mpp)):pp}

So I guess this mean I don't need to change anything correct ?
Correct.

The mystery continues, I guess.

QBZappy

Obitalk,

Hi,

Can you get a screen capture of the "Call Status" OBi web page while the call is ringing, and of the call history. There might be some useful info in there. (From both OBi's) Attach it as an image on your post. JPG image works well.

Are the OBi's at both ends behind one or 2 routers?

Try this:
Port forward the configured RTP ports configured in the OBi web page to the each of the OBi units:
ITSP Profile A or B->RTP->LocalPortMin         
ITSP Profile A or B->RTP->LocalPortMax
Owner of the 1st OBi110/100 units in service in Canada & South America. 1st OBi202 on my street. 1st OBi1032 in Montreal.

QBZappy

Obitalk,

I remembered you are dialing **9, meaning you are using the OBitalk service and not a SIP account to call the other OBi. Then port forwarding the Min and Max port numbers I made reference to should not make any difference in your setup.

I think the OBi severs work like a "mediation server" all the OBis can connect to their server. If two OBis want to call each other the OBi server will negotiate the connection between the two units and presumably leaves the call path leaving the two OBi units to be peer to peer environment. I think this is why it is not necessary to port forward the OBi service. It resolves the NAT issue in this way. A similar technique is used by various other services. I can think of the Hamachi VPN which works this way.

I think this is the first time this topic has been brought up. Maybe the OBi people can confirm if this is the underlying concept of the OBi service.
Owner of the 1st OBi110/100 units in service in Canada & South America. 1st OBi202 on my street. 1st OBi1032 in Montreal.

OBiSupport

Obitalk,

Please confirm that at this time, you can dial another OBi number and
exchange audio fine ?
The only problem right now, is calling out via PSTN on another OBi ?

Can you please email support@obihai.com on this ?
Please indicate the OBi number where you are calling from, and also
the OBi number of the unit that is calling out via PSTN.

-Obihai Support Team

Obitalk

Hi ObiSupport,
Last time I called the remote Obi I let the AA continue by pressing '1' and was able to talk to the person at the other end. That was about 5 or 6 days ago. I will make sure I can still do the same and update the staus. Also I have noticed that sometime on the OBiTALK Service Status it indicates Backing Off most of the time while the US based Obi always indicates Normal Mode

I will email Obisupport the requested Obi Numbers.

Thank you

Obitalk

Another symptom I have noticed is that once the call fails to connect through the PSTN line, I'm unable to access the remote Obi web interface for 5-10 mins. Thanks

RonR

Is there anyone there who can watch it and try to use it locally while it's in that state.  It would be interesting to know if it's rebooting after 5 - 10 minutes and that's what brings it back to life.

Obitalk

Obisupport,

I can confirm that both parties can hear audio and the call is ok when dialling **9 to the remote Obi.

Thanks

Obitalk

RonR

I think you are on the right track. I think the remote Obi rebooted after the PSTN called failed.

See below:

HardwareVersion 2.8 
SoftwareVersion 1.1.0 (Build: 1892) 
SystemTime 05:47:15 01/-40176/2010, Monday 
UpTime 0 Days 0:17:15 (6)

Uptime of 17mins. I couldn't access it for approximately 15mins.

Thanks

RonR

Quote from: Obitalk on March 16, 2011, 06:04:32 AMHardwareVersion 2.8 
SoftwareVersion 1.1.0 (Build: 1892) 
SystemTime 05:47:15 01/-40176/2010, Monday 
UpTime 0 Days 0:17:15 (6)
The Reboot Reason Code is suspicious looking, especially if this is a reproducible scenario:

6: New Profile Invoked AND Profile URL Changed

I believe that Reboot Reason Code would normally mean the OBi rebooted because it just received new provisioning info (but it could also be meaningless if the OBi rebooted because of an unexpected software malfunction).

I would suggest trying several more calls and observing whether each of them show the same Reboot Reason Code.  Then I would disable Auto Provisioning and try several more calls to see if the results change.

It's possible your calls through the Auto Attendant aren't happening because they're crashing the OBi for some reason.  You need to collect more data and symptoms in order to narrow down what's really occurring.

MichiganTelephone

Quote from: RonR on March 16, 2011, 10:23:49 AMIt's possible your calls through the Auto Attendant aren't happening because they're crashing the OBi for some reason.  You need to collect more data and symptoms in order to narrow down what's really occurring.

Or, you know, he could contact Obihai support and let them work their magic, instead of taking orders from you.  ::)  They have diagnostic tools not available to the rest of us.
Inactive, no longer posting or responding to messages.  Goodbye and good luck.  Some of my old Obihai-related blog posts have been moved to http://tech.iprock.com - note this in NOT my blog; I have simply given the owner permission to repost some of my old stuff.

Obitalk

Hi RonR and MichiganTelehone,

Thanks for all of your input.

Sometime you don't realize the little things like

1.) The Obi rebooting after the PSTN call failing
2.) ObiTalk network shows the status as backing off 50% of the time etc

Did I mention that I had a tough time factory reseting the unit. I did it via the IVR and then couldn't get it to succed even after the reboot of the unit. Then requested someone at the other end use a paper clip to reset the unit. After 5-10 try I was able to get the unit te reset.

Anyways every little bit helps and thank you for your continued support.

I did already provide both the Obi numbers to support@obihai.com. I hope they get back to me sometime.

Thanks

RonR

Quote from: Obitalk on March 16, 2011, 11:19:04 AM2.) ObiTalk network shows the status as backing off 50% of the time etc
I didn't mention it in my previous post, but there does appear to be something not quite right in the networking area.  The OBi's Real Time Clock is not getting set properly:

SystemTime 05:47:15 01/-40176/2010, Monday

Quote from: Obitalk on March 16, 2011, 11:19:04 AMDid I mention that I had a tough time factory reseting the unit. I did it via the IVR and then couldn't get it to succed even after the reboot of the unit. Then requested someone at the other end use a paper clip to reset the unit. After 5-10 try I was able to get the unit te reset.
I don't recall you mentioning it.  There is a known bug in the OBi that after a reset to factory defaults from the IVR (option eight), the OBi fails to reboot itself and is left in an indeterminate state until it's manually rebooted.

Obitalk

I agree with you that there might be some network issue indicated by the incorrect time as well as the Obitalk service that showd the status of backing off. To make matters complicated, I'm able to call the Google Line on SP1 without any issues anytime. So I'm not sure whether its entirely a network issue and not an issue with the ObiTalk service.

RonR

Others have reported unrelated issues with time synchronization, so it may not mean anything to your current problem.

Obitalk

Hi Obi support, Any luck on finding out what my issue with the device might be ?  Thanks

yhfung

Most of second-stage diallings in SPA3000 or SPA3102 have the same and well-known problems as you described.

You may consider by adjusting the gains (receive or transmit in either or both OBi devices) such that the analogue DTMF signals at the callee end are GOOD enough for the DTMF digit detection.


Hope this give you some direction to go.


YH

Hong Kong and China OBi Users Group
www.telecom-cafe.com

obi-support2

Obitalk,
Our support staff is checking your OBi configuration right now. They will continue to communicate with you directly over email. We may need to run some further diagnostics with your remote OBi in order to trouble shoot the root cause. Thanks for your patience.
Please do not hesitate to email support for status update or to provide further information.

-------

I also would like to make a quick note about the extra rule ([1-9]x?*(Mpli) in digit map
and {([1-9]x?*(Mpli)):pp} in call route. These are added to support a new feature in release 1.2, known as ad hoc 1-stage gateway dialing. Basically you can have a gateway's obi number configured in one of the 99 speed dial slots (1-99). Suppose this gateway obi does not require userid/password authentication for inbound 1-stage call (i.e., only based based on circle-of-trust), then one can dial
<speed-dial> * <target-number> to make a 1-stage call to the target number via the gateway (whose obi number is configured in the given <speed-dial>. For example, speed dial 8 = pp(ob200123456)).

About the missing **8 rule in OutboundCallRoute on some OBi. This was caused by an earlier bug in the OBiTALK portal that accidentally removed the rule from some obi units that are managed by the portal. This issue has been fixed and you will get back the correct OutboundCallRoute after resync'ing with the portal. We apologize for your inconvenience.


OBIHAI Support Staff

OBiSupport

Obitalk,

You mentioned earlier that you ask someone at the remote location to press
**8<phonenum>>. You said that it is working at that place, that's good.
Can you also ask that person to press **0 (which AA will respond)
and then option 2, proceed to **8<phonenum> ?

This way, the person at the remote location is trying the same exact way
as what you do when you call in to AA.

This will need to be handled by the support team,
can you please email support@obihai.com with the answer to above.

Thanks
-Obihai Support Team

Obitalk

I requested the person at the remote end to dial

**8 (phone number) and it was successful. Both parties were able the hear each other

**0 Pressed 2 and then **8 (phone number) was also successful. Both parties were able to hear each other.

I'm emailing the same information to the support team.

Thanks