[no subject]

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.


   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