Thursday, July 19, 2012

Kamailio v3.2.4 Released

Kamailio SIP Server v3.2.4 stable is out – a minor release of the previous stable branch including fixes in code and documentation since v3.2.3 – configuration file and database compatibility is preserved.
Kamailio (former OpenSER) 3.2.4 is based on the latest version of GIT branch 3.2, therefore those running previous 3.2.x versions are advised to upgrade. There is no change that has to be done to configuration file or database structure comparing with older v3.2.x.
Note that the latest stable release series is 3.3.x (at this moment the latest packaged version being v3.3.0) – Kamailio project is officially maintaining the latest two stable branches to allow long term support (approx 2 years) for all deployments. New installation should start with the latest stable version.
Resources for Kamailio version 3.2.4
Source tarballs are available at:
Detailed changelog:
Download via GIT:
  # git clone –depth 1 git://git.sip-router.org/sip-router kamailio
  # cd kamailio
  # git checkout -b 3.2 origin/3.2
  # make FLAVOUR=kamailio cfg
Binaries and packages will be uploaded at:
Modules’ documentation:
What is new in 3.2.x release series is summarized in the announcement of v3.2.0:

Saturday, July 14, 2012

Kamailio v3.1.6 Released

Kamailio SIP Server v3.1.6 stable is out – this is the last minor release packaged from branch 3.1. It includes fixes in code and documentation since v3.1.6 – configuration file and database compatibility is preserved.
Important note: this release has been done to mark the end of official packaging of 3.1.x series. As of July 18, 2012, with the release of v3.3.0, the last two stable branches are 3.2 and 3.3. If you look to install the latest stable version, you have to use v3.3.0 at this moment.
Kamailio (former OpenSER) 3.1.6 is based on the latest version of GIT branch 3.1, therefore those running previous 3.1.x versions are advised to upgrade. There is no change done to configuration file or database structure.
Resources for Kamailio version 3.1.6
Source tarballs are available at:
Detailed changelog:
Download via GIT:
 # git clone –depth 1 git://git.sip-router.org/sip-router kamailio
 # cd kamailio
 # git checkout -b 3.1 origin/3.1
 # make FLAVOUR=kamailio cfg
Binaries and packages will be uploaded at:
Modules’ documentation:
What is new in 3.1.x release series is summarized in the announcement of v3.1.0:

Tuesday, July 10, 2012

Kamailio worldwide in August and September

If you want to meet people around Kamailio project, it might be your chance to be nearby several locations around the world in August and September:
  • Chicago, IL, USA – August 7-9 – during Clucon Conference, Kamailio will be touched in at least two presentations – the talks about mobile geo-location server by Luis Guaman and the one about Homer project by Alex Dubovikov
  • Alkmaar (or Amsterdam Area), The Netherlands – September 10-12 – during Kamailio Practical Workshop, coordinated by Daniel-Constantin Mierla
  • Seattle, WA, USA – September 24-26 – during Kamailio Advanced Training, coordinated by Daniel-Constantin Mierla and Flowroute
Contact us via sr-users community mailing list to get in touch or announce other Kamailio-related events to be listed here.

Monday, July 9, 2012

SIP over Websocket support integrated into Kamailio

Peter Dunkley, an active member of the Kamailio developer team, has integrated support for SIP over the WebSocket protocol into Kamailio. It will be part of the next release and exist only in the developer code today. There are still some issues to sort out to get a production-ready setup. SIP over Websockets, an IETF draft composed by a number of members of the SER/Kamailio/SIP router community – Iñaki Baz Castillo, Victor Pascual and José Luis Millán Villegas – is still a moving target and hopefully on it’s way to become an RFC.
From the IETF draft abstract:
   The WebSocket [RFC6455] protocol enables messages exchange between
   clients and servers on top of a persistent TCP connection (optionally
   secured with TLS [RFC5246]).  The initial protocol handshake makes
   use of HTTP [RFC2616] semantics, allowing the WebSocket protocol to
   reuse existing HTTP infrastructure.

   Modern web browsers include a WebSocket client stack complying with
   The WebSocket API [WS-API] as specified by the W3C. It is expected
   that other client applications (those running in personal computers
   and devices such as smartphones) will also run a WebSocket client
   stack.  The specification in this document enables usage of the SIP
   protocol in those new scenarios.

   This specification defines a new WebSocket sub-protocol (section 1.9
   in [RFC6455]) for transporting SIP messages between a WebSocket
   client and server, a new reliable and message boundary transport for
   the SIP protocol, new DNS NAPTR [RFC3403] service values and
   procedures for SIP entities implementing the WebSocket transport.
   Media transport is out of the scope of this document."

