I can't help wondering whether treating this like offer-answer is the wrong approach. With offer-answer, an offer has a different semantic meaning to an answer, particularly when it comes to more advanced features such as SDP capability negotiation. Since offers and answers are not explicitly indicated as such (unfortunately), we have to have very precise rules for which messages contain offers and which contain answers, so that there is no confusion.
I don't think Send-Info and Recv-Info have quite the same characteristics. What problems would be introduced if we just said that any request or any response can contain Send-Info and/or Recv-Info, and that the latest one you send or receive is the one that applies? There might be some scope for getting out of step, but I am having difficult identifying really convincing concerns. It seems a lot cleaner than introducing a whole lot of new state machinery similar to offer-answer. John > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Christer Holmberg > Sent: 22 October 2008 10:36 > To: Paul Kyzivat; SIP IETF; Eric Burger > Subject: Re: [Sip] draft-ietf-sip-info-events-00: package negotiation > > > Hi, > > >General issues with the negotiation mechanism: > > > >What happens if the initial INVITE by a UAC includes only > Send-Info or > Recv-Info? Does that indicate a "half-legacy" device??? Or > does it delay > negotiation for one but not the other? Or does > >the presence of one mean the absence of the other is equivalent to an > empty one? > > > >As I think about it, I don't think its really necessary to treat the > absence of these headers as meaning "legacy". Treating the absence of > these headers as equivalent to their presence without > >any packages is sufficient to get the proper legacy behavior. The > tricky part is figuring out out when their absence *doesn't* > mean that, > which is significant only in the non-legacy case. In > >particular, when they aren't present in INVITE it means > deferral of the > "offer" to the UAS. And possibly absence in an UPDATE means "don't > renegotiate"??? > > I don't think the presence, or absence, of the S/R-Info headers should > in any way be connected to legacy in any way. A UA can be legacy no > matter if the headers are present, or not present, but that > is all done > based on "configuration", as described in the draft. > > So, if a UAC only included Send-Info, it means that it only supports > sending of Info packages. Then, it may, or may not, also > support legacy > INFO usages, but that is completely separated. > > > >I'm confused by the three way negotiation of info packages in > INVITE/2xx/ACK. Its allowed when the Send-Info/Recv-Info are in the > INVITE, but not when they are deferred to the INVITE response, > >or when they are conveyed in UPDATE and its response. If the > three way > handshake is needed to seal the deal, then those other > options should be > off the table. But the "deferred offer" of these > >is really needed, so it can't be off the table. Or is this just an > extra benefit that can be exploited when possible? > > > >Also, I don't see any provision for additional round(s) of > negotiation > before 2xx via PRACK and UPDATE, though there is provision for > additional "half-negotiations" via provisional responses > >and the final response. Given the parallels with O/A, I'd > prefer to see > them more aligned in this regard, though I can be talked out of that > with a good argument. > > I agree (I think :). The negotiation whould be 2-way. Then, based on > what the UAC gets from the UAS, it may send a PRACK/UPDATE/re-INVITE > with a new set of supported Info packages, but that is a new 2-way > negotiation transaction. > > > >I'd also like to take advantage of the lessons that have been learned > with O/A and nail down more of the semantics now. One issue that leaps > to mind in that regard is what happens if we start > >to negotiate info packages in a reINVITE and then the reINVITE fails? > > That's a good point. > > I think we should use the same rule as for offer/answer. > Because, assume > I send you a new set of packages in a re-INVITE, and you send > me back a > set in a 18x. Then we may start using info packages based on that > negotiation long before the re-INVITE is rejected. > > >IMO what is needed is a state model for this stuff, added to > the state > for an invite-dialog-usage. This state should determine which packages > may be sent, and which should be received without > >error. We should be very clear about exactly which events > cause changes > to this state. > > > >Even then there are race conditions that need to be clarified. For > >instance: Suppose, as a result of an INVITE/1xx exchange > between Alice > and Bob, that packages P & Q are allowed to be sent from > Alice to Bob. > >Alice then sends an INFO with package Q, and at the same > time Bob sends > a 2xx that only allows the receipt of package P. Then Bob receives the > INFO with package Q. What should happen? > > > >Another issue is that if the Send-Info/Recv-Info contents change in > subsequent 1xx responses to the same INVITE, the UAS has no guarantee > that they are received. So any reduction in what can be > >received cannot be counted upon until the 2xx/ACK. > > True. But, I wonder whether this will really be a real-life problem. > > And, we could a response code (4xx Info package not > supported), which is > used by the UAS if it receives an info package which it > doesn't support. > Then the UAC knows. > > Regards. > > Christer > > _______________________________________________ > Sip mailing list https://www.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://www.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
