phsean

Idiot me. I installed Exchange SP1 this morning, and PBXnSIP can no longer reach Exchange for either auto attendants or voicemail. Looking through the log files, I see that the difference is a 'SIP/2.0 403 Forbidden' instead of a 'SIP/2.0 180 Ringing' message. I have installed the Unified Messaging Role on another server (not SP1) and can still reach it through PBXnSIP. Does anyone have any suggestions to offer to get this working again? What I'm looking at (if I can't get this working today) is having to: - change the dial plans for 80 Exchange users to the new dial plan on the alternate server - recreate the autoattendants to the alternate server (they cannot switch dial plans) - do the move in reverse before the alternate server makes me give it a license key in 119 days. Don't follow my lead and install SP1 unless you test it first - there's no way to remove SP1 short of wiping Exchange completely and reinstalling Exchange w/o SP1.

Same problem here, fwiw. If a user tries to "Play on Phone" to their own phone, it goes straight to voicemail, but if they "Play on Phone" to another extension, it works just fine. I was going to wait until the new polycom firmware configs came out before taking a closer look at any of our issues, but I just happened upon this thread.

This is not the same thing, but just in case it's useful: we wanted the phone to flash a notification of a second call without an audible beep. Model12 tried to turn the call waiting beep off but my fuzzy memory won't allow me to remember why it didn't work. He ended up changing the onDur to 5 for the Call_Waiting tone in polycom_sip.xml... rendering it so short that it's essentially inaudible. <CALL_WAITING tone.chord.callProg.6.freq.1="440" tone.chord.callProg.6.level.1="-19" tone.chord.callProg.6.onDur="5" tone.chord.callProg.6.offDur="0" tone.chord.callProg.6.repeat="1"/>

Great info, thanks to you both. Since the issues that we're having aren't ones that have caused a huge uproar, I think that we'll wait this out for a while. Whenever there's been time to get the 2.2 polycom configs tied up, could they be posted to the forum?

I had the same non-registering problem with the phone that I tried last week but I wasn't able to look too much into it because of a separate software bug I was stuck chasing down. Would've warned you but I thought you were past that point, I must've misunderstood! (sorry) I was using Winmerge to compare the beta build config files to the Polycom 2.2 config files last week, and there are definitely some differences. The most important ones though seem to be the {variable names} so that PBXnSIP can populate the port numbers, etc. from the web interface. It'd be nice to hear from PBXnSIP which of the other changes in the config files between the files from the beta build and the files from Polycom's firmware download were customized to improve PBXnSIP's behavior and which were changes made by Polycom. If all of those changes between config file versions were made on Polycom's side, then we should only need to insert the {variables}. PBXnSIP said they were testing using the 2.2 firmware -- since both you and I had trouble with the PBXnSIP config files, it could be possible that they were using different Polycom config files than were included in that beta build. Those beta build config files are 100% identical to the ones that we had previously received for firmware 2.1.

Yup, you're exactly right - they're in Installshield build 2093, posted on the forum here for future ref: http://forum.pbxnsip.com/index.php?s=&...post&p=1090 Thanks very much for your help -- wishing all goes well for you tomorrow night.

Not sure if we can do it thataway and get it working 100%... We have a few config options that we've customized to our setup using those config files, like dialplan.digitmap, voice.volume.persist.x, and a handful of others. Unless I'm mistaken, we'll need the config files to keep those options. (I'm very glad to hear that you have 50 2.2 Polycoms successfully running. )

I'd like to upgrade our Polycoms from Sip version 2.1.0.2708 to 2.2.0, so I downloaded 2.2.0 from the Polycom site (http://downloads.polycom.com/voice/voip/sp_ss_sip/spip_ssip_2_2_0_release_sig.zip). I remember seeing (http://forum.pbxnsip.com/index.php?showtopic=340&hl=polycom&st=20) that internal testing for the Polycoms has been using 2.2.0 and that there weren't any noticeable problems even though it's not "officially" certified. What would be very helpful is the PBXnSIP customized versions of the config files for 2.2.0. The files given to us by our good friends at Pulsewan for version 2.1.0 were polycom_adrbook.xml, polycom_master.xml, polycom_phone.xml, and polycom_sip.xml. Is there any way to have the 2.2.0 versions posted here? Or could I get them some other way? Thanks, Sean Not sure if it matters, but our bootrom version is 3.2.2.0019. I can't find the 4.0.0 download from Polycom's site, but if I don't need it to do the SIP update, then I'm not going to worry about it anyway.

Reminds me of our recent callerid problem which a new build from pbxnsip fixed: http://forum.pbxnsip.com/index.php?showtopic=388 Might be worth a look...

Polycom phones do not currently support multicast paging (latest sip app at time of post: 2.2.0) From Polycom support: I now have confirmation that we do not support multicast paging. You can request a feature enhancement at the following link; https://jira.polycom.com:8443//secure/Creat...assword=polycom The more feature requests we get, the faster it will be implemented. Just FYI. But if this is something that you'd like to see added, it couldn't hurt to throw a request their way. Hope they're not upset at me for posting the link -- I'll gladly take it down if asked... really can't see it being abused on this particular forum, though.

Yessir. Put the new build on, and now toggling the Remote Party/Privacy Indication on the Exchange trunk to Asserted Identity has the bugger resolved. What a great way to wind up the day... thanks!

Sorry... I scattered the posts on two topics -- perhaps I'm suffering from a lack of context myself. Reposted here: http://forum.pbxnsip.com/index.php?showtopic=388 along with someone having the same problem but the suggested fix isn't working for us.

Having the exact same problem here since a 2.1 upgrade, but the Assert-Identity toggle doesn't fix the problem, surprisingly (tried all five Remote Party/Privacy Indication settings, but no effect...). I ran a call log and stripped out my test call: Log File What's happening in the log: 2503 calls 2412, 2412 rejects call, 2503 receives "2412 is busy" message, hits 2 to leave a voicemail, and does so. (Exchange UM is running on port 5060 and PBXnSIP is running on the same machine, 192.168.11.4, port 5070) Starting with Line 234, the From header changes from the calling extension 2503 to the recipient extension 2412 when the call is referred to the unified messaging server... why that translation takes place looks like the problem. I have been doing some testing using a clean 2.1 install on a separate machine with a demo key, set up two test users with a completely new (3-digit) dial plan on the same Exchange server, used X-Lite to test, and the problem exists on the test server as well. They've been patient, but the natives are getting restless... thanks for the help!

Since I can reproduce this using a brand new test PBXnSIP installation, I really doubt that this problem is related to just us. I've looked at the trunk settings suggested in the other thread for the Exchange SIP Gateway and I've toggled every other setting that seems related but no luck. Now that I have a test out-of-the-box PBXnSIP installation reproducing the same problem, I can change settings to my heart's content if it's a setting. Whether or not it is a setting, I'm positive that it's related to 2.1 - it wasn't doing this on our production 2.0.3 install, and now both our production and test 2.1 installs are doing the same thing. I really have to get this fixed for our users, who have been pretty patient with me thus far with beta builds and the phone system migration in general. I'll do whatever I can -- my hunch is that it's something internal that I can't fix with a setting, but I would be glad to be wrong. Help?!?

Giving back, in case someone's having the same issue: I was experiencing dropped calls (PBXnSIP was sending my phone a BYE, couldn't see why in the logs) in certain scenarios involving a Hunt Group whose final stage was an Exchange 2007 UM Auto Attendant. We had a basic hunt group setup to forward external calls on a specific number directly to the UM auto attendant without needing to tie up a PBXnSIP extension license with call-forward all calls flagged to send them to UM. It worked fine -- but after the auto attendant sent the call back to a "real" hunt group, if there was no answer, the call would just be dropped instead of being transferred to voicemail (back to Exchange). After some testing on my test server, here's a simple workaround: on your forwarding hunt group, move your final stage UM AA number to the Night Service Number, and create a Night Service Flag Extension that's always on. Now the call coming back from the AA will go to voicemail.

