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.

FSA Corporation

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

Danfreedman 10:13, 23 March 2007 (UTC)

-- Hadrielk, I'll give it another couple of days before acting. I presume you're likely traveling home from VON, or something like that. Please let me know if you need more time to respond. -- Dan Danfreedman 20:56, 25 March 2007 (UTC)

Re: Hadrielk

Regarding Microsoft LCS: what makes you call it an SBC? They don't claim to be an SBC, the LCS doesn't handle media, the LCS doesn't do topology hiding, no real protocol interworking, etc. I mean the only thing it is which SBCs are is a b2bua, but if that's the criteria for being an SBC then most boxes in networks these days would be SBCs. :) To me, being a b2bua is necessary but not sufficient to being an SBC. Honestly, you are the first person I have ever heard call the Msoft LCS an SBC.

Regarding Borderware: yeah a bit of a stretch, I agree they should be removed.

Regarding b2bua terminology: yup, in fact in my company (Acme), we've even used to discuss the MGCP one being B2BMGCA, andh.323 B2BGK, B2BGW, and so on, but it neveer stuck and now we just use B2BUA for all and people know what we mean.

Regarding Jasomi's dispraportionate innvoation: but this was all from your viewpoint. When talking with Cullen I was actually surprised that you guys thought you invented NAT traversal. I'm pretty sure Acme didn't, but we saw it from another vendor first - Netrake I think. But even so, that was one of many features. The protocol interop/normalization was definitely NOT an innovation by Jasomi, and neither was media steering. Acme had those, and knew their importance, since day-1, but we give a lot of the credit for the SBC concept to Audiovox, though according to Rosenberg Dynamicsoft had the signaling piece of it and controlled the Aravox media portion, which was news to me. As far as we know, we (acme) were also the first ones to realize a b2bua (vs an ALG) was the only real way to do NATing and topology hiding correctly, the first ones to do media steering and policing in hardware, qos monitoring for media, dynamic DDoS protection (which has still not been fully copied by others), TRIP, codec-based routing, etc., etc. Whether that's true or not is hard for us to really know, which is why I think it pointless to assert such on the wiki. Before Rosenberg's statement, for example, I had also thought we were the first ones to build the decomposed signaling+media control model (we built that before we built the integrated SBC we ended up shipping), but perhaps that was Dynamicsoft.

But anyway I'm not saying these things as a rah-rah for Acme - my point is I'm sure Netrake and Kagoor and NexTone and others all feel they had a large contribution of technical innovation as well. It is subjective as to what new "features" are technically innovative, and difficult to prove who came up with one first. When I first read the SBC wiki and saw the Jasomi bit (well actually someone emailed me about it), it sounded like sour grapes. From where I sit it's revisionist history. You want to make it sound like the other vendors copied your stuff, but the reality is Jasomi was not even on our radar screen. We (acme) never came across Jasomi in customer deals, and I was under the impression it was targeted more at enterprises than service providers.

-hadriel