Dean Willis wrote: > On Oct 17, 2007, at 5:54 PM, Hadriel Kaplan wrote: > > > Why does there need to be a 3-way exchange? > > Can the 200-ok have Events listed that weren't offered? (why would > > it bother to? The offerer didn't say it could do them.) > > So isn't the ACK always a mirror image of the 200ok, in which case > > why bother? > > Unless you had competing Event types, where only one should be > > used, or couldn't do some combo of them. And then this concept is > > getting bloated, and will end up looking like SDP capabilities > > negotiation. > > > > 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. > > 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. Not necessarily something that needs to be supported, but a data point from the field to be considered. Regards, Michael _______________________________________________ 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
