Location over IP

Locating IP calls is becoming an increasingly important subject

  • More and more persons and companies are equiped with VoIP access
  • Service provider as us may be interested or required to provide video call access to emergency services.
  • Our participation to the REACH 112 European projet put this kind of discussion in front of the issues to address in order to provide good emergency services for deaf population.

The transport of location information is already well described and standardized by IETF and the ECRIT commitee and is using XML format (how verbose!) called LO-PIDF. Its handling in SIP protocol is decribed in the following draft: location conveyance.


Finally, telecom authorities are starting to take noice and OfCom, the British regulator has produced a fairly comprehensive report about this. Good reading.


Hassle with SIP ALG in routers

As part of our services, we perform a lot of videotelephony deployments into homes of private persons. These are connected to the Internet using DSL lines or cable modems. More and more links comes with a router provided by the ISP.
We are starting to notice that more and more of these routers include a SIP Application Gateway Layer which aim is to facilitate NAT traversal for SIP and RTP protocols. In some sophisitcated routers, such ALG also triggers dynamic firewall opening for RTP conversations. Our experience is that such piece of software often prevent the SIP communication to operate. Here are the cases that we encountered:

  • SIP ALG does not support loose routing: the ACK message is not sent back and the SIP dialog cannot be establish. Typically, the communication is only one way and/or it drops after 30 seconds.
  • SIP ALG does not support a call procedure or such or such primitives: ex 183 Session Progress is not supported or in dialog MESSAGES or INFO are dropped.
  • SIP ALG only support SIP infrastructure where SIP and RTP comes from the same IP addresses, which forbid any kind of load balancing on the server side.
  • Some older CISCO firware also corrupt the TCP packets (when using SIP over TCP).

We believe that given the fact that it is very difficult to find some competent people capable of troubleshooting this on the router side. Even though, obtaining a firware correction and applying them to ISP branded modems is nearly impossible. This leaves us with a simple message to all ISP and router vendors:
Please please, Mr router, include a menu tp disable the ALG


Side by Side ... follow up

I was surprised by the publication and the number of reactions of what was a simple technical article. It convinced us to share more broadly the technical issues and solutions that we encounter on this blog in the future. In the meantime, I would like to comment on the comments.
Some people wrote "This guy is clueless about Microsoft. It is written that the needed DLLs must be shipped with the C++ application.".
Maybe we should be more explicit about our application: this is a Web plugin. It needs to be installed fairly automatically. So we cannot ask every user to run vcredist.exe on his PC. What if you needed to do that to install Flash ! And we did try a number of things:

  • We tried to ship the DLL as a private assembly. It would not work because of the strange conflict mentionned in the previous post.
  • We tried full static linking. Our plugin GUI because strangely unresponsive and slow.

Some others said "It's a non-story"
It is. Otherwise it would not have caused so much reaction and Ted and others would not have patiently proposed some solutions. Why is there NO article on MSDN on this topic?


Microsoft DLL hell 2.0: the Side by Side assemblies

This not just a rant against microsoft but a pratical article for all developpers using Microsoft Visual Studio 2005 to build their product.
At the beginning of August 2009, Microsoft issued a security patch KB971090 on its Microsoft Visual Studio 2005 product: the result was that when we recompiled our plugin with this updated Studio, it would not run on other PCs. The symtoms were:

  • Our ActiveX would not register on the system, complaining that the CRT or MFC assembly could not be found (to be detected by opening the Event Observer).
  • Our Fireforx plugin would not load.
  • If you have a standalone application and have upgraded to Internet Explore 8, you may have the complain that IESHims.dll is missing.

You can easily confirm the issue by configuring your project to generate an external manifest for your application and see if you have someting like:

version='8.0.50727.4053' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />

In your manifest.
Hopefully, some smart people suggested four solutions:

  • Install the vc_redist.exe to be found in c:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\BootStrapper\Packages\vcredist_x86 on every customer's PC. Not very convenient.
  • Remove the security fix KB971090. This is what we did.
  • Some other people like Ted, proposes a method to force the use of build 762 (the previous version used by Visual Studio 2005) but we could not make this work properly.
  • Finally, it was also suggested to ship this 4053 build as private assemblies. We ran into other isses that are detailed below.

We also noticed that some client PCs running Windows Vista had updated build 3053 (not 4053) and when we tried to ship build 4053 as private assembly, Windows complained that the two assemblies were in conflict (although we were shipping the MFC and CRT as private assemblies). This conflict message was so undocumented that nobody seems to have encountered the situation. So the simplest solution was to remove this security fix.
I am not sure this is sustainable when Windows 7 will start to be around ...


Skype founders may bring skype to stop by revoking technology licence

Slashdot has an astonising new about Skype:
It appears that when Skype was bought by eBay from the small amount of 2.8 billions USD, the intellectual property of the peer to peer core technology behind skype has not been transferred but there has been a simple licence agreement between eBay and Skype founders Niklas Zennstrom an Janus Friis
The fact is that Skype founders are threatening to revoke this licence with a small consequence: it may force ebay to stop Skype. How could eBay executive shed 2.8 B$ and not have at least shared intellectual property on the technology?
Some people analyze the situation as follow. The skype founders started another project with Joost and it was not successful. They tried to buy skype back at a much lower price. This last move has been seen as a way to make it happend.


There are two lessons to be drawn from this story

  • use open protocols in telephony.
  • if you buy a company for a good price, buy it ALL.

SIP domains: advanced DNS features

Today, we have migrated our main DNS domains to our own DNS server running bind.
This action was not done just for pride of running our own DNS but out of necessity. I would like to give some insight about the advanced DNS features that needs to be used to setup a proper sip domain.
Any SIP service provider like us needs to operate one or more SIP domains in a professional way. Each of these SIP domain is associated a DNS domain to provide the following features:

  • Internet wide URI resolution
  • Proxy load sharing and redundancy
  • Public / private network support


Internet wide URI resolution

An IVeS subscriber is identified his/her SIP URI e.g. Cette adresse e-mail est protégée contre les robots spammeurs. Vous devez activer le JavaScript pour la visualiser..">Cette adresse e-mail est protégée contre les robots spammeurs. Vous devez activer le JavaScript pour la visualiser.. How is the domain part (here "") translated into the IP address of the SIP server to use?
All the process is described in the RFC 3263: Locating SIP servers.
To give a simplified explanation, this is done in three steps:
The calling User Agent (UA) sends an "SRV" DNS question to the domain specified in the domain part of the URI. The domain answers with a list of records (it is advised to use A recornds) with priority, weight, etc.
The A records gets translated in IP addresses. The UA selects one of the server in the list according to a well defined algorithm and can send the SIP packet to the selected address.
In case the initial SRV request fails, many SIP User Agents fallback to simple "A" DNS requests.
It is to be noted that the process is very similar to mail server location using MX DNS records.
If we were running a closed garden network where our subscribers would only be capable of calling between themself, this would not be very useful but as our philosophy is to aim to interconnections with other SIP domains, this is a must.


Redundancy and load sharing

The standard unables to define more than one SIP server per domain and per transport protocol. Furthermore, a priority and a weight can be indicated. The SIP user agent selects the actual server during the first resolution and stick to it until a failure (timeout or server failure) is encountered. This is a very elegant mecanism that enables failover and load sharing Internet wide.

The most difficult part remains to implement true redundant SIP servers, but tha'ts another story.

Public / private network support

We run our network both on the public Internet and a private network (an IP VPN). In order to do this, we leavageage the "view" feature of bind to serve the same names as different IP addresses depending if the user is connecter on the Internet or on our VPN. This is not part of the standard but very useful.

Quick cookbook to setup a SIP domain

Define your SIP proxy/regsitrar servers as A records in your zone file using names that represents the hosts themselve
server1 IN
server2 IN
Define the SRV record for each supported transport protocol (here TCP and UDP).
_sip._udp SRV 0 5 5060
_sip._udp SRV 0 5 5060
_sip._tcp SRV 0 5 5060
_sip._tcp SRV 0 5 5060
Also, the standard mandate that the domain holds NAPTR record in order to notify the transport protocol preference.
@ IN NAPTR 0 0 "s" "SIP+D2U" ""
@ IN NAPTR 1 0 "s" "SIP+D2T" ""
It is advised also to have a simple A records that is resolved with multiple IP for UAs that do not support SRV resolution.
sip IN


