Dealing with RTP loss

In my last post, you read about SIP call recovery from RTP loss. This post continues the theme, providing some more useful information – detecting and dealing with RTP loss between two SIP end points.

If you recall the scenario, there is a gateway installed between an SS7 carrier network and an emergency services IP network – an ESInet – over which emergency calls are routed to public safety answering points (PSAPs). Calls entering the ESInet via the gateway are SIP/RTP/UDP and, as the NENA i3 specification quite rightly states, in no circumstances should an in-progress emergency call be taken down automatically, just because RTP streams fail.

Whatever effort you put into making the call handling equipment redundant and resilient, it is always best to assume that bad things can still happen. To misappropriate the principle of simplicity from Ockham’s razor, follow the rule of thumb that advises, “Make as few assumptions as possible.” In fact, make one assumption only – expect the worst (i.e., ‘the proverbial’ happens).

So, we can expect situations to arise in which RTP media between the gateway and the ESInet fails.

PSAP equipment must be able to distinguish between RTP failure and real silence by a caller. That capability must apply at all points on an ESInet where RTP media is encountered by a device – from the gateway right through to the PSAP. The gateway uses technology – some form of digital signal processing, using either hardware (DSPs) or software (HMP) – to encode the media, and that same functionality will be used to detect the presence of RTP streams and distinguish between packets of silence or ‘speech’.

So far, so good, but as suggested, in a prediction far more likely than a prophecy from a Nostradamus quatrain to come true, the worst will happen and an RTP stream will fail.

Using SIP OPTIONS here is not entirely adequate – yes, that’s a good method of monitoring the far end, but only in so far as it confirms the presence of a signalling capability at the User Agent. A 200OK response doesn’t confirm the presence of RTP; merely that the signalling link is functioning. So, for what are we catering?

It’s not a failure of the gateway with which we need to deal – it’s a failure from (or towards) the other end. It might be counterintuitive, but when the device at the far end fails, it doesn’t know it’s failed, because it can’t tell if the gateway has received any RTP. Furthermore, although the gateway can tell if it’s receiving RTP, it can’t tell if the other device is receiving its RTP. The point being, half the solution has to be implemented at each end in order to achieve a whole result. That is, similar signal processing functionality needs to be implemented at both ends.

If there’s been a failure in transmitting RTP from the remote end equipment, the gateway clearly isn’t responsible. However, any gateway worth its salt can mitigate the situation by detecting RTP loss and implementing SIP call recovery as discussed in last month’s post. In addition, as part of the process of failover recovery from far end RTP loss, any decent gateway will provide management notification of RTP loss via SNMP.

Good gateways will follow the ‘Robustness Principle’ of Jon Postel: “Be conservative in what you do, be liberal in what you accept from others.” Innovative gateways will not leave anything to chance – after all, Nostradamus never predicted anything good.

Click on the link if you want to know more about Aculab’s range of gateways or why not post a comment – or give us a call.

Ian Colville
Enhanced by Zemanta
| 0 Comments | 0 TrackBacks

Listed below are links to sites that reference Dealing with RTP loss:

Dealing with RTP loss TrackBack URL :

Around TMCnet:

Leave a comment

Recent Comments

  • Houston CRM: Integrated communication is the new wave and it benefits any read more
  • los angeles unified communications: Having all types of communication integrated makes things so much read more
  • Kevin Rodak: Leaked military protoype test video ... lots of capability read more
  • Eddie Marietta: Extremely useful and informative article. I wish i can do read more
  • Erin Locknane: Stumbled into this site by chance but I’m sure glad read more
  • David: This is good information on FoIP, and you may want read more
  • Jules Turnner: Good job! read more
  • Ebonie Behrman: Awesome blog! read more
  • Aculab: Steve, Interesting scenario you have, and I am sure one read more
  • Steve Klinger: Hello Andrew, We have 14 offices across the world with read more

Subscribe to Blog


Recent Entry Images

  • zeus
  • evolution.jpg
  • Traditional_vs_cloud_based_deployments.png
  • Prosody X - boxed
  • Telephony_paas2.jpg

Recent Activity


  • Aculab tweeted, "Case study - Aculab’s software stack underpins massive PSAP solution in Germany. "


  • Aculab tweeted, "Can you guess which phone will ring? So far we have had 4 winners on our demo game. Come to stand 354 to try your luck!"
  • Aculab tweeted, "We're getting ready to kick off day 2 of #CHLive17 Come to stand 354 to have a chance to win an Amazon echo dot!"
  • Aculab tweeted, "Not long left to be in with a chance to win an Amazon echo dot! visit @aculab at stand 354 to play our game #CHLive17"
  • Aculab tweeted, "Thanks @Channel_Live_ and thanks to everyone who visited our stand"


  • Aculab tweeted, "Channel Live: doors open tomorrow at 10am - get yourself to the NEC and learn how to move your Channel business forward! #CHLive17"
  • Aculab tweeted, "@aculab and @phactsolutions case study: Phact and Prosody S - a virtual success "
  • Aculab tweeted, "It's time to head over to the NEC and meet all these awesome exhibitors:  #CHLive17"


Around TMCnet Blogs

Latest Whitepapers

TMCnet Videos