reducing dialout delay on Obi110 over the LINE interface
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:
Quote from: lk96 on December 27, 2011, 10:52:00 am
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:
Quote from: lk96 on December 28, 2011, 09:57:08 am
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.
Quote from: lk96 on December 28, 2011, 09:57:08 am
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.
Navigation
[0] Message Index
[*] Previous page