News:

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

Main Menu

Why is My 110 Slow Answering and Sending Landline Calls?

Started by Bluewind, May 02, 2013, 04:38:46 AM

Previous topic - Next topic

Bluewind

I just installed a 110 and connected it to a landline phone (and Google Voice too). The landline phone is set as my primary line. I pickup a phone and dial any 10 or 11-digit number and there is a lag of approximately 15 seconds before the 110 starts to dial. Why does it take the 110 so long to dial the number? Is there some setting to delay the start of dialing that I accidentally set? My expectation is that there should be little or no delay before calls start dialing. Note that the same delay occurs when dialing out with Google Voice.

On the inbound side I have a similar situation. If I call my landline from another landline in the same central office I hear three rings on the calling phone before the 110 starts to ring. Callers to my landline hear five or six rings before I can get to a phone in my house to pick it up. Frequently I get a hang up or after 30 seconds of ringing my telco-based voice mail assumes that the call will not get picked up so it answers the call. I can easily test the number of rings the caller hears before the 110 starts to dial by disconnecting the 110 and plugging my line side into a phone. When this happens the caller hears the first ring simultaneously with the first ring on my 110. My expectation is that the 110 should start ringing the same time as the caller hears ringing.

I am running the latest Obi firmware.

Thanks for your ideas.

ianobi

QuoteWhy does it take the 110 so long to dial the number?

This looks like a problem matching numbers dialled with the relevant DigitMap. The default OBi110 Line Port DigitMap is:

Physical Interfaces > LINE Port > DigitMap:
(xxxxxxxS4|1xxxxxxxxxx|xx.)

If you dial an eleven digit number starting with "1" then it should match using the "1xxxxxxxxxx" rule and dial out in two seconds or so. A ten digit number does not match any rule so the "xx." rule is used as a "catch-all". The OBI does not know how many digits to expect, so it waits for ten seconds before assuming that you have finished dialling. Then it has to dial the digits to line, so the overall delay could be 12 to 15 seconds.

The problem with Google Voice is harder to explain as it should be using this DigitMap:

Service Providers > ITSP Profile A > General > DigitMap:
(1xxxxxxxxxx|<1>[2-9]xxxxxxxxx|011xx.|xx.|(Mipd)|[^*#]@@.)

This matches ten and eleven digit numbers.

Do you live in North America? Could you give examples of numbers being dialled? (not real numbers).


QuoteIf I call my landline from another landline in the same central office I hear three rings on the calling phone before the 110 starts to ring.

This is due to:

Physical Interfaces -> Line Port -> RingDelay. The default is 4000 (4 seconds). This is to give the OBi110 time to capture and process the the CallerID. You could try reducing this setting. If you do not care about CallerID you can set it to 0.


Ideasmiths

#2
Quote from: Bluewind on May 02, 2013, 04:38:46 AM
I just installed a 110 and connected it to a landline phone (and Google Voice too). The landline phone is set as my primary line. I pickup a phone and dial any 10 or 11-digit number and there is a lag of approximately 15 seconds before the 110 starts to dial. Why does it take the 110 so long to dial the number? Is there some setting to delay the start of dialing that I accidentally set? My expectation is that there should be little or no delay before calls start dialing. Note that the same delay occurs when dialing out with Google Voice.

My Obi110 settings are 2 years old and a bit fuzzy, but I vaguely remembered these information.

There are TWO sets of digitmaps that you need to finetune. The first is when you initiate a call, the Obi110 has to determine which service to use based on the digits you have pressed (or dialed) and whether the digits are valid or allowed. The second set of digitmap is when the service (example PSTN line) received the digits (from phone), does these digits need to be modified and so on.

All the digitmaps has some sort of delay preset in the obi110 internal counter (around 2 seconds), I assume this is to allow users to have time to press the numbers.

First digitmap - for the phone
When you press the digits on the landphone, there may be a 2 seconds waiting while the Obi110 is waiting when it cannot determine which segment of the digitmaps is 'valid'. To tell it to execute immediately without waiting to compare other digitmap segments, append a S0 behind (see below)

a) you may want to change parameter at

Physical Interfaces > Phone Port > DigitMap: (xxxxxxxxxxS0|xx.)

The above digitmaps has 2 segments. What this means is that once you press in 10 digits. This becomes a valid number and Obi110 will stop comparing and immediately send the numbers to the correct outbound call services (for example the PSTN Line).

If you press in quantity 0 to 9 digits, there will be a slight delay as the counter waits. For example pressing 123456789 will not trigger the xxxxxxxxxxS0 and the Obi110 is using the xx. segment and waiting, if nothing is pressed for the next 2 seconds, it will send these 9 digits to the service.

b) change the parameter OutboundcCallRoute to "{@:li}

Please note the above is my own setup as I only use the phone to make PSTN line call, so what happens is that whatever number I press on the phone, the call will be send to the PSTN line.

The Second digitmap
When the service (example PSTN line) received the digits from the source (ie the phone) it also checks the digits you have press against the digitmap conditions. As mentioned above, the default digitmap is

Physical Interfaces > LINE Port > DigitMap:
(xxxxxxxS4|1xxxxxxxxxx|xx.)

This means that the counter will try to match 3 different segments before it dial the number. So basically the simplest explaination is that if you key in a 7 digit number there will be a delay of 4 seconds ie the xxxxxxxS4 conditon,

if you key in a number starting with 1,  there is also a delay because the last condition xx. waits as you may be about to press the 12th or the 13th digit.

On my setup I use (<9>[23689]xxxxxxxS0|xx.) because in Singapore the mobile or landlines number are 8 digit and starts with 2,3,6,8 or 9. Example 91234567. The <9> is used to append a 9 infront of the number I dial because inside my office, you need to dial 9 to connect to an outside line.

So when I press 91234567 on my phone connected to the Obi110, the obi110 gets 991234567 and knows that this is a VALID phone number. When this matches, the S0 at the back immediately dial the number. If I press 9 or 10 digits example 9123456789 then this does not match the first set of digitmap and it goes to the xx. portion and there is delay while the counter waits....

so my suggestion is you ADD to the digitmap for example [6]xxxxxxxxxxS0| which will immediately dial any 10 number that starts with 6, example 61234567890    . Change the 6 or add to it to suit your needs.

After you set the digitmap and it is working, you can tune the following parameters also at Physical Interfaces > LINE Port >

DialDelay   350       (default was 500)
DialDigitOnTime 65 (default was 200)
DialDigitOffTime   65 (default was 200)   

The dial delay is x milliseconds when the obi110 connect to the PSTN line, then send out the digits you have pressed. The default is 500ms and each digit is send at the default 200ms interval. My settings is for Singapore's PSTN specification where the Obi110 will start sending out the digits after 350 milliseconds, then each digit is send in 65ms. This may speed up the 'delay' that you experience.

You need to check the specification at your local telco to see what speed they can accept because if the settings is wrong (ie you send the digits too fast), the call will fail as the telco phone switches didn't receive the digits. For example in the above settings, if your local telco needs a 100 ms delay between each keypress, then the call will fail as the Obi110 is sending out the digits too fast at 65 ms.