RE: Side Effects of SUBSCRIBE are Harmful (was RE: [Sipping] RE: I-D ACTION:draft-culpepper-sipping-app-interact-reqs-00.txt)

["Bert Culpepper" <[e-mail]>]

I'm not sure where this thread is going or why it got here...certainly one
can define SIP Events packages that are inappropriate, out-of-scope, and
even harmful.  I don't think anyone has done that to date though.

For the problem at hand, a SIP Events solution has been proposed and an even
"richer" approach has been documented.  The SIP Events approach is simply a
"primitive" that applications can use to derive "user input".  It's an
"indirect" solution to address user application interaction.  But one that
seemed to be the "right" direction in many folks minds from my visibility.
It does have the benefit, IMHO, that is uses the same protocol as the
session control protocol.  In addition, it more tightly couples an
"interaction session" with a SIP session, without trying to invent too much
new semantics.  (Not that defining semantics for a new mechanism is bad or
hard to do.)

I got off the subject...If your point is that using SUBSCRIBE to ask a
device to render some content to a user, then I would have to agree that's
inappropriate.  Now if some Events Package contains some supplemental
information that a device can do with it what it pleases, then I don't see
the harm.  However, any specific proposal probably won't "fly" for several
reasons.  *Requiring* a UA to do anything other than report changes in state
is a misapplication of SIP Events IMO.

Regards,
Bert

