Milestone1:
Download the tool and create two user agents and a proxy server.
Generate a basic call setup and teardown. Submit the hard copy
of the configuration, and call flows.
Project Descriptions:
The following are six projects with varying levels of complexity that provide addition
functionality into a Session Initiation Protocol (SIP) simulator. The simulator is a tool
that should help explain how the SIP protocol functions, and further explain the
construction of SIP networks. The purpose of these projects is to add functionality and
develop a deeper understanding of the SIP protocol.
1. SIP Transfer
The goal of this project is to implement the Blind Transfer feature for a SIP User Agent.
Blind Transfer is a feature that is often used by PBX(s) in call center environments.
When a person calls a support line at a department store often the first person who
answers that phone cannot actually answer any questions and has to transfer that caller to
another person or department. In that scenario the original operator that answered the call
will initiate a transfer that call to the appropriate person or department without actually
knowing the state of that person or department. This scenario is often called a blind
transfer.
SIP has defined a couple of mechanisms to establish a blind transfer. For sake of
explanation let us consider three parties: Alice, Bob, and Carroll. Alice first calls Bob;
however, Bob cannot help Alice on the phone but knows that Carroll can provide the
appropriate answer to Alice’s question. Bob knows that if Carroll does not immediately
answer the phone her voice mail will answer and record a message. So Bob decides to
initiate a blind transfer of Alice to Carroll’s phone.
In this scenario Alice will first establish a SIP dialog with Bob (this procedure is
explained in detail in RFC 3261). Next, Bob will initiate a REFER transaction towards
Alice instructing Alice to contact Carroll (the REFER mechanism is defined in RFC
3515).
In order to implement this new feature there are several modifications that will be
necessary within the simulator tool. The necessary steps are listed:
 Create a GUI control (Transfer) from the sub-tree item that represents an active
dialog
 Create a entry point within UserAgentDevice that the GUI control can call to initiate
a call transfer
 Create an entry point within UACore to initiate the REFER transaction
 Create the proper business logic within DialogCtx to handle the transfer/REFER state
machine as both a User Agent Client (UAC) and User Agent Server (UAS)
Hint: There are some obvious steps that are not called out specifically such as: NOTIFY
sequence, and release (BYE transaction) of the original dialog.
2. Proxy Recursion
SIP has defined a mechanism called the Redirect that allows both Proxies and User
Agents to redirect a dialog request to an alternate location. This feature is used often
under several use cases: reduce load on a registration/location server, implement call
forwarding, etc. Some Proxy Servers and all User Agents contain a feature called 3XX
recursion. This allows a SIP device to terminate the failed transaction that resulted in a
redirect and initiate a new transaction with the new target provided in the 3XX redirect
response message. The goal of this project will be to add 3XX recursion to the Proxy
element within simulator tool.
3XX class responses, redirection, and recursion are handled quite completely within RFC
3261 (main SIP specification).
In order to implement this feature the following steps will be necessary:
 A GUI control for this feature is already present with the Proxy Edit Control;
however, it is just a stub.
 Introduce new business logic within Proxy Core in the Response Processing section
to handle the 3XX class response.
o Produce the ACK to properly close the initial transaction
o Initiate new INVITE on behalf of requesting entity towards the target of the
3XX Contact header
o Put some arbitrary upper bounds on the number of recursions (we don’t want
infinite loops between any set of elements).
Hint: A lot of this code exists already within the UA classes.
3. CANCEL Transaction
SIP has defined a method called CANCEL that allows a User Agent (UA) to cancel an
existing transaction. This feature enables a standard telephony use case that everyone
uses every day. When a person does not answer there phone it usually rings for an
indefinite period of time (assuming no answering machine, or SIP transaction timer).
Typically people will not call someone and let the phone ring for an indefinite period of
time, they will simply hang up after a couple of rings.
In SIP this scenario is explained by a typical INVITE/100/18X series. If the UAS does
not product a final response within a certain period of time (but keeps the transaction
alive through periodic messaging, timers, etc) the caller can hang up initiating a
CANCEL request. The CANCEL request will cause the UAS to cancel the matching
pending transaction.
This scenario has not yet been implemented within the simulator tool. RFC 3261
thoroughly explores the CANCEL transaction and its affects on a pending transaction.
The simulator tool will have to be modified in several areas. The implementer will need
to take advantage of the GUI Answer state defined within the User Agent Device. This is
a GUI control variable that allows an operator to decide whether a call flow can be
generated automatically, or human interaction is necessary. A new dialog box will need
to be developed that has two components: Callee Answer, and a Caller Release control.
This dialog will only be activated if the GUI Answer state is true. Then the dialog will
start a timer and display itself. At any time the user should be able to either click on
callee answer or caller release causing the transaction to be completed successfully or to
be canceled. The following steps will need to be followed:
 Create proper dialog control for GUI Answer
 Modify the User Agent classes to launch the GUI Answer dialog box if GUI Answer
