reducing dialout delay on Obi110 over the LINE interface

[lk96]

Hello:

I have a configuration where an Obi110 device sits between my home phone handset
and a Vonage adaptor. So the connectivity is like:

PHONE -> Obi110 -> Vonage adaptor

The line copper interface from the Obi is connected to the phone port coming off the Vonage adaptor.
This allows me to have all home calls routed by default through the Vonage service. But also to be able
to redirect specific calls/number to lower cost SIP services (using the Obi).

The Obi110 is configured to use the LINE interface as the primary line out.

What I noticed though is that once I inserted the Obi device, when I try to dialout a number that is to be routed over the Vonage  service, there is significantly higher delay until the first ring back tone comes back.
Empirically it seems that the "extra" delay (compared to not having the obi in the chain) is around 4-5 seconds.

I also noticed that if a press "#" after the number that I dial, this extra delay is eliminated.

I searched around for the reason or a way to configure something that may reduce that delay without success.
Some of the Obi documentation (if I'm not mistaken) implies that for digits sent over the LINE interface
there is no significant delay added.

Anyone in this forum has any ideas of what may be the source of the delay? and if so, what may
be a way to eliminate it?

thanks

L.

[RonR]

Empirically it seems that the "extra" delay (compared to not having the obi in the chain) is around 4-5 seconds.

I also noticed that if a press "#" after the number that I dial, this extra delay is eliminated.

When you press #, the OBi bridges the PHONE Port directly to the LINE Port.  You are hearing LINE Port dialtone and sending DTMF tones straight through.

When you dial normally through the OBi, the OBi first collects the entire number and processes it through DigitMaps and an OutboundCallRoute in order to determine which trunk should be used for the call.  If the outbound trunk is the LINE Port, the OBi has to take the LINE Port off hook, wait 0.5 seconds to ensure dialtone is present, and then dial the number.  Each digit had a 0.2 second on-time followed by a 0.2 second off-time.  For an 11-digit number, that totals about 4.9 seonds.

[Stewart]

@RonR,

Something doesn't jive here.  I believe that the OP was describing the effect of the interdigit timeout:

I also noticed that if a press "#" after the number that I dial, this extra delay is eliminated.

However, the delays you described are also present, so the total (compared with OBi out of system) would be almost ten seconds.

@lk96,

Is this a temporary setup, i.e. you would replace Vonage with a lower cost provider, once the OBi is proven?  If so, the delay may be just a minor issue.  OTOH, if you'll be keeping Vonage, you should probably adjust your digit maps, so that dialing # won't be necessary in most cases.  For domestic calls, you can set it up to use 7 digits (local) and 11 digits (out-of-area), or to use 10 or 11 digits for all calls.  If you want both 7 and 10 digit dialing, there is no way (other than pressing #) to avoid the delay on 7 digit calls.

[RonR]

@RonR,
Something doesn't jive here.  I believe that the OP was describing the effect of the interdigit timeout:

I also noticed that if a press "#" after the number that I dial, this extra delay is eliminated.

However, the delays you described are also present, so the total (compared with OBi out of system) would be almost ten seconds.

It does compute : 0.5 + 11 x (0.2 + 0.2) = 4.9 seconds

One can play with DialDelay, DialDigitOnTime, and DialDigitOffTime, but the small difference that can be achieved probably isn't worth the instability it may cause.

The default LINE Port DigitMap:

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

contains an indefinite match rule (xx.) that will introduce an extra 2 seconds of delay (or 10 seconds when dialing a service number such as 411) that can be eliminated by pressing the # key.

I always recommend replacing the default LINE Port DigitMap with something like:

Physical Interfaces -> LINE Port ->  DigitMap : ([2-9]11|[2-9]xxxxxx|1xxxxxxxxxx)

which will eliminate the extra delay if dialing is not terminated with a # key.

This assumes 7- and 11-digit dialing.  If 10-digit dialing is needed, then a slightly different variation can be used.

[lk96]

@RonR,

Something doesn't jive here.  I believe that the OP was describing the effect of the interdigit timeout:

I also noticed that if a press "#" after the number that I dial, this extra delay is eliminated.

However, the delays you described are also present, so the total (compared with OBi out of system) would be almost ten seconds.

@lk96,

Is this a temporary setup, i.e. you would replace Vonage with a lower cost provider, once the OBi is proven?  If so, the delay may be just a minor issue.  OTOH, if you'll be keeping Vonage, you should probably adjust your digit maps, so that dialing # won't be necessary in most cases.  For domestic calls, you can set it up to use 7 digits (local) and 11 digits (out-of-area), or to use 10 or 11 digits for all calls.  If you want both 7 and 10 digit dialing, there is no way (other than pressing #) to avoid the delay on 7 digit calls.

This  is more like the fingal config with Vonage being the "default" household line and for those in the household
that don't want to be bothered with * and # codes

I do need the Obi for making low cost calls to mobiles to Europe and Asia for my own work/business,
through low cost SIP providers.

I haven't spent time familiarizing myself with the Digitmaps and route rules but will do shortly.
I should clarify that most of my calls are either 11 digit or 15 digit ones (international). So I don't have much
need/use to optimize for 7 and 10 digit numbers.

So optimizations will be needed for 11 and 15 digit numbers only.

thanks

L.

[RonR]

So optimizations will be needed for 11 and 15 digit numbers only.

If the call is processed by the OBi, there's no way to significantly shorten the re-dialing delay the OBi introduces.  For an 11-digit number, this is 4.9 seconds.  For an international call, each additional digit will add 0.4 seconds, plus there will be an extra 2 second timeout if you don't terminate the dialing with a # key.

The only way around this is to totally bypass the OBi by first pressing the # key to get a direct connection to the LINE Port.

[lk96]

I took a quick look at the DigitMaps syntax.
Please let me know if my understanding on when digits are "played out" is correct.

In my case I want to optimize for the following cases so I was thinking that something like
the following is as good as it gets:
1xxxxxxxxxxS0 (11 digits)
011 xxx xxx xxx xxxS0 (15 digits)
00 xx xxx xxx xxx xxxS0 (14 digits)

The last two cases have to do with whether the SIP provider supports a 00<country code> prefix for
international calls or a 011<countrycode> prefix.

When exactly will the Obi determine that the call needs to be directed to the LINE interface,
take the line off-hook and start playing out? at the point that a partial match is unambiguous?
or when the full set of digits are entered ? For example, when I enter "011", isn't that
a unambiguous hint that calls goes to LINE?

thanks again for your continuous clarifications

L.

[lk96]

or may be to rephrase my question in the previous post:

is there an explicit way to direct the Obi to go off hook as soon as
its determined that an international call is being placed (ie when 011 is dialed),
but without waiting for the complete number to be entered ?

thanks

L.

[RonR]

The OBi will not touch the LINE Port until the entire number is dialed.  The addition of special rules for 14- and 15-digit numbers will eliminate the delays incurred with indefinite match rules if you don't terminate dialing with a # key, but the redial delay of 0.5 seconds for dialtone plus 0.4 seconds per digit cannot be circumvented.

[lk96]

What about a different approach:

if I want to automate the process of dialing a "#" before dialing anything so that LINE is connected to my
Vonage adaptor, can I enter a: <S2:#> rule? (ie if not digits are entered, dial # which will cause
LINE to go off hook ?

thanks

[RonR]

That would mean you'd pick up the phone, hear OBi dialtone, have to wait 2 seconds for a LINE Port dialtone, and then dial your number.  I haven't thought it through and can't test it here, but give it a try and see if it does what you want.

To dial anything else, you'd have to begin within 2 seconds instead of the normal 10 seconds or else it would go out the LINE Port.

[lk96]

yes, that was pretty much the intent. The 2sec wait time can be adjusted
but it was just a placeholder to indicate how long someone takes between
taking the handset off hook and dialing the first digit. And at the same
time I wanted it to be reasonably long to allow me to dial **1 for using a different
SIP line when I need to.

I'll try it to tonight when I'm back home and report back.

The only thing that can be tricky though is whether between switching from
the obi generated dialtone to the Vonage adaptor generated dial tone, any digits are "lost".

L.

[RonR]

The only thing that can be tricky though is whether between switching from
the obi generated dialtone to the Vonage adaptor generated dial tone, any digits are "lost".

You shouldn't be dialing any digits until you hear the Vonage adapter dialtone, so there shouldn't be any possibility of any digits getting lost.

While this will probably work, the idea of having to train other household members (or tell visitors using the phone) that they have to wait for a second dialtone before dialing is too kludgey for me.  It's just not worth the trouble to save 3 seconds of dialing delay (a 2 second wait versus a 4.9 second delay).  Plus you have to be very quick if you want to use an alternate trunk.  Yuk.

[lk96]

Here is some measurements as an FYI with a possible issue to flag:

When I enter the <S2:#> rule, it seems that the DMP goes first into the "long" interdigit timeout.
So, the "#" is sent only after around 12 seconds (10sec is the long interdigit timer setting as per the documentation+2 secs for the delay I added through the S2 rule). So this option is out (on top of agreeing to your comments that the overall setup gets cludgey.

I also made some other measurements by ringing a specific international number in Europe by entering
a 15 digit number. I started making the measurements after I dialed that number a few times
to make sure that any intermediate softswitches and routers have cached route information.
Below are configurations/rules and the time it takes to get the ring back tone:

+ default digit map: 16.5 seconds
+ default digit map and entering # after number:  7secs
+ modified digit map as: "011xxxxxxxxxxxxS0": 7secs
+ modified digit map as: "011xxxxxxxxxxxx":     9 secs


The 2nd and 3rd entry seem about right as per your previous calculations: it takes about
5 secs to play out the digits with default tone durations. And it takes couple secs for my
phone provider to dial out and send back the ring back tone.

The 4th entry seems also consistent with 2nd and 3rd: since I didn't add the S0 rule, a default
2 sec interdigit timer will be fired before the digits start being played out.

The 1st entry though seems excessively long. So Stewart was right that something doesn't seem right.
It looks to me that when the "xx." rule is matched, the long interdigit timer is fired which adds
about 10sec delay before the digits will start being played out. When I scanned through the documentation
I thought that once a digit is entered, the short interdigit timer applies but I may have misunderstood. 
It's certainly not obvious to me why the long timer is triggered in this case. May be someone would like
to take a look in this.

BTW, I did try to shorten the tone duration on/off intervals to 120msec ON and 80msec OFF.
These values are 2x or 3x the values required by the standards. I'll keep monitoring this change though
for any side effects. Naturally, the interval to get a ring back tone was reduced to about 4.5 secs in this case
and this is certainly very acceptable.

L.

[RonR]

When I enter the <S2:#> rule, it seems that the DMP goes first into the "long" interdigit timeout.
So, the "#" is sent only after around 12 seconds (10sec is the long interdigit timer setting as per the documentation+2 secs for the delay I added through the S2 rule). So this option is out (on top of agreeing to your comments that the overall setup gets cludgey.

I did some testing yesterday and <S2:#> worked as expected for me but only when used from the PHONE Port DigitMap.  It appeared to be ignored when used in an unconditionally referenced DigitMap (such as the LINE Port DigitMap when the PrimaryLine is set to PSTN Line), but maybe I wasn't patient enough.  This appears to be a bug in the DMP.  I emailed Obihai about it but haven't received a reply.

The 1st entry though seems excessively long. So Stewart was right that something doesn't seem right.
It looks to me that when the "xx." rule is matched, the long interdigit timer is fired which adds
about 10sec delay before the digits will start being played out. When I scanned through the documentation
I thought that once a digit is entered, the short interdigit timer applies but I may have misunderstood. 
It's certainly not obvious to me why the long timer is triggered in this case. May be someone would like
to take a look in this.

For the short timer to be used on an Indefinitely Matched rule, there must be at least one rule in the Exactly Matched state.  Since there was no rule in the Exactly Matched state, the long timer was used.