Contact Us

Customer Access




In SipCel, as an open mind business, we’re just open to offer the service under all possible modalities, thereof we provide the service over tow different type of transport protocol, TCP, and UDP.

The common question, is what to choice, and where is the difference. Here, before going ahead, let’s understand the TCP is referring to Transmission Control Protocol, used commonly in World Wide Web Sites transmissions, meanwhile the UDP is the User Datagram Protocol is a transportation protocol that is one of the core protocols of the Internet protocol suite.

But, what’s mean the one, and the other. Let’s take the following example. Using portal service, rather the Parcels, or the DHL, or UPS, all of them provide the end purpose of the service, handling, and transporting our letter to a certain specified destination. Both, are effective, but the difference is, with the standard parcel service, we just send a letter, and the letter is gone, no simple way to trace it, no any guarantee that the letter are being handled to the destination, no any way to trace if the letter was received by the specific destination person. Meanwhile, UPS, or DHL, may handle the letter within the same, speedy, or other specific express service, but, they may provide us online, live proof to trace the letter, and deliver it to that specific destination, and may also trace us back within a report when the letter was delivered. Both are handling and delivering service, but, one provide tracing, monitoring, and other not, one provide delivery notification, and the other no…etc.

Let’s compare here. TCP, are similar to the DHL, or the UPS, or even, the registered service by the parcels postal service. It provide handling responsibility, where our transported package are always surly delivered, and if not, the package will stay re-transmitted, until delivered. But UDP is the fastest way to send the package to the destination, as soon as the package is packed. No any proof if the package was handled, no any proof to trace it, the unique proof which we can have, is that our package was sent.

So, here, after this explanation, let’s expose pros, and cons, of all of this.

  1. Responsibility. TCP is a really secure handling way, that we send our package within a responsible post man, who may take charge of our package, and be responsible to handle is, or bring it back to us. Meanwhile UDP don’t include such as promise in his service.
  2. Security. Imagen that we send a package including sensitive information. It’s highly important to insure the reception, where TCP are responsible, meanwhile UDP may just send our litter in a bottle into the Ocean, it may arrive, and may never do, or maybe received by some one else. This may not be a certain issue, as both are destinate to a specific IP (Internet Protocol). But, remember here, that Sort Message Service, SMS, is also being handled by UDP as it’s a fast way to transmit our data. Meanwhile an SMS package may include sensitive information understandable for humans, but media packaged, are non understandable for human, so dose this is really a question to discuss over SIP service? Certainly not, as our media package are non understandable for humans, so, let’s forget the security issue.
  3. Speedy. Here is the important issue. I want to talk to my customer, and what I want is a flood communication and conversation, where I don’t expect any interruption in the service, when I talk to him, I want that he here exactly what I say in this exact moment, in real time, and without any delay. Imagen, where TCP is responsible to handle all over our package, but, when he cannot do, he try and retry, and also, if he lose some package, or if a package confirmation is loosed in the way, he try to retransmit it. That’s mean, our conversation may become horrible… we may hear some worlds with delay, repeating, or even, if package handling confirmation may loose, the conversation may full down. Otherwise, UDP, may provide fluent conversation, no matter if we loose some worlds into the conference, but, it provide certain fluent conversation, which is exactly what  we really need.
  4. Session timer. UDP as a fast retransmission protocol, have lower session timer then the TCP. what’s mean, is, when we are over 3G devices, for example, we need to refresh the session as maximum as 800 seconds, if we need to be qualified by the network and expect receive calls from the net. Meanwhile, TCP may keep as the session over 1200 seconds, and there is no real need to refresh our session. What’s mean, is a battery saving over TCP over 30% more then the UDP usage.
  5. Ports. Over SIP service, TCP are vailable to connect exclusively over the standard VOIP port 5060, which is in must cases are blocked by the ISP operators. Meanwhile the UDP are flexible, allowing us to whatever port we like, and as in SipCel we handle the service over port 443 to avoid ISP monitorization.

In conclusion.

In SipCel, as a standard configuration, we do handling the service over UDP protocol, into port 443, packing within 20ms, over 8Khz, keeping the sessions alive for 800 seconds. Within that configuration, even the simple handset devices, like Samsung Galaxy Y, which have a simple 1300 mAh buttry, are being usable for around 14 hours, without any serious battery problem, to guarantee the service redundancy, and provide an acceptable media quality over the 3G networks.

For that customers who certainly like to go into TCP, also are welcome, in the App, just try to turn the transport mode to TCP, port 5060, and go ahead testing, you may save little bit more battery, but you may loose the essence of the service, the media quality. For what we need an available phone, when we receive a call, we can’t talk fluently?

We just do it Simply, and can’t be more simple then simple

<<Everything should be made as simple as possible, but not simpler>> Albert Einstein (1879–1955)

In SipCel simplicity is our Spirit, and Serving your Business is the Spirit of our Business!!

Leave A Reply

Your email address will not be published. Required fields are marked *

Time limit is exhausted. Please reload the CAPTCHA.