UKenGB

I am having difficulty with this and could do with some help. I have a Linksys SPA3102 that is set up to handle calls between the PSTN and an account at my VOIP provider (to which I have SIP clients registered) and it all works. But I'm not getting very far transferring this to pbxnsip. To start with, I'm only working on incoming PSTN calls getting to the specified PBX extension. Currently, the SPA is configured to place a direct IP call to my provider (i.e. it's not registered). The dial plan contains the number to be dialled and the Subscriber info contains the authorisation info, i.e. username and password, the former is actually the same number as is being called but that's OK. This is all as the SPA should be configured and as I said, it works perfectly. But when I simply change the address to that of the PBX rather than my provider's account (username and password are set the same to make this easier) it fails with the following error in the PBX's logfile:- "Received incoming call without trunk information and user has not been found" The trunk is set up in the PBX as a 'SIP Gateway' with the Account=UserName which is the same as on the SPA and the correct password. The Proxy is set to the address and port of the SPA (but that should only be relevant to outgoing calls that I am not troubleshooting here) and the domain is set to the address of the PBX host. In fact all the addresses are the DNS names rather than numeric, but they are all correctly resolvable so that shouldn't be an issue. Oh, it is set to send calls to the extension I want. Part of my problem is understanding how the trunk is supposed to work. I presume this type does NOT try to register, so the correct methodology would appear to be direct IP calling and I would think that I am therefore correct to be calling: <trunk username>@<pbx address> which should get picked up by the PBX and handed to the extension as specified in the Gateway Trunk setup, but it doesn't. I just get that error. What do I need to set in the Trunk to tell it to accept these calls?

I have since discovered that Service Flags have already been incorporated into Dial Plans (the perfect solution of course) but not yet finalized for release. Hopefully this won't be too long until we're able to do what we want.

How about Snom just recognise that as they don't currently have any Mac or iPhone softphones (and I suspect unlikely to for the foreseeable future) they ALLOW extension registrations from e.g. Counterpath's Bria. They could add more, but I guess each would need to be coded as an 'allowed' product. However, this would at least be a start and cover all the client OSs of any importance. Snom also have some existing relationship with Counterpath as they already 'recommend' other Counterpath products (not for snomONE, obviously :-)

Certainly looks promising. I presume you would need to use special ports so the the appropriate device got the connection? Do you have a link to Sangoma product literature that covers this?

Well, Apple for a start, but I'm sure there are others now and more in the future. I agree that it is a messy subject and hard to resolve for all parties concerned.

I don't think you're reading my posts carefully enough. I actually stated that I did NOT have a problem with a single domain restriction and this is not about "intellectual property and licensing". My last post simply pointed out that Snom have made certain specific claims about snomONE and they are are not actually true. I don't see how you can defend or deny this when I have quoted (direct from Snom's own website), the claimed spec that you have here categorically denied. I will also state again that I CAN see why Snom might want to limit the use of third party products that are in direct competition with their own. But I do NOT agree with this restriction applying to products that Snom themselves can NOT supply and which therefore canNOT affect the sale of Snom products. If Snom wanted to sell their own softphones, then again I would understand, but this is not the issue since their are NO SUCH Snom products. That is why I find this restriction so inexplicable, as well as preventing me from doing what I wanted with snomONE. Don't forget, my intention was to always pair snomONE with M9 hardware, but I need to compliment that with softphones. So again, I understand and do not necessarily disagree with what Snom want to achieve with this restriction, but I think it has been implemented in a clumsy way that unintentionally precludes the possibility of using other products about which Snom don't need to concern themselves and this will adversely affect the overall sales of snomONE, but for no benefit elsewhere as there can be NO sales of Snom softphones to protect. Unless Snom are about to launch softphone products for the Mac and iPhone - in which case, tell me more.

I must look into that, but how would it work? How would you direct the PBX to connect with SIP over USB?

Some sort of system as you suggest would be fair, but you need to consider softphones rather than other non Snom hardware. A single user on their Mac/PC might want to connect to several extensions and it would be unfair to have to pay for each extension they use as it is still only 1 person. No point in putting any more effort into thinking up a good workable scheme unless Snom say they're open to suggestions.

I cannot help but remind you of Snom's own proclamations regarding snomONE. The following is from the snomONE FREE page:- Multidomain ... Full feature set with every version (blue, yellow, free) Looks clear enough to me. I think this is what annoys the most. Misdirection that cannot be seen as anything other than outright lies.

Any chance Snom/pbxnsip would create a driver for the Sangoma adapter? It would be such a useful device.

Well I have read all I can find about the 3 editions and missed that so it's certainly not clear. However, it's a quite understandable restriction and not a problem for me. But Snom make a BIG point that the 3 versions are full featured with no limitations, but it is now becoming apparent that they are being VERY economical with the truth. For many obvious reasons the support issue you mention is of course a complete red herring. I still maintain this is a small minded and misplaced policy. I don't believe there is anything to gain and much WILL be lost. BTW, I sorted the issue with the Gigaset, but I guess that's rather a moot point now.

