On Mon, 2009-05-11 at 23:06 +0200, Iñaki Baz Castillo wrote: > > In practice, the solution is for the user agent to perform the transfer > > in the background by doing nothing until the new call leg is answered, > > and then sending the REFER that completes the transfer. (This has been > > understood since at least 2003, when the Pingtel Xpressa phone > > implemented it.) Although the phone must perform much activity, the > > user of the phone is freed to do other things. > > Interesting. And does some phone implement it? (I've never seen it).
I call your attention to the sentence I wrote: "... the Pingtel Xpressa phone implemented it". I suspect that if you check other high-quality phones that have been in the market for several years, you will find others. Of course, many low-quality phones with poor software do not handle this case correctly, and customers discover that their calls fail unexpectedly in various circumstances. (I know, because I've had to debug many such cases and report them to the phone vendors.) > IMHO this mechanism is really poor. The phone is using a line until the > transfer target answers the call. What about simple phones with just 2 lines? Since the intention is to free the phone's user from dealing with the call, any "lines" that show on the phone's user interface can be released immediately. Of course, the phone software will still have to handle the signaling of these calls, but since SIP is an Internet protocol, there is no intrinsic limitation on the number of calls that a phone can handle at any one time. And in this case, there is no requirement that the phone handle media for *either* of the call legs (even if it is implementing music-on-hold), the phone only handles signaling, which is not computationally demanding. > How to explain the human user that a phone line is still busy even if he has > already free-up himself? Since the user-interface representation of the "lines" can be freed immediately, this does not have to be explained, as the user-interface appearance matches the user's mental model (even if it doesn't match reality). > This is a really bad design IMHO, and it's obvious why so many vendors have > decided not to implement it. I invite you to design a mechanism that works better (but it needs to work correctly in the face of forking). Dale _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
