SIP response codes
SIP trace
Types of SIP packets
SIP headers
Registration
Digest authentication
SIP extensions

RTP streams in Wireshark

Before you continue with the protocols, please download and install wireshark - free and open source software tool. It is necessary for VoIP troubleshooting and understanding network protocols. The wireshark is able to record (sniff, capture) packets from network adapter, save them to file (.pcap, .pcapng), parse captured packets and display them in user-friendly way. It also includes tools to parse, display, listen VoIP calls, RTP media streams. To analyse a VoIP issue with Wireshark one should

• Select network adapter(s), start capture of VoIP packets. Reproduce the issue. Stop capture. The recorded packets could be exported/imported via .pcap/.pcapng files.
• Apply a display filter. Examples: "sip", "sip || rtp", "http", "tcp", "udp"
• Look into captured packets and see the sequence, timestamp and contents of packets
• Analyse captured VoIP call(s) (Menu - Telephony - VoIP calls)
  
• Analyse captured RTP streams (Menu - Telephony - RTP - RTP Streams)
  

The VoIP troubleshooting is complex; it requires deep understanding of protocols.

The Internet protocol (IP) is designed to send data packets across IP networks from source host to destination host. The source and destination hosts both have IP address. There are 2 most popular versions of the IP protocol: version 4 and version 6. In 2018 most widely used version is still version 4; in the IP v.4 the address includes 32 bits and is written as 4 numbers (bytes) from 0 to 255 separated by dot, example: 192.168.0.1. In IP v.6 the address includes 128 bits, written as 8 groups of 4 hexadecimal digits with the groups being separated by colons, example: 2018:0db8:0000:0042:0000:8a2e:0370:5678. Here is a task to check your new skills: If you are unable to do it, please contact us and we will clarify this chapter. As you can see in wireshark, IP protocol data in the packet (also called IP header) has many fields, most important are "Source", "Destination". The "Differentiated Services Field" (includes DSCP bits) is used to prioritise VoIP traffic in IP routers.

The UDP is designed to send data over IP protocol and UDP header contains fields "Source port" and "Destination port". The port is a 16-bit integer having values from 0 to 65535. Multiple applications running on source and destination host at the same time use different port numbers; the port number identifies application which is linked (bound) to the port. Standard port number for SIP protocol is 5060; for RTP protocol port numbers are assigned dynamically. The UDP protocol has no means to control delivery of packets from source to destination, so the packets could be lost in IP network. Small packet loss (below 2%) is normally handled by SIP and RTP.

In some cases VoIP calls go over Transmission Control Protocol (TCP). In other words same SIP packet data can be encapsulated into either TCP or UDP packets. The TCP protocol header contains source and destination port numbers as UDP, it also contains fields used to control guaranteed delivery of packets. TCP protocol provides guaranteed delivery of packets in same order from source to destination, it retransmits lost packets unlike UDP protocol. On the other hand TCP adds extra delay for setting up connection, increasing Post-dial delay (PDD). Besides the guaranteed delivery of data, use of TCP instead of UDP for VoIP means

• Better passing through IP routers (NAT, firewalls): TCP is used for HTTP and HTTPS web browsing and it works everywhere
• Better security: source IP address in TCP can not be spoofed
• SIPS: encryption of SIP data using TLS method (similar to HTTPS encryption)
• Stateful processing of IP packets, no possibility of lightweight stateless SIP proxy.

The TCP protocol introduces concepts of client, server and connection. Client initializes TCP connection to server using TCP SYN packet; the connection is ended with TCP FIN packet. Default server-side TCP port number for SIP is 5060; client-side TCP port number is selected randomly.

The SIP is most widely used protocol for VoIP calls. It defines specific format of messages (SIP packets) and their sequence to make calls over IP networks. The SIP messages are carried by means of UDP, TCP, or TLS/TCP (it is called SIPS). A typical sequence of SIP messages during a VoIP call (SIP call flow diagram) is displayed in beginning of the book, here we show it one more time:

• INVITE packet (request from endpoint A to endpoint B) means initiation of call: "A wants to make new call to B"
• 100 Trying packet (response from B to A to INVITE) means confirmation of INVITE packet delivery: "B received the INVITE". 100 means response code
• 180 Ringing packet (response from B to A to INVITE) means indication of ringing state: "Phone B started to make rings". At ths time caller (A) starts to hear ringback tone. 180 means response code
• 200 OK packet (response from B to A to INVITE) means indication of answer (connection, start of billing): "Phone B answered to the call". 200 means response code
• ACK packet (from B to A) means confirmation of 200 OK packet delivery: "A received the 200 OK"
• BYE packet (request from A to B) means termination of call: "Phone A ends the call"
• 200 OK packet (response from B to A to BYE) means confirmation of BYE packet delivery: "B received the BYE"

Other possible scenarios of VoIP calls:

• Call is ended by B after answer
  
  
  • Difference from previous flow is initiator of BYE packet
  Task: open this file in wireshark, see which party (A or B, caller or callee) ended the call with BYE.
• Call is ended by A before answer
  
  • Caller party (endpoint A) sends SIP packet "CANCEL" before connection - means "A ends the call before answer"
  • Called party (endpoint B) responds to CANCEL with "200 OK" - means "B confirms receiving of CANCEL"
  • Called party (endpoint B) responds to initial INVITE with "487 Request Terminated" - means "B confirms ending of call". 487 means response code
  • Caller party (endpoint A) sends ACK to 487 packet - means "A confirms receiving of 487"
• Call is rejected by B (ended before answer)
  
  • Called party (endpoint B) responds to initial INVITE with "486 Busy Here" - means "B rejects the call with status = busy". 486 means response code
  • Caller party (endpoint A) sends ACK to 486 packet - means "A confirms receiving of 486"
• Normal call flow (same as on first diagram) but with audio ringtone coming from B (can be ringback tone or music)
  
  • Called party (endpoint B) responds to INVITE with "183 Session Progress" which means initiation of audio channel between A and B
  • RTP media packets (audio signal) are sent between endpoints after "183", before "200 OK" (answer signal), it is called early media. Note that it is bidirectional audio stream, but it does not mean that SIP servers always pass early media from A to B. It depends on every particular softswitch. From our experience we see that most softswitches really pass early media from caller to called party in early media, before start of billing. It is safe for caller-side software because caller does not pay for early media RTP traffic.
  Tasks:

  • Does this file contain early media (RTP packets before 200 OK)?
  • Does this file contain early media?

Caller and called parties are also called SIP endpoints, A and B, user agents, UAC (User Agent Client) and UAS (User Agent Server). Full technical documentation is available in RFC3261 standard document published by IETF. Also, you can find many articles and tutorials published on our website.

SIP response codes

SIP trace

In next chapters we will describe the SIP trace in detail.

Types of SIP packets

SIP headers

A header in SIP packet has a simple format: [name]: [value]. SIP headers are separated by line breaks. Most widely used SIP headers are

• From header indicates identity of caller, usually contains Caller ID (ANI, CLI, A number). Also contains unique "tag" set by UAC
• To header identifies recipient of the call, usually contains Called ID (called number, B number). Also contains unique "tag" set by UAS
• Via header saves information about proxy servers - server IP address and port - to pass response from UAS back to UAC via same set of proxy servers
• Record-Route header is optionally inserted by proxy servers to route subsequent SIP requests for the same SIP call
• Call-ID header identifies SIP call along with "From" and "To" headers
• Contact header specifies IP address and port to be used by peer SIP endpoints for subsequent SIP requests for the same SIP call
• CSeq header contains a decimal number which increases by 1 with every subsequent SIP request within the same SIP call, with the exception of CANCEL and ACK requests which use the CSeq number of corresponding INVITE request
• Server header indicates model, software/firmware version of UAS
• User-Agent header indicates model, software/firmware version of UAC
• Content-Length header as you will read later, INVITE and "200 OK" packets usually contain encapsulated SDP protocol data with information about RTP audio streams. This header specifies size of encapsulated SDP (or other) data
• Content-Type header specifies type of encapsulated data. Equals to "application/sdp" in case of encapsulated SDP
• Allow header lists set of SIP requests supported by user agent which generated the SIP message
• Supported header specifies set of supported SIP extensions by user agent which generated the SIP message
• Require header specifies set of required SIP extensions by user agent which generated the SIP message
• Session-Expires header - part of RFC 4028 (Session Timers) SIP extension - specifies max. interval to refresh SIP call with keep-alive packet (the RFC3261 standard does not define way to abort hang calls)
• Expires header specifies lifetime of corresponding SIP request
• WWW-Authenticate, Authorization headers are used for digest authentication

There are many more headers; adding custom headers into requests and responses is a way to extend SIP protocol.

Registration

