TSM 350G – IP Telephony Lab #3
Spring Semester 2009
Objectives
1 - Place a peer – to – peer VoIP call between two endpoints (or two user-agents in SIP parlance .
). This is the simplest of all VoIP calls. In this lab, you will get a chance to watch the signaling (the messages being sent from end-to-end that cause the call to be setup, and then torn down), and you will get to speak the famous
Alexander Graham Bell “Come quick
Watson” lines.
2 – Place a call from a VoIP phone to the PSTN.
OK, you can call you mom, or your brother, etc. If you are calling international, please keep the call very short. Otherwise, try calling a friend’s cell phone or something like that.
Figure 1
– example of a peer-to-peer IP telephone call. The telnet and client/server sessions are the mechanism to collect the signaling traces.
Configure an endpoint: SIP user-agents (such as ip telephones, integrated access devices, or soft-phones) are generally not configured to send signaling messages directly to another endpoint; they are typically configured to send signaling data (registration information and/or call setup messages) to another entity most often called a SIP Proxy . For this lab, the user-agents will need to be configured (fooled) into thinking that the called end-point is the proxy (or outbound proxy ) to send all calls to. You will have to configure the endpoint – in one of several ways, depending on the endpoint – to do so, and as such this lab will also give you flavor for how such configurations are done.
Grab the signaling messages from one of the endpoints, and draw a ladder diagram. Per the discussion above, signaling between endpoints typically runs through one (if not many) proxy servers. Proxy servers are often the “natural” place to look at signaling using tools running on the proxy server (protocol analyzers), or by looking at log files. Sometimes however, access to the proxy server will not be available, or there may not be a proxy server (as in this lab). In these

cases, the signaling data can often be obtained directly from the endpoint. There are typically four ways to obtain the signaling information from an endpoint:
• log into the endpoint (e.g., telnet or ssh), and watch the signaling data in real time
• read a log file generated by the user agent acting as a client to some form of logging server, such as syslog on a unix platform.
• open a display window provided by the user-agent (in this case, the UA is most often softphone)
• use a hub between the network and the endpoint (a hub, unlike a switch, will broadcast all layer
2 frames to all endpoints plugged into the hub), or use an IP switch to mirror the traffic to/from the port connected to the endpoint to the observation port. (Note that port mirroring is usually a function of switches that can be configured or managed. It is almost never a function of $20
SoHo switches. Note also that it is very difficult to find true hubs for sale; in the past these were much cheaper than switches, and were commonly available. With the availability of IP switches on a silicon chip, true hubs have become difficult to find in stores, and are often more expensive.
Hubs however are invaluable in debugging IP Telephony signaling; the best trick is to find a hub on ebay and hang on to it!).
Doing the Lab:
Tips before getting started a) We will be using the VoIP lab in Dana 238 b) Lab groups will be made up of two people – each group will use a single VoIP endpoint. c) Each group should bring a laptop, which can then connect to the private (non-routable) lab network. d) We will try to make sure that all phones are returned to some form of default settings, so that you will have to touch the device configuration file to get things to work. The lab
TAs will help with this!
During the lab, calls will be made directly between two end-points. As described before, you have to configure your phones in a way that they think they are sending SIP messages to a proxy.
However, they will be sending these messages directly to the other end.
Using your choice of packet sniffing techniques, build ladder diagrams for the following calls (or processes): Extension to Extension Call (make a call and have it answered).
NOTE: This lab was written a few years ago. In addition to the IP Phones listed below, you may also want to consider using a VoIP client on an Android phone, such as http://sipdroid.org/ .
Getting the debugs this way may be a little bit more difficult, you will either need to get them off the server using ngrep, or use a WiFi dongle that enables debugging off of an 802.11 network connection. (I may have one, will try to come up with it).
CISCO PHONEs: To change the sip proxy address on the cisco phone, press the settings key, scroll to the bottom of the menu, and press the unlock key to allow you to change the phone settings from the front of the phone. The phone unlock password is 1234 . Then scroll up to SIP Configuration => Line 1 Settings => Proxy Address, and change the proxy address so that it points to the desired address. You can also edit the Cisco configuration by editing the xml config file on the server. I would suggest that you do both. (see the section under Polycom to see the xml file editing).
CISCO ATAs: The ATA (like many IP phones and Internet Access Devices) is configured using a web server running on the ATA. Point a web browser at http://ip_address_of_ata/dev, and change the GkOrProxy address to be the desired address to send calls to.

Cisco ATA configuration
Polycom Phones: Polycom phones can be configured either by using the web browser on each phone, or by editing the XML in the /tftpboot directory. You can You can hand-edit the
Polycom configs, but I would recommend the use of an xml editor. I would suggest you try both.
Polycom Phone Web Browser

Use of an XML editor for editing Polycom configs
Making the call
It is the easy part. Using the phone’s keypad, type in the telephone number (or extension number) of the endpoint that you want to make calls to. In the language of SIP, this telephone number is the USER ID of the CALLED endpoint.
Collecting the Data
There are different ways to collect the data. The easiest way is to run ethereal on your laptop, and plug into the lab hubs. Another way is to collect the data directly off the phone (for example, see the Cisco 7960 below).
CISCO 7960s: Now, telnet to the phone. Once you have logged into the phone, remember to turn on sip debugging using the debug sip-messages command, and relay those messages to the console (the phone is running quasi IOS commands) using the tty mon 0 command.
Here’s an example log file: bash-2.00$ telnet 171.78.174.140
Trying 171.78.174.140...
Connected to 171.78.174.140.
Escape character is '^]'.
Password :****
Cisco Systems, Inc. Copyright 2000-2002

Cisco IP phone MAC: 0006:28f0:fb2b
Loadid: SW: P0S3-04-3-00 ARM: PAS3ARM1 Boot: PC03A300 DSP: PS03AS30
SIP Phone> debug sip-messages
Enabling bug logging on this terminal - use 'tty mon 0' to disable debugs: sip-messages
SIP Phone> sip_sm_cc_channel_send_buf_fcn: Sent SIP message: handle=<2>: message=
<INVITE sip:53200@171.78.205.31;user=phone SIP/2.0
Via: SIP/2.0/UDP 171.78.174.140:5060
SIP Phone> tty mon 0
Current States: echo is 1 mon is 0 timeout is 3600 seconds prompt is SIP Phone> level is 2 – Privileged
Things to Observe and Answer:
See if you can put a call on “hold.” What happens? Make a call but with the wrong CALLED number. What happens? Try configuring your FWD account, does that work?
OK, now change the configuration so that you can call through the Asterisk PBX, and call home. Go ahead, mom wants to hear from you.
Writing up the lab
• Be obscure clearly. – E.B. White
• Blessed is the man who, having nothing to say, abstains from giving us wordy evidence of the fact – George Elliot (Mary Ann Evans) 1819-1880.
• Plagiarism, let no ones work evade your vision. Plagiarize! Plagiarize! Plagiarize! –Tom Leher.
• Keep it short, you’ll get a better grade. – Elliot Eichen
1. A picture of our network.
2. Annotated ladder diagrams (with the actual sip dialog in the appendix. Use numbers and brackets around the sip dialog to reference which message points to which ladder diagram.)
Provide one ladder diagram with relevant logs for the first part of the lab:
A successful call directly to another endpoint.
An unanswered call from another endpoint.