> -----Original Message----- > From: Hadriel Kaplan [mailto:[EMAIL PROTECTED] > Sent: 17 November 2008 15:33 > To: Adam Roach > Cc: Jiri Kuthan; Dan Wing; [EMAIL PROTECTED]; 'SIP > IETF'; [EMAIL PROTECTED]; Elwell, John; > [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: RE: [Sip] draft-kuthan-sip-derive > > > > -----Original Message----- > > From: Adam Roach [mailto:[EMAIL PROTECTED] > > Sent: Monday, November 17, 2008 9:12 AM > > > > On 11/17/08 7:40 AM, Hadriel Kaplan wrote: > > > Or you could pick something else to use for verification. > > > > Such as...? > > Either a new header or a new parameter. We seem to be > getting this requirement a lot lately in various SIP-related > WG's: we need some unique per-call identifier thingy that > crosses b2bua's without change. I propose we just > standardize one, but avoid making it have any property which > made changing call-id value's a necessity. (like don't put > addressing info in it, and don't make it a dialog match > criteria in the state machine, etc.) I was planning to > submit a draft to do that before the deadline, but was too busy. > > It would require the UA's to change to support it if you want > to use it for Derive, but somehow I don't really believe a > significant market share of deployed UA's support the rfc4235 > subscribe dialog-package yet either (despite Sipit's poll). > And I think we'd have uses for a logical call-id not in Call-ID. [JRE] In fact SIPIT showed 16% support for the dialog event package, but there is no analysis of how many of these were UAs that supported the package as notifiers, as opposed to subscribers. My suspicion is that the population is small. Requiring support for something like a unique call identifier, plus a simple event package to confirm its presence, would probably be no more onerous than requiring support for the dialog event package as notifier.
John _______________________________________________ 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
