2010 January

January 2010


Let’s change everything – and cause no damage for the end users!

The current version of the Internet is up for a big overhaul. We have to change the whole infrastructure it runs on, the famous IP protocol. A lot of work needs to be done and it affects everyone that works with the infrastructure. The result of all the hard work? Everything will work exactly as before. Nothing gained for the end-user experience. That’s why very few are paying attention to IPv6. It is very hard to convince the persons in charge of IT projects what the benefit is compared with upgrading all PCs to Windows 7 or installing that new spam filter for e-mail.

Internet telephony needs IPv6 peer-to-peer addressing

It is easy to explain the need for a unified address space using telephony as an example. The fact that all companies and homes use a private address space that can’t be reached from the outside doesn’t matter when it comes to the old-fashioned Internet applications. The web browser contacts a server on the Internet. The e-mail client contacts an e-mail server on the Internet. The IM/Presence application contacts a server on the Internet. Nothing needs to reach in. Until you start using peer-2-peer applications. And telephony is a very common p2p application.

  • -”You know that you have a broadband router that use one IP address from the Internet, assigned to you by the provider?
  • “- “Yes”
  • - “Do you also know that the broadband router let’s all your devices on the inside share this address by setting up a private address range that can’t be reached from the outside?”
  • - “Yes”
  • - “If you add an IP phone on the inside – do you want to be able to receive calls?”
  • - “Yes”
  • - “How do you think I can call your phone  directly, if we don’t share the address space?”
  • - “I don’t know.”

With IPv6, true p2p Internet telephony will become possible. When we get rid of the need for NAT, network address translation, we can finally separate access and policy. With a unified address plan, every device on the net has the possibility of reaching every other device. Policys might prevent access and we implement these in a firewall software in the systems or in dedicated systems.Currently, in order for a phone to work on the inside of a NAT, most implementations connect to a server on the Internet. In order for an incoming call to get through, the phone or the server keeps sending empty messages. As long as these messages are sent – occupying unneeded bandwidth and resources in the network – the NAT believes there’s a communication session going on and let the messages in. The NAT itself has no policy, it just checks if there’s a client-initiated session going on or not. As long as the NAT believes there’s a session, it will forward packets from the outside to the inside device. When you have an incoming call, the server can forward an alert to the phone and the phone will start ringing. The same setup is used if your organization has a PBX system on the inside and use a SIP trunk provider on the Internet.This solution is used by a range of applications and are not unique in any way for IP telephony.  IPv6 will make it easier to enable true Internet telephony and other p2p applications, as long as your firewalls let it happen. (more…)

I’ve created a test branch for patches hidden in several Asterisk development branches – all based on Asterisk 1.4

  • RTCP improvements from pinefrog-1.4
  • “Sip show chanstats” cli command
  • The branch pinequality-* giving you the manager “sipchannel” event to check QoS

This branch is now open for testing and I need feedback. Among the improvements you’ll find:

  • Manager QoS events during a call and after a call
  • Improved RTCP – it now works for p2p bridge in RTP, which means that we will get RTCP stats for many, many more sip calls
  • RTCP over NAT improvements – if Asterisk is behind NAT, we will now kick-start RTCP from the remote end by sending a first “emtpy” RTCP packet to open a NAT port.
  • QoS reports to realtime storage after each call – one report per call leg (The amount of data and the names will change)

The reason that I store  QoS data in realtime, is that the CDR is usually gone or frozen at the time that we freeze the RTP channels and get the last QoS data. The QoS reports can’t thus be included in CDR, you have to merge it in automatically later in your database.There’s still a lot to do, but please test it so I get some sort of feedback.For testing, don’t forget to run the “rtcp debug” cli command so you can see what’sgoing on in the RTCP channel.

FAQ

  • Yes, this work will be ported to trunk and hopefully merged soon.
  • No, we don’t support RTCP XR or MOS in this work
  • No, I have no reason or funding to adapt it to 1.6.x at this point.
  • No, the RTPAUDIOQOS channel variable is not changed. You will get more data than before – for many more calls.

This work is funded to 20% by companies in the community. If you want to cover the80% that’s still not funded, please contact me by e-mail: oej@edvina.net.
URL:  
http://svn.asterisk.org/svn/asterisk/team/oej/pinefrog-deluxe-rtcp-test/

Kamailio - the successor to OpenSER – has been released in a new version, 3.0. This version is based on the merge between SER, SIP Express Router, and OpenSER code bases and developer teams. It’s a SIP server that you can run as a SIP proxy, a session border controller, a SIP load balancer or SIP application server. In version 3.0 you have the power of all the modules and applications in OpenSER and the raw strength of the SER core in one product. Go check it out today!

During the last week, I’ve been diving down into the RTCP protocol and Asterisk’s implementation of it. What is RTCP? In short, it’s the way to understand what’s going on with your SIP calls on the network.

VoIP relies on the IP network for media transmission

Voice over IP protcols, like SIP, needs to send the media in digital form across the network. The core IP protocols allow for packets to get lost, actually there’s nothing stopping a busy router from just deleting packets it doesn’t have time to deal with. On top of the IP protocol there are two main transport protocols, TCP and UDP. TCP tries to have control of message delivery, so if a router drops a packet, TCP will resend it until it gets confirmation from the other end that the message is received. UDP is like our royal mail service, you have no idea of what happened to the message. If you’re lucky, it will reach the destination.

Interactive realtime conversations are different from downloads

Protocols like HTTP and SMTP for web and email can use TCP and rely on retransmissions, since there is no realtime hurry. A few retransmissions won’t bother you much, but missing data in an e-mail message or web page might be very irritating. For media, especially interactive media, the situation is very different. Retransmissions will not help, since we propably already played the message in your speakers. We can’t reinsert part of a second worth of audio in the media stream after you’ve already enjoyed listening to it. For interactive media, like a phone call, we’re also in a hurry. We can’t wait for missing packets to arrive, since if we delay media too much, the call will break down. You will hear this and if it gets too hard, switch to James Bond walkie-talkie mode. “over”, “over, roger that”, “over and out”…Media for most of the standard VoIP protocols use RTP, the real time protocol. RTP is a way to send media over an IP network. Each message has a time stamp that tells the receiver where the payload fits into the media stream. If a packet is lost, the receiver will discover a glitch in the time stamps. Some receivers insert some noice to prevent you from discovering the issue. Of course, if there are too many packets lost you will notice. 20 milli-seconds here and there will propably go un-noticed in most cases.

Introducing RTCP – the bi-directional reporting system

RTP has a companion protocol called RTCP, the Real Time Control Protocol. This protocol is an out-of-band communication channel between the sender and the receiver. In a phone call, both ends are of course both receiving and sending.  RTCP is used to send reports to the other end, saying “I have sent xxx packets since we started and received yyy packets”. Both ends can then compare data and calculate the packet loss. The reports also include time stamps, so that the round trip time, the time for a packet to travel between the devices, can be measured. There are many pieces of data, and also a standard for extended reports that will deliver a bit more data.If a device, like an Asterisk server, collects this data, we can measure not only the quality of a particular phone call. We can gather data and get hints about issues with SIP trunks to a particular provider, about users on weak WiFi networks in hotels and a lot of other situations. We could potentially deliver this data in real time and alert users when the link is really bad, midcall.There are also advanced codecs that are adaptive to the situation and could use this data in real time. If the network shows signs of problems, the codec can try to change the flow of data – size of packets sent, rate of packets or other properties, like error correction and packet loss concealment.

Project Pinefrog – improvements to Asterisk’s RTCP support

Asterisk today has a very simple implementation of RTCP reports that isn’t very useful, but still a very good starting point. I’ve been working to make it a bit more useful by sending reports over manager, storing quality data in a database and also trying to improve the NAT support for RTCP. I’ve been testing a large number of phones to see how they have implemented RTCP and how Asterisk handles the received data. Hopefully, the turnout will be a large improvement and help us all in getting better and managed quality for our Internet telephony.This work is sponsored by a few companies in the Asterisk community who answered my earlier call for sponsorships.  I am always happy when things work out and Asterisk users step forward and contribute to the process of creating a better version of Asterisk. Being able to get quality data about the calls is a huge improvement for all of us that use the Internet as a transport for our telephone calls. As always your feedback is as welcome as the RTCP feedback on our SIP calls!

Peter Saint-Andre blogs about Jabber’s 11th anniversary and what the focus will be for the XMPP community during 2010. Here’s his list:

  • End-to-end encryption
  • Finalizing Jingle-based file transfer
  • Multi-user Jingle for voice conferencing and the like
  • Distributing chat rooms across servers
  • Bridging between serverless mode and server mode (very useful in distressed networks)
  • Reputation systems for XMPP servers and users

All of these issues are important. End-to-end encryption is something that the SIP community should spend more time trying to handle and I can only wish for some cooperation between SIP and XMPP in trying to find a security architecture for end-to-end communication – involving both encryption and authentication.

A named ACL is an Access Control List that can be manipulated after configuration and live in it’s own name space. The NACL module manage a list of NACL objects that can be used by other modules, like channel drivers, manager and dialplan apps.

Several SIP devices can share the same access control list and there will be one for the whole SIP channel. An external application that reads the security events in 1.8 can manipulate the NACLs in real time through AMI and block/unblock devices. There’s also an API so that Asterisk modules can modify NACLs internally. Applications can be added, so that NACLs can be manipulated through the dialplan. Call in, identify yourself and add yourself to an NACL for the next call…

Amongst the future ideas are NACLs that can be set by referring to a DNS name and use the DNSmgr to stay up to date with DNS. That requires some changes to the ACL.c api that will happen in the trunk version only.

I have also been playing with the idea of having a callback so that an app will know when a NACL is matched or some sort of counters to measure activity per time period and trigger alarms. Kamailio has one implementation of something like this in the pike module.

A lot of security-related ideas for Asterisk has been based on named ACLs, so I thought that was a starting point and a good holiday hack :-) The code is in the deluxpine branches for your testing!

Feedback and comments are, as always, welcome./olle