SIP/Voice Alarms fail after 4 minutes on Avaya

I’m having problems with the voice module connecting to my Avaya system. I created a howto a few months ago, and that works… For 4 minutes. I’ve looked at captures and have come to some conclusions.

What I know:

  1. when starting up ignition, it registers with the Avaya system.
  2. If I do nothing, after 4 minutes, Avaya removes the extension, and alarms no longer work
  3. during that 4 minutes, voice alarms work perfect
  4. Ignition sends out double CRLF to port 5060 (sip) as keep alives every 25 seconds, as mentioned in RFC5626
  5. other SIP devices (polycom phones) registered on Avaya send out periodic SIP “REGISTERS” and have no problems staying connected

What I think:

  1. RFC5626 seems to indicate sending out the double CRLF is only for TCP, not UDP (as I interpret it)
  2. Ignition isn’t sending the right keep alives
  3. Avaya is not seeing them, and shutting down the extension

Any ideas? I’ve got packet captures for tech support.

I tried a connection to another SIP provider (callcentric).

The only difference I can see is the 200 OK response from Avaya has a “Supported: timer” header, and callcentric does not. It seems to stay connected to callcentric - Ignition sends the occasional REGISTER command, along with the double CRLF at times.

PS, a User-Agent header of “Ignition” would nice.

Hey, just wanted to let you know that we’ve seen and read your post, but that Colby (the developer who’s going to have to look into this) is rather busy this week with the Ignition Community Conference, so he may not get to dig into the issue until the end of the week or early next week.

Your troubleshooting so far is nice and thorough so I don’t imagine the issue will be too difficult to resolve.

Sorry for the inconvenience.

Hey, sorry for the delay, we’re back up and running in the office now.

You analysis sounds good, I’ll have to look into it a bit more. If you can, upload any traces/captures/etc you have to ticket number 13732.


As I wait for your upload, a few things:

  1. Yes, it appears Ignition is sending those keep-alives every 25 seconds.
  2. While I don’t think this is specifically disallowed, I can’t find any specification that would cover the current use. I think it must be almost a “hack” to bypass some NAT issues (to keep the nat route open, to allow for incoming messages), which generally is ok, given this line of RFC 6223:

[quote]“Since there are SIP entities that already use a combination
of Carriage Return and Line Feed (CRLF) as keep-alive messages,
and SIP entities are expected to be able to receive those, this
specification does not forbid the sending of double-CRLF keep-
alive messages towards an adjacent SIP entity even if usage of
keep-alives with that SIP entity has not been negotiated.”[/quote]

I think we could make this optional, so that it could be turned off. Additionally, I think the re-registration time should be settable, since I think we’re currently doing it way too often (I think it’s 1 minute, whereas most recommendations say 30-60 minutes)

Also: What version of the “Voice Notification” module are you running? Make sure it’s 1.6.3. I just saw someone today who was running Ignition 7.6.3, but v1.6.1 of that module. There was a problem fixed that could cause issues with registration, and cause everything to stop after a while.


Sorry for the delay, Uploads are done. They both capture the initial handshake, and one has a couple of calls. You can’t really see the failure in the log after 4 minutes. The Avaya system just stops accepting packets.

Running Ignition 7.6.3 with Voice 1.6.3.


So, I’ve just taken a look at the captures. I see the cr/lf, but the more suspicious thing from this capture is that it appears that multiple calls work to an extension, but it’s only when you attempt to call a real number that it doesn’t work. Obviously, that could just be the coincidental sequence of events in this capture, but it stands out. When it’s “working”, are you able to successfully dial numbers like 8-651-XXX-XXXX?

The other (theoretical) possibility here is that something is going on in the router, and the NAT session is being canceled, so packets coming from the voip server are no longer getting routed (to be fair, though, it appears that you’re only going to a voip server on your network… but maybe it’s on a different subnet, and still being routed).

Let me know what you think of these two observations. It would be relatively trivial for me to build the module without that “cr/lf” keep alive, but I doubt that is really what’s causing this.


It’s just a coincidence. During the first 4 minutes, it works fine - internal or external calls. If no calls are made in the first 4 minutes, it still doesn’t work after that time. The registered extension literally disappears on the Avaya system status page.

There is no router, and no NAT between the Ignition server and the Avaya IP Office. They are on the same segment.

I don’t think the issue is that the CR/LF is there, I think the issue is that there are no occasional SIP REGISTERS. I see this when I connect ignition to another SIP provider (callcentric) every 60 seconds. You don’t see that at any other frequency after ignition registers with Avaya.

PS I know almost nothing about SIP, so don’t make an assumption on that :slight_smile:


Oh, I see… yes, Ignition does re-register fairly often on other servers, even though it shouldn’t need to more than every hour or so. I’ll look in that direction, perhaps the rate should be settable.


I saw something about half the session interval in RFC4028 section 7.2. What’s odd is that the avaya 200OK does have a “Expires” header, which I think is what they are referring two.

In comparing packets between Avaya and Callcentric, the only big difference I see in the 200OK is the one from Avaya has a “Supported: timer” while the one to call centric does not. The expires header is also in a little different place.


Ok, I think I’ve tracked it down. We were only looking for the “expires” parameter on the contact field, which many servers set, but weren’t falling back to looking at the general “Expires” header on the message. So, with the Avaya server, the system was defaulting to a 5 minute refresh, which is much longer than the 2 minutes Avaya wants.

Try this build: [attachment=0]this build[/attachment] which should fix that, and let me know how it goes. Important: When you install this module through the gateway, it will fault, and you’ll need to restart the gateway. It’s a known issue that the voice module doesn’t support hot-reloading.

On a side note, thanks so much for the effort you put in to tracking this down, it really helped me to get to the source quickly!


It seems like it is working, at least in my test environment. It is holding onto the Avaya system and I was able to make multiple calls. I’ll put it in my production environment and put it through it’s paces.

We’re so exited to have a voice dial system that works well. I’ll have to post on our final solution because it is pretty unique, I think.

Thanks for recognizing my effort. It takes equal effort on your end to come to a solution.


Great, I’m interested to hear more about what you’ve put together.


Take a look: