At this point I suppose the SIP registration is successful but you encounter problems with the call, now check the following:
1. The outgoing VoIP call attempt fails?
First off check if the proxy rejects a request with a Route header. If so, remove the proxy address from the SIP settings.
If the call attempt is unsuccessful, that is, there is no alert in the other end, check the following:
- Are there any User Interface notifications?
- If yes, how long is the delay before receiving one?
- For testing purposes, wait at least 3 min. If the target SIP client alerts after a long delay (for example, 1.5 min), the extra delay is most likely caused by a TCP connection establishment attempt which times out. All VoIP service providers not supporting TCP should configure their firewalls to return the TCP RST or ICMP not reachable response. Force the UDP transport into use in the SIP settings
Possible err could be one of the ones listed hereunder:
Either the target is having another call or the ‘Do not disturb’ (DND) feature is enabled.Try calling some other target, this problem is on the receiving side.
Address not in use
Either the target SIP client was not registered (a WLAN coverage or NAT keep-alive problem) or the target URI was incorrect. Check the phone number or user name and domain carefully. Check the spelling, lower/upper case letters. The data is case sensitive.
Error in connection
This error notification means that the user is trying to establish a call but the access point does not support calls.
Internet call service not available
This error notification indicates problems with the server/proxy or other peer. If the proxy works with other SIP clients, there is probably some kind of interoperability problem.
Invalid Internet call address
Check the user name and domain carefully. Check the spelling, lower/upper case letters. The data is case sensitive.
This error notification can be caused by an error on the proxy, a possible SBC on the route or on another peer.
This error notification means that the SIP INVITE was sent to the SIP proxy and an alerting indication was received from the target but no connection indication within a prescribed time period.
The target can either be reached at several different locations, is no longer or only temporarily found at the address requested, or the requested resource must be accessed through the proxy given by the Contact field.The target was not registered. Check the URL.
The message from the proxy to the target was lost and the proxy reported a timeout.Either the target is not in the WLAN coverage or it cannot keep the NAT binding alive.Try calling rapidly (within 0.5 min) in both directions. If the other peer does not alert, for example, in 10 s, terminate the call attempt in the originating side and call from the other client. If this helps, the target client is most likely behind a NAT and unable to keep up the binding.
Unable to call due to recipient’s restrictions
Either the recipient’s terminal has no compatible audio codecs or the recipient has activated the Internet call barring setting for anonymous calls in the general settings. Or the clients are incompatible.Try using another client as a receiver.
2. The outgoing VoIP call has no audio or only one-way audio?
Sometimes the call establishment succeeds, but because of a NAT traversal or firewall problem the speech is only heard in one direction or not at all.A typical reason is that a totally silent VoIP client is behind a NAT and not configured to use a STUN to get the media routed through the NAT, and there is no SBC or NAT helper on the SIP server taking care of the situation. Or the STUN is used behind a symmetric NAT.
- Does your service provider support using a STUN for NAT traversal?
- If yes, ask them for client configuration data.
- Is the situation same if the client which cannot receive media is behind a different type of WLAN access router or the network of a different Internet service provider?
- There are cases when the NAT type is simply incompatible with the STUN server-based media NAT traversal. Enabling (or disabling) possible ALG function may help.
- There can also be various other reasons. The function depends on possible NAT boxes, for example, WLAN and/or xDSL access routers on the route.
- Some malfunctioning ALGs on some WLAN/xDSP access routers have also been detected. Upgrading the firmware of that unit may help.
- Are both VoIP clients using the same WLAN access router (or in general, are they both behind the same NAT)?
- Some NAT models do not support peer-to-peer packets sent through the public address of the same NAT.
- Does your service provider support using a STUN for NAT traversal?
3. Is the outgoing/outgoing call of low quality?
When you want the quality to be decent, be sure to go with a reputable Internet Service Provider (ISP). If your ISP is not very reliable (E.g. bad pings, slow downloads compared to others on the same speed plan) then expect the quality to be of a lower standard with echo and a time delay between talker and listener.
If you encounter problems with the outgoing call quality, check the following:
- If the NAT traversal is taken care of by a SIP server or an SBC, are you using the closest available one, that is, not from another continent? This can be affected by changing the SIP proxy address.
- WLAN cell or broadband capacity may be exceeded if you share the connection with many other devices.
- The WLAN interference level may be too high due to too many users on the same channel in the neighborhood. Try changing the WLAN channel (in the WLAN access point settings). Note also that the channels are overlapping, that is, if the default channel is 6, try channel 2 or 10. Channel 5 or 7 does not necessarily affect anything.
- Active Bluetooth devices, such as a wireless headset, operating on the same unlicensed frequency as the WLAN band increase the interference level as well.
- There may be, in some rare cases, problems in the broadband connection causing the performance to be too low for VoIP. Try using VoIP from a PC connected to the same access router with an Ethernet cable.
- Try disabling the Power saving setting in the WLAN settings.
- in 3G (WCDMA) networks, mVoIP, audio compression codecs might overuse the mobile broadband capacity, in this case you need to optimize audio compression codecs’ priority in your device. Generally, a codec with a higher bandwidth requirements provides better voice quality – only if your Internet connection is capable enough to support the codec.
- What audio compression codec should I use for my device?
- Both codecs PCMU and PCMA will give you toll quality but their bandwidth consumption is also the highest, i.e., requires higher bandwidth and doesn’t tolerate 3G latencies as well as G729 and iLBC. If your network bandwidth is low or variable (such as mobile 3G), choose a lower-bit-rate codec such as iLBC or G729 which will give you near toll quality at much smaller bandwidth consumption.
- Poor call quality may be caused by upload bandwidth limitations. For example, some providers have higher incoming bandwidth, but lower (even as low as 128kbps) outgoing bandwidth. In these conditions, have all participants disconnect and prioritize lesser bandwidth audio compression codecs such as iLBC or G729.
- You could try the registration and keep-alive settings, however the more activity, the shorter the battery life, though I can’t recall ever needing to re-charge more than once a day (obviously depending on the network condition).
- What audio compression codec should I use for my device?
4. Is the call dropped automatically and systematically after 30 s-3 min?
Call drop might be caused by a simple stupid mistake from user’s part – it’s a little confusing to be registered with the same account from two different sources/devices/computers and expect the server to know to which account to send the acknowledgements back (although it should know to send the RTP traffic to the proper client). With proper registration, from any device/client you shouldn’t get regularly disconnected. Check that you are not having a multiple registration simultaneously active with the same account.
In some cases the SIP message routing is broken. A possible reason is a malfunction on the SIP proxy or other SIP client, for example, inside the WLAN access router causing the SIP ACK (and all SIP requests inside the call) to be lost. The call is terminated when the SIP transaction timer fires. You could try the registration and keep-alive settings, however the more activity, the shorter the battery life, though I can’t recall ever needing to re-charge more than once a day (obviously depending on the network condition). In the worst-case scenario contact your VoIP service provider for assistance.
Some clients expect to get Real-Time Transport Control Protocol (RTCP) Receiver Reports. By default, the S60 VoIP client does not send them, which may cause a call to be dropped by the other peer after a time-out. A typical time-out value is 30 seconds. The RTCP can be enabled (“on”) through the Advanced Settings of the SIP VoIP Settings application;
advanced VoIP settings -> “name of your VoIP profile account” -> profile settings -> RTCP
Problems with Firewall and NAT
If you’re VoIP’ng thru WLAN your firewall may block you, certain ports must be open to the VoIP gateway to enable you to communicate with servers. The standard ports are listed hereunder. Check your firewall documentation for information about opening ports.
- Port type, number, Service
- UDP, 3478, STUN
- UDP, 5060, SIP
- UDP, 8000, RTP
- UDP, 8001, RTCP
You should always verify above configuration data with your VoIP account provider.
5. Is the call dropped immediately it is answered?
Most probably the media, Session Description Protocol (SDP) level, negotiation fails. Try using some other SIP client (for example, another Nokia S60 device) as a target.If the problem persists, the most likely reason is a malfunction on the SIP server or the ALG on the route is malfunctioning. If there is a firewall in a corporate network on the route, disable the possible ALG function.
This is one of the cases when SIP messages or IP logs help in solving the problem.
6. The incoming call fails
If you encounter problems with the incoming call, check the following:
- If the incoming INVITE using UDP transport is so big that it encounters IP fragmentation, check that the NAT or firewall is not dropping the fragments.
- The terminal has registered a SIPS URI but the incoming INVITE contains a SIP URI as Request-URI and the proxy is unable to upgrade the request from the SIP to SIPS.
7. Do you receive any response from the originating side (see above “The outgoing VoIP call fails”)?
If the outgoing call succeeds, but the reverse direction causes a ‘Request timeout’ error on the other side, try making rapid calls in both directions as described above “The outgoing VoIP call attempt fails?”.
If the problem is (temporarily) solved, the reason is that more enhanced NAT keep-alive methods are needed. Enable the CRLF keep-alive packets as described in, ‘NAT/FW traversal settings’. If you request information on the keep-alive method, see http://en.wikipedia.org/wiki/Keepalive .
- If the problems remains and STUN is used, the most likely reason is that the access router is incompatible with the STUN. In more detail, the NAT type is not full-cone as required by STUN’s correct function. For information on a full-cone NAT, see http://en.wikipedia.org/wiki/Network_address_translation .
- A malfunction in the access router and more than one VoIP (or in general, SIP) client behind it may also cause this problem. If upgrading the firmware does not help, consider changing the WLAN access router.
Nokia S60 NAT/Firewall traversal settings
Nokia S60 VoIP Implementation has STUN protocol support for NAT traversal and NAT binding refresh features. The NAT/Firewall traversal features enable the VoIP functionality behind NATs of certain type. The STUN/firewall settings cannot be edited from the device, but must be provisioned by the service provider.
If the STUN server address is not configured, the terminal tries to find one with a DNS SRV query using the Public User Identity domain of the used SIP profile.
Additional dummy packet (CRLF) refresh may be enabled by provisioning. The CRLF refresh is also enabled automatically if the STUN server is situated in a different address from the SIP proxy/registrar. The CRLF refresh is also enabled if there is no STUN server configured, and the user’s own IP address is in a private address space, since the terminal is then presumably behind a NAT. NAT/Firewall settings by default refer to SIP domain-specific settings. Refresh timers are overridden with IAP-specific NAT/FW settings, if IAP-specific values are defined.