Registration in SIP means passing information about user agent to server, it is implemented with REGISTER. It means "Hello SIP server, here are my contact details for extension number 456: IP address 1.2.3.4, SIP port 5060". Without registration SIP phones must know IP addresses of every destination phone; with registration the IP addresses are stored by SIP server, also known as SIP registrar server. Her is example SIP trace for the registration process: As you can see in the SIP trace, first REGISTER request sent by UAC 192.168.10.4 to UAS 5.135.179.50 means resitration of extension 100 at SIP server startrinity.com on SIP port 6000. The UAC sends its IP address in Contact header: Contact: <sip:100@192.168.10.4:5090>. "Expires" SIP header equals to 3600 means that the registration entry should be valid for 3600 seconds - in 60 minutes the registrar server should clear the registration entry if not received new REGISTER requests for this extension. REGISTER request with "Expires: 0" means unregistration.

Digest authentication

As you can see in previous SIP trace (with REGISTER), first request is rejected with status "401 Unauthorized" and WWW-Authenticate header, it is called digest challenge. The WWW-Authenticate SIP header contains nonce and opaque values which are used by UAC along with user name and password to send second INVITE request. The second INVITE request contains Authorization header with digest response, it is used by UAS to verify user name and password. If user name and password are correct, UAS sends "200 OK" response, otherwise it sends "403 Unauthorized" response.

SIP extensions

The RTP transfers audio or video stream between user agents over UDP protocol. RTP media stream goes from source IP address and UDP port to destination IP address and UDP port. In most cases RTP streams in VoIP are bidirectional. RTP is defined by RFC3550 IETF standard document; its usage for VoIP is described in RFC3551. RTP packets (encapsulated in UDP) contain following important fields:

• SSRC (synchronization source identifier) - a randomly selected 32-bit identifier for source of RTP stream, usually also unique for many VoIP calls and does not change during call (SSRC may be changed only in rare cases, for example when call is put on hold). The SSRC is used to detect RTP collisions (when multiple RTP streams are sent to same UDP port)
• Sequence number - 16-bit integer number which is incrememented by 1 with every subsequent transmitted RTP packet. Is used in jitter buffer on receiver side to detect and compensate lost and delayed packets. Initial value for the sequence number is usually assigned randomly.
• Timestamp - 32-bit field, usually randonly initialized like sequence number and incremented with every transmitted RTP frame by number of transmitted samples. For example for audio RTP packets with sample rate 8kHz and containing 20ms audio in every RTP packets, RTP timestamp gets incremented by 8000 / 1000 * 20 = 160 samples. For a MPEG video RTP packet with sample rate 90000Hz and 30FPS it would be 90000/30 = 3000 samples per frame. For codecs with variable bit rate (VBR) it is more complex. Note: Timestamp and Sequence number values may jump, and VoIP software must be able to handle the jumps.
• Payload - encapsulated voice/video data, or DTMF digit. The media stream is splitted into small frames of 10..50 milliseconds and transmitted over RTP packets. The duration of the frame is called packet time, it is configurable in VoIP software. The audio/video data is encoded with a codec. Type of the codec is specified by payload type and SDP.
• Payload type - 7-bit integer (0-127), specifies format of encapsulated payload: encoded audio/video or DTMF digit. RTP streams are used to transfer DTMF digits (when caller presses a key on phone during call), it is defined by RFC2833. Range of payload types (0..127) is divided into static payload types (0..95) and dynamic payload types (96..127), for more information please refer to RFC3551. Most common static payload types / audio codecs are:
  • 0 / G.711 mU-law (also known as PCMU) and
  • 8 / G.711 A-law (also known as PCMA) - stateless audio codec with simplest implementation. There is one-to-one mapping between uncompressed 16-bit PCM samples and compressed 8-bit G.711 samples; the mapping is different for mu-law and a-law. A-law is used in EU; mu-law is used in US. The G.711 codec is used in TDM networks. Sample frequency is 8 kHz (8000 audio samples per second). Here word stateless means that encoding/decoding of an audio sample does not use information about previously encoded/decoded audio samples. Bandwidth of G.711 codec is 64kbit/s.
  • 18 / G.729 - stateful 8kbit/s audio codec, royalty-free since 2017 (patent has expired). G.729 has been extended with annexes G.729A and G.729B:
    • G.729A has a medium complexity, and is compatible with original G729. It provides a slightly lower voice quality
    • G.729B extends G.729 with silence suppression, and is not compatible with the previous versions. The G729B introduces CNG (comfort noise generator) packets with smaller size, in this way reducing bandwidth when there is no sound
    • G.729AB extends G729A with silence suppression, and is only compatible with G729B
    DTMF digits and fax transmission cannot be transported reliably with G729.
  • 3 / GSM - GSM codec, stateful. Is rarely used
  • 4 / G.723 - G.723 codec, stateful. Is rarely used
  Other codecs and DTMF digits are transmitted with dynamic payload types. The dynamic payload types are used in conjunction with SDP, where actual name of codec is specified. SDP - example #1
  
  INVITE sip:123456@5.6.7.8;user=phone SIP/2.0 SIP request line: method = "INVITE" (make call)
  Via: SIP/2.0/UDP 1.2.3.4:5061;rport;branch=z9hG4bK-3767867992-3776019369-1982645923-1415686538 various SIP headers
  From: <sip:srct_tel_num@1.2.3.4:5061;user=phone>;tag=910826072-3776019369-1982645923-1415686538
  To: <sip:123456@5.6.7.8;user=phone>
  Call-ID: 581a4a72a97b11e1a3c62c768aa96154@1.2.3.4
  CSeq: 1 INVITE
  Contact: <sip:srct_tel_num@1.2.3.4:5061;user=phone>
  Content-Type: application/sdp SIP header indicating type of encapsulated content: SDP = Session Description Protocol (what kind of data is carried inside the SIP INVITE packet?)
  Allow: ACK, BYE, CANCEL, INFO, INVITE, OPTIONS, REFER, REGISTER, UPDATE
  Max-Forwards: 70
  User-Agent: StarTrinity v.4.4.0-19a
  Content-Length: 714 size of encapsulated content
  here starts the encapsulated content, SDP offer from caller side (SIP UAC)
  v=0
  o=- 1338288302 1338288302 IN IP4 1.2.3.4
  s=-
  c=IN IP4 1.2.3.4 IP address where UAC waits for RTP packets from UAS. when UAC is behind NAT, and there is no SIP ALG, it is internal (LAN) IP address, and it should be ignored by UAS
  t=0 0
  m=audio 35018 RTP/AVP 18 103 0 8 4 3 96 102 list of codecs (payload types) supported by UAC. 0, 3, 4, 18 are static, others are dynamic
  a=rtpmap:18 G729/8000 rtpmap entry: what is payload type (PT) 18? it is mapped to codec G.729, sample frequency 8000 Hz
  a=fmtp:18 annexb=nofmtp entry: what are parameters of payload type 18? annexb=no means that it is G.729 or G.729A, not G.729B. CNG packets are not expected by UAC for PT=18
  a=rtpmap:103 G729/8000 PT=103 is declared similarly to previous PT=18,
  a=fmtp:103 annexb=yes with support of CNG packets (it is G729 annex B)
  a=rtpmap:0 PCMU/8000 PT=0 is G.711U, sample frequency is 8000Hz
  a=rtpmap:8 PCMA/8000 PT=8 is G.711A, sample frequency is 8000Hz
  a=rtpmap:4 G723/8000 PT=4 is G.723, sample frequency is 8000Hz
  a=fmtp:4 annexa=yes
  a=rtpmap:3 GSM/8000 PT=3 is GSM, sample frequency is 8000Hz
  a=rtpmap:96 speex/8000 PT=96 is Speex, sample frequency is 8000Hz
  a=fmtp:96 mode=3;vbr=off
  a=rtpmap:102 telephone-event/8000 PT=102 means DTMF digits. UAC expects to receive DTMF digits inside RTP stream from UAS with payload type 102
  a=fmtp:102 0-15
  a=sendrecv UAC offers bidirectional RTP stream in this SDP
• Marker bit - could be is set to 1 with every start of new RTP stream fragment (for example when RTP stream is interrupted by DTMF digit). The marker bit is used as a flag to re-initialize jitter buffer.

RTP streams in Wireshark

todo: what is delta and skew? What are normal values? What if skew is too high: desync of RTP clock. in TDM circuits there was a special wire for this 8khz synchronization. and in voip - no. and it is a potential issue, not covered by RTP and SIP.

See SDP example #1

The issue has been reported by Telin, cloud IP PBX service provider, reseller of 3CX: Troubleshooting steps:

