On Apr 8, 2010, at 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)
We can't control how a user will do the transfer, either blind or consultative, so it has to work for either case. And in the case of a consultative transfer, the prompts need to be played from the beginning once the transfer is completed, otherwise the caller might be left wondering what happened to them. > > 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 This problem has to be addressed on the application side. Besides properly handling the transfer and subsequent reset of the application state, the application must also update the associated call ID, which it currently does not. FreeSWITCH supplies all of the necessary event information required for an application to properly handle this call scenario so there is no reason why an application cannot be made to work. The new ACD implementation, which properly interfaces with the FreeSWITCH event_socket API, handles consultative transfers quite well. Unfortunately it will probably require some major brain surgery to get sipXivr to do likewise. -Mardy
_______________________________________________ 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/
