Subject: Re: [SIP] Solving the REFER retransmit issue

From: William Marshall <[email-masked]>
Date: Thu, 14 Dec 2000 19:04:05 -0500 (EST)

I think there is a definite simplification possible here, 
if the three-phase-procedure can be dissaciated with INVITE.
That is, to allow the three-phase-procedure for all methods.

SIP defined two mechanisms for retransmission/reliability.  One
(currently used for INVITE) involves a three-way handshake
(INVITE, 200-OK, ACK); and the other (currently used for all
other methods) is a two-way handshake (INVITE, 200-OK).  
The major difference, in my opinion, is that the three-way
handshake allows a provisional response, which is not allowed
for such methods as BYE, INFO, SUBSCRIBE, REGISTER, etc (even
though it might be useful).

I think the changes are relatively simple.  All are currently
implemented in the handling of INVITE, and just need to be
made non-INVITE-specific.

UAC/UAS behavior changes:

(1) A UAC that receives a 1xx response to any method, MUST send
an ACK when it receives a final response.

(2) A UAS MUST send a response within some short time limit of
receiving a request, either a final response or a provisional
response.  

(3) If a UAS sends a provisional response, it MUST re-transmit any
final response until receiving an ACK.

Proxy behavior changes:

(1) A Proxy MUST forward an ACK to the UAS, regardless of original
request.

(2) Proxy MUST forward a 100 provisional responses back to the UAC,
except when the proxy generated its own 100 response for the same 
request.

REFER, of course, is the first example of a method that could use
the three-way-handshake other than INVITE.  The only reason the 
situation didn't arise before (with the Also/Replaces version of 
call control) because they were headers added to an INVITE method.

The main issue is whether this is toooo incompatible with RFC2543.
Proxy point (2) is the only point that is not backwards compatible
with existing devices that conform to RFC2543 and that handle only
existing methods.

Would this involve significant implementation changes in UAs?
Regardless, I think the contortions needed for REFER are more complex.

Bill Marshall
[email-masked]

-----original message-----
From: "Robert Sparks" <[email-masked]>
To: "Venkatesh Venkataramanan" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: [SIP] Solving the REFER retransmit issue
Date: Thu, 14 Dec 2000 11:04:13 -0600

If we wanted to use the first two phases of invite, we
must take the third (ACK) with it. The ACK provides
recovery from a lost final response.

RjS

