Iñaki Baz Castillo wrote:
> El Martes 07 Abril 2009, Scott Lawrence escribió:
>
>>> How is possible a RFC (2976) not being a a standard and a draft being it?
>> That RFC only defines the INFO method, but not how DTMF or anything else
>> is transported using that method:
>>
>> The definition of the message bodies or any new headers created for
>> the INFO method is outside the scope of this document. It is
>> expected that separate documents will be created to address
>> definition of these entities.
>
> Thanks for pointing it out.
>
> However it seems that, even if something is widely extended (as SIP INFO for
> DTMF), since it doesn't appear specified in a RFC then a different approach
> must be approved. Ok, let get more incompatibilities!
Surely you know this has been the subject of endless discussion over the
years. Its one of the primary motivators of the new work on INFO.
There are *always* problems when something is defacto-implemented after
being rejected for cause as a standard.
> What is exactly wrong with SIP INFO? it just works!
> SIP nodes interested in receiving DTMF are, basically, PBX's, media servers
> (voicemail, conference server...), PSTN gatewasy...
>
> It's really easy to expect that most of them implement SIP INFO and RFC2833.
> Forget DTMF negociation!
> And now IETF proposes a new way. Ok, something so easy as DTMF will become a
> new interoperability chaos.
"forget negotiation". Look at the base note of this thread. The guy
needs a way to negotiate between INFO and 2833.
Our products support 3 or 4 ways of sending DTMF. And ad hoc means of
negotiating among them have been developed.
Normally you don't want the DTMF both places, because that causes its
own set of problems. Somebody instead filters the dtmf out of the media
and puts it in the signaling. We have very common situations where one
side has it in media and the other side needs it in signaling. During
call setup we have to figure out whether to put in a media relay to
convert between the two, or if we can omit that.
> An endpoint (phone) is not interested in receiving DTMF (is it
> ***really***?).
Usually not. Which is why it would be really unfortunate if you end up
deciding that you need a media relay in the middle of the call to
convert DTMF into INFO so you can send it to the phone that doesn't (but
might have) wanted it as DTMF. That is why you need negotiation.
> But anyway, a phone wanting to receive DTMF could implement SIP INFO and
> RFC2833, this is very common today. But not, this is not valid since is a
> working solution not based in a specification (since the specification didn't
> exist then).
>
> Ok, let's make complex something so easy as DTMF. Now the solution for DTMF
> is
> KPML with lot of exotic XML and so on. Great, sure it will inmediatelly
> adopted by most of the vendors and implementation, sure.
In retrospect, perhaps KPML was over engineered. But in retrospect INFO,
and DTMF over INFO, was way *under*-engineered.
Thanks,
Paul
> Sincerelly I cannot understand such things...
>
> Best regards.
>
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
