Click Here To Visit SIP Broker  

Go Back   Voxalot / SIP Broker Support Forums > Voxalot Forums > Voxalot Support

Voxalot Support Support for the Voxalot service.

 
 
Reply
Thread Tools Display Modes
Unread 02-19-2007, 09:10 PM   #11
Cris77
Member
 
Join Date: Sep 2006
Posts: 33
Thanks: 0
Thanked 0 Times in 0 Posts
Cris77 is on a distinguished road
Default

I am interested in this FreeDigits ( http://www.freedigits.com/ ).
I got a number and it can sucessfully forward it to voxalot.

A problem: I have to inform all the people that I know that I changed the number.
A doubt: FreeDigits seems very commercial oriented service. I wonder if they will keep the number free or they are going to change in a paying service.

-Cris
Cris77 is offline   Reply With Quote
Unread 02-19-2007, 10:17 PM   #12
ctylor
 
ctylor's Avatar
 
Join Date: Apr 2006
Location: Vancouver, BC
Posts: 296
Thanks: 94
Thanked 53 Times in 27 Posts
ctylor will become famous soon enough
Default

IPKall and FreeDigits have the exact same business model for their free phone numbers - viz. they charge exorbitantly expensive rates to the phone company to connect calls from callers to you (which the caller themselves do not see but only the phone company does), which compensates these two providers for offering these phone numbers to you for free.

In all honesty, this sort of parasitic thing is only possible because of the distortion caused by government intervention in the phone market. It might be drawing to a close but not yet. Either the government intervention will only get worse in order to stop this 'unlawful' profiteering or the socialized conditions that exist in the first place will have to be dismantled so that the market can be reorganized on rational lines.

See this thread for info on these free Iowa numbers:
http://www.dslreports.com/forum/remark,17789735
ctylor is offline   Reply With Quote
Unread 02-20-2007, 06:17 AM   #13
Cris77
Member
 
Join Date: Sep 2006
Posts: 33
Thanks: 0
Thanked 0 Times in 0 Posts
Cris77 is on a distinguished road
Default

Did you change something on your side?

Last 2 calls I received today through IPKall had very good quality. Maybe the internet is not very busy because the President Day?

I just changed the server to which IPKall forwards the phone calls from voxalot.com to us.voxalot.com.

-Cris
Cris77 is offline   Reply With Quote
Unread 02-20-2007, 07:18 AM   #14
martin
 
Join Date: Feb 2006
Posts: 2,930
Thanks: 528
Thanked 646 Times in 340 Posts
martin is a jewel in the roughmartin is a jewel in the roughmartin is a jewel in the roughmartin is a jewel in the roughmartin is a jewel in the roughmartin is a jewel in the rough
Default

Nothing has changed here since our last release. I suspect your upstream provider is having a better quality day.
__________________
Martin

Please post support questions on the forum. Do not send PMs unless requested.
martin is offline   Reply With Quote
Unread 04-18-2007, 11:06 AM   #15
haifischjunge
Member
 
Join Date: Apr 2007
Location: Vienna, Austria
Posts: 56
Thanks: 5
Thanked 4 Times in 4 Posts
haifischjunge is on a distinguished road
Default

ipkall does not use 641 numbers for the inbound connection. they use for example 206 seattle metro area numbers. as far as i know these are normaly charged numbers.
haifischjunge is offline   Reply With Quote
Unread 04-18-2007, 03:36 PM   #16
DracoFelis
 
DracoFelis's Avatar
 
Join Date: Mar 2006
Posts: 188
Thanks: 4
Thanked 64 Times in 41 Posts
DracoFelis is a jewel in the roughDracoFelis is a jewel in the rough
Default

Quote:
Originally Posted by Cris77 View Post
I found this IPKall now Supports g.729a - Voxilla VoIP Forum

They support G729a

But I am not sure what happens when IPKall pass the call to Voxalot.
It seems that depends on the coded exported by voxalot and the order of them.
If I'm not mistaken, IPKall only did ulaw/G711u for the longest time. And even though they have now added other CODECs, I think IPKall will still always pick ulaw/G711u if/when that is an allowed/supported CODEC on the receiving end (i.e. the IPKall web site doesn't give you any CODEC choice/setting for your IPKall account). You might want to check in their support forum (it's over on Voxilla.com at IPKall Support Forum - Voxilla VoIP Forum ) to make sure, but I think that's IPKall's behavior.

Now, here's where I think things are getting "interesting":

Even if you have your adapter setup to not support ulaw/G711u (for example, because you don't have enough bandwidth), it's still the case that the voxalot.com proxy (as well as the more specific us.voxalot.com, au.voxalot.com, and eu.voxalot.com addresses) support ulaw/G711u even if/when your adapter has that CODEC turned off (for example, because you don't have enough bandwidth).

So when IPKall connects to VoXaLot, it likely does so via ulaw/G711u (because VoXaLot itself will support those CODECs), and then VoXaLot will see that your adapter doesn't support G711u and "transcode" the CODECs. And since you (currently) have no way to control the CODEC that IPKall uses to contact VoXaLot, you also don't appear to have any way to control the "transcoding" issue.

And the above analysis is assuming my memory is correct, and IPKall still always picks ulaw/G711u, when that CODEC is supported by the remote proxy. If (instead) IPKall were to pick one of the other CODECs that VoXaLot supports, than the situation could be even worse. For example, imagine how lousy of sound you would get if/when IPKall picked G723, forcing VoXaLot to transcode G723 to G729!

Hmmm...

What this situation is really calling for IMHO is a general "CODEC list" for our VoXaLot accounts, that has the same format/purpose as that CODEC list we have for our specific providers. However, in the case of our general (account) provider list, it will control which CODECs VoXaLot responds to (and in which order we "prefer them") when someone makes a call to our_voxalot_account@voxalot.com (or @us.voxalot.com, or...).

The idea is, we currently have this level of CODEC control for our own "providers". But when we are just "forwarding" the call (or someone is calling us via SIP Broker, etc), than we don't have any say on which CODEC is used for the "1st hop" (the call to VoXaLot). And that can (and apparently does, in practice) result in some unwanted "trnascoding". But if we had a setting on our VoXaLot account to control the CODECs for such calls, than end users would have at least some control over transcoding, by being able to influence the CODEC on the first hop of the call.

What I don't know (since I haven't seen the internals of the code recently), is how easy it would be to add such an (incoming CODEC select) option/feature to our VoXaLot accounts. But IMHO without such a feature, we will continue to get situations where unwanted transcoding is occurring (with little an individual VoXaLot user can do to stop that transcoding when it's causing problems)...
DracoFelis is offline   Reply With Quote
Unread 04-18-2007, 08:42 PM   #17
mbossard
Junior Member
 
Join Date: Aug 2006
Posts: 3
Thanks: 0
Thanked 0 Times in 0 Posts
mbossard is on a distinguished road
Default

I agree, it would be very nice to be able to control Voxalot codecs for incoming calls (not just outgoing, as is possible currently for each provider in the Voxalot "Providers" page).

Another option is to forward IPKall (or any other DID provider) direct to your hardware. This eliminates any possible transcoding, but also has it's own complexities. The main hurdle is if you are a standard broadband subscriber with dynamic IP address. Requires signing up with a free dynamic DNS service. Also require some router/firewall config.

SIPBroker has a nice article HERE.

Benefits - most direct incoming call routing method. Minimize transcoding. Your hardware then has direct control of the incoming codec.

Drawbacks - requires a little more tweaking/setup on your end. Not as "clean" as simply forwarding your DID to userid@voxalot.com.

If you have a router that has dynamic DNS support (they often do, e.g. Netgear), this is an extra helpful feature to get this working. Check your router setup.

Martin, has Voxalot considered feasibility of adding user control of codecs for incoming calls?
mbossard is offline   Reply With Quote
Unread 05-13-2007, 08:01 PM   #18
majo
Senior Member
 
Join Date: Jun 2006
Posts: 115
Thanks: 32
Thanked 20 Times in 18 Posts
majo is on a distinguished road
Default add codec pref for incomming calls!!!!!!!!!!

Hi,
adding possibility to control codec for incomming call will be very good feature. Actully this is requirement for my braintel account that support only G729 codec. My Fritz box does not support G729, so I have setup my fritzbox to connect braintel through voxalot. Currently I can make calls through voxalot, but to recieve I have to keep my PC online. I have tried to register braintel on voxalot but even then i was not getting calls on my fritzbox. This post explain's what was the problem. If voxalot can support control over incomming codec then hopefully i will be able to recieve call on fritzbox through voxalot. I will request voxalot team to consider about implementing control for incomming call codec. I don't know if it is too difficult or not, but will hope for this feature.

With best regards.

majo
majo is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Voxalot and Sipura/ATA Tutorial: A Comprehensive Walkthrough ctylor Voxalot General 5 04-28-2010 12:52 AM
Call Quality and Voxalot shibukraj Voxalot Support 1 12-01-2006 03:39 AM
Best Quality - Sip Broker or VoXaLot? Mallycat Voxalot Support 10 06-08-2006 09:01 PM
DID pointing to Voxalot and Call Quality pmerrill Voxalot Support 9 05-23-2006 12:20 AM
Voxalot affect on Call Quality pmerrill Voxalot Support 0 05-12-2006 04:53 AM


All times are GMT. The time now is 10:36 AM.


Powered by vBulletin® Version 3.7.2
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.