Subject: [Sip] SIPit 21: REFER with Replaces - and Require: replaces

From: Robert Sparks <[email-masked]>
Date: Mon, 19 Nov 2007 15:48:41 -0600

Here's a really interesting one.

Lots of people are sending REFER with a Refer-To URI that has an  
embedded Replaces header.
This is what we're specifying in cc-transfer.

Nobody puts Require: replaces in the REFER request (and I don't think  
they should - does anybody disagree?)

However, very few implementations are putting Require: replaces in  
the triggered INVITE. They're copying the Replaces header into
the INVITE though.

This will cause very wrong things to happen if that triggered INVITE  
forks.

 From talking to people at SIPit 21, I don't think leaving the  
Require off of the INVITE was done on purpose - just that the code
path followed blindly copied the headers from the URI into the  
triggered request and didn't check to see if it needed to explicitly
signal an extension.

We might look for places to tighten up the text on extensions so that  
implementors get this one right.

One implementor was including the Require: replaces as an imbedded  
header in the Refer-To URI. That shouldn't break anything,
but it also shouldn't be required.

What can we do to make this better?

RjS

_______________________________________________
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: Mon, 19 Nov 2007 17:58:52 -0500

From: Robert Sparks <[email-masked]>

That's OK, the UA that processes the REFER isn't *supposed* to put a
"Require: replaces" header into the generated INVITE unless there is a
"?Require=replaces" header parameter in the Refer-To URI.

(Because otherwise the sender of the REFER couldn't specify "I want
you to send an INVITE with a Replaces header but without a 'Require:
replaces' header.  Such an INVITE is clearly legal and its effects are
well-defined, although not very useful.)

Or if the intended destination of the INVITE doesn't happen to support
Replaces.  Hence, the sender of the REFER should always include
"?Refer=replaces" in the Refer-To URI.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 19 Nov 2007 20:10:55 -0500

Robert Sparks wrote:
> However, very few implementations are putting Require: replaces in the 
> triggered INVITE. They're copying the Replaces header into
> the INVITE though.
> 
> This will cause very wrong things to happen if that triggered INVITE forks.
> 
>  From talking to people at SIPit 21, I don't think leaving the Require 
> off of the INVITE was done on purpose - just that the code
> path followed blindly copied the headers from the URI into the triggered 
> request and didn't check to see if it needed to explicitly
> signal an extension.

And what would make the referee think it *should* put a Require:replaces 
into the INVITE? That is supposed to be inserted if the UAC requires 
that the Replaces be honored. But the referee doesn't require that - it 
is the referror who does. The referee may not even understand the 
"replaces" option, isn't required to, and otherwise doesn't need to.

> but it also shouldn't be required.

Unpleasant as it seems, that seems to be the proper solution.

I guess another path would be to ammend 3891 so that if there was a 
Require:replaces in the REFER then the referee MUST put a 
Require:replaces in the INVITE. But backward compatibility will cause 
such a change to be useless.

This is another manifestation of the "REFER means 'do what I mean', not 
'do what I say'" situation.

> What can we do to make this better?

I see nothing better than requiring the referror to embed the 
Require:replaces. Or else live with the consequences of having the 
Replaces be ignored by those that don't support it.

Of course this isn't a problem if you already know that the refer target 
supports Replaces. This is likely to be the case most of the time. (You 
will have seen a Supported:replaces in your earlier dialog with it.) But 
it can be a problem if you are sending the INVITE to an AOR (because 
there is no gruu support) and it forks to multiple devices, some of 
which don't support Replaces.

	Paul

---

From: [email-masked]
Date: Mon, 19 Nov 2007 20:45:05 -0500

From: [email-masked]

Our company's software did generate such REFERs for a while.  The idea
being that during a call transfer or pick-up sequence, even if the
refer target UA didn't support Replaces, at least the call would come
in "on another line", and the UA user could switch to it.

(The folly of this idea was proved when the refer target was a PSTN
gateway.  The inbound PSTN caller received a call-waiting indication
from the second call, but nothing to indicate that they should switch
to that call to complete the transfer sequence.)

Dale