PondGroup

Many thanks, worked perfectly - except that I had to copy webminlogin.htm back into /usr/local/snomONE/html/ because the Admin section of the web GUI stopped working.

We have recently installed a snom ONE Plus (Yellow) which works very well. The problem I have is that when I go to the Admin --> Web Page Control menu, all of the HTML Templates are missing, apart from 2 which I modified. When the system was originally set up the list was complete with every single XML file in there. I'm not sure at what point they disappeared, but it was either after an update or after switching around the primary domain and one of it's aliases. I have SSH access to the box if I need to change and config files. Below (and attached) is a screenshot:

Thanks for the update Katerina, it's very good news. As you say - fingers crossed!

I just noticed, a lot of this is repeated in a post I started back in December: http://forum.snomone.com/index.php?/topic/5567-missing-leading-zero-on-inbound-caller-id/

Thanks for the replies. Unfortunately, I had to remove the system from the client site as they could not work with this problem. Mr X, I did try a support call with Sangoma and spent a few hours talking to them, sending logs & conf files to no avail. They escalated the call and then never got back to me. My own research turned up the following: Sangoma NBE passes a number of fields from the ISDN setup message through to the routing rules section, they include dnis and ani (i.e. called and caller numbers) They also pass the entire ISDN setup message in the field pstn.in.isdn.setup.ie.0xZZ.0xYY They do NOT pass the ISDN TON (Type Of Numner) field, apart from in hex format in the setup message. A RegEx Guru, or hopefully Snom ONE expert could write a routing rule to append either a single or double zero the the sip.out.from.uri field depending on the content of the relevant ISDN call setup message. You already have a pstn.out.ani.type, so why not include a pstn.in.uri.type? Fair enough if this is a Sangoma problem, I'll speak to them (again). My main concern is that I'm about to purchase a Snom ONE Plus T1/E1/J1 and want to avoid the same problem. Does anyone know if the Snom ONE Plus uses Net Border Express or does it have its own ISDN gateway/interface software?

We have exactly the same problem using Snom ONE and a UK PRI ISDN. Other systems (Asterisk to name one) use the ISDN TON (Type Of Number) field which can be extracted from the ISDN call data. I believe this data is already passed through to the inbound call routing rules (in the NetBorderExpress pstn.in.isdn.setup.ie.0xZZ.0xYY field), but there is no way to set the sip.out.from.uri headers using it. I'm sure some RegEx guru could write a workaround based on the binary value of the relevant ISDN headers, but I'm not that guru unfortuantely. There is already a pstn.out.phoneNumber.type, we just need a pstn.in.phoneNumber.type and we can get NBE routing rules to do the rest. The "official" snom Wiki suggestion (Here...) is pretty useless too - it basically forces a 0 to be appended to every incoming call. Brilliant for local, but no use whatsoever for international calls. This really needs to be resolved before we can start selling this as a serious ISDN PBX - I can't comment for SIP as all our clients so far still use ISDN for external calls. All business users need to be able to hit the redial button on a missed call and get through. Having to guess if it was a local, national or international number is not going to go down well!

Good Day, We've just rolled out our first SnomONE install with a BT ISDN30 PRI line connected to a Sangoma A101 card. The inbound caller ID we see getting passed through to the handsets is always missing the leading zero. As per a Snom FAQ, we can (and have) amended the routing rules on the Sangoma side of things to manually prepend a 0. This works well for local and national calls, but international calls are then still missing a zero. Sangoma support scratched their heads and couldn't come up with an answer. I'm hoping your superior knowledge and experience will prove them wrong ;-) I reckon there's a way to write a fancy Regular Expression in routing-rules.xml to replace sip.out.to.displayName either based on the number or by extracting some of the ISDN Information Elements from pstn.in.ie (I think) Any tips apreciated and If I work it out myself, I'll post the solution for others to share. Many thanks Pond Group.