VoIP
SIP is an application-level protocol for setting up, changing and terminating multimedia sessions between participants. It is primarily used on IP networks but it is both network- and application-agnostic. The IETF developed SIP to aid in the move toward convergence by allowing voice, video and data to be integrated over the same network. SIP enables integration with e-mail, the World Wide Web and next-generation technologies for wireless 2.5 and 3G networks as well as broadband IP networks. SIP has been implemented as the chosen means of establishing VoIP calls into and out from Vocality networks.
The first application is where a customer has a SIP network at the hub site. The Vocality SIP gateway provides access to this SIP network from/to legacy analogue and digital voice networks at the remote sites. The second application is where a legacy analogue or digital voice network at a hub site can be connected to a SIP network at a remote site. The advantage of running the SIP network at the remote site is that this network can typically be created with less equipment than a legacy analogue or digital voice network. Although these applications seem similar (a legacy voice network at one end of the network and a SIP network at the other), there are subtle differences in how they are typically implemented, which lead to different requirements on how calls are routed between the networks. Also, the implementation of the SIP gateway does not preclude it from being used to connect SIP networks at the hub and remote sites. The advantage of doing this via the SIP gateway instead of just using standard IP routing is that bandwidth is allocated dynamically for the duration of the calls.
Vocality equipment can interoperate with a SIP network with or without a SIP registration or outbound proxy. When an outbound proxy is available, the SIP gateway can refer all calls into the SIP network to this proxy for call routing. When no SIP proxies are available, SIP devices can be the endpoints of long line extensions or alternatively, basic dialled number to SIP endpoint address translations can be made to provide a simple call routing scheme into the SIP network. Conversely, calls from the SIP network can be routed through the gateway in either a long line extension scheme, where all calls received to a particular SIP address are forwarded directly to a specified voice port in the Vocality network or alternatively, the gateway can operate in an indirect SIP call routing scheme. In this scheme, the gateway will always answer calls from the SIP network, and will provide dial tone to the calling SIP device. It then captures dialled DTMF digits from the calling SIP device, and routes the call to another voice port in the Vocality network.
The SIP Gateway and User Agents
The SIP gateway is a software-only extension to the Vocality multiplexer feature set. Encoding and decoding occurs on the SIP network endpoint devices, and the analogue or digital voice ports that calls are routing through. The SIP gateway just provides a set of SIP User Agents (UAs) through which SIP calls are handled. From the multiplexer’s view, the UA is a logical entity addressable (channel) within SIP and Vocality address spaces through which a single call may be routed.
The number of SIP UAs required within a gateway depends on the type of call routing required. When using the gateway to connect a SIP network to a legacy voice network in direct (long line extension) mode, a SIP UA is required in the Vocality gateway for every remote device that we wish to provide a long-line extension for. When using the gateway in indirect mode, a separate SIP UA is only required for each simultaneous voice call that must be supported. The selection of whether call routing is done directly or indirectly is chosen on a per-UA basis and so a gateway can therefore handle a mixture of directly and indirectly routed calls. The number of SIP UAs implemented in the SIP gateway is controlled via feature keys in the unit configuration.
A hunt group is also automatically created on the SIP gateway. It can be used to route a call into the SIP network using any of the SIP UAs present, in a similar fashion to the automatic hunt group used for digital voice interfaces.
Each SIP UA has an address of record (AOR) in SIP addressing space. The address used is taken from the configured user-id. The actual address used depends on the configuration. If a fully qualified address has been entered (user@location), then this is the AOR used. Otherwise, if the UA has been configured to use a SIP registration proxy, then AOR is set to user-id@registration_proxy where user-id is the configured user-id and registration-proxy is the configured registration proxy location. Otherwise, if the SIP gateway has been configured with a fully-qualified domain name (FQDN), then the AOR is set to user-id@FQDN where user-id is the configured user-id for the AOR and FQDN is the configured fully qualified domain name for the gateway. Otherwise the AOR is set to user-id@IPAddress, where IPAddress is IP address configured for the first Ethernet in the IP configuration.
Each SIP UA can be configured with a Destination in the format of a Vocality node:slot:channel port identifier. This controls how calls received from the SIP network on this UA are routed. See the section on SIP->Vocality call routing for more info.
Each SIP UA can be configured with a SIP peer URI. This is used to control how calls are made into the SIP network from this UA. See the section of Vocality->SIP call routing for more info.
Each SIP UA can be configured with an IP TOS value. This sets the IP TOS field to be used in voice packets sent from this SIP UA into the SIP network. This allows the SIP network provider to identify the voice traffic in the SIP network for service differentiation.
Each SIP UA can be configured with an outbound proxy address/location. This is used to control how calls are made into the SIP network from this UA. See the section of Vocality->SIP call routing for more info.
Each SIP UA can be configured with a registration proxy address/location. If configured, the AOR for this UA is registered with the configured proxy. Re-registration occurs periodically, at a frequency controlled by the gateway’s configured re-registration interval (which may be overridden by a value returned in the registration attempt).
Some SIP networks require that all UAs be authorized. Therefore authorization information may be configured on each UA. The authorization may either use the configured user-id for that UA, or a specific identification used for authorization only.
Each SIP UA must be configured to specify which voice coding algorithm is used. As this is the parameter used to control how much bandwidth is required over the Vocality network, there is no flexibility in the codecs offered and either G711A, G711u or G729A must be selected. SIP devices making calls through a UA in the Vocality SIP gateway MUST support the specified codec for the call to work. The codec type selected in the SIP UA configuration is always the codec type used for a Vocality->SIP call regardless of the Algorithm configured on the originating voice port. This also means that for SIP UA to SIP UA calls to succeed the same algorithm must be configured on both SIP UA ports used on the call.
Summary
The Vocality SIP gateway will interoperate with any SIP device that is compliant with RFC3261. The SIP protocol is supported over UDP transport running on the standard port (5060). The following SIP standards are supported:
RFC3261 SIP: Session Initiation Protocol
RFC3262 Reliability of Provisional Responses in the Session Initiation Protocol (SIP)
RFC2327 SDP: Session Description Protocol
RFC3263 Session Initiation Protocol (SIP): Locating SIP Servers
RFC3264 An Offer\Answer Model with the Session Description Protocol (SDP)
RFC3265 Session Initiation Protocol (SIP) -Specific Event Notification
RFC3515 The Session Initiation Protocol (SIP) Refer Method
RFC3428 Session Initiation Protocol (SIP) Extension for Instant Messaging
RFC3581 An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing
RFC3891 The Session Initiation Protocol (SIP) "Replaces" Header
RFC3842 A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP)
RFC2617 HTTP Authentication: Basic and Digest Access Authentication
RFC2976 The SIP INFO Method
Voice packets are transferred between the SIP gateway and the SIP network using the standard RTP mechanism as described in:
RFC3550 A Transport Protocol for Real-Time Applications
RFC3551 RTP Profile for Audio and Video Conferences with Minimal Control
The gateway expects all voice samples to be presented in 20ms samples as indicated in RFC3551. To operate in indirect mode, or to get the legacy DTMF relay function to operate through the SIP gateway, the SIP devices should also support:
RFC2883 RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals