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.
The normal flow is the phone sends an invite to the server:
INVITE sip:302@172.16.150.199 SIP/2.0
Via: SIP/2.0/UDP 172.16.150.212:51822;branch=z9hG4bK-d87543-cc17cf716a1e4872-1--d87543-;rport
Max-Forwards: 70
Contact: <sip:301@172.16.150.212:51822>
To: "302"<sip:302@172.16.150.199>
From: "W2K laptop"<sip:301@172.16.150.199>;tag=3d02b714
Call-ID: e021da497323e82eZjAyYzBmNzc2NGQwNTU5NDM3OTU1MWRiN2U0NmRhMzQ.
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
Content-Type: application/sdp
User-Agent: X-Lite release 1002tx stamp 29712
The phone sends a request to the server requesting to speak to an extension. The calling phone does not know the actual address of the called phone so it uses the proxy address.
The server responds with:
SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP 172.16.150.212:51822;
From: "W2K laptop"<sip:301@172.16.150.199>;tag=3d02b714
To: "302"<sip:302@172.16.150.199>;tag=as15db0375
Call-ID:
CSeq: 1 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Proxy-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="5911c5d4"
This is the challenge process where the phone then responds with the correct information Notice in the challenge the algorithm is MD5
ACK sip:302@172.16.150.199 SIP/2.0
Via: SIP/2.0/UDP 172.16.150.212:51822;
To: "302"<sip:302@172.16.150.199>;tag=as15db0375
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
If the server does not know where to reach the endpoint because of registration timeouts the call will not complete. The word binding is highlighted because this is sometimes seen in a packet in the following manner:
Num | Source IP | Destination IP | Info |
2 | 67.192.61.42 | 192.168.10.222 | Status: 401 Unauthorized (0 bindings) |
3 | 192.168.10.222 | 67.192.61.42 | Request: REGISTER sip:pop2.FQDN:5060 |
4 | 67.192.61.42 | 192.168.10.222 | Status: 100 Trying (1 bindings) |
5 | 67.192.61.42 | 192.168.10.222 | Status: 100 Trying (1 bindings) |
6 | 67.192.61.42 | 192.168.10.222 | Request: OPTIONS sip:FQDN.804@192.168.10.222 |
7 | 67.192.61.42 | 192.168.10.222 | Status: 200 OK (1 bindings) |
8 | 192.168.10.222 | 67.192.61.42 | Status: 200 OK |
9 | 67.192.61.42 | 192.168.10.222 | Request: NOTIFY sip:FQDN.804@192.168.10.222 |
10 | 192.168.10.222 | 67.192.61.42 | Status: 200 OK |
11 | 192.168.10.222 | 67.192.61.42 | Request: REGISTER sip:pop2.FQDN:5060 |
12 | 67.192.61.42 | 192.168.10.222 | Status: 100 Trying (1 bindings) |
13 | 67.192.61.42 | 192.168.10.222 | Status: 401 Unauthorized (0 bindings) |
14 | 192.168.10.222 | 67.192.61.42 | Request: REGISTER sip:pop2.FQDN:5060 |
15 | 67.192.61.42 | 192.168.10.222 | Status: 100 Trying (1 bindings) |
16 | 67.192.61.42 | 192.168.10.222 | Request: OPTIONS sip:FQDN.854@192.168.10.222 |
17 | 67.192.61.42 | 192.168.10.222 | Status: 200 OK (1 bindings) |
18 | 192.168.10.222 | 67.192.61.42 | Status: 200 OK |
Remember Binding is the process of registering with the different registrars in the domain. This is used as a locator service. If the phone is not in locator database, the calls will not reach the phone. The packet capture details are not shown because of privacy. The domains listed in the capture have been replaced with FQDN.
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
This info needs to include the actual contact info for purpose of SIP includes:
1. media type
2. transport protocol, in SIP case RTP
3. Format of media
4. address
5. ports
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.
The following example is from a configuration where the endpoints are located through a VPN connection, none of the traffic logically should have no public addresses noted.
TRANSPORT LAYER INFO
10.0.1.10 10.0.3.206 SIP/SDP Request: INVITE sip:6713@10.0.3.206:5061;transport=udp, with session description INVITE APPLICATION LAYER INFO SDP
sip:6713@10.0.3.206:5061;transport=udp SIP/2.0
Via: SIP/2.0/UDP 72.54.167.82:5060;branch=z9hG4bK458e2d3e;rport
From: "USER" <sip:6700@72.54.167.82>;tag=as11557eee
To: <sip:6713@10.0.3.206:5061;transport=udp>
Contact: <sip:6700@72.54.167.82>
ATTRIBUTES SECTION FOUND IN THE MESSAGE BODY
v=0
o=root 2664 2664 IN IP4 72.54.167.82
s=session
c=IN IP4 72.54.167.82
b=CT:384
t=0 0
m=audio 10150 RTP/AVP 0 8 101
The transport layer has all private addresses. The VIA address is a public address. The contact address is a public address. The contact info in the attributes also contains the public address. After correcting the configuration so the correct private address shows up, the issue was resolved.