However a small tool really useful can help you: Siproxd

Siproxd is a Sip proxy really simple to use. After a standard installation (depending of your distribution) you can start to configure it. Three parameters must be modified:

• if_inbound: used to define the network interface used as internal network. It’s the network where your sip phone is plugged (eth0 for example)
• if_outbound: used to define external network interface. In my case it is the VPN’s virtual network interface (tap0 for example)
• hosts_allow_reg: list of networks allowed to register to a SIP server.

Now you have a fully functional Sip proxy. Adding debug log (silence_log parameter) can help you for diagnostic.

Finally only a Microsoft Windows port is missing…

Project web : siproxd

Then Astitray’s objective is to provide:

• A simple application
• with a good desktop integration
• which allow to originate calls
• with a central phone book

Of course it is not possible to open a manager access to all desktop computers and sharing a common access will allow bad jokes (like originate a call for a friend…).

The Astitray coming with a XMLRPC server written in PHP. This one handle access control and all services. The objective of this is to create an abstraction stack for PBX communication. In this situation, it’s possible to write a “driver” for an other PBX than Asterisk.

Anyway, depending of the number of desktop computers, XMLRPC server should not be used directly with asterisk manager and a proxy must be used. But Astitray use Ajam to communicate with asterisk. For the moment, there is no proxy which is able to handle this. So writing driver for handling native manager protocol in Astitray is the next step for the project !

ENUM is a telephony directory system based on DNS infrastructure and allowing an association between a traditional phone number (using E.164 format) and Internet oriented information. It is possible to store information related to email address, URL but more important for us today: SIP, IAX or H.323 addresses that could be used to be reached through.

ENUM can authorize a smooth transition between the traditional telephony system, where we are using phone numbers, towards pure IP telephony where we will manipulate URI (as email addresses). We are today in between, using IP telephony with traditional phone numbers.

How is ENUM working

As said previously, ENUM is based on DNS. It stores information accessible through this protocol and highly used over the Internet to translate names to IP addresses. With ENUM we are translating phone numbers to internet information like a SIP address for example. The key used in the ENUM base is a traditional phone number but these ones are mostly used nowadays, no issue.

Whenever an IP PBX wants to route a call to a traditional phone number, it could check first if a SIP (or IAX or H.323) record is available in the ENUM base. If such information exists, it could use it to establish a peer-to-peer telephony call, directly over the Internet or any other IP network. If the information isn’t available, the call will be routed through a standard operator (PSTN or Centrex).

How to register

Prior being able to get direct call on your IP PBX, it requires you register your phone number into one of the ENUM databases. Effectively there are multiple ENUM databases, some are maintained by providers, other are free, you can also build your own one for a closed user group. We can consider today that ENUM is not yet widely deployed by telcos since it authorize peer-to-peer calls that will not be billed, nor even supervised.

The easiest way to start is by using the e164.org free service¹. Once your account created, you can register two different entries:

• from a PSTN valid number you can link one or multiple IP telephony records (ie a SIP uri),
• from an IP PBX connected to the Internet (directly or through an SBC² ) get virtual numbers that can be called by any ENUM user. For example, e164.org is providing you with 10.000 numbers for each server you register, enough to start with, isn’t it?

Warning: any ENUM SIP entry at e164.org requires a valid PBX. A validation call will be issued during register in order to avoid fake entries.

How to check a record

Once registered in the system, your ENUM information will be propagated in the DNS system and can be queried by DNS client tool. If you haven’t the dig DNS client on your system, it is a good time to install it.

In order to query the ENUM system, we have to provide it a phone number. The request is similar to a reverse IP address query, we have to rewrite the phone number in reverse for this (try to make it without pen and paper, it is good for brain training). Last, since we are looking for a specific information and not a domain name or an IP address, we will specify the NAPTR type of record. A typical query could looks like:

dig 9.9.9.9.8.7.3.5.0.0.9.9.2.8.8.e164.org. NAPTR

This request query the ENUM database for an IP telephony way to reach the user with the phone number : 88299 005378 9999. This number is not a PSTN number but one from my personal number out of the e164.org range. The answer is:

;; ANSWER SECTION:
9.9.9.9.8.7.3.5.0.0.9.9.2.8.8.e164.org. 600 IN NAPTR
   100 10 "u" "E2U+IAX2"
   "!^\+88299005378(.*)$!iax2:guest@cislyon.homeip.net/88299005378\1!" .

It is an IAX record followed by a URI that can be directly used through the Asterisk Dial() command.

When your record is in the ENUM database and available through your DNS client, any IP PBX using the ENUM would be able to place a peer-to-peer call to your place.

Asterisk configuration for ENUM

You will find some literature over the Internet to set up your ENUM configuration in Asterisk, but for a quick test, here are the main points.

Receiving calls with IAX

IAX is the Asterisk protocol used to interconnect PBX. This solution has a big advantage: the signalling and voice parts are sharing the same media path, only one UDP port is used for a phone conversation, which is good for firewall and NAT boxes. Once your security infrastructure allows IAX calls to flow in, we have to add few things in the Asterisk configuration.

In iax.conf we add a specific section corresponding to the entry registered in the ENUM. In the previous example, my number 88299 005378 9999 is associated to a user called guest located behind a server called cislyon.homeip.net. The section to add in the configuration is:

[guest]
type=user
context=fromiax

This one is very basic and will probably need some adjustment if needed (ie codec). From a security standpoint, since calls from anywhere over the Internet needs to be accepted, there is no host line³. Any call towards this user will be presented to the fromiax context in the dial plan.

The dial plan is configured in the extensions.conf file and contains any action required to handle a call. The configuration could look like

[fromiax]
; echo pour Enum IAX
exten => 882990053789999,1,Answer()
exten => 882990053789999,n,Echo()

Here, we have an entry corresponding to the phone number and the service proposed is an echo of anything you would say, ideal for testing service, quality and latency⁴.

Receiving calls with SIP

When dealing with SIP, even if the principle remains the same, we have more things to do and the configuration is a bit different. But first we assume that you can receive SIP calls from the Internet with regards to security measures (firewall, NAT, …).

If you plan using e164.org, you have to set-up the call validation part. One approach is to create a dedicated context in sip.conf. This could differ based on the ENUM provider you may choose. You can add something like:

[enumsip-e164]
type=peer
host=e164.org
qualify=no
context=from-e164org
insecure=very

In the call plan, we have to add a section for this call validation, but since only an INVITE is sent, we limit it to something like:

[from-e164org]
exten => _.,1,Answer()
exten => _.,2,Hangup()

Now we need the specific configuration to accept SIP calls. This part is not trivial since Asterisk wants to validate any peer establishing a SIP session and link it to a context in sip.conf. In our ENUM case, we would like any call to be accepted, by definition we don’t know by advance who will place it. We will for this part use the fallback test proposed by the SIP Asterisk implementation: if a call could not be linked to a context, send it to the dial plan default context. Since any call will arrive in this context we have to be careful on our dialling rules. For example you could do in extensions.conf:

[default]
; echo pour ENUM SIP
exten => 882990065339999,1,Answer()
exten => 882990065339999,n,Echo()

A SIP call to 88299 006533 9999⁵, will arrive to the Echo() application.

Now our Asterisk system is able to get calls, let’s move to the dialling part.

Dialling with ENUM

The idea here is to check whether an ENUM entry exists before using a standard PSTN or SIP provider. The function used is called ENUMLOOKUP and available in the func_enum.so module. This one should be present in the module configuration and the associated enum.conf file in the configuration directory.

The ENUMLOOKUP performs the DNS query to the ENUM provider specified, by default e164.arpa.

Our proposal to add in the extensions.conf file is a macro:

; callENUM *****
; --- get address in ENUM DNS record and dial
; args:
;  1: extension
;  2: domain to lookup
;  3: iax2 or sip
;
[macro-callENUM]
exten => s,1,Set(count=${ENUMLOOKUP(+${ARG1},${ARG3},c,,${ARG2})}|counter=0)
exten => s,n(start),GotoIf($["${counter}" >= "${count}"]?end)
exten => s,n,Set(counter=$[${counter}+1])
exten => s,n,Set(ENUM=${ENUMLOOKUP(+${ARG1},${ARG3},,${counter},${ARG2})})
exten => s,n,GotoIf($["${LEN(${ENUM})}" = "0" ]?start)
exten => s,n,Set(DIALSTR=${ARG3}/${ENUM})
exten => s,n(dodial),Dial(${DIALSTR},30)
exten => s,n,GotoIf($["${DIALSTATUS}"=="CHANUNAVAIL"]?start)
exten => s,n,GotoIf($["${DIALSTATUS}"=="CONGESTION"]?start)
exten => s,n(end),Verbose(Dial failed due to ${DIALSTATUS})

The way it works is: first we check that at least one record is present in the ENUM database (there could be more than one for redundancy purpose). Then we look for a specific record matching a signalling protocol that could be IAX or SIP, then use the answer to perform a Dial(). If the call is not working, we try the next record and return if success-less.

In order to use this macro one could use something like:

exten => _X.,1,Macro(callENUM,${EXTEN},e164.org,iax2)
exten => _X.,2,Macro(callENUM,${EXTEN},e164.org,sip)
exten => _X.,3,Macro(callENUM,${EXTEN},e164.arpa,sip)

Here we try an IAX the SIP call with ENUM record in e164.org. If not working, we try in SIP only with the e164.arpa ENUM database.

Conclusion

We could see here that peer-to-peer IP telephony is technically ready but not yet widely used since the PSTN network is still highly used. The migration towards IP telephony is in progress and initiatives such as ENUM are very good since will allow “operator less IP telephony”. It will remain some issue to solve with regards to regulation and legal monitoring of phone calls which are technically difficult to put in place with peer-to-peer telephony.

Don’t expect to receive a lot of phone calls through your ENUM registery, but the more will use it the more we will have a chance to place free calls using our IP PBX.

1. for sure you can donate afterwards if you like it [↩]
2. Session Border Controller [↩]
3. we will see in another article how to protect from spam and spit [↩]
4. you could give a call to this extension for your ENUM tests [↩]
5. this is also a specific e164.org number [↩]

A new Wi-Fi phone, this is not really a big news since the market is already filled with these small gadgets. But the data sheet and user guide are talking about some innovation that may raise the customer expectation on this area. If we consider that Aastra reports its experience on SIP in the new model and install a similar software in its Wi-Fi model than in the 5xi product range, I think I will love it¹.

In the proposed features I have seen :

• the ability to store the phone configuration, user profile and phone book on a memory card that could be transferred to another phone. This feature was used on some market telephony turrets, but I haven’t seen it on IP phones.
• a real user guide
• Wi-Fi security with WPA and WPA2 using pre-shared keys (no Enterprise mode)
• IEEE 802.11e support for efficient power saving implementing U-APSD
• since such a phone will be in movement, the screen is able to show the Wi-Fi radio signal level and the AP on which it is currently associated, as well as the history of the last one

On the bad points, the information is not yet available on Aastra corporate site, but you can get it on the German entity that develop the product. This is probably linked to the fact the products hasn’t yet been widely launched.

We are very excited about testing this new IP phone with Asterisk and asked to the French Aastra entity to send us a model. This will be done soon so stay tuned…

1. I am a 5xi fan [↩]

Introduction

Wireshark (aka Ethereal) is a tool to have in his toolbox whenever working with application using the network; it is simple, efficient and running either on Microsoft Windows or Linux, moreover it is free. Even if you will find on some commercial products very powerful features, Wireshark has some good plugging targeting the VoIP space (aside many others). This article is more focusing on SIP and RTP protocols which represents most of nowadays voice over IP implementation.

How to capture frames

Prior analysing the network frames crossing the network it is required to capture these ones. Analysis could be done either in real time when Wireshark is running on the probe itself, but it is also possible to capture the frames, store these in a file and perform the analysis afterwards.
More important is where to locate the probe in order to gather the appropriate frames containing voice related protocols. Since the SIP protocol is really distributed by nature, gathering voice traffic is a challenge but there are solutions.

In order to collect voice frames we can either use Wireshark directly or use the application tcpdump, available on most Unixes and working directly from the command line.

With the chosen tool, two approaches are proposed:

• using a mirror port on a switch: this solution requires to use network switches with a port mirroring feature. Generally available on advanced enterprise products, some low end devices are not supporting it. The feature is sometime called port mirroring or SPAN port but the way it works is the same: we configure the switch to copy all frames going in and out a specific port towards a dedicated port where the analyzer is connected. If the voice traffic is separated from the data traffic onto a specific VLan, it is sometimes possible to copy all traffic going through the Vlan towards the copy port. The port we will copy is where the SIP proxy is connected, but we can also copy an IP phone port if we know more precisely what to look at.
• using directly the proxy server: this second solution is about capturing traffic on the unix server hosting the proxy. For sure this requires running the tcpdump command directly from this server, which is not always possible. In the case of Asterisk, we are mainly using Linux as a hosting system and Linux does support tcpdump in most distribution, we will install it directly from the package if not yet present.

Capture with tcpdump

When using Asterisk, we can take advantage of two main points:

• the operating system is mainly Linux, so we can use tcpdump
• Asterisk is acting as a “back-to-back UA”, that is to say it stays by default in the middle of any session (phone call), even if this is not following the SIP distributed model, we will leverage on it; see also “Asterisk and voice transport”.

When doing a capture directly from the Asterisk server, we will have the full voice session, including signalling (SIP part) and the voice transport (RTP part).

tcpdump is a line command, it doesn’t require any graphical interface to run and is very light, we could use it without putting to much stress on our voice gateway and altering the quality¹. As always with Unix, the command requires parameters and tcpdump proposes a lot of options. Here is a list of the useful ones in our case:

• -p : doesn’t start in promiscuous mode, only frames from or to the Asterisk node will be captured,
• -n : no name resolution, otherwise we will have a lot of DNS queries which is not useful at that stage, we could do name resolution afterwards if needed,
• -s 0 : we get the full frame, not only the first bytes. When working only at the protocol level it is enough to get only the start of each frames, in our case we are requiring the content of the SIP and RTP frames. 0 means getting the whole frame,
• -w output file : all the captured frames will be stored in the file. That way we will be able, afterwards, to analyze the frames from the file. If using ‘-’ as the name of the file, the output is send to the standard output, we will use this afterwards.

In addition, we could specify to tcpdump a filter which will lower the number of frames we got in the capture. We can for example get only UDP frames and filter IP addresses in order to focus only on a specific host.

Local capture

In order to perform the capture directly on the Asterisk host we should be connected to it. This can be achieve either directly on the console or through a remote terminal, I do like ssh like many admins since it is simple and secured.

With the following command

tcpdump -w trace.cap -p -n -s 0 "udp”

, we will gather all UDP frames in transit on our server, the capture will be stopped by pressing CRTL-c. The file trace.cap will be stored for later analysis. If storage space is low on the Asterisk server, we can compress the trace with a very good ratio, using gzip.

Remote capture

Since you could manage many Asterisk servers, it could be easier to start a capture from your desktop by using the remote command facility provided by ssh. The ssh command on the desktop is required, already installed on Mac OS X and on Linux, you can install the Cygwin version on Microsoft Windows, you will have exactly the same command.

The proposed command is:

ssh root@asterisk 'tcpdump -w - -p -n -s 0 udp' > capture-asterisk.cap

The capture will occur on the server named asterisk using the tcpdump command, the frames will not be stored on the server itself but redirected to the desktop machine through the ssh tunnel². The file will be named capture-asterisk.cap and stored in the current directory. Using such method, you can start a capture on multiple Asterisk servers without having to connect on these and transfer the capture file afterwards, furthermore, no storage issue.

Analyze

One we have a trace file we can now use the Wireshark tool to dive in it.

Wireshark is using a rich GUI and presents all the frames in the capture³. On the upper window part you have the frame list, below the content of the selected frame either in decoded format either in raw. For sure Ethernet and IP protocols are decoded, what interest us today are SIP, IAX2 and RTP protocols since dedicated to voice over IP.

From the file explorer, we can open the file trace and analyze it, by default frames are ordered by arrival time, you can change this sort criteria if required.

Filtering

Depending on the filter used during capture, we can have noisy frames in it. The filtering feature of Wireshark allows to focus only on specific frames, it is activated through the ‘Filter’ field on the upper part of the window. The filter language is specific but easy to learn, for example if only SIP frames are needed you enter the ‘sip’ filter, if you are interested in IAX, the filter is ‘iax2’. One tip: when the filter background field is green the syntax is ok, when orange it is not yet good.

If you need more complex filtering rules, you can directly select the field from the decode window. Each protocol fields can be selected and added to the current filter through a right click and the “Apply as filter / … and Selected” menu.

SIP analysis

When looking at all the frames we have in a capture, it could be difficult to find quickly what we are looking for. Hopefully, Wireshark is bundled with some SIP tools, these are accessible through the “Statistics / VoIP calls” menu.

In the window you will see all the voice over IP calls present in the capture file. If the capture is performed directly with Wireshark, this list will evolve in real time.

From the list, it is possible to show a specific conversation graphically. This view is really helpful to follow the conversation since all frames can be selected and inspected in the main window. It is also possible to analyze the content of the voice conversation since transported in the RTP files.

The “Player” feature decodes the RTP frames associated with the selected conversation. The graph is showing the shape of the voice flow for both ways. This tool is interesting when focusing on voice quality, if a user is complaining when talking with a specific phone, it is possible to listen to the conversation afterwards.

RTP analysis

The RTP⁴ protocol is not dedicated to voice over IP traffics. But this protocol is used aside H.323 and SIP signalling, Wireshark proposes a specific module to analyze the RTP flows. The feature is available through the “Statistics / RTP / Stream Analysis” menu.

The analysis window proposes information about the terminals engaged in the conversation, the used codec and some statistics about the flow. You can focus for example on jitter and packet loss in order to explain why the voice quality wasn’t good enough. From this module, it is also possible to extract the content of the RTP frames and rebuild a voice sound file. This one will be saved in WAV format and you can listen it with any sound tool available⁵.

Conclusion

IP telephony, like any application heavily using the network, should be analyzed whenever a problem occurs. In order to be reactive, my advice is to train yourself when everything is working fine and you have spare time to train. This will allow you to know the tools but also when looking at nothing special it is very common to find issue on the network. Finally, don’t be afraid by protocols, even if they are complex, their proper understanding will be a great advantage when facing a real issue on your system.

1. be careful if your system is low on resources since tcpdump works at a very low level and could impact real time performances in that case [↩]
2. one could put in place ssh keys in order to automated the login part [↩]
3. be careful to limit the capture file size, when playing with > 50MB files the memory is highly stressed [↩]
4. Real Time Protocol [↩]
5. if the codec used for encoding is supported by your player [↩]

Introduction

SIP is a protocol dedicated to multimedia session establishment and management between peers. In this respect, SIP is considered as a peer-to-peer protocol. Today, we are mainly using SIP in the voice world in order to establish phone calls, but a lot of applications are supported by SIP on top of a session.
In order to be able to establish a session (in our case a phone call), one peer needs to know how and where to reach the other peer. This function is provided by the proxy which is able to lookup the destination address and establish the relationship between both peers. The lookup is performed within a kind of directory and maintained by either static routing (call routing in this case) or dynamic registration of clients.

The SIP proxy server is looking in the directory for IP Information related to the session’s destination. We are talking about User Agent (UA) for the database key and IP information related are address, protocol (TCP or UDP) and port number. Each UA is hosted on an IP machine (ie an IP phone) and uses UDP (or TCP) ports in order to communicate. The default SIP port number is 5060 but it is not mandatory to use this one. When a proxy server is asked to put in relation two members of a session, it should find IP information related to each UA.

This is the main role of the registrar to collect IP information from the UA and feed the directory in order for other SIP components (ie proxy) to be able to manipulate sessions.

Since initial IP information are only known by the client (UA), we require a specific communication between the UA and the registrar in order to inform this one. This specific exchange is performed at the UA start-up and on a regular basis in order for the registrar to clean the directory from old (and thus invalid) records. By default the exchange is done every hour, but this period can be adjusted.

The registration phase between each UA and the registrar server is using a SIP specific method called REGISTER.

Parameters

First, each UA willing to establish a session should know how to reach the other UA. Generally a SIP component is used for this purpose: the proxy. The proxy information should be available in the UA configuration. This is either done statically with a configuration in the UA maintained through the web interface, a file or through automatic provisioning if supported by the UA application. It could also be possible to use specific records available in a DNS service, for more information on this topic, please have a look to “SIP registry and DNS SRV”.

How does it work

Here below is a registration exchange trace between an IP phone (at 192.168.16.181) and an Asterisk server (acting as a registrar, at 192.168.16.40). The network trace has been collected with Wireshark and exported as text:

Session Initiation Protocol
    Request-Line: REGISTER sip:192.168.16.40 SIP/2.0
        Method: REGISTER
        [Resent Packet: False]
    Message Header
        Via: SIP/2.0/UDP 192.168.16.181:32262;branch=z9hG4bK-d87543-624dc77d9c1b9618-1--d87543-;rport
        Max-Forwards: 70
        Contact: <sip:11@192.168.16.181:32262;rinstance=9dd2c78e6ac0a5a5>
        To: "soft 2"<sip:11@192.168.16.40>
        From: "soft 2"<sip:11@192.168.16.40>;tag=394aa21c
        Call-ID: YjYzYTAyNzM0NGVkYmEzZWMyMzJmNzMzNDZjMzIyMjg.
        CSeq: 1 REGISTER
        Expires: 3600
        Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
        User-Agent: X-Lite release 1011s stamp 41150
        Content-Length: 0

Main information we could see in this exchange are:

• the SIP method: REGISTER
• information regarding the UA, these are in the Contact field: URI 11@192.168.16.181:32262 in which we found the identifier (phone number in this case, 11), the IP address (192.168.16.181) and port number on which the UA is listening for SIP messages (32262). You can see here the SIP port is not the standard one (5060), but since it is not mandatory to use the standard one we have to put it in the URI.

The answer from the registrar should be 200 OK in order for the UA to be known in the directory. Here is the answer frame from our Asterisk server:

Session Initiation Protocol
    Status-Line: SIP/2.0 200 OK
        Status-Code: 200
        [Resent Packet: False]
    Message Header
        Via: SIP/2.0/UDP 192.168.16.181:32262;branch=z9hG4bK-d87543-624dc77d9c1b9618-1--d87543-;received=192.168.16.181;rport=32262
        From: "soft 2"<sip:11@192.168.16.40>;tag=394aa21c
        To: "soft 2"<sip:11@192.168.16.40>;tag=as22b3d595
        Call-ID: YjYzYTAyNzM0NGVkYmEzZWMyMzJmNzMzNDZjMzIyMjg.
        CSeq: 1 REGISTER
        User-Agent: Asterisk PBX
        Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
        Supported: replaces
        Expires: 3600
        Contact: <sip:11@192.168.16.181:32262;rinstance=9dd2c78e6ac0a5a5>;expires=3600
        Date: Sun, 07 Oct 2007 13:00:11 GMT
        Content-Length: 0

In the answer we can find:

• message type: OK
• same contact content as in the register message
• same Call-Id field which identifies the exchange, since this one can use UDP as the transport medium.

Validation

Once the registration is performed, the registrar should be able to restitute information contained in the directory. Each SIP PBX should therefor have a command or a way to gather which SIP UA are registered and the IP information related. With Asterisk, the sip show peers command on the CLI is able to list all configured peers and there respective status:

asterisk41*CLI> sip show peers
Name/username              Host            Dyn Nat ACL Port     Status
11/11                      192.168.16.181   D          32262    OK (3 ms)

On this output we can see the UA identifier (11), the IP address and the port number. Asterisk is not providing information about the protocol used to talk to the client since supporting only UDP for now¹. The last information is the status and the monitoring delay between the Asterisk server and the UA, see also “Network transit and peer qualification”.

Troubleshooting

In the case one UA is not able to get registered, it could be useful to see the cause and if registration messages are well exchanged. In the Asterisk world, most of the time, the UA should be listed in the sip.conf configuration file before a registration message could be received. If your configuration is good, but the UA is still not in the directory, you can use the debug mode in the sip part. It is also possible to use a network analyzer if you have access to the network layer.

Here below is a debug trace taken on the Asterisk CLI with an UA trying to register:

asterisk41*CLI> sip set debug ip 192.168.16.181
<--- SIP read from 192.168.16.181:38192 --->
REGISTER sip:192.168.16.40 SIP/2.0
Via: SIP/2.0/UDP 192.168.16.181:38192;branch=z9hG4bK-d87543-2365443e5f277647-1–d87543-;rport
Max-Forwards: 70
Contact: <sip:not_good@192.168.16.181:38192;rinstance=b4480613d7542907>
To: “soft 2″<sip:not_good@192.168.16.40>
From: “soft 2″<sip:not_good@192.168.16.40>;tag=e474c93c
Call-ID: OTkwODU3ZjUwNjAyYmU4ZTk2OWM2MTdmYjE3ZTk3MGU.
CSeq: 1 REGISTER
Expires: 3600
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
User-Agent: X-Lite release 1011s stamp 41150
Content-Length: 0

<— Transmitting (NAT) to 192.168.16.181:38192 —>
SIP/2.0 404 Not found
Via: SIP/2.0/UDP 192.168.16.181:38192;branch=z9hG4bK-d87543-2365443e5f277647-1–d87543-;received=192.168.16.181;rport=38192
From: “soft 2″<sip:not_good@192.168.16.40>;tag=e474c93c
To: “soft 2″<sip:not_good@192.168.16.40>;tag=as4f1da0ea
Call-ID: OTkwODU3ZjUwNjAyYmU4ZTk2OWM2MTdmYjE3ZTk3MGU.
CSeq: 1 REGISTER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Length: 0

Asterisk is receiving a REGISTER message but the proposed contact (not_good) is not specified in the sip.conf, therefor Asterisk answers back with a 404 not found message².

Conclusion

The SIP REGISTER method is used to register mobile clients (UA) in the internal routing directory. The stored informations allow resolution of IP information versus UA identifier. This registration method is mainly used when clients are using temporary IP addresses, like in a DHCP domain. Mainly IP phone are using the registration, but also any IPBX when talking to an IP centrex. The IP telcos are using the registration in order not to maintain voice routing tables and not managing IP addresses of their customers who can use any kind of Internet provider.

Registration is useless whenever the other peer is well known with regards to IP informations, in that case we are talking about call routing and tables are static. This is mainly used for PBX trunk interconnections, gateways and SBC³.

Asterisk is implementing the SIP registrar server feature and clients can registered themselves to Asterisk in order to be reachable. But Asterisk can also register itself to another registrar, in that case it is acting as an standard UA. The sip.conf configuration file is the place where can be configured both aspects: each client in a dedicated section and each registration using the register => syntax.

1. SIP devices should support both UDP and TCP, but… [↩]
2. you can see here that the return code is similar to the HTTP page not found code web servers are returning when a browser tries to access an unknown page [↩]
3. Session Border Controller [↩]

Principle

The main components of our solution are: an IVR for managing presence (here room occupancy), the internal Asterisk database to keep track of the status. The room supervision (kind of busy lamp over the door) is available either through a phone call or through a SIP subscription, this last feature allows to have a lamp on your phone showing the room free status in real time, cool isn’t it?

How it works

Here are the main points on how it works:

• we create a specific extension for each room, this extension will be used to manage the room and get the status through BLF¹.
• when calling the room extension, if this one is free, a security code is asked to the user. This code will protect any further operation performed during the reservation period. The next information asked for is for how long the room is reserved, this value is entered in minutes. Both information will be stored in the Asterisk internal database.
• once the room is reserved, we change the status of the supervision field (BLF) and create an automatic call (placed in the Asterisk outgoing spool) which will free the room when reservation period will be expired.
• if ongoing reservation needs to be changed (either to free the room sooner or later), one can redial the room extension, re-enter the security code and specify a new number of minutes for the reservation period. If 0 is entered, the room is freed immediately.
• if one calls the extension when the room is already busy, he would not have the security code, by pressing # he will get an announce of the time when the room will be free.
• when reservation period expires, the automatic call is placed and the room status is changed to free as well as the BLF indicator, everybody supervising this status could thus be informed about the new status.

Room busy lamp

We already have talked about the BLF in a previous article, for more information please see “Asterisk and line supervision“. Here we are not supervising a phone line but someting virtual. For this purpose we are using the DEVSTATE function developed by Russell Bryant.

This function is available in the 1.6 Asterisk release, it is necessary to install it manually for the actual 1.4 release. This installation is easy but requires a recompile, the make menuselect will prepare the compile after the function source has been installed in the function directory. Source file is available directly at Digium.

Code

The proposed application is mainly based on the dial plan of Asterisk. We have created a specific extension file with this application, it is thus easier to manipulate an include in your dial plan if you want to test it.

Dial plan

In order to insert the application in your dial plan, you can simply include the following lines in your extensions.conf file:

; ------ MEETING ROOM START
#include conf/meeting-room-status.conf
include => meeting-room
exten => 638,1,Set(_ROOM=room_chicago)
exten => 638,2,Goto(meeting-room,s,1)
; ------ MEETING ROOM END

Here we set the ROOM variable to the name of the meeting room associated to the extension 638. The room name will be used as key for the internal database and as the name of the virtual lamp to be monitored (hint) by SIP phones.

Line supervision

Since we are not supervising a standard line, we need something special. Here we are using a custom hint, provided with the DEVSTATE function, the syntax to add to your extensions.conf file is the following:

exten => 638,hint,Custom:room_chicago

The name of the room should math the ROOM variable seen previously. The extension is the one used to access the application.

How to install

First you need to download the package we propose, see at the end of this article for the link. Untar the package on your Asterisk server and proceed with the following actions:

• copy the directory sounds/meeting-room into /var/lib/asterisk/sounds
• copy the directory conf in /etc/asterisk, it contains the specific dial plan in the file called meeting-room-status.conf
• copy the shell script agi/meeting-clean-at.sh in the directory /var/lib/asterisk/agi-bin. This script is creating the .call file allowing the automatic room cleaning at the end of the reservation period.

Room IVR manager

If you are interested in how the dial plan is working for our application, here are some information. The format used is from Asterisk::Configure but does not require any particular knowledge but Asterisk one. The code is not complete, you can look at the one provided with the package for the full version, in the src directory.

Reservation

file meeting-room-status.conf {
     context meeting-room {
          exten s {
             Answer()
             GotoIf($[${DEVSTATE(Custom:${ROOM})} = BUSY]?%%RESET%%)
             Playback(meeting-room/this_room_free)
             Playback(meeting-room/enter_code_to_lock)
             Read(lock,,8,1)
             Set(DB(meeting-room-reservation/${ROOM}/lock)=${lock})
%%RESERVE%%  Playback(meeting-room/minutes_room)
             Read(min,,3,,1)
             GotoIf($[${min} == 0]?%%CLEAN%%)
             Set(DB(meeting-room-reservation/${ROOM}/endtime)=
  ${MATH(${EPOCH}+${MATH(${min}*60,i)},i)})
             System(/var/lib/asterisk/agi-bin/meeting-clean-at.sh ${ROOM}
  ${STRFTIME(${DB(meeting-room-reservation/${ROOM}/endtime)},,%m%d%H%M)}
  ${lock})
             Playback(meeting-room/you_reserve_room_until)
             DateTime(${DB(meeting-room-reservation/${ROOM}/endtime)},,R)
             Set(DEVSTATE(Custom:${ROOM})=BUSY)
             Hangup()

This first part is about managing the room reservation. First we verify this one is currently free, then ask for a security code stored in lock. We then ask for the reservation period, this value is expressed in minute and stored in min. These values are stored in the Asterisk internal database, the end time is calculated from the actual time incremented with the minutes entered.
The script meeting-clean-at.sh is called, it will prepare a .call file that will generate a call to clean the room reservation at the end of this one. In order for this call to be placed at the appropriate time, we change the unix time of the file prior placing it in the outgoing directory.
We indicate to the calling user what is the ending reservation time and set the busy lamp indicator for this room. Any supervising phone will be informed the room is now busy.

Modifying or checking reservation

%%RESET%%    Playback(meeting-room/room_busy)
             Playback(meeting-room/consult_code)
             Playback(beep)
             Read(lock,,8,1)
             GotoIf($["${lock}" != "${DB(meeting-room-reservation/${ROOM}/lock)}"]
  ?%%BADCODE%%:%%RESERVE%%)
             Hangup()
%%BADCODE%%  Playback(meeting-room/room_reserved_until)
             DateTime(${DB(meeting-room-reservation/${ROOM}/endtime)},,R)
             Hangup()

If the room is currently occupied, when calling the room extension, the security code is asked for. If you have it, we consider you can change the reservation and use the same process as expressed previously. If you don’t have the security code, the IVR will announce the ending time of the reservation.

Automatic clearing

          exten clean-room {
             GotoIf($["${lock}" != "${DB(meeting-room-reservation/${ROOM}/lock)}"]
  ?%%RCLEAN%%)
             GotoIf($[${DEVSTATE(Custom:${ROOM})} != BUSY]?%%RCLEAN%%)
             GotoIf($[${MATH(${EPOCH}+60)}>
  ${DB(meeting-room-reservation/${ROOM}/endtime)}]
  ?%%CLEAN%%)
             Hangup()
%%CLEAN%%    Set(DEVSTATE(Custom:${ROOM})=NOT_INUSE)
             Set(foo=${DB_DELETE(meeting-room-reservation/${ROOM}/endtime)})
             Set(foo=${DB_DELETE(meeting-room-reservation/${ROOM}/lock)})
             System(rm -f /var/spool/asterisk/outgoing/call-meetingroom-${ROOM}-${lock}-*)
%%RCLEAN%%   Hangup()
          } 

From the .call file place in the outgoing directory, a call is placed at the end of the reservation period to the clean-room contexte. This one will check the security code (passed as a parameter in the call) and the current time that should be after the reservation end time. If these tests are successful, the busy lamp for the room is cleared as well as the database. The room is now free.

Download

Our solution is available here. If this application was helpful, please let us know through an email or a comment.

Conclusion

Once more a small Asterisk application, using only dial plan and standard Unix commands, can help a lot in the real world. For sure you can modify the concept for any other usage that you may have in your organization.

1. Busy Lamp Field [↩]

Intercom

First, an intercom call is used to push message to a specific location represented by a phone, this call doesn’t require a human intervention since the phone switch it automatically to its speaker mode. In order to implement this feature in an IP phone, the solution is based on a specific SIP header added in the INVITE message. Whenever the IP phone is configured to evaluate this field¹ it accepts automatically the call. Generally the intercom call is presented to the user by a specific ring in order to capture his attention and the microphone is automatically turned off (see also Volontary bug in some SIP IP phones?).

But the intercom feature is not normalized, thus all phones are using something slightly different, it will be important to change the sent message with regards to the IP phone that will get it. The information should be available in manufacturer documentation but is most of the time not easy to find.

Conference bridge

Asterisk is integrating a high value application with its conference bridge one, called MeetMe. This application, using the Zap modules, allows a call to have more than two extremities, it mixes voice and send the mixed flow to each phone.

The solution used in our implementation is to bridge the message call to a bridge with all IP phones that should play the message in intercom mode. In order to limit noise, the talker is unique and can only talk and all intercom phones are in listen mode.

Proposed solution

We are using a dedicated conference room in our solution (the 99) since we would like to have an authentication phase for the speaker. This could be changed towards dynamic rooms if authentication is done outside or simply suppressed. If more than one intercom group would be required, multiple rooms will be provisioned.

First the call from the talker is executing an AGI script that will insert all intercom phones in the room, then the talker is pushed to the conference room itself and asked for authentication. The AGI script should push any phone selected in the conference room and in intercom mode, no authentication is required and no action from user behind each phone. Since more than one phone can be selected, the AGI will create as much calls between the phone and the conference room as required. This will be done by creating a .call file and use the outgoing spool feature of Asterisk.

Sources

Conference room

; for intercom
conf => 99,1234 

Here the room is static and protected by a code that should only be shared with people authorized to push a message, the configuration is stored in meetme.conf.

Getting the call

A specific extension is added in our dial plan for the intercom call, it simply is here to redirect the call to a specific context called meet-talker. In extensions.conf we have:

exten => 635,1,Goto(meet-talker,s,1)

meet-talker context has been created to be able to handle the call closure. Effectively, since using a conference room, when the talker close the call the room should be closed and any intercom phone disconnected automatically.

[meet-talker]
exten => s,1,AGI(push_to_meetintercom,SIP/15,SIP/30)
exten => s,2,Answer()
exten => s,3,MeetMe(99,tq)
exten => h,1,MeetMeAdmin(99,K) 

First we start the AGI script, passing it the list of phone to put in the intercom group, then the talked is directed to the conference room 99 in talk mode only. At the end of the call (h extension), all participants are suppressed from the room with the K option of the MeetMeAdmin command.

The AGI call script

Here written in Perl it doesn’t require anything else but the interpreter. The content of the script is detailed by section:

#!/usr/bin/perl                                                                                                                       

my $outgoingDir  = '/var/spool/asterisk/outgoing';

my %sipHeadersIntercom = (
  "Aastra 5xi" => "Alert-Info: info=alert-autoanswer",
  "Polycom"    => "Alert-Info: Auto Answer",
                          );

my %phones = (
          "SIP/15" => {
              sip => $sipHeadersIntercom{"Polycom"},
              wait => 1,
          },
          "SIP/30" => {
              sip => $sipHeadersIntercom{"Aastra 5xi"},
              wait => 1,
          }
          );
 

First we defined each specific SIP message header that should be sent to IP phone in order to start the intercom mode. Each vendor has its own implementation, thus message are different per phone type, here we have included an Aastra and a Polycom, you will have to continue this table if required.

The second table is a hashed one with any IP phone we have in the installation and that could receive an intercom call. For each extension we have defined the phone type, linked to the first table, and a waiting parameter, expressed in second and which will be used by the dial plan in order to throttle calls².

foreach my $exten (@ARGV) {
    createCall($exten);
}

sub createCall {
    my ($exten) = @_;
    my $id = $exten;
    $id =~ s/\///g;
    my $file = "$outgoingDir/$$-$id";
    open(CALL, ">>$file" );

    print CALL << "EOF";
Channel: Local/start@meet-and-page
MaxRetries: 1
Retry: 0
RetryTime: 1
Context: meet-and-page
Extension: call
Priority: 1
SetVar: TOCALL=$exten
SetVar: HEADER=$phones{$exten}->{sip}
SetVar: WAIT=$phones{$exten}->{wait}
EOF
;
    close(CALL);
}

Next we start the process. Each phone extension passed as a parameter to the AGI script is used to create a .call file by the function createCall. If a lot of phones are used we could maybe change the approach towards a data base oriented one.

createCall function is creating the .call file which will connect the IP phone in intercom mode and the conference room. The way .call file is working is simple: first a call is created by Asterisk to the Channel one and when this one answers the call, connect it to the Context/Extension/Priority one. We should take care of having the first extremity answering the call automatically, this is why we direct the call to the conference bridge. The Local/start@meet-and-page is used to connect the conference room directly.

The second extremity of the call should target the IP phone but the call requires the specific SIP header in order to toggle the phone in intercom mode. We decided to use a context in the dial plan to perform this action, thus passing back from the AGI the required information in specific variables: TOCALL is the IP phone extension and HEADER is the SIP header to add for the intercom mode.

Each .call file is saved in the spool directory and will be interpreted by Asterisk automatically, nothing special is required for this part.

Intercom call in the dial plan

Now that the .call file is created, we need to build the specific dial plan parts. Here is the one handling the conference room call and the IP phone call:

[meet-and-page]
exten => start,1,Answer()
exten => start,n,MeetMe(99,mql,1234)
exten => start,n,Hangup

exten => call,1,SIPAddHeader(${HEADER})
exten => call,2,Wait(${WAIT})
exten => call,3,Dial(${TOCALL},2)
exten => call,4,Hangup() 

The start part is the first to be called and target the MeetMe application, here executed in listen mode and passing the access code automatically.

The call part is targeting the IP phone. First we need to add the SIP header specific to the called phone, then dus a simple Dial() command to place the intercom call. This part is using the variables set by the AGI script.

Conclusion

Here is a simple approach of an intercom call pushed to a set of IP phones, you would probably have to adapt this to your own usage and need. But it demonstrates that Asterisk is a very good solution to specific user requirements with only out of the box application and small dial plan adaptation.

1. some are doing this by default, some don’t [↩]
2. we have seen some phones blocking the intercom if message was sent too fast [↩]

First, we should start this article with the fact this product is really a good one. Most standard features available on a PBX are available and if the target is SOHO and small organisations, you should give it a try. The installation is really simple and no need to have deep knowledge in voice over IP to get its first voice network up and running.

For sure, this free edition is not proposing everything we can think about, but some additional products are available and the cost stays low. Some could prefer to this implementation a more opened one, like an Asterisk based one, but this product is doing the job for most of our needs and is fully integrated, no installation hassle.

If you don’t require an advanced computer integration or API development, it could be a nice way to jump in IP telephony at a reasonable cost. You just need to add some IP phones or softphone and a SIP provider over the Internet or a gateway to get connected to the PSTN, that is all.

You will find in the following table some more information about the product and some of the test we have conducted on it. We got some help on specific topics directly from the forum, but most features are easy to set up. Don’t hesitate anyway if you got question to drop us an email.

1. seen on the web site as a possibility [↩]