[Freeswitch-users] hangup/disconnect on transfer

[Hector Geraldino]

Hi,

I'm facing a problem that I'm not even sure that belongs to the FS boundaries but I'm asking anyway: I need to know when the legB of the call transfers the legA to another extension. Here's the scenario:

PSTN -> Cisco Unified CM -> Sip Trunk (FreeSwitch) -> ESL application

An incoming call is effectively bounded by a Cisco Call Manager platform to a SIP trunk managed by FreeSwitch, and controlled by a Java application. I can answer the call, play prompts and do some more stuff. After that, I'm originating a call to another extension (managed by the CUCM, not freeswitch) to be answered by an agent, and bridging both legs using uuid_bridge. So what I've is a classic call center scenario where I connect incoming calls to agents, and I calculate the call handling time based on the time between the call was bridged to an operator and the time the call was dropped because one of the two legs hanged up. Also after receiving the disconnection notice I perform some cleanup tasks. Great. So far so good.

But, there's a problem that begins when the agent (legB) transfers the call to another extension (or even an external phone number) using the transfer function on their IP Phone. As this phone is not 'controlled' by FreeSwitch there's no event registered for this call transfer. So what is happening is that both legs are still connected to FS even when the agent (legB) has transferred the call. This off course is an undesired behavior, because I'm saying that 'agentB spent 30 minutes handling call X' when he actually transferred this call to someone else after maybe just 20 seconds.

So what I need is an event or something that helps me to detect when a call has been transferred, not using the 'transfer' tool on freeswitch but transferred outside FreeSwitch. The only notification that FreeSwitch receives after a call transfer is performed is this SIP message (with its response):


recv 805 bytes from udp/[192.168.23.104]:5060 at 14:40:04.945886:
   ------------------------------------------------------------------------
   UPDATE sip:mod_sofia at 192.168.5.72:5060 SIP/2.0
   Via: SIP/2.0/UDP 192.168.23.104:5060;branch=z9hG4bK78836e9096b
   From: <sip:5562 at 192.168.23.104>;tag=63092ed1-42e0-4489-9bb9-bd2b77b7fcf3-28767966
   To: "" <sip:5512 at 192.168.5.72>;tag=cFQ5y9jHy0a0p
   Date: Mon, 31 Oct 2011 14:39:41 GMT
   Call-ID: e062f678-7e70-122f-f890-000c298202db
   User-Agent: Cisco-CUCM8.0
   Max-Forwards: 70
   Supported: timer,resource-priority,replaces
   Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
   CSeq: 101 UPDATE
   Contact: <sip:5562 at 192.168.23.104:5060>
   Supported: X-cisco-srtp-fallback
   Supported: Geolocation
   P-Asserted-Identity: "Leona C" <sip:5655 at 192.168.23.104>
   Remote-Party-ID: "Leona C" <sip:5655 at 192.168.23.104>;party=calling;screen=yes;privacy=off
   Content-Length: 0

   ------------------------------------------------------------------------
send 624 bytes to udp/[192.168.23.104]:5060 at 14:40:04.946088:
   ------------------------------------------------------------------------
   SIP/2.0 200 OK
   Via: SIP/2.0/UDP 192.168.23.104:5060;branch=z9hG4bK78836e9096b
   From: <sip:5562 at 192.168.23.104>;tag=63092ed1-42e0-4489-9bb9-bd2b77b7fcf3-28767966
   To: "" <sip:5512 at 192.168.5.72>;tag=cFQ5y9jHy0a0p
   Call-ID: e062f678-7e70-122f-f890-000c298202db
   CSeq: 101 UPDATE
   Contact: <sip:mod_sofia at 192.168.5.72:5060>
   User-Agent: FreeSWITCH-mod_sofia/1.0.head-git-
   Accept: application/sdp
   Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
   Supported: timer, precondition, path, replaces
   Session-Expires: 1800;refresher=uas
   Min-SE: 120
   Content-Length: 0

   ------------------------------------------------------------------------


Is there any way to react to this incoming message and generate an event or action? A channel variable or something that I may be missing? Any thoughts?

Thanks for your kindly attention,
Hector


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20111031/33c23cc4/attachment.html