is true once its has received an INVITE and processed the 100 response.
 If GUI Answer – Caller Release is invoked call the CANCEL method for the
transaction
 UACore and DialogCTX are going to need modification to process the CANCEL
request properly
4. Register Support
The REGISTER method allows endpoints to dynamically register their current location.
Routes within Proxy and Redirect Servers can be registered in two ways: statically via a
user interface, or dynamically through endpoint registration events. User Agents have the
ability to register their current location (IP or URL) for either an explicit period of time
(Expires header), or in perpetuity (*). The REGISTER method provides endpoints with
the ability to manipulate these bindings. RFC 3261 throughly explains the use of the
REGISTER method within section 10.
The simulator needs to have two functions added to the User Agent element: a manual
registration and deletion control. These controls will cause the indicated User Agent to
initiate a REGISTER sequence. The GUI control code has already been inserted but has
been stubbed out. The following steps will need to be added to support the REGISTER
method within the User Agent code.
 Modify the User Agent Device class for a registration method that creates the proper
transaction based on the expires time
 Edit UACore and DialogCtx to handle the REGISTER transaction
 Ensure that Proxy core edits the route table appropriately based on a REGISTER
transaction.
5. Session Timers
Session-Timers is a draft item within the SIP working group. Session-Times allows a
User Agent to detect the failure of a remote user agent and expire an existing dialog. RFC
3261 does not provide any sort of dialog keep-alive mechanism. Once a dialog has been
established it could exist for an indefinite period of time without any requiring any
subsequent transactions. For VoIP it is often useful for telephones and gateways to know
if a remote system has failed (media will not be deliver properly but since RTP is
typically an asynchronous mechanism it provides no feedback). Session-Timers was
developed so that at least one participant within a dialog could detect remote failure and
terminate a dialog properly. It is currently defined by draft-ietf-sip-session-timer-15.txt.
The simulator does not provide session timer support. In this project the functionality
specified within the Session-Timers draft will be added to the User Agent code. The
following steps should be followed:
 Create a Checkbox within the User Agent edit control for Session-Timers
 Create a field within the UAConfig to support serialization of this features state
 Modify User Agent Device, UACore, and DlgCtx to indicate support of SessionTimers as indicated in RFC 3261 (supported features)
 Modify DlgCtx with a timer to support the asynchronous support of the reINVITE
sequence
5. SIP Parser
Currently, the simulator tool only provides virtual network space; it does not interact with
real networks through any network interfaces. By only working in the virtual network
space the tool has never had to perform actual ASCII text -> parsing -> SIPMsg Class
operations. The parser is the first component that must be added in order to give the tool a
network interface. The goal of this project is to build a fully compliant SIP parser that can
build SIPMsg structures from ASCII text input.
There are going to be many possible approaches to building a parser that produces the
SIPMsg object within a C# program. Because the number of implementation options is
quite large, only one method will be described and it will be up to the implementer to
decide on the appropriate path. This project should use a generated parser that can take
ASCII input and produce SIPMsg objects from the properly parsed text. Section 25 of
RFC 3261 describes the ABNF format for SIP messages extremely well.
A successful parser will be able to be executed from within a C# program, read an ASCII
file, and produce a C# SIPMsg structure upon successful parsing of the file. If the file
does not parse the program should indicate where in the file the ABNF is violated and
why. There are many sources of messages to provide both positive and negative testing;
here are three: RFC 3665 Basic SIP Call Flows, draft-ietf-sipping-torture-tests-04, and
any text output from the simulator tool.
In order to implement this module the following steps will be necessary:
 Create a Scanner and Parser file that conforms to the ABNF defined in Section 25
from RFC 3261. There are several different parser generator programs freely
available for use with Visual Studio.
 Create a SIPMsg structure that can be mapped appropriately to C# through exporting
 Compile the Scanner/Parser as a C library for linking
 Create a C# program that exports the parsing function from the SIP Parser

Read ASCII files and provide the parsing result of the file: Success, or Failure:
Why/Where
Note: The simulator tool is still being worked on and in some cases might present
incorrectly formatted SIP messages. So care should be given to the types of messages
copied from the simulator.