Subject: RE: [Sipping] I-D ACTION:draft-culpepper-sipping-app-interact-re qs-00.txt

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Sun, 14 Apr 2002 02:59:36 -0700

> 
> The "outside of a session" part was added to support being 
> able to receive
> indications before a SIP session was fully established, (aka "early
> sessions").  So do we want to limit the mechanism to 
> established sessions?

I believe that "outside of a session" and "early dialog" dialog subscription
are two entirely different beasts and should be considered differently.
"Outside a session" subscriptions relate to NO other dialogs; "early
"subscriptions relate to a session that is in the progress of being
established - but they still relate to a dialog. . 

I guess there are two types of "early" subscription. The first is a
subscription established before the session dialog has become established
but only becomes active when the session becomes established. This is needed
to ensure an appln doesn't miss any user indications when the session
becomes active. The second is where the subscription becomes active while
the sessions is still only an early dialog. This allows a number of services
such as pre-ring PIN identification. We allowed this type of subscription in
our key-events draft but now I'm having second thoughts. Allowing this
mechanism could encourage people to do things in early dialogs that should
only be done in established sessions. For instance, the pre-ring PIN
identification should perhaps really be done in an established session to
the "SIP answering machine"  rather than an early session. 

Can anybody think of any legitimate reasons where user indications are
needed before a (possibly forked) subscription becomes active?

Robert.

> [additional comments] First, "early dialog" was meant above, and the
> requirement should be re-worded I think so this is clear.  
> Second, related
> to service activation Jonathan mentions above, I can see 
> using SIP for these
> things where no SIP session is in progress or established may 
> be (in fact is
> most likely) a misuse of the protocol.  For the kinds of 
> service activation
> mentioned above, a user could "call" the service and interact 
> with it using
> the resulting mechanism we're going for here if the user 
> device was protocol
> limited.  I can see other means for doing this (service 
> activation/control)
> too so the second part of the requirement is not needed IMHO.
> 
> [snip]
> 
> >
> > >
> > > >  R6:  The mechanism must support filtering so that only user
> > > >         indications of interest are transmitted.
> > >
> > > I don't know what this means.
> >
> > Well, an application that wants only digits should be able 
> to apply a
> > generate a request so that only it gets digits.  This may
> > help the problem
> > of "application interaction" and bandwidth.  Agree that
> > filtering is not a
> > good word - will re-write.
> >
> 
> The comment above got garbled...the requestor should be able 
> to apply a
> "mask" so that it is possible to request a subset of supported UI
> indications.  This "mask" (or whatever) should of course be 
> able to do other
> things as indicated above.
> 
> [snip]
> 
> Best regards,
> Bert
> 

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 25 Apr 2002 01:25:05 -0400

> established - but they still relate to a dialog. .

I was concerned about the "outside of a session" case. I think its ok to
have user input indications for early dialogs.

> only be done in established sessions. 

A dialog and a session are not the same thing.

For instance, the pre-ring PIN
> the "SIP answering machine"  rather than an early session.

pre-ring PIN identification will require a session to be established
(meaning, an O/A exchange has completed). Otherwise, the user doesn't
get the voice prompts to input the PIN code. Now, the dialog could be
early, or it could be established, but that doesn't seem to be terribly
relevant. 

I can think of scenarios where you can only make the app work if the
user input indication is sent during an early dialog.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com