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

From: "Venkatesh Venkataramanan" <[email-masked]>
Date: Thu, 14 Dec 2000 11:23:54 +0530

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

---

From: "Robert Sparks" <[email-masked]>
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

> [mailto:[email-masked]]
> Sent: Wednesday, December 13, 2000 11:54 PM
> To: Robert Sparks; [email-masked]; Venkatesh Venkataramanan
> Cc: [email-masked]

---

From: "Venkatesh Venkataramanan" <[email-masked]>
Date: Fri, 15 Dec 2000 09:54:02 +0530

Unless we re-transmit REFER until a final response has been received to
ensure reliability of the final response like we mentioned in a previous
posting.