Hi, A UA can support both legacy usages and INFO packages.
For example, ISUP transport may have been implemented in a network years ago, and now some new fancy Info package stuff starts to come around. A UA which supports the new stuff will still have to support the old stuff. Regards, Christer > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Eric Burger > Sent: 30. lokakuuta 2008 19:07 > To: Christer Holmberg > Cc: SIP IETF; Paul Kyzivat > Subject: Re: [Sip] draft-ietf-sip-info-events-00: package negotiation > > I would offer the likelihood of a UAC only half implementing > Info Packages is about 00.000% (five zeros, anyone?). I > cannot imagine anyone expending the effort to implement Info > Packages but not use them. > > If the UAS is a legacy device, the UAC will detect it from > the absence of Send/Recv-Info headers. > > If the UAC is a legacy device, the UAS will detect it from > the absence of Send/Recv-Info headers. > > Since I will soon make it clear a conforming UAC can send a > legacy INFO, half negotiation is a non-issue. > > For example, let's say it's two weeks from now and I've > published the update to RFC 3398 to use Info Packages. Either > the implementor will implement the full ISUP package, or not. > It just does not make sense to do half the job, since 90% of > the job gets done when one does the first half. If one side > does not do Info Packages, then presumably, in the interests > of legacy interoperability (and often because the code is > already written), the device falls back to legacy INFO/RFC 3398. > > 3pcc? By the time you can list one header (Send or Recv), you > can list both. > > Therefore, I would offer it is an implementation failure to > list only a Send-Info or Recv-Info header. > > On Oct 22, 2008, at 5:36 AM, Christer Holmberg wrote: > > > > > 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