The Kamailio SIP over Websocket support

Some customisation of the websocket module is possible through modparams, but for most users the defaults should be OK.  The WebSocket module uses
the xhttp and sl modules for the initial handshake, and (unless you have both a Kamailio installation and WebSocket SIP client supporting GRUU, Outbound[1], and Path[2]) nathelper for request routing and the core force_rport() function for response routing (a new nat_uac_test() has been added to detect whether a message has arrived on a WebSocket).  There is an example kamailio.cfg in the websocket module directory.
  • [1] Kamailio does not currently support Outbound
  • [2] I have not updated the Path module for WebSockets
I believe that, once Kamailio supports Outbound and WebSocket support is added to the Path module (and you have a SIP over WebSocket client that
supports this), it will be possible to use the websocket module without the nathelper module and force_rport() and without needing to change the websocket module or Kamailio core code.
If you want to use secure WebSockets (wss) as well as ordinary WebSockets just configure TLS and listen on an appropriate port.
I have added WebSocket support to some modules, but there are definitely going to be others (modules/lcr, modules/sipcapture, modules_k/nat_traversal, modules_k/path, modules_k/seas, and modules_k/snmpstats, at least) that need updating too.  WebSockets is an unusual transport, so I have put a few notes together for anyone who needs to use it in the code (including adding support to additional modules):
  • A WebSocket server cannot initiate a WebSocket connection.  So a WebSocket connection (over TCP or TLS) is like a TCP/TLS connection coming from behind a NAT.  This is why nathelper aliasing and force_rport() is used for the routing, and “set_…_no_connect()” is always used (it’s set within the websocket module).
  • WebSocket (PROTO_WS) and secure WebSocket (PROTO_WSS) connections are just upgraded TCP and TLS connections, so there are no listening sockets for PROTO_WS and PROTO_WSS.  This means that, when deciding on what transport is being used, you need to look at the proto set in the tcp_connection, receive_info, and/or dest_info structure for the message -looking at the socket_info structure (that the message has arrived on or will be sent on) will not give you the right answer.
  • Although WebSocket (PROTO_WS) and secure WebSocket (PROTO_WSS) are different internal protocols there is only one SIP transport type for both ”;transport=ws” (WS and WSS are explicitly used in Via: headers though).  This means that you can’t tell whether the transport parameter in an R-URI, Route/Record-Route, or Contact-URI is for WebSockets or secure WebSockets.  As long as the message makes it into the WebSocket module everything will be OK as that module sorts it all out, but it has led to slightly more complex checks being required in some of the code relating to record-routing to handle this – and it may have an effect on other modules too.
Please give the new module a go and let Peter know (by writing to the developer mailing list) about any issues you find!

Friday, July 6, 2012

Two new Diameter-IMS modules added to Kamailio repository

Jason Penton of Smile Communications has just  committed CDP and CDP_AVP modules.
CDP (C Diameter Peer) allows Diameter communication from Kamailio and CDP AVP is a helper module for various applications on top of CDP (C Diameter Peer). CDP AVP module adds support for the following applications:
  • Various base AVPs (implemented in base.h) for RFC3588 base AVPs
  • Base AVPs (implemented in nasapp.h) for RFC4005 base AVPs
  • Diameter Credit Control App (implemented in ccap.h) for RFC4006 AVPs
  • EPC (implemented in epcapp.h) for 3GPP Rx, Gx(x) interface AVPs – see TS29l061, TS29.212, TS29.214, TS29.272 and TS29.299
  • IMS (implemented in imsapp.h) for 3GPP IMS AVPs, Cx, Dx, Sh interfaces – see TS29.229 and TS29.329
You can read more about them in the module documentation:
RFCs