BLOGCategorie :: TechnologiesAs 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:
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
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. 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 resolutionAn IVeS subscriber is identified his/her SIP URI e.g. 60606060@visioassistance.net. How is the domain part (here "visioassistance.net") 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:
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 sharingThe 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 supportWe 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 domainDefine your SIP proxy/regsitrar servers as A records in your zone file using names that represents the hosts themselve server1 IN 212.1.1.10Define the SRV record for each supported transport protocol (here TCP and UDP). _sip._udp SRV 0 5 5060 server1.mydomain.com.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" "" _sip._udp.mydomain.com. @ IN NAPTR 1 0 "s" "SIP+D2T" "" _sip._tcp.mydomain.com. 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 212.1.1.10Conclusion : 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. 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:
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:
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:
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.
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. |