On Oct 18, 2007, at 9:47 AM, Hadriel Kaplan wrote:
And I'm still stuck on your last question, which is what
application use-case really needs directionality, other than as a
nit?
Yeah, me too. Or to rephrase, what application needs "I want to
send . . ." rather than "I understand . . ."
DTMF? I noticed this problem with RFC2833 negotiation a couple of
years
ago. A device wanted to indicate willingness to send RFC2833, but
wasn't able to render received indications. Since SDP describes what
the device can receive, the 'solution' was to fib.
Yeah, that was my first response to Dean's question (that DTMF has
such a use-case), but "fibbing" about it isn't really harmful. You
may get extraneous INFO, which you just don't render. (just like
for 2833) The question is if the extra complexity of
directionality is worth it or not, and is it necessary to provide
in the general negotiation vs. in individual event packages. In
other words, if some event package got defined which really needed
directionality, it could handle that itself with two event names.
But if it would be a common problem it's better for the general
solution to handle it, IMO.
I think my point has been missed. Why did the device need to indicate
willingness to send 2833 tones? It can't send them unless the other
side has indicated willingness to accept them. And, as pointed out,
it doesn't have to be able to receive them to be able to send them.
--
Dean
_______________________________________________
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
