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
