Step by step configuration of the SIP stack on the Nokia N93

Now that I finally found a free screen capture program that supports the Nokia N93 (thanks to the excellent 3lib page and to Antony Pranata for his free tool which really works on S60 3rd edition), I can finally include screen shots of the N93 to support this step by step guide.

Before jumping into the SIP stack configuration, I am using WiFi to provide the IP connectivity for the SIP stack and therefore a WLAN access point needs to be configured. This procedure is pretty straightforward once you know where to start :)

1. Go into the "Connectivity" screen and select the "Conn. mgr."
2. Select "Avalab. WLAN" to browse the available WLAN access points
3. Select the WLAN access point you would like to configure and then select the menu option "Define access point" to configure that access point and make it available to applications requiring a data connection.

Once the access point is configured, Go to the "tools->Settings" application to setup the SIP stack.

1. Select "Connection"
2. Select "SIP settings"
3. Select menu "Options->Add new" to create a new SIP configuration either using the default profile or an existing profile. This should open the configuration settings for the new profile where we will setup the stack parameters as well as the proxy and registrar servers.

4. Give a name to the profile, select IETF as a service profile for the SIP stack and select an access point to be used for the data connection. This could be the WLAN access point configured just before.
   Setup the public user name of the SIP user that will be used in sessions created via the SIP stack. This public user is in the form of a SIP URI (sip:user@domain).
5. Do not use compression or security as this will activate SIP header compression and secure connections which require special features in the SIP stack on the other side (network) unless of course you need them and you are sure that the servers on the other side support them.
   Leave the "Registration" option as is for now.
   
6. Select the "Proxy server" option to setup the proxy.
   

7. This will open a new screen that allows to setup the parameters for the SIP proxy available in the network.
   Setup the proxy address using a SIP URI in the form of "sip:hostname|address" where the host name or the IP address refer to the proxy server.
   Setup the real name for SIP authentication. This is in general the same thing than the domain name for simplification but can be different.
   Configure the user name and password used for the SIP authentication. The user name can be the same than the user part of the public identity or a completely different name. Just make sure that this corresponds to the user configured at the proxy level or at the HSS in an IMS network.
8. Set the "Allow loose routing" to "Yes".
   Make sure you use the "TCP" transport for the SIP connection and set the port number according to what the proxy/CSCF configuration. The UDP transport has problems and does not work. If you find out why or how it make it work, please let me know.
   

9. When done with the proxy configuration, select "Back" and then "Registrar server" to also setup the registrar. Without that, the SIP stack will not be usable.
10. Setup the registrar address using a SIP URI in the form of "sip:domain" where the domain corresponding to the domain name/security real for the SIP servers. Note that contrarily to the proxy server, you do not need (and it will not work if you do so) to specify the server address. The reason is that the REGISTER messages sent by the stack will actually go through the proxy and not directly to the registrar. Traffic routing rules (like Initial Filter Criteria in the CSCF) will proxy that message to the appropriate registrar.
11. Configure the user name and password used for the SIP registration. This is in general the same name used for the SIP authentication.
12. Make sure you use the "TCP" transport for the SIP connection and set the port number according to the proxy/CSCF configuration (see step 8 above).

When done with the proxy and the registrar configurations, the stack is ready to use and we can test that by requesting an immediate registration with the SIP network. To do so, you can go back to the SIP profile configuration and change the "Registration" option to "Always on". That will have the effect of immediately attempting to register with the network.

If things go wrong, check again the proxy address, port number and that it does support the TCP transport. Check the user name and password used for the proxy authentication and the registration and that the user is actually configured at the proxy/registrar/HSS.

When nothing helps, there is still ethereal (wireshark as it is called now) that can be run at the CSCF/proxy level to capture the traffic and analyze the SIP messages sent by the N93 to the proxy.

This will still not allow you to make VoIP calls with the N93 unless of course you have a SIP phone client that runs on the S60 3rd edition, but that will be another story...

Initial review of the Nokia N93 VoIP features

The Nokia N93 is clearly one of the most advanced 3G phones available in the market as of today. It comes with an extensive connectivity support via GSM, WCDMA, WiFi, Bluetooth and Infrared connections. One of the most interesting features that made me buy this phone is the availability of WiFi along with a SIP stack. Do not expect however that setting up a N93 for VoIP calls over WiFi is for common mortals. It takes some serious hacking to finally get the WiFi connection up and running and the SIP connectivity configuration to work correctly.

