On Wed, 2008-08-20 at 14:27 -0400, Beeton, Carolyn (CAR:9D60) wrote: > > > -----Original Message----- > > From: Lawrence, Scott (BL60:9D30) > > Sent: Wednesday, August 20, 2008 2:19 PM > > To: Beeton, Carolyn (CAR:9D60)
> > One possible problem with implementing the notification in > > the dial rule redirector itself is that at that point we > > don't know that we're actually going to make that call. > > > > A redirector provides contacts, but subsequent redirectors > > can modify or override those contacts or even turn the > > response into an error. In addition, there are many other > > redirectors that might well be used to provide the contact > > that is an 'emergency' call. > > > > A better place to put detection/notification might be on the > > outbound side of the proxy in an AuthPlugin. At that point > > we know that the call is actually being made, and it's not > > sensitive to what other things might have happened in the > > redirector chain. > > > > On the other hand, what is implemented here is an "Emergency Dial Rule" > detector. Even if the call doesn't make it out of the building, or is > subsequently modified, if someone dialled something that triggers it, a > notification would be sent. If emergency numbers are configured through > other types of rules, no notification is sent. That is under the > administrator's control. It's that latter point that is of more concern to me - we have a rich and expanding set of mechanisms for routing/redirecting calls and it shouldn't matter which one routes your emergency call, you should get the same service - including notices if that's an active feature. > As a learning exercise I will look at AuthPlugins as well. Ha... it worked :-) _______________________________________________ sipx-dev mailing list sipx-dev@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