Eric Burger wrote:
>
> This message outlines the results of misusing SUBSCRIBE to
> change the state
> of an endpoint to do work.  This goes way beyond what the
> current definition
> of SUBSCRIBE is and goes way beyond the intentions for SUBSCRIBE.
>
> The key premise is offered in the message sent by Bert.  How is
> "subscriptions for UI data do not change the state of the
> Notifier other
> than establishing a subscription" compatible with "They
> simply ask the SIP
> UA to prompt & collect, etc.  I suppose asking a device to update its
> display may be thought of changing some state in the
> Notifier.  But this
> seems harmless to me as far as affecting state of any SIP dialog."?
>
> Here is the logical conclusion (and harm) of that line of
> thinking.  Let us
> say I have a media gateway connected to the PSTN.  I want to
> place a call to
> the PSTN, terminating on my SIP Phone.  To place the call, I send a
> SUBSCRIBE message to the gateway, registering for the "Call
> 8885551212"
> event.  That causes the gateway to place the call, initiate a
> SIP session
> with my SIP Phone, and send me a NOTIFY that it is done.
> "Hey, that's OK"
> you say: so what if a SUBSCRIBE has side effects... after
> all, this clearly
> doesn't affect my session; for that matter, there never was a
> session to
> affect in the first place!
>
> Also, how do you reconcile the proposal with
> draft-ietf-sip-events-05.txt?
> Consider:
>
> 1. "The SUBSCRIBE method is used to request current state and
> state updates
> from a remote node."
> What is the current state of "play a prompt and collect
> digits"?  Where do
> you see the phrase "request current state, do work ON MY
> BEHALF to change
> state, and report the state update"?  When does the
> subscription expire?  If
> you have "Expires: 0", then the UA must IMEDIATELY reply with
> the NOTIFY.
> See #2 next.
>
> 2. "In no case should a SUBSCRIBE transaction extend for any
> longer than the
> time necessary for automated processing. In particular,
> notifiers MUST NOT
> wait for a user response before returning a final response to
> a SUBSCRIBE
> request."
> While this refers to the 200 OK, it also means that there is no time
> available between the 200 OK and the first NOTIFY message.
>
> 3. Consider the call flow proposed below.  It looks like the following
>
>       UAC               UAS (e.g., MS)
>        |                 |
>        |    SUBSCRIBE    |
>        |---------------->|
>        |command in event |
>        |filter body      |
>        |                 |
>        |     200 OK      |
>        |<----------------|
>        |                 |
>        |     NOTIFY      |
>        |<----------------|
>        |   what is the   |
>        | notification of?|
>        |                 |
>        |     200 OK      |
>        |---------------->|
>        |                 |
>        |                 |
>        =user interaction =
>        |                 |
>        |     NOTIFY      |
>        |<----------------|
>        |digits collected?|
>        |                 |
>        |     200 OK      |
>        |---------------->|
>        |                 |
>
> That is an awful lot of messages.  Were you thinking of doing
> a 202?  Ouch!
>
> 4. How does the UAC know the subscription has ended with the
> NOTIFY?  One
> could consider using thinking of sending "Subscription-State:
> terminated".
> However, that tells the UAC to try again.  I do not think
> that would be the
> desired behavior.
>
> Some more issues:
>
> Quoting below, "SUBSCRIBE is a dialog establishing method.
> And AFAIK, the
> only method
> other than INVITE that can currently establish a SIP dialog
> (session)."  I
> ABSOLUTELY AGREE.  So, one has a session between the endpoint
> and someplace
> else.  Then, one creates a session by sending a SUBSCRIBE.
>
> 5. How does one direct the SUBSCRIBE to the appropriate
> session at a UAS?
> That is, the UAC is in some dialog already with the UAS (the
> normal INVITE).
> How do you direct this "action at a distance" SUBSCRIBE with the first
> dialog?
>
> 6. The kinds of interactions described below, to me, imply a
> dialog longer
> than one interaction.  For example, if you used this
> mechanism to collect a
> billing number with confirmation, you would (1)
> prompt-and-collect ("enter
> the billing number"), (2) prompt-and-collect ("you entered
> mumble, press 1
> if this is correct"), and (3) prompt ("thank you").  However, using
> SUBSCRIBE requires establishing a new dialog for each
> interaction.  That
> again does not sound like an appropriate use of the message.
>
> -----Original Message-----
> From: Bert Culpepper [mailto:[e-mail]]
> Sent: Wednesday, May 08, 2002 1:37 PM
> To: [e-mail]; 'Fairlie-Cuninghame, Robert'
> Cc: [e-mail]
> Subject: RE: Side Effects of SUBSCRIBE are Harmful (was RE: [Sipping]
> RE: I-D ACTION:draft-culpepper-sipping-app-interact-reqs-00.txt)
>
>
> I have to disagree with the comments below.  As was proposed,
> subscriptions
> for changes in key states seems an entirely appropriate
> application of SIP
> Events.
>
> Presently, other mechanisms are being considered.  However, a
> SIP Events
> solution can meet the requirements IMO.  Whether this is the
> best approach
> will be determined soon I believe.
>
> If a SIP Events solution does happen, the logic below does
> not apply.  First
> of all, subscriptions for UI data do not change the state of
> the Notifier
> other than establishing a subscription.  They simply ask the SIP UA to
> prompt & collect, etc.  I suppose asking a device to update
> its display may
> be thought of changing some state in the Notifier.  But this
> seems harmless
> to me as far as affecting state of any SIP dialog.  Now, an
> application upon
> receipt of some UI data may affect a SIP dialog.  But this is
> not something
> performed by the mechanism we're looking for, it is done by
> the agent using
> the mechanism.  And I think it's not the job of the protocol
> to prevent
> misuse in this case, I think the market will control this
> kind of thing.  In
> fact, the mechanism's primary goal IMO is for applications to
> be able to
> provide services for a SIP dialog (session).
>
> If the act of having to process a SUBSCRIBE and establish a
> subscription
> somehow unacceptably modifies the state of the Notifier, then
> there is a
> fundamental problem with that mechanism itself IMO.  (I don't
> think that is
> the case though.)  And I don't agree that asking an UA to
> display and report
> some indications has any direct effect on any associated
> dialog established
> using INVITE.
>
> BTW, SUBSCRIBE is a dialog establishing method.  And AFAIK,
> the only method
> other than INVITE that can currently establish a SIP dialog (session).
>
> Regards,
> Bert
>
> > From: Eric Burger
> >
> >
> > Mumblings I've been hearing include the thought of using
> the SUBSCRIBE
> > method to request a device to do something, like play a
> > prompt, prompt and
> > collect digits, and so on.
> >
> > This is bad, verging on EVIL.  Let us look at the definition
> > of SUBSCRIBE,
> > from Section 4.1 of draft-ietf-sip-events-04:
> >
> >      The SUBSCRIBE method is used to request current state and state
> >      updates from a remote node [Notifier].
> >
> >
> > SUBSCRIBE is supposed to be a non-invasive method.  With one
> > exception,
> > SUBSCRIBE is not supposed to modify the state of the
> > Notifier.  Starting a
> > prompt play, displaying a screen, or a prompt & collect
> operation most
> > definitely changes the state of the Notifier.
> >
> > The one exception is (obviously) the Notifier responds to the
> > SUBSCRIBE
> > request.  If there is a non-zero Expires, the Notifier needs
> > to remember to
> > update the Subscriber.  Other than that, SUBSCRIBE should
> > (MUST?) not have
> > side effects on the Notifier.
> >
> >
> > With respect to the comment below, a session is infinitely
> > more appropriate
> > for the interaction model.
> >
>
>
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [e-mail] for questions on current sip
> Use [e-mail] for new developments of core SIP


_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP