User talk:Danfreedman

From Wikipedia, the free encyclopedia

&==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)

Contents

[edit] 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.

[edit] 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)

[edit] 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.

[edit] 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).


[edit] 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)

[edit] 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 Aravox, 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 —The preceding unsigned comment was added by Hadrielk (talk • contribs) 13:58, 26 March 2007 (UTC).

[edit] Re: Hadrielk

Concerning Microsoft's LCS, it is true that the initial version did not handle media, but it did ultimately and now still will steer media, for example via their joint project with Ingate or through Microsoft's own corporate firewall of sorts, Microsoft ISA Server. I have seen LCS used both ways - as what we all used to call a proxy, or perhaps these days a feature server, and what we should call a SBC. I suspect the greatest use of LCS these days is to deal with IM, but it is a fair statement to say it has many of the capabilities of other SBCs, albeit with an enterprise focus. But then again, that was the topic being discussed in that paragraph -- enterprise. So while I am in no way an LCS defender, I think it is fair when discussing the enterprise end of the SBC business to include Microsoft's product in the mix. For deployment within the enterprise (albeit for IM-based text, voice, and video), I still say it's among the most widely deployed _within the enterprise_.

And back to innovation. When you mention NAT traversal in your most recent response, I believe you're referring to what we called "near end NAT traversal". Near end NAT traversal is where the SBC works either co-operatively with a firewall or (more frequently) as a sidecar solution sitting in the DMZ or behind a firewall. The task of a SBC doing near end NAT traversal is to get the VoIP through the NAT-firewall it is sitting close to (ie: at the "near end" of the call). Jasomi was an early player in near end NAT traversal (2001/2002), but does not claim to have invented the technique.

The other kind of NAT traversal is "far end NAT traversal". In far end NAT traversal, the SBC still sits close to a firewall at the near end of the call. But the SBC's job is to get the VoIP streams through the NAT-firewall at the _other_ end of the call without the knowledge or cooperation of that far end firewall (all in the days before STUN or ICE had been deployed on anyone's IP phones). The benefit of far end NAT traversal was that the customer simply plugged in an IP phone somewhere on his LAN (supplied by a service provider), and everything just worked. I know of no VoIP-related published work, be it in the form of a product, paper, or even advertisement, that predated Jasomi's release of this feature in the PeerPoint product. Now, did someone else invent this feature in a VoIP context prior to Jasomi? It's not impossible of course, because companies don't always talk about their inventions. But if you're saying that another SBC company had this significant feature prior to Jasomi, please bring that information forward. Note that I'm talking about far end NAT traversal, not near-end.

You mention Acme's realization of the B2BUA as the evolution of the ALG. However, I'd be interested in the time context of your release of this feature on a product. At Jasomi, we demonstrated a B2BUA-based SBC in two versions at Fall 2001 VON. First was PeerPoint, aimed at inter-carrier peering. Second was NatPoint, aimed at the carrier-to-customer interface. We had no ALG-based product at all during that time period. However, we did release one in mid-2002 that turned out to be quite successful for the company, and was the first PeerPoint to feature the far end NAT traversal feature. Eventually, these product lines merged when we added variable opacity to the B2BUA. But once again, this is the untold story of Jasomi's innovation.

You go on to mention that Jasomi was not on Acme's radar screen. I'm sure that is true from a sales perspective. Indeed, it is interesting that there are many different kinds of customers, and not every SBC company sold to each one. I don't find this remarkable. Jasomi had a different job to do in order to be successful when compared to Acme. I tip my hat to Andy Ory and the entire Acme team for taking it so far. But that trajectory was not the one sought by Jasomi.


By the way, the majority of Jasomi's customers were service providers, not enterprises. But Jasomi targeted tier 2 and tier 3 SP's, not tier 1. These were the telcos struggling with far-end NAT issues as they enabled (for example) S. American small businesses to have Miami phone numbers for a few $/month. That's why Acme and Jasomi didn't cross paths that often.

