VOICE over IP (VoIP) is increasingly being used and SIP is the standard that is supported by a growing number of vendors.
Setting a link between two codecs via networks involving the IP protocol, especially when transmitting via a WAN or the Internet, needs a rather complex preliminary setting and is sensitive to many potential mistakes.
A number of parameters must be known beforehand, as several technical issues are raised. The IP addresses of the devices must be known. As far as the remote unit is concerned, this may be less obvious than it looks, as the IP address is subject to change when assigned by a DHCP server.
When the connection goes through one or more NAT routers and/or firewalls, this IP address may be unusable.
The precise configuration of the coding parameters has to be agreed on. Other parameters may have to be set for specific network constraints.
According to AETA Audio Systems, represented in Australia by Engineering Design & Services Pty Ltd , there is a need for protocols and tools that help automate the process and make it accessible to non-specialists.
SIP is the acronym for Session Initiation Protocol, a protocol specified by the IETF for establishing media transmission sessions.
SIP is considered the communication protocol of the future by most vendors and as such it has a deep influence on the VoIP applications.
As a signalling protocol, SIP brings methods and techniques to solve the issues related to the establishing of an audio link. Almost as important, it is a recognised standard, implemented on many network devices and systems.
Using SIP helps customers build modular and evolving systems, not being tied to a single vendor.
Setting a link with SIP
Here is an example - A reporter on the move with AETA Audio Systems’ Scoopy wants to make a call to a SIP compliant codec located in the main station. The reporter may be at home, or at another location, not necessarily known in advance.
Once the Scoopy is on and connected to the network, it will register itself to a SIP ‘registrar’. This registrar can be located on the LAN of the radio house, but it could be elsewhere in the network. Then the registrar ‘knows’ where the Scoopy is, what its IP address is. On the radio house side, a similar process takes place.
To call the codec of the radio house, the reporter just needs to know its SIP address, which can be like firstname.lastname@example.org (very similar to an email address). To call the unit, the reporter has to select the preferred audio coding mode on the Scoopy (e.g. mono G722), then call the remote unit, simply by using this SIP address (SIP URI).
The Scoopy sends the request (INVITE in SIP protocol) to a proxy server (often the same device is also the registrar). To make things simple, this proxy then relays and routes the request to its destination. Resolving the SIP URI to a physical network and address uses mechanisms similar to those used for resolving URLs.
Several proxys may be involved in cascade to finally reach the desired destination, but this does not have to be known or dealt with by the end devices.
The following is like the initiation of a phone call - the IP codec ‘rings’; if it accepts the call, this is notified to the Scoopy.
At this stage, the proxy(s) provide the Scoopy and the IP codec with all the address data they need for the link, then the actual audio streams can be exchanged between both units.
The end devices now can exchange data directly; the proxys do not have to be on the path, they are only involved in the setting (and later the ending) of the session.
The codecs will automatically exchange their coding capabilities, and agree on a coding mode, with no further user intervention.
Alternatively, the call can be done from the station to the reporter, in a way very similar to the above.
In contrast with ISDN links, the operators at the station do not even need to know where the reporter is located. This is because the registrar deals with this issue.
Note that it is also possible to set a link with a SIP-compliant VoIP phone instead of another codec.