VoIP: SIP phones cannot make and, or receive calls

03/26/2020 254 People found this article helpful 486,230 Views

Description

Resolution

Overview:

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

Registration is another common operation in SIP. Registration is one way that the biloxi.com server can learn the current location of Bob. Upon initialization, and at periodic intervals, Bob's SIP phone sends REGISTER messages to a server in the biloxi.com domain known as a SIP registrar. The REGISTER messages associate Bob's SIP or SIPS URI(sip:bob@biloxi.com) with the machine into which he is currently logged (conveyed as a SIP or SIPS URI in the Contact header field). The registrar writes this association, also called a binding, to a database, called the location service, where it can be used by the proxy in the biloxi.com domain. Often, a registrar server for a domain is co-located with the proxy for that domain. It is an important concept that the distinction between types of SIP servers is logical, not physical.

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.

Not Finding Your Answers?

ASK THE COMMUNITY

Was This Article Helpful?

YES NO

VoIP: SIP phones cannot make and, or receive calls

Description

Resolution

Related Articles

Categories

Not Finding Your Answers?

Was This Article Helpful?

Article Helpful Form

Article Not Helpful Form

Follow Us

Subscribe to newsletter

Stay In Touch