News:

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

Main Menu

Two Point Foreign Exchange (FX) Telephone Calling (OBI100/OBI110)

Started by NYGuard, April 26, 2020, 07:11:54 AM

Previous topic - Next topic

NYGuard

I have read multiple requests for information identical to the request for information (RFI) below, however the request I have read may not be straight forward or ask for additional other call configuration features that are not required with the description below.

I seek to configure two OBI ATA's, each located at distant geographic locations, in a two-point Foreign Exchange (FX) telephone application where an OBI110 (FXO) connected to POTS dialtone sends / receives calls to/from a telephone connected to an OBI100 (FXS) ATA.

1.   Both OBI ATA's are not located on the same IP Subnet.
2.   Incoming POTS calls at the OBI110 Line Port to ring a telephone at one OBI100 ATA.
3.   Outgoing calls from the OBI100 to draw dialtone, and place calls via a POTS line connected at the OBI110 ATA.
4.   Provisioning for FX service to take place on SP1 on each OBI ATA.
5.   Reduce/eliminate the delay time to outbound calling at the end of dialing from the OBI100 on FX calls, if possible.
6.   SP2 ports on the OBI100 and OBI110 to remain spare, and available for future SIP provisioning.
7.   Maintain Station to Station calling capability between OBI ATA devices via **9 dial access to the OBITALK dial network (**9 + 9D), if possible.

I understand that the above may be redundant on the Forum, however I have not been able to locate a specific example to a solution with what's indicated above.

Thank you in advance too the major forum contributors for the helpful technical support provided to users on this forum.
West Street T Carrier

drgeoff

In the following replace 110110110 by the 9 digit OBi number of the OBi110 and replace 100100100 by the 9 digit OBi number of the OBi100.

1a. To make incoming calls on the POTS line of the OBi110 ring both the phone on the OBi110 and the phone on the OBi100 replace the current ph in the 110's LINE port InboundCallRoute with {ph,pp(100100100)}

Or

1b. To make incoming calls on the POTS line of the OBi110 ring only the phone on the OBi100 replace the current ph in the 110's LINE port InboundCallRoute with {pp(100100100)}

2. To make calls dialled on the phone on the OBi100 use the POTS line on the OBi110 you should enable some security.  I would use Voice Gateway operation.

On the OBi100 enable Voice Gateway 1.  Give it a name eg Rem. Set the AccessNumber to pp(110110110).  Set the Digit map to match the numbers you want to dial and exit the OBi110 LINE port.  Set and take note of the AuthUserID and the AuthPassword. (You have free choice of both.)

Still on the OBi100 go to the PHONE port OutboundCallRoute and insert immediately before what is already there

{(MRem):vg1},

On the OBi110 go to the Obitalk Service page. For the InboundCallRoute add before what is already there

{100100100>(MLi):Li},

and further down that page for AuthUserID1 and AuthPassword1 enter what you used on the OBi100.

(Note that the above assumes that MLi is configured to match the numbers being dialled on the POTS line.)

NYGuard

Thanks for the OBI FX config data.
I will implement the config information as provided.

I appreciate the information in your reply.

Regards.
West Street T Carrier

NYGuard

The following observations were made after all configurations were completed.

Inbound call on the POTS line to the OBI110 via the Line Port to the OBI100 ring and complete OK

Outbound calls placed from the OBI100 towards the OBI110 fails. I reach a recorded message that sounds like an OBITALK message, states: The Number dialed was rejected by the service provider - Reason 403

OBI100 DigitMap is at the DEFAULT (xx.) NOTE: No restrictions on outbound calls
OBI100 Phone Port Primary Line is at the DEFAULT (SP1)

I enabled, and disabled AuthUserID & AuthPassword entries to VG1 at the OBI100, and OBI110 and the one way incoming only operation persists.

Am I supposed to receive a second dial tone before a call attempt is made?
When does the OBI100 spill calling to digits to the OBI110 Line Port to advance a call since the OBITALK Network acts as a Tandem Switch?

I am open to suggestions.

NYG
West Street T Carrier

drgeoff

1.  The configurations for the two directions are completely independent.  Nothing for the OBi110 to OBI100 direction impacts on the OBi100 to OBi110 direction and vice versa.

2.  If you have local access to either or both the 100 and 110 you should log in to their onboard webservers and look at the Call History.  Unfortunately Call History is one of the very few things that are not available via Expert mode on the portal at obitalk.com. What you see in Call History could be very helpful to see where the 100 to 110 is failing.

