Ok and its an attended transfer (It would probably not fail if a blind transfer). This behavior is supposed to be fixed in FS 1.07. I think its being worked to bring it to a 4.3 dev build soon.
On 9/2/10, Tony Graziano <[email protected]> wrote: > 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. > -- 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/
