VoIP: SIP phones cannot make and, or receive calls

The calls not completing come in two scenarios:

1.       The called phone does not ring 
2.       The called phone rings but no sounds

For phone to make, or receive calls it must be registered. Registration is performed when the phone first comes on line. This process is explained in article number 6535. It authenticates to the phone server, wherever it is located. When a call is initiated it has to authenticate with the server again. The server is authorizing the phone to make the call. These restrictions are normally provider, and admin controlled. This is not a firewall function.

The reason for this separate article is the process for completing calls is almost the same with different response codes, and additional mechanism occurring. All of this traffic is still on port 5060. The response when initially registering is 401 Unauthorized, when going through the call registration process it is 407 Proxy Unauthorized.

One of the major reasons for calls not completing the phones looses the registration. If the Sonicwall is handling the transformations, the inactivity timeout is 1800 seconds. Most deployments are configured with a setting of 3600 seconds. The recommendation is discover the value used by the provider, and add 120 seconds to the value. If the firewall is not handling the transformation, the timeout is handled with rules. This is not an option on standard firmware. Some implementations will a mechanism like “STUN,” once defined as Simple Traversal of User Data Protocol (UDP) Through Network Address Translators (NAT), now called Session Traversal Utilities for NAT (STUN) RFC 5389 to get around this issue. To use such a mechanism is the implementer’s choice. If something like STUN is used, disabling transformation on the firewall is recommended. It has been observed to resolve the problem. 

From: "W2K laptop"<sip:301@172.16.150.199>;tag=3d02b714

Call-ID:

CSeq: 1 ACK

At this point it is helpful to reference the SIP RFC

Once phones complete the registration process for the invite, there is an exchange of information agreeing on the media properties. The protocol is SIP/SDP. The properties are defined in RFC originally 2327 that is obsoleted by 4566 that is currently the proposed standard. The introduction for SDP states “SDP is purely a format for session description, it does not incorporate a transport protocol” This means this information is not seen by the firewall passing the traffic. If transformation is enabled the IP addresses should be changed as needed.

In the RFC 4566 under the examples page for usage states: The SIP protocol is an application layer control protocol for creating and modifying, and terminating sessions such as internet multimedia conferences, Internet telephone calls, and multimedia presentation. The SIP messages used to create sessions carry session descriptions that allow participants to agree on a set of compatible media types. These session descriptions are commonly formatted using SDP. When the used with SIP, the offer/answer model provides a limited framework for negotiation using SDP

For a unicast session as used in VOIP the information also needed is the remote address and port. In a protected network natting must be performed. A remote endpoint must communicate to the public (bound) address, and some device must change the address at this level from the public to the private address.