VoIP: Example and explanation of a completed normal SIP call

03/26/2020 44 13278

DESCRIPTION:
VoIP: Example and explanation of a completed normal SIP call

RESOLUTION:

SIP The mechanism used for negotiation is documented in RFC 3261.

SIP is based on an HTTP-like request/response transaction model. Each transaction consists of a request that invokes a particular transaction consists of a request that invokes a particular method, or function, on the server and at least one response.

The RFC contains this example of the process.

Live Capture

Most SIP calls are not point to point, there is a proxy server involved. Please refer to the RFC for the roles. SIP normally involves at least one PBX/SERVER/PROXY. There are two examples included the first from the RFC, and one from a live capture. The example from the RFC shows all sides of the call, while a normal capture no matter the location where it is taken will not have a location included. The only time it is possible to see each leg in a packet capture is when the call is a point to point connection. This article is to illustrate a completed call from start to end. To troubleshoot an unsuccessful the successful process must be understood. The default port used for SIP is UDP 5060, if using TLS it is on UDP 5061. Some vendors will vary from this port, or use an additional port. If they vary from the default port triage may be not possible with this process.

1.   The RFC example does not show the authentication process
2.   The first packet is the phone starting the call with an INVITE.
3.   The proxy/PBX replies with the 407 response
4.   The phone responds with ACK (Status 200)
5.   The two previous steps from the capture are the authentication challenge and response process.
6.   The phone then sends another invite with the session description, SIP/SDP including media IP address, ports, codec, and features
7.   The status 100 is a message to let the caller know the proxy is trying to contacted the called party
8.   What is missing are the responses sent to the called party.
9.   The status 100 trying is initiated from the remote proxy
10. The status 180 is initiated from the called party
11. The server then responds with it’s own attributes
12. The ACK status 200, in the live capture after the RTP stream is in response to a BYE, request to end call.
13. Notice all action request are replied to with a status 200.

The outlined steps are for a normal point to point call. A different type of call is when there is a “Follow Me” feature. Additional articles will address the three common problem:

1. Phones do not register
2. Missing Audio
3. Call Quality