• Clarify the situation with Telin. What happens in terms of SIP protocol
  • At the same time both Mitel phone and 3CX softphone send REGISTER to 3CX server to same extension. Mitel phone sends via UDP. 3CX softphone sends via tunnel.
  • The Mitel phone receives 200 OK response to the REGISTER, this response contains multiple "Contact" headers.
  • The Mitel phone displays an error related to registration, and calls do not work. When 3CX softphone is not registered, everything is fine.
  Response from Mitel:
  Mitel phone analyses contact header which is received from server in response to register. It does not accept the syntax.
  Incorrect:
  Contact: <sip:003@127.0.0.1:50195;transport=TCP;rinstance=1-xs7ou4dgsbv7tg5.ntvyho6kmku6kv-a;ob;inst="D7FCE2">;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-0000-0000-00008340d0fa>";expires=74
  
  Correct:
  Contact: <sip:003@127.0.0.1:50195;transport=TCP>;rinstance=1-xs7ou4dgsbv7tg5.ntvyho6kmku6kv-a;ob;inst="D7FCE2";reg-id=1;+sip.instance="<urn:uuid:00000000-0000-0000-0000-00008340d0fa>";expires=74
  
  The problem seems to be in incorrect contact header in the 200 OK for the softphones. Below is one of the sipphone contact headers in NotWorking trace. In this contact header the > sign is added in an incorrect place which takes some of the feature parameters like rinstance inside the sip: part. I have shown the incorrect and correct way (based on how Mitel phone processes the contact header).
• Clarify the situation ourselves by making the experiment one more time, sniffing working and non-working REGISTER cases.
  • Working case: one mitel phone registers and receives "200 OK" response to REGISTER with following contact header:
    
    Contact: "Mitel Phone"<sip:701@10.0.6.39:5060>;+sip.instance="<urn:uuid:00000000-0000-1000-8000-00085D5C0866>";expires=120
  • Not working case: one 3CX softphone is registered, at the same time one more (mitel) phone send REGISTER with contact header
    Contact: "Mitel Phone" <sip:701@10.0.6.39:5060>;+sip.instance="<urn:uuid:00000000-0000-1000-8000-00085D5C0866>";expires=0
    and receives "200 OK" response to REGISTER with following 3 contact headers:
    
    Contact: "Mitel Phone"<sip:701@10.0.6.39:5060>;+sip.instance="<urn:uuid:00000000-0000-1000-8000-00085D5C0866>";expires=120
    Contact: "Mitel Phone"<sip:701@127.0.0.1:5060;rinstance=1-hkg2btlqkdv6ydfaixt62uwrre1zz4sd;inst="b98a8bbf">;expires=62
    Contact: <sip:701@127.0.0.1:5488;rinstance=f27cf6aeccdab97f>;expires=55
    We see that the response is not correct. It muct contain only 2 contact headers, not 3, since only 2 phones are registered to one extension
• At this point we know that we have a multi-component system and an issue related to one or multiple components, or to combination of components. It is helpful to understand which component causes the issue. So we make a new experiement with a new system containing different components: 3CX PBX, Mitel phone and Polycom phone: we replace 3CX softphone by Polycom phone to see what happens. This is what we observe:
  • In this combination it works. All phones registered successfully
  • Contact headers in "200 OK" response to REGISTER:
    Contact: "Mitel Phone"<sip:701@10.0.6.39:5060>;+sip.instance="<urn:uuid:00000000-0000-1000-8000-00085D5C0866>";expires=120
    Contact: <sip:701@127.0.0.1:5488;rinstance=f27cf6aeccdab97f>;expires=72
    We see that the 3CX PBX server responded correctly with 2 contact headers
  One more experiment with Polycom phone and Mitel phone. Polycom sends contact header
  Contact: <sip:007@10.0.6.8>;methods="INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, MESSAGE, SUBSCRIBE, NOTIFY, PRACK, UPDATE, REFER"
  and receives
  Contact: <sip:007@10.0.6.8:5060>;methods="INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, MESSAGE, SUBSCRIBE, NOTIFY, PRACK, UPDATE, REFER";expires=120
  Contact: <sip:007@127.0.0.1:5488;rinstance=8d481b0693d20404>;expires=106
  - this is also correct, 2 contact headers in response, and it works in this combination too.
• Based on the experiments we make conclusion and suggest possible ways towards solution
  • 3CX PBX is wrong in sending 3 Contact headers. Further action: submit bug report to 3CX team including SIP trace
  • Mitel phone could have a configurable setting whether to verify Contact headers in response to REGISTER or not. Further actions: try to downgrade to old firmware version which does not verify contact headers in response, or request a new version with the configurable setting