I feel I must insert at this point a statement saying that I agree with your assertion that both Aravox and Dynamicsoft (indeed, working together in some areas) made some of the most fundamental breakthroughs in the field. I also agree with your point that every company in the field made some contribution. So, the question is, is it worth trying to capture some of this in the SBC Wikipedia article? I feel it is, and I feel that collectively, we can do a much better job than we've been doing of outlining what came from where.

Let's start to list some of the important breakthroughs in the field, and talk about where they came from and when. Then we'll have the basis for putting a real context on innovation. I believe this will serve us much better than the sort of bickering that has been going on so far.

I notice you agree with my comments concerning the B2BUA name, and concerning Borderware. Would you like to make the appropriate changes/reversions, or would you like me to? I'm loathe to revise other people's revisions unless they've been abandoned, or unless they are vandalism. Neither of those apply in your case. Let's continue the discussion, and figure out a way of turning the controversial mention of Jasomi's innovation into something constructive that we can use to insert more definitive information into the article. Dan Danfreedman 10:02, 27 March 2007 (UTC)

[edit] Re: Hadrielk


Microsoft an SBC?
If being able to steer media with the "cooperation" of another box is sufficient to be labeled an SBC, then the list of SBCs will grow very very big. Heck, the Cisco Call Manager would have to be included, and Msoft pales in comparison for deployments. I mean in some respect most every traditional SBC which has media steering enabled is "helping" another box steer media, but it doesn't make that other box also an SBC. The only piece in the LCS which goes above and beyond the usual is they can munge SIP headers and make the signaling side of NAT work (sort of - if you ever see traces of what they do you realize it won't work for all applications, but at least they're scriptable).

But really, if even Msoft doesn't call themselves one, why should it be so on wikipedia? Can you find other sources that say so?

Microsoft has "packet forwarding" abilities in windows - are they then one of the largest enterprise router vendors? And they have firewall software - do they compete with CheckPoint/Netscreen/Pix? Methinks not.

NAT traversal
Nope, I wasn't referring to near-end NAT traversal. I was referring to far-end (in Acme we call it "Hosted NAT Traversal"). Again, it wasn't acme who invented it as far as I know, though I will say we rarely publish papers/datasheets on such things until we feel all of our competitors already know about it. In fact even then we keep it fairly generic. But for this specific feature I will ask around when I get back to corporate where we heard about it first.

B2BUA
Indeed 2001 would have been our year as well I believe, but who knows what the date was. I doubt even our founders would know when that would have been. The only reason I even mention it is because being only an ALG was one of the technical failures of one of our competitors, which partially led to their downfall (but only partialy). What you call "variable opacity" (a great term!) was also available on us since day 1 I think, though we describe it as something else. But really I'm speaking beyond my knowledge and only on heresay to go back that far - I was not at acme back then.

The big question we always get asked is who coined the term "Session Border Controller". We take some credit for it (and it's certainly arguable we marketed the term like none other), but we can't be sure.

Putting it on wikipedia
In order to do such a thing justice you would have to get representatives from all of the players back then. I have no idea what Netrake or Kagoor did, or think they did. And that last part is the rub. There is no way to prove any of this that far back. None of us patented any of our inventions (well, that's not totally true, we patented some, but hardly any). And as start-ups mum was the word on most things.

If you look at other such wiki product pages, like routers and firewalls, they do have a history section but they don't get into specific features. To me that it keeps it devoiod of marketing, devoid of any subjective analysis of what features are more important, or from guessing who delviered what first. If we go down that road, then the next thing will be "who had working code first", then "well who deployed it first", then "well who announced it first". Down the rat-hole it goes.

I think we should just follow the lead of the other wiki's and do a brief history of the first vendors - which is basically what it is now.

(p.s., sure I'll edit it right now for the other nits)

--Hadrielk 01:14, 29 March 2007 (UTC)

[edit] Re: Hadrielk

About LCS being an SBC. You'd asked for some background material that would help make the case for LCS as an SBC. I'd try this document for a good overview. Note especially the diagrams. Note that the focus is on using LCS to support Microsoft's own VoIP client (Messenger), and so the solution presented there is appropriate for IM. But with the addition of a media relay (such as the old Aravox box, the Ingate box, or the Jasomi box, and no doubt there's an Acme box that will just do media relay too), the solution is valid for voice.

I don't agree that a network element has to carry or even steer media in order to be an SBC, although most do. The job of an SBC is to solve one or more problems associated with network edges or borders. In some cases, these are technical problems caused by firewalls, NATs, filtering routers, and so on. In other cases they are jurisdictional problems, such as providing a demarcation point at which various control or measurement functions can be undertaken. The bottom line is that there are many roles for an SBC, and the media steering you refer to, while certainly an important function, is only one of them. Also, some SBCs have very interesting functionality that is absolutely nothing to do with borders. For example, some have registring proxies, dialed number translation, call recording, and so on. These are nothing to do with controlling sessions as they cross borders, but they do not prevent the network elements that implement them from being known as SBCs. So, is LCS an SBC? Let's leave aside the quibble about whether it really handles SIP as defined in the drafts (and it is a quibble, because the blunt truth is that no SBC today handles every nuance of all those drafts). LCS clearly has functionality that is not required of an SBC, such as the ability to log IMs, have dial plans, and so on. Likewise, LCS clearly lacks some functionality that other products known as SBCs have, such as the ability to relay media. But LCS is an SBC for the following simple reason. Many customers deploy LCS to control and demarc SIP-like and SIMPLE-like call streams at the internal or external edges of their networks. While the LCS home server is not acting as an SBC in this instance (more like a feature server), the peripherally-deployed LCSs are usually *solely* there to deal with network boundary issues as mentioned previously. It's tough to avoid classifying this as SBC functionality, whether it steers media streams or not.

About as far as I'll go on this subject is to admit that the definition of SBC is fairly loose. Where's the line separating an SBC from a feature server or proxy? I think the SBC article would benefit from an exploration of this subject, and I will move it forward. But to claim that LCS is not an SBC simply doesn't match the large, real-world scenarios in which it is deployed as a cluster of servers, many of which are there exclusively to deal with boundary issues.

I do agree with your assertion that Microsoft doesn't seem to use the term "SBC" in its literature. Still, this doesn't stop it from being one. Microsoft often has its own names for things.

I'll have a go at re-wording the section you changed, to see if I can make the wording a bit more palatable to you. But removing Microsoft from mention in the enterprise section doesn't make sense. I'm surprised you feel so strongly about it if you're a bit distant from the enterprise side of things.

About the origins of far end NAT traversal. In the absence of any evidence to the contrary, I maintain that Jasomi was first to bring this significant enabling capability to market. However, it's a big world with lots of companies doing confidential things. I will defer any further discussion on this issue until such time that evidence to the contrary appears. In our discussion, we started to talk about this in the context of Jasomi's innovation and whether it was disproportionate to its size, as mentioned in the article. While I still maintain that it was, I would like to avoid the appearance that this diminishes the innovations of other companies. Accordingly, I will let the deletion of the sentence about Jasomi's innovation stand, and will come up with a better way at some point to identify the origins of the different operational modes of SBCs.

About commentaries from around 2001: I agree with your suggestion that those who were there at the time would be the best ones to comment on what actually happened. But if you want to comment on such things yourself, you should be able to find a few people at Acme who were there then. With their input and your sense of perspective (which I think is pretty good overall), you should be able to add quite a lot.

About Wikipedia: Actually, I think the firewalls page does this in the right level of detail. Fairly broad in terms of classifying the generations of product, but with clear articulation of origins. That's what I'm looking for. Certainly the firewalls article outclasses the SBC article in this respect (as so it should, having received considerably more commentary over the years).

Bottom line: I hope you and I are back on the same page (perhaps literally). Thanks for pointing out the negative reactions that could result from mention of Jasomi's innovation. I think removal of that phrase serves the page well. Over time, we can replace it with something broader that lets readers understand the origins with a more appropriate level of detail.

Dan Danfreedman 22:24, 29 March 2007 (UTC)