Clojure SIP servlets library

[Richard Newman-8]

Hi folks,

Just a quick note to anyone who's interested in Clojure: I've released  
a supporting library and documentation for an approach I've been using  
to simplify SIP servlets development. You can grab it on GitHub:

   http://github.com/rnewman/clj-sip

It uses Clojure's multimethods and ad-hoc hierarchies to reduce the  
blow-up of dispatching on state and message types that arise in non-
trivial B2BUAs, without departing entirely from the SIP servlet model.  
This all compiles right down to a real servlet class in a .sar.

 From the example in the source tree:


(req-> [:init :invite]
   (log "Got an INVITE in state "
        (application-session-state app-session)
        ". Sending response.")
   (set-application-session-state! app-session :propagated)
   (.send (.createResponse req 200)))


The real power comes when you use and extend the hierarchies available  
in the library. For example, say you're proxying for a downstream  
gateway which doesn't understand requests from RFCs 3262, 3265, or  
3903. You can refer to the built-in categories (e.g., :rfc3262-
requests) to name your own collection of methods and define a handler  
for these without repeating yourself:


(def *my-hierarchy*
   (ref (deriving @*sip-hierarchy*
                  (:not-understood
                    :rfc3262-requests
                    :rfc3265-requests
                    :rfc3903-requests))))

...

(req-> [:state :not-understood]
   (.send (.createResponse req 405)))


This leverages Clojure's hierarchies, so we can ask if a message  
is :not-understood:


user=> (isa? @*my-hierarchy* :prack :not-understood)
true

or even ask into which categories it falls:

user=> (ancestors @*my-hierarchy* :invite)
#{:sip-message :dialog-creating-request :rfc3261-requests :sip-request}


Similarly, you can define response handlers that reflect the  
hierarchy: a 400 Bad Request is a :client-failure-response, an :error-
response, and so on all the way up to :sip-message.

You can also cluster together *states* in your application into  
arbitrary hierarchies, so you can simplify the handling of, say, in-
dialog INVITEs versus out-of-dialog INVITEs. No more switch  
statements! No more repetition!

This library has been tested against SailFin, and by default builds  
against SailFin's jars. It's early days, so questions and comments are  
welcome.

Thanks,

-Richard

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...