Hi,
>I agree with you on this. And yet people keep using all these different
>things for DTMF, with KPML apparently last in the running.
>
>I know my employer currently implements at least *two* non-standard
>mechanisms for DTMF, plus 4733, in a number of products. Even if we came
>up with a standard way that had the message conserving properties that
>seem to be required, it would then it would have to be added along side
>those.
Correct - what is already out there is most going to stay out there - and there
is nothing we can do about that (writing a you-must-not-do-that-RFC won't
help). But, if we can provide a more simple way of doing things we will
hopefully then see more and more deployments using it.
>Perhaps we need a discussion specifically about DTMF - what is happening in
>the real world, and what the chances are for >improving that situation.
Finally someone who agrees with me that there is a real world outside our
Hilton meeting rooms :)
> (Sounds like a bar BOF to me.)
If the outcome of such bar BOF is simply going to be a
we-need-to-go-out-and-make-people-understand-that-they-have-to-implement-RFC-xxx
type of statement it's not going to be very useful.
Regards,
Christer
Paul
Adam Roach wrote:
> Dean Willis wrote:
>> Future event packages would have the option of defining and
>> registering only INVITE dialog usage, only SUBSCRIBE dialog usages, or
>> both.
>
> But even having a structure that encourages that kind of thinking is bad
> hygiene. Having more than one way to do the same thing in a protocol is
> the fastest and most powerful way to simultaneously decrease
> interoperability and increase implementation burden.
>
> Implementations need to either include all possible mechanisms (I just
> love telling developers that they get to do RFC 4733, KPML, *and* INFO
> if they want to convey DTMF), or they end up not working with everything
> out there. Either outcome is seriously unfortunate.
>
> /a
>
>
> _______________________________________________
> 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
>
_______________________________________________
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
_______________________________________________
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
