Working with SCTP ancillary data in FreeBSD

Comments

Introduction

The socket interface provides good generalized interface for the underlying networking protocol, which is exactly what one programmer needs in most of the time. However for some more specific use cases someone might want to exploit specific protocol features, which can't present in the generalized interface. Ancillary data allows the socket interface to handle such specific protocol parameters/features, otherwise unaccessible from the socket API. Today we will add some ancillary data support to the one-to-many style application from the previous post.

Before digging right into the ancillary data I believe I owe you an explanation. My initial intention was to demonstrate the SCTP interface in Linux and as you have probably noticed, up to now I wrote only for Linux. However it turned out that not all ancillary data control messages are supported out of the box in the Linux distribution I currently use (Ubuntu 14.04.2 LTS with kernel version 3.16.0-36). Because the SCTP stack in Linux was ported from FreeBSD I decided to see what is supported there. Luckily all control messages described in Section 5.3 from RFC 6458 were supported in FreeBSD. That's why for this post I will use this operating system.

If you need to use some SCTP specific features in your Linux powered project I suggest you to use sctp_sendmsg, sctp_connectx, etc.

Read more…

SCTP Linux API: One-to-many style interface

Comments

Introduction

In the previous post we saw one very simple example of SCTP client-server application with the one-to-one style API. Here I will reimplement it with the one-to-many interface and we will see different approach to the same application. Again all the code used in this post is available for you on this GitHub project. Switch to 'one-to-many_basic' branch before you continue. This and the following posts will heavily use information from RFC 6458 Sockets API Extensions for the Stream Control Transmission Protocol (SCTP). As usual I will provide links to the relative sections for your convenience. If you are serious about using Linux's SCTP socket API I highly recommend you to read the entire specification. You will find tons of interesting information there.

Read more…

Introduction to the SCTP socket API in Linux

Comments

Sockets introduction

In Linux, you deal with the network stack via sockets. I assume you are familiar how they work and you have got some basic network programming knowledge in C. What I mean is that you know what functions like socket(), bind(), listen() do, how you should call them and how to implement a simple client-server application. For the purposes of this and the following posts I have created a project in GitHub. You will find there all the code mentioned here. Please check the one-to-one_basic branch now and make sure you understand the code there. It is nothing fancy - client and server application exchanging few messages over SCTP. Anyway if you need a refreshment or you are new to Linux socket programing check some other tutorial on this topic. There are a lot of good ones out there so just pick one you like. My personal best is Beej's Guide to Network Programming.

Disclaimer about the code

Please note that the code is not at all intended to be used on production systems. It is created as a demonstration for the interfaces that I shall write about. It has got some basic checks, but it is far from production ready. If you plan to use it in your project please take some time and add proper error handling. You have been warned.

Read more…

SCTP failure detection and association teardown

Comments

Overview

In the previous post we reviewed how the essence of the SCTP protocol works - the user data transfer. Now it's time to see some failure detection procedures and finally how an SCTP association is closed. Both topics will be discussed in this post. Error detection procedures are specified in Section 8, titled 'Fault management', but in this post I will mainly discuss heartbeating. The other failure detection mechanisms will be described in brief, so if you wish to know more about the specific mechanism - read the corresponding Section of the specification (hyperlinks are provided in each section). Association teardown is specified in Section 9 - 'Termination of association'.

Read more…

SCTP Data Transfer

Comments

Overview

Up to now I have reviewed message encoding and association initialisation. Now it's time to see how SCTP does some real work - user data transfer. It is implemented via DATA and SACK chunks. Two peers can exchange user data only when the association is established, which means it should be in ESTABLISHED, SHUTDOWN-PENDING or SHUTDOWN_SENT state. SCTP receiver must be able to receive at least 1500 bytes in a single packet, which means its initial a_rwnd value (in the INIT or INIT ACK chunk) must not be set to a lower value. Similar to TCP, SCTP supports fragmentation of user data, when it exceed the MTU of the link. The receiver of the segmented data will reassemble all chunks, before passing it to the user. On the other side, more than one DATA chunk can be bundled in a single message. Data fragmentation will be discussed in more details later.

