Is there a way to disable or configure the Conference Bridge Module to change behavior if a call is dropped. We have a customer that states if they lose voice connection during a conference bridge when the dial back and re-connect to the conference they then get a dial back from the conference bridge. They would prefer the system not call them back in the above scenario. Version is 4.5.4
John Wable
Mark,
We were able to narrow it down enough to figure out a work around. It appears that anytime the end user opened a bridge with the bridge ID 0517 at various times throughout the bridge the carrier would actually initiate the dial back. It only happened when using that call bridge number. The carrier ran traces and could see the call going out but was not able to see what generated it. However on my end the Adtran showed no logs of an outgoing call, the InGate Insiperator had no logs of an outgoing call at the time. So the best I can figure is that the Carriers Broadsoft switch interperated the 0517 with some sort of internal function causing a dial back to occur. I am thinking many people becuase they are used to it may be dialing bridge 0517# and the extra # may have tripped something like a spree code as the SIP traffic was hitting Broadsoft. So the short answer is it was not Adtran doing it, and it was not the Gateway doing it. It was something in Broadsoft causing it to occur. And the work around was not to use Bridge 0517 anymore.
John Wable
John,
I am not aware of this feature with our conference bridge on where it calls a user back when they lose voice connection to the bridge. I also verified this with engineering. The only feature that we have that does this is when you park a call.
What is the conf bridge setup? Are you calling the default 7050 in the dial plan or do you have a custom service set for the conf bridge?
If you are using just the default conf bride in the ECS dial plan, then please provide a packet capture via Wireshark of a caller in the bridge and then losing connection if you are able to re-produce it and put it in a .zip file and put it on our FTP server with the instructions below I would be happy to review it.
Open Internet Explorer web browser on their PC
Type the following URL: ftp://ftp.adtran.com
Press the Alt key, click View, and then click Open FTP Site in Windows Explorer
Double-click the "Incoming" folder
Drag and drop files from PC into the Internet Explorer window
-Mark
Mark,
Thanks for the reply I was expecting that to be the answer but was trying to verify it. After additional talks with the customer the issue seams to be limited to one specific user. They are calling into a DID that points to the defaults 7050 conference service. THey call in from a cell phone and connect, if they get disconnected they call back in and rejoin the conference and then right after they connect everyone on the conference hears a phone dialing, followed by ringing that user hears the ringing not only on the conference call but there cell phone ringing as well, then his cell phones voice mail is heard over the conference call, after the call if he dials back into his voice mail on his cellphone he has a message containing the conference call. It has happened several times to this specific user however no reports of it happening to anyone else. I think either the user is having issues with there cell phone or there maybe a speed call for his cell phone which is getting triggered from the dial in process somehow. However it only happens after his call gets dropped not the first time he dials in. I will try to get the customer to recreate the issue and get the requested information to try and narrow it down. THanks for the reply.
John Wable
John,
If you are able to get the customer to reproduce, then go to the C:?adtranlogs folder and copy the current syslog.txt file. Then delete origanal one right before the customer tests. Then copy the syslog.txt file and put it in the .zip file along with packet capture. Yeah sounds like something going on with the customer's cell phone. Very interested on who is calling the customer back.
Have a good weekend!
-Mark
John,
Just following up to see if you found or fixed the problem. If so, could you post an update.
Thanks,
Mark
John,
Just following up again to see if you need anything. If you have time, could you post and update or if this was resolved and the fix.
Thanks,
Mark
I went ahead and flagged this post as "Assumed Answered". If any of the responses on this thread assisted you, please mark them as Correct or Helpful as the case may be with the applicable buttons. This will make them visible and help other members of the community find solutions more easily. If you still need assistance, we would be more than happy to continue working with you on this - just let us know in a reply.
Thanks,
Matt
Mark,
We were able to narrow it down enough to figure out a work around. It appears that anytime the end user opened a bridge with the bridge ID 0517 at various times throughout the bridge the carrier would actually initiate the dial back. It only happened when using that call bridge number. The carrier ran traces and could see the call going out but was not able to see what generated it. However on my end the Adtran showed no logs of an outgoing call, the InGate Insiperator had no logs of an outgoing call at the time. So the best I can figure is that the Carriers Broadsoft switch interperated the 0517 with some sort of internal function causing a dial back to occur. I am thinking many people becuase they are used to it may be dialing bridge 0517# and the extra # may have tripped something like a spree code as the SIP traffic was hitting Broadsoft. So the short answer is it was not Adtran doing it, and it was not the Gateway doing it. It was something in Broadsoft causing it to occur. And the work around was not to use Bridge 0517 anymore.
John Wable
Thanks for the update John. Glad you got it resolved.
-Mark