9.1.1 Conferencing issues- cant change personal bridge# and personal bridge now blocked until moder 1

[gmasters]

BEWARE: I had issued personal bridge numbers that were a 5+extn number and all were working well in 9.0.3. Participants could connect at any time and start collaborating and when the 1X Portal user/moderator joined with his 1 click join personal bridge button he could see all an moderate (mute/etc). Now all the bridges I set up do not work because personal bridge# is LOCKED to be same as extn number (even though ATAC agrees the docs say it should be changeable) AND when I tried to convert to this we discovered that participants get hold tone or music UNLESS moderator has already joined- while that might be nice for certain conferences (i.e. disaloww certain audiances from chit chat until moderated) it KILLS department pre-meeting collaboration and I am still looking for a way to get 'either/or' or just go back to the old way.

 

[daken]

Having rufly the same issue trying to get documentation from avay on it.

The have introduced new conf pins but have not introduced the documetation to go with it.

It looks like there is a new file that is being included in voicemail pro version 9.1 “>REQUESTPIN.vmp”. ?

I take it no one has a copy of this in a mod version?

da-ken

 

[dclake]

Where is this documentation?

NCDS | NCSS | APSS - SME | ACIS - SME | ACSS - SME | ACIS - UC | ACSS - UC | APSS - SCOPIA | APDS - SCOPIA | CCENT

 

[ThePhoneMn]

I have been up one side, and down the other with this, and same issue's.
- Conference is locked to extension, but if you call extension while in your conference, it rings the phone.
- With or without PIN, system is showing REQUESTPIN, but verbal prompt is asking you log into your voicemail.
- 3rd issue I have is conferences are 4 hours behind start/end time set in OneX portal scheduler

Documentation is user manuals on marketingtools so far. We lost a sale to ShoreTel because we cannot demo a working unit... bummer


Been there, done that

 

[derfloh]

Install a new IPO Anywhere for demo. It should work out of the box. The problems occur mostly on upgraded systems.

 

[daken]

Have the same problem with Prompt for voicemail extn

Think the problem is it can't find the >REQUESTPIN module so defaults to requesting mailbox number.

I'm currently revers engineering the REQUESTPIN.vmp file from the txt to a module
Naming the module >REQUESTPIN looks to do stuff. It appears that avaya may be using call tag and passing the required pin.

Haven't managed to get time to revers eng the entire file yet.

Looks to be using *#N shortcode to transfer in the conference room

This is fresh install on our demo kit with application server on 9.1 sp 1

Has anyone got this working ?

 

[shardian]

I spoke to Avaya about this a few weeks back. It seems to only be an issue on upgraded systems, no issue on new boxes - or at least not for me.
I had the issue on 3 that I setup on lab systems as 9.0 then upgraded to 9.1
To fix them, I copied the >REQUESTPIN.vmp file to the /opt/vmpro/ directory, and >REQUESTPIN.XML to the /opt/vmpro/RemoteXMLCallflow/ folder. If you want to do the same, you'll have to muck around with file/folder permissions a bit, and I had to rename the files before moving them (windows doesn't like > in file names I found).

Avaya's view on this was that the upgrade to 9.1 wasn't done properly (I just mounted the iso and booted from it), instead upgrades should be carried out from the web control/manager view by transferring the iso and then completing the upgrade. After that, when OXP connects to VMPro, the appropriate files and changes are apparently automatically made.

 

[gmasters]

So, the original posted problem is not "new install vs Upgrade' which sounds like it has something to do with the requestpin.vmp in voicemail pro and might be a seperate valid related issue- the root of the problem is that there are changes (blocking the conference until moderator joins) and they are not documented and there is no way to 'not change'. I have a select number of bridges that bypass vmPro thus use no prompting/no pin and users just access them via meetme shortcode or incoming call route that takes you to the shortcode (unsecured, & yes its a 'no no', but what the customer wants and worked well even when vmPro down). So if the new personal pins require either a new shortcode or requestpin.vmp in a flow, then I need documentation, example, etc and away we go (after totally ticking customer off for a couple weeks). I have a std flow for same client that does just a fixed pin and bridge number prompt for 'std bridges', I assume I just duplicate that with a new 9.1 pin prompt and then hope it works on my upgraded system? geez wish avaya would do this stuff better. yet another happy customer that an upgrade ticks off (and waited for sp1 thinking docs and bugs would be gone by now (lol).