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.
And I'm still stuck on your last question, which is what application use-case really needs directionality, other than as a nit? -hadriel > -----Original Message----- > From: Dean Willis [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 17, 2007 6:25 PM > To: Paul Kyzivat > Cc: sip; Francois Audet; Christer Holmberg; Brian Stucker > Subject: Re: [Sip] INFO > > > On Oct 17, 2007, at 4:18 PM, Paul Kyzivat wrote: > > > As a swag for how to encode this in actual headers, how about: > > > > INVITE ... > > Exchange-Events: dtmf;sendrecv, foo;sendonly; > > bar;recvonly; xyzzy;sendrecv > > > > 200 OK > > Exchange-Events: dtmf;recvonly, foo;recvonly; > > bar:sendonly; xyzzy:inactive > > It's more concise to have: > > INVITE ... > Send-Events: dtmf, foo, xyzzy > Recv-Events: dtmf, bar, xyzzy > > > 200 OK ... > Send-Events: bar > Recv-Events: dtmf, foo > > ACK ... > Send-Events: dtmf, foo > Recv Events: bar > > Do we need to encode in 200 OK that xyyyz was offered and rejected, > or is just not including it in the 200 OK enough? > > I think that if you offer to send it, and I don't offer to receive > it, then we know we aren't using it. > > -- > 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 _______________________________________________ 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
