Christer Holmberg (JO/LMF) wrote:
I don't think an application will trigger INFOs in a spray and pray
matter. You will only send media server control messages if you are
communicating with a media server control application that understands
them.
How does my phone know it is communicating with a media server that
understands INFO for conveying DTMF? The thing I call may indicate
support of INFO because it supports qsig tunneling.
Before you send a DTMF/INFO, you really need to know that the
recipient understands DTMF/INFO in general and the specific
encoding of DTMF in INFO that you're using (there have been
multiple encodings proposed).
Yes, and you know that if you receive an indication from the other party
that he supports application/my-dtmf (or whatever value is used).
And, if we would have standardized one encoding, maybe there wouldn't be
multiple ones out there...
We currently have no way to say "I support mime-type foo for use with
disposition bar and method baz", but in reality that is going to be the
situation. I support sdp for disposition "session" in the methods that
convey o/a. But I don't support sdp in MESSAGE or INFO. I support
text/plain with content-type "render" in MESSAGE, but not for other
dispositions and other message types.
Getting an indication of support for application/my-dtmf is useful *if*
you know that the UA sending it to you always uses it the same ways you
do. You can only know that if you control it, or if all the uses of that
type are standardized.
And beyond just understanding your encoding of DTMF/INFO, you
need to know that the recipient you are sending it to is
likely to do something useful with that INFO, and that this
"something useful" is what you intend it to do when you send it.
Yes, but you wouldn't send it unless you have a reason to think the
receiver is going to do something with it, e.g. if you have been asked
to give your PIN code.
I don't understand why people think that applications would start
sending all kind of INFOs "just for fun", without any logic behind. I
have never seen that happen in real world deployments. I wouldn't start
sending UPDATEs and/or re-INVITEs just for fun either, eventhough there
is nothing preventing me from doing it.
Lets go back to my phone. *It* doesn't know that I have been asked to
give my PIN code, even though I do. All my phone knows is that I have
pressed one of the buttons on the keypad. It may reasonably infer that I
want *something* to be done with them, and probably that I want them
sent to the other end in some way. It has no idea *how* (or *if*) the
other end is prepared to receive them.
For instance, it may have indicated support for a mime type that my
phone knows how to use to encode DTMF. But its possible it was really
trying to say that it would support that type in a NOTIFY (sent or
received).
I will agree that if you have N different ways that you are able to send
DTMF, and if the other party has indicated support for *something* that
is consistent with one of them and not with any of the others, then you
might reasonably decide to try that one. But it is still a somewhat iffy
proposition. We would be much better served defining something more
deterministic.
Paul
_______________________________________________
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
