Hi, In fact RFC4235 is what most people call BLF, it gives you the details (and updates) of every call of an extension with so many information (when provided by the IP PBX) that you can actually steal any call by placing an INVITE/Replaces to the extension. (you can even REFER another extension to do it).
Basically for each call you know: the direction incoming/outgoing, the status ringing/connected/on-hold, the caller/ee name. Some IP PBX have perfect support for every kind of virtual extension, you can see calls in parking rooms, calls (participants) in conference rooms, calls waiting in different types of queues. When everything is supported (with INVITE/Replaces) you can actually monitor every extension and move calls around from one extension to another. I will definitely investigate the Valet Parking if this is the future parking system of sipXecs. I wasn't aware of the issues of the default parking system... Now regarding conference extensions since the error message we get (when transfering/subscribing) is not meaningful for us, I wonder if this is a sipXecs bug or the feature is not supported, but usually when we subscribe to sipXecs extensions where RFC4235 (or even subscription) is not supported we get: 405 Method Not Allowed. Regarding to XX-8640 (and josh comment), it is indeed what we saw, the REFER is accepted/initiated but fails with: 482 Loop Detected with 2 hops ago Regards. Tony Graziano wrote: > Understand. There is a wiki page in sipfoundry that details how to use > the FreeSwith "Valet Parking". Valet parking allows you to retrieve a > "Valet Parking Slot" by simply dialing the extension (not *4 prefix > required). To me that "simplifies the dialplan. The issue I am facing > in trying to understand how to use it is how to monitor the "slots" > with BLF, which the current park server in sipxecs does. I was told by > the FS guys that these are monitorable with BLF if you monitor the > fifo (they use mod_fifo to park the calls), but not the slot. So I was > attempting to understand if this is the "same" question in a different > form. > > I understand your need is to monitor a "conference" where the > conference provides "dialogue events" to update its status with RLS > for presence to be monitored, is this correct? As I understand RFC4235 > in a very basic way, it is BLF presence that is able to examine the > dialogue events. > > I see you say it is working "perfectly, but also realize it is slated > to be replace (current call park) due to instability issues. In large > environments, calls get "stuck" in park and cannot be retrieved. > Eventually the ParkServer has to be restarted and "stuck" calls even > have to get kicked out of the gateway. If you do not have a volume > environment, you might not be seeing the issue. > > There is an issue with "attended transfers" in FS through version > 1.06. This is supposedly fixed in FS 1.07 but FS 1.07 is not in any > builds yet. I am not aware that BLF monitoring is possible in a > conference. > > Please see Josh's reply about XX-8640 > > Would be helpful to understand your transfer method. > > _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev/
