SipAgent

Richard Rodger

1
/20

SIP Sanity

A rapid
-
prototyping and validation
environment for SIP* applications

*Session Initiation Protocol; RFC 3261

Richard Rodger


Richard Rodger

2
/20

SIP is HTTP for Phones

SIP Sanity

Client/Server

Proxy Server

RTP (Audio)

SIP

SIP is text
-
based protocol for
phones, analogous to HTTP for
the web.

Unlike HTTP, each agent can be
both a client and a server.

Unlike HTTP, there are many more
types of requests and responses.

Correct implementation of SIP
means sending and receiving the
right SIP messages in the correct
sequence.

Messages can go directly between
agents, or via proxy servers.


Richard Rodger

3
/20

Some SIP Call
-
Flows

How to Start a Phone Call



Alice Bob


| |


| INVITE |


|
-----------------------
>|


| 180 Ringing |


|<
-----------------------
|


| |


| 200 OK |


|<
-----------------------
|


| ACK |


|
-----------------------
>|


| Two
-
Way Audio RTP |


|<======================>|


| |


| BYE |


|<
-----------------------
|


| 200 OK |


|
-----------------------
>|


| |

Instant Messaging



Alice Bob


| |


| MESSAGE |


|
--------------------
>|


| |


| 200 OK |


|<
--------------------
|


| |


| |


| MESSAGE |


|<
--------------------
|


| |


| 200 OK |


|
--------------------
>|


| |

Presence


Alice Presence Server Bob


| | |


| |<
--

SUBSCRIBE
--
|


| | |


| |
--

200 OK
-----
>|


| | |


| |
--

NOTIFY
-----
>|


| | |


| |<
-----

200 OK
--
|


| | |


| | |


|
--

PUBLISH
--
>| |


| | |


|<
---

200 OK
--
| |


| | |


| |
--

NOTIFY
-----
>|


| | |


| |<
-----

200 OK
--
|


| | |

Richard Rodger

4
/20

So What Does SIP Sanity Do?

•
Rapid prototyping of SIP agents

–
Build an instant messaging client in 10 min

–
Build a presence server to test against

•
Acceptance testing of SIP agents

–
Who does what to whom and when

•
Specify an expected sequence of requests and
responses

Richard Rodger

5
/20

Class Relationships

TCP/UDP Server

SIP Server

1

1

SIP Manager

SIP Handler

SIP Agent

*

1

Application…

creates

SIP Message

SIP Request

SIP Response

Richard Rodger

6
/20

Start
-
up Collaboration

:Application

sh:SipHandler

1. new

sm:SipManager

2. new

3. add( sh )

ss:SipServer

3.1 set( sm )

4. new( sm )

5. start

:SipAgent

1.1 new

Richard Rodger

7
/20

Handle an Incoming Request

:SipServer

:SipManager

1. handle

:SipMapper

1.2 map( req ):
SipHandler

:SipHandler

1.3 handle( req )

req:SipRequest

:SipParser

1.1 parse:
SipMessage

1.1.1 new

1.3.2 send( res )

1.3.1.1 new

res:SipResponse

:SipAgent

1.3.1 respond( req ):
SipResponse

Richard Rodger

8
/20

Philosophy

•
SIP messages are “bits on the wire”

–
Handlers
can

build invalid messages

•
…because we need this for acceptance testing

•
Handlers must do everything

–
…but SipAgents can help with call state

•
Use a scripting language (Ruby) so that
Handlers are easy to write

•
Not interested in RTP media streams, just
SIP call flows


Richard Rodger

9
/20

Sample Applications

•
Instant Messaging Client

–
Supporting SIP messaging and SIP presence

•
SIP Presence Server

–
Store users presence information and notify
interested parties when it changes

•
SIP Acceptance Testing Framework

–
Execute a series of SIP message interactions

–
Verify that other clients/servers are
operationally correct

Richard Rodger

10
/20

Instant Messaging Client

•
Start
-
up

–
REGISTER identity

–
SUBSCRIBE to buddies presence

•
Send a Message

–
Send MESSAGE

•
Receive a Message

–
Handle MESSAGE

Richard Rodger

11
/20

IM Client Message Handling

•
To Send Messages

–
Use
SipManager.send

•
To Receive Messages

–
Use a
SipHandler

•
Accept MESSAGE Requests

–
Display the content and who it’s from

•
Accept MESSAGE Responses

–
If not 200, then let the user know

Richard Rodger

12
/20

IM Client Handler Code

class

IMHandler < MessageHandler


def

initialize( uri )


super( uri )


end



def

accept( sipmsg )


super( sipmsg ) || "NOTIFY" == sipmsg.verb


end



def

handleReq( sipreq )


if

"MESSAGE" == sipreq.verb


showMsg( sipreq.from, sipreq.content,


sipreq.header?("Content
-
Type") )


elsif

"NOTIFY" == sipreq.verb


updatePresence( sipreq )




end



$sipagent.send(sipreq.respond)


end



def

handleRes( sipres )


if

"200" != sipres.status


if

"MESSSAGE" == sipres.verb


showMsg( sipres.to, "ERROR:"+sipres.status )


end


elsif

"PUBLISH" == sipres.verb


$etag = sipres.header?("SIP
-
ETag")


end


end

end

The super class accepts
MESSAGEs from and to the given
URI

The sample IM client is presence
-
aware, so presence
-
handling code
is included.

The GUI update code is elided

A SipAgent ensures complete
headers when a message is sent.

Handlers have to manage their own
state.

Richard Rodger

13
/20

SIP Presence Server

•
As per RFCs 3265, 3903 (mostly!)

•
Accept SUBSCRIBEs from clients

•
Accept PUBLISHs from clients

•
Send out NOTIFYs to clients whenever we
get a SUBSCRIBE or NOTIFY

•
Maintain user state
–

ONLINE or OFFLINE

–
Users identified by URI (address of record)

Richard Rodger

14
/20

Presence Server Implementation


•
Unlike the IM Client, this is “just” a Handler

•
Here’s a simple setup:



•
This is all you need for the IM Clients

•
PresenceHandler can also operate on its
own if desired

sipman = SipMan.new

sipman.add( RegistrationHandler.new )

sipman.add( PresenceHandler.new("127.0.0.1",“5060") )

sipman.add( ProxyHandler.new )

Richard Rodger

15
/20

Inside The Presence Handler

Handle SUBSCRIBE
Request

Handle PUBLISH
Request

Handle NOTIFY
Response

•

add subscriber to subscribee watch list

•

send back a 200 OK

•

send a NOTIFY to subscriber

•

send NOTIFY to each subscriber watching

•

send back a 200 OK

•

record SIP
-
ETag value for PUBLISHs

Richard Rodger

16
/20

Acceptance Testing

•
Verification and Validation of SIP
Applications is difficult

•
Unlike HTTP, SIP call
-
flows consist of
multiple requests and responses

•
SIP Acceptance Tests validate the
behaviour of the application on the
network

Richard Rodger

17
/20

Test Definition

•
Define messages declaratively

•
Ruby syntax allows a DSL
-
like approach

•
Each message is dependent upon a
subset of previous messages.

•
All dependent messages must be
complete (fully sent or received, and valid)

•
Each message must satisfy testing criteria
with respect to headers and content

Richard Rodger

18
/20

The Test Handler

•
Will handle ALL messages, so must run
standalone

•
Incoming message

–
Validate and mark as done

–
Execute next message step if dependents
now satisfied, else keep waiting

•
Outgoing message

–
If dependents all done, send it, otherwise wait

Richard Rodger

19
/20

An Example Test

Scenario: test a SIP message service that “echos” back whatever we say to it

Step

Message Criteria

Depends

1

OUT:Request MESSAGE “foo”

None

2

IN:Response MESSAGE 200

1

3

IN:Request MESSAGE “foo”

2

4

OUT:Response MESSAGE 200

3

Richard Rodger

20
/20

Development Path

1.
Prototype Ruby UDP/TCP Servers

2.
Prototype simple registration and IM

3.
Design IM Client using Z specification

4.
Tracer bullet implementation of
SipManager and Handlers

5.
Finalise Z specification of system and
sample applications

6.
Refine and refactor codebase for beta
release

Richard Rodger

21
/20

SIP Sanity

A rapid
-
prototyping and validation
environment for SIP applications

Richard Rodger