Topic 'voip.ms and sipbroker' in forum 'VOIP Tech Chat' - dslreports.com

Re: voip.ms and sipbroker

Fri, 07 Aug 2009 19:35:34 EDT

DogFace05 posted : To expand on Sipbroker's redirect behavior, it is at best of dubious value. It is only useful if and only if the numbering plan of the default provider coincides with that of Sipbroker, something that is generally highly unlikely, except possibly in the case of ENUM calls. Generally (in cases other than ENUM) the results will be unpredictable at best, or potentially very undesirable at worst.

Re: voip.ms and sipbroker

Fri, 07 Aug 2009 16:17:35 EDT

DogFace05 posted : Well, I'll be darned. It isn't often that anyone proves me wrong and makes me have to eat my own words, so hats off to you.

Over the years that I've used Sipbroker, I've always observed it operating strictly as an intermediary forwarding proxy. I've never ever seen it try a "300 redirect". Well, you prompted me to fire up my old Wireshark and capture a Sipbroker call to a bogus number, and lo and behold, there came the "300 redirect", so you're absolutely right about Sipbroker redirecting the call to the default provider.

However, in your original post you seemed to infer (although that may just have been my interpretation) that the ATA's own logic would decide a fallback path for a failed Sipbroker call, based on its configuration. That is not the case. I still maintain that there is no such fallback mechanism in any ATA.

What there is (and you did point that out in your last post), is a redirect (essentially a call forwarding function) that allows Sipbroker to cause the call to be rerouted to a destination. However, the redirect destination is solely determined by Sipbroker (based on the From information provided by the ATA, but nonetheless decided by Sipbroker), and not by the own logic of the ATA, as you appear to give the impression of. But again, I may be misinterpreting your message.

Personally, though, this is not the kind of behavior that I would ever want implemented, at least not without the ability for the user to disable it. I like knowing that my calls will be routed where I explicitly direct them to be routed, and nowhere else. If I set up a dial plan whereby I explicitly dial an access code to go out via Sipbroker, I want that call to go out that route only or not at all, and not out a default fallback route. I don't want misdialled calls that I explicitly made for routing through Sipbroker, to then surprise me with unexpected, perhaps expensive, bills. To each their own, though, and some may prefer the LCR like way as it is.

At any rate, you've proved that there's always room for all of us to learn something new, so thanks for setting back on the correct path.

Re: voip.ms and sipbroker

Fri, 07 Aug 2009 13:44:28 EDT

mbuugg posted : I am a little shocked when I read you said "not at all". That's how Sipbroker has been working for years and Sipbroker had never invented its own VoIP protocol. It is merely implementing a redirect server, the most standard definition in SIP protocol as part of its service, as standard as the registrar server or proxy server which you had showed a foundametal understanding. :)

But I am not worried because you are an expert and I guess before I write this post, you probably already took off one minute to look at the SIP trace for a call to your_cell_number@sipbroker.com. Watch out the 300 response and you may want to experiment more to find out how Sipbroker composes the redirection URI address.

If someone says it is not working, most of the time it is because the dial plan is incorrect or the client has an imcompatible/faulty implemtation. In order for the redirection to work, the from header must contain the provider information, not the "@sipbroker.com".

I am quite assured neither Sipbroker is smart enough to invent its own SIP protocol to "proxy" SIP authentication, nor is voip.ms stupid enough to not authenticate a paid call request. :D

Re: voip.ms and sipbroker

Thu, 06 Aug 2009 14:09:21 EDT

DogFace05 posted :

said by Anon Imos :

Now the interesting part...

I called my friend who is also with voip.ms through sipbroker. I dialed #*85701XXXXXXXXXX#, where XXXXXXXXXX is a normal North American number (not virtual). I again watched the progress of my call and it went to *85701XXXXXXXXXX@sipbroker.com. The call went through fine, and I thought it was free for me. The big surprise was when I found it in my call records, and I was charged for it as if I dialed 1XXXXXXXXXX! I am sure the call went through sipbroker and had nothing to do with voip.ms. So voip.ms tracked the origin of my call and charged me anyway? Is this the way it should work? Can anybody comment on this?

The problem here is that voip.ms can't tell whether your call is being made directly through them or through Sipbroker, without some involved deeper inspection of the SIP header's Record-Route and/or Via entries. And to do that, they have to be aware of what proxies along the way belong to Sipbroker. It would be unlikely for any provider to bother doing that.

Voip.ms know you as a subscriber of their service by looking at the SIP From header, which is identical regardless of which route the call takes to get to them. Once they recognize you as one their subscribers, they will charge (as is their policy) for any calls dialled to URIs outside their network. Even though the Invite will be to a URI within voip.ms, the To field will contain the originally dialled URI, which is a Sipbroker URI. Apparently, it would seem that voip.ms's billing system bases it on the latter, instead of the Invite URI.

This may be a serious security issue with voip.ms, that you should take up with them, as anyone who knows the user id of a voip.ms subscriber, may be able to rack up bogus charges on the subscriber's account, by making calls to Sipbroker routed numbers, either directly via voip.ms or via Sipbroker, if voip.ms are not authenticating the caller for such calls. Note that I don't know whether voip.ms do authenticate such calls.

Re: voip.ms and sipbroker

Thu, 06 Aug 2009 12:47:51 EDT

DogFace05 posted :

said by mbuugg:

That's the way how it works. Put it simple, Sipbroker tries to reach 1XXXXXXXXXX@voip.ms, and voip.ms tells Sipbroker no way, then Sipbroker hands over the call back to your ATA, and your ATA re-sends the request to voip.ms, and then voip.ms authenticates your credential and connect the call and charges you.

That's the same way how PSTN_number@sipbroker.com does the ENUM check in a dial plan. Your ATA calls PSTN_number@sipbroker.com, and Sipbroker does the ENUM check. If Sipbroker finds an ENUM record for the PSTN_number, it connects the call for your ATA for free. It not, Sipbroker hands over the number back to your ATA, and your ATA then tries to connect the number using the provider information on it. In the whole process, you will only see that your ATA is calling the sipbroker. You won't see what deal your ATA has made with sipbroker.

No, this is not at all how it works. There is no fall back dialing mechanism in either ATAs or Sipbroker that would make an ATA resend the request, should Sipbroker fail to find a suitable route. If Sipbroker fails, the call fails.

Re: voip.ms and sipbroker

Thu, 06 Aug 2009 10:07:12 EDT

anon posted :

I am not sure if this is correct. First, I used IP dialing with an appropriate dial plan by putting ## around the number. Second, I saw in the info section that the call was to number@sipbroker.com. The ATA would have shown something else if the call was routed differently by the ATA itself, I think. Third and most important, if I dial just an arbitrary PSTN_number@sipbroker.com I get dead silence and call does not connect, so I think the ATA does not re-route sipbroker-rejected calls to my provider. Also supposedly sipbroker accepts calls to voip.ms through their *XXXX number. I think something else, fishier, is going on.

Re: voip.ms and sipbroker

Thu, 06 Aug 2009 00:48:18 EDT

mbuugg posted : That's the way how it works. Put it simple, Sipbroker tries to reach 1XXXXXXXXXX@voip.ms, and voip.ms tells Sipbroker no way, then Sipbroker hands over the call back to your ATA, and your ATA re-sends the request to voip.ms, and then voip.ms authenticates your credential and connect the call and charges you.

That's the same way how PSTN_number@sipbroker.com does the ENUM check in a dial plan. Your ATA calls PSTN_number@sipbroker.com, and Sipbroker does the ENUM check. If Sipbroker finds an ENUM record for the PSTN_number, it connects the call for your ATA for free. It not, Sipbroker hands over the number back to your ATA, and your ATA then tries to connect the number using the provider information on it. In the whole process, you will only see that your ATA is calling the sipbroker. You won't see what deal your ATA has made with sipbroker.

Re: voip.ms and sipbroker

Thu, 06 Aug 2009 00:01:58 EDT

anon posted : Sorry for resurrecting this thread but it is the most relevant. I am a customer of voip.ms with SPA2102 configured to use their service. After reading this thread I enabled IP dialing without registration and added this to my dial plan:

<#:>[x*][x*].<:@sipbroker.com>

I pointed my ATA to a STUN server just like hayim to take care of NAT and checked if everything worked as intended. It did. My ATA knew my external IP. I tried the number with monkeys by dialing #*266300# and it worked. I tried the Sheraton number #*18003253535# and it worked too. I could watch the progress of my calls in the Info section of my ATA's web interface by constantly refreshing it. I could see the the calls were to *266300@sipbroker.com and *18003253535@sipbroker.com. I checked my call records at voip.ms, there was no trace of those calls as expected. When I tried to dial 18003253535 directly it appeared in the call records, again as expected.

Now the interesting part...

