Subject: RE: [SIP] REFER progress

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 9 Jan 2001 15:53:38 -0500

I assumed the originator would be subscribed to all of the responses
associated with the transaction, simply as a consequence of piggybacking on
the general SUBS/NOTIFY mechanism as applied to SIP events.

> -----Original Message-----
> From: Robert Sparks [mailto:[email-masked]]
> Sent: Tuesday, January 09, 2001 2:24 PM
> To: 'Rohan Mahy'; Sean Olson; Robert Sparks
> Cc: sip
> Subject: RE: [SIP] REFER progress
> 
> 
> As far as I can thell, You and Sean are assuming you get
> exactly one NOTIFY then. 
> 
> At that point we're just quibbling on the method name.
> 
> Or do you disagree? If you are assuming more than one
> NOTIFY, then I think you missed my point.
> 
> RjS
> 
> 
> 
> > -----Original Message-----
> > From: Rohan Mahy [mailto:[email-masked]]
> > Sent: Tuesday, January 09, 2001 12:50 PM
> > To: Sean Olson; Robert Sparks
> > Cc: [email-masked]
> > Subject: Re: [SIP] REFER progress
> > 
> > 
> > Hi,
> > 
> > I agree with Sean that an implicit NOTIFY is 
> straightforward, no more
> > complicated than REFERDONE and solves the timeout problem.  I 
> > hope we don't
> > need a meeting to close this issue.  ;-)
> > 
> > The "other" problem, however, is the one that opened the 
> can of worms.
> > What primitive(s) do you use to get attended transfer to 
> > work?  All of the
> > proposals (something like 4 of them) work and solve the 
> > requirement for an
> > attended transfer.  Some of these proposals deal more with 
> > the  bis draft
> > (see Tom Taylor's post today).  Everyone seems to want other 
> > features as
> > well, but we need to see at least a "sketch" of the 
> complete features
> > picture associated with each proposal.  This is why I 
> > proposed the one-day
> > face-to-face meeting.
> > 
> > thanks,
> > -rohan
> > 
> > 
> > 
> > At 12:15 PM 1/9/01 , Sean Olson wrote:
> > >I'm sorry, I don't see the standardization of the
> > >REFERDONE as being any easier than the standardization
> > >of a NOTIFY to serve the same purpose.
> > >
> > >To satisfy a need stated by Billy, the
> > >body of the NOTIFY could simply be the SDP
> > >from the 200 OK (assuming an INVITE) or empty
> > >for a BYE. Uses of REFER for other methods would
> > >need to be specified in extension drafts.
> > >The Event: token could be "referdone".
> > >
> > >Is there anything else that needs to be specified
> > >for the use of NOTIFY that I am missing?
> > >
> > >I don't wish to drag this out forever. I think
> > >the solution is fairly simple and straightforward
> > >and could be extended in the future.
> > >
> > >Please point out faults with this proposal and
> > >areas of implementation difficulty.
> > >/sean
> > >
> > >Robert Sparks wrote:
> > >
> > >> a.s. This got a little long - sorry
> > >>      It does contain a concrete proposal.
> > >> ------------
> > >> I think we are falling into a set of traps
> > >> with the REFER discussions, endangering an
> > >> already overdue deliverable.
> > >> 
> > >> The worst is specification creep. The group
> > >> was pretty happy with the functionality of
> > >> the current draft. When we tripped up on the
> > >> timeout problem, we saw a host of extra 
> > >> functionality we could add while working
> > >> around that problem.
> > >> 
> > >> Most of us have gravitated towards a model
> > >> where REFER is answered with a set of
> > >> reciprocal responses (essentially NOTIFYs,
> > >> possibly of a different name, with or without
> > >> an explicit subscribe). What we _haven't_
> > >> spent much time on is the profile of those
> > >> responses. How many can there be? What do
> > >> they contain?
> > >> 
> > >> I really anticipate the answers to those last
> > >> questions will vary widely depending on the
> > >> application using REFER. We want to be able
> > >> to do other things than transfer (this is 
> > >> why the method got renamed from TRANSFER).
> > >> A rich response set for a REFER that triggers
> > >> a SUBSCRIBE is likely to be entirely different
> > >> in character from one that triggers an INVITE.
> > >> 
> > >> 
> > >> PROPOSAL
> > >> In interests of meeting our working group
> > >> deliverable on this topic (now _WAY_ overdue),
> > >> I suggest that obtaining this rich response
> > >> set has shown itself to be too big a bite. I
> > >> propose that it is time to fall back to a single
> > >> REFERDONE reciprocal request, carrying the
> > >> information that is provided in the current
> > >> draft's final response. This would provide a
> > >> baseline version of REFER that would meet the
> > >> requirements the current draft addresses.
> > >> 
> > >> I further propose that when we complete that work,
> > >> we can return to REFER and define an extension that
> > >> would get the richer response set, addressing the
> > >> current lack of definition of that response set
> > >> with something like sip-event profiles.
> > >> 
> > >> 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
>

---

From: "Robert Sparks" <[email-masked]>
Date: Tue, 9 Jan 2001 16:02:51 -0600

If you have enough of the SUB/NOTIFY mechanism to include an event
header, you can create profiles on the event that will tell you what
the many NOTIFYs coming back mean. I again argue that to go down
this path sanely, you want an explicit subscribe to a particular event.

Now - to push again for closure of the work item at hand.

Allowing more than one NOTIFY is probably solvable, but is
going to take a _lot_ of discussion. If we restrict the behavior
to one reciprocal request, and call it NOTIFY, we close
the door on allowing more than one NOTIFY in the future.

Hence I push again for REFERDONE. That gets us to where we
thought we were with NOTIFY before we ran afoul of the timeout
problem. This will satisfy the working group deliverable.

_Future_ work can work add notifies to the scenario by extension,
preferably in the context of SIP Events.

RjS

-----Original Message-----
From: Tom-PT Taylor [mailto:[email-masked]]
Sent: Tuesday, January 09, 2001 2:54 PM
To: Robert Sparks; 'Rohan Mahy'; Sean Olson
Cc: sip
Subject: RE: [SIP] REFER progress

> From: Robert Sparks [ mailto:[email-masked]]
> > From: Rohan Mahy [ mailto:[email-masked]]

---

From: Rick Dean <[email-masked]>
Date: Tue, 9 Jan 2001 16:52:52 -0600

I beg we use NOTIFY or REFERDONE if the call-leg has
not had an INVITE, and if it has, send INVITE or BYE.
Otherwise the REFER sender may have to
generate and send ringback when a blind transfer
fails.  The REFER may take some time before
it fails, so he would need to alert his user who
thought the call was gone.

--
Rick
[email-masked]