Read more…

SCTP - association initialisation

Comments

Introduction

In my previous post we've explored how SCTP packets are encoded and what protocol elements they contain. Next we will look at three SCTP procedures - association creation, user data transfer and association tear down. Each procedure requires specific message flow, which will be reviewed in separate posts.

Section 4 from RFC 4960 has a state diagram for a SCTP association. There are two main states - CLOSED and ESTABLISHED. The transfer between them contains more intermediate states (COOKIE-WAIT, COOKIE-ECHOED, etc). Two endpoints can exchange user data only when the association is in ESTABLISHED state. This is accomplished with association initialisation procedure. Once it is completed successfully the peers can exchange data by following user data transfer procedure. Finally the connection is closed with termination of association procedure. Now we will review association creation procedure.

Read more…

SCTP: overview and message encoding

Comments

SCTP Introduction

SCTP is transport layer protocol with functions similar to TCP and some unique additions. Although it is not very popular in the Internet world, this protocol plays important role in telecommunication networks. It is used as a transport for various SIGTRAN protocols and it is the default transport protocol in EPC.

There is a Wikipedia article which provides a basic overview of SCTP's features. Another good document is SCTP: What is it, and how to use it? by Randal Stewart, Michael Tuxen and Peter Lei. In this article I want to provide SCTP overview from network developer point of view, which (in my opinion) means to dig into some specifications. What you will find here is a quick walkthrough the parts that I find most interesting, with references to the corresponding sections in RFC 4960, the SCTP specification.

Read more…

LDAP support in Asterisk 1.4

Comments

This is another post from my old blog. Again - the information here is old so it may not be useful for the recent versions of Asterisk. It is for Asterisk 1.4.

I had to use an LDAP server to retrieve SIP accounts for Asterisk. I had some difficulties to make it work, so I'll describe what I did here. Officially in Asterisk 1.4 there is no LDAP support, but there is a plugin in SVN, which works with the trunk version. You can get it from here. res_config_ldap.c should be added in res from Asterisk source code directory. Then compile this way:

./configure
make menuconfig
LIBS=-lldap
export LIBS
make
make install

Then edit res_ldap.conf. You can get a sample from here. In the section [sip] you should add this line, for clear text password (highly unrecommended!):

secret = AstAccountSecret

In extconfig.conf this lines should be added:

sippeers => ldap,"ou=accounts,dc=example,dc=com",sip
sipusers => ldap,"ou=accounts,dc=example,dc=com",sip

And finally the LDAP server should include this schema. Restart Asterisk and everything should be fine.

func_odbc in Asterisk

Comments

Sooner or later, when you develop a dialplan for asterisk you'll need to work with database. There are many approaches for this. Below there is an old post from my previous blog, describing how to accomplish this with func_odbc(). This information is a bit outdated - it was tested on Asterisk 1.4, so it may not be usable for the current versions.

Of course in order to use func_odbc() you should have installed and configured ODBC itself. If you don't know how to do this check this great article from Debian-Administration.org. I'll only add that if the database connections are described in /etc/odbc.ini they will be accessible from all users of the system, which might be unacceptable. Alternative approach is to save the configuration in ~/.odbc.ini so they will be accessible only for the given user.

In Asterisk, the configuration file res_odbc.conf should be modified. For example:

[asterisk]
enabled => yes
dsn => ASTERISK
username => user
password => pass
pre-connect => yes

The database name is specified in square brackets, dsn is the dsn from odbc.ini. After that in func_odbc.conf you should configure the desired requests. For example:

[TEST]
dsn=asterisk
read=SELECT name from test where extension='${ARG1}';
write=INSERT INTO test VALUES ('${ARG1}', '${VAL2}');

As with AstDB, each function can read or write from/to the database. Here is an example how to use the new functions in Asterisk dialplan:

Set(foo=${ODBC_TEST(${EXTEN})})
Set(ODBC_TEST(alpha)=200)

The first line gets a value from the database, the second - saves one. alpha and ${EXTEN} are arguments (ARG). 200 is value (VAL). There are more examples at voip-info.org