FAQ

Any SIP-compatible device should be able to send and receive calls via PortaSwitch. You need to specify a PortaSIP server’s IP address or hostname as well as a SIP username and password for the corresponding PortaBilling account in the device settings. For additional information you can refer to the list of RFCs supported by PortaSwitch (Please refer to the Supported SIP RFCs section for more details).

You can use the 3-way calling feature, available in most SIP phones or ATAs. The full-scale SIP conferencing service is provided by a conference IVR application which is part of PortaSIP.

Yes, we can; however, you will have to purchase an additional consulting contract. Generally speaking, there should be no compatibility problems between PortaSIP and any standards-compliant SIP device. However, for obvious reasons we only provide detailed setup instructions for the Cisco AS5300 gateway.

To do this you need to use a SIP->H.323 protocol converter. Either purchase a dedicated solution, available from a number of vendors (for instance Aloe Systems www.aloe-systems.com), or use one of your 36xx Cisco gateways with the special IOS feature called UBE (Universal Border Element), previously called IPIPGW.

In addition to protocol conversion, you may also need convert codecs. This is not possible with IPIPGW, but you can use the Cisco AS53XX gateway by looping one or more pairs of E1/T1 ports on it to allow SIP->ISDN->H323 call flow.

Please note that, in the latter approach, one ongoing session will consume 1 timeslot in each looped E1/T1 (2 total), as well as 2 DSPs. For example, if you have two E1 interfaces connected back-to-back, the maximum number of simultaneous SIP sessions that you will be able to terminate to your H.323 provider will be 30, and each such session will use 2 DSPs.

PortaSIP supports the late offer-answer model; therefore these two elements can be connected directly. For more details regarding the supported modes and configuration, see the Cisco website.

Of course PortaSIP does not really allow unauthorized clients onto your network. If the SIP UA tries to register using an incorrect username or password, or with an account which is blocked, registration will not succeed. However, UA will still receive registration confirmation (and this is why you see “registered” in the UA). But if you try to make an outgoing call it will be diverted to the IVR, where the appropriate message will be played (e.g., “This account does not exist” or “Account is blocked”). This allows SIP registration’s troubleshooting to be greatly simplified.

Your SIP phone must correctly respond to keepalive re-INVITE requests. If it does not support this functionality, then it may either not reply at all to these requests, or (even worse) assume that this is a new incoming call. If PortaSIP detects that the SIP UA has not answered the first keepalive (at the very beginning of the call, when the SIP phone should presumably be online), then it assumes that the SIP UA does not support this functionality, and disables keepalives for this session. In any case, it is recommended to choose a SIP UA which supports re-INVITEs (e.g., Sipura).

The STUN RFC (http://www.faqs.org/rfcs/rfc3489.html) states: “This protocol is not a cure-all for the problems associated with NAT”. STUN is merely a service that can be installed on a server such as PortaSIP, allowing a STUN-enabled SIP phone to communicate with it and detect the type of firewall it is behind and the public IP address of the NAT router. Thus, a SIP phone may obtain certain information by communicating with a STUN server, but this will not have any effect on the way NAT handles IP packets traveling to or from the phone. In the case of a “cone” firewall, STUN information may help the SIP phone to determine in advance which IP address and port the remote party can use to communicate with it. However, in the case of a “symmetric” NAT this will not work, and so an RTP proxy is still required. Moreover, since this is a relatively new technology many phone vendors have not implemented the STUN functionality in its entirety, or completely correctly.

So, theoretically, STUN may be used in conjunction with PortaSIP’s RTP proxy: If a phone detects that it can bypass NAT via STUN, it will act as if it were on a public IP address, and the RTP proxy will not be engaged. Unfortunately, in practice activating STUN only makes matters worse, due to flaws in STUN implementation for IP phones.

Using two different approaches to handling NAT concurrently is the same as adding flavorings (salt, pepper, etc.) to a stew by following several recipes from different cookbooks at the same time: even a slight mix-up will probably result in your adding some of the seasonings twice, while not putting others in at all – and the result will be something which no one can eat.

Currently, one very common problem situation is that where a SIP phone is behind a symmetric NAT and obtains its public IP address from STUN, putting this into the contact information. This confuses the RTP proxy, since PortaSIP regards the SIP phone as being on a public IP address, so that no RTP proxy is used; the result is one-way audio.

So, the simplest answer is: yes. You can use STUN to avoid usage of an RTP proxy in some cases. At the present moment, however, due to unreliable STUN support on the IP phone side, the safest option is to avoid using STUN.

How many simultaneous voice conversations can be recorded by a combination of using a single PortaSIP server plus a single server executing the conversion?

Voice conversion is a resource-intensive task that fully occupies CPU resources while being executed (which is why a dedicated server is required.) A server can efficiently execute a number of concurrent conversions that equal the total number of its cores minus one (the remaining core will be used for executing OS tasks, monitoring, transportation of files to be processed and conversion results, etc.). Only one recorded call is converted per CPU core at a time.

On average, a raw RTP stream containing data for a 5-minute call has a size of about 6 megabytes (assuming the use of the G.711 codec), and so its conversion to a 2.4 megabyte .wav file takes about 1.5 seconds on a single 3 GHz core.

Assuming that a dedicated server for call recording has a 3 GHz quad-core processor, generally three out of four cores will be engaged to execute voice conversion. This server will be able to convert 3 * (5 minutes/1.5 seconds) = 3 * (300/1.5) = 600 concurrent calls that are being recorded on the PortaSIP server. If the number of voice calls being simultaneously recorded exceeds this number (e.g., during peak hours), conversations will continue being recorded and end users will be able to download them, but with a small delay.

When converting the same raw RTP to a 1.9 megabyte .mp3 file, it takes about 1.9 seconds on a single 3 GHz core. Therefore, a dedicated server will be able to convert 3 * (5 minutes/1.9 seconds) = 3 * (300/1.9) = 470 concurrent calls being recorded on the PortaSIP server.

The use of different codecs influences the time necessary for the conversion. Thus, for example, it takes about 1.7 seconds to convert a 1.7 megabyte file that contains raw RTP stream (assuming the use of the G.729 codec) to a 2.1 megabyte .wav file and about 4.8 seconds to convert the same file to a 2 megabyte .mp3 file.

Accordingly, a dedicated server will have the capacity to convert 530 concurrent calls being recorded on the PortaSIP server to the .wav format and 190 concurrent calls to an .mp3 format.

Therefore, the conversion speed increases with the number of cores the dedicated server has and depends on the codec used for voice transition.