The first thing that seemed unnatural to me is that the WiFi connection setup is not as you may expect part of the "Connectivity" set of configuration applets but rather part of the "Tools->Settings->Connection->Access points" screen. I would say that Nokia did a really good job making it so difficult for users to find that configuration screen. One you got that, it is a pretty usual way of setting up a WiFi connection. I have only used it with WEP security and it worked fine for me in that mode. Surfing the web over WiFi from your N93 is great and I thought that Nokia did a great job with the integrated web browser in their 3G phones.

As the N93 comes with a complete SIP stack that is supposedly ready to allow you to use the N93 over an all-IP network to establish SIP sessions for voice calls and other SIP based interactions, it immediately assumed that such a thing would work pretty fine with the WiFi access point. The SIP configuration setup is clearly not an obvious thing for common users but it is pretty straightforward for anyone familiar with SIP network architectures (or 3GPP IMS by the way) and the SIP protocol. Accessible from the same place than the WiFi Access point configuration, you can start using it by creating a new profile.

A couple of things that I found out through ethereal traffic captures and multiple tests in different configurations may save you some time:

1. First and foremost, you can not establish any SIP session unless your registration was successful. Honestly this has nothing to do with the SIP protocol itself but is rather a way of ensuring some control over what things you can do with your N93 phone. Mandatory registration makes it more difficult for common mortals to just use the N93 to make VoIP calls in a P2P configuration without going through a SIP or a 3GPP IMS infrastructure.
2. You can not have a successful registration unless the SIP proxy and the registrar server (or the CSCF) are in the same subnet than the IP address that you obtained via the WiFi access point. Again, this is simply another restriction to ensure that you can not freely use your N93 to make VoIP calls. By restricting the registrar to be in the same subnet than your N93's IP address, you are forced to register with a server in the WiFi service provider's network. It appears to me that Nokia has integrated WiFi and VoIP over WiFi only to meet the needs of enterprise customers for calls made only within the enterprise's WiFi network or for a combined offer of WiFi and other access networks from the same service provider.
3. You need to specify the registrar and the proxy addresses as a SIP URI and not simply as an IP address. The registrar server URI should be "sip:domain" where domain is just your domain name not including the host name. In general this is the same thing than the realm.
   
4. There is no integrated SIP phone client in the N93, so you need to find one or you need to create your own Symbian client :)

I have only tested the IETF profile and not yet the Nokia 3GPP profile of the SIP stack. Soon I will be testing the phone SIP capabilities to establish SIP sessions both in an IETF SIP network architecture as well as in a 3GPP compliant SIP architecture. As I could not find a usable free SIP client, I will be using one of our own IMS application clients for Music Sharing.

Stay tuned....

Designing video applications for 3G users

Several operators in Asia have already launched some form of 3G service and many are going to do so in the near future. A common theme for all of them was the focus on video capabilities as the main driver for why users should adopt 3G and have a 3G mobile phone.

It seems to me that a lot of developers have simply forgotten that using a video application from a 3G terminal is still a visual activity that requires the content to be somewhat pleasant to the eye. Why would a user watch (for more than 1 minutes) a poorly designed video application offering an interactive menu to some streaming video content or a video blog or whatever similar video content that can be delivered to 3G mobile users?

3G mobile screens are still way too small compared to a laptop display or a TV! That requires in my opinion even more care and attention to produce clear and eye catching content for those small displays. But what I still don't get is why are most of the applications currently available still so poorly designed from a visual point of view: bitmapped fonts used to render text over the video screens which do not scale properly when the video size changes, poor color choice that does not make it easy for the user to read the text for the menus, poor use of the scarce real estate offered by the handset small display,...

I really hope that some of those developers will start soon thinking about some of the following methods to improve the visual quality of the video content served to mobile users and to make their experience more attaching:

• Do not use static menus that are already integrated into the video content. Rather than doing that, use dynamic menu generation and rendering overlayed over the video content so that it can be adapted to the display size (font size, less options in one screen,...).
• Consider different options when organizing the display: menu overlay with transparency vs. structured layout of the display.
• Use a professional designer like we already do for web applications, TV broadcasting,...
• Allow for personalization and customization (skins, theme,...) of the video screens to adjust to different user populations and different tastes.

On Internet Explorer and JavaScript memory leaks

I have recently been working on an AJAX application used to manage and monitor a system part of one of the solutions we are creating. Asynchronous events and near realtime updates to the management GUI are nice features to have in such application. I wasted a day or so tracking a memory leak (or apparently so) in the web application client GUI. I thought that it may be useful to share some of the experience and lessons with whom might be interested.

