On 4/8/2010 4:52 PM, CHU, XINGJUN (XINGJUN) wrote: > Hi, > > I can easily reproduce the behavior mentioned in this JIRA via two LG phones. > let's say A calls B, then A attempts to attended/consultatively transfer B to > voice mail. After transfer completes, the dialog between A and VM is replaced > by a new dialog between B and VM by "invite with replaces header sent by B to > VM. Although the replacement call is a new Call with a new Call-id according > to RFC 3891, but freeswitch doesn't seem treat it as a brand new call, i.e., > for the replacement call, freeswitch still uses the original control > channel/connection(event socket) created when A calls VM and keep sending all > events regarding to the replacement call to this channel. The channel is > still owned by the old sipX IVR Voice Mail thread which is created by sipXivr > during A calls VM, it continues doing what it does as previously when A calls > voicemail. That's why the target transfer doesn't have a fresh conversation > with VM (i.e., hearing the prompt from the beginning, usually it's the w > elcome prompt). Basically that's what happens. > > To proceed, I would like to have some clarification > 1) why people would do an attended transfer somebody to voice mail? there are > also two scenarios (transfer before login themselves to VM and after) > > 2) If we need to fix as suggested in the JIRA, the following two options (my > opinion) could be discussed > > a. solve it from freeswitch side - freeswitch treats the replacement call > as any other new calls, once call is replaced, it should send event to > destroy the replaced call's control channel/connection and make a new > connection to sipXivr. this is an ideal solution. clean and no work required > from sipXivr side. > > b. solve from sipXivr, There could be a monitor thread to handle certain > event possibly CALL_UPDATE (based on sipxivr.log, every time a call is > replaced, there is an CALL_UPDATE event sent, looks like for this purpose, > but need to be confirmed). when this event happens, some logic to check if > this call has a new call id, based on that, the Voice Mail thread who owns > the control connection should cancel all applications/activities (for > example, prompt playback, etc) freeswitch may be doing by sending command > "BREAK", and then start from the beginning. > Note: I suspect it might be some limitation due to the timing and the > granularity activity could be cancelled, the transfer target B may still hear > some of the trailing part of prompt A was hearing before the VM start from > scratch. > > Comments > Jason > _______________________________________________ > 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/ >
Only comment is why people would do this.. Many of the phones Consultative transfer by default and/or a user doesn't know the difference. Imagine an operator transferring an incoming call to a persons mailbox. You can't have dropped calls or poor call flow behavior. _______________________________________________ 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/
