We are having a problem with one of our trunk providers on incoming calls that go thru the IVR and ring groups. When the call is transferred to the final extension, Asterisk is sending two invites to the trunk with a Remote-Party-ID for the extension and the name.
Our trunk provider randomly (1 in 8 times) drops these calls with a “Error 491 Request Pending” The trunk provider claims they do not support INVITEs inside the call. I can turn them off by setting the sendrpid=no but then our outbound callerID does not work.
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.3.3, 1.8.6 and 1.8.7.1. With CentOS 5.5 and 6.0 and FreePBX 2.9.
Is there a way to prevent these INVITEs during call transfers without effecting the initial call INVITE?
I hope this is enough information to get help solving this. I have many many hours of pulling out the little bit of hair I have left.
Unfortunately canreinvite which has been replaced by directmedia in Asterisk 1.8, only affects reinvites for the direct audio connection. It has no affect on the reinvites for the callerID updates.
Yes that is all part of the CCSS stuff in asterisk 1.8 that we put in FreePBX. Sending reinvites during a call is normal and the carrier should ignore them if they can not do anything with them but dropping a call is foolish and not something they should be doing.
This is how we update the Caller ID when you do a attended transfer so the person who gets the transfer gets the updated Caller ID and not show they are talking to the extension that transferred the call to them.
Here’s what Callcentric had to say about why incoming calls would drop when they were transferred out of an IVR:
The issue here is with how your asterisk attempts to send this information. As mentioned previously your asterisk PBX is doing two things:
1 - Attempting to reference a call on our servers using the Contact field from the original INVITE in order to update the callerID: INVITE sip:[email protected]:5060;transport=udp SIP/2.0.
This is not supported as the reINVITE process should be handled on your PBX with an inbound and outbound leg which are then bridged within asterisk and not an attempt to divert/update the original call mid-transaction/process.
2 - The callerID your asterisk is attempting to use in this reINVITE is not valid: Remote-Party-ID: “device” sip:[email protected];party=called;privacy=off;screen=no
In this case you need to do two things:
1 - Correct the callerID for either extension 40, the ring group, outbound route or the Callcentric trunk your calls are going out on.
2 - Make sure that your configuration is correct for performing the correct re-invite, which is why we requested the information in our last response.
If you have any further questions on this issue please do let us know.
this is probably a bug in when we are choosing to send the CONNECTEDLINE() updates for the reverse callerid. (and btw … when Tony said CCSS he was thinking CONNECTEDLINE
anyhow, best thing is to file a bug report in the tracker and include a CLI trace of an incoming call where this happens, as well as turning on SIP debug. Try not to have any other calls going on.
If you can get it with the carrier hanging up the call that is great, though not necessary. Just want to see the full call flow of the type of call that this happens on so we can come up with the best solution.
I am not sure if what CallCentric says about the details of the invite being incorrect are valid. VoicePulse has been very responsive with the issue and have been looking into it.
I feel that the itsp should just ignore it and not drop a call.
I have found if you set sendrpid=no on the trunk, the invites stop and so does your outbound callerID if you have fromuser set to anything. The combination of sendrpid=no and no fromuser seems to stop it.
It still appears Asterisk has issues with this processing. It is sending the Remote-Party-ID invite twice in a row, once with “device” and then again with the extension user name.
whether or not Asterisk should have a setting to prevent this I don’t know as I have not thought about it much, though I wouldn’t count on a quick turn-around with them even if they do.
However, we are still the ones triggering the event so a ticket with us is needed and a CLI + sip debug trace would be very helpful in the suspect scenarios so we can see where we are triggering them and address it if it is in fact in our control which I think at least the extension update is.
I have to admit that this is all WAY over my head. I know what Callcentric told me, but I don’t really have a good understanding of what they mean by it, or what I should put in a bug report on it.
I just know that when calls come in on a Callcentric trunk and they get transferred internally, Callcentric drops them. I wasn’t having the problem on Flowroute or on VOIP.ms, so I was assuming that it was Callcentric’s problem until I saw this thread.
I generally agree that an ITSP should just ignore these issues, rather than dropping the calls, and that’s what VOIP.ms appears to do.
Has a bug report been opened by the OP? Do you need anything from me? If so, please be specific and give easy to follow instructions!
BTW- I do have a logfile that I provided Callcentric with Debug on that shows CC dumping the call if you have a place for me to upload it. I’d rather not post it, because it is LONG and I don’t want to review it for personal info (i.e. passwords, phone #s, etc). If you want me to e-mail it to you, I’m happy to do that…
not looking for a super long log file, simple a CLI trace with SIP debug in Asterisk turned on starting with a single call coming into the system and ending when the call is answered, which I presume is when the call gets dropped.
This can be pasted into a ticket without being too long and to my knowledge, there has not been a ticket open.
Has anyone opened a ticket on this yet? Asking for bugs to be looked at in a Forum post usually wont get many developers involved. Please open a bug report for us and we can take a look at things. Please include a CLI trace of the call.
it’s not clear that the issue is an Asterisk issue as I think I mentioned as I’m pretty sure we trigger the new INVITE with the CONNECTEDLINE() call, and thus Asterisk is just doing what we say.
I glanced at your trace in the Asterisk ticket, you have sip debug turned on calling a ring group with at quick glance looks like over half a dozen extensions on it. You would be a lot better off getting some of us (or the Asterisk folks) to look at this if you could recreate the problem with a single call to one extension without the ring group or if you need the ring group to re-create the issue then create a single extension ring group and redo the trace. Also, probably better off setting the sip debug to just the trunk and not all sip extensions so that you can eliminate more of the irrelevant traffic in the trace.
However, from glancing at our forum post it looks like you isolated it down to the CONNECTEDLINE() calls that get called in the post answer macro of the ring group. Is that the case? And … if you route a call directly to an extension do you get the same issue or is it required that the channel is first answered like in your call trace where you are running through an IVR and it is answered for the playback?
And … if you comment out the calls to CONNECTEDLINE() in the extensions_additonal.conf file (the ones that appear to be the culprits) does the issue go away? Let me know, if so, open a ticket on trac with the summary of what you found and I’ll get a patch up that will skip the CONNECTEDLINE() if the calling party is not another extension (which is really the intent of all that) so that you can test and confirm if it address the issue. Thanks.
The ring group or some king of transfer is needed to reproduce the problem as it is needed to create that update. The pcap which is MUCH easier to follow, filter and view, it also trimmed down to just the trunk and extension that picked up the call. I find that trying to follow the SIP debug in the Asterisk log is a nightmare and very difficult to find what your looking for. The system also has many extensions which are always showing up in the debug for registrations and updates. It really needs improvement. I already had spent time removing some of the debug text that was irrelevant (about half).
I have commented out the ConnectedLine calls and it still seems to occur. I am thinking something in Asterisk is noticing the change in endpoint and doing it on my behalf. I have spent close to 100 hours on identifying and detailing this problem so far. I am pretty convinced this in in Asterisk at this point.
I understand the pcap’s are much easier to track down, but they don’t help in correlating back to the dialplan. You can use the CLI ‘set sip debug peer xzy’ to the given peer (or ‘ip xx.xx.xx.xx’ in place of peer xyz) to remove much of the other traffic.
Concerning to the CONNECTEDLINE() calls, did you comment out ALL of them as they show up in several places? in the case of ring groups, I believe the one that are used are in macro-auto-confirm and macro-auto-blkvm. Furthermore, did you comment out any code that adds the “I” option to the dial() command which I think is needed to trigger the updates once a line is answered?
If you have not tried the following to see if it reproduces it. Create an inbound route directly to an extension and set that route to detect faxes, pointing the fax destination to the same extension. This will have the affect of answering the call during the inbound route process before sending it on. I believe doing such will then force Asterisk to require the INVITE() update since the line has been answered before the CONNECTEDLINE() where as I believe if the line is not answered yet then it just puts the remote party id information in the ACK when the call is eventually answered.
into 2.9 may help here, it doesn’t do the CONNECTEDLINE() updates if the caller is not a local extension, since it doesn’t make sense to otherwise do it anyhow. This has not been published out yet as it could use some testing.
