I'm not going to opine on whether this is a great idea in general.
HOWEVER, if we do it, I want the mechanism to be much more general
than DTMF. If a phone has a button, and the UA doesn't know what
to do with it, and some downstream proxy does, then a mechanism to
transport the button press might be useful. Whether this is
a number (DTMF) button, or a button that is labeled "Double Latte",
the action should be the same.
To be most general, you want events for button down and button up,
with a parameter for duration.
Brian
> -----Original Message-----
> From: Bert Culpepper [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, September 13, 2001 4:33 PM
> To: 'Fairlie-Cuninghame, Robert'
> Cc: [EMAIL PROTECTED]
> Subject: DTMF event proposal (was [Sip-implementors] Sending DTMF
> digits)
>
>
> I believe there should be a method for DTMF/tone event detection and
> reporting independent from RFC2833 RTP. While it's needed in certain
> scenarios, I think it's been shown that it's problematic for
> the case of
> application control, particularly distributed application control.
>
> I can only think of just a few attributes that are of interest in
> application control. They are a digit/tone has been detected, what
> digit/tone was generated, and the duration (in a few cases).
> I think we
> also need to look at what devices will detect/generate
> digits/tones in SIP
> networks. We have SIP Phones (both stand-alone and PC
> software), MGCs, and
> media gateways. Are there others?
>
> The signaled-digits I-D has promise to solve the problem for
> application
> control. However, I think we should distinguish the types of
> devices. The
> goal being to minimize the burden on those devices that perform the
> detection/notification.
>
> SUBSCRIBE: For SIP phones, what's specified in the signaled
> digits I-D is
> fine - RFC2833 fmtp representation (text). Volume is of no
> interest and
> duration is supported. For MGCs and media gateways, use the
> MGCP/Megaco
> event representation. MGCP has the RequestedEvent and Megaco
> has the Events
> Descriptor parameters. For MGCP duration is provisioned in the media
> gateway and can not be requested. Do we really need the
> duration in the
> signaled-digits defined SUBSCRIBE?
>
> If we do this we need to decide how much control we allow. I
> suspect we
> only need to be able to specify the package, no digit maps or other
> attributes. Let the subscriber accumulate/filter/process the received
> information. For MGCP the default action is to notify immediately. A
> potential problem with not allowing a DigitMap in MGCP is that RFC2705
> states if it's absent the previously defined value is used.
> For Megaco
> hopefully the DigitMap defined for the root termination is
> such that any
> digit will be notified as detected with no accumulation, etc.
>
> NOTIFY: For telephone-event (RFC2833) allow the same textual
> representation
> as in the SUBSCRIBE. For mgcp-event use the ObservedEvent, and for
> megaco-event use the ObservedEventDescriptor. I would prefer
> to see this
> data as a NOTIFY body rather than message headers.
>
> We can define event subpackages (telephone-event.RFC2833 |
> telephone-event.MGCP | telephone-event.Megaco). If desired, have two
> subpackages for RFC2833. RFC2833-RTP (presently described in
> signaled-digits) and RFC2833-text (that is the fmtp representation).
> Alternatives?
>
> If something along these lines is useful, I (or someone else)
> can work this
> proposal and try to influence the evolution of the
> signaled-digits draft.
>
> Comments? (Recommendations not to waste my time will be accepted :-).
>
> Regards,
> Bert
>
> (BTW: the signaled-digits ID does have "placeholders" for INFO usage.)
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of
> > Fairlie-Cuninghame, Robert
> > Sent: Friday, September 07, 2001 2:21 PM
> > To: 'Bert Culpepper'
> > Cc: [EMAIL PROTECTED]
> > Subject: RE: [Sip-implementors] Sending DTMF digits
> >
> >
> >
> > The SUB/NOT approach [draft-mahy-sip-signaled-digits-01.txt]
> > allows multiple
> > AS's to receive event notifications (each with a different
> > event set) - an
> > important advantage over previous methods. It also allows the
> > signaling
> > "plane" to be used for event notification but does not
> > require the AS to
> >
> > a) mess with SDP in a nasty and/or potentially complicated
> > way. [RFC2833
> > approach](and RFC2833 has security issues as it can be used
> > as a multiply
> > attack and draft-mahy-sip-signaled-digits-01.txt discusses
> > many others)
> > b) generate or terminate messages in the signaling path
> > (therefore becoming
> > a B2BUA)
> >
> > yet retains the advantages of the INFO based method where
> >
> > a) digit transport is reliable and not susceptible to small
> transient
> > network jitter/loss periods.
> > b) one event maps to one notification [less traffic, less
> > load, easier to
> > process IMO]
> >
> > I agree with you Bert that a textual representation is better than
> > transporting RFC2833 in MIME. mgcp/event or
> > application/vnd.nortelnetworks.digits would provide this.
> >
> > I think the mgcp/event is a good representation because
> > a) it is reusing rather than re-inventing a digit package
> > b) it is very simply to parse and generate
> > c) it does not try to control UA behavior too tightly
> >
> > I think the last point is important. When there are
> multiple AS's each
> > asking for events you don't want to have to handle different
> > interdigit
> > timeout, last digit, and total timeouts, etc, etc for each AS that
> > subscribes. KISS.
> >
> > The SUB/NOT approach fits in with the Call Control
> > Transfer/Application
> > Server model which should hopefully make Jonathan Rosenburg
> > (amongst others)
> > happy. The two UA's talk to each other without interference
> > by the AS. The
> > AS Subscribes to get digit information but would then use
> > Transfer [or other
> > method] to take action based on the events. [This seems like
> > another place
> > when loose source routing would be useful - but that's
> another can of
> > worms.]
> >
> > Important points:
> > - RFC2833 still has its place for "inband" end-to-end digit
> > transport. Most
> > clients will need to support both SUB/NOT or INFO [for AS
> > interaction in the
> > signaling plane] and RFC2833 [for "in-band" end-to-end digit
> > transfer]. This
> > is not a new concept [eg H.323] and trying to accomplish both
> > using RFC2833
> > is, in my opinion, making things messy. This is the reason
> why a large
> > number of vendors have "gone their own way" and implemented
> > expired drafts
> > utilizing the INFO method.
> > - It is a common misconception that the mgcp/event or
> > megaco/event draft is
> > trying to tunnel MGCP through SIP (a layer violation). However, the
> > Culpepper draft merely re-uses the event packages from
> these existing
> > protocol's [isn't that one of IETF mantra - don't re-invent
> > something it
> > already exists in a usable form?]
> >
> > There are still issues to be resolved but I think this is a
> > good approach
> > that has enough merits that it may satisfy both "DTMF camps".
> >
> > The downside of the signaled-digits approach has is its more
> > complicated to
> > implement than say simple DTMF in INFO [which works _very
> > well_ when the AS
> > is a B2BUA] but signaled-digits does seem to be a more
> > general solution that
> > fits into the whole SIP Call Control framework in a much
> more cohesive
> > manner.
> >
> > Robert.
> >
>
> [snip]
>
> _______________________________________________
> Sip-implementors mailing list
> [EMAIL PROTECTED]
> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
