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
