RE: [Sip] Canceling REFER

[Robert Sparks <rsparks@dynamicsoft.com>]

No, there is no conflict. The subscription can be terminated without
affecting the referenced request.

On Fri, 2003-09-05 at 08:58, Tolga Asveren wrote:
> >From RFC3515:
> The implicit subscription created by a REFER is the same as a
> subscription created with a SUBSCRIBE request.  The agent issuing the
> REFER can terminate this subscription prematurely by unsubscribing
> using the mechanisms described in [2].  Terminating a subscription,
> either by explicitly unsubscribing or rejecting NOTIFY, is not an
> indication that the referenced request should be withdrawn or
> abandoned.  In particular, an agent acting on a REFER request SHOULD
> NOT issue a CANCEL to any referenced SIP requests because the agent
> sending the REFER terminated its subscription to the refer event
> before the referenced request completes.
> 
> Are the second and third sentences not in conflict?
> 
> Because such a SUBSCRIBE is going to be sent also in the same dialogue, I
> would think is a better option than a "NEVERMIND", because it will follow
> the same mechanism as decribed in RFC3265.

A dialog is a dialog - sending any request on it is well defined. What
do you see different between a SUBSCRIBE and any other method in this
situation?

> 
> 
>    Tolga
> 
> > -----Original Message-----
> > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Robert
> > Sparks
> > Sent: Friday, September 05, 2003 9:47 AM
> > To: Tolga Asveren
> > Cc: sip@ietf.org
> > Subject: Re: [Sip] Canceling REFER
> >
> >
> > >From RFC3515:
> >
> >    Terminating a subscription,
> >    either by explicitly unsubscribing or rejecting NOTIFY, is not an
> >    indication that the referenced request should be withdrawn or
> >    abandoned.  In particular, an agent acting on a REFER request SHOULD
> >    NOT issue a CANCEL to any referenced SIP requests because the agent
> >    sending the REFER terminated its subscription to the refer event
> >    before the referenced request completes.
> >
> > RjS
> >
> > On Fri, 2003-09-05 at 08:21, Tolga Asveren wrote:
> > > What about sending SUBSCRIBE with Expires=0 , as described in RFC3265.
> > > Afterall RFC3515 states also in 2.4.4 that for unsubscribing,
> > the procedure
> > > described in RFC3265 is valid.
> > >
> > >    Tolga
> > > --- "Mark Eastman (meastman)" <meastman@cisco.com> wrote:
> > > > Hello,
> > > >
> > > > I have a question about how to deal with canceling a
> > > > REFER.  Let's say I
> > > > REFER Bob to Betty, but then decide I want to REFER
> > > > Bob to someone else
> > > > before the transfer is complete.  Are there existing
> > > > call flows describing
> > > > such behavior?  I know the REFER rfc states handling
> > > > multiple refers is
> > > > valid, but is that how one would handle this
> > > > situation (Sending a new REFER
> > > > with either a new target or perhaps method=CANCEL).
> > > > If so, call flows
> > > > describing such behavior would be nice.
> > > >
> > > > Thanks,
> > > > Mark
> > > >
> > > >
> > > > _______________________________________________
> > > > Sip mailing list
> > > > https://www1.ietf.org/mailman/listinfo/sip
> > > > This list is for NEW development of the core SIP
> > > > Protocol
> > > > Use sip-implementors@cs.columbia.edu for questions
> > > > on current sip
> > > > Use sipping@ietf.org for new developments on the
> > > > application of sip
> > >
> > >
> > > _______________________________________________
> > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > > This list is for NEW development of the core SIP Protocol
> > > Use sip-implementors@cs.columbia.edu for questions on current sip
> > > Use sipping@ietf.org for new developments on the application of sip
> >
> >
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sipping@ietf.org for new developments on the application of sip
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip