OCS/Asterisk integration Update

Many people have been eager to find out what is going on with the Asterisk and OCS integration guide. First, let me say I haven't forgotten about it! There are a few problems that myself and others who are working on this with me are trying to resolve.

As it stands, OCS and Asterisk don't want to play nice together. Each product seems to have a unique bug in it, that unfortunately only shows up in combination with the other. I'll give you a short explanation of each problem. If you haven't already done so, I recommend you read up on SIP and RTP, otherwise this probably wont make any sense to you.

The OCS bug

The first RTP packet sent by the OCS mediation server is completely broken. There are two problems with this packet

1. The packet is being sent to UDP port 0, not the port defined in the SIP Session description (SIP/SD) packet. Port 0 is a reserved port, and should never be used. The remote host correctly responds with an ICMP destination port unreachable message.

2. The second problem with the packet, is that it is sent to the SIP gateway, not the RTP endpoint specified in the SIP/SD packet. So even if the packet was sent to the correct port, its being sent to the wrong host. In our setup, the Mediation Server is sending this RTP packet to port 0 of the sipX server. It should be going to the RTP port of the Asterisk server.

image Initial RTP packet sent by the OCS Mediation server to port 0

Now, as far as I can tell, this happens even with the 'OCS approved' gateway products. I reviewed some SIP traces of communication with a Dialogic gateway, and saw the same behaviour. Subsequent RTP packets appear to travel to the correct destination server and port, and other gateways ignore and compensate for the bad/missing packet. This is where Asterisk's bug comes into play

The Asterisk bug

Now, as we all know, UDP is a stateless protocol, that does not guarantee reliability or delivery as TCP does. Packets may arrive out of order, or go missing completely. As VoIP is time-sensitive, we use UDP for the audio data, because we would rather some packets go missing, than all of the arrive, but possibly be delayed. So a UDP implementation must never rely on the delivery of a UDP packet.

From my own behavioural observations (and I could be wrong), it seems the Asterisk uses the initial RTP packet as a 'trigger' to start proxying the RTP traffic it receives from both endpoints. This first RTP packet is used to inform the other endpoint that it is about to start receiving data, but it never contains audio data (as shown in diagram above). As this packet never arrives, Asterisk just seems to wait indefinitely, ignoring all subsequent RTP packets from the mediation server, and our SIP phone. Given that there is no guarantee of receiving this packet, Asterisk should not be waiting for it, and should proceed with the correctly formed RTP packets it receives from the OCS Mediation Server.

The good news

There have been some reports of success with the newer build of Asterisk that comes with the new beta version of trixbox. I have not personally tried this, and coming up to Christmas, I'm not sure I will get time to until the new year. However, for those that do not want to wait, here is a post with some bits and pieces to get you started.