site Search:


 
    All Forums Hot Topics Gallery






how-to block ads


 
Search Topic:
Uniqs:
1108
Share Topic
Posting?
Post a:
Post a:
Links: ·ALL ·Review Your VoIP Provider ·VoIP Providers ·VoIP FAQ ·Porting Rules ·What Codec?
AuthorAll Replies


DracoFelis
Premium
join:2003-06-15

Using a different VT servers for 10 vs 11 digit dialing.

On those occasions when VT is having problems (which isn't very often, but still), sometimes VT has only some of their servers. For example, this recent thread discussed problems that some of us recently had with servers in the Chicago region:

»Can't call out... Delay then slow busy signal

Which got me to thinking... Wouldn't it be nice if we could setup our adapters to easily be able to pick a different VT server, if/when there seems to be a problem calling out on the primary? Then it hit me, we can!

LinkSys/Sipura adapters (which include both the SPA-3000 I use as a BYOD customer, and the PAP2 that VT supplies) allow you to specify the "proxy" (server) for a dial plan pattern match in the dial plan itself (and this proxy, if/when specified for the pattern, overrides the normal proxy/server for the line if/when that pattern matches). But, it will still attempt to use your normal login credentials from the line.

The practical upshot of this, is that by simply modifying your dial plan (which you will need the admin password for your adapter to do), you can have multiple ways to dial that are each slightly different, and each will call out using a different VT server (you setup in the dial plan). For example, you could have 11-digit dialing (1-area-number) use one VT server, but have 10-digit dialing (area-number) use a different VT proxy. So if you normally dial one way and you are having trouble calling out, just switch to the other dialing and you will use a different proxy (after setting this up in your adapter). This still won't provide full fault-tolerance for inbound calls (IMHO that's what the network down phone number is for in the control panel), but this will give you an easy "manual" way to go to a backup server on outbound calls. I just tested this theory on my adapter, and it appears to work as expected!

Here's how to set up these multiple outbound VT servers in your adapter:

1) Log into your adapter as "admin" and "advanced".

2) If you are using a VT provisioned adapter, you will want to turn off provisioning (on the "Provisioning" tab), or VT's web site will override your adapter settings.

3) On the "Line 1" tab, setup the Line with the proxy/server (and account info) you want to use for default dialing out, and for all inbound calls. In many cases this will already be setup correctly, as you are (after all) already using your adapter with VT.

4) Pick an alternate proxy/server (in a different geographical area) from the list of VT servers, that you wish to use for your alternate dialing sequence:
»Updated Server List

5) Look at your dial plan (on the "Line 1" tab). With luck it will already have dial plan pieces to handle 10 and 11 digit dialing. If not, add them into the dial plan, and save:
10-digit dialing piece:
<:1>[2-9]xx[2-9]xxxxxxS0
 
11-digit dialing piece:
1[2-9]xx[2-9]xxxxxxS0
 
NOTE: Case if important. It has to end with "capitol-S zero"

6) Decide which of the above dialing methods should use the alternate proxy/server (that you picked in step 3), and modify that dial plan piece to point to the alternate proxy. For example, if you wish 10-digit dialing to use the alternate proxy, and you picked "houston-1a.vtnoc.net" as your alternate proxy, you would replace the 10-digit dial plan piece with the following:
<:1>[2-9]xx[2-9]xxxxxxS0 <:@houston-1a.vtnoc.net>
 
i.e. The LinkSys convention to override the server for a single dial plan piece, is to append that dial plan piece with: ""

7) Save the changes to the dial plan, and then reboot (power cycle) your adapter.

8) At this point (if you setup everything correctly), you should be using one server for inbound and "normal" calls, but just switch to the other way to dial to use your alternate server. In my case my alternate server is gotten using 10-digit dialing (with my normal server for 11-digit dialing and inbound call), but you could just as easily reverse those conventions (if you are more used to 10-digit dialing). And you could even expand this further, if you wanted, to allow even more ways to dial. For example, the following dial plan piece (if it were added to your dial plan) would send the call out via "richmond-1a.vtnoc.net", if/when you dial an extra 1 in front of the number (i.e. 11-area-number):
<1:>1[2-9]xx[2-9]xxxxxxS0 <:richmond-1a.vtnoc.net>
 

Hope this little dial plan trick helps some of you out there. Yes, I know that dial plans are a bit "techy" for some, but its amazing how much you can do when you customize them. And this little "trick" is just one way to easily use a different VT server as your backup for your primary VT server. And once you make this dial plan change to your adapter, it's setup. At that point, you simply need to dial differently from your phone (for example, using 10 digits to pick the alternate server, if you normally dial with 11), and out the call with go via your chosen alternate VT server)!


burris
Premium
join:2000-08-22
Miami, FL
Reviews:
·VOIPo

I admire your ideas, but in the end result, "What's it all about, Alfie."

This is like asking a passenger on an airplane to bring his tools, so when the plane runs into problems over the Atlantic Ocean, he can try to find some alternative ways to keep it frrom crashing.

Is this anyway to run a business?


Russell_

join:2006-04-06

said by burris:

I admire your ideas, but in the end result, "What's it all about, Alfie."

This is like asking a passenger on an airplane to bring his tools, so when the plane runs into problems over the Atlantic Ocean, he can try to find some alternative ways to keep it frrom crashing.

Is this anyway to run a business?
While not disagreeing with what you're saying Burris, I thought it was rather ingenious and the solution appealed to the geek in me. The OP has issues and if this workaround works for him and gives him greater reliability - great!
--
Russell


burris
Premium
join:2000-08-22
Miami, FL
Reviews:
·VOIPo

said by Russell_:

said by burris:

I admire your ideas, but in the end result, "What's it all about, Alfie."

This is like asking a passenger on an airplane to bring his tools, so when the plane runs into problems over the Atlantic Ocean, he can try to find some alternative ways to keep it frrom crashing.

Is this anyway to run a business?
While not disagreeing with what you're saying Burris, I thought it was rather ingenious and the solution appealed to the geek in me. The OP has issues and if this workaround works for him and gives him greater reliability - great!
I too, thought his idea was interesting, but it would be difficult to teach this to my wife.

On the other hand, what I am beginning to see in quite a few threads, has to do with basic functionality of the service.
I cannot believe that only geeks migrate to VOIP in order to be able to tweak away.

Again, my service has worked well and if ever it does not, I don't intend to spend my time tweaking just to maintain a measure of connectivity.

I think that only a very small number of users post about esoteric problems, if they post at all, they way some of us might. I'm not sure they are even aware of subtle problems, maybe because VOIP is their secondary service, or the price is so attractive that they roll with the punches. I don't know.


DracoFelis
Premium
join:2003-06-15

reply to burris

said by burris:

This is like asking a passenger on an airplane to bring his tools, so when the plane runs into problems over the Atlantic Ocean, he can try to find some alternative ways to keep it frrom crashing.
I'm not a ViaTalk employee, just a user. A "geeky" user, yes, but still just a user of theirs.

I started this thread primarily because I thought of that solution as a clever "backup", and thought some of the other "geeks" in this forum might agree. As to the non-geeks in this forum, they are more than welcome to skip over this thread.

As to me, I've already made this change (to my configuration), and so I really didn't need to take the time to post this stuff. I just thought some others might like to hear about this trick. And even without that "trick" I already had multiple other ways to make a call (and did in fact use one of those other "backups" during the recent Chicago area VT glitches). So I'm covered, and having VT be a "backup" to itself (i.e. letting me choose different VT servers, so that my account still works if/when VT only has a partial outage) is just "icing on the cake" as it were. But it is "icing" that appeals to the geek in me. So I thought some other geeks might like to hear about it as well...


DracoFelis
Premium
join:2003-06-15

reply to burris

said by burris:

I too, thought his idea was interesting, but it would be difficult to teach this to my wife.
I never try to explain the geeky details of setting up the adapter to my wife. I just do that myself, and then explain to the wife how to use the phone (with the adapter already setup correctly).

And the beauty of this "trick", is that the ONLY THING you need to teach the wife, is that area-number and 1-area-number call out slightly differently. So if one stops working for some reason, just try the other and your call might go through...

Everything beyond that, is just the details of how you setup your adapter to provide this redundancy. But once this adapter change is make, anyone in the house can take advantage of it by knowing that 1-area-number and area-number dialing often don't stop working at the same time. So when one is out, try the other to see if the call goes though!


burris
Premium
join:2000-08-22
Miami, FL
Reviews:
·VOIPo

said by DracoFelis:

said by burris:

I too, thought his idea was interesting, but it would be difficult to teach this to my wife.
I never try to explain the geeky details of setting up the adapter to my wife. I just do that myself, and then explain to the wife how to use the phone (with the adapter already setup correctly).

And the beauty of this "trick", is that the ONLY THING you need to teach the wife, is that area-number and 1-area-number call out slightly differently. So if one stops working for some reason, just try the other and your call might go through...

Everything beyond that, is just the details of how you setup your adapter to provide this redundancy. But once this adapter change is make, anyone in the house can take advantage of it by knowing that 1-area-number and area-number dialing often don't stop working at the same time. So when one is out, try the other to see if the call goes though!
A good idea..but could VT set this up for those adapters that have a second line active, and could they put it into their provisioning registration?


DracoFelis
Premium
join:2003-06-15

said by burris:

A good idea..but could VT set this up for those adapters that have a second line active, and could they put it into their provisioning registration?
Yes, and yes. i.e. Yes, the same idea should work with both lines active (you would just customize the dial plans of both lines in that case, instead of just customizing the dial plan on one line), and yes their provisioning system should (at least in theory) be able to handle this change (as this is just a config change made with the admin password, and provisioning should be able to push any such changes to the end user's adapter).

What I don't know however (as I don't work for VT, and have no actual access to their provisioning server), is how easy it would be to tweak VT's user profiles (on their provisioning server) to push this sort of change to end users. What I know about provisioning as an end user says it should be doable (as LinkSys VoIP adapters, such as the PAP2, allow virtually all configuration changes to be "provisioned" remotely). But I don't know how much work it would be for them to setup such a profile change on their end.


dcurrey
Premium
join:2004-06-29
Reviews:
·RoadRunner Cable
·ViaTalk

3 edits

reply to DracoFelis
Thats a neat idea.

Would a star code work to trigger it?

Something like

*23[2-9]xx[2-9]xxxxxxS0 <:richmond-1a.vtnoc.net>
 
or better yet just
**[2-9]xx[2-9]xxxxxxS0 <:richmond-1a.vtnoc.net>
 

Added into the plan. Both work for 10 digit dialing not including the * stuff.

Also would need to make sure *23 doesn't conflict with anything. Didn't check.


DracoFelis
Premium
join:2003-06-15

1 edit

said by dcurrey:

Thats a neat idea.

Would a star code work to trigger it?
Sure, you could use just about any trigger you wanted (that's the beauty of LinkSys VoIP adapter dial plans, like the PAP2 uses). I just figured the natural trigger of 10 vs 11 digit dialing would make more sense to the family (and be easier to remember) than some * code.

said by dcurrey:


Something like
*23[2-9]xx[2-9]xxxxxxS0

or better yet just
**[2-9]xx[2-9]xxxxxxS0
I think the forum ate the angled brackets in your examples. Which is why I always enclose dial plan examples in "code" blocks on this forum (to prevent the forum software from eating some of the key characters). Did you perchance mean something like the examples below? If so, than yes both ideas should work (choose the alternate VT server of your choice in the dial plan pieces below) if you prefer to trigger this from a *code from your phone.
Something like
<*23:1>[2-9]xx[2-9]xxxxxxS0 <:@chicago-1a.vtnoc.net>
 
or better yet just
<**:1>[2-9]xx[2-9]xxxxxxS0 <:@newyork-1a.vtnoc.net>
 


dcurrey
Premium
join:2004-06-29

1 edit

Thanks forgot that time. Fixed it above.

Edit: Would the first part of sting need the brackets? Or is the one I have correct?

Soon as I can I will get my server logging the pap so I can see what happens.



CyberSultan
Premium
join:2006-07-20

1 edit

This one would work as well:

<**, :>1xxx[2-9]xxxxxxS0 <:@newyork-1a.vtnoc.net>
 

This would allow you to not have to replace your current 11-digit dialing plan. The ** would trigger this portion of the dialing plan without transmitting the **. I also included a "," in mine, which creates an outside dialing tone after entering the ** if you press hook/flash before dialing the number. If you like to type in your phone number without hitting hook/flash first, it won't hurt anything.


dcurrey
Premium
join:2004-06-29
Reviews:
·RoadRunner Cable
·ViaTalk

1 edit

Thanks.

This is what I added. Logs show it working.

<**, :>[2-9]xx[2-9]xxxxxxS0 <:@richmond-1a.vtnoc.net>
 

Other than second dial tone why add the ",". I tested it without it and it works correctly. All calls show up in the logs as "Calling:513XXXYYYY@richmond-1a.vtnoc.net:0"

Edit: BTW I use 10 digit dialing.


CyberSultan
Premium
join:2006-07-20

1 edit

said by dcurrey:

Other than second dial tone why add the ",". I tested it without it and it works correctly. All calls show up in the logs as "Calling:513XXXYYYY@richmond-1a.vtnoc.net:0"
Correct. You don't need the "," to make it work. I just added it for the second dial-tone.

Edit: Now, if you setup each VT line (assuming you are using the 2-line feature) on a separate server...and add something like this to each line's dial plan (referencing a different proxy in each of the two dial plans), that would setup a bit of redundancy.


DracoFelis
Premium
join:2003-06-15

1 edit

reply to dcurrey

said by dcurrey:

Thanks forgot that time. Fixed it above.

Edit: Would the first part of sting need the brackets? Or is the one I have correct?
Even the edited one you have would NOT work, as your initial trigger is outside of angled brackets. Which means that not only will those keystrokes be used to trigger that dial plan piece, those same trigger keystrokes would be sent to VT (which wouldn't know how to deal with your trigger keystrokes).

So you really do need to enclose your initial trigger sequence with both the angled brackets and the colon. The convention for LinkSys VoIP adapters is that dial plan pieces between angled brackets, which also include a colon, are treated as follows:

1) Anything before the : is included as something you dial (to match the pattern), but is NOT sent to the remote end (in this case ViaTalk). This is why you want your "trigger" before the colon (but still enclosed in angled brackets).

2) Anything after the : is sent to the remote end, even though you didn't type it in (at the phone). This is why the proxy override is after a colon. It's also why I prefer to use an initial colon 1 (inside angled brackets) for 10-digit dialing patterns (because it actually then sends 11-digits to the far end, even though you only keyed in 10 on the phone).

3) Either side of the colon is optional (i.e. can be blank). When you only have a pattern before the colon (in those angled brackets) you are just doing a dialing trigger. When you only have a pattern after the colon (again within angled brackets) you are doing an insert (send these extra entries to the remote end). For angled brackets with patterns on both sides of the colon you are doing a replace (i.e. phone user types in the thing before the colon, but the adapter actually send the thing after the colon).

Which means what I think you really want to do with your 10-digit dialing examples is:
<*23:1>[2-9]xx[2-9]xxxxxxS0 <:@richmond-1a.vtnoc.net>
 
or better yet just
 
<**:1>[2-9]xx[2-9]xxxxxxS0 <:@richmond-1a.vtnoc.net>
 
NOTE: Those examples assume trigger-area-number dialing (i.e. trigger + 10 digit dialing), and actually send the call out to the alternate VT server in the 1-area-number format (even though you never actually type the initial 1 in, the adapter dial plan piece adds it for you before sending to the VT server, so the VT server always sees 1-area-number). i.e. The initial angled brackets (in those dial plan pieces) are being used to replace the trigger with an initial 1, before sending those digits off to VT (with the alternate server)...

Edit: Added a missing @ character to the dial plan examples in this post.


no_one

@DNVR.QWEST.NET

reply to burris

said by burris:

