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

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 7 Mar 2002 16:06:31 -0500

I personally think keys-in-rtp is the way to go, but it's worth talking
about.  

Brian

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]]
> Sent: Thursday, March 07, 2002 3:45 PM
> To: Bert Culpepper; 'Rosen, Brian'; 'Rohan Mahy'
> Cc: [email-masked]
> Subject: Re: [Sipping] Key-Based User Indication Support
> 
> 
> Well, I think it's a worthwhile topic, but I liked 
> DTMF-in-INFO, so what do
> I know?
> 
> --
> Dean
> 
> ----- Original Message -----
> From: "Bert Culpepper" <[email-masked]>
> To: "'Rosen, Brian'" <[email-masked]>; "'Rohan Mahy'"
> <[email-masked]>
> Cc: <[email-masked]>
> Sent: Thursday, March 07, 2002 12:31 PM
> Subject: [Sipping] Key-Based User Indication Support
> 
> 
> > I apologize for this re-post, please pardon the Subject of 
> the previous
> > posting...the current Subject line is hopefully more appropriate.
> >
> > >
> > > Hello all/sipping chairs,
> > >
> > > I'd like find out if there is any interest moving forward
> > > with defining a mechanism to transport key presses (user
> > > indications) using SIP.  I believe there is significant
> > > interest in some standard mechanism for what's been typically
> > > referred to as "DTMF in INFO".  It is my belief that what's
> > > really desired is application access to user indications as
> > > the transport of DTMF in IP networks *is* handled nicely by
> > > RFC 2833.  I also believe that it is desirable to use SIP for
> > > the mechanism so as to reduce the number of protocols a
> > > device must support for access to the services that can be
> > > associated with media sessions.
> > >
> > > As far as I can tell, there are two current proposals that
> > > relate to the above.  The first is
> > > draft-mahy-sipping-signaled-digits-00 and the other (more
> > > general :-) is draft-culpepper-sip-key-events-01.
> > >
> > > Any feedback will be appreciated.
> > >
> > > BTW, the latest copy of the key events draft is available at
> > > http://www.ietf.org/internet-drafts/draft-culpepper-sip-key-ev
> > > ents-01.txt.
> > >
> > > 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
> >
> >
> 
> 
> _______________________________________________
> 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
> 

_______________________________________________
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: "Dean Willis" <[email-masked]>
Date: Thu, 7 Mar 2002 16:16:54 -0600

Reliability and confirmation issues . . . you really want an ACK on a
key-press.

--
Dean

----- Original Message -----
From: "Rosen, Brian" <[email-masked]>
To: "'Dean Willis'" <[email-masked]>; "Bert Culpepper"
<[email-masked]>; "'Rohan Mahy'" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, March 07, 2002 3:06 PM
Subject: RE: [Sipping] Key-Based User Indication Support

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 07 Mar 2002 21:56:47 -0500

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. 

> Reliability and confirmation issues . . . you really want an ACK on a

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

---

From: "Dean Willis" <[email-masked]>
Date: Fri, 8 Mar 2002 11:05:02 -0600

> FEC is far better way to go here, and thats what rfc2833 does.

Ok, you can run telnet-over-RTP-with FEC if you want to,
(OrX-over-RTP-with-FEC) but it strikes meas not a good idea. And yes, I
really do think that that's a valid comparison. We're tallking user I/O
comparable to telnet or X, but as a companion of a SIP application.

--
dean