Delayed Dialing on LINE Port

Started by RonR, March 13, 2011, 06:00:35 PM

Previous topic - Next topic

RonR

For those experiencing long delays when dialing out on the LINE Port, try changing:

Physical Interfaces -> LINE Port -> DigitMap

to:

(xxxxxxxS4|<1>[2-9]xxxxxxxxxS0|1xxxxxxxxxxS0|xx.)

This assumes the service provider on the LINE port expects or accepts 7-digit local numbers and 11-digit long distance numbers (1 + area code + 7-digit number).

You may dial long distance numbers from an OBi phone with or without a leading '1'.

RonR

911 is already handled at the PHONE Port DigitMAP/OutboundCallRoute level, hence it goes out immediately regardless of what the LINE Port DigitMap is.

Before you jump to conclusions, you might want to study the Administrator's Guide in the area of how DigitMaps and interdigit timers work in the OBi.

jimates

THIS IS A POST I MOVED FROM ANOTHER THREAD TO KEEP THINGS ON TOPIC.
THE OP IS A RESPONSE TO MY POSTS




I noticed a difference in making calls on the LINE when pressing **8.
Pressing **8 does place a call on the LINE but I do notice now that when I place a call using **8 there is a 20 second delay before the DMP processes the call.


It seems my outbound call route for the PHONE was also modified with the beta version. There is no rule for **8 in it either. How does it route the call without it?

Physical Interfaces > Phone > DigitMap
([1-9]x?*(Mpli)|[1-9]|[1-9][0-9]|911|**0|***|#|(Mpli)|**1(Msp1)|**2(Msp2)|**9(Mpp))

Physical Interfaces > Phone > OutboundCallRoute
{([1-9]x?*(Mpli)):pp},{(<#:>|911):Mpli},{**0:aa},{***:aa2},{(Mpli):pli},{(<**1:>(Msp1)):sp1},{(<**2:>(Msp2)):sp2},{(<**9:>(Mpp)):pp}

I can't access either of my Obi's web interface. I get an xml error
Someone post their data for the Physical Interfaces > Phone from the 1.1.0 FW

jimates

THIS IS A POST I MOVED FROM ANOTHER THREAD TO KEEP THINGS ON TOPIC.
THE OP IS A RESPONSE TO MY POSTS




I changed my settings on the Phone Port. I noticed no difference, there is still a 20 second delay in the outgoing call.

jimates

Quote from: QBZappy on March 13, 2011, 03:00:23 PM
jimates,

Default settings: SoftwareVersion=1.1.0 (Build: 1892)

Physical Interfaces->PHONE Port->DigitMap->=

([1-9]|[1-9][0-9]|911|**0|***|#|(Mpli)|**1(Msp1)|**2(Msp2)|**8(Mli)|**9(Mpp))


Physical Interfaces->PHONE Port->OutboundCallRoute->=

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


jimates

#5
RonR,

It would help immensely if you would could post the default settings for call route and digit maps when you give editing information.


Also, I moved my posts to this thread so you should delete yours in the other thread, if you want.

jimates

#6
Quote from: RonR on March 13, 2011, 06:00:35 PM
For those experiencing long delays when dialing out on the LINE Port, try changing:

Physical Interfaces -> LINE Port -> DigitMap

to:

(xxxxxxxS4|<1>[2-9]xxxxxxxxxS0|1xxxxxxxxxxS0|xx.)

This assumes the service provider on the LINE port expects or accepts 7-digit local numbers and 11-digit long distance numbers (1 + area code + 7-digit number).

You may dial long distance numbers from an OBi phone with or without a leading '1'.

That edit had no effect on my problem, I still get the delay.

My provider will not accept 7 digits, only 10 or 1 + 10. And both return the same results when dialing out without the Obi or when dialing # first, immediate delivery of the call.

RonR

As I'm sure you know, you can always get the default value for any setting by checking the default box in the OBi.  I didn't bother to post it in this case because this was not a case of editing.  What I posted was a total replacement value.  Perhaps if I had posted the default value, however, it might have prevented MichiganTelephone from blowing his cork.   :)

The default Physical Interfaces -> LINE Port -> DigitMap is: (xxxxxxxS4|1xxxxxxxxxx|xx.)

Let's see if he criticizes the Obihai folks as much as he did me.   :)

jimates

Replacing, editing, same difference.

It just makes for a better response. And, for the sake of those that have no idea what we are talking about, if you could explain what the new rule does. At least the part you add.

I know I can get the default, after I access the device.
For some reason I can't access it using IE, I get an xml error. So I open Chrome and access through it. Changing from one tab to another is quite easy but having to change browsers is slightly more of a pain.

And remember, at this point in the game there will be many newbies reading these threads and they are going to get scared off if we don't keep it as simple as we can.

RonR

jimates,

I'd be happy to explain the elements of the LINE Port DigitMap I suggested:

(xxxxxxxS4|<1>[2-9]xxxxxxxxxS0|1xxxxxxxxxxS0|xx.)

The interdigit timer starts out at 10 seconds, meaning you have 10 seconds to enter another digit before the DigitMap Processor assumes you're done and evaluates what's been entered to that point.  It stays at 10 seconds until there's at least one rule in an Exact Match state.  At that point, the interdigit timer changes to 2 seconds.

For this set of rules, the timer stays at 10 seconds until the 7th digit has been entered.  Since 7 digits exactly matches the first rule, the timer would normally change to 2 seconds at that point.  Since 2 seconds is a bit short if you've got more digits to enter, such as a 10- or 11-digit number, S4 sets the timer to 4 seconds instead.  If you haven't entered anything else after 4 seconds, the DMP returns the 7-digit number.

The 8th digit you enter causes the first rule to change to the Mismatch state and the timer reverts to 10 seconds.  If you keep entering digits until you reach the 10th and the first digit is not a 0 or 1, it's assumed you've entered a 10-digit number starting with an area code.  Since this exactly matches the second rule, the timer would normally change to 2 seconds, but S0 sets the timer to 0 and the DMP returns the 10-digit number immediately, adding a 1 to the beginning.

If the first digit is a 1 and 10 more digits were entered behind it, the third rule is matched, the timer is forced to 0 and the DMP returns the 11-digit number immediately, unchanged.

If none of the first 3 rules are matched, the fourth rule matches whatever digits you've entered and the DMP returns them after 10 seconds.



Now let's look at the default LINE Port DigitMap:

(xxxxxxxS4|1xxxxxxxxxx|xx.)

This DigitMap has three problems:

1. 10-digit numbers.  Since they don't exactly match any of the rules, there's a 10 second wait for the DMP to return them.

2. 10-digit numbers.  A 1 is not added to the beginning of the returned number.

3. 11-digit numbers.  There's a 2 second wait that's totally unnecessary.



There you have it.  Are you still glad you asked?   :)

MichiganTelephone

Quote from: RonR on March 13, 2011, 08:21:45 PM
As I'm sure you know, you can always get the default value for any setting by checking the default box in the OBi.  I didn't bother to post it in this case because this was not a case of editing.  What I posted was a total replacement value.  Perhaps if I had posted the default value, however, it might have prevented MichiganTelephone from blowing his cork.   :)

RonR, I apologize for those messages, which I have since deleted (I tried editing them and decided that just made them worse, and confused things more).  Now that you've explained it, it makes perfect sense.  Part of the reason I responded in the first place was that I just did not see the angle brackets around the <1> at the start of one of your patterns, and my first thought was "why is there a duplicate pattern in there?" and that's what got me going.  I'm actually wondering if, for some reason, my browser originally didn't display the angle brackets (I'm assuming you didn't edit the post, because it doesn't say it was edited, but I still can't understand how I missed them).  :-[

But for future reference, sometimes explanations are helpful!
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.

jimates

#11
Quote from: RonR on March 13, 2011, 09:38:33 PM
jimates,

I'd be happy to explain the elements of the LINE Port DigitMap I suggested:

(xxxxxxxS4|<1>[2-9]xxxxxxxxxS0|1xxxxxxxxxxS0|xx.)

The interdigit timer starts out at 10 seconds, meaning you have 10 seconds to enter another digit before the DigitMap Processor assumes you're done and evaluates what's been entered to that point.  It stays at 10 seconds until there's at least one rule in an Exact Match state.  At that point, the interdigit timer changes to 2 seconds.

For this set of rules, the timer stays at 10 seconds until the 7th digit has been entered.  Since 7 digits exactly matches the first rule, the timer would normally change to 2 seconds at that point.  Since 2 seconds is a bit short if you've got more digits to enter, such as a 10- or 11-digit number, S4 sets the timer to 4 seconds instead.  If you haven't entered anything else after 4 seconds, the DMP returns the 7-digit number.

The 8th digit you enter causes the first rule to change to the Mismatch state and the timer reverts to 10 seconds.  If you keep entering digits until you reach the 10th and the first digit is not a 0 or 1, it's assumed you've entered a 10-digit number starting with an area code.  Since this exactly matches the second rule, the timer would normally change to 2 seconds, but S0 sets the timer to 0 and the DMP returns the 10-digit number immediately, adding a 1 to the beginning.

If the first digit is a 1 and 10 more digits were entered behind it, the third rule is matched, the timer is forced to 0 and the DMP returns the 11-digit number immediately, unchanged.

If none of the first 3 rules are matched, the fourth rule matches whatever digits you've entered and the DMP returns them after 10 seconds.



Now let's look at the default LINE Port DigitMap:

(xxxxxxxS4|1xxxxxxxxxx|xx.)

This DigitMap has three problems:

1. 10-digit numbers.  Since they don't exactly match any of the rules, there's a 10 second wait for the DMP to return them.

2. 10-digit numbers.  A 1 is not added to the beginning of the returned number.

3. 11-digit numbers.  There's a 2 second wait that's totally unnecessary.



There you have it.  Are you still glad you asked?   :)

That is exactly what I though it said.

So if I dial **8 xxx xxx xxxx then rule 2 should apply.

But I still get a 15 - 17 second delay. Which is the same thing I get if I dial **8 1 xxx xxx xxxx

dealyanodeal

I am facing the same 20 seconds delay after dialing out so I will try the new digitmap tonight and report back the result.

@jimates.....good to see u here

OBi-Guru

It seems like there may be some issue with Sn (n = second) for honoring the delay.   Although it can't be that long like 20 seconds.
Our development team might have a fix in the upcoming release.

jimates

#14

This is the conversation from another forum that prompted this discussion.


Quote from: dealyanodeal;37987841@jimates. I got it all working now. As you had pointed out I reset the device and after that ooma automatically became primary as all other settings got wipred out. I then tried to setup sp1 for google but obitalk was already showing my prior setting and it didnt work. I deleted the device itself from obit talk and then added it back. Added sp1 as non primary and it all started working. I guess the key is to first set the primary line and have it working and then add the sp1.Also, only use obitalk or obiportal as i have seen using both kind of puts the system in limbo.

Latest problem....on OOMA line, .the lag between dial of last no. and the actual  ring is way too much.I timed it ..it is about 18-20 seconds which i think is not realistic for normal use. OOMA connected directly probably has 2-3 seconds. I am not sure if this lag can be reduced down by setting something......Please help.

and thanks for all your help.

Quote from: Mikeabcd;37988615Try dialing # after the number. It should cause the OBI110 to immediately process the number, pick up the line and send the dialed number using DTMF dial tones to the OOMA.

That said, the timeout on digits in the OBI110 is supposed to be 4 secs max with the default digit maps so I don't understand your far longer delay. I wonder if the OBI110 is stripping out something like the leading 1 on long distance and causing the OOMA to wait a long time.

Also, if you press # first when you pick up a phone connected to the obi, it will immediately connect you to the line port and send anything else you press immediately to the OOMA. You'll hear a brief pause after pressing # while the OBI switches you from its internally generated dial tone to the line port (OOMA) and the OOMA senses "off-hook" and starts generating its own dial tone.

For calls you want the OOMA to handle, pressing # first makes things more intuitive but requires a pause in speed dials on your phones between the initial # and the rest of the number. (if your phones have speed dial, OBI110 speed dialing is another thing).

Quote from: RonR;38002753The additional delays they're experiencing are probably not from the OBi.  They're probably the result of their telephone service provider being slow to set up the call and start giving them ringback.  Without careful investigation, it's difficult to tell where the source of the delay is.

Quote from: jimates;38007503In testing I found that my system also has the 20 second delay. I don't make any calls out on my line so I never knew it did that. As discussed on the Obitalk forum though, it didn't do that originally.

pressing # and getting a dial tone then dialing the number gives no delay. This indicates the delay is from the obi processing the call.

dialing **8xxx xxx xxxx results in a 20 second dealy. I can hear a click at 20 seconds when it happens. The ringing starts immediately after the click.
dialing **8xxx xxx xxxx # reduces the delay to 10 seconds from 20.

Quote from: RonR;38008091When you dial # (and get a direct dial tone) do you only dial 10 digits like you do when you use **8 on the OBi or do you dial '1' + 10 digits in that case?

Try:

**8 1 xxx xxx xxxx#

The default LINE port DigitMap does not add a leading '1' when you only dial a 10-digit number:

(xxxxxxxS4|1xxxxxxxxxx|xx.)

The OBi waits 10 seconds for another digit and finally places the call based on the 'xx.' rule (without adding a leading '1').

Now, your phone company probably does the same thing (waits to see if you're going to dial anything else).  If it sees '1' + 10 digits, it knows that's the complete number and immediately processes the call.

Quote from: RonR;38009195For those experiencing long delays when dialing out on the LINE Port, try changing:

Physical Interfaces -> LINE Port -> DigitMap

to:

(xxxxxxxS4|<1>[2-9]xxxxxxxxxS0|1xxxxxxxxxxS0|xx.)

This assumes the service provider on the LINE port expects or accepts 7-digit local numbers and 11-digit long distance numbers (1 + area code + 7-digit number).

You may dial long distance numbers from an OBi phone with or without a leading '1'.

Quote from: jimates
I only dial 10 digits when calling out on the LINE to anywhere in the US. Dialing a 1 first has no effect since the call starts immediately anyways. My provider has no delay.

Pressing # and then dialing 10 digits sends the call immediately - this pretty much eliminates any possibility that any part of the problem lies with the provider on that LNE.

**8 xxx xxx xxxx gets a 20 second delay
**8 xxx xxx xxxx# gets a 10 second delay
**8 1 xxx xxx xxxx gets ~ a 15 second delay
**8 1 xxx xxx xxxx# gets a 10 second delay

obi-support2

jimates,

Thank you for reporting the delays for different dialing patterns.

I can explain up to 15s of delay contributed by the OBi (assuming all default settings) when you dial 10 digits without ending # key. But I cannot explain your 20s delay. The extra 5s has to come from somewhere else?
As I read through the thread, it seems OOMA itself would contribute at least a few seconds (2-3 were mentioned in this thread). So I hope when you say "immediately" you mean a few seconds (up to 5s)?

For the OBi...
Dialing 10-digit w/o ending # -- Digit map delay is 10s
Dialing 1+10-digit w/o ending # -- Digit map delay is 2s
Dialing 10/11-digit w/ ending # - Digit map delay is 0s

In addition to digit map timers, the device needs extra time to "dial out" the 10 or 11 digit number. The additional delay comes from:
1. LINE Port - DialDelay (default 500ms)
2. LINE Port - DialDigitOnTime (default 200ms), for each digit
3. LINE Port - DialDigitOffTime (default 200ms), for each digit
So for 10-11 digits, the additional delay is about 5s.

So the differential with your delay measurements is 5s.
Hope this give you some more insight into this problem.
I can't really explain the extra 5s at this time.

-------------
Note that you can try to reduce DialDelay, DialDigitOnTime, and DialDigitOffTime
to say 200ms, 100ms, and 100ms respectively. Just check to make sure it works with your local phone company. The default values are chosen conservatively to make sure it works for most regions.

Also the S0 syntax at the end of a digit pattern is correct; but it will not work in the
current release (1.1); so it will still give you 2s delay as if it does not exist.
This problem is fixed in the upcoming 1.2 release (due out in 1-2 weeks).



OBIHAI Support Staff