Summary: | ASTERISK-25381: res_pjsip: AoRs deleted via ARI (or other mechanism) do not destroy their related contacts | ||
Reporter: | Matt Jordan (mjordan) | Labels: | |
Date Opened: | 2015-09-07 11:36:51 | Date Closed: | 2015-09-08 14:05:31 |
Priority: | Minor | Regression? | |
Status: | Closed/Complete | Components: | Resources/res_pjsip |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ||
Description: | Say we have created an AoR, and then had a REGISTER request arrive that mapped to that AoR's endpoint. This will create a non-persistent contact object in Sorcery, which by default is stored in the AstDB. If the AoR is subsequently destroyed via ARI (using {{DELETE /asterisk/config/dynamic}}), the non-persistent contact is not removed. Persistent contacts, on the other hand, are removed as a result of being stored in the AoR's {{persistent_contacts}} container.
At first, this is relatively harmless, other than continuing qualify spam occurring for the now defunct contact. However, if we re-create the same AoR, the contact in the AstDB is treated as if it were a persistent contact (as it looks like one when the object set apply handler is called). This creates a weird situation where two things will occur: (a) Asterisk will fail to raise all of the necessary state changed events, as it will believe that the contact already existed. (b) The AoR will end up with two contacts, even if {{max_contacts=1}}: the original dynamic contact, and the fake pseudo-persistent contact it accidentally created from the dynamic contact. The proper thing to do is to destroy all contacts when an AoR is deleted via sorcery. | ||
Comments: |