Ah... But since the conferencing system is based on FreeSwitch in sipxecs, this becomes something FS must allow in a conference.
On 9/2/10, Jean-Hugues Royer <[email protected]> wrote: > 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. >> >> > -- Sent from my mobile device ====================== Tony Graziano, Manager Telephone: 434.984.8430 sip: [email protected] Fax: 434.984.8431 Email: [email protected] LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 sip: [email protected] Fax: 434.984.8427 Helpdesk Contract Customers: http://www.myitdepartment.net/gethelp/ Why do mathematicians always confuse Halloween and Christmas? Because 31 Oct = 25 Dec. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev/
