Subject: RE: [Sipping] Key-Based User Indication Support

From: "Kevin Summers" <[email-masked]>
Date: Fri, 8 Mar 2002 13:30:58 -0600

The case where a service/feature requires use of (and I shudder to
mention) vertical service codes (or feature access codes) for
activation/deactivation. This can be done during call setup or,
depending on the service/feature, without any call at all.

RFC2833 (without a session) wouldn't work here. It seems that a method
using SUBSCRIBE/NOTIFY might be best for these scenarios. It would also
be suitable for 
those ugly yet persistent features like reorigination during/after a
call (calling party presses '#' and is prompted for new destination
address info).

I know this is not the PSTN and am loathe to perpetuate old-style
thinking in the SIP environment...but some sort of configuration
mechanism (REGISTER, anyone?) seems needed here.

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Friday, March 08, 2002 10:36 AM
To: Kevin Summers
Cc: Dean Willis; Rosen, Brian; Bert Culpepper; Rohan Mahy;
[email-masked]
Subject: Re: [Sipping] Key-Based User Indication Support

Kevin Summers wrote:
> 
> 4. Using INFO requires a session to be established; there will be
cases
> where you need to transport (DTMF) information without a call being
> established.

Which cases? And how would that work with rfc2833, which also requires a
session to be set up?

-Jonathan R.

> 
> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Thursday, March 07, 2002 8:57 PM
> To: Dean Willis
> Cc: Rosen, Brian; Bert Culpepper; 'Rohan Mahy'; [email-masked]
> Subject: Re: [Sipping] Key-Based User Indication Support
> 
> I definitely want to discuss this during IETF. THis issue has been
> hanging around too long, and there is tons of proprietary stuff all
over
> the place.
> 
> I have come to the conclusion personally that, because DTMF is used
for
> two separate things in the PSTN (end-to-end, where the network doesn't
> care about it, and for application stimulus), there is really a need
for
> two separate solutions. The end-to-end stuff makes much more sense
with
> rfc2833 than it does with INFO or with SUB/NOT. The reasons are:
> 
> 1. synchronization with the media stream; sending in INFO will cause
the
> DTMF presses to not be synchronized, or there will be huge playout
> delays needed to synchronize them
> 
> 2. INFO would cause needless traffic through all these proxies. None
of
> them will care. Plus, it will need to send an INFO after each and
every
> digit. Could put a real strain on proxy networks for no reason.
> 
> 3. reliability is a red herring; with packet loss, the delays of INFO
> retransmit would be so large to render the information useless anyway.
> FEC is far better way to go here, and thats what rfc2833 does.
> 
> For stimulus to applications not on the media path, a SUB/NOT model
> seems to be better. Plus, there are other problems I'm worried about
> that are similar (the isTyping indicator for presence), which I think
is
> really a similar problem. I think we still have a lot of work to go,
but
> a general solution for SIP-based user input to applications using
> SUB/NOT is worth discussing.
> 
> Dean Willis wrote:
> >
> > Reliability and confirmation issues . . . you really want an ACK on
a
> > key-press.
> 
> True for application invocation - not true for e2e media usage, I
would
> argue. For the e2e case, the media stream coming back would be your
> confirmation. For example, you'd get the next voice prompt.
> 
> -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
> 
> _______________________________________________
> 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

-- 
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

_______________________________________________
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: "Bert Culpepper" <[email-masked]>
Date: Fri, 8 Mar 2002 17:07:33 -0500

Hi Kevin, a response below...

> mechanism (REGISTER, anyone?) seems needed here.

We do describe the use of key-event subscriptions being established outside
of a INVITE dialog (SIP Events itself supports this).  This would support
the first feature you describe above.  I won't comment on legacy network
services though :-)

Regards,
Bert