Robert Sparks wrote:
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.
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.
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.
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
RjS
_______________________________________________
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