It's pretty simple to me too. I want to make use of Snom's M9 with snomONE, but with the ability to use additional softphones and also a door phone and due to this policy under discussion that is impossible. Not only that, but it appears they are keeping quiet about this with NO mention of it on the Snom website which has caused a lot of apparently wasted time and effort. If I was just after a free PBX to use with all NON Snom clients I could understand their point of view, but that is not the case. In fact, I'd have been interested in Snom's Softphones and door phones IF THEY MADE THEM, but they do not so I HAVE to use third party products. So it doesn't matter how many of Snom's products I buy. If I want to augment this with more than 2 registrations of products, of a type that Snom does not themselves produce, I am not 'allowed' to do so. If they just specified that you have to use more Snom registrations than third party, hey that would make sense and I could live with that. But as it is... As you say, it is very simple. If Snom want me to sell their Yellow and Blue versions of snomONE, they have to allow the use of softphones in the free product. I cannot tell you how disappointed I am about this, but with this current policy it is unworkable.

Now that DOES look interesting. But again, it needs a driver, however, I'd say there's more chance of this than for e.g. Apple's USB modem, plus it is exactly made for the job which is never a bad thing. A USB connected FXO gateway seems like an ideal solution. Good find.

My comment about "waste of time" referred to the last few days I have spent getting familiar with snomONE only to find a stupid political decision by Snom renders it apparently useless for my purpose and I believe stupid is defined as "lacking intelligence or common sense" which IMO fits this perfectly. My requirements for 'third party devices' is entirely limited to products that Snom DO NOT SUPPLY, so what do they gain by not allowing their use? It is very clear to me what they will lose if this is as bad as it now seems. Regarding the Snom softphone, I can easily dismiss that as worthless to me since it doesn't run on Macs - case closed. Back to pbxnsip, I am still unable to determine the real differences between the Basic and Pro editions. The web site is completely contradictory (ON THE SAME PAGE), which as I said, doesn't inspire confidence. So, does the Basic edition allow the use of Service Flags and unlimited Trunks, or is that a lie too? My frustration and irritation is largely borne out of the fact that I do think it's a nice product that I was so pleased to see 'apparently' ticked all the right boxes and I was enjoying learning all about it, only to have my hopes dashed like this :-(

Hi Matt, I know you're not Snom, but appreciate your participation. Do I understand correctly then that this limitation DOES apply to softphones? This is so stupid of them. I can understand that they don't want to be supporting the competition, but since they effectively don't produce softphones (their crummy old product is Windows only and really doesn't count) and as you point out, also door phones (something else I want to incorporate), what are they thinking? Also, it is unforgivable that they basically keep this secret. The Snom website clearly states - "No limits, ALL features in all editions" and now, it's only after apparently wasting days on this I discover that was a lie. Let's be clear on this, what constitutes a third party device and is this a domain wide limitation or per extension. IOW, I was trying to use a Siemens Gigaset until the M9 arrives, but would that count as 1 device, or 1 device for each extension to which it registers? I realise that I could purchase pbxnsip, but apart from the obvious inconsistency in products from now the same company, there is a basic problem of cost. I want to be able to supply systems for residential and small business and the former isn't going to be paying the sort of costs pbxnsip seem to want. In any case, I've spent the entire morning researching this and to be honest it took that long just to get some idea of the costs and I don't appreciate companies making obvious information like this so hard to come by. Then there is the contradictions I find about the PBX regarding the various levels that are available and what they include. Specifically, the comparison chart states the Office Basic edition has no Service Flags and only 2 trunks, yet from their web site:- "Limited Accounts With the Office Basic IP PBX, your company benefits from features such as : - Auto Attendants - Hunt Groups - CO Lines - Service Flags Limited Trunks With the possibility to connect to many different devices your Office Basic IP PBX includes unlimited trunks." This is taken from the same page that they display the chart with the totally contradictory data of NO Service Flags and only 2 Trunks. This is the sort of amateurism that puts me off. This is looking like it's all just a big waste of time. snomONE looks like a nice product and I've been very keen on getting involved, but if I cannot make use of softphones and a door phone, then as I said before - it's a non starter and I'll look elsewhere for an equivalent product on which to base my business. Unless I'm wrong about all this, in which case I take it all back.

Where has this been aired? I can find no topics on this subject which is causing me great concern. None of the info on Snom's site makes any mention of such limitation and it is only a passing comment by a support person here that alerted me to this and caused me to search further. I guess first of all I need to find out exactly what this entails. Is this limit per extension or per domain? What do they mean by 'third party devices'? What about the M9? Since Snom can't supply their own Softphones (PC, Mac or iPhone) it seems harsh to artificially limit the use of other's products of this type. Or am I getting this completely wrong? Does it perhaps only relate to other hardware devices? I need to get to the bottom of this because if I cannot use the softphones I need, then for me (and I suspect many others) the use of snomONE is a non starter.

I can see no reason why a modem could not be used as a PSTN gateway. They are specifically designed to get the PSTN audio stream into the computer. The only problem is the lack of drivers to 'connect' it to the PBX. I am VERY keen to look into the possibility of using Apple's external USB modem as a PSTN gateway into a Mac. The problem is - no driver. I am not the only one to take this view. There is another Mac PBX project called Afelio and its developers make specific mention of their intention to do this.

I've been trying to find out more about this, but can find NO mention of it anywhere. All I can find is that all versions of snomONE support ALL features, the only limitation being the number of extensions. The info available for snomONE makes a big thing of this very fact, there are NO limitations apart from the extensions (which I agree is entirely reasonable). What do you mean by 'third party devices'? Any SIP client not made by Snom? Are you saying that this limit is per extension or per domain? Where does this info come from?

Er, what? This is news to me. Can you please elaborate on what you mean. Mind you, I don't think that's the issue here as I was trying it with NO other registration on ANY extension.

So you're saying we WILL be able to do this soon? When?

So it would be reasonable to ignore address books on the PBX and set up LDAP access on the M9 and let the soft phones use whatever they have? This would be good since the soft phones would all have access to appropriately shared address books which could also sync to the LDAP server. IOW, you could set up a system that required no manual updating. Yes? What about CardDAV?

Any suggestions regarding setup? I am trying to register a Gigaset S685IP to snomONE and it simply refuses to register. I am already using a softphone that I was able to easily register to the PBX, but using the same info on the Gigaset and it refuses to register. I turned off the softphone just in case there was a problem with multiple registrations to the same extension (shouldn't be, the limit is still set to 5 and these are the only 2), but it made no difference. I'm a bit stuck really. The Gigaset registers directly to the VOIP provider and works perfectly, but won't to the PBX, yet all the settings look good. Anyone done this and aware of any gotchas?

This seems very close to what I would REALLY like to see, i.e. To change dial plans according to day and time of day. I want to set up least cost routing, but (at least here in the UK) this often varies by day and time, but dial plans have no concept ot time. So why not incorporate SFs into dial plan control so e.g. a call would use different trunks at different times of the day and on different days? It may well be possible to get the same effect with some external scripting and direct URL control, but it really ought to be configurable within the PBX. I'm sure I'm not the only one who wants this.

Oh yes I agree, in a business environment, each with its own extension is best, but then it's reasonable to assume they will be paying for the Blue or Yellow versions to get sufficient extensions - unlike the home user. But I want to be conversant with both scenarios and understand the optimum configuration in each instance. However, there is still an issue with lack of integration between the DECT and the SIP domains. Even with a PBX extension for each handset, once you add in additional SIP (non DECT) clients, the connectivity between them all is not uniform - unless you completely eschew any DECT functionality and rely entirely on SIP/PBX intercom and transfer, which would be a shame because the DECT version is easier to use as you don't have to remember esoteric numbering to do it. This is how I would 'want' to see it done:- When the M9 is configured with snomONE, the PBX tells the M9 about the additional (non DECT, i.e. softphones or other SIP clients) extensions it has and the M9 then adds these to its list of known 'handsets'. So when an internal call or transfer needs to be made, the M9 handset user simply uses the standard M9 methods of doing this, but the list of 'handsets' that is presented also includes those other SIP clients which can be selected and used as if they were other M9 DECT handsets. In this way, the integration between the 2 systems would be TRANSPARENT, which is how it should be. The problem is of course that we are dealing with 2 entirely different systems, but this should be hidden from the user as illustrated above. In any case, what about Address Books? Should the M9 be configured with VCARDs or should a SCSV file (SemiColon Separated Variables) be prepared and imported into snomONE? Or both? The lack of consistency here is clear, but it is not even obvious in which location is it best to put such data. Maybe that's a different topic (unless you want to cover it here :-)

So it's just 'Paging' really? How can you use the PBX to just ring another extension (ignore multiple registrations) in the same way as in the DECT world? Overall, the problem I am trying to get my head around is how best to integrate an M9 into the snomONE setup alongside other NON M9 SIP clients (be that softphones or even other Snom SIP hardware). Mainly this involves figuring out how to perform tasks like Intercom and Call Transfer. While both the PBX and the M9 have ways to do this, they require different methods of operation which is not ideal. I see that the M9 setup includes an option to specify it is being used with snomONE, but how does that modify the M9's behaviour? Whilst I can see some advantages of every handset (M9 and other) having its own extension, there are obvious disadvantages to that, not least of which is the licensing limitation on the total number of extensions. Also, the M9 itself provides most of the functionality that would be gained by using separate extensions. In fact the DECT handsets provide simple Menu operation of Intercom and transfer instead of additional numeric dialling to achieve the same result using the PBX. I was not thinking of putting everything onto one extension, but maybe assign the M9 in that way and use separate extensions for the other SIP clients. Truth is, I'm still not 100% sure of the best way to achieve integration between the PBX and the M9 - hence my request for others' suggestions and ideas.