AJAX applications by design rely heavily on dynamic HTML and manipulation of the DOM using JavaScript, so it is not uncommon to see a large amount of the application being written as a single web page with a lot of scripts. This model is fundamentally different from the traditional web browsing experience where each piece of information or user action/result of that action is presented in a new web page obtained from the server. With the old web browsing experience, it is pretty common to open a browser and close it in less than 5 minutes. With AJAX applications however, as the whole application is presented within one single web page, this old model is no longer valid. Memory leaks in web pages, due to whatever broken browser or broken application script, do not really bother the user browsing the web the old way. They do however manifest quickly and in a noticeable way when using a moderately complex AJAX application. In my case, I could get Internet Explorer reaching 120 Mb in less than 5 minutes. That was pretty big and pretty unacceptable, so I decided to track the origin of that leak and fix it.

Understanding where memory leaks in JavaScript come from

It seems that the most usual source of memory leaks in JavaScript comes from the use of closures and event handlers attached to DOM nodes. Basically, most of the asynchronous processing in the application GUI is done by setting asynchronous event handlers on particular events that happen to particular nodes in the DOM. The event handlers are simply JavaScript functions, which could be declared as named JavaScript functions or anonymous functions within closures. The issue with closures is that a closure sees and can use all variables defined in the parent cope (the scope within which the closure is defined), which is a good thing as it simplifies a lot the coding, and a bad thing as those closures now keep a reference to all those variables defined within the parent scope. This situation may result in what is called circular references which cause memory leaks: A DOM node references a closure (which is a JavaScript function, i.e. a JavaScript object) which itself references the DOM node.
A good article explaining those circular reference issues with JavaScript closures has been written by Richard Cornford. You can also have a look at this page by James Mc Parlane which could be easier to understand than Mr Cornford's detailed study on JavaScript closures.
Closures are definitely the main source of memory leaks (in my experience) but are not the only source. Other sources of memory leaks include keeping references to temporary variables in global JavaScript variables (totally useless and very bad programming habit) as well as broken browser implementations like Internet Explorer .

How do I track that leak?

There is a serious lack of JavaScript development supporting tools that are ready for the explosion of AJAX applications and dynamic web pages. There is no memory profiling tools, no JavaScript heap walking tool, not even a simple dumper of the JavaScript heap which produces a readable format. Even mozilla and firefox lack such extensions... To be honest and fair with IE, the only decent tool I found that could help a little bit in tacking the leak source is an IE only tool called Drip.
Another useful tool that does not tell where your memory leak is, but at least can help you see if you have a memory leak or not is SysInternals free Process Explorer tool. Because it can accurately show the process memory usage, it can help in watching if the browser memory increases over time while using and reusing the application JavaScript code.
Of course, you need to have two or three running web browsers to compare and see (only guesswork) if the leak is really coming from your application code or from the broken browser. I usually run with mozilla or firefox or both and IE 6 or IE 7 or both.

Fixing the code won't always make the leak disappear at once

After reviewing all my JavaScript files, preparing memory stress tests and all, I basically managed to eliminate the leaks when using browsers like firefox or mozilla, but still see Internet Explorer memory growing as I use the application and run the test cases. It is absolutely frustrating and time consuming to find why this continues to happen with IE. At one point in time I almost commented out all the code of one of the JavaScript classes that was causing leaks in IE, and run the test case with the minimum required code to have at least some form of the object being used in the browser. The amazing thing is that the leak was still there. I just became crazy with IE, trying to figure out why would a DIV added to a parent DIV then removed cause a memory leak. There were no event handlers, no closures, nothing!
After some googling, I just came across some page recommending not to use removeChild DOM method on a DOM node with IE as it causes some "pseudo-leaks". Now this is a really dumb implementation of the most popular web browser in the world. Why would a method that is documented as removing a DOM node from the DOM tree not make that object garbage collectable and clean it up? Well, not in the IE world! All DOM nodes removed from the DOM tree with removeChild calls stay there until the page is unloaded. I do not know why, but I know for sure that if you reload the page or load another page, the memory is claimed back.

In conclusion, I could not manage to get IE memory not to grow constantly while using the application, but I decided that it is not worth to artificially reload the page from time to time to get rid of that growing memory with IE. It was better to keep a design of the AJAX application that works with most non-broken browsers and requires a page reload after a 100 uses of the application with IE.

Anyway, I was disappointed not to find an ultimate solution for this problem, but I understood quickly (thanks to the many other people who faced the same issue) that there is no such solution with IE .