Thanks to everyone for the clarification on this ! James
-----Original Message----- From: David Robbins [mailto:[EMAIL PROTECTED] Sent: Friday, July 20, 2007 8:23 AM To: Elwell, John Cc: [email protected] Subject: Re: [Sip] RFC3891 (Replaces header) discrepancies There are some existing SIP server implementations that support REFER/ Replaces in the situation that James describes. It only works, though, if you *know* that there is exactly one dialog involved in the call -- i.e. if you *know* that no forking has occurred. Sending REFER/Replaces to complete a transfer before the transfer target has answered the call is understandably seen as desirable, because it allows the transferor to entirely remove itself from the call at the time of the transfer. But for the reasons John and Dale have noted, it's not as simple as that. The safe, RFC 3892-compliant way to handle this transfer is for the transferor to continue managing the two dialogs (transferee and transfer target) until the transfer target dialog has become confirmed, at which time the REFER is performed. The transferor UA can do this "in the background" -- the device is immediately available to the user for initiating or receiving a new call, even though the UA is waiting for the transfer target to answer. I've had to explain this a number of times to people who don't recognize how forking makes SIP different from traditional switched telephone signaling. They tend to build things without recognizing the possibility of forking. On Jul 20, 2007, at 4:49 AM, Elwell, John wrote: > In addition to what Dale has said, consider the case where call2 has > been forked to several destinations, 2a, 2b, 2c... To populate the > Replaces header field and the Refer-To URI, the sender of the REFER > request would need to pick one of these arbitrarily, say 2b. So > suppose > the REFER request were sent and dereferenced, resulting in an INVITE > request with Replaces header field arriving at 2b. What if call2 is > then > answered by 2a (or has already been answered by 2a while this > signalling > is taking place)? I don't think the intended operation of attended > transfer would then be realised. So basically, I don't think the > authors > of RFC 3891 saw any solutions to problems of this nature, and hence > the > restriction. > > John > >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >> Sent: 19 July 2007 18:47 >> To: [email protected] >> Subject: Re: [Sip] RFC3891 (Replaces header) discrepancies >> >> >> From: "Jackson, James" <[EMAIL PROTECTED]> >> >> Consider an attended transfer in which call1 is >> established between a >> transferee and a transferor. The transferor creates a new >> call2 towards >> transfer target. While this call is still alerting (early >> dialog), it >> sends a REFER on call1 with a Replaces header that >> references call2. In >> this case, the Replaces header attempts to replace an >> early dialog which >> was "terminated" by the target. >> >> That is not allowed by RFC 3891. But suppose it was allowed. >> Further >> suppose that the transfer target rings for another 90 seconds >> (sending >> an additional 180) and then the proxy that manages the transfer >> target >> cancels the call, causing the transfer target to send a 487. Who >> receives the 180 and 487? >> >> Dale >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use [EMAIL PROTECTED] for questions on current sip >> Use [EMAIL PROTECTED] for new developments on the application of sip >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use [EMAIL PROTECTED] for questions on current sip > Use [EMAIL PROTECTED] for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
