Suspected SIP session timer mismatch causing audio degradation on Cisco 8851 (Asterisk PJSIP + IPSec)

Asterisk Asterisk Endpoints
1

Hello Community,

I have been dealing with a hard-to-reproduce audio issue for quite some time involving a Cisco 8851 connected to an Asterisk PJSIP setup behind IPSec/NAT. I would like to ask whether anyone has experienced something similar or can spot an obvious mistake in the configuration.

Setup

Infrastructure

  • Asterisk (PJSIP) on a public server

  • Cisco 8851 as SIP client

  • Remote site connected via LANCOM IPSec site-to-site VPN

  • SIP over UDP

  • RTP handled via Asterisk (direct_media=no)

  • Codec: alaw only

Symptom

Calls would initially work completely normally, but after approximately:

  • 30–40 minutes

  • sometimes slightly longer

audio would become heavily choppy.

What was noticeable:

  • At times, I would hear the remote party in a heavily choppy way while they could hear me clearly

  • In other cases, it was the opposite:

    • I could hear the remote party normally

    • they would hear me in a choppy way

The SIP dialog itself remained active, and the call was not disconnected.

The issue did not occur on every call, but it appeared quite frequently during longer conversations.

Initial assumptions

Initially, the suspected causes were:

  • IPSec rekey events

  • LANCOM UDP aging

  • RTP timeout handling

  • NAT issues

  • RTP relay behavior

  • Cisco SIP behavior

Especially because on the LANCOM side:

  • UDP aging is ~300 seconds

However, IPSec lifetimes had already been increased to:

ikelifetime=8h
salifetime=8h

meaning an IPSec rekey around 30–40 minutes should no longer align with the observed timing of the issue.

Key finding

When comparing SIP session timer settings, it became clear that the timers between:

  • Cisco 8851

  • Asterisk

  • SIP peer/remote side

were not consistent.

Cisco 8851 (previous state)

INVITE Expires: 240
ReINVITE Expires: 30

Asterisk (previous state)

Initially:

timers=no

and later:

timers=yes
timers_sess_expires=3600

This likely caused different session refresh mechanisms to run in parallel.

Current state / harmonization

All timers have now been aligned to:

Cisco 8851

INVITE Expires: 1800
ReINVITE Expires: 1800

Asterisk PJSIP endpoint

[1005]
type=endpoint
transport=udp
context=outgoing
disallow=all
allow=alaw

auth=auth1005
aors=1005

direct_media=no

rtp_symmetric=yes
force_rport=yes
rewrite_contact=yes
media_use_received_transport=yes

rtcp_mux=yes

timers=yes
timers_sess_expires=1800
timers_min_se=90

rtp_keepalive=20
rtp_timeout=0
rtp_timeout_hold=0

Additional relevant points

IPSec

ikelifetime=8h
salifetime=8h
rekey=yes
rekeymargin=300s

LANCOM

  • UDP aging approx. 300 seconds

Current status

Important:

The timer harmonization has only just been applied.

I have not yet been able to perform a sufficiently long test call to confirm whether this actually resolves the issue.

At this stage, this is still a hypothesis based on:

  • the strong time correlation (~30–40 minutes)

  • previously inconsistent session timer configurations

  • the behavior observed during long calls

Current hypothesis

The current assumption is:

  • Inconsistent SIP session timers caused Re-INVITE / RTP re-binding issues

  • potentially combined with NAT/IPSec state handling

  • RTP streams may have remained on an outdated or suboptimal path

  • resulting in heavily choppy audio despite an active SIP dialog

Since IPSec lifetimes are now set to 8 hours, a direct correlation with IPSec rekeying now seems unlikely.

Questions to the community

  1. Does this hypothesis sound plausible?

  2. Has anyone seen similar issues with Cisco 88xx + Asterisk + NAT/IPSec setups?

  3. Are there known issues with:

    • rtcp_mux=yes

    • media_use_received_transport=yes

    • Cisco Re-INVITE behavior?

  4. Would you generally enforce strict 1800s session timer alignment across all endpoints?

  5. Any known pitfalls with long SIP calls over IPSec/NAT with Cisco 88xx devices?

Thanks in advance.

Kind Regards

2

What firmware is the 8851 running? 3PCC or Cisco Enterprise firmware?

3

Hi, it’s running 3PCC.

4

Asterisk wouldn’t change the port numbers for its end on a session timer refresh, and I hope the Cisco wouldn’t. Asterisk’s media stream should not be affected in any way by a simple session refresh.

5

3PCC basically used the Linksys SPA phones firmware as a template.

I assume when you said LANCOM above you are referring to LANCOM Systems, a router maker that sells in Europe?

You had asked “Has anyone seen similar issues with Cisco 88xx + Asterisk + NAT/IPSec setups”

The answer is absolutely yes, people have seen all manner of trouble running SIP through an address translator.

Fixes have involved one or more of 5 things:

  1. changing configurations on the phone. 3PCC does give you lots of knobs under SIP you can fiddle with

  2. Changing configurations on the address translator. You did not say if you have control over the translator or not

  3. Changing configurations on Asterisk

  4. Replacing the translator with a different manufacturer’s product and going through steps 1-3 again

  5. Replacing the phone with a different manufacturer’s product and going through steps 1-3 again.

Multiply out the different settings involved in all of these and you can see that steps 1-3 probably involve many dozens of different configuration possibilities. Which is why, in general, people try to avoid passing SIP through a NAT particularly when it’s an endpoint involved. It’s bad enough when it’s a trunk going through a translator.

The question you have to answer is what are you willing to do? If you are hell bent to get this working with a specific translator and specific phone - you are likely doomed to failure, in my experience.