Category Archives: Genesys Projects

Genesys SIP Architecture Changes

There have been some pretty big release announcements relating to Genesys SIP over the last few weeks:

SIP Proxy – 8.1.100.36 [03/15/13] – General
SIP Proxy provides an interface for SIP communication between SIP devices and SIP Server components. It handles register requests, load-balances SIP transactions, and provides an alternative HA model that supports deploying primary/backup SIP Server instances within the same HA pair across different subnets and does not require a virtual IP address.

SIP Server – 8.1.100.64 [03/15/13] – General
Support for a restricted release of SIP Cluster.
Support for Resource Manager in active-active HA mode.
Support for Genesys SIP Proxy

Sipspan2 – 8.1.100.09 [03/15/13] – General
sipspan2 is a log navigation tool designed to simplify troubleshooting in a SIP Cluster environment. It processes log files generated by multiple Genesys components to build a troubleshooting view where each record represents a call flow event given as a clickable link to the corresponding place in a log file.

The primary focus of these releases are to improve the scalability and resilience of the Genesys SIP architecture. Of particular note is the introduction of a new component, SIP Proxy which removes the dependency on third party solutions such a Windows NLB, F5 BIG-IP LTM or IP Address Takeover to provide SIP server High Availability (HA).

The technical documentation relating to these releases is still being produced. However there is a link here which provides deployment information for SIP Proxy:

http://docs.genesyslab.com/Documentation/SIPS/latest/SIPProxyDeployment/SIPProxyOverview

In summary:

The primary purpose of Genesys SIP Proxy is to provide high availability without requiring a virtual IP address.

An N+1 pool of proxy instances is defined for each SIP Server HA pair. The proxy instances monitor the SIP Server pair to determine which is active and which is backup.

Incoming SIP messages are proxied to the primary SIP Server instance. It is the responsibility of external SIP user agents to select a proxy instance based either on DNS or static configuration of multiple IP addresses, and to fall back to an alternate instance if the select instance is not responding.

In a standard deployment, an N+1 pool of SIP Proxy instances handles incoming and outgoing SIP transactions between a SIP Server HA pair and external SIP elements. Each SIP transaction would be handled by a single proxy instance.

SIP Proxy is responsible for proxying SIP messages from external SIP user agents to the appropriate SIP Server. It is the responsibility of each external user agent to choose a SIP Proxy instance when sending a SIP message.

In SIP Cluster mode, Session storage ensures that each message from the same or related SIP session is routed to the same SIP Server.

SIP Proxy acts as a SIP registrar. SIP Proxy has shared registration-info storage. Any endpoint can be reached by any SIP Proxy. SIP Proxy uses SIP Server as an authentication server. It passes REGISTER requests to SIP Server and waits for a response.

SIP Proxy provides load balancing of incoming traffic across SIP Servers. This is achieved by using a random or round-robin SIP Server selection routine.

SIP Proxy depends on DNS to resolve the SIP Proxy FQDN by A and SRV records (as described in RFC 2782). More specifically, SIP endpoints must support SIP SRV Server Resolution as defined in RFC 3263 – Locating SIP Servers (don’t worry – most IP Phones do). Basically, SRV records are a nameserver record type that return the port as well as weight and priority information for a request. Hence, the SRV records are used by the SIP endpoint to discover the IP address and port of a SIP proxy it should use.

Share

SIP Mid Call Codec Re-Negotiation

Most of us usually work in a SIP environment which is fairly static and the primary codec is G.711 RTP. But in some networks such as Cellular radio networks that might not always be the case. For example in cellular networks codec re-negotiation could occur during Hand Over or Hand Off.

Some background:

The Mobile Telephone Switching Office (MTSO) is the mobile equivalent to a PSTN Central Office. The MTSO contains the switching equipment or Mobile Switching Center (MSC) for routing mobile phone calls. It also contains the equipment for controlling the cell sites that are connected to the MSC.

Image

The most basic form of hand over is when a phone call from a Mobile Station (MS) in progress is redirected from its current cell to a new cell. The source cell and the target cells may be served from two different cell sites or from one and the same cell site. Such a hand over, in which the source and the target are different cells is called Inter Cell Hand Over. The purpose of inter-cell hand over is to maintain the call as the subscriber is moving out of the area covered by the source cell and entering the area of the target cell.

If during ongoing call a Mobile Station (MS) moves from one cellular system to a different cellular system which is controlled by different MTSO and Inter System Hand Over occurs to avoid dropping of the call. This can occur when a mobile signal becomes weak in a given cell and MTSO can not find other cell with in its system to which it can transfer the call. In the context of Inter System Hand Over different cellular systems include 2G Networks, 3G Networks e.g. Universal Mobile Telecommunications System (UMTS) and 4G Networks e.g. Long Term Evolution (LTE).

