RE: [Sip] Canceling REFER

[Robert Sparks <rsparks@dynamicsoft.com>]

On Fri, 2003-09-05 at 12:22, Tolga Asveren wrote:
> > -----Original Message-----
> > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Robert
> > Sparks
> > Sent: Friday, September 05, 2003 11:44 AM
> > To: Tolga Asveren
> > Cc: sip@ietf.org
> > Subject: RE: [Sip] Canceling REFER
> >
> >
> > On Fri, 2003-09-05 at 10:26, Tolga Asveren wrote:
> > > [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?
> >
> > Things like allowing endpoints that don't care about the result of the
> > reference (true "blind" transfer for example) to not have to take on
> > subscription state by rejecting the first NOTIFY.
> [TOLGA]Even to cover such a case:
> a)rejecting NOTIFY ===>go ahead with request but cancel the subscription
> b)SUBSCRIBE/0 ====>if request is pending send CANCEL, and cancel the
> subscription
> seems working.
> Now, the above just won't cover the case, where the initiator of REFER
> decides *after it send the response for NOTIFY*, that it is no more
> interested in the result of request but also does not want the request to be
> cancelled.

Hence, SUBSCRIBE/0 is really not where we want to go.
Among other things, it would take us (again) down a path where we
overload an operation to mean two things that really need to be
handled separately.

So - =IF= we want to pursue this, it really does need to be a new
method. Lets focus on that "if" for awhile instead of the mechanics
of "how".

What's the compelling first application of having such a tool?

RjS


_______________________________________________
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