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/
