Fix unattended transfer
Issue generated from Tuleap's migration script. Originally submitted by: Alexandre Lision (alision)
When making an unattended transfer, the peer that got transfered does not see the new call, although it's properly handled in the daemon.
After some investigation I found out that when the peer receive a transfer request (refer_to field in invite), the daemon creates a new outgoing call, and hang up the previous one (as explained here: http://www.in2eps.com/fo-sip/tk-fo-sip-service-04.html).
Problem is, daemon doesn't warns that it is doing that, therefore clients can't handle this new outgoing call.
The next thing emitted by the daemon about that call is a state changed to CONNECTING. But LRC has no knowledge of this call, and rejects it.
We need to agree on what daemon should emit:
-
a simple call state change, and LRC will handle the unknown call. But in this case, we should remove the incomingCall signal and replace it by a call state change as well.
-
create a new signal just as incomingCall (or reuse the NewCallCreated signal)