Frequently asked questions


This email address is being protected from spambots. You need JavaScript enabled to view it.

C2Call Developer Network - FAQs

Here is a list of the questions we get asked most frequently, with their answers. If you don't find an answer to your question, please contact us


We spent the past 5 years developing our own mobile communication technology for the cloud, which is unbelievably efficient to operate. The way we have been hosting and monetizing the FriendCaller apps has generated millions of dollars revenue over the last few years. That's the reason we decided to open C2Call SDK to all developers for free.
Your part is to build great apps with C2Call SDK, and we will host them for free. Let your users make as many Video calls, Voice call as they want, send unlimited messages and transfer rich media. Pay us only when you are successful. We know, how hard it is!

First of all, we will be very happy for you that your App got popular! Your app will continue to work meanwhile C2Call Team will contact you to either convert you to Pro or Enterprise account.

These are paid services where we have to pay service providers for each call or SMS you app users send. Think of your account as the master account that is used to top up your users pre-paid accounts.

If you are running low on funds in your developer prepaid account, we will alert you via email. You will get sufficient time to top up your developer account so your users won't experience service disruption. If your developer account funds reach to nill, then your users will be able to use their pre-paid accounts but no credit can be added until your developer account is funded.

C2Call SDK comes with built-in Ad spaces that are fed from leading Ad networks like Flurry, RadiumOne, Sponsorpay and others. All you need to do is to register with these networks and we do the rest. You will receive your full payout directly from these networks. We just want you to earn all the revenue yourself.

Encrypted communication protects the privacy of the communication when the transport layer is encrypted to prevent eavesdropping. End-to-end file encryption will use an app specific certificate to encrypt the file. Any media file transferred using the latter technology will allow only your app to open that. So for example: A photo, which is sent by your app can only be viewed by a device with your app installed; ideal for enterprise communication.

We work closely with Flurry, which is the world’s leading analytics provider for mobile apps. You will find all relevant usage and events predefined in your Flurry dashboard and can add your own as you activate SDK features.

Each time a new user signs up to your service, you can send a welcome email with verification link to that user on your behalf. This email will have a verification link which when clicked will complete the email verification and will auto opt-in the user for your newsletter service.

Yes, you can verify phone numbers by sending SMS with a unique PIN. Also you can initiate an automated voice call that reads the unique PIN to the user in several languages. When this feature activated, SMS and phone charges apply to your developer account.

The C2Call community consists of all the apps that are powered by C2Call including FriendCaller (having more than 11 million registered users). Please apply for approval that your users can communicate with users from other C2Call powered apps. We will be happy to facilitate your request.

Selected apps powered by C2Call SDK are featured in our weekly C2Call newsletter that is sent to millions of 100% opt-in users. These users also get push notification with the download link. All of this is offered at no cost.

C2Call SDK comes with built-in Ad spaces that are fed from leading Ad networks like Flurry, RadiumOne, Sponsorpay and others. All you need to do is to register with these networks and we do the rest. You will receive your full payout directly from these networks. We just want you to earn all the revenue yourself.

Encrypted communication protects the privacy of the communication when the transport layer is encrypted to prevent eavesdropping. End-to-end file encryption will use an app specific certificate to encrypt the file. Any media file transferred using the latter technology will allow only your app to open that. So for example: A photo, which is sent by your app can only be viewed by a device with your app installed; ideal for enterprise communication.

We work closely with Flurry, which is the world’s leading analytics provider for mobile apps. You will find all relevant usage and events predefined in your Flurry dashboard and can add your own as you activate SDK features.

Each time a new user signs up to your service, you can send a welcome email with verification link to that user on your behalf. This email will have a verification link which when clicked will complete the email verification and will auto opt-in the user for your newsletter service.

Yes, you can verify phone numbers by sending SMS with a unique PIN. Also you can initiate an automated voice call that reads the unique PIN to the user in several languages. When this feature activated, SMS and phone charges apply to your developer account.

The C2Call community consists of all the apps that are powered by C2Call including FriendCaller (having more than 11 million registered users). Please apply for approval that your users can communicate with users from other C2Call powered apps. We will be happy to facilitate your request.

Selected apps powered by C2Call SDK are featured in our weekly C2Call newsletter that is sent to millions of 100% opt-in users. These users also get push notification with the download link. All of this is offered at no cost.


 

Java Applet


Video calling functionality has been implemented based on Java(TM) technology. A Java Applet will be launched as browser plugin. The plugin requires to access your Microphone/Speakers/headset and your video camera. Please select “trust” or “always trust” to enable the Java Applet for video calling functionality.

In order to run the Java Applet as browser plugin, several security constrains have to be fulfilled otherwise the browser will reject to run the Java Plugin

  • The Java Certificate has to be valid and be accepted (trusted) by the user
  • The Web-Site launching the Java Applet and the Java Applet itself has to be loaded via https (SSL secured connection)
  • The Java JRE (Java Runtime Environment) has to be the latest version. Most browsers, especially on Mac OS X reject to launch the Java Applet on older Java versions.
  • The Java Plugin must be loaded from a location which is explicitly allowed in the singed JAR File Manifest attributes, either as IP address, as domain or as wildcard domain

In order to find out why the Java Applet is not loading, we recommend to enable the Java logging and tracing. This can be done in the Java Control Panel under section „Advanced“. Please enable tracing, login and lifecycle exceptions and „Show Console“.

After the settings have been applied, the browser and all running java sessions have to be terminated. Restart the browser and try again. The Java Console will automatically come up and report any issues. Please send the full Java Console output for 3rd level support analysis.

In some rare conditions, the Java Applet is loading successfully but the connection to the service cannot be established. While the Java Applet will be loaded via HTTPS connection which it a TCP/IP connection via port 443, the actual connection to the service for VoIP and video calling will be done via connection less datagram protocol (UDP) using various ports. In some network environments the communication with the outside world is very restricted through the firewall.

In some cases UDP data traffic is explicitly blocked by the firewall, which means no UDP packets can by sent or will be received by the Java Applet. The Java Applet has a fallback method implemented to overcome those problems. When the Java Applet has been started, the App will probe the network try to establish the communication with the server via UDP protocol on various port ranges. If this fails, the TCP/IP tunnel connection via port 80 will be automatically established to a tunnel server. All UDP packet will be then sent through that tunnel and the tunnel server will forward the packets to the actual destination and vice versa. This should work in most cases, even though a higher latency during a call can be expected. In some cases, the firewall is doing stateful packet inspection. As port 80 is usually been used for HTTP protocol, the firewall might block any data which is not conforming to HTTP protocol. In those cases, the connection cannot be established until the firewall rules have been changed.


Use ports and protocols:

SIP Protocol (UDP Data) : UDP Port 5060, 6060, 25366, 43233 (This ports will be probed and the first where a response is received, will be used)
RTP Protocol (UDP Data) : 1 Random UDP Port between 1025 and 65535 during a call
TCP Tunnel (TCP Data) : TCP Port 80 for non HTTP data

If the Java Applet cannot be called while it’s connected and the user is shown as online this is typically caused by some network or firewall issue.


There are two main scenarios why this can happen:

  1. The firewall/NAT closes the hole too early. This means the Java Applet can send a packet from inside the firewall to the server, but the server has only very limited time to send a packet back. Normally when sending a UDP packet from inside to and outside server, the firewall/NAT allows response packets 45-60 seconds from that destination and port to be delivered. Therefore the Java Applet send a keep alive packet in regular intervals (every 25 seconds) to the server to keep the firewall open for calling requests coming from the server. This method is called UDP hole punching (http://en.wikipedia.org/wiki/UDP_hole_punching). When the firewall closes this hole earlier then the keep alive interval, calling requests may not be received. Please change the firewall setting to extend this interval.
     
  2. The MTU size (Maximum Transmission Unit) of the network is set too small. The MTU size defines the maximum size of the data packet for transmission on a physical layer like a WiFi or ethernet connection (http://en.wikipedia.org/wiki/Maximum_transmission_unit). A typical SIP INVITE packet, which is send to call a remote party is about 1300 bytes. With the regular MTU size of 1500 bytes, this SIP INVITE packet will fit into exactly one physical packet. When a remote party will be called, the caller Java Applet will send a SIP INVITE as UDP packet to the server.
     

The server will then forward this packet to the last know address of the receiver. If the receiver is behind a firewall, which has a smaller MTU size defined then the current INVITE packet requires, the INVITE packet will be automatically split into two or more physical packets. Some firewalls will reject SIP/UDP packets which are split into multiple parts, as they often do stateful packet inspection and let only packets in, which looks like valid packets in the specified protocol (in this case the SIP protocol). As the actual SIP packet has been split into 2 or more parts, the firewall might not longer be able to recognize the packet as valid and reject it. Therfore, the remote party cannot be called, even though it’s correctly connected and registered with the service, since the register packets are much smaller and the register responses from the server will pass the firewall without problems.

The actual video quality in a call depends on various factors.

  1. The available network bandwidth between the two parties in a call
  2. Is the connection peer-to-peer or a relay connection
  3. Are both parties in different networks or in the same network
  4. Is the device powerful enough to do the video and audio processing
  5. Is the network a home WiFi, public WifI or corporate WiFi

During a video call, the bandwidth and the packet lost rate is constantly measured by the video calling App. High packet lost rates are typically indicating network congestion problems. This means the amount of data packets sent by the video calling client is higher than the routers on the way between the two parties can handle. A router is connecting two or more networks and transfer data packets between those networks. If the amount of packets to transfer is higher then the actual queue size of the router, an incoming packet will simply be discarded. In TCP protocol, a discarded packet will automatically be retransmitted, therefore this might cause a delay on the transmission but the packet will not get lost. In a video call, the communication is based on UDP, where a packet will not automatically be retransmitted. Therefore the packet gets lost. So, a high rate of packet loss is a strong indicator, that the amount of data submitted is too high and the bandwidth must be lowered. The video calling app will automatically do this on packet loss detection by reducing the frame rate (amount of pictures sent per second) and finally by deducing the resolution of the video image. The packet loss will cause video artifacts in the video image, if the retransmitted video packet does not arrive in time. The picture will be disturbed and a keyframe has to be sent in order to rebuild the video image on receiver side. Also a lower frame rate and a lower resolution will reduce the quality of the image on receiver side. If the picture keeps to be disturbed even after the resolution has been significantly lowered, the bandwidth might by still too high. In some cases, especially in case of Home WiFi routers/cable modems, it helps to restart the router to improve the bandwidth and the video image quality. Very often those Home WiFi routers have a bad quality and while TCP traffic is still going good enough, UDP traffic is badly served.

When establishing a video call, the two parties are trying to establish a peer-to-peer connection. This means, the two parties are sending the data traffic directly between each other. In some cases (approx. 30% of all connections), the firewall prevents those peer-to-peer connection and as a fall back, the communication clients will use a middle man (a relay server) in order to establish the connection. This relay server will add additional latency and additional distance to the connection and therefore can result in a lower call quality. This can result in audio / video delay, lip sync or bandwidth issues.

When a call between two parties is done, while both parties are in the same network, the actual data traffic will still go outside and come back in. This will result in most cases in a relay connection and, as the data traffic has to go out and come in again, the bandwidth requirements are double compared to a regular call, where the remote party is in a different network. This can result in a lower video quality for reasons explained above. When both parties are even in the same room, you might hear a strong echo or even interferences.

Doing the video encoding and decoding and presentation as well as the audio encoding and decoding, is a CPU and memory intensive process. Dependent on available video hardware acceleration this can cause heavy CPU loads. When the CPU load is too high, the codec will automatically reduce the video quality of the output video data. On very weak hardware the video decoding and presentation can significantly hold up the video encoding so that only a very low frame rate will be achieved. Both clients are automatically trying to detect those scenarios and automatically reduce resolution and frame rate to avoid that the system gets out of balance. But in rare cases when the hardware it too weak, this cannot be handled good enough to produce a reasonable video output. Too high CPU load will be indicated by a high fan activity during the call. Especially on notebooks, that’s a good indication for the diagnose.

The actual WiFi location is very important for the diagnostics. A Home WiFi is very often suffering from an old /cheap WiFi router with limited capabilities or even a lot of bugs. For example you can do 3 call in a row which are working fine and the 4th and any further calls will not longer be working until the router has been restarted. In a public WiFi in most cases, many devices are connected to that WiFi and create traffic which often leads to congestion problems and packet loss. In some cases, only http ports are open while other traffic is blocked. In a corporate WiFi the problem in most cases is a very restrict firewall setup which might prevent VoIP/Video traffic. In this cases, the firewall admin must be involved. Also congesting problems due to the high number of devices in the network can be an issue.

This is a typical scenario where significant packet loss happens on the connection. The video data is transmitted in two different frame types. The keyframe and the intermediate frame. The keyframe will be always sent at the beginning and from time to time during the call. This a is full picture frame of a reasonable size (for example 20 kBytes) which will be split into approx. 16-20 video packets which will be restored at the receiver side.

The intermediate frames are differential pictures which are containing only the differences between two pictures and are much smaller then the keyframe and typically result in 1-2 video packets. As the keyframe consists of a lot more video packets than an intermediate frame, it’s much more likely to loose one or more of the 16-20 packets. If that happens and the retransmission of those packets are not arriving in time, the keyframe cannot be restored. Without initial keyframe the video picture cannot be presented and the video screen remains dark. When the keyframe arrives, but one or more of the intermediate packets are lost, the video picture will be display but the picture might be disturbed until the next keyframe arrives.

In order to analyze those scenarios, please turn on Java Console logging as described above and send us the output. Packet lost will be reported in this log and can be easily found.

About us

C2Call GmbH leads the way in introducing next generation mobile and browser-based calling solutions for the computing cloud. FriendCaller for iOS and Android are built using C2Call SDK, and demonstrate the unique capabilities to establish a peer-to-peer connection with any mobile platform and with any Internet browser without prerequisite software installations. With the new C2Call SDK, developers would now be able to integrate features alike FriendCaller in their existing or new apps on mobile.