User talk:Danfreedman
Bosendorfer addition
The Bosendorfer tone is "sweet". With a "fullness" of "body" and a "richness" of tone. Your insertions in the Bosendorfer article have a strong tendency toward advertisements. And the "literal heavyweight" Imperial grand piano seems to imply that not only is Bosendorfer the best piano (the non-literal heavyweight), it weighs a lot. Of course, this is not to say the Imperial does not weigh a lot (which it does!).
Advertisements are not permitted on Wikipedia. The sections you inserted have an unfortunate tendency toward ads. However, you are not nearly as bad as User:MichaelIsGreat. MichaelIsGreat kept inserting a huge section on the CEUS Computer Grand Piano, which is a new Bosendorfer reproducing piano. The section kept getting removed by editors, of which I was one. The section was obviously an ad, and took up more space than the rest of the article. Instead of complying, MichaelIsGreat kept inserting the section, threatening with comments like "They are censoring me!" and "The mad people who delete my postings, GO BACK TO YOUR MAD HOUSE!". He never gave up. Eventually the threats got so bad that he was banned from editing.
Evidently you do not edit Wikipedia a lot- it's been about 5 months since you inserted the sections! If you have an argument for keeping the sections, then we can continue discussing. Otherwise, I may delete it.
Don't worry though. First of all, you have chosen to discuss the topic, rather than resort to insulting comments. Second of all, the time when you inserted the sections was right after the MichaelIsGreat edit war, so that's why I quickly deleted it as an ad. Third of all, unlike MichaelIsGreat, you're actually a nice guy! SupaStarGirl 13:37, 7 January 2007 (UTC)
Thanks
I will rearrange the text into something that does not look like an ad. SupaStarGirl 17:33, 10 January 2007 (UTC)
Good re-addition of info. The Imperial, however, has 97 keys.
I have added a "{{prod}}" template to the article FSA Corporation, suggesting that it be deleted according to the proposed deletion process. All contributions are appreciated, but I don't believe it satisfies Wikipedia's criteria for inclusion, and I've explained why in the deletion notice (see also "What Wikipedia is not" and Wikipedia's deletion policy). Please either work to improve the article if the topic is worthy of inclusion in Wikipedia, or, if you disagree with the notice, discuss the issues at its talk page. Removing the deletion notice will prevent deletion through the proposed deletion process, but the article may still be sent to Articles for Deletion, where it may be deleted if consensus to delete is reached, or if it matches any of the speedy deletion criteria. Fram 13:41, 5 February 2007 (UTC)
Article on FSA broadened to better show its historical context
Additional context for FSA Corporation added, tying it to IBM, Symantec, and McAfee's histories, and also commenting on Theo de Raadt's history at the company.
Session Border Controllers
Hi Dan - I checked the previous edits and I notice you keep trying to add Jasomi as the technical innovator in the market, while someone else and I disagree. It's not that Jasomi did not have technical innovation (in fact fluffy was quick to point a couple out last night when I talked to him), but frankly every company thinks they created the most or a significant part of the technical innovation. You shouldn't work somewhere if you don't think it's true, IMO, and certainly you shouldn't be it's CEO if you don't think so! Trust me I firmly believe it's true of a different SBC vendor. :) However, so as to avoid an endless debate on such a subjective topic, I removed it and hope you will leave it at that.
Also, why would you think Microsoft even makes an enterprise SBC, let alone is a leader in the space?? I'm not in the enterprise side really, but from where I sit they don't even exist in the SBC market. For example they have strong partnerships with a couple of the SBC vendors, which they wouldn't do if they were in the game. —The preceding unsigned comment was added by Hadrielk (talk • contribs) 07:28, 23 March 2007 (UTC).
Hadrielk:
Thanks for the commentary. We clearly have some disagreements on the history of the field, and I'm afraid we're going to have to have a debate on the subject. Fortunately, Wikipedia makes that easy, and only we could make it unpleasant (I hope we won't).
Let's leave the Jasomi stuff for a moment, and talk about the other parts of your recent SBC edit:
First, could you please replace the information you removed about the enterprise side of the space. I believe your concern is about Microsoft. Their product, Live Communications Server, is an SBC, and very likely the most widely deployed enterprise SBC in existence today. Frankly, I wish it were not so, since it contains many extensions to SIP that are only described in proprietary documentation obtainable only under license. At Jasomi, we tried very hard to buy this information, first at a resonable price, then later at the price Microsoft was asking. Jasomi was acquired long before we were able to claim success on this front. Nonetheless, any reference to the enterprise side of the SBC space is incomplete without a significant mention of Microsoft LCS.
Second, I like the way you've broadened the protocol coverage in the first paragraph. Thanks for doing this. However, this createsa a bit of a problem in the 2nd paragraph, because B2BUA is a formal term in the SBC protocol, but is not recognized in those other protocols. So, the concept of a B2BUA applies to those other protocols, but I think it's worth mentioning that the name really only has formal meaning in SIP. Because of SIP, we all know what an "MGCP B2BUA" is. But in MGCP, you'd call it something like a "Back to Back Call Agent / Media Gateway" -- not that that's a defined term in MGCP though. But B2BUA is certainly not defined in MGCP or H.323, whereas it is in SIP. So, what should we do? I think we should keep your improvement in this paragraph, but note that the terminology is not the same in the other protocols. I'm happy to take a stab at this if you like.
Third, I'd like to better understand your rationale for including Borderware as a major enterprise SBC player. Perhaps the company is doing significantly better than I thought. Microsoft and Jasomi each had numbers of users well into the millions. I'm not too sure about Edgewater and Borderware but would like to learn more.
And now to your removal of the reference to Jasomi's technical innovation. The fact is that making SBCs solve real-world problems that customers actually had, was what Jasomi did best. In doing so, it advanced the state of the art in SBCs. I remember jaws dropping at a major customer in Japan when Johnson Wu and I first demonstrated inbound and outbound calls across corporate firewalls (without changing anything on the firewall). I remember a major New York trading bourse's network architecture group sitting in stunned silence as they realized they would not have to redesign their global netowrk to accomodate SIMPLE/VoIP, because PeerPoint would steer media and signaling through a layered mesh of fault tolerant signaling and media engines, alternating between encrypted and decrypted signaling and media streams, all multiplexed through a single TCP/IP port number (not just one call, thousands). I could go on and on, but we're not just talking about adding support for Radius, or finally getting fault tolerance down to a reasonable time.
Another thing that Jasomi was out in front with, was the notion of the SBC as an interoperability situation improvement tool. With N types of endpoints out there, interop was an order N^^2 problem. But with a variable-opacity SBC in the loop (as PeerPoint was), this problem was reduced to order N. Come to think of it, the SBC article doesn't mention this benefit of SBCs. I think I will make an edit sometime to correct that oversight.
Bottom line: I'm not willing to give up on inclusion of the information about Jasomi as innovator in the field. By no means did Jasomi have an exclusive on that. But in terms of paving the way forward in functionality, Jasomi's contribution was truly, as mentioned in the article before your edit, disproportionate. I'd like us to agree on how to put mention of that back into the article.
So far, this is a good conversation. I look forward to your response. -- Dan