Asterisk 1.8.11
FreePBX 2.10.1.1
The system is not physical, it is virtual. The system is only being used for conferencing (app_MeetMe). There is 1 extension configured that automatically forwards all calls to the custom destination that is the MeetMe setup. The server is connected via SIP to a Mitel 3300 ICP.
Everything works great if we call it from internal extensions. Calling in it picks up the bridge and PIN numbers. No problems at all. It’s when people call in from external that it kind of goes crazy. It prompts 3 times for the PIN before disconnecting. I’m not sure what logs I can provide to help troubleshoot and resolve. I did enable a higher level of logging to include DTMF. Here is a clip of some of the information.
[2012-12-19 09:00:48] DTMF[22360] channel.c: DTMF begin '5' received on SIP/<MITEL>-0000004a
[2012-12-19 09:00:48] DTMF[22360] channel.c: DTMF begin ignored '5' on SIP/<MITEL>-0000004a
[2012-12-19 09:00:48] DTMF[22360] channel.c: DTMF end '5' received on SIP/<MITEL>-0000004a, duration 140 ms
[2012-12-19 09:00:48] DTMF[22360] channel.c: DTMF end passthrough '5' on SIP/<MITEL>-0000004a
[2012-12-19 09:00:48] DTMF[22360] channel.c: DTMF begin '7' received on SIP/<MITEL>-0000004a
[2012-12-19 09:00:48] DTMF[22360] channel.c: DTMF begin ignored '7' on SIP/<MITEL>-0000004a
[2012-12-19 09:00:48] DTMF[22360] channel.c: DTMF end '7' received on SIP/<MITEL>-0000004a, duration 160 ms
[2012-12-19 09:00:48] DTMF[22360] channel.c: DTMF end passthrough '7' on SIP/<MITEL>-0000004a
[2012-12-19 09:00:49] DTMF[22360] channel.c: DTMF begin '1' received on SIP/<MITEL>-0000004a
[2012-12-19 09:00:49] DTMF[22360] channel.c: DTMF begin ignored '1' on SIP/<MITEL>-0000004a
[2012-12-19 09:00:49] DTMF[22360] channel.c: DTMF end '1' received on SIP/<MITEL>-0000004a, duration 80 ms
[2012-12-19 09:00:49] DTMF[22360] channel.c: DTMF end passthrough '1' on SIP/<MITEL>-0000004a
[2012-12-19 09:00:49] DTMF[22360] channel.c: DTMF begin '7' received on SIP/<MITEL>-0000004a
[2012-12-19 09:00:49] DTMF[22360] channel.c: DTMF begin ignored '7' on SIP/<MITEL>-0000004a
[2012-12-19 09:00:49] DTMF[22360] channel.c: DTMF end '7' received on SIP/<MITEL>-0000004a, duration 140 ms
[2012-12-19 09:00:49] DTMF[22360] channel.c: DTMF end passthrough '7' on SIP/<MITEL>-0000004a
[2012-12-19 09:00:52] DTMF[22357] channel.c: DTMF begin '#' received on SIP/<MITEL>-00000049
[2012-12-19 09:00:52] DTMF[22357] channel.c: DTMF begin passthrough '#' on SIP/<MITEL>-00000049
[2012-12-19 09:00:52] DTMF[22357] channel.c: DTMF end '#' received on SIP/<MITEL>-00000049, duration 40 ms
[2012-12-19 09:00:52] DTMF[22357] channel.c: DTMF end accepted with begin '#' on SIP/<MITEL>-00000049
[2012-12-19 09:00:52] DTMF[22357] channel.c: DTMF end '#' detected to have actual duration 19 on the wire, emulation will be triggered on SIP/<MITEL>-00000049
[2012-12-19 09:00:52] DTMF[22357] channel.c: DTMF end '#' has duration 19 but want minimum 80, emulating on SIP/<MITEL>-00000049
[2012-12-19 09:00:52] DTMF[22357] channel.c: DTMF end emulation of '#' queued on SIP/<MITEL>-00000049I see a lot of the last 2 lines through out the logs. I’m trying to coorelate to see if these line up with the users who can’t get in. Could this be the problem? The system is not picking up the hash sign and just disconnects?
I’m also getting flooded from tiem to time with this:
WARNING[11906] app_meetme.c: Unable to write frame to channel SIP/-00000043
I’m not sure if that is related or not.