UKenGB

Excellent, thanks. At last some very useful real information. However, I do have a problem that is almost made more confusing with the above. My PSTN Gateway Trunk uses the same FQDN (of the Linksys itself) in the Domain and Proxy fields, the latter including the port. The account and password is also the same as set up in the Linksys (although it doesn't look like any auth is requested). IOW, I would think the match should be good. But I found that incoming PSTN calls would be consistently assigned to different Trunks which ALL register to the VOIP provider so no domain names or IP addresses would match at all. I then discovered that if I entered the Linksys' FQDN in 'Explicitly list addresses for inbound traffic:' in the PSTN Gateway Trunk config (empty for ALL other Trunks) it all seemed to then work with calls being correctly assigned to the PSTN Gateway. But I have now noticed some calls that are NOT being correctly matched e.g. 010/12/19 19:36 077xxxxxxxx 01932xxxxxx(44) Ken.work The above is a (test) call from my mobile to the PSTN number, but it is being incorrectly assigned to the Ken.work Trunk - a test Trunk that is registered to the VOIP Provider. Later :- 2010/12/20 16:18 077xxxxxxxx 01932xxxxxx PSTN Gateway Another test call from my mobile to the same PSTN number, but in this case it is correctly assigned to the PSTN Gateway Trunk. Neither of the above are isolated incidents, but something that puzzles me is the extension number (44) that appears in the first line. I'm not sure why that is there and what does it mean. Is it significant to this problem? In fact I've just realised that the (44) means the extension to which calls assigned to the Ken.work Trunk were being directed, so it appears by virtue of the Trunk that has been assigned and therefore has no relevance to which Trunk is assigned. At least, it shouldn't have. However, the PSTN Gateway Trunk directs calls to a Hunt Group, so why is that not specified in the Call log in the same way? Bearing in mind that the Linksys' FQDN is in 'Explicitly list addresses for inbound traffic:' in the PSTN Gateway Trunk config for BOTH the above calls, I fail to see how it can possibly match this call to a Trunk that has no relationship to the incoming call data, but that seems to be exactly what it has done for that first call. Sorry, I seem to have Hijacked this thread, although the subject mater is relevant. Should we move this to a new thread?

This explanation linked to is seriously lacking in clarity and doesn't help much with understanding how a Trunk is 'assigned' to a call. I have a Linksys SPA3102 as the PSTN Gateway and although it apparently works, in fact some calls get assigned to the wrong Trunk and not the actual PSTN Gateway Trunk. This is of course a real problem since it means calls get misrouted. So I need to be able to specify ABSOLUTELY that calls incoming from the Linksys (i.e. from the PSTN) DO get assigned to the PSTN Gateway Trunk. When trying to find the correct Trunk, the PBX apparently looks for:- - The incoming call matches the IP address of the outbound proxy of that trunk etc... but how is a telephone call matched to an IP address? Sorry if that's a bit silly, but what part of the call is being matched? The Request URI, the address of the packet, the From Header, the To Header, all of the above...? The wording of the explanation is somewhat obscure. When the expression "Domain Name" is used, does that mean the Domain part of a FQDN or the Domain field in the Trunk config page? When the call is correctly identified, the log shows:- - "Identify trunk (domain name match) 1" What does that mean - EXACTLY. What is really being matched to what? Without a true understanding of what snomONE is doing with this 'matching' it is impossible to ensure such matching will be correct EVERY time and it MUST be correct or as I said, calls get routed incorrectly with potentially disastrous consequences. So could we have some additional explanation here please?

Then you should be Ok as when I complained about the snomONE restriction I was told in no uncertain terms that I should buy pbxnsip as that definitely has NO such restrictions.

I agree that the installation is not as smooth as it should be. Leaving the HTTP and LDAP ports set at the standard is somewhat daft since it can prevent the PBX from starting at all. The information about this and how to fix it is available, if you search for it, but that shouldn't be necessary. I run ports 81 and 390 to avoid this issue, but why not make those the defaults, then at least it would start. If those are not ideal for you, you can then change them in the web interface. Just make sure that the install notes make it plain what is the default HTTP port. There is of course the question of why the PBX wants to bind to the LDAP port anyway. It's not an LDAP server so it shouldn't be doing anything of the sort. The free version of snomONE is restricted to 2 NON Snom registrations. I believe the next level up (paid for) raises that to 4. I guess the top level, no holds barred has no such limit, as is the case for the pbxnsip version. I have railed against this on the forums, but to no avail. I can see how they want to protect the market for their own hardware, but they don't even allow softphones, which is stupid as Snom don't make one themselves. But as I said, I can see why they don't want to provide a free PBX to use with their competitors phones and so I think you either need to find a different PBX, or pay for pbxnsip.

That's the start/stop control script. The pbx.xml file is where I said it is. Look in the crash log to find out more about why it is not starting.

Indeed. Maybe there's a deal to be done :-)

A couple of points for Snom to consider. Apple is deprecating the use of StartupItems, preferring instead that services are started using launchd. How are Snom dealing with this? In the meantime, I find the 'restart' function of the PBX script often fails so I have inserted a 'sleep 2' between the 'stop' and 'start' functions to give the process time to fully quit. This is better, but I have still seen it fail, so may need to increase that delay. I'll try 3 next. To facilitate this process, I have deleted one of the scripts and instead created a hard link to the other so it doesn't matter which I edit - they are both the same file. These 2 changes are how it should have been after installation.

The pbx.xml file can be found in /usr/Applications/snomone. However, I think that whole folder gets created the first time the pbx runs although I'm not 100% on that. In any case, as long as you're not running OSX Server's Web service, you can run the PBX on standard settings, log in (that would be on the default port 80) and change it to something else, restart the PBX and log in again using the new port. If you ARE running OSX Server's Web service, just shut it down while you perform the above port change for the PBX and then restart the Web service. It'll only be down for a minute or 2 and this would undoubtedly be easier than having to wade through the unformatted XML of the config file. I have to say there's a lot of room for improvement with regard to the documentation for the OSX install and general layout and basic control.

I look forward to the new release with this configuration option.

Just spotted this topic while looking for info on exactly this problem. I have set up an entry in the Domain Address Book (Me and my mobile number). When I call in it is passed to the Hunt Group and so to the M9 handsets which display only the number (of my mobile of course). I checked the logs and the PBX is NOT passing the name from the Address Book. I can mix the incoming number and the name of the Hunt Group using it's configuration option, but I cannot get it to pass the name resolved from the Address Book. If I read the original post correctly, this is by design? You cannot pass the names from the Address Book on with the call if it goes to a Hunt Group? Let's assume that means it IS possible if the call is simply passed to an extension, but what nonsense is this that using a Hunt Group precludes the use of the Address Book to name the caller? There needs to be another Hunt Group option to use the name from the Address Book instead of the number. Or did I misunderstand and this is already possible? In which case why is it not occurring?

Any resolution to this?

OK, got postfix to accept the helo from Localhost, but now there's another problem:- status=bounced (mail for mx.home loops back to myself) The email is being sent by snomONE and accepted by postfix, which than complains about it looping. Can anyone suggest how to configure postfix to accept these email messages from snomONE running on the same machine?

This is the error I get from postfix when it rejects email sent from the pbx. It is because snomONE is using 'localhost' in the 'helo' to the SMTP server, which is postfix on the same machine on which snomONE is running. There are several ways to fix this:- Remove that restriction from postix's config. I'd rather not do that as it may open the door for abuse by others. Configure postfix to accept a helo using localhost. What I've tried hasn't worked so would be grateful for pointers on this one. Configure snomONE to use a different name in the 'helo'. This last options is preferable, but I cannot find how to change that. Can anyone explain how I can change the name snomONE uses in the helo when sending email notifications of voicemail?

So basically manually add a dummy registration. Brilliant. The iPhone rings while the PBX is thinking about it and if not answered it eventually goes to the mailbox. Seems to work perfectly:-) Thanks for that, a wonderfully sneaky solution.

Ah, but there is no other mailbox, that's what I want the PBX for in this case. Sounds interesting, but I'm not sure what you mean by "static registration"? Could you please elaborate on what you mean by this setup.

No, I obviously wasn't clear. Sorry. The situation I am working with is snomONE on the local LAN behind a NAT router and hence not accessible from the Net. The PBX uses SIP Registration trunks to the accounts at my VOIP provider. One of the SIP clients is an iPhone running Bria and if this is away from the LAN it would not be able to connect to the PBX, so instead it registers to the appropriate account at the VOIP provider - in parallel to the PBX. This is the only way to let it receive calls whether on the LAN or half way around the world, without exposing the PBX to the 'Net which I am not about to do. So if the iPhone answers the call, it gets cancelled to the PBX. But if it does not, I want the PBX to pick it up and send to the mailbox. Obviously if the PBX immediately picks it up and sends to voicemail, my whole plan fails:-) So I just need to introduce a delay before the PBX Picks up the call. Is it possible? Here's another thought. When the PBX receives an INVITE, does it accept the call and then try to find an extension, or does it NOT accept the call until it has a destination, whether that is an extension or a mailbox? I guess this is fundament to what I'm trying to do.

Ah but the thing is, I don't want it to answer the call so that while 'waiting' it is possible for the call to be answered by another client registered to the VOIP provider in parallel to the PBX's trunk, IOW, I want it to just be an answer phone for that account at the VOIP provider so I can use the line when I'm away (and not able to access the PBX) but if I don't answer it, then the PBX picks it up. Is it possible to have it NOT answer the call until the voicemail timeout expires and then pick it up and go straight to the mailbox?

