Connected Party Identification, sendrpid, transfers

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:

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,, 1.8.6 and 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.

This is the result of introducing a much demanded new feature to update the display on the caller’s phone when transferring a call. I don’t know if it can be disabled, but maybe this will give you a clue as to what to look for in sip.conf.

yes, this is a good feature and we look forward to implementing it however, the trunk providers are hiccuping on this. I have looked thru the documentation and even some of the source code. There is not too much information on this.


Appears to be have been submitted as:

Note that the actual rules for SIP bug reports require the use sip set debug and sip set history output. Wireshark captures are less likely to get looked at.

I have updated the bug report with the Asterisk and SIP debug.