Answered Elsewhere


Could someone offer some clarification on this error?

“SIP Internal Call Failure (1 Events)
2019-05-15 16:02:40 SIP internal call failure! from user: (xxx) xxx-xxxx , to user: 1014 , SIP response code: Answered elsewhere”

It’s never generated a ticket by any of my customers, I’ve only seen it a couple times in the last couple years. I’ve got nothing going on that urgent about this. I’m mostly just curious.



roughly is the mistake you find in this link, which is driving me crazy to fix:

even your mistake sometimes happens to me, seems to say “… that call has been answered from another position”.


Typical usege:
call -> ring group (all ring) -> 1pickup. rest phones in RG will receive" Answered elsewhere". It will notice phone to not store that call as missed (after all it was answered by other phone).


UCM actually reports it as an error/fault.
If it were simply that there was a pickup I would see that error all the time.
And it’s not like that.
It could be that there was a combination where two extensions made the pickup at the same time, obviously only one was successful, and the other UCM pickup interprets it as an “anomaly”.
I’m always in the conditional.


Rapport this via GS ticket, it is 3xx response but that is redirection service not fault 4xx so i think it should not be in error log.


It is not possible to have a single call answered exactly at the same time by different devices. The UCM processes the data streams serially. As a result, whichever endpoint’s data stream reaches the UCM first will have answered the call with the 200OK?SDP and subsequent ACK from the UCM. The second 200OK will receive CANCEL.


As far as the message goes, it is not an error. The message is reporting a reason header associated to a sip response in a cause code. You likely have more than one endpoint with the same extension on it and when a call came in and was sent to both (or more) one answered which then resulted in a cancel to the other(s) with the reason in the cause of the cancel.

I assume it was not a ring group because if you expand the CDR record, you will see how the call progressed thru each step to get to its destination one of which would have listed the ring group.

Damiano, no relation to your issue. This is normal, yours is not, or least not yet till you find out.


Unfortunately I know :frowning: