News:

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

Main Menu

triggering a callback without Obi answering the call

Started by lk96, January 08, 2012, 08:29:49 PM

Previous topic - Next topic

RonR

Quote from: lk96 on January 14, 2012, 07:59:11 PM
How can I instruct the Obi to use a VG or a trunk *other* than the SP1 and SP2 to dial out the destination number ?

Using OBi Voice Gateways with SIP Providers

lk96

I'm absolutely positively shocked/impressed with both the quality of the responses
and the flexibility/power of the device.

thanks much !

L.

lk96

So thanks to RonR and Stewart's suggestions I have a well setup configuration
where callbacks are configured to also use VGs. Additionally I have freed up an SP trunk
after the clarification that a lot of voip providers don't require SIP registration.

I have also obtained a free incoming DID from ipkall (I didn't realize that I could
forward an ipkall-obtained DID to my obi without going through another voip provider - thanks RonR
for a posting demonstrating that) (Note: when I dial the DID I got from ipkall from my cell phone
i get a ringback tone and the obi calls back as expected. However when I call the DID ipkall #
from my office phone (corporate phone but with a direct #) I get a busy tone and the Obi also
doesn't show any record of incoming calls. Not sure why this is so).

My next step is to look into Voxbeam. Voxbeam requires a real IP address (not DNS name)
to be used.

Stewart: you mentioned something about a script to do that automatically. Can you please share?
What kind of platform it runs on?

I really don't know how often my public IP address changes. For sure it changes when there
are service/device failures/reboots. I believe that in my case the address doesn't change otherwise.
But Mr. Murphy is sure to hit when I'll be traveling and when I need this to work urgently.

thanks

L.

Stewart

I posted the Voxbeam update script at http://www.dslreports.com/forum/r26795392-script-for-Voxbeam-on-dynamic-IP-address .  You may need to register to download the attachment.

I got another IPKall account and PMed you the number.  It points to 883510000000093@sip.inum.net (caller ID test).

lk96

Stewart: I downloaded and will install on a new Mac server I'm setting up. Thanks much.

I do have couple of issues and questions for Voxbeam though. I have set up an account with them.
But all calls are rejected. Here is what I have:

SIP server: sbc.voxbeam.com
port: 5060
user: mylogin@gmail.com
password: mypassword
no STUN server is configured.

I dialed trying either the standard or premium access lines (ie 0011101 and 0011103 prefixes).
The Obi reports: Register Failed: 500 Method not allowed (server=95.211.119.251:5060; retry in 25s)

In addition to the above I do have couple more questions:
1. what do I need to do to spoof a caller ID of my choice when using Voxbeam?
enter it in URI? or any other mechanism?

2. I'd like to simplify the dialed digits when using the Voxbeam trunk and to normalize the
dialing to that of other services (this is mostly for my other "customers" in the house that
have little tolerance for new dialing habits). So suppose I want the following:

if I dial on the handset **2 011 nn 1234567890 (nn=country code), the obi
converts it to appropriate # for the voxbeam trunk that will look like:
0011101 nn 1234567890

3. Does Voxbeam require SIP registration or just authentication ?

thanks

L.


lk96

I edited previous posting to correct the info that the Obi was not registering with Voxbeam actually.
Obitalk was saying one thing but when I went to the device itself it was giving me the real error.

L.

RonR

Quote from: lk96 on January 21, 2012, 11:13:52 AM
I dialed trying either the standard or premium access lines (ie 0011101 and 0011103 prefixes).
The Obi reports: Register Failed: 500 Method not allowed (server=95.211.119.251:5060; retry in 25s)

Have you listed your IP address at Voxbeam?:

Authentication

Authenticating your calls with Voxbeam couldn't be simpler; all that we need to know is the IP address(es) that you'll be sending calls from. You can add and remove IP addresses at any time using your Voxbeam account's settings page.

Quote from: lk96 on January 21, 2012, 11:13:52 AM
2. I'd like to simplify the dialed digits when using the Voxbeam trunk and to normalize the
dialing to that of other services (this is mostly for my other "customers" in the house that
have little tolerance for new dialing habits). So suppose I want the following:

if I dial on the handset **2 011 nn 1234567890 (nn=country code), the obi
converts it to appropriate # for the voxbeam trunk that will look like:
0011101 nn 1234567890

The following will prepend 0011101 to all calls sent using SP2:

Service Providers -> ITSP Profile B -> General -> DigitMap:

(<0011101>(1xxxxxxxxxx|<1>[2-9]xxxxxxxxx|<1aaa>[2-9]xxxxxx|<011:>xx.)|(Mipd)|[^*#]@@.'@'@@.)

where aaa is your local (US) area code.

Stewart

In addition to what RonR posted, please note:

1. Voxbeam will not accept a registration (there is no need, as they don't sell phone numbers or incoming service of any kind).  So, if you put them in SP1 or SP2, turn off X_RegisterEnable for the service.

2. Voxbeam requires proper NAT mapping.  In your setup, that does need STUN.  Set STUNEnable and set a working STUN server in STUNServer (mine is currently set to stun.ekiga.net).


lk96

Quote
Have you listed your IP address at Voxbeam?:
Yes, I had done that couple days back when I opened the Voxbeam account. And
verified that my public address matches the one I entered on my Voxbeam account.

Quote from: Stewart on January 21, 2012, 12:05:12 PM
In addition to what RonR posted, please note:

1. Voxbeam will not accept a registration (there is no need, as they don't sell phone numbers or incoming service of any kind).  So, if you put them in SP1 or SP2, turn off X_RegisterEnable for the service.
Interesting they are doing strict checking. I have now disabled that option so
the Obi is not attempting to register.

Quote
2. Voxbeam requires proper NAT mapping.  In your setup, that does need STUN.  Set STUNEnable and set a working STUN server in STUNServer (mine is currently set to stun.ekiga.net).

I have done so as per your suggestion.

After taking care of all of the above, I still get  "fast" rejection of any calls I try to make over
the SP2 trunk where I placed the Voxbeam account.

Any other ideas or things to check?

L.

Stewart

Quote from: lk96 on January 21, 2012, 09:04:56 PM
After taking care of all of the above, I still get  "fast" rejection of any calls I try to make over
the SP2 trunk where I placed the Voxbeam account.

Any other ideas or things to check?
Look at Call History, both for what error you got, and whether the correct number was sent to Voxbeam.

lk96

I got it working now.
Apparently the problem had to do with the fact that my login name
at the voxbeam site and the name that the SIP service was expecting are different.

on the voxbeam site my login is: myname@gmail.com

However, when I setup the SP2 voice service, I need to use only the "myname" part (and remove the @gmail.com).

In any case this is working now. I also noticed that if I enter my desirable caller ID
in the URI, the caller ID is delivered appropriately.

Tomorrow, will work to setup the dialing rules and simplifications as described by RonR
so that I have a unified dialing plan for the house users.

thanks much to both of you again for your help.

L.

lk96

In case someone is interested in some subjective and relatively simple voice quality assessment
of EasyVoip vs VoxBeam ...

I did couple of test calls where I used a callback from Obi to one of my two cell phones (which
is with Tmobile). Then from the AA I dialed out to my second cell phone (that is with AT&T).

I tried two basic scenarios. In scenario #1, the calls were connected over EasyVoip.
In the second case the calls went over Voxbeam.

So the call paths were like this:

Scenario #1: mobile #1 <----(over Easyvoip) ---> Obi <---(over EasyVoip) ---> mobile #2
Scenario #2: mobile #1 <----(over Voxbeam) ---> Obi <---(over Voxbeam) ---> mobile #2

I did a wall clock measurement of the voice latency from mobile #1 to mobile #2 in each case.
In the first scenario, the latency was really high ... about 1sec or a bit over 1sec.
In the 2nd scenario the latency was a bit less than 500msec. Measurements were subjective
based on simple listening.

Given that the call was from Mobile to mobile, it is estimated that even without any network
delay, mobile-side processing introduces up to 200-250msec of delay. So as much delay will
be present no matter who the provider is.

I found this quite significant. Voice quality studies have found that when the voice latency is greater
than around 300-400ms, the quality of the conversation degrades as the two speaker
tend to step on each other (double talk).

From above, it seems that at least in the test calls I performed, Easyvoip introduces
significant latency. Depending on the location of call participants it may, it may not create
for challenging experience. For example, during a recent call I did (using above method)
to a mobile in France, the delay exceeded 1.5 seconds. That made for a tricky phone exchange.

I'm located in the US so the above measurement may not hold true in other continents.

L.









lk96

Quote from: RonR on January 21, 2012, 11:37:15 AM

The following will prepend 0011101 to all calls sent using SP2:

Service Providers -> ITSP Profile B -> General -> DigitMap:

(<0011101>(1xxxxxxxxxx|<1>[2-9]xxxxxxxxx|<1aaa>[2-9]xxxxxx|<011:>xx.)|(Mipd)|[^*#]@@.'@'@@.)

where aaa is your local (US) area code.


I'm getting strange digit formations that are sent out to the selected service (SP2) with above syntax.
The exact digitmap I'm using for SP2 is shown below. In addition to substituting 011 with the Voxbeam prefix,
I'm also adding/replacing numbers that start with "00" with Voxbeam prefix as well:
(<0011101>(1xxxxxxxxxx|<1>[2-9]xxxxxxxxx|<011:>xx.|<00:>xx.|xx.)|(Mipd)|[^*#]@@.)

Below is representative behavior I see at the call records.

Example:
I dialed: **2301234567890
digits shown at PHONE1 terminal:  **20011101301234567890
digits shown at SP2 terminal:       001110111101301234567890

It seems that for some reason the 0011101 prefix was added to the phone terminal digits before the SP2 digitmap was applied. And when the SP2 digitmap was applied, the "011" pattern was removed and
a second 0011101 prefix was attached.

The digit map and outbound call route info for PHONE are the defaults.

I can't seem to figure out why Obi shows that the PHONE terminal added the first
instance of the 0011101 prefix.

L.

PS: I tested also with an SP2 digitmap where I removed all the 00 and 011 handling part.
I see again that the 0011101 prefix is shown in the PHONE1 terminal digits.

RonR

I made a mistake and you compounded it with your 00xx. rule.

Use this instead:


Service Providers -> ITSP Profile B -> General -> DigitMap:

(<+:0011101>xx.|<+>(1xxxxxxxxxx|<1>[2-9]xxxxxxxxx|<011:>xx.|<00:>xx.)|(Mipd)|[^*#]@@.'@'@@.)

lk96

So the logic with your revised rule is:
1. handle the rules in the inner parenthesis first (ie if you see 011 remove it).
2. add a placeholder symbol in front of the modified string of digits
3. substitute the "+" placeholder with the desired voxbeam prefix.

Do I have this right?
If so, then the above syntax is no obvious from the admin documentation.

L.


RonR

Quote from: lk96 on January 23, 2012, 03:00:38 PM
Do I have this right?

Yes.  The '+' is added when the PHONE Port DigitMap is evaluated.  The '+' is replaced by 0011101 when the PHONE Port OutboundCallRoute is evaluated.

Quote from: lk96 on January 23, 2012, 03:00:38 PM
If so, then the above syntax is no obvious from the admin documentation.

There's a lot about the OBi that isn't obvious from the admin documentation.   :(

lk96

OK, confirming that the revised rule worked. Thanks.

If I have it right, there is no such thing as recursive evaluation of the rule.
You simply exploit the simple fact that when **2 is dialed, Msp2 will be applied
to the dialed number which is 011301234567890 and will convert it to: **2+301234567890.
And at that point,the OutboundCallRoute will kick it, it will remove the **2, and
it will also match the "+" symbol and Msp2 is used again.
And it is at that point that the final expansion to include the desired prefix, takes place.

interesting ...

L.



lk96

Suppose I use SP2 to get a callback from the AA. I have already configured
the SP2 digitmap as we discussed before.

What I noticed is that when I get the callback from the AA through SP2, there was no digitmap processing
performed: ie, if I have set aa(sp2(1234567890)) to get a call back to that #, and given
that SP2 is the voxbeam trunk, what I see in the call record is that the number dialed
on SP2 is just the 1234567890 part and not 0011101 1234567890 as I'd expect.

Would you have an idea why there is different digit handling in this case? Does the above
make sense?

thanks

L.

RonR

Calls using TK format [(sp2(1234567890)] don't use a DigitMap or OutboundCallRoute, so you would have to include whatever you want to go out: SP2(001110112341234567).

lk96

Yes, I figured that after more tests. However I did try something else that also didn't work.

I defined a user-defined digitmap that was called: Mvoxmap

If I use a term like: {(Mvoxmap):aa($1)} in the inboundcallrules, the incoming
call on SP2 that is supposed to trigger the callback fails (I get a busy tone).
And the Obi call records do not include any trace of that call.

However, if instead, I cut&paste the exact same Mvoxmap digit map directly in the inboundcallrule,
it works properly and all digit processing is done as per the rule used.

Going by the documentation I expected that I can use the (Mvoxmap) reference directly in the inbound rule.
However in my case it seems that Obi totally ignores/rejects it.
It feels like a bug to me but again I'm not 100% sure if this handling was intentional or just buggy behavior.

For the time being, I have the above work-around that works ok.

thanks again

L.