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
