We are going to analyse the packet exchange between two voice gateways, in a SIP setting.
On the originating gateway, I modified the dial-peer of the outbound call leg to make it a SIP dial peer.
SIP Packet Analysis
We make the call and we inspect the SIP packets with Wireshark.
The originating gateway sends a SIP INVITE message. In the Wireshark trace, we notice that the SDP message is sent within the INVITE message; this is SIP Early Offer.
Let’s examine one SIP request message: the SIP INVITE message:
- UDP is the transport protocol,
- The destination port is 5060. This is the default SIP port
- The message contains three major sections
- the Request-Line (or the method): tells us this is an INVITE message to extension x5002. To reach extension x5002, the host located at IP address 10.14.14.2 is responsible for routing the call to it. The destination port is 5060.
- the message header fields: contains information about the sender: the source number, the source IP address, the source port,…
- the message body: in SIP Early Offer, contains the Session Description Protocol Offer message. This is what the SIP UAC suggests using regarding the media: user information, time information, media information (including type and codecs).
The terminating gateway responds with 100 Trying. The TRYING message -and the rest of the messages- contain “From” and “To” sections, which describe the originator of the SIP request (the INVITE message) and the original recipient of that SIP request.
The terminating gateway sends a 180 Ringing message.
The originating gateway acknowledges the ringing message with PRACK.
The called party hooks the phone off. The attached gateway sends a 200 OK response that contains SDP Reply. These are the media characteristics that the gateway agreed upon.
The UAC acknowledges the 200 OK message, and RTP media streams begin.
Ending The SIP Session
To end the session, one party sends a BYE message. The other party replies with OK message.
Session Description Protocol
Let’s analyze the SDP protocol. In the body of the INVITE message, the SIP UAC suggests the following parameters:
- information about the Owner/Creator of the session:
- Owner Username: CiscoSystemsSIP-GW-UserAgent. This is automatically generated.
- session ID: 5081
- session Version: 6826
- Owner Network Type: IN
- Owner Address Type: IPv4
- Owner Address 10.14.14.1
- session Name: SIP Call
- Information about the connection:
- Network type: IN
- Address type: IPv4
- address: 10.14.14.1
- information about session start time and session stop time
- description of the media:
- media type
- media port: this will serve as a source and destination port.
- media protocol
- media format: order of codecs to be negotiated. Each codec preference is detailed in a Media Attribute sub-section
The OK reply demonstrates that the UAS agreed on the suggested media properties. The SDP Reply has a similar structure, with minor differences such as the user ID information, the session ID and the port number.
If one of the phones hooks on before the call is established, a SIP Cancel packet is sent
show sip-ua connections
show sip-ua connections tcp brief
The counters are null. It is maybe a SIP UDP call.
show sip-ua connections udp brief
I still don’t know why the Total active connections counter shows 1, even after the call is terminated.
show sip-ua connections udp detail
This command too still shows Established, even after the call is terminated. I even shut down the remote gateway but the “bug” persists.
Show sip-ua calls
As we made a call from Mongi Shop to PSTN, the active call is displayed on the PSTN router that is acting as a UAS:
Show sip-ua status
I did a “show sip-ua status” on the SIP UAC of the call:
We are going to experiment secure RTP (or SRTP). Here is the network setting:
x5002 — Mongi Shop router — PSTN router— x4002
The connection between Mongi Shop router and PSTN is an IP link.
case #1: Mongi Shop router implements SRTP; PSTN router does not.
A call from x5002 to x4002 succeeds. And voice media streams are exchanged in RTP traffic.
case #2: Mongi Shop router implements RTP; PSTN router implements SRTP
We make a call from x5002 on Mongi Shop to x4002 on the PSTN. The call fails.
On the UAC we have RTP. On the UAS we have SRTP configured. And the call fails.
In the Cisco CVOICE Foundation Learning Guide, on page 227 it says:
Let’s see which IOS versions we are running on Mongi Shop router and PSTN router:
The IOS version is inferior to 12.4(22)T. So the media session fails. That’s what we had in the lab.
case #3: SRTP is implemented on both Mongi Shop router and PSTN router
We get the same result as before. The media session fails.
Configuring SIP Secure (SIPS)
Configuring SIP Secure is done at one of two levels:
- at the Voice Service Voip level,
- at the dial peer level (outbound or inbound)
configuring SIPS at the voice service voip level
configuring SIPS at the dial peer level
Playing with SIPS and SRTP
I played with different combinations of SIPS and SRTP to experience the different outputs. Sometimes I configured SIP globally and sometimes on the outbound matched dial peer. Sometimes I configured RTP, sometimes SRTP and other times SRTP with fallback to RTP.
Here are the results:
UAC Signaling protocol, UAC Media protocol, UAS Signaling protocol, UAS Media protocol, Result
SIPS, RTP, SIP, RTP, the call succeeds on port 5061 (SIPS)
SIP, RTP, SIPS, RTP, the call succeeds on port 5060 (SIP)
SIPS, SRTP, SIPS, SRTP, call failure
SIPS, SRTP, SIPS, RTP, call failure
SIPS, SRTP, SIP, RTP, call failure
SIP, RTP, SIPS (dial peer), RTP, call succeeds
SIPS (dial peer), RTP, SIP, RTP, call failure
SIP, SRTP (w fallback), SIP, SRTP (w fallback), call success
SIP, SRTP, SIP, SRTP (w fallback), call success
SIP, SRTP (w fallback), SIP, SRTP, call failure
A couple of notes after the table:
- whenever I activated SIPS on the UAC, the call fails. I found out later that it is a TLS issue on the originating router, and not an issue with the call setup itself.
- Without SRTP fallback, any call that involves a call leg configured with SRTP has failed.
- When SRTP fallback is configured on any call leg, the call succeeds. The only exception is when the inbound matched dial peer at the UAS is configured with SRTP with no fallback.
Verifying the transport protocol for SIP dial peers
To check the transport protocol configured for a SIP dial-peer, do “show dial-peer voice” and look for session-transport
The keyword system refers to what is configured under Voice Service Voip.
By default, SIP runs on UDP. And we can further confirm that with debug ccsip transport command.
However, you must pay attention when SIPS is enabled at the dial peer level; SIPS sets the transport protocol to TLS over TCP, although this can not be seen by doing a mere “show dial-peer voice” command.
A better way to determine the transport protocol is, as I said earlier, with debug ccsip transport
Modifying the transport protocol of outbound SIP messages
We are going to play with combinations of transport protocols for SIP.
The SIP INVITE/SDP message is transported by UDP, which is the default behaviour.
If we want to change the transport protocol for outbound SIP messages, Cisco says there are two methods:
We change the transport protocol of SIP to TCP, under the sip section of the voice service voip menu:
The SIP INVITE/SDP message is now transported in TCP.
We change the transport protocol under the matching outbound dial peer (and we remove the TCP definition from the Voice service voip)
And yes it uses TCP as the transport protocol.
Modifying the transport protocol of inbound SIP messages
Although the SIP UAS is not configured with TCP as a transport protocol (in fact it uses UDP), it still accepts the SIP invitation from the SIP UAC and replies with SIP messages over TCP. So the UAS must have been already configured with TCP and UDP?
Let’s check that:
In lines 123 and 124, “ENABLED” means that the SIP UAS accepts inbound SIP packets transported over TCP or UDP.
Let’s configure the SIP UAC outbound dial peer to use UDP:
and configure the inbound call leg on the UAS to use TCP. This is done at the sip-ua level:
We make a call. It succeeds. And UDP is the underlying transport protocol.
This is not what I understood from the CVOICE FLG. The call succeeded, despite the UAC uses UDP and the inbound dial peer is configured with TCP.
–> that’s because the UAS is still configured to accept inbound SIP invitations on UDP (remember the “ENABLED” in the last figure).
To make the UAS accept SIP invitations only on the TCP protocol, we must explicitly disable UDP and TLS TCP at the sip-ua level:
Now let’s make the call again:
the call fails this time, and an ICMP message “Destination Unreachable, Port Unreachable” is returned by the UAS to the UAC.
Binding a source interface to SIP packets
I’m going to use the loopback0 interface in this experiment. The loopback interface has IP address 22.214.171.124.
case #1: binding lo0 as a source interface of SIP control traffic
we see that control is intiated by the UAC from IP address 126.96.36.199 (which is the loopback0 interface) to IP address 10.14.14.1. However, IP address of loopback 0 is not used in media traffic exchange.
case #2: binding lo0 as a source interface of SIP media traffic
This is confirmed by the figure:
case #3: binding lo0 as a source interface of all SIP traffic
We can also bind the interface to both control and media traffic:
Changing the default SIP timers
Changing SIP default timers is easy. Let’s verify their default values and change the Notify timer value.
SIP Debug commands
I make the call from x5002 to x4002 and launch debug commands for SIP.
debug ccsip events
debug ccsip error
debug ccsip messages
This command gives a similar output as Wireshark. You see all the exchanged SIP messages and their contents:
debug ccsip calls
This command is like doing “show sip-ua calls” every time a SIP call is made or torn down. I make a call then I hook on the phone, and here is the correspondent output:
The block of text that corresponds to the Control traffic starts with “The Call Setup Information is:”. Earlier, we changed the source interface for SIP control messages to be the loopback address. That’s why we see the IP address 188.8.131.52 as the source IP address for signaling.
State of The Call = STATE_ACTIVE means that the call is still active.
The RTP part begins with the sentence “Number of Media Streams”. Again, we’ve set the loopback interface (184.108.40.206) to be the source interface for SIP media traffic.
debug ccsip transport
With this command we can verify the transport protocol, the port number and the remote UAS in a SIP call.
debug ccsip error