My users began receiving a message saying “We’re sorry - your call cannot be completed at this time.” when placing calls this past Tuesday. One called a supplier 3x in a row from his desk phone and got this message every time, then got through first try using his cell phone.
I contacted our SIP trunk provider & they put detailed monitoring on our line, then began waiting for more of these calls to occur. There were 2 instances that I found yesterday afternoon.
The first one is from someone who recently changed providers and there’s a routing issue on their network - we can receive calls from the number, but calls from other networks cannot send calls to the number.
There was another call with this message which is not attributable to changes at the destination number. The tech at our provider sent the following explaining what is happening:
The additional monitoring we had in place provided some valuable insight. I observed that a carrier message, from downstream, is being sent to your IP address. Once that message ends and the downstream side closes the connection with a 500 response, a common way to end calls still connected after a carrier message. Upon the 500 response, we then send our carrier message indicating the call cannot be completed. Both messages are sent to the same port as the initial INVITE, but the first is delivered during early media, while our message is sent after the 200 OK. This helps explain the discrepancy in call durations – our records show a longer duration because we track at the begining of RTP, whereas your system may track from the 200 OK. I recommend reviewing how early media is being handled as it seems to not be reaching the end users.
I honestly don’t understand early RTP. We used to have the chan-sccp module loaded, which has a setting to set Early RTP, but I’ve been unable to find a setting anywhere in the system for chan_sip extensions. (That is the extent of my knowledge about early RTP.) Does anyone have any ideas?
If you have used chan_sccp, you presumably have CUCM at our end. CUCM uses late offer SDP, depending on the MTP? settings for the call. With late offer the calling device will not have a chance to say where to send media until the final response has been sent, as that information is carried in the SDP, in the ACK. You will need detailed protocol logs, to see if that is the case here.
We came from a managed phone provider - they used CUCM & I managed the configuration on their server. We migrated away from them in 2019 & are now on PBXact. Management wanted to keep the Cisco 7960 phones when we migrated, both because our people knew them & liked them as well as to save money by reusing existing hardware. I flashed the phones to SIP firmware and ran with that for several years.
A firmware upgrade to our edge firewall somehow killed the phone playing audio cleanly, so I installed chan_sccp to use the skinny protocol from the server to the phones, but this did not clear up the problem. All the Cisco phones have since been replaced with Polycoms and the chan_sccp module disabled in the PBX. (I only brought it up because I remember an early rtp setting & that’s where it was located, not in the core PBX.)
Are the callers on local extensions? Network operators often block early media that they didn’t originate, to prevent people making free, one way audio, calls.
Another thing that can break early media is if the caller is behind NAT relative to Asterisk. If, like most phones, they don’t compensate for that, Asterisk will need to rely on symmetric media, to establish their true external media address, but they probably won’t send any media until the call is answered.
All these options are why detailed logs make thinks much easier to understand.
I remember Early RTP setting having 5 options - none, progress, ring, and more. (It’s been a year and a half since I looked at the module & honestly cannot remember all of them. Since I do not understand what each does, they’re especially forgettable. )
All of our phones are local to our PBX. The PBX is behind a firewall and interfaces with our provider via a SIP trunk. When setting up the Cisco phones, they refused to work unless NAT was set to never in the extension options - I believe that they are all still configured that way.
The tech working on this sent me a pcap of a call showing what he found, but I do not know how to interpret what I’m looking at. However, it does have information in it about both our system & that of a random customer, so I do not feel comfortable sharing it.
After going back & forth with our provider several times with many different reports of the “We’re sorry, your call could not be completed at this time”, I believe an explanation has finally been uncovered.
With the exception of the first example of the guy getting that message when calling a supplier from his desk phone & getting through on his cell phone, every one of the numbers reported to me that generates this message has been disconnected when called from a cell phone.
The latest person I spoke with at our provider said that they recently migrated to a new session border controller as part of a merger and that BroadWorks (??) generates that message when it receives a 480 unavailable message from the far end of the call. When I asked why it doesn’t read the same message as when calling from a cell phone or land line (‘The number you have dialed has been disconnected’ in digitized 80s AT&T lady voice), he did not know, but said that it is not something that he can change. This seems a bit silly to me, but I have 0 control over their systems & the service has been excellent otherwise.
Learning this, I have advised my users that this is simply how the system reports disconnected numbers and to let me know only if they can get through on their cell phone when they get this message on their desk phone. Still don’t know what the early media settings are or how it’s handled, but while I do feel there was a glitch initially that corrected itself, reports since have been attributable to this change by our provider.
For the record, Early Media is determined by the receiving end (i.e. the callee). As the caller you have no control over if Early Media is going to be used.
You send an INVITE
Your provide sends back 100 Trying << If you do not get this back within a certain timeout it's considered a hard Timeout error meaning no response.
Your provider sends call to destination, mostly sends a 180 reply to indicating it's attempting the ring the user
At this point the far side can send back a 180 OR a 180 followed by 183 OR a 183 reply. << 183 indicates the far side has started early media, there will be a SDP body with codec/media details.
The far side either answers (200 OK) or then sends back a 486, 480 or even a 408 (user level timeout indicating no answer).
Carriers will use early media to play back things like “This number is not in service” messages. So if your provider is getting a 183 back from the far side and sending you a 500 error reply, that is 100% your provide refusing to accept early media on outbound calls. Some providers will block early media to avoid their users from getting audio without completion and thus can’t charge for it.
)
