Presentation is loading. Please wait.

Presentation is loading. Please wait.

Richard Rodger1/20 SIP Sanity A rapid-prototyping and validation environment for SIP* applications *Session Initiation Protocol; RFC 3261 Richard Rodger.

Similar presentations


Presentation on theme: "Richard Rodger1/20 SIP Sanity A rapid-prototyping and validation environment for SIP* applications *Session Initiation Protocol; RFC 3261 Richard Rodger."— Presentation transcript:

1 Richard Rodger1/20 SIP Sanity A rapid-prototyping and validation environment for SIP* applications *Session Initiation Protocol; RFC 3261 Richard Rodger

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

3 Richard Rodger3/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 --| | | |

4 Richard Rodger4/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

5 Richard Rodger5/20 Class Relationships TCP/UDP Server SIP Server 1 1 SIP Manager SIP HandlerSIP Agent * 1 Application… creates SIP Message SIP Request SIP Response

6 Richard Rodger6/20 Start-up Collaboration :Applicationsh: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

7 Richard Rodger7/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

8 Richard Rodger8/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

9 Richard Rodger9/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

10 Richard Rodger10/20 Instant Messaging Client Start-up –REGISTER identity –SUBSCRIBE to buddies presence Send a Message –Send MESSAGE Receive a Message –Handle MESSAGE

11 Richard Rodger11/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

12 Richard Rodger12/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 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.

13 Richard Rodger13/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)

14 Richard Rodger14/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 )

15 Richard Rodger15/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

16 Richard Rodger16/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

17 Richard Rodger17/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

18 Richard Rodger18/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

19 Richard Rodger19/20 An Example Test Scenario: test a SIP message service that “echos” back whatever we say to it StepMessage CriteriaDepends 1OUT:Request MESSAGE “foo”None 2IN:Response MESSAGE 2001 3IN:Request MESSAGE “foo”2 4OUT:Response MESSAGE 2003

20 Richard Rodger20/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

21 Richard Rodger21/20 SIP Sanity A rapid-prototyping and validation environment for SIP applications Richard Rodger


Download ppt "Richard Rodger1/20 SIP Sanity A rapid-prototyping and validation environment for SIP* applications *Session Initiation Protocol; RFC 3261 Richard Rodger."

Similar presentations


Ads by Google