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

From: "Kevin Summers" <[email-masked]>
Date: Fri, 8 Mar 2002 08:24:17 -0600

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. 

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

_______________________________________________
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: Fri, 08 Mar 2002 11:36:20 -0500

> where you need to transport (DTMF) information without a call being

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

-Jonathan R.