I called my friend who is also with voip.ms through sipbroker. I dialed #*85701XXXXXXXXXX#, where XXXXXXXXXX is a normal North American number (not virtual). I again watched the progress of my call and it went to *85701XXXXXXXXXX@sipbroker.com. The call went through fine, and I thought it was free for me. The big surprise was when I found it in my call records, and I was charged for it as if I dialed 1XXXXXXXXXX! I am sure the call went through sipbroker and had nothing to do with voip.ms. So voip.ms tracked the origin of my call and charged me anyway? Is this the way it should work? Can anybody comment on this?

Re: voip.ms and sipbroker

Fri, 31 Jul 2009 01:23:20 EDT

hayim posted :

said by DogFace05:

Note that when calling through a registered provider, you'll often be proxied with no need to set special NAT aware settings on your adapter. When going out directly through sipbroker, there is no such proxying, so you need to make sure that your PAP2T is properly set up to handle being behind NAT.

Thanks Dog, this was my exact problem! Couldnt get my SPA-2000 to work gateway calls properly, until I pointed it to a stun sever (in my case, stun.voxalot.com:3478 - don't ask me why i dont just register thru voxalot..)

Cheers!

Re: voip.ms and sipbroker

Fri, 19 Jun 2009 09:14:38 EDT

anon posted : I get about 50 percent success on any attempt to dial any number of any vosp via sipbroker. I assume you have tried more than once or twice.

Or maybe there is something extra-special about a sub-account sip url.

Want to invest in a virtual DID? 25 cents/month, 1/10 cent per minute. That's what I use with sipbroker.

Re: voip.ms and sipbroker

Fri, 19 Jun 2009 08:50:14 EDT

AndrewZ posted :

said by fjddi99 :

It works now. Try it.

Not for me.
I'm using sub-account SIP URI, direct calls to that URI are passing through. Calls from sipbroker pstn gateway to this URI using *013 & ENUM are passing through as well.
Dialing *8570 followed by 8-digit number (account + subacct) gives me BUSY.

Re: voip.ms and sipbroker

Fri, 19 Jun 2009 08:40:24 EDT

anon posted :

And what if someone wants to dial to VoIP.ms from sipbroker using the *8570 code?
Any chance that this will work in the future?

It works now. Try it.

Re: voip.ms and sipbroker

Fri, 19 Jun 2009 08:18:59 EDT

AndrewZ posted :

said by MartinM:

However, if someone wants a dial code to dial to sip broker via VoIP.ms, we've no objection programming such an extension. Just contact our support and mention this thread and we'll add it.

And what if someone wants to dial to VoIP.ms from sipbroker using the *8570 code?
Any chance that this will work in the future?
If for some reasons you cannot do it with the single code may be you can setup the different codes to your us, uk and other servers as it was suggested earlier in this forum?

Please do not offer using *013 and e164, I'm aware of this.

Re: voip.ms and sipbroker

Tue, 16 Jun 2009 03:12:41 EDT

DogFace05 posted :

said by nitzan:

Many toll free numbers WILL refuse calls from non-standard Caller ID's. If it works it means either A- this specific TF number doesn't check for valid CID, or B- the carrier the call went through overrode the CID with something else that appears valid.

We've had tons of problems where a user would enable CID blocking on their ATA, then complain that they can't call TF numbers. To resolve this, now we are manipulating CID to not allow anonymous calls to TF numbers and it will send CID even if it's blocked on the ATA.

Yes, but that's something that you, as the one who interfaces with the carrier, have to worry about and deal with. Same goes for the TF provider that Sipbroker forward TF calls through.

Given that this TF call provider specializes in serving SIP clients who, in general, cannot be expected to provide proper 10-digit, numeric user ids, one would be hard pressed to believe that they would just blindly pass on non-kosher user ids as CID. And as it turns out, they don't--this TF provider sets one of their own phone numbers as CID, whenever a caller's user id isn't a proper 10 digit number.

Whether this is desirable, or not, is probably debatable. However, it assures that no TF call routed via Sipbroker should ever be rejected based on a caller's user id not being a 10-digit number. PX's 6-digit user id from voip.ms, simply cannot be the cause for his direct-through-Sipbroker routed TF calls fast busying.

Re: voip.ms and sipbroker

Fri, 12 Jun 2009 20:20:12 EDT

PX Eliezer posted :

said by MartinM:

I think PX Eliezer gets paid every time he post about Call centric in VoIP.ms related threads ;)

Sounds like something David Letterman would say. :p

Hey, I've posted some NICE things about Voip.MS. And I was the person who got Voip.MS added to this website's review submission list, and then I posted the very first official review of it, which was last year. It was a very nice review at the time, BTW. :) And I have also helped a few folks with their Voip.MS configurations and settings.

Conversely, I've also constructively criticized CallCentric on occasion.

