Subject: [Sip] Replaces and 481

From: Alan Johnston <[email-masked]>
Date: Mon, 11 Mar 2002 10:02:15 -0600

All,

I'd like to discuss an open issue in the current Replaces draft
(http://search.ietf.org/internet-drafts/draft-ietf-sip-replaces-00.txt)
in Section 5.1:

"  If no match is found, the UAS MUST ignore the header and process the 
   INVITE normally. 
    
        OPEN ISSUE: If no match is found, should the UAS ignore the 
        header and process normally, or return a 481?"

The current use of Replaces in the Transfer and Service Examples draft
uses the current behavior that the header is ignored if no dialog
matches.  Also, since no Require: replaces header is present in the
current call flows, a UA that does not understand Replaces also just
ignores the header.

This becomes an issue in attended transfer in the presence of forking or
misrouting, in which the triggered INVITE with the Replaces header may
reach the wrong endpoint.  The current solution to this is to use the
Accept-Contact only=true header so that the wrong endpoint will reject
the INVITE rather than accepting it.  However, the requirement on a UAS
to reject a request in which the Accept-Contact only=true  header is
present is only a SHOULD.  Also, a Require: prefs would be needed in the
triggered INVITE to make certain that the UAS understands the
Accept-Contact header.  This could cause an attended transfer to fail
with a 420 response because the UAS does not support Caller Prefs when
in fact it may support Replaces and the transfer should succeed.

An alternative is to change the Replaces behavior to say that a matching
failure generates a 481 response.  If the triggered INVITE with the
Replaces contained a Require: replaces header, then one of three things
will happen when a UAS receives it:

1. The UA does not understand Replaces and will return a 420.  This
means that an attended transfer will fail, and the transferor should
fall back to the unattended transfer which does not use the Replaces
header.

2. The UA does understand Replaces but the dialog does not generate a
match and a 481 is returned.  If this is caused by misrouting, it is an
error condition.  The transferor could try sending the REFER to the
other party (see if the transfer works in the other direction).  With
forking, the incorrect endpoints should all return a 481 while the
correct endpoint will return a 200 resulting in a successful transfer.

3. The UA does understand Replaces matches and the dialog matches and a
200 OK is sent.  The attended transfer succeeds.

This way, the transferor knows the outcome of the transfer and each
failure suggests a fallback or course of action to resolve the problem.

Although I am not in favor of most uses of the Require header, I like
this approach.  Note that the Require: replaces would be in the
triggered INVITE only, and not in initial INVITEs.  The normal option
discovery mechanisms (Allow: REFER and Supported: replaces) would be
used most of the time.

Comments?

Thanks,
Alan Johnston
WorldCom
sip:[email-masked]

_______________________________________________
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: Robert Sparks <[email-masked]>
Date: 11 Mar 2002 10:32:39 -0600

I agree with the proposal.

To extend 2. below, if routing prevents an INVITE-Replaces from
reaching the endpoint that actually has the state to be replaced,
the request fails. If the requester _wants_ to try a "maybe we can
get lucky and find the right person anyhow" approach, they can 
resubmit the INVITE without the Replaces.

RjS