I have an extension set to go to voicemail at the default (20s), but what will happen if there's no registration for that extension? I actually want it to wait for the prescribed time and then answer with the mailbox (unless the call was taken elsewhere and cancelled with the PBX), but I'm concerned that it may go immediately to the mailbox if there's no extension actually registered. Will it go immediately or wait? I've not tried this yet as there's still so much else to figure out, but if I cannot do it this way, is there any other way to force it to wait before sending to voicemail?

Will do, just need to do some more testing to ensure I've got it all correct and it works reliably as it should,

OK, got it working, but had to enter the SPA's IP address (or FQDN) in the "Explicitly list addresses for inbound traffic:" field. Once this was done the PBX was able to recognise the call as coming on on that trunk and deal with it appropriately. Whilst this is not a problem, I am not entirely sure why it was necessary since it seems to me it ought to have been able to do this without that last step. So if anyone can shed any light on this I'd be grateful. But in the meantime it is working for inbound and outbound calls with the former providing the CID of the real calling party, i.e. the SPA is receiving it from the PSTN and passing it on to the PBX. Perfect:-)

I had seen that, but it is fundamentally wrong and shows a lack of understanding of the SPA by the author. Once you understand how the SPA is logically structured, you don't need to bounce the calls around as suggested in that article. It took me some time, but I now understand the relevant bits of the SPA and as I said, it has been working as a PSTN <-> VOIP gateway for the last few months, but that was with my VOIP provider. In this case, the info used was a username and password (with which the SPA was able to authenticate to my provider's server) and then the number that was the target of the connection. So a PSTN call would arrive at the SPA and it would immediately place a call with my provider to the specified number. The PSTN line continues to ring until the VOIP call is picked up. This is straightforward PSTN -> VOIP gateway, no messing around with dialling in to get another dial tone in order to then make cheap International calls. The SPA can do that, but that's not really a function for a straight PSTN gateway to an IP PBX and certainly not what I want. Anyway, it works with my provider. But I cannot yet get it to work with snomONE. I believe the problem is that snomONE is not correctly configured to accept the call. It sees the incoming call and negotiation commences, but the PBX eventually reports that it cannot find any trunk information and the call fails. So I need to somehow configure it to understand that this is a call coming in on that trunk (i.e. the PSTN gateway) and then it can be directed to the extension specified for the trunk. But the trunk configuration is for incoming AND outgoing calls and it is not clear which of the displayed fields relate to which direction of call. As I said in my last post, I am trying to gain a better understanding of what the various fields mean so that I can then (hopefully) fill them with the correct info and it will all work perfectly:-) The snomONE manual is not entirely clear on what the fields all mean and just provides examples which are simply numbers, but with no indication of to what they refer. Are they telephone numbers, IP addresses or what? It shows the username as what looks like an IP address followed by a port number, but how can that be a username? In any case is that for incoming or outgoing calls? Or is the manual simply wrong as it looks suspiciously like they got the fields mixed up when they printed it. Sorry, rambling again. But I have the M9 now to set up and so need to crack this PSTN Gateway problem.

That would appear to rule out OSX Server being the problem. Snom obviously need to investigate further and get to the bottom of this.

Problem is, I don't know what the various fields are in snomONE. I know what all the information in the SPA is for, I have set it up to successfully work with my VOIP provider. What I don't know is which bits of info in the PBX relate to which function. In the Trunk setup:- Type: Not sure what the difference is between SIP Gateway and SIP Proxy. Neither work. Proxy Address: I assumed this was where to send outbound calls and would therefore be the SPA3102, but the PBX is then trying to register to the SPA which is always going to fail as it is NOT a SIP server. Does this have ANYTHING to do with incoming calls to the Gateway? Username and Password: I assume these would be used by the SPA to authenticate. Account: No idea what this is. What does this relate to in the SPA's configuration? I'm sure if I can get these correct it will work, but right now I'm having difficulty cross referencing the various fields between the 2 devices.

AFAICT that is exactly the same issue that was causing it to crash for me, yet was fixed with that new release. Consider also the fact that even the earlier release worked ok on a different Mac and I think we can assume the problem is not something endemic in OSX as was claimed. What Mac are you running this on? Regular OSX (Client) or OSX Server version?

I just read a VERY unfavourable review of this device so maybe it's not the saviour we were hoping. Still worth finding out if we can make it work though. Let us know what you find out.