For the practical realisation of handoffs in a cellular network each cell is assigned a list of potential target cells, which can be used for handing-off calls from this source cell to them. These potential target cells are called neighbours and the list is called neighbour list e.g. a list of neighbour ARFCNs.

During a call one or more parameters of the signal in the channel in the source cell are monitored and assessed in order to decide when a handover may be necessary. The downlink (forward link) and/or uplink (reverse link) directions may be monitored. The handover may be requested by the MS or by the base station (BTS) of its source cell and, in some systems, by a BTS of a neighbouring cell. The MS and the BTSs of the neighbouring cells monitor each other others’ signals and the best target candidates are selected among the neighbouring cells.

From a Genesys perspective what could happen during a Hand Over?

The answer obviously depends on the core network architecture to which Genesys SIP components are connecting. Depending on core network topology a Hand Over could result in a SIP re-INVITE with a change in SDP to change the codecs offered by the network due to cellular Radio Area Network (RAN) conditions. Equally in the case of an Inter System Handover for example between 4G LTE and 3G UMTS networks this could result in a completely new call (SIP INVITE).

Genesys 8 SIP components (SIP Server, Resource Manager, Genesys Media Server, GVP) all support SIP re-INVITE which is specified in RFC3261. RFC3261 states that a SIP UA may change codecs during mid-call with re-INVITE. Effectively a re-INVITE is simply another INVITE on the same SIP dialog but with updated SDP information.

Lets assume we have a call from a Mobile Station (MS) in queue and receiving audio treatment from Genesys Media Server (GMS) under the control of a routing strategy. For an announcement treatment depending on the current codec negotiated GMS may or may not be performing transcoding. For a music treatment if we are using a RTSP streaming music content source then GMS will almost certainly be providing transcoding from MP3 to the negotiated codec.

A hand over then occurs.

SIP Server and hence GMS get re-INVITED and mid call codec re-negotiation occurs. During any current announcement treatment GMS must transcode for the remainder of the announcement. Subsequent announcements will use the audio content file encoded in the native codec format and no further transcoding is required.

The only exception to this is AMR codecs. For AMR, Radio Access Networks (RAN) typically only support a subset of AMR modes. Given that Genesys Media Server looks for AMR encoded files using the file extension we can only encode audio content with a single AMR mode. Therefore, audio content is recorded in the mode with the highest available bitrate and GMS is used to transcode to lower modes if required.

UPDATE 01/04/2013:

A further consideration when using secure RTP (SRTP). Is it a valid thing to change the SRTP media encryption keys during a session and signal this using a re-INVITE?

In RFC4568 (SDES) there is no exact statement regarding this.  In fact section 5.1.4. “Modifying the Session” suggests that this should work: “Once a media stream has been established, it MAY be modified at any time, as described in RFC 3264, Section 8.  Such a modification MAY be triggered by the security service, e.g., in order to perform a re-keying or change the crypto-suite.  If media stream security using the general security descriptions defined here is still desired, the crypto attribute MUST be included in these new offer/answer exchanges.”

Share

F5 BIG-IP LTM and Genesys

Just a quick blog as an Aide-mémoire for myself. When using F5 BIG-IP devices to provide a Virtual
IP Address (VIP) for Genesys SIP HA Pairs:

  • Use BIG-IP build v11.2.0.2446.0
  • Disable Clustered Multi-Processing (CMP) on all virtual servers
  • Ensure that source port is set to “Preserve” rather than “Preserve Strict”

  • Ensure that all iRules use SIP message events rather than client connected events as
    incorrectly documented on page 31 of the 2009 document “SIP Server Integration Guide with
    F5 Networks Big-IP Local Traffic Manager” e.g.

when SIP_REQUEST {
when SIP_RESPONSE {

and not:

when CLIENT_ACCEPTED {

Share

VoIP Infrastructure Security

How secure is your VoIP Deployment?

There are lots of approaches to securing VoIP networks including the deployment of firewalls,
Session Border Controllers (SBC), encrypting SIP with TLS and voice with SRTP. But have you ever
considered an attack from the inside and in particular the integrity of the firmware running on each
IP Phone? If not I strongly recommend taking 55 minutes to watch the following on YouTube:

http://www.youtube.com/watch?v=f3zUOZcewtA

Share

Converting IRD Strategies to Visio (UPDATED)

As a Happy New Year gift to the Genesys community I’ve decide to release the binaries associated with these blog posts in to the wild!

http://genesysguru.com/blog/blog/2011/03/18/documenting-genesys-strategies/
http://genesysguru.com/blog/blog/2011/03/25/genesys-strategy-analyser/

Hopefully somebody will find my Strategy Analyser useful!

Please note that this is beta code and that not all IRD blocks / block properties are implemented. Also the layout still needs some work.

You can download it here:

http://wikisend.com/download/231404/GenesysStrategyAnalyser02022013-2.zip

25/01/2013:

Just to let you know that a couple of testers have reported the same problem. COM exception (0x86DB0904). It is possibly a Visio 2003 interop issue which I am trying to get to the bottom off. In the meantime if anybody wants a strategy converting then please just email the XML export to me: craig.reading1@gmail.com

27/01/2013:

A quick video of Strategy Analyser in action on YouTube here:

This just shows dropping some XML exports into it and then converting them to Visio in real-time. I’ll post a video of the online mode when a get some time.

28/01/2013:

YouTube video of online mode:

02/02/2013:

Hopefully the problem reported by testers in France, Germany and Brazil has now been fixed. Version 1.7 is available for download here:

http://wikisend.com/download/231404/GenesysStrategyAnalyser02022013-2.zip

 

 

 

Share

Raspberry Pi and OpenBTS

Great little article: “How to shrink a 30ft base-station into a three-inch Raspberry Pi” here:

http://www.youtube.com/watch?v=GCcKgrzbix4
http://uktispecialist.com/our-experience/how-to-shrink-a-base-station-into-a-raspberry-pi

Not quite sure a Raspberry Pi can be used to shrink a 30ft base-station without the additional costs of a duplexer and some power amplification! Also I have concerns that the Pi doesn’t have enough physical RAM. But hats off – it shows the art of the possible.

From my own experiences and like the folks at PA Consulting Group say “Overcoming some seriously complex obstacles along the way, we successfully managed to route voice and SMS traffic through the computer”. For me the biggest obstacle to date on Centos 5 / RHEL 5 has been sorting out all the package version dependencies.

For my project I’m planning to use a Fairwaves (http://fairwaves.ru/) UmTRX (http://code.google.com/p/umtrx/) as the GSM transceiver rather than an Ettus USRP (http://www.ettus.com/). This will give me a bit more flexibility to use the same hardware for other projects in the future.

Image

Also rather than having my own screened-room facility my research suggests that an old Microwave oven with some copper mesh should make a cheaper Faraday cage (although the UmTRXv2 is pretty low-power at 50-100mW anyway)!

More soon.

Share

Driving some relays from a Genesys routing strategy!

Firstly a very Merry Christmas and best wishes for a successful 2013. I’ve not written many blog posts in 2012 – just been too busy and plan to rectify that in 2013. Anyway, a little fun project to keep the brain cells working over the festive period …

For this project you need a Raspberry Pi (http://www.raspberrypi.org/) The Raspberry Pi allows peripherals and expansion boards to access the CPU by exposing the inputs and outputs. The Raspberry Pi board has a 26-pin expansion header, marked as P1, arranged in a 2×13 strip. Amongst other things this provides 8 GPIO pins.

We need to build a circuit to drive the relay from one of the Raspberry Pi General Purpose Input/Output (GPIO) pins (http://elinux.org/RPi_Low-level_peripherals) as shown below:

Image

The parts required are:

2N3904 transistor
6V 10A PCB Relay
1N4004S diode
1K2 Metal Film 0.6W Resistor

This circuit is needed as the Pi’s GPIO pins are 3.3V and the maximum current is 16mA which is not enough to drive a 5v relay directly but is enough to switch a transistor on and off. Essentially, to activate the relay, all the circuit does is send a few milliamps at 3.3V from the GPIO pin, through a 1K resistor. This current is enough to saturate the transistor, causing current to flow on the 5V rail through the transistor, and therefore also through the relay’s coil.

The relay circuit wired to GPIO 17 via the 26-pin expansion header:

Image

To control the GPIO pins we install Apache and PHP5 on the Pi and use a PHP library from here: http://www.huubknops.com/rpi-gpio. The following Linux commands do most of the work:

sudo apt-get update
sudo apt-get install apache2
sudo apt-get install php5 php-xml-serializer php5-gd

cd /var/www
sudo wget http://www.huubknops.com/rpi-gpio/gpio.tar.gz
sudo tar zxvf gpio.tar.gz
sudo bash -c “echo www-data ALL=\(ALL\) NOPASSWD: ALL >> /etc/sudoers”

All we need to do now is to call the relevant PHP scripts from Web Service blocks within a Genesys IRD based routing strategy:

http://xxx.xxx.xxx.xxx/gpio/rpi_init.php
http://xxx.xxx.xxx.xxx/gpio/rpi_flip.php?number=17

Image

Image

I can’t think of many real world applications at the moment. If you can then please drop me an email. For now I am using it to turn on a blue flashing light!

Image

Look out for some more posts soon – details of CLiDE (Craig’s Little Development Environment) including SBC, core IN, Voxeo, Sangoma and Genesys integration as well as my own GSM mobile test network using OpenBTS (http://en.wikipedia.org/wiki/OpenBTS) as the base transceiver station (BTS)!

Share