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

From: "Culpepper, Bert" <[email-masked]>
Date: Wed, 2 Aug 2000 23:10:02 -0500

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).  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: "Rosen, Brian" <[email-masked]>
Date: Thu, 3 Aug 2000 10:33:15 -0400

> RTP.  (If for no other reason, than PSTN interworking).
Minor point, but some terminals that can send audio may not be able to
send and receive DTMF via RTP.  A UA which had a telephone plugged into it,
would probably need a DTMF detector, but would not need a DTMF generator.
A sipphone which had a keypad could fake DTMF send, but would not
necessarily have any use for DTMF reception.

I think it's all okay.
A POTS equipped UA would generate DTMF RTP (and events) to work with
legacy apps and SIP-aware apps.  If it was sent DTMF RTP, it would
just ignore it (actually, I have a use for it, but it's all within
the UA)

A sipphone without a DTMF generator would work fine in all circumstances
unless it connected to a device that did NOT send DTMF inband on the audio
RTP,
but used DTMF RTP only, and expected the user to "hear" tones.  The user
would
hear silence.

Brian

---

From: Rohan Mahy <[email-masked]>
Date: Thu, 03 Aug 2000 14:32:00 +0200

>just ignore it (actually, I have a use for it, but it's all within

if the POTS equipped UA was plugged into an answering machine, you might
want to generate DTMF to it when you get DTMF RTP.

thx,
-r

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 3 Aug 2000 14:44:33 -0400

Only if the codec didn't pass in band DTMF well and you wanted to
use the DTMF codec to deal with that.

Of course these are implementation issues, and anyone can
choose whether to do so or not.  For your purpose, you want
UAs to send DTMF RTP.  Whether it recieves them or not
isn't important to your problem.  

Brian 

> From: Rohan Mahy [mailto:[email-masked]]
> Sent: Thursday, August 03, 2000 8:32 AM
> To: Rosen, Brian; 'Rohan Mahy'; [email-masked]
> Subject: RE: [SIP] DTMF discussion from WG meeting
> 
>

---

From: "Culpepper, Bert" <[email-masked]>
Date: Thu, 24 Aug 2000 10:20:09 -0500

I'm happy with the AVT tone format for transport of DTMF.  I can request
that media type and direct it independently from other media.  I also expect
to be able to use this media format independently and in addition to any
other method for transporting DTMF or other "user input".  If an endpoint
supports both RTP-DTMF and some event reporting mechanism (SUBSCRIBE/NOTIFY)
then I expect I can request either or both.  The associated IDs and RFCs do
not place any limitations on this that I can see.  If there are additional
mechanisms - great.  I like choices.

I do look forward to seeing support for draft-camarillo-sip-sdp-00.txt.  I
think this will encourage support for the transmission of multiple copies of
a media "stream" to different destinations.  And I look forward to support
for terminal events using SUBSCRIBE/NOTIFY.  I think this can help in
addressing concerns with reliable delivery of user input.  Hopefully work in
both of these areas moves along to completion.

Regards,
Bert

-----Original Message-----
From: Rohan Mahy [mailto:[email-masked]]
Sent: Wednesday, August 23, 2000 7:24 PM
To: Jonathan Rosenberg
Cc: Culpepper, Bert; [email-masked]
Subject: Re: [SIP] DTMF discussion from WG meeting

At 09:46 PM 8/3/00 , Jonathan Rosenberg wrote:
>Rohan Mahy wrote:
> >
> > 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 > 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).
>
>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

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
>mechanism is the right way to go.

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

thanks,
-rohan