PondGroup Posted December 20, 2011 Report Share Posted December 20, 2011 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. Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted December 21, 2011 Report Share Posted December 21, 2011 Is there any way snom ONE can figure this out? I mean are the numbers somehow looking different to the PBX? I am not the biggest Sangoma expert... Quote Link to comment Share on other sites More sharing options...
Vodia support Posted January 4, 2012 Report Share Posted January 4, 2012 I would open a ticket with sangoma, http://www.sangoma.com/contact/technical_support.html Quote Link to comment Share on other sites More sharing options...
PondGroup Posted January 19, 2012 Author Report Share Posted January 19, 2012 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? Quote Link to comment Share on other sites More sharing options...
katerina Posted January 20, 2012 Report Share Posted January 20, 2012 Hi Pond Group, We opened a request to Sangoma for the same problem (our Sangoma ticket number for reference: ). First they said to use the routing rules, like this: <condition param="pstn.in.isdn.setup.ie.0x0.0x6c" expr="1.*"/> Then they explained that this solution will not work because, unfortunately, the pstn.in.isdn.setup.ie.0xZZ.0xYY fields are not populated correctly. This is a bug in their software and they said they are planning a Jan27th release of NBE 4.2.1 which will expose this variable directly instead of using the setup.ie method of retreiving this information. Let's keep our fingers crossed and hope it will work. Quote Link to comment Share on other sites More sharing options...
PondGroup Posted January 20, 2012 Author Report Share Posted January 20, 2012 Thanks for the update Katerina, it's very good news. As you say - fingers crossed! Quote Link to comment Share on other sites More sharing options...
sgwestrip Posted February 22, 2012 Report Share Posted February 22, 2012 Hi Pond Group, We opened a request to Sangoma for the same problem (our Sangoma ticket number for reference: ). First they said to use the routing rules, like this: <condition param="pstn.in.isdn.setup.ie.0x0.0x6c" expr="1.*"/> Then they explained that this solution will not work because, unfortunately, the pstn.in.isdn.setup.ie.0xZZ.0xYY fields are not populated correctly. This is a bug in their software and they said they are planning a Jan27th release of NBE 4.2.1 which will expose this variable directly instead of using the setup.ie method of retreiving this information. Let's keep our fingers crossed and hope it will work. Are we still waiting for NBE 4.2.1 to be released? I see that my Snom One Plus PBX says it is up to date with 4.1.6-1 Quote Link to comment Share on other sites More sharing options...
katerina Posted February 23, 2012 Report Share Posted February 23, 2012 Yes Last week I asked them and they said they have no estimation yet Quote Link to comment Share on other sites More sharing options...
katerina Posted March 20, 2012 Report Share Posted March 20, 2012 Hello everybody, Just to inform you of the status for this problem: we got the new version of NetborderExpress and tested it, it seems it solved the problem. We are working on adding this version to the update server so you can install it, I will get back to you as soon as we are done. Quote Link to comment Share on other sites More sharing options...
katerina Posted March 20, 2012 Report Share Posted March 20, 2012 Hello again, Good news, the update is there. You will need to also modify the routing rules, see complete instructions here: http://wiki.snomone.com/index.php?title=Snom_ONE_plus_missing_0_in_callerid_for_incoming_calls We are looking forward for your feedback. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.