I know you were joking, but my objectivity is important to me. :huh:

I'll let my posts speak for themselves. ;)

Re: voip.ms and sipbroker

Fri, 12 Jun 2009 19:00:23 EDT

MartinM posted : I think PX Eliezer gets paid every time he post about Call centric in VoIP.ms related threads ;)

Great thing about using SIP Broker with outbound is actually configuring it in your Dial Plan so that it's transparent, it's not dependant on the VoIP provider. However, if someone wants a dial code to dial to sip broker via VoIP.ms, we've no objection programming such an extension. Just contact our support and mention this thread and we'll add it. Case closed

Re: voip.ms and sipbroker

Wed, 10 Jun 2009 20:21:23 EDT

afred posted : I am using X-Lite to make SIP calls to voip.ms URIs, just by typing the SIP URI into X-Lite.

I have un-checked "Register with domain", and this way no account or password are needed to make the call.

When I call to a SIP account registered with voip.ms, and configure the X-Lite "Domain" to sip.ca1.voip.ms, the voip.ms server apparently only accepts the call when the username I use for the caller does not exists as an account with voip.ms. As long as I make up some string for my username the call goes through, but as soon as I set it to my voip.ms account, or a subaccount, or a friend's account, the call fails with "Call failed: forbidden".

Can anyone else confirm this behaviour? Any idea why voip.ms servers would refuse to accept SIP calls from voip.ms accounts?
It's not very convenient to have to reconfigure my SIP client with a fake username every time I want to make a SIP call to another voip.ms user.

Re: voip.ms and sipbroker

Wed, 10 Jun 2009 18:23:42 EDT

skyhook posted :

said by DogFace05:

In testing on one of my SPA2102s, I did come across an issue. It turns out that when dialing without the terminating #, the number is sent out through the registered provider, instead of sipbroker. In fact, the <:sipbroker.com> substitution of my dial plan rule never takes place.

The expected behavior (according to spec), when the interdigt timeout expires before any dial plan rule has been satisfied in full, is to send out the number exactly as dialed (without any substitutions or translations) to the registered provider. In our case, the prefix substitution takes place, but not the trailing one. It seems we have a bug, whereby when we have an open ended rule (such as emoci's and mine), it is considered fully satisfied insofar as the leading substitution concerns, but not the trailing, so the dialled number is stripped of the prefix, but sent out to the registered provider instead of that in the trailing substitution.

I believe this is the expected behavior according to the administration guide. Here is the revelant paragraph:

If IP dialing is enabled, one can dial [user-id@]a.b.c.d[:port], where ‘@’, ‘.’, and ‘:’ are dialed by
entering “*”, user-id must be numeric (like a phone number) and a, b, c, d must be between 0 and
255, and port must be larger than 255. If port is not given, 5060 is used. Port and User-Id are
optional. If the user-id portion matches a pattern in the dial plan, then it is interpreted as a regular
phone number according to the dial plan. The INVITE message, however, is still sent to the outbound
proxy if it is enabled.

In short, if the # key is not used then the entered digits are sent to and processed by the proxy server when the short timer expires.

If the # key is used as the last entered digit then the relevant sequence in the dial plan is executed in its entirety, including the trailing substitution.

The prefix substitution is used regardless.

Re: voip.ms and sipbroker

Wed, 10 Jun 2009 15:39:49 EDT

PX Eliezer posted :

said by nitzan:

Many toll free numbers WILL refuse calls from non-standard Caller ID's. If it works it means either A- this specific TF number doesn't check for valid CID, or B- the carrier the call went through overrode the CID with something else that appears valid.

We've had tons of problems where a user would enable CID blocking on their ATA, then complain that they can't call TF numbers. To resolve this, now we are manipulating CID to not allow anonymous calls to TF numbers and it will send CID even if it's blocked on the ATA.

This is standard procedure at the regular (POTS) phone companies, as you know. Many members of the public are not aware that *67 does NOT hide their number when they are making a TF call.

Re: voip.ms and sipbroker

Wed, 10 Jun 2009 15:37:34 EDT

PX Eliezer posted : Thanks for all your work. :)

I suspect this may be a NAT problem so I'll look at that.

Interesting about the bug relating to the terminating "#". This has been noted as well on the Sipbroker wiki in regard to Linksys adapters.

Re: voip.ms and sipbroker

Wed, 10 Jun 2009 15:08:52 EDT

nitzan posted : Many toll free numbers WILL refuse calls from non-standard Caller ID's. If it works it means either A- this specific TF number doesn't check for valid CID, or B- the carrier the call went through overrode the CID with something else that appears valid.

We've had tons of problems where a user would enable CID blocking on their ATA, then complain that they can't call TF numbers. To resolve this, now we are manipulating CID to not allow anonymous calls to TF numbers and it will send CID even if it's blocked on the ATA.

Re: voip.ms and sipbroker

Wed, 10 Jun 2009 14:29:07 EDT

mazilo posted :

said by DogFace05:

Well, I set a 6 digit user id (and also display name) and tested calling both "#1*18003253535#" and "#1*266300#".

Just to confirm that your dialplan works just fine on my PAP2v1.

Re: voip.ms and sipbroker

Wed, 10 Jun 2009 14:14:05 EDT

DogFace05 posted : Well, I set a 6 digit user id (and also display name) and tested calling both "#1*18003253535#" and "#1*266300#". They both went through just fine. Same thing with a 4 digit user id. I think your issue is related to something else, perhaps NAT? Note that when calling through a registered provider, you'll often be proxied with no need to set special NAT aware settings on your adapter. When going out directly through sipbroker, there is no such proxying, so you need to make sure that your PAP2T is properly set up to handle being behind NAT. I don't know your setup, so I can't tell if this is the cause of your troubles, but it's something to keep in mind.

In testing on one of my SPA2102s, I did come across an issue. It turns out that when dialing without the terminating #, the number is sent out through the registered provider, instead of sipbroker. In fact, the <:sipbroker.com> substitution of my dial plan rule never takes place.

The expected behavior (according to spec), when the interdigt timeout expires before any dial plan rule has been satisfied in full, is to send out the number exactly as dialed (without any substitutions or translations) to the registered provider. In our case, the prefix substitution takes place, but not the trailing one. It seems we have a bug, whereby when we have an open ended rule (such as emoci's and mine), it is considered fully satisfied insofar as the leading substitution concerns, but not the trailing, so the dialled number is stripped of the prefix, but sent out to the registered provider instead of that in the trailing substitution.

Re: voip.ms and sipbroker

Tue, 09 Jun 2009 21:50:45 EDT

PX Eliezer posted :

said by DogFace05:

What exactly did you dial (including the #1 prefix) that didn't work with my dial plan rule? And could you give a few example numbers that won't go through as per your explanation above, so I can test from my end?

I was able to get your dial plan rule to work tonight. (Thank you!) The difficulties yesterday apparently related to 2 points. First, perhaps because of the second dial tone, there were "timing issues"---if not finished quickly enough with all the digits, the call would time out. Also, the Linksys PAP2T seems to have a quirk, previously reported, that for these IP calls the "#" key needs to be pressed at the end.

Thus, this type of call would go through to SipBroker using your dial plan: (Calling to a CallCentric number):

#1*4621777xxxxxxx#

-----------------------------------

The calls that would NOT go through to SipBroker by this method included, for example:

Nationwide TF number for Sheraton Hotels:
#1*18003253535# (dead air; probably they don't like seeing the Voip.MS User ID of just 6 digits)

The famous "we have been captured by monkeys" from Blueface.ie:
#1*266300#

Both of these do work when accessing SipBroker through CallCentric. I only say that for reference.

Thank you for your interest. :)

Re: voip.ms and sipbroker

Tue, 09 Jun 2009 20:59:00 EDT

anon posted : Check your subaccounts page, it shows you external sip uri:

External SIP URI:

10237715@server (example: 10237715@sip.us4.voip.ms)

That's the correct id :-) I put 10237715@sip.us4.voip.ms in IPKALL and it work perfectly.

Re: voip.ms and sipbroker

Tue, 09 Jun 2009 08:03:06 EDT

anon posted : fwiw, I tried setting up a sub account in voip.ms. This was my user id + 4 digits, the idea being to be able to use the 10 digits: 123456 7890 in my pap2 ata.

voip.ms uses an underscore as part of the sub-account's value. So it is actually: 123456_7890 and you have to use that in the ata to be able to call out. I mean call out by dialing a pstn number.

When you call out that way, the callerid that is sent is whatever you set in [main menu / account settings].

If you use the dial plan to call out, the callerid ignores the underscore and passes 1234567890 as the caller id, so that might be a solution to the problem that px eliezer reported.

On incoming, my setup routes calls to an ivr. If an extension is entered at the prompt, the call is normally routed to the 'main account': 123456. But with the sub account value in the ata, I had to change the routing to the sub account: 123456_7890. If I left the routing to 'main account', the call went to voicemail.

I don't know why it is like that: it seems like a bug.

Re: voip.ms and sipbroker

Tue, 09 Jun 2009 00:59:24 EDT

DogFace05 posted : What exactly did you dial (including the #1 prefix) that didn't work with my dial plan rule? And could you give a few example numbers that won't go through as per your explanation above, so I can test from my end?

Re: voip.ms and sipbroker

Tue, 09 Jun 2009 00:11:04 EDT

PX Eliezer posted :

said by DogFace05:

Voip.ms have absolutely nothing to do with it. This dial plan rule completely bypasses voip.ms, or any other provider you may happen to be registered to, and goes straight to sipbroker.

Yes, of course it bypasses the provider.

But here is the problem I ran into, which indirectly does relate to Voip.MS or any provider that uses a user ID that is less than 10 digits:

I was able to use the dial plan to access SipBroker, and then to make calls to various Voip numbers on services such as CallCentric, CallWithUs, and so forth.

However, calls to some destinations would NOT go through. This was especially true when calling 800 numbers, but also some commonly used echo tests and so forth.

When I called some of my OWN Voip numbers, and looked at the INCOMING call logs, I was able to see that the Linksys PAP2T phone adapter was sending OUT my Voip.MS account number (which the PAP2T lists as "User ID") as my phone number. Again, that's because the PAP2T has it listed as the User ID.

And that Voip.MS number is 6 digits. As you know, lots of phone systems, especially 800 numbers, will reject incoming calls that come in with an improper identifier. So that's the problem, even though the call is not going through Voip.MS.

Now, if I change my User ID to a spoofed 10 digit number instead of the 6 digit Voip.MS account number, then the adapter is not registered, and then I have no dial tone, so it won't work that way either.

I also tested out this theory by doing the exact SAME setup, but with a provider that has a 10-digit account number to plug into the PAP2T "User ID". All the SipBroker calls were fine that way.

---------------------------------------------

I think that Voip.MS is a fine provider. And they are not under any obligation to provide easy outbound access to SipBroker.

My main point has been that in THIS particular area, CallCentric has the advantage, and that remains so.

Re: voip.ms and sipbroker

Mon, 08 Jun 2009 23:52:36 EDT

PX Eliezer posted :

said by Glurg :

So I don't see any incompatibility between voip.ms and sipbroker.

Thanks for the dialing suggestions.

As per my post above, the dial plan from emoci does work.

However, there IS an issue using it on an account registered to Voip.MS, as I will discuss in my next post.

Because of the issue, CallCentric (with its **275 dialing) is still much easier for many of the outbound SipBroker calls.

Re: voip.ms and sipbroker

Mon, 08 Jun 2009 23:49:46 EDT

PX Eliezer posted : Thank you, that dial plan works well.

It does seem that the # key has to be dialed at the end.

Re: voip.ms and sipbroker

Mon, 08 Jun 2009 19:30:46 EDT

anon posted : You're welcome. I used a pap2t-na.

Re: voip.ms and sipbroker

Mon, 08 Jun 2009 19:14:22 EDT

PX Eliezer posted :

said by Glurg :

Here are a few things I entered that worked.

Thank you for the extensive tests. May I ask, what kind of ATA or other device did you use? Was it a PAP2T-NA, other Linksys device, or something else?

Re: voip.ms and sipbroker

Mon, 08 Jun 2009 19:12:08 EDT

PX Eliezer posted : I will try that, thanks!

Re: voip.ms and sipbroker

Mon, 08 Jun 2009 19:09:17 EDT

PX Eliezer posted :

said by DogFace05:

It's more likely that you didn't enter it correctly--perhaps you forgot to separate it with a vertical bar from the rest of your dial plan entries.

No, that is not the case at all.

Re: voip.ms and sipbroker

Mon, 08 Jun 2009 11:11:31 EDT

anon posted : I overlooked something in the scenario above: this is where you pick up the phone that is registered to voip.ms - how do you then dial out?

What you do is pick up the phone and dial the DID for that phone, and voip.ms will treat it the same way as it would for a call from any phone. If you have an ivr set up, you will get the menu and can enter the approprate 'quickdial' code to dial out.

Granted, it is a bit klunky compared to callcentric, where you just pick up the phone and dial *7501 or some other quickdial code, but it is easy to program a speed dial phone number, including the pauses, to get you where you want to go.

Re: voip.ms and sipbroker

Mon, 08 Jun 2009 07:12:26 EDT

anon posted : I added the string suggested by emoci to my dial plan.

Here are a few things I entered that worked.

Using my voxalot number, 123456
#*010123456#
#*010123456

Using my sipbroker number, 1234
#*0111234#
#*0111234

Using my callcentric number, 17771234567
#*46217771234567
#*46217771234567#

To do the tests above, I called from a phone registered to voip.ms, but as was pointed out by dogface05, that has nothing to do with whether or not it will work.

Then, to test how voip.ms works with sipbroker, I added a sip url to my voip.ms 'sip url' section. The url that I added was *011xxxx@sipbroker.com, where 'xxxx' is a number registered with sipbroker (siprbroker points it to my voxalot account).

Then I set up an extension, 54321, so that when I dialed my voip.ms DID, and entered 54321 at the prompt, the call was routed to the sip url *011xxxx@sipbroker.com, and that worked, ringing my phone, which is registered to voxalot.

Of course I could have set it up simply to immediately ring my voxalot account when the voip.ms DID was dialed.

And, as was mentioned before, you can call a sipbroker gateway and enter *8570 plus a voip.ms virtual DID, and that will connect to your voip.ms account.

So I don't see any incompatibility between voip.ms and sipbroker.

Re: voip.ms and sipbroker

Mon, 08 Jun 2009 01:15:51 EDT

emoci posted :

said by PX Eliezer:

said by DogFace05:

Dial plans aren't rocket science. That said, the following rule added to anyone's favorite dial plan, will allow calling out via SipBroker routing.....

Give this a try:

(<#:>*xxx[*x].<:@sipbroker.com>|Rest of Dial Plan)

You'll need to dial as #-*SipCode-Number-# (the # at the end may make the difference between working and busy ...)

Re: voip.ms and sipbroker

Mon, 08 Jun 2009 00:14:45 EDT

DogFace05 posted :

said by PX Eliezer:

Thanks, much appreciated.

Unfortunately, did not work on Voip.MS.

I used the exact sequence you wrote, and I even put it at the beginning of my PAP2T-NA dial plan. Also switched "IP dialing" to Yes.

But just ended up with "fast busy signals".

This might be characteristic of Voip.MS. Keep in mind, on the Voip.MS dashboard, you have to choose between NANPA dialing and E164 dialing.

I just do not believe that Voip.MS supports IP dialing from an ATA, such as your dial plan would entail.

Voip.ms have absolutely nothing to do with it. This dial plan rule completely bypasses voip.ms, or any other provider you may happen to be registered to, and goes straight to sipbroker. It's more likely that you didn't enter it correctly--perhaps you forgot to separate it with a vertical bar from the rest of your dial plan entries. Although I've never had a PAP2T in my hands to test the rule on, I use it on a regular basis (exactly as stated) with PAP2, RT31P2 and SPA2102 adapters. The PAP2T is based on the same software base, so I see little reason why it would not work there, barring some unlikely bug that would only have crept into that model. And again, it makes not one shred of difference what provider you're with, nor what dialing capabilities they support, as the rule completely bypasses them.

Re: voip.ms and sipbroker

Sun, 07 Jun 2009 22:42:29 EDT

garys_2k posted : F9 also allows easy SIP Broker callouts. You dial 06*xxxxyyyyyyyyyy and your call should go straight through. »[Future9] SIP Broker pass-through.

As for CC and F9, CC definitely has the edge regarding maturity, but I went with F9 because I think it's a better value and I like what I've heard and seen from Nitzan. His service is very solid, as is CCs. I do have a CC backup account that I intend to keep, too.

Re: voip.ms and sipbroker

Sun, 07 Jun 2009 22:35:55 EDT

neftv posted : I have a free account on Callcentric and found it so easy to get information on how to make SIP call via SIP Broker.
Seems like the more and more I read different topics here referencing Callcentric the more I see favorable things about Callcentric. Seems like they are a more mature company reading things about them. Future Nine would be my second choice. Both in the one and two position also because they are based in the states. Probably by Wednesday I going to flip a coin.

Re: voip.ms and sipbroker

Sun, 07 Jun 2009 21:58:52 EDT

PX Eliezer posted :

said by DogFace05:

Dial plans aren't rocket science. That said, the following rule added to anyone's favorite dial plan, will allow calling out via SipBroker routing.....

Thanks, much appreciated.

Unfortunately, did not work on Voip.MS.

I used the exact sequence you wrote, and I even put it at the beginning of my PAP2T-NA dial plan. Also switched "IP dialing" to Yes.

But just ended up with "fast busy signals".

This might be characteristic of Voip.MS. Keep in mind, on the Voip.MS dashboard, you have to choose between NANPA dialing and E164 dialing.

I just do not believe that Voip.MS supports IP dialing from an ATA, such as your dial plan would entail.

-------------------------------------------

If I am wrong, I would be glad to hear it.

But I circle back to saying:

CallCentric clearly surpasses Voip.MS in this area, because with CallCentric, it just works.

Re: voip.ms and sipbroker

Sun, 07 Jun 2009 20:50:43 EDT

DogFace05 posted : Dial plans aren't rocket science. That said, the following rule added to anyone's favorite dial plan, will allow calling out via SipBroker routing by just dialing the prefix #1 followed by any sipbroker accepted number.

<#1,:>[x*][x*].<:@sipbroker.com>

Feel free to replace "#1" with any desired prefix. The (optional) comma, following the prefix, causes a second dial tone to be played back upon dialing the prefix.

Re: voip.ms and sipbroker

Sun, 07 Jun 2009 20:29:12 EDT

sream posted :

said by Bogtrotter :

I am not sure what is gained with this, aside from it giving you an infinite number of incoming DIDs, each of which can be routed with precision to the intended recipient.

Actually I think that is precisely why. You have to understand that not everyone is running an ata with a 'cloned' line, whatever that is. For me the combination of pbxes paired with voip.ms infinite configuration options is a godsend. Allowing me to run a simple pbx (3cx) on a desktop rather than a separate * box.

VOip.ms never advertised a 'free calling network' like callcentric has. They are different companies with different options.

Now up until a few months ago I was routing a lot of incoming traffic through several callcentric accounts and I've never personally spent a dime with them.

Sorry for rambling but I'm exhausted.

Re: voip.ms and sipbroker

Sun, 07 Jun 2009 20:24:05 EDT

PX Eliezer posted :

said by DogFace05:

If you have a PAP2/SPA type adapter, and you have control over the dial plan, there is no reason whatsoever why you couldn't use SipBroker for outgoing, regardless of provider (including voip.ms).

Yes, of course, but you are one of the smartest guys around, and an industry professional.

Isn't the point to make it easier for the average joes and janes?

With CallCentric, people can access SipBroker just by dialing **275* and they don't even require a paid CC account.

»www.callcentric.com/faq/4/150

»www.callcentric.com/faq/4/130

(And even though I am not a fan of the Gizmo5 service, people on that service can make SipBroker calls just by dialing *).

CallCentric, and Gizmo5, have made SipBroker access EASY and they deserve credit for that, as does any other provider who does that.

Most folks don't like to have to tinker with dial plans. Besides, if it's so easy, let the provider do it (as CC and Gizmo5 have done) rather than the customer.

Re: voip.ms and sipbroker

Sun, 07 Jun 2009 19:58:58 EDT

anon posted : I don't know what calling out via sip broker is, so I am confused; but maybe some of the other confusion is due to voip.ms's requirement that its sip url must use a virtual DID.

For example, if your userid at voip.ms is 123456, you cannot make a sip url of 123456@sip.us4.voip.ms and expect it to work when called from ipkall or anything else.

What you have to do is create a virtual DID such as 11 123456 789 and make a sip url of 11123456789@sip.us4.voip.ms.

I am not sure what is gained with this, aside from it giving you an infinite number of incoming DIDs, each of which can be routed with precision to the intended recipient.

Re: voip.ms and sipbroker

Sun, 07 Jun 2009 19:34:27 EDT

DogFace05 posted :

said by PX Eliezer:

And even if SipBroker works for incoming Voip.MS, it will not work for outgoing.

By contrast, CallCentric works great with SipBroker both in and out.

If you have a PAP2/SPA type adapter, and you have control over the dial plan, there is no reason whatsoever why you couldn't use SipBroker for outgoing, regardless of provider (including voip.ms).

Re: voip.ms and sipbroker

Sun, 07 Jun 2009 19:05:31 EDT

PX Eliezer posted : See this thread:

»sip broker pstn number to voip.ms sub-account number. how?

And even if SipBroker works for incoming Voip.MS, it will not work for outgoing.

By contrast, CallCentric works great with SipBroker both in and out.

Re: voip.ms and sipbroker

Sun, 07 Jun 2009 11:32:34 EDT

sream posted : NY works. sip uris are routed just like any did so it should work.

voip.ms and sipbroker

Sun, 07 Jun 2009 11:12:13 EDT

anon posted : I just noticed something interesting. If you check for voip.ms in the list of sipbroker providers, they show *8570 as the access code.

I connected to a local sipbroker gateway and entered *8570 plus my virutal DID number.

Let's say it was: *8570 11234567123

Surprisingly, it connected. My virtual DID uses the Toronto server, but I assume sipbroker has jiggered things up so that it will work with any server.

Perhaps someone using a different server could try it and let us know.