Conclusion : we did not find any hosted services capable of providing the level of required feature to host such DNS domain. My advise: run your own bind server.


SIP as a foundation for building modern interactive Value Added Services

Continuing my thoughts about value added services in a SIP world, I’d like to complete my idea about this subject by defining an interactive service and briefly talking about what enabling technologies and protocols are available.

So how do you define an interactive service ?

I believe an interactive service has 3 main components:

  • Enables users to interact with the service or other users in real-time by an online interaction.
  • Utilizes “presence”.
  • Allows the service logic (or backend application) to send unsolicited events to the user or subscriber.

IM services like Skype, MSN and Yahoo Messenger, etc., are perfect examples of this type of service. Note that interactive services are not a new concept and many BBS in the 80s or the 90s or even terminal based services on the French Minitel used these principles already. Except that at this time there was no video transport and very crude UI and protocols. And let’s not forget that an interactive value added service willl be the combination of both interactive and value added service.

What technologies and protocols enable us to produce interactive services then ?

I can summarize them like this:

  1. A user interface technology.
  2. A set of protocols to download the user interface, authenticate the user and provide a two way interactive conversation composed of media (IM, audio, video), server events and user commands.
  3. Application servers that implement the business logic and protocol connectors to interact with clients.
  4. Billing servers.

For now let’s focus on items 1 and 2. For these items there’s an obvious choice: Adobe Flash. It is a widespread UI technology and it has interactive functions provided by Flash Media Server. However, control and media transport use a proprietary protocol called RTMP based on TCP and a proprietary video codec On2. This severly limits the interoperation with other infrastucture.

We also studied the MPEG4 framework that has provisions for client/server interactive services. However, there is no known implementation of this.

Another choice was Microsoft: they prepared an alternative with XAML and its offer Microsoft Live Communication Server but it will be deployed with Vista. It will take two years for Vista to be supported enough to build mass services and we believe that HTML, Ajax will be in place already and it will be extremely difficult for XAML to take over.

Given these constrains, we decided to stick with “the triplet”: HTTP, HTML and Ajax and combine them with these great protocols:

  • XMPP: It is a very tempting choice because it has all the primitives and the extensibility built-in.
  • SIP: which provides a very good interoperability with the existing telco infrastructure.

Finally, at IVèS we chose SIP because of the reasons stated above. Without being too specific, the fact is that the MESSAGE primitive can be used for IM services, the INFO primitive can be used by the user to send commands or receive events and thus a SIP presence server can be created.


Creative Inperson

inpersonCreative inPerson is a wireless H264 videophone compliant with IVèS services.

Here are product specifications :

802.11b/g WiFi and Ethernet, 76-degree wide-angle lens with "excellent low light performance," H.264 video with SIP support, rechargeable/removable Li-ion battery, remote control, headphone jack for privacy, and TV-out to view callers on a larger display. The battery can be charged in 5-hours for a 2-hour run when using the built-in, 7-inch, 16.7 million color LCD at 50% brightness. That lifespan increases to about 5 hours when sending the display to the TV. It's also fully integrated with SightSpeed accounts.


Mobotix SIP camera

mobotixMobotix is a German IP camera manufacturer.


They propose an innovative range of SIP camera integrating Linux operating system and mobotix software. Such cameras are proposed in IVèS video device catalog thanks to SIP/RTP interface proposed by Mobotix.


REACH112 - accessible emergency through video telephony

REACH112 project is ment to install and trial video telephony for emergency services. The project is part of the CIP European project and involve a three year trial of Total Conversation (Video, audio and text) solution embedded in emergency services.
The consorsium that setup the project is composed of major telecom operators such as Orange and Vodaphone, video telephony platform provider, video such as IVèS, Aupix and Omnitor and of course several public emergency services (Emergency services of Grenoble, France; Emergency Agency of Galicia and Fire and Rescue Dpt of Avon and Summerset.

The project has been submitted to the european commission on September 10.