Hadrial, You wrote: > The sticky part in my mind has always been what to do if both > info-dtmf were negotiated and 2833/4733 was offered/answered. > Or even what to do with in-audio tones. I *think* the > answer is info-dtmf should trump 2833 - i.e., if you > negotiated info-dtmf only do that, for a variety of reasons; > but with delayed SDP offers that would mean you'd always end > up using info-dtmf when you could have done 2833 instead. > And I can see the argument for "do both", and that's what > kpml did except it has the suppression/<pre> concept, but I > assumed that was due to pattern matching being inconsistent > with in-band event sending one-at-a-time. But I still think > info-dtmf trumping would be right, because the tones will get > to the far end if they should. [JRE] Performance is a consideration with DTMF, because the speed with which the user receives a response from the server can have impact on the user experience. RFC 2833 is always likely to get through quicker.
John _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
