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, "With identity theft on the rise, voice biometrics is being used to mitigate the risk associated with fraudulent account access. Discover more with #VoiSentry, the fast & effective speaker verification & authentication solution #Biometrics #FraudPrevention "


  • Aculab tweeted, "Webinar: VoiSentry - How voice biometrics can boost the value of your solutions - 23rd May 3:00 PM (BST)"




  • Aculab tweeted, "We're enjoying out last day @PCCEMEA in the demo area. If you're curious about how #voicebiometrics can benefit your solution deployments in the @Avaya_UK environment, then come and have a chat at the Aculab booth!"
  • Aculab tweeted, "If you've not visited the Aculab booth @PCCEMEA yet, then head over to the demo area and we can tell you a bit about VoiSentry - our DevConnect tested #voicebiometrics product"


  • Aculab tweeted, "The @PCCEMEA demo area is getting busy! We've already spoken to many visitors about our #voicebiometrics product - VoiSentry. If you're at the conference, head over to the Aculab booth and say hi!"


  • Aculab tweeted, "We are a proud sponsor of the @PCCEMEA Spring Conference starting this Sunday! Visit our booth to find out about our DevConnect tested #biometrics product - VoiSentry. Read more here:"


Around TMCnet Blogs

Latest Whitepapers

TMCnet Videos