- This topic has 11 replies, 1 voice, and was last updated 18 years, 10 months ago by
.
-
Posts
-
Had some free time and started to write. This is what my fingers typed.
Please, do not start a flame war. This is just my personal opinion.Very nice document. Thank you for your efforts Teodor.
A few comments:
“With Quintum you can change both the incoming and outgoing call signalling port.”
On the second generatation gateways, I have never managed to change the port the Tenor connects to, although I have changed the port it listens on. I think this point has been discussed on this forum before.
“And in 99% of the cases, the newest firmware image is the best one”.
Except perhaps P103. It has some real issues with settings being lost on reboot (country tone plan; codec profiles). But, to be fair, Quintum are still publishing their final P102 firmware and advertising it as stable, which it is.
Hi,
Yes, on the second generation Quintums you can NOT change the destination call signalling port for H323. But for SIP, you can change it in the SIP signalling group.
I am pretty sure, Quintum will apply back the ability to change the H323 outgoing call signalling port.For the P103 – yes, true. This is because they changed the format of their database =)
Check out inline response to your some of the points.
1. Odd routing logic. Based not on the longest match, but on the route type. Each type of route (PSTN, PBX, IP) has a priority.
If you have a 0* route through the “PBX” trunk group (LCRG), and a 001* route via PSTN (a TCRG group), Quintum will try first
to go through the PBX route, despite the longest match. Yes, this is really odd.Check out their “CallRoutingServer”. It takes out Routing complexity out of the box.
It is very simple,flexible and powrefull routing engine. If you have own more then 1 Tenor and you want to centrally control Routing then Routing Server is the way to go.4. Poor number rewriting engine. In comparison to Cisco’s SED-style rewriting engine, the one of Quintum is not a match
at all.Once again Routing Server can do very powerfull Number rewriting.
It supports “regular expressions” for pattern matching.8. Unlike Cisco, Quintum can not work simultaneously with SIP and H323. You have to choose one of the protocol via a configuration option.
Well, with Quintum you can always receive SIP and H323 calls Simultaneously, and to send selective H323 and SIP calls again use Call Routing Server. it can do it.
Hmm, sounds like someone with a lot of Quintum experience on the Call Routing Server. Hmmm, I wonder if you reside in Chicago perhaps? 😉
OK, pretty fine, I know what Call Relay (SP) can do, but… we are comparing here gateways, not softswitches.
Cisco with a MERA MVTS softswitch (in example) can do 5 times more than a Quintum gateway with Call Relay SP.
And if you have to buy a Call Relay for your ASM800 in order to have a normal routing logic and fair rewriting engine… Come on, give me a break… …
I believe that such comparison is very relative and cannot conclude the advantage of one solution over the other. Overall Quintum and Cisco products can serve absolutely the same purpose, depending on the budget and expectations. Below are several of my comments to some points from the document:
1. The number of simultaneous calls on Quintum are known because the call volume is limited by a software license. Cisco basically allows the administrator to sacrifice call volume for call quality by choosing different codecs. This is great!
2. I consider the ability of loading a different IOS on Cisco at any point of time another great advantage over any gateway vendor out there. Regarding version stability, just for the record, 12.1.(5) T8 has been rock-solid for years.
6. The debug output from Cisco is much more detailed, which I consider another great advantage.
8. When reading point 8, I came across the following question: if the E1/T1 span to the PBX side is down, how will the user from the PSTN side ever reach an extension on the PBX side “thus ensuring a transparently passage of the traffic between the PBX and the PSTN”? I believe that the previously mentioned “unique “relay bypass” functionality is actually widely implemented in the industry. For example, Cisco can be configured for route failover on span level depending on the return code from the ISDN (suppose the T1/E1 line is up and there is a protocol error of some type). However, if the D-channel of the span is down due to either a physical or signaling reason, then the gateway will not route the call out via that span at all. Another way to achieve failover either on IP or PSTN calls on Cisco is via back-to-back configuration on the spans. Furthermore, there are other solutions out there that provide even more intelligent route failover solutions for transparent call failover. What about channel failover?
a new rule –> if you want to gain experience into Quintum, you MUST relocate to the Chicago area. No other possibilites.
Even if you think that you have wide experience in Quintum, do not ever think to mention it, until you relocate to Chicago area 🙂
Otherwise – how dare you???!!!
1. We are comparing products, not solutions.
2. No, the gateways of Quintum and Cisco can not always serve the same purpose. There are numerous (I can freely name 3) of cases where one of the vendor’s gateway can not replace the other.
3. The Crossbar (X-bar) switches are rock solid too. Working for more than 50 years (and definitely will work more). But they seriously lack of features. Spread the 12.1.(5) T8 IOS among different installations and you will soon get complains of lack of features.
4. The debug of Cisco is not more detailed than the Quintum ones. Which gateway of Quintum you have in mind?
5. I think you have missed to understand how exactly the Tenor bypass feature works.
Game of words. FYI each “product” can be considered to be a “solution” as well. By offering products, vendors offer solutions indeed.
Teodor, I am pretty sure that I have not missed anything, but thank you for the note anyways.
For the sake of others who will read the comparison between Cisco and Quintum, the document is very misleading, the facts are superficial and not supported in dept. In fact, it appears to be a naive attempt to promote the more convenient for the author _solution_.
One thing not yet discussed is call handling capabilities. That is: calls per second. My company owns several DX gateways in London for VoIP –> Q.931. If you throw calls at the gateways, the call setup times can be as long as 10 or 15 seconds, whereas, normally, calls are set up in one second.
I have not managed to find any published figures for calls per second on the DX gateways, but my experience is that a DX-4120 can handle about 10 calls a second before it begins to slow down.
Anything faster tends to come from call centre customers with autodiallers, so we simply implement call gapping on our switch for those particular customers to get round the problem.
The answer may be to use a Quintum CMS, but I doubt it. And I have never used a Cisco gateway, so I do not know how they compare with the Tenor.
Hi, I agree that only the name of the document sounds “misleading” –> Quintum advantages.
If you look deeper at the document (I am sure you have done it, but you won’t admit it), I have pointed to the Quintum *DISADVANTAGES* as well.
So, I am not promoting any solution more or less convenient to me.
My comparison is anything, but biased.
At the other side, lets take a look at YOUR post. You are merely defending Cisco, not even a single good word for Quintum, or a bad word for Cisco.
So, which post is biased? Mine or yours?
Lets the other people reading the forum say that.
You have not understood how the Quintum “relay bypass” works. It works on HARDWARE level using the TECHNICAL ELEMENT called “RELAY”. Even if the gateway burns out, or I switch the power off, it will transparently move the traffic between the E1s, thanks to this “relay” (an element, not an action).
Before discussing any others documents as being “promoting” and “naive”, lets take a look at your documents. What have you written? A t least anything? May we take a look at it?
- The forum ‘Voice over IP’ is closed to new topics and replies.
