Subject: [Sip] RFC3891 (Replaces header) discrepancies

From: "Jackson, James" <[email-masked]>
Date: Thu, 19 Jul 2007 10:04:24 -0500

It seems that there is discrepancy between a statement in RFC3891 and
some vendor implementations.

   RFC3891, section 4 states:

   A UAC MUST NOT send an INVITE with a Replaces header field that
attempts

   to replace an early dialog which was not originated by the target of
the

   INVITE with a Replaces header field.

The issue appears to be related to the restriction of "originated" in
the above statement. It tends to imply that it is invalid if the early
dialog was "terminated" by the target rather than "originated" by the
target.

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.

Thanks !

James

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: [email-masked]
Date: Thu, 19 Jul 2007 13:47:26 -0400

From: "Jackson, James" <[email-masked]>

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

---

From: "Jackson, James" <[email-masked]>
Date: Thu, 19 Jul 2007 13:29:54 -0500

The assumption is that the transfer target rejects the initial early
dialog on receiving the REFER. The 180 and 487 would be sent in the
NOTIFY associated with the REFER.

I'm not trying to pick on any vendors here but take a look at what is
called "attended transfer with early completion" on this link:

http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_
guide09186a0080110c01.html

Thanks,
James

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, July 19, 2007 12:47 PM
To: [email-masked]
Subject: Re: [Sip] RFC3891 (Replaces header) discrepancies

   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.

Dale

---

From: [email-masked]
Date: Thu, 19 Jul 2007 18:33:07 -0400

I don't see what you're describing here.  If the INVITE/Replaces were
to complete, you would have the previous early dialog ended (probably
with 487).  And the INVITE/Replaces would presumably get a 200
quickly.  But the phone is still ringing.  To what "other end" UA does
it send provisional and final responses in regard to its status?

>From the looks of Figure 4 on that page, the INVITE/Replaces does
*not* complete immediately, but rather its provisional and final
responses are the continuation of the previous early dialog at the
transer target.

I wonder how well that would interoperate.  Previously,
INVITE/Replaces completes quickly, but there is no reason that it
*must*, and transferee phones should be able to cope with long
transaction times for INVITE/Replaces.

Dale

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 20 Jul 2007 09:49:18 +0100

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 

> Sent: 19 July 2007 18:47

---

From: David Robbins <[email-masked]>
Date: Fri, 20 Jul 2007 09:22:37 -0400

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.

---

From: "Jackson, James" <[email-masked]>
Date: Fri, 20 Jul 2007 09:38:35 -0500

Thanks to everyone for the clarification on this !

James

---

From: [email-masked]
Date: Fri, 20 Jul 2007 10:57:54 -0400

From: David Robbins <[email-masked]>

Thanks for the explanation!

   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 know the (now obsolete) Xpressa phone from Pingtel does that.  I
expect many modern phones do so also.

Dale