Well, we do advise the products to implement History-Info and the one that I was responsible for in the past does implement all three (including the remote-party-id solution).
On your last point, it's not clear to me the reason why folks haven't implemented it, other than that it's just in the pile of stuff that they haven't implemented. And, it's not all the members of SIP Forum that haven't implemented it (perhaps the subset that are currently contributing to the SIP Connect spec). There is a handful of vendors that interop with one of our products (that I know has implemented HI) that do implement it, as well. So, I don't think it's fair to say across the industry it has not been implemented. Now, I can see folks not wanting to implement it from the perspective that there are already a number of core interop issues per your interop document, thus there's really no point in adding something like HI when the basics are broken. But, that's a broader problem and kinda takes us to Dean's tricycle analogy on the RAI list. Mary. -----Original Message----- From: Hadriel Kaplan [mailto:[email protected]] Sent: Wednesday, March 11, 2009 12:05 PM To: Barnes, Mary (RICH2:AR00); Shida Schubert; [email protected] Subject: RE: [Sip] Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt I don't actually have much stake in Diversion - you know it wasn't us who implemented it first, and it's a softswitch/PBX thing not SBC thing anyway - I just hate having two ways of doing the same thing, or having to convert between the (multiple) vendors that do one or the other. And before you throw stones at me for it, you can look into your own product line and find that there are products that only do Diversion and not Hist-Info. In fact several vendors have a mixture of both across product lines, afaict. But anyway I'm not debating the merits of History-Info vs. Diversion. That time has passed, and we will just have to live with both for a while, and hopefully someday Hist-Info will win. I will be happy to convert between it and Diversion for now, just so it can be un-converted on the other side of the link, so that a piece of wire can claim to be standards-compliant. ;) I'm not even arguing for a new header. I'm just saying something ain't right when we don't even want to use it in practice. If we can't eat our own dog food, there's something wrong with the food. -hadriel > -----Original Message----- > From: Mary Barnes [mailto:[email protected]] > Sent: Wednesday, March 11, 2009 12:39 PM > To: Hadriel Kaplan; Shida Schubert; [email protected] > > Yeah, we can define a new header and just ignore the use of a basic > SIP building block that the WG spent 2.5 years (note this doesn't > include the > 2+ years spent on the doc as an individual and as a SIPPING WG > 2+ document ;) > And, while we're at it, let's just go ahead and obsolete 4244 > altogether and standardize diversion (something the WG rejected almost a decade ago). > That will make one vendor and a handful of SPs very happy and those of > us that have implemented the specs can ripout some code after while > when we have some spare change to pay folks to do so (and of course, > this is after the folks that have not implemented diversion actually > implement it - there are actually some of those out there). > > As an aside, this is another fine example as to why we don't seem to > make great progress or produce specs that are deemed useful - we agree > on a way forward and then change our minds later (sometimes for good > reasons and sometimes because a shortcut seems easier or it's just > arbitrary based on the phase of the moon it seems). > > Mary. _______________________________________________ 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
