Proposed Solution:
In order to solve this problem, we have decided to implement these steps:

• 1 - Add a new event in Asterisk Dialplan (xivo-config) at the user, conference, and meeting extensions configurations files. This new event has the following properties:

  • called WAZO_REMOTE_PARTY,

  • contains for now the type of remote_party (destination) that we want to reach: user, meeting, conference, or unknwon by default/missing,

  • conatins the id of the remote_party (either destination_user_uuid, conference_id, or meeting_uuid),

  • contains also the name of the remote_party that we want to describe.

• 2 - Add an interpretation function for the aforementioned event in order to extract the above three properties correctly,

• 3 - Created a new field called remote_party which contains the following two sub-fields:

  • kind: contains the type of destination extracted from the newly created event,

  • description: varies depending on the kind field; contains user_uuid and user_name in case it is a user, conference_id and conference_name in case it is a conference call, and meeting_uuid and meeting_name in case it is a meeting call.

• 4 - This new field has been implemented as the following:

  • Low-level (SQL database): as a new table called RemoteParty with the field description of type hstore; the field is then add to CallLog table by defining a One-to-One relationship between the two tables,

  • High-Level (Marshmallow Schema): as a fields.Nested field which contains the two fields mentionned above: kind as a fields.String type, and description as a fields.Dict format.

• 5 - Finally, the required integration tests (test_call_logs_generation.py and test_cdr.py) have been implemented to make sure that this new field is updated correctly for each test scenario.

Work to do:

• make sure to understand the “why”. If not, ask for clarification.

• design the new API fields and request for comments

• implement the new API fields