Woof! On Mon, 30 Nov 2009 10:01:39 -0500, Paul Mossman <[email protected]> wrote:
> Woof commented in XX-7151 that: Configuration of per-user MOH can be > moved to a separate MOH configuration file or directory, and need not > effect alias.xml at all. (Thanks!) Just to confirm though, changes can > take effect without a service restart? Depends how the information is conveyed to sipXivr. Today it checks the modification date on most of it's configuration files (like validusers.xml) and reloads and caches them on the next call after they change. No restart required. > That brings me to another proposal... I think "None" should be an MOH > Audio Source option. This wouldn't change the MOH URI. What it would > do is result in the held party not receiving any audio when held. > (Whatever the acceptable way to accomplish this with the SDP is...) That one would require phone config changes, so it doesn't invite the MOH server in the first place...or perhaps the MOH server could reject the MOH call. However, to accomplish the same thing, silence could be played as an MOH source for those situations. It's not the same from SDP and RTP point of view, but the caller wouldn't notice the difference and the effect would be the same. > > It would be very nice for a user to have the ability to disable MOH > after dialing into a conference call, without having to disconnect and > dial back in. > > (Bonus points if MOH source configuration changes can be applied to > calls already on hold.) Not sure how you'd signal that. The "conference problem" is one of those system wide issues that a pure SIP system doesn't do well. A B2BUA like FS handles it beautifully, as it knows the state of all the calls and the phones don't do the work, the single image system does. With a fully distributed set of conference bridges, and a fully distributed set of MOH servers, somehow the information that "this" phone is in a conference would need to be discovered by whatever MOH server got the call, so it could change its behavior. Now, we've got the XMPP status tracking, so perhaps by adding a third party state tracker like openfire could help here, with the MOH server querying the state of the users, and somehow discovering "in a conference". But boy, I wouldn't want to rely on that. And there's still the problem of the PHONE doing MOH as opposed to the USER. I.e. I'm on line 3 in a conference, but when I go on hold it doesn't send line 3's identification to the MOH server, instead is sends line 1's. --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 sipXecs IP PBX -- http://www.sipfoundry.org/