I admire your ideas, but in the end result, "What's it all about, Alfie."

This is like asking a passenger on an airplane to bring his tools, so when the plane runs into problems over the Atlantic Ocean, he can try to find some alternative ways to keep it frrom crashing.

Is this anyway to run a business?
The basic service works for me. Knock on wood. Found a stable for me server and all ok. Wife even uses it for local calls sometimes. We still have a POTS line also. But I did partly or mostly chose Viatalk on two things. Cheap cost and the geek factor of being allowed to learn VOIP. So thanks to the OP for this thread.
But to me for VOIP to survive it will of course need to be stable but have a geek factor. Without that then just bundle the phone with your dsl/tv/cable package.


burris
Premium
join:2000-08-22
Miami, FL
Reviews:
·VOIPo

said by no_one :

said by burris:

I admire your ideas, but in the end result, "What's it all about, Alfie."

This is like asking a passenger on an airplane to bring his tools, so when the plane runs into problems over the Atlantic Ocean, he can try to find some alternative ways to keep it frrom crashing.

Is this anyway to run a business?
The basic service works for me. Knock on wood. Found a stable for me server and all ok. Wife even uses it for local calls sometimes. We still have a POTS line also. But I did partly or mostly chose Viatalk on two things. Cheap cost and the geek factor of being allowed to learn VOIP. So thanks to the OP for this thread.
But to me for VOIP to survive it will of course need to be stable but have a geek factor. Without that then just bundle the phone with your dsl/tv/cable package.
Do you really think that VOIP won't survive without a geek factor or without 5,000 features?

Fortunately, for whatever reasons, I don't seem to have the problems that appear in the postings. I do have the VT supplied adapter and I leave provisioning on. I have tried a few tweaks like dial plan, and when I found what worked for me, I called and they hard coded it for me.

Cost is certainly a factor and I don't see the cable/dsl triple play as a bargain, and there's no tweaking, and the reliability is related to the integrity of the packet provider.

The reality is, and I'll bet it's true for most couples, if I die before my wife, she will be back on POTS before the body is cold, and I won't be around to make excuses.



dcurrey
Premium
join:2004-06-29
Reviews:
·RoadRunner Cable
·ViaTalk

reply to DracoFelis
Thanks but do have a working plan. (See above). Didn't want to change the original post again in order not to confuse anyone on the question about the brackets.

Really appreciate the detailed explanation as to what is actually going on with the dial plan.



dcurrey
Premium
join:2004-06-29
Reviews:
·RoadRunner Cable
·ViaTalk

2 edits

reply to CyberSultan

said by CyberSultan:

Edit: Now, if you setup each VT line (assuming you are using the 2-line feature) on a separate server...and add something like this to each line's dial plan (referencing a different proxy in each of the two dial plans), that would setup a bit of redundancy.
Depending on how long the dial string accepts you can add multiple servers using star codes

Example
<*23, :>[2-9]xx[2-9]xxxxxxS0 <:@newyork-1a.vtnoc.net>
<*24, :>[2-9]xx[2-9]xxxxxxS0 <:@richmond-1a.vtnoc.net>
 

Getting a bit extreme but should work. This gives me my default chicago server with 2 backups using *23 and *24.

I think 1 should be plenty. :)

Edit: I don't know what it is with my and entering code but that should be 1 line with the "|" between them not a return.

LottaMoxie

join:2007-06-04

reply to DracoFelis
Well I for one LOVE this. I'm a bit of a geeky gal myself so I appreciate learning these workarounds. I'm going to bookmark this so I can get back to it and try it out for myself.

When I first signed up on VT I was given the NY-2 server to use (I'm BYOD). But that one eventually experienced so many issues that I had to start changing around to find one that would be stable (certainly a challenge). Now I'm on one of the Chicago servers. I had my best quality in those early days on NY-2 before all the problems started in the past 3 - 4 months.


Tuesday, 29-May 11:15:29 Terms of Use & Privacy | feedback | contact | Hosting by nac.net - DSL,Hosting & Co-lo
over 12.5 years online © 1999-2012 dslreports.com.
Most commented news this week
Hot Topics