|Summary:||ASTERISK-18999: Connected Line updates need a disable option on a per SIP device / trunk basis.|
|Reporter:||Gary Herbstman (gherbstman)||Labels:||asterisk colp|
|Date Opened:||2011-12-09 06:10:40.000-0600||Date Closed:||2017-12-19 09:39:26.000-0600|
|Versions:||184.108.40.206 13.18.4||Frequency of|
|Environment:||CentOS 5.5 and 6.0, FreePBX 2.9||Attachments:||( 0) Asterisk_capture_dropped_call_with_sip_debug.txt|
( 1) cap-cell-ivr-rg-ext7999-vp-filtered.pcap
( 2) Failed_call_flow.jpg
|Description:||Some SIP trunk providers do not handle the connected line updates well and are dropping calls. This feature can be disabled by setting senderpid=no on the trunk but this also prevents CallerID / Remote-PartyID to be set on the initial INVITE as well. We need to be abble to set the CallerID on the initial INVITE but NOT send additional INVITEs to the trunk as the call is transferred.|
The trunk provider Voicepulse in this case but seems to also occur with CallCentric, is sending back ERROR 491 and dropping the call.
This is somewhat related to this DAHDI bug ASTERISK-17025. Same problem but different code.
As a further note, Asterisk is sending not one but two updates to the trunk. One for device@extension and one for user name@extension.
|Comments:||By: Gary Herbstman (gherbstman) 2011-12-09 06:15:37.982-0600|
This is a capture of problematic call. The incoming call flow was: IVR => Ring Group => Extension. when the excention picks up, the update is sent to the trunk and the call is dropped.
By: David Woolley (davidw) 2011-12-09 06:51:07.808-0600
By: Thomas Arimont (tomaso) 2011-12-12 05:04:50.086-0600
Why don't you just disable the connectedline feature on a(ny) sip provider line (sendrpid=no) and build your own SIP Invite headers (remote-party-id, p-asserted-idenity, p-preferred-identity or whatever) using the SipAddHeader dialplan function instead? Since there are so many different implemented ways of CLIP (for incoming and outgoing SIP calls) on the part of sip providers, you have to differentiate between SIP providers in the dialplan anyway (if you want to support more than only one SIP provider).
That's the way we (as the initiator of the connectedline feature implementation) do it, and it works fine.
A simple Re-invite (without any additional/changed header) should not bother a SIP provider's protocol stack ...
By: Gary Herbstman (gherbstman) 2011-12-12 07:09:30.255-0600
Thomas, Because the customer will not be able to manage their system. They have multiple companies and different extensions need different outgoing callerID. They can easily manage this in FreePBX but I cannt ask them nor would I want them to be writing script.
By: Leif Madsen (lmadsen) 2011-12-14 14:21:33.963-0600
I have changed this to Minor and marked it as a New Feature, because that is technically what this is. Minor is because a workaround solution has been provided.
By: Mark Michelson (mmichelson) 2012-03-09 14:09:59.154-0600
I have identified several issues here.
First, when looking through your trace, it seemed weird to me that Asterisk was sending two connected line updates back-to-back. The first was sending an update with information as "Device <7999>" and the second was sending an update with information "Gary Test Phone <7999>". This corresponds to faulty dialplan. Specifically, I found these two lines in your log:
-- Executing [s@macro-auto-blkvm:3] Set("SIP/7999-0000a068", "MASTER_CHANNEL(CONNECTEDLINE(num))=7999") in new stack
-- Executing [s@macro-auto-blkvm:4] Set("SIP/7999-0000a068", "MASTER_CHANNEL(CONNECTEDLINE(name))=Gary Test Phone") in new stack
The problem is that after each CONNECTEDLINE function call, we will send a connected line update out. This means that the first reINIVTE updated the number to be 7999 and the second added on the changed name of "Gary Test Phone." There is an 'i' option that can be passed to the CONNECTEDLINE function which tells the function to store the changed information but not to send an update. This is useful for situations like this one where multiple CONNECTEDLINE calls are made and the update should wait until the final invocation. Adding the 'i' option to the first CONNECTEDLINE call would reduce the number of reINVITEs Asterisk sends to just one. Another solution for your particular case would be to combine the CONNECTEDLINE calls into a single Set(CONNECTEDLINE(all)) call instead and set both the name and number in that one instance of the function.
Now, having said that, I have a feeling based on the User-Agent header of your server that you are using FreePBX and you may not be able to make this change yourself. I am not familiar with FreePBX's options with regards to connected line updates, so I don't know what you would have to do in order to get this fixed using their GUI. If there do not appear to be any relevant options to set, then you may wish to file a report with FreePBX on the matter.
Now, having said *that*, the bigger issue here is the 491 response you're receiving from VoicePulse/CallCentric. A 491 response to an INVITE means that they cannot process the INVITE at the moment because they are in the midst of another INVITE transaction. Looking at the pcap, it's clear that there is no previous INVITE transaction that could be pending. I can only conclude that INVITE in frame 9 reaches your provider before the ACK in frame 8.
Sending a 491 is not correct behavior in this case though. According to RFC 5407, section 3.1.4, if a UA receives a reINVITE while in the "moratorium" state, then it is supposed to respond with a 200 OK, not a 491. What makes this particular case interesting is that I can see from the User-Agent string of the VoicePulse/CallCentric side that they are also using Asterisk. However, they are presumably using a very old version of Asterisk because I can remember this issue arising on the bugtracker and fixing it nearly 3 years ago (ASTERISK-13025).
Furthermore, even though your provider is incorrectly sending a 491, we *still* are handling this properly by ACKing the 491, and then sending a new reINVITE after a short period. Your provider now provides a 200 OK, which we ACK. For some reason though, your provider is retransmitting the 491 for the previous reINVITE, which we dutifully ACK. The fault is clearly with your provider for not being able to handle legitimate traffic from us.
Of course, I have the feeling that if you make the fix suggested at the beginning of this comment, then the 491 problem will cease to happen since Asterisk will not be sending as many reINVITEs.
By: Richard Mudgett (rmudgett) 2017-12-19 09:39:26.813-0600
Based upon [~mmichelson]'s analysis this is not a bug but bad dialplan and misbehavior of the telco as a result.