Jump to content

Kenny Munro

Members
  • Posts

    11
  • Joined

  • Last visited

Everything posted by Kenny Munro

  1. I had the same issue also, perhaps significantly, with a Comodo EssentialSSL wildcard certificate. I did two things, one of which fixed it but can't be sure which! 1. I uploaded the various intermediate certificates that came with the Comodo SSL certificate to the server as Trusted Root CA for server authentication 2. I updated the phone firmware to the latest version (for the 870 in my case) After that everything seems to work fine! Hope this helps you.
  2. Ah OK, that's annoying (but at least I wasn't missing something obvious!) Thanks for the reply and I hope you can find a solution in the near future!
  3. I'm having problems figuring out how to setup inbound DID routing where the DID number is given in a custom header - in this case X-voipnow-did: INVITE sip:0029*012@92.60.105.171:5060;transport=udp;line=1679091c SIP/2.0 Record-Route: <sip:78.109.167.249;lr=on;ftag=as30270734;did=b85.e9a03053> Via: SIP/2.0/UDP 78.109.167.249:5060;branch=z9hG4bK8d94.1802a331.0 Max-Forwards: 69 From: "07738588786"<sip:07738588786@78.109.167.249>;tag=as30270734 To: <sip:0029*012@78.109.167.249:5060> Call-ID: 7df0086e20d105c646034db51ab10d31@78.109.167.249 Contact: <sip:07738588786@78.109.167.249:5060> CSeq: 102 INVITE User-Agent: contactPro Date: Tue, 29 Sep 2015 10:31:42 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO Supported: replaces, timer X-voipnow-extension: 0029*012 X-voipnow-infrastructureid: 01c9bd49d8f2 X-voipnow-did: 01189072971 Content-Type: application/sdp Content-Length: 266 Please could you provide instructions on how to do this (at idiot guide level please!!!)
  4. I'd followed the setup procedure in the manual which is essentially the same as that link I think. No luck! I've done a bit more digging around on Exchange though and noticed these event logs: A call was received with the following parameters: Calling Party: "sip:xxxxx@pbx.x.co.uk;user=phone", Called Party: "sip:740@pbx.x.co.uk;user=phone", Diversion Information: "", Referred-By Header: "", Call ID "ba7f2aaa@pbx". followed by: The Unified Messaging server has received a call from "xxxxx", with user extension "" and a call ID of "ba7f2aaa@pbx". The users extension in Exchange is 740 so it looks like the issue is that exchange is not recognising the extension from the call info passed. Not sure if it's related, but I tracked down this post: http://social.technet.microsoft.com/Forums/en-US/exchangesvrunifiedmessaging/thread/b4aa0e7b-ac34-42bf-b303-0d618203bed3/ which implies that the way Exchange 2010 processes the SIP headers to determine the extension is different from Exchange 2007. Has anyone got this working with Exchange 2010 or is it just busted?
  5. Having some problems configuring Exchange SP1 UM with the latest SNOM One PBX. I'm not sure if this is an Exchange issue or a SNOM One so apologies in advance if this turns out to be the wrong place to post. For some reason, Exchange does not seem to be recognising the target extension number when a caller is diverted to voicemail. Instead of getting the "you've reached the mailbox of ...." message, they get the generic autoattendant ("To access your mailbox, enter your extension, to contact someone, press #" What's odd, when I call voicemail from the extension, it works as expected - it knows who I am and prompts for the pin to access messages. It only seems to be an issue for external callers. I'm kinda stuck right now so any pointers where to look would be greatly appreciated. Thanks, Kenny
  6. I'm having exactly the same issue - did you ever find a fix?
  7. Sorry, should have included the version - it's 4.2.0.3981 (Win64) I don't think this is related to the Skype issues. We've been having the problem for a few weeks ang Googling around I haven't found any suggestion that anyone else is having problems with Skype Connect
  8. We have one of those Skype SIP Connect lines into our system which has been working fine for several months. All of a sudden, it's no longer registering and we're getting this in the log: [1] 2011/06/07 22:03:34: TCP: TOS could not be set, code 0 [4] 2011/06/07 22:03:34: Certificate for VeriSign Class 3 Public Primary Certification Authority - G5 not available [5] 2011/06/07 22:04:06: Registration on trunk 5 (SKYPE Connect) failed. Retry in 60 seconds In the certificate screen I have this: VeriSign Class 3 Public Primary Certification Authority - G5 Rejected Root CA for server authentication I've tried deleting the cert but it just reloads it when it next registers. I'm all out of idea - any suggestions? Thanks, Kenny
  9. I was able to fix this by making the .171 IP the primary one on the NIC and putting the .168 as a secondary IP under the advanced options. Once I did that everything came good. Still think it's likely a bug though!
  10. I'm having a problem getting provisioning working. I have SnomONE build 4.2.0.3958 (also tried 3966) running on Windows 2008 R2. The windows box has 4 public IP addresses: 92.X.X.168 - 92.X.X.171 SnomOne is configured to be bound to the last of these (.171) which is fine, the web interface etc appears on the correct IP. During the provisioning process, however, the phones just hang. After a bit of digging, I discovered that the response to the initial provisioning request is as follows: <?xml version="1.0" encoding="utf-8"?> <setting-files> <file url="http://92.X.X.168:80/prov/snom_3xx_fw.xml?model=snom370" /> <file url="https://92.X.X.168:443/prov/snom_3xx_phone.xml?model=snom370" /> <file url="https://92.X.X.168:443/prov/snom_3xx_fkeys.xml?model=snom370" /> <file url="https://92.X.X.168:443/prov/snom_web_lang.xml?model=snom370" /> <file url="https://92.X.X.168:443/prov/snom_gui_lang.xml?model=snom370" /> <file url="https://92.X.X.168:443/tftp/snom_370_custom.xml" /> </setting-files> As there's a completely different web server running on .168, this obviously doesn't work! Is there a setting somewhere that I've omitted to set or is this a bug? Many thanks, Kenny
×
×
  • Create New...