3.  The settings I gave you are based on part of a setup I have with an OBi100 in Japan and an OBi110 in the UK.  Mine is slightly different in that the 110 routes calls from the 100 out on SP1 to an Asterisk PBX from whence depending on day of the week and landline or cellular number the call is further routed out on a SIP trunk from the PBX or back to the 110 to the POTS line.  My wife uses the facility when she is in Japan to call UK numbers so I know it works though I've haven't yet used it myself so while I am reasonably certain there is no second dial tone I cannot swear to that.

At the 100, the new addition at the beginning of the OutBoundCallRoute should mean that the suitable dialled numbers are sent to Voice Gateway 1, irrespective of the Primary Line setting or anything else later in the OutboundCallRoute.

At the 110 the OBitalk Service page, Inbound Direct Dialing Authentication, AuthMethod should be HTTP Digest (the default).

Check very carefully for inadvertent { ( and , . swaps.

NYGuard

I configured both devices locally after obtaining their individual IP adress, and not through the Obi portal.
I copied your configuration onto a text file, made appropriate modifications where applicable.

Security was enabled, as suggested, and disabled to determine if there is any trouble with peer to peer authentication. I was considering a TRUNK to TRUNK configuration, but I can not locate such information on the web, or it will not yield a functional operation.

I have configured an FX config using Auto Attendant (AA) at the FXO end. I would instead like to install a straight FXO to FXS circuit configuration as if the connection between the OBI110 and OBI100 were a full time DS0 channel.

The end state is to eventually have an inbound connection from a SIP provider to be able to draw dial tone at the FXO without going through AA by first dialing an extension number, the draw second dialtone to advance a call.

The configuration that you described in Japan to UK calling via an IP PBX may be similar to what I want to accomplish. A One Way Dial Repeating Tie Line.

I have been looking at the data logs in the call history of both ATA's. Call data is presented below.

From what I have observed from the data below. The OB110 FXO is not recording FXS call failure events where the OBI100 FXS does. The OBITALK Network appears to be rejecting the Phone Port PRIMARY LINE configuration.

OBI110 call history registers show a call completion event inbound from the OBI110 to the OBI100, OK.

I used different OBI100 PHONE PORT PRIMARY LINE options as a test samples. All call attempts failed.  

Number of calls in history: 1 OBI110 (FXO)
      
Call 1   04/26/2020    20:48:27   
Terminal ID   LINE1          OBiTALK1
Peer Name      
Peer Number             111111111
Direction   Inbound          Outbound
20:48:27   Ringing   
20:48:43                     Call Connected
20:48:46                     End Call

-----------------------------------------------------------------------

OBI100 with PHONE PORT Primary Line: SP1 (DEFAULT)

Number of calls in history: 2 OBI100 (FXS)
      
Call 1   04/26/2020    15:46:21   
Terminal ID      PHONE1           SP1
Peer Name      
Peer Number  18005551212   18005551212
Direction      Outbound    Outbound
15:46:21                            New Call   
15:46:21                            End Call (403 Incorrect Authentication)

Call 2   04/26/2020    15:40:32   
Terminal ID           PHONE1           SP1
Peer Name      
Peer Number1     18005551212   18005551212
Direction           Outbound            Outbound
15:40:32           New Call   
15:40:32                               End Call (403 Incorrect Authentication)

-------------------------------------------------------------------------

OBI100 with PHONE PORT Primary Line: OBITALK
      
Call 1   04/26/2020    17:56:00   

Terminal ID           PHONE1          OBiTALK1
Peer Name      
Peer Number   ob18005551       b18005551  - Dialed number truncated
Direction           Outbound          Outbound
17:56:00           New Call   
17:56:00                             End Call (404 Not Found)

Call 2   04/26/2020    17:48:27   
Terminal ID            OBiTALK1            PHONE1
Peer Name      
Peer Number   ob180055512    ob18005551
Direction           Inbound            Inbound
17:48:27           Ringing   
17:48:43                                Call Connected
17:48:46                                End Call

-------------------------------------------------------------------------

OBI100 with PHONE PORT Primary Line: TRUNK GROUP 1  

Number of calls in history: 2
      
OBI100 with PHONE PORT Primary Line: TRUNK GROUP 1  
      
Call 1   04/26/2020    18:12:02   
Terminal ID            OBiTALK1   PHONE1
Peer Name      
Peer Number   222222222   
Direction           Inbound          Inbound
18:12:02           Ringing   
18:12:09                             Call Connected
18:12:10                             End Call

Call 2   04/26/2020    18:07:47   
Terminal ID            PHONE1           SP1
Peer Name      
Peer Number   18005551212   18005551212
Direction           Outbound           Outbound
18:07:47           New Call   
18:07:47                              End Call (403 Incorrect Authentication)

The OBITALK network is the middle man in this scenario, and it appears that it does not like what's inbound from the OBI100. Unless there is a remote possibility that the OBI110 is rejecting a connection attempt from OBITALK, and is not registering that even in the call history log.

I have seen similar trouble conditions on ATM networks with switched virtual circuits (SVP) dropping cells one way due to ATM fabric issues. OBITALK is more primitive than ATM, but subject to similar ailments not limited to IP connections.

I believe that what I want to achieve may not be technically possible using the OBI ATA's as configured, and the AUTO ATTENDANT may be the only way possible.

I appreciate your assistance.

NYG  
West Street T Carrier

drgeoff

Apologies.  There was an error in the instructions I posted.

MRem was incorrect.  There is no map with that name unless one of the User Defined Digit Maps is given that label. No need to do that. Instead, the correct addition to the OBi100 OutboundCallRoute is

{(Mvg1):vg1},

With that change the OBi100's Call History should now show something like

vg1110110110*18005551212

though you may find that the leading v is changed to an underscore.

I have taken my spare OBi110 out of the cupboard and configured it as I instructed above for your OBi100.  And I have added the extra part to the in-service 110's OBitalk InBoundCallRoute and added the ID and password.  I can successfully dial from a phone on the spare 110 through the in-service 110 and directly (not via SP1 and Asterisk) out on the POTS line to my cell phone.  There is no second dial tone.

NYGuard

Thank you for your follow up.

I will put my equipment puzzle back into operation later today and test the layout, and advise.

Thanks again.

NYG
West Street T Carrier

NYGuard

drgeoff

I continue to experience outbound call completion trouble. Inbound calls from the POTS Line continue to Test OK.

{(Mvg1):vg1}, replaced all references to MRem, and I included {(Mvg1):vg1}, at the very beginning of the OBI110 InboundCallRoute parameter.

Will the circuit work with Authentication turned off, and if yes, how is it turned it off (Disabled)?

Thanks
West Street T Carrier

drgeoff

Quote from: NYGuard on April 28, 2020, 01:54:21 PMand I included {(Mvg1):vg1}, at the very beginning of the OBI110 InboundCallRoute parameter.
Why?  I didn't say to change anything on the OBi110.

NYGuard


Condition resolved.

The update provided to insert {(Mvg1):vg1}, at the OBI-110 was my misunderstanding. After rereading the text it became obvious that a OBI110 was used at the closed end of the FX circuit, and configured as an FXS.

I though  I was faced with an authentication trouble, and or other something else with the Config of the equipment. That is why I wanted to turn off Authentication to remove one possible stumbling block, and pursuit the trouble.

I managed to locate one option configuration that resulted in outbound call failure. The trouble was isolated at  the OBITALK SERVICE SETTINGS InboundCallRoute configuration.

The information originally provided indicated that in the OBI110 Obitalk Service Setting InboundCallRoute, the following was to be placed in front of what was there. The Inbound Call Route window displayed: ph.

The value in the InboundCallRoute setting was it's default. I reset all equipment to Factory default prior to any re-provisioning.

At the OBITALK SERVICE SETTINGS, I observed the following: InboundCallRoute = ph

Change #1: I inserted {2000xxxxx>(MLi):Li}, in front of the value found in the InboundCallRoute window to read: {2000xxxxx>(MLi):Li},ph

The above resulted in a ring no answer condition on call attempts at the OBI100. I was more than likely ringing the phone port on the OBI110.

I removed the ph in a quick test. This resulted in fast busy conditions AKA: Reorder Tone, on outbound calls.

Change #2: I replaced the InboundCallRoute "ph" with "Li" to now read: {2000xxxxx>(MLi):Li},Li

After change #2, all outbound, and inbound calls at the OBI100 completed OK to/from a second POTS line.

OBI110 Software Build: 1.3.0 (Build: 2886), Hardware Ver: 2.8
OBI100 Software Build: 1.3.0 (Build: 2886), Hardware Ver: 3.4

I will assume that FX Line configuration options would apply to a OBI200/202 to OBI212 equipment layout. Unless software/hardware versions with newer equipment require different configuration values.

Thank you for your patience & assistance.

NYG
West Street T Carrier

drgeoff

Quote from: NYGuard on April 28, 2020, 07:25:15 PM
Change #2: I replaced the InboundCallRoute "ph" with "Li" to now read: {2000xxxxx>(MLi):Li},Li
1.  Without a ph the OBi110 will be unable to receive calls to its phone using the Obitalk service.  You originally posted that you would like to retain the **9 possibility.

{2000xxxxx>(MLi):Li},{ph}

will allow any OBi to call the OBi110's phone by dialling **9 followed by the 9 digit number of your 110.  Or

{2000xxxx>(Mli):Li},{2000xxxx:ph}

will limit it to calls from your OBi100.

2.  These methods work with any OBi ATA or OBiPhone released to date. (Provided not using an ancient firmware or a firmware/configuration that has been adversely customised.)

3.  The Bible for all this stuff is the Admin Guide. https://www.obitalk.com/info/documents/admin_guide/OBiDeviceAdminGuide.pdf for the ATA.  Page 130 for Voice Gateways and page 191 onwards for Call Routeing and Digit Maps.

4.  When you fully understand Call Routeing and Digit maps you will be able to make optimisations such as minimising post-dial delays and short cuts. For example, adding your version of

<0:**9110110110>

into the OBi100 Phone port Digit Map gives the option of calling the OBi110 phone by simply dialling a single 0.

NYGuard

Thank again.

Good information, however {ph} was not the default option in the InboundCallRoute field, ph was, and as stated, call completion could not take place until Li was added after the argument string.

If there were a named config settings that enables OBITALK ***9 station to station calling in addition to POTS stage one dial access, I can not identify it the original instructions.

A procedure in para 1a does give a config option for simultaneous call termination at both the OBi100 and OBi110 on inbound POTS calls. Where 1b presents a config for call terminations at only the OBi100.

I had examined the Admin Guide, as suggested, and after spending time with it, it pointed to the change that resolved my outbound calling when ",Li" was placed after {2000xxxxx>(MLi):Li} Digimap string.

If the {2000xxxxx>(MLi):Li} string inhibited all outbound POTS line calls, how will adding {ph}to the string as {2000xxxxx>(MLi):Li},{ph} permit dual outbound Stage One calling, and OBITALK calls to terminate at the OBi110?

Would {2000xxxxx>(MLi)},{:Li},{ph} be a more appropriate Digimap string? The only way to know is to try it.

I find that books are a tremendous resource, however hands-on always wins.

Thanks.
West Street T Carrier

azrobert

The OBi100 default SP1 (ITSP A) digit map might be causing your routing problem. It won't allow you to send a 10 digit number to Line. The primary route digit map is used to validate the dialed number. It contains rule "<1>xxxxxxxxxx" which prefixes a 10 digit number with a "1". When you dial 10 digits, 11 digits will be sent to the OBi110. If OBi110 (Mli) doesn't contain an 11 digit rule then "{2000xxxxx>(Mli):li}" will not get a match and the call will fail. Just remove the "<1>" to fix the problem.

drgeoff,
I didn't know a vg can be used with obitalk. I tried it w/o a password and it worked.
Thanks

drgeoff

Quote from: azrobert on April 29, 2020, 12:31:51 PM
I didn't know a vg can be used with obitalk.
That was the original use.  The additional ability to use it as an outward only, no registration SP came with firmware v1.2 according to page 131 of the Admin Guide in the paragraph preceding the bullet points.

NYGuard

Azrobert

The circuit works both ways as initially provisioned, and later with changes during the troubleshooting process. Sometimes the "book" may not be always correct. My experience with Telecommunication products has revealed capabilities that are not be captured by documentation.

Think of it in terms of an Easter Egg find. I have discovered, and exploited non-standard signaling combinations with TDM voice channel equipment in the past where developers did not know existed. Of course there is a risk of losing a hidden find during a future firmware update that removes it, because the item was not accounted for during regression tests. Firmware updates have been known to lose capabilities, but regression testing typically finds it.

The one thing that I didn't test was a OBiTALK end to end connectivity. Something to do by using Digimap argument string combinations to determine what will work.

Lastly, I was able to achieve a circuit function that I have been seeking for a long some time. Most post on the Forum were very close to the circuit function I was looking for. But most Q&A's were close, but not close enough.
If there was ever an RFI to the Forum requesting help for a same or similar FX configuration, I was not able to find it.

drgeoff's approach to my circuit configuration question was direct, and simple in terms of equipment configuration requirements. I was handed a 99% solution that helped tremendously to get to what I wanted to achieve; FX dial tone.

Thanks.
West Street T Carrier

NYGuard

Thread follow up. Please feel free to comment to observations.

Below are Digimap combinations, and test results made to the OBi110 ATA.

All calls were  performed at the OBi100 phone port to PSTN# 1.800.555-1212 and OBiTALK# 200xxxxxx.

Modifications to the OBi110 OBiTALK Service Setting InboundCallRoute Digimap Configurations were made, with associated test call reference results as indicated, below:

{200xxxxxx>(MLi):Li},ph
Dial 1.800.555-1212, rings OBi110 Phone Port continually until answered, when OBi110 Line Port is not spare.
Dial 1.800.555-1212, rings OBi110 Phone Port continually until answered, if OBi110 Line Port is spare.

Dial ***9+9D OBiTALK number, call fails when OBi110 Line Port is not spare.
Dial ***9+9D OBiTALK number, call fails if OBi110 Line Port is spare.

{200xxxxxx>(MLi):Li},Li
Dial 1.800.555-1212, long pause, call completes OK.
Dial 1.800.555-1212, call fails if Line Port is spare.
Dial ***9+9D OBiTALK number, reach second dialtone. Re-enter 1.800.555-1212 on second dialtone to complete call OK.
Dial ***9+9D OBiTALK number, call fails if OBi110 Line Port is spare.

{200xxxxxx>(MLi):Li},Li,ph  
Dial 1.800.555-1212 rings OBi110 Phone Port with two ring cycles, if call is not answered at the OBi110, call is passed automatically to the Line Port to complete OK.
Dial 1.800.555-1212 rings OBi110 Phone Port continually until answered, if OBi110 Line Port is spare.

Dial ***9+9D OBiTALK rings OBi110 Phone Port with one ring cycle, then second dialtone. Re-enter 1.800.555-1212 on second dialtone to complete call OK.
Dial ***9+9D OBiTALK rings OBi110 Phone Port continually until answered, if OBi110 Line Port is spare.
----------------------------------------------------------
{200xxxxxx>(MLi):Li},{ph}
Dial 1.800.555-1212, Long pause, continually rings OBi110 Phone Port when OBi110 Line Port is not spare.
Dial 1.800.555-1212, Long pause, continually rings OBi110 Phone Port if OBi110 Line Port is spare.

Dial ***9+9D OBiTALK number, call completes OK with OBi110 Line Port connected to a POTS line
Dial ***9+9D OBiTALK number, rings OBi110 Phone Port continually until answered, if OBi110 Line Port is spare.

{200xxxxxx>(MLi):Li},{Li}
Dial 1.800.555-1212, call completes OK
Dial 1.800.555-1212, call fails when OBi110 Line Port is spare.
 
Dial ***9+9D OBiTALK number, call fails if OBi110 Line Port is spare.
Dial ***9+9D OBiTALK number, long pause, reach second dialtone. Re-enter 1.800.555-1212 on second dialtone to complete call OK.

{200xxxxxx>(MLi):Li},{Li},{ph}
Dial 1.800.555-1212, call completes OK
Dial 1.800.555-1212, call fails when OBi110 Line Port is spare.

Dial ***9+9D OBiTALK number, long pause, reach second dialtone. Re-enter 1.800.555-1212 on second dialtone to complete call OK.
Dial ***9+9D OBiTALK number, call fails if OBi110 Line Port is spare.


Thanks again.


Side note: 1.800.555-1212 AT&T Toll Free Information Service: Recording states: AT&T Toll Free Information Service will be discontinued by AT&T on 01 June 2020.

West Street T Carrier

drgeoff

Your results do not correspond with what I recall either from some years of use of the OBi100 in Japan to the OBi110 in the UK or the OBi110 to OBi110 test setup that I did a few days ago.  In both setups "Dialling through" never rang the phone on the 110 and calling the phone (**9, not ***9 as you have typed) never reached anywhere other than the phone whether the phone was answered or not.  At this moment I'm not able to repeat that test but should be able to in the next day or two.

Your results make me think that the first rule in the InboundCallRoute is not working.  Yet no matter how hard I look I see no difference in the format of what you post

{200xxxxxx>(MLi):Li},{ph}

and what works for me.  That makes me query the 9 digit OBi number you are using.  Are you sure that the 2000xxxxx is that of the OBi100 and not that of the OBi110?  A further reason for my query is that both of my OBi110s have numbers that begin with 200 and my OBi100 has a 300xxxxxx number.  To be absolutely clear, that number MUST be that of the calling, not called, OBi.

azrobert

Try this for the obitalk InboundCallRoute:
{>(xx.):li},{ph}

NYGuard

drgeoff

You are correct with a OBiTALK line number transposition. A cut and paste transcription error on my part.

Obitalk Service InboudCallRoute was: {200xxxxxx>(MLi):Li},ph

Changed to: {300xxxxxx>(MLi):Li},ph or {300xxxxxx>(MLi):Li},{ph}

The ph or {ph} designation change allows the POTS/OBiTALK to works both ways OK.
What is the significant between the two DigiMap options, ph and (ph}?

My apologies for dragging this out.

Thanks again, always.

NYG
West Street T Carrier