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

From: "Tom-PT Taylor" <[email-masked]>
Date: Fri, 5 Jan 2001 14:55:38 -0500

I've been reviewing this thread in response to the latest messages about the
Also: header, and fully support the operation of REFER in the way Sean
describes it.  In particular, I need a way for an operator to tell a
conference server to add a party to a conference without including the
operator in that conference.

Just to remind people, where we are talking about A sending a REFER to B to
tell B to send an INVITE to C, there is still the problem of how C knows
whether the incoming call
  - replaces an existing call
  - is another party to an existing call
  - is an unrelated call.

The only durable answer I recall for this one is Jonathan's advice: let the
user at C decide.  

> -----Original Message-----
> From: Sean Olson [mailto:[email-masked]]
> Sent: Friday, December 22, 2000 11:56 AM
> To: Billy Biggs
> Cc: Henning G. Schulzrinne; Rohan Mahy; Robert Sparks; Jonathan
> Rosenberg; [email-masked]
> Subject: Re: [SIP] Solving the REFER retransmit issue
> 
> 
> I have to confess that I prefer the notion of a REFER that is outside
> of any active (INVITE) session. Separating the REFER and INVITE 
> seems the most natural to me. In this case, there would be no 
> re-INVITE
> to carry this header (if I understand your suggestion correctly)
> 
> What I would prefer to see is a NOTIFY sent for responses with the
> REFER acting as an implicit SUBSCRIBE and a new Refer-Notify: header
> in the REFER request which would indicate the desire to receive
> such notifications. 
> 
> Refer-Notify: (name-addr | addr-spec)
> 
> If the Refer-Notify: header is present in the request, 
> it indicates the desire to receive NOTIFYs for the responses.
> If the Refer-Notify: header is present in the response,
> it indicates that the receiver is willing to send NOTIFYs (of
> course only applicable to a 2xx response to the REFER)
> 
> I think this will allow for the most common cases without
> incurring any great overhead or restricting the possibilities.
> 
> /sean
> 
> 
> Billy Biggs wrote:
> > 
> > Sean Olson ([email-masked]):
> > 
> > > > > It is not clear that this is workable if REFER is treated as a
> > > > > means of executing a generic request somewhere else, 
> not limited
> > > > > to INVITE.
> > > >
> > > >   And obfuscate this request in a URI?
> > > >
> > > >   Is this a specific feature or just for protocol cleanness?
> > > > Executing a generic request may have dangerous security
> > > > implications.
> > >
> > > This is no more insecure than a REFER with INVITE as the 
> method.  I
> > > actually like the idea of being able to REFER a SUBSCRIBE 
> or even a
> > > REGISTER. I realize the implications of this but I don't 
> think it's
> > > much different than receiving a REFER with an INVITE for which you
> > > might be billed.
> > 
> >   Do you need to know the response to the 
> SUBSCRIBE/REGISTER?  If so,
> > can you live with it as a header in a re-INVITE?  It will 
> save alot of
> > trouble, and optimizes the most common case.
> > 
> > --
> > Billy Biggs, 3Com               Email: [email-masked]
> > http://www.div8.net/billy/      Phone: [email-masked]
> > 
> > _______________________________________________
> > 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
>