Woof! On Mon, 27 Apr 2009 08:55:35 -0400, Paul Mossman <[email protected]> wrote:
> 1. Completing a Consultative Transfer to a voicemail box results in the > prompt being re-started for the Transferee. A very nice touch. It does? That's totally unintentional. Might be a nice touch, but it's due to a bug, not a feature! > My complaint though is that the original prompt plays for a couple of > seconds before being re-started. Well, the whole thing is a bug. Woof's rule: "Audio and timers from the IVR shouldn't stop or restart due to external changes." There was a whole to-do on the SIPPING list years ago about HOLD and VoiceXML based IVR systems. I argued the IVR should ignore HOLD and just keep on playing (as it would with any telco interface other than SIP). I lost, and the VoiceXML SIP interworking drafts claims HOLD should freeze all audio and suspend all timers, except for certain "total call" timers, oh, and interdigttimers if they had pressed one digit but not yet completed another. See why this is starting to smell, and why I disagree? That said, I really don't know what FS does. Try it with the AA, that would have identical behavior to the new VM. > 2. Bulk deleting multiple voicemails through the user portal results in > a rapid succession of message-summary NOTIFYs, one for each deleted > message. Each NOTIFY is <100ms apart, in violation of RFC 3842: > Notifiers SHOULD NOT generate NOTIFY requests more frequently than once > per second. Ideally there would be a single NOTIFY send on a bulk > delete. At the moment, we aren't touching the user portal or the MWI server (although Scott wants us to scrap the MWI server and build it into the new VM). I was aware of this issue, so if we do rework the MWI server that'll be part of it. We had this discussion on the list previously. I said I'd consider delaying sending the NOTIFY by a second each time a new request came in. Thus the NOTIFY wouldn't be sent until 1 second after the last change. Scott said a second was too slow, and the little blinky lights wouldn't be right, and people would complain. --Woof! _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
