[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Sip] Canceling REFER
> -----Original Message-----
> From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Robert
> Sparks
> Sent: Friday, September 05, 2003 10:06 AM
> To: Tolga Asveren
> Cc: sip@ietf.org
> Subject: RE: [Sip] Canceling REFER
>
>
> No, there is no conflict. The subscription can be terminated without
> affecting the referenced request.
[TOLGA] O.K. , I see, yes they are different things.
>
> 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]That was my point, that a SUBSCRIBE is also just a method inside a
dialogue. But because of the above -that SUBSCRIBE does terminate the
subscription, not the referenced request-, SUBSCRIBE is not a solution,
unless that behaviour is changed. But still, I would think, changing
semantics for SUBSCRIBE/0 -and allowing it to abandon a pending referenced
request- should work. What was the reason, not to allow SUBSCRIBE/0 to do
so?
>
> >
> >
> > 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
_______________________________________________
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