> -----Original Message-----
> From: Venkatesh Venkataramanan
> [mailto:[email-masked]]
> Sent: Wednesday, December 13, 2000 11:54 PM
> To: Robert Sparks; [email-masked]; Venkatesh Venkataramanan
> Cc: [email-masked]
> Subject: Re: [SIP] Solving the REFER retransmit issue
>
>
> Steve:
> I was essentially suggesting the same thing to Robert Spark in an email I
> sent him earlier today except that I missed out mentioning that we don't
> need the "ACK" for the final response received for a REFER !!
> Venkatesh
> ----- Original Message -----
> From: "Robert Sparks" <[email-masked]>
> To: "Venkatesh Venkataramanan" <[email-masked]>
> Sent: Thursday, December 14, 2000 10:22 AM
> Subject: RE: [SIP] Solving the REFER retransmit issue
>
>
> > This has been brought up before and was not well received. Why do you
> > need a three phase transaction for this? Do we want to introduce a
> > whole new state machine to do the first two phases of invite without
> > the third?
> >
> > The opinions I have been hearing to date are to try _very_ hard to
> > find a solution that worked within the existing non-INVITE transaction
> > model. If a good solution can't be found within that constraint, then
> > we start discussing the other options.
> >
> > > -----Original Message-----
> > > From: Venkatesh Venkataramanan
> > > [mailto:[email-masked]]
> > > Sent: Wednesday, December 13, 2000 10:10 PM
> > > To: 'Robert Sparks '
> > > Subject: RE: [SIP] Solving the REFER retransmit issue
> > >
> > >
> > > Robert:
> > > I am probably missing out something here. Let me try to explain what I
> was
> > > proposing and get your thoughts on this one.
> > > Instead of processing REFER like a BYE request, we should modify the
> REFER
> > > to be processed like an INVITE. The rationale being if REFER is being
> used
> > > for initiating "requests" to make calls and the initiator of the
> > > call wants
> > > to see "call progress", REFER is "like" a 3pcc INVITE.
> > > Use provisionals received by the Invoker of INVITE to be forwarded to
> the
> > > initiator of REFER. The arrival of a provisional stops the timer
> > > (as we have
> > > now modified REFER to be processed like an INVITE).
> > > Venkatesh
> > >
> > > -----Original Message-----
> > > From: Robert Sparks
> > > To: Venkatesh Venkataramanan; [email-masked]
> > > Sent: 12/13/00 9:31 AM
> > > Subject: RE: [SIP] Solving the REFER retransmit issue
> > >
> > > The problem is that the REFER transaction itself will timeout
> > > if the referred action (INVITE for example) takes longer than
> > > the run of REFER retransmits to complete.
> > >
> > > RjS
> > >
> > > > -----Original Message-----
> > > > From: [email-masked]
> > > > [mailto:[email-masked]]On Behalf Of Venkatesh
> > > > Venkataramanan
> > > > Sent: Wednesday, December 13, 2000 3:07 AM
> > > > To: Robert Sparks; [email-masked]
> > > > Subject: Re: [SIP] Solving the REFER retransmit issue
> > > >
> > > >
> > > > Well, I go back to my suggestion(rather a question I posed
> for Rohan)
> > > of
> > > > forwarding provisionals received for INVITES initiated by
> the UA that
> > > is
> > > > processing the INVITE :-) instead of using an explicit
> > > SUBSCRIBE/NOTIFY
> > > > mechanism. With this approach all the UA would do have to do is to
> > > forward
> > > > any message that it receives in response to an INVITE it
> issued (after
> > > > suitably modifying the callID/From and To fields to match
> the one for
> > > the
> > > > REFER request which triggered this INVITE). Any UA that doesn't want
> > > to
> > > > about what happened to a REFER request it issues could explicitely
> > > specify
> > > > so using the Request-Disposition header (caller preferences).
> > > > Any repercussions with this ?
> > > > Venkatesh
> > > > ----- Original Message -----
> > > > From: "Robert Sparks" <[email-masked]>
> > > > To: <[email-masked]>
> > > > Sent: Tuesday, December 12, 2000 11:23 PM
> > > > Subject: [SIP] Solving the REFER retransmit issue
> > > >
> > > >
> > > > > The presentation of status of REFER and the discussion of the
> > > > > REFER timeout issue is at
> > > > >
> > > > http://www.softarmor.com/sipwg/meets/ietf49/slides/draft-ietf-sip-
> > > cc-transfe
> > > > r-02.htm
> > > >
> > > > Rohan Mahy also proposed an optimization of 2 where the REFER
> > > > was overloaded to also mean SUBSCRIBE - NOTIFYs for the progress
> > > > of the REFERed action would just happen and could be ignored/481'ed
> > > > if the the REFERing agent didn't care.
> > > >
> > > > Jonathan R. stated that 2) requires any agent accepting a REFER to
> > > > implement being an event server (must implement accepting and
> > > > managing subscriptions), and this is asking too much.
> > > >
> > > > Discussion?
> > > >
> > > > RjS
> > > >
> > > >
> > > > _______________________________________________
> > > > SIP mailing list
> > > > [email-masked]
> > > > http://lists.bell-labs.com/mailman/listinfo/sip
> > > >
> > > >
> > >
> > >
> > > _______________________________________________
> > > SIP mailing list
> > > [email-masked]
> > > http://lists.bell-labs.com/mailman/listinfo/sip
> > >
> > >
> > > _______________________________________________
> > > SIP mailing list
> > > [email-masked]
> > > http://lists.bell-labs.com/mailman/listinfo/sip
> > >
> > >
> >
> >
> >
>
>

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 15 Dec 2000 09:34:51 -0800

Hi,

If we were to build SIP again from scratch, then I agree that we should
allow the 3-way handshake to be more general, or switch to a 4-way
handshake as Jonathan proposed.

However, the changes to add 3-way to REFER that Bill Marshall and others
propose, isn't backward compatible with baseline SIP.  We had a variation
of this theme during the discussion of 200 resonses to PRACK.

following the KISS principal, I'd like to propose that REFER responds
immediately once the Referred-to message is sent.  (Note: this is backwards
compatible with implementations of REFER that just want to do blind
transfer).  I further propose that the provisional and final progress of
the REFER is sent back via either an unsolicited NOTIFY or a REFERSTATUS
(for example), either of which can be ignored, or 481ed if they are not
needed.  I would further propose that if we use a separate method, that the
separate method should be identical in format to an unsolicited NOTIFY,
except for the method name.  That way, an implementation that already
supports NOTIFY can easily handle/parse the message.

thanks,
-rohan

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Sat, 16 Dec 2000 17:26:52 -0500

While I have some sympathy for allowing the 3-way handshake for REFER,
I'm very concerned about the proxy backward compatibility issue. An
"old" proxy that thinks REFER is just another non-INVITE and a new UAS
that retransmits 200s until it gets an ACK will get not be happy
together. (A UAS that doesn't know REFER is likely to respond
immediately with a 400 and will likely just dump the ACK, so that
variation seems less of a concern.) Thus, we at least need a
Proxy-Require

An implied SUBSCRIBE (i.e., NOTIFY on state changes) seems like the
solution we might have chosen even for INVITE. It requires the least
amount of changes, particularly if we just carry the response from the
"remote-control" request in the notification as a message/sip.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs