When using Meetme, the conference ends (hangs up) after 1 hour. (1 hour 2 min) What’s the time-out settings that I need to set?
Re-createable error:
Asterisk 1.8.7
Dail into Conference (MeetMe)
Using DAHDI dummy driver (pure sip otherwise)
After 1 hour, you get:
This is re-creatable. Apparently other callers seem to be fine. It appears to be the primary meeting holder, that has the problem. (unconfirmed). Otherwise if its just 1 caller, then is definitely does this.
It must be something timing out, or some time limit of DAHDI… Google wasn’t very helpful.
Just an update… I tried this on another box and get the same result. Although we do try to keep all the versions the same, i think this proves this is a “bug” and not a configuration / once-off error.
Can anyone else confirm this, or point me in the right direction?
Ok, there is more… I just tried the same test with “ConfBridge” rather than MeetMe because I see the main difference is that the ConfBridge does not use the DAHDI timer… and what do you know… 62 minutes later… hangup!
That tends to eliminate Asterisk itself from the problem!
Note that the statement that MeetMe uses a dahdi timer, whilst possibly true, is not a true description of how it uses dahdi. The actual conference bridge (mixer) is implemented in dahdi (or in hardware, accessed via dahdi).
Correct on both accounts!
(…well with MeetMe and DAHDI, from what I understand is that it uses DAHDI as a timing source. So when the conference is started it creates a pseudo DAHDI channel. As they say in the document “The DAHDI kernel modules and a functional DAHDI timing source (see dahdi_test) must be present for conferencing to operate properly.”)
The problem was in fact that inbound provider was cutting the call after 1 hour. If i had “core set debug 4”'ed it a little earlier I would have seen this as clear as day.
It depends. It’s probably a SIP Session Timers thing. The viability of those within Asterisk was improved greatly in the 1.8 branch, mid-stream, where I’m forgetting exactly which release.
What it turned out to be was that the ISP was trunking us a call and we, for some reason, put a progress() or ringing() or something i cant remember, but the result was that the ISP was seeing us as not answering the call, but performing the entire conference in the “early media” phase of the call… so after a rather generous hour, cut the call off.