Hmm... this sounds like it could possibly be related to my 2.1 Exchange UM problem. Update: I have been doing some testing using a clean 2.1 install on a separate machine with a demo key, set up two test users with a completely new (3-digit) dial plan on the same Exchange server, used X-Lite to test, and the problem exists on the test server as well.

Okay. We're keeping up with the latest builds (putting 2115 on tonight). You had mentioned not having the same issue with your UM server; please let me know if there is any other Trunk debugging that I could do that would be helpful to get this fixed up. And thanks!

Tried all five Remote Party/Privacy Indication settings, but no effect... flopping that shouldn't need a service restart, should it? If so, we'll have to retest it after hours this evening.

Regarding the Exchange UM Caller ID issue posted earlier: I removed the polycom files from the html directory, restarted PBXnSIP and my phone (just to be sure) -- no dice still. So I ran a call log and stripped out my test call: Log File You can see that starting with Line 234, the From header changes from the calling extension 2503 to the recipient extension 2412 when the call is referred to the unified messaging server... why that translation takes place looks like the problem. Quickie explanation of what's happening in the log: 2503 calls 2412, 2412 rejects call, 2503 receives "2412 is busy" message, hits 2 to leave a voicemail, and does so. (Exchange UM is running on port 5060 and PBXnSIP is running on the same machine, 192.168.11.4, port 5070) Thoughts? Thanks.

Thanks, yes there are a few -- we've been working alongside Model12 on some Polycom issues and so right now what I have in the html directory are four files: polycom_adrbook.xml, polycom_master.xml, polycom_phone.xml, and polycom_sip.xml. The modifications that have been made by us to those files are all in the polycom_sip.xml file, and they are: - a hardcoded dialplan: <digitmap dialplan.digitmap="[2-6]xxx|7xxxx|[2-9]11|91xxxxxxxxxx|9[2-9]xxxxxxxxx|*xx[2-6]xxx|xx.#" dialplan.digitmap.timeOut="3"/> - a modded <CALL_WAITING tone.chord.callProg.6.onDur value - switched the <volume voice.volume.persist.handset value to 1 Thanks for the help...

Is anyone else running UM alongside a PBXnSIP 2.1 RC version that can either confirm or deny that this is a problem with 2.1? That's when we started to see it.

This appears to be a Unified Messaging issue with build 2108 (unless it's also due to the lang_en.xml that we removed): before this build, missed call notifications and voicemail notifications had the correct caller/caller ID information attached to it. 'Missed call from Jack', or 'voicemail from 3015555555'. Now, all missed calls and voicemails appear to come from the user themselves, for example, all my voicemails say: 'Voicemail from Sean'. We went straight from 2.0.3.1715 to build 2108 (and removing the lang_en.xml), so if this is a 2.1 bug I don't know how long it's existed.

I can't explain it, but I know what the problem is that Model12 and I have been encountering with the web interface. We had a lang_en.xml file provided by our reseller in the html directory... we put it in there when we were messing with adding a 4-digit extension dialplan. To be honest, we don't know exactly what the custom lang_en.xml does that the built-in one does not, so we might have hurt some stuff without knowing it. But we can see the web interface buttons at the top to nav around the new version, now. Hope it helps.

We just went live with our pbxnsip installation and this is our users' #1 concern at the moment. And the solutions that you've posed there sound like good ones. I see this in the newest build (2100) release notes: Auto Attendant Feature: We added a simple park reminder that calls the extension back which parked the call. The time can be set on domain level. Is that what this is going to do? Thanks! (I did try to put the new build on our server to see but the web interface is funky -- I couldn't see any of the top-level or sub-level navigation buttons at the top, using either firefox, IE, or Opera for Windows, so I put the newest stable release back on it.)

You are correct, sir. I need to go back and refresh my understanding of dial plans from the doc, but I added a Call Extension trunk with pattern 2* -> 2* with lower priority than the other rules and Play on Phone is completely happy now. Thank you! Have a great weekend.