Bug #2884

Call Control timers are very long and not configurable

Added by laforge over 3 years ago. Updated over 1 year ago.

Target version:
Start date:
Due date:
% Done:


Spec Reference:


I just noticed that there are some timers for which the 3GPP specs don't provide defaults, but we use some really large compiled-in value that cannot be modified.

T310 is one such example. It is invoked if (in a MT call) CALL CONFIRMED is received from the MS, but there's never nay ALERT, CONNET or DISCONNECT following. We are setting it in libosmocore to 180 seconds, which is super large. I doubt anyone would make a call and then wait three minutes for any indication that it rings on the other side. For comparison, the MS-side timer for the same situation is specified at 30s.


  • reduce default T310 timeout
  • make call control timers T3xx configurable in VTY

Associated revisions

Revision cd82710b (diff)
Added by laforge over 3 years ago

gsm_04_08.h: Reduce T310 default to 30s.

3GPP doesn't specify a network-side T310 default, but waiting for 180s
(3 minutes!) for the next message after CALL CONFIRMED is clearly way
too long and will just use radio resources for no good reason.

Change-Id: Ia52f9358bc86b23c72af9c80e2fff5cb0004b57a
Related: OS#2884


#1 Updated by laforge over 3 years ago

  • Checklist item reduce default T310 timeout added
  • Checklist item make call control timers T3xx configurable in VTY added
  • Assignee changed from laforge to sysmocom
  • Priority changed from Normal to Low
  • % Done changed from 0 to 10

See which reduces the default T310 timeout to (still very long) 30s.

Let's still make those T3xx configurable via the VTY (pending).

#2 Updated by laforge over 1 year ago

  • Assignee deleted (sysmocom)

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)