triggering a callback without Obi answering the call
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page