Home / IT Certifications / CCNP Collaboration / CIPTV1 300-070 / SIP IOS Configuration And Packet Analysis

SIP IOS Configuration And Packet Analysis

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-2016-03-02 06_34_41

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.

sip-2016-03-01 04_47_16

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).

sip-2016-03-01 04_48_47

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.

sip-2016-03-02 04_01_09

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

sip-2016-03-02 04_23_49

  • Information about the connection:
    • Network type: IN
    • Address type: IPv4
    • address: 10.14.14.1

sip-2016-03-02 04_25_09

  • 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

sip-2016-03-02 04_26_58

sip-2016-03-02 04_28_19

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.

sip-2016-03-02 04_34_56

If one of the phones hooks on before the call is established, a SIP Cancel packet is sent

sip-2016--2016-03-06 17_12_41

 show sip-ua connections

show sip-ua connections tcp brief

sip-2016-03-02 04_47_09

The counters are null. It is maybe a SIP UDP call.

show sip-ua connections udp brief

sip-2016-03-02 04_47_15

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

show-sip-ua-connections--2016-06-12 10_50_38

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:

sip--2016-03-09 06_18_22

Show sip-ua status

I did a “show sip-ua status” on the SIP UAC of the call:

sip--2016-03-09 06_20_27

Secure RTP

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.

sip-2016--2016-03-06 17_22_55

sip-2016--2016-03-06 17_23_26

A call from x5002 to x4002 succeeds. And voice media streams are exchanged in RTP traffic.

sip-2016--2016-03-06 17_20_13

case #2: Mongi Shop router implements RTP; PSTN router implements SRTP

sip-2016--2016-03-06 17_26_09

sip-2016--2016-03-06 17_26_16

We make a call from x5002 on Mongi Shop to x4002 on the PSTN. The call fails.

sip-2016--2016-03-06 17_27_56

On the UAC we have RTP. On the UAS we have SRTP configured. And the call fails.

sip-2016--2016-03-06 17_38_57

In the Cisco CVOICE Foundation Learning Guide, on page 227 it says:

sip-2016--2016-03-06 17_32_391

Let’s see which IOS versions we are running on Mongi Shop router and PSTN router:

sip-2016--2016-03-06 17_35_04

sip-2016--2016-03-06 17_34_57

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

sip-2016--2016-03-06 17_41_14

sip-2016--2016-03-06 17_41_09

We get the same result as before. The media session fails.

sip-2016--2016-03-06 17_41_41

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

sip--2016-06-12 12_16_12

configuring SIPS at the dial peer level

sip--2016-06-12 12_17_27

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

sip--2016-06-12 11_04_11

The keyword system refers to what is configured under Voice Service Voip.

sip--2016-06-12 11_09_15

Nothing special is configured under SIP, in the Voice service voip section. So default parameters apply globally.

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.

sip--2016-06-12 11_39_15

Although the transport protocol set at the dial peer level is TCP TLS, the “show dial-peer voice” command does not reflect that.

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.

sip--2016-03-07 20_10_142

sip--2016-03-07 20_10_141

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:

Method 1/

We change the transport protocol of SIP to TCP, under the sip section of the voice service voip menu:

sip--2016-03-07 20_00_55

The SIP INVITE/SDP message is now transported in TCP.

Method 2/

We change the transport protocol under the matching outbound dial peer (and we remove the TCP definition from the Voice service voip)

sip--2016-03-07 20_02_15

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:

sip--2016-03-07 20_03_00
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:

sip--2016-03-07 20_03_52

“no session transport tcp” at the dial-peer defaults to a transport protocol of UDP

and configure the inbound call leg on the UAS to use TCP. This is done at the sip-ua level:

sip--2016-03-07 20_04_23

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:

sip--2016-03-07 20_05_14

Now let’s make the call again:

sip--2016-03-07 19_45_56

the call fails this time, and an ICMP message “Destination Unreachable, Port Unreachable” is returned by the UAS to the UAC.

sip--2016-03-07 19_52_15

Binding a source interface to SIP packets

I’m going to use the loopback0 interface in this experiment. The loopback interface has IP address 5.5.5.5.

case #1: binding lo0 as a source interface of SIP control traffic

sip--2016-03-09 06_09_51

In Wireshark:

sip--2016-03-07 19_15_16

we see that control is intiated by the UAC from IP address 5.5.5.5 (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

sip--2016-03-09 06_12_34

This is confirmed by the figure:

sip--2016-03-07 19_18_10

case #3: binding lo0 as a source interface of all SIP traffic

We can also bind the interface to both control and media traffic:

sip--2016-03-09 06_14_02

sip--2016-03-07 19_19_35

Changing the default SIP timers

Changing SIP default timers is easy. Let’s verify their default values and change the Notify timer value.

sip--2016-03-09 06_15_18

sip--2016-03-09 06_15_51

sip--2016-03-09 06_16_26

SIP Debug commands

I make the call from x5002 to x4002 and launch debug commands for SIP.

debug ccsip events

sip--2016-03-12 10_59_00

debug ccsip error

sip--2016-03-12 11_00_54

debug ccsip messages

This command gives a similar output as Wireshark. You see all the exchanged SIP messages and their contents:

sip--2016-03-12 11_02_01

sip--2016-03-12 11_02_26

sip--2016-03-12 11_03_05

sip--2016-03-12 11_02_55

sip--2016-03-12 11_03_05

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:

sip--2016-03-12 11_05_13

sip--2016-03-12 11_05_26

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 5.5.5.5 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 (5.5.5.5) to be the source interface for SIP media traffic.

sip--2016-03-12 11_05_37

debug ccsip transport

With this command we can verify the transport protocol,  the port number and the remote UAS in a SIP call.

sip--2016-06-12 11_12_54

debug ccsip error

debug-ccsip-error--2016-06-12 10_18_30

Leave a Reply

Your email address will not be published. Required fields are marked *

*

Adsense black background: