Subject: RE: [SIP] DTMF discussion from WG meeting

From: Rohan Mahy <[email-masked]>
Date: Thu, 03 Aug 2000 11:22:20 +0200

Hi,

I think we may have a slightly different definition of first and third
party.  I'd say that the moment an app switches from first to third, it
becomes third party and can subscribe to DTMF events.  Perhaps I should say
that a first-party cannot *take action* on DTMF events, but a thrid party
should.

If a 1st party app subscribes to DTMF events, there is a danger that it can
count the same DTMF event twice (once from RTP, and once from the event).
My preference is to avoid that slippery slope completely, and make a clean
delineation.  I have seen this kind of problem first hand.  It is hard to
troubleshoot, frustrating to the user, and it is not deterministic.  The
last double-DTMF problem I had only affected an apparently random portion
of the DTMF events.  It took a long time to discover why.

thanks,
-rohan

At 06:10 AM 8/3/00 , Culpepper, Bert wrote:
>Rohan,
>
>Is eliminating a first party from subscribing to DTMF event too restrictive?
>I say this because I'd like to have the choice of either SUBSCRIBE or RFC
>2833 (DTMF in RTP) as a first party.  (I assume that by "first party" you
>mean an endpoint with both a signaling session and a media session with the
>other endpoint).  

yes

>You imply the other endpoint will support both sending
>DTMF events by NOTIFY and in RTP, maybe that's my interpretation problem :).
>I believe a SIP UA can be a "first party" initially in a call then become a
>"third party" by redirecting the other UA's media.  Maybe I just need to
>understand the terms first and third party.
>
>Thanks,
>Bert
>
>> -----Original Message-----
>> From: Rohan Mahy [mailto:[email-masked]]
>> Sent: Wednesday, August 02, 2000 1:41 PM
>> To: [email-masked]
>> Subject: [SIP] DTMF discussion from WG meeting
>> 
>> 
>> Hi Folks,
>> 
>> Below is a summary of one proposal for DTMF (basically what I said at the
>> mic today).
>> 
>> - Terminals which *send audio* must be able to send and receive DTMF via
>> RTP.  (If for no other reason, than PSTN interworking).
>> 
>> - First-party applications which *receive audio*, must be able to receive
>> DTMF via RTP, because the sender may send their DTMF over RTP.
>> 
>> - Third-party applications which want to find out about keypresses (IP
>> endpoints) or DTMF events (PSTN endpoints) of a party in a call, should
>> send a SUBSCRIBE to that party for dtmf-events.  The third party may
>> request [using some kind of parameter (ex: ";silent" or ";private")]  that
>> DTMF is not sent via RTP during this subscription.  Otherwise the first
>> party still sends DTMF to its audio peers using RTP.
>> 
>> Applications of the "silent" parameter would be private signalling to
>> calling card things, to conference control services, etc.
>> 
>> - Alternatively a third party MAY send a script/document/application (ex:
>> VoXML doc) to an endpoint to run, which could result in other SIP
>> messages//notifies, etc.  This script/doc/app MAY trap DTMF locally (and
>> silently).
>> 
>> - A first-party MAY NOT subscribe to dtmf-events, but MAY trap DTMF based
>> on a local script/app/doc.
>> 
>> Key here was the difference between a first party participant and a third
>> party participant.
>> 
>> Thoughts?
>> 
>> thanks,
>> -rohan
>> 
>> 
>> 
>> _______________________________________________
>> SIP mailing list
>> [email-masked]
>> http://lists.bell-labs.com/mailman/listinfo/sip
>> 
>

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 04 Aug 2000 00:46:13 -0400

> count the same DTMF event twice (once from RTP, and once from the event).

Sounds like the kind of nasty things that happen when there are two
completely different ways to do the same thing. As I suspect you will
not be able to cleanly define a role as either 1st or 3rd, with a clean
changeover during which you would never receive events, sounds like one
mechanism is the right way to go.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 23 Aug 2000 16:23:50 -0700

At 09:46 PM 8/3/00 , Jonathan Rosenberg wrote:
> > becomes third party and can subscribe to DTMF events.  Perhaps I 
> should > that a first-party cannot *take action* on DTMF events, but a 
> thrid party
> > should.
> >
>changeover during which you would never receive events

I think the definition is crystal clear, and most apps will always be one 
or the other.  maybe you will like this better:

         If your app will *ever* terminate audio,
         then it must be ready to receive DTMF via AVT tones,
         and must never subscribe to "keypress events"

This leaves "pure" 3rd party apps (of which there are still plenty), which 
will never, ever terminate any media.  I think that something like VoXML is 
a good model here.  Send the endpoint a script or document to run.  If the 
end user does something interesting (press some keys, say something 
intelligable, etc), then execute a URL.  The URL may fetch a new script, 
contain a REFER, an INVITE, a BYE, a REGISTER, etc...

>sounds like one

Lots of folks will want a VoXML-like model.  Only ever sending DTMF as AVT 
tones is limiting and short-sighted IMHO.

thanks,
-rohan