THe general case for event packages is that they are asymmetric
(unidirectional). It seems to be the infrequent case where it makes
sense to support an event in both directions. So making bidirectionality
the default seems wrong.
Paul
Hadriel Kaplan wrote:
-----Original Message-----
From: Michael Procter [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 18, 2007 5:33 AM
To: Dean Willis; Hadriel Kaplan
Cc: sip; Paul Kyzivat; Brian Stucker; Francois Audet; Christer Holmberg
Subject: RE: [Sip] INFO
Dean Willis wrote:
The only argument I can see is -- it prevents race conditions. Don't
send an event until the ACK.
That sounds like the media clipping problem. If the INVITE indicates
willingness to receive a specific event, then maybe it should be able to
do so before it has seen the 200 response. Then the UAS needn't wait
for the ACK before sending events.
Actually, I think it the other way - if there were no such thing as media
before 200ok/ACK, there wouldn't be an early media problem. So I think the
INFO needs to wait for the ACK period, like BYE's do.
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.
-hadriel
_______________________________________________
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
