Randomly occuring re-invite errors on originate

I have a situation that has appeared recently. Basically when I attempt to do AMI based operations that will cause a particular phone to ring (either to play a recording or to connect it to another channel) this error occurs:

chap_sip.c:20453 handle_response_invite: Re-invite to non-existing call leg on other UA.  SIP dialog '<someID>'.  Giving up.

Nothing I do (cycle my phone, reprovision my phone, do “sip reload” at the CLI, cycle the core, etc) can make this problem go away. So it’s probably an issue at the openSIPs proxy, but I’d still like to better understand what exactly Asterisk means when it displays this error.

Can someone explain in detail what this error means in Asterisk/SIP novice terms? Also if someone’s had this issue and solved it, that info couldn’t hurt either. Thanks.

EDIT: This issue only seems to happen to my hardphones. When I initiate the same AMI actions to a softphone, there are never any problems. The originate/whatever goes through every single time.

I suggest you increase debug and verbose message level. This should provide you more information on the nature of the problem. I guess, most probably the re-Invite is pointing to a call-id that does not exists.

Asterisk received a 408 or 481 response to a re-invite that it sent. Note that it is not Asterisk that is claiming there is something wrong; it is just passing on the bad news.

21.4.9 408 Request Timeout

The server could not produce a response within a suitable amount of
time, for example, if it could not determine the location of the user
in time. The client MAY repeat the request without modifications at
any later time.

21.4.19 481 Call/Transaction Does Not Exist

This status indicates that the UAS received a request that does not
match any existing dialog or transaction.

UAS = User Agent (Server)
Re-invite means using INVITE mid-call to change some setting.

When Asterisk sends 481 (it is receiving it here), it normally means that the tag value is wrong on a To or From line.

Thanks for the replies. Turns out it was just Asterisk forwarding bad news from the SIP provider.