Connected line update prevented

My users report that our lines sometimes ring busy (when they are not) or that incoming calls disconnect immediately before they can pick up the phone i.e. 1/2 ring.

When I look at the log I see “connected line update prevented” just before the call disconnects i.e.

[2011-06-01 13:43:15] VERBOSE[30538] app_dial.c: – SIP/5144471234-00000bd6 is ringing
[2011-06-01 13:43:24] VERBOSE[30538] app_dial.c: – Connected line update to SIP/208.72.111.217-00000bd5 prevented.
[2011-06-01 13:43:24] VERBOSE[30538] app_dial.c: – SIP/5144471234-00000bd6 answered SIP/208.72.111.217-00000bd5
[2011-06-01 13:43:45] VERBOSE[30538] pbx.c: – Executing [h@macro-dial-one:1] Macro(“SIP/208.72.111.217-00000bd5”, “hangupcall,”) in new stack

or
Connected line update to Local/3338111@from-internal-2267;2 prevented.

Do your phones support connect line state and are they configured for it.

We use SPA2102 and HT286 and I don’t see that option anywhere in the manual or provisioning so I would say “no” to both questions. Never had this issue in Asterisk 1.6. Seems like many things have changed with no regards for backwards compatibility.

Do you have any suggestions? Anyone?

Having the same issues with spa509g’s did you find a solution?

I had a similar problem in a particular call flow scenario. Here is how the inbound call flow worked:

Inbound DID --> Time Group checks --> IVR
A particular option off of the IVR would drop the call into a Ring Group

When the ring group was answered, call would connect just long enough to display the caller id, then drop.

The issue was that Asterisk was sending back to the SIP trunk provider a connected party update. The SIP trunk provider didn’t like it and would drop the call rather than just ignore the update.

You can “sip set debug on” while doing a test call and watch the SIP messages to see if that is what is happening.

The resolution for my situation was in the SIP trunk: sendrpid=no

This prevents sending the update out that trunk.

Good luck!

We started seeing the same error message with Internal calls after switching to Asterisk 1.8.8.0 and FreePBX 2.9

I see this same error message on my system logs with no ill effects whatsoever.