We have been having a serious problem of dropped calls with our SIP Trunk Provider on several Asterisk 1.8 systems.
We are getting call drops on about 1 in 8 incoming calls that are transferred in some manner. The transfer can be manual from extension to extension or from IVR to extension for example.
In debugging with the provider we have found that transferred calls are sending additional invites with Remote-Party-ID. This is causing them to sometimes drop the call.
We have tried setting on the trunk sendrpid=no but we then loose outbound callerID on the call setup and the recipient get the call from “Unknown Caller”
Is there a way to control the sending of Remote-Party-ID to just the initial invite and not create the additional invites during call transfers to the trunk provider?
These forum posts are basically the same problem. This work around may work but would be very inconvenient as we many different outbound callerIDs for different users and we would loose the UI ability to set these: http://forums.asterisk.org/viewtopic.php?f=1&t=80237&p=164872&hilit=rpid_update%3Dno+not+working&sid=f739815137364a03ac5ba84194995f92#p164872
It appears that these lines during the transfer are causing Asterisk to send these reinvites. The call flow is: Inbound call => IVR => Ring Group (ring all) => Extension.
-- Executing [s@macro-auto-blkvm:3] Set("SIP/7999-00008cdf", "MASTER_CHANNEL(CONNECTEDLINE(num))=7999") in new stack
-- Executing [s@macro-auto-blkvm:4] Set("SIP/7999-00008cdf", "MASTER_CHANNEL(CONNECTEDLINE(name))=Gary Test Phone") in new stack
This seems to be something related to the combination of Asterisk 1.8 and FreePBX 2.9
We can reproduce this problem in Asterisk 1.8.3, 184.108.40.206, 1.8.6 and 220.127.116.11. With CentOS 5.5 and 6.0 and FreePBX 2.9.
Both the Provider an I have been pulling our hair out over this. I also see that other providers like CallCentric are having problems with this issue.
Also, before you hit me with cross-posting, I had posted on the FreePBX forum yesterday but have not received any response there. After additional research into this issue, it seems like the Asterisk forum may be a more proper venue.