Hi, >> 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.
>We could just define that no INFO (or NOTIFY if that be the method) can be >sent until the ACK, regardless. Like BYEs. I guess the ACK could also be PRACK, because I don't think we want to prevent INTIFY (it's shorter than "INFO or NOTIFY" :) before 200 OK. Regarding the race condition, I guess the problem is in the backward direction. In the forward direction it's not a problem, once the calling party has received the response. Regards, Christer -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
