Woof wrote: > 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?
Yes, that smells. But consider softening your rule: The IVR is not required to stop or restart audio and timers due to external changes, though it may. No need to do it for hold/unhold. But if it accepts an INVITE with Replaces, then re-starting the current audio prompt in that call would be a nice touch. > That said, I really don't know what FS does. Try it with the > AA, that would have identical behavior to the new VM. See XX-5643: Consultative Transfer to AA fails - call is dropped > > 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 OK. > (although Scott wants us to scrap the MWI server and > build it into the new VM). Makes sense. Is that the plan? > 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. The challenge is that a bulk delete in the User portal results in a series of individual delete requests? It would be easier to handle a single delete request that indexes multiple messages. That way the MWI server would be able to send a "0 messages" NOTIFY promptly, as long as it hasn't sent another within the last second. But yes, I understand now that XX-4753 does not include a new MWI server. -Paul [email protected] _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
