Freeswitch quirks to handle: myevents/linger, uuids, bgapi, ChannelState/CallState

[Netzvamp]

These are some of the unique quirks to handle when we implement channels.

myevents/linger

The myevents command is evil and shouldn't be used. What it does it to set a hard filter to the uuid of the current outbound session. On first glance this is ok, until you realize there is no way to modify this filter. With myevents used you can't create a new channel and get the events for that channel, even if you use "filter" to add another uuid. The only valid way is to not use myevents and set the filter manually, so you can add to it later.

filter Unique-ID {aleg_uuid}

That way you can create a new parallel channel to the already existing channel, for scenarios like manual waiting queues and just add this new uuid to the filter with filter Unique-ID {bleg_uuid}. Thats impossible with myevents active.

With that in mind: If you activate linger (keep outbound connection after hangup) you can still manage the other channels you created in the background.

When we abstract channels into objects, we should hardcore some things like myevents and linger, to have predictable call flows, or it will be hard for the user to understand why he creates channels and nothing happens or why freeswitch is killing connections while he still has channel open.
That means we have to manage filters, but that's no problem when you define your own uuid.

Funfact: A outbound socket with linger and without any filter is the same as an inbound socket.

UUIDs

Wherever possible we should set the uuids by ourself when we execute or create something inside of freeswitch. That way we don't have to wait for the freeswitch answer with the uuid the server has given to a task. Without manual uuid assignement this also could cause strange bugs, where we assign the wrong answer events to a command we initiated. When we have the control over the uuid in the first place, its clearly defined and we should use that.
And no, we shouldn't use api create_uuid, just use the python uuid lib to get a uuid4().

bgapi

We should use bgapi wherever possible. If you start something with sendmsg or execute and it takes longer freeswitch stops sending events until the execution is finished. It depends on the application how long it stops, some stop only for a short time, create their own event to signal they've done something and then another event to signal finished, but some just hanging until they are finished and that are the problematic. And also for async reasons we should use it everywhere.
However: There are some application that don't need bgapi, like hangup, because they don't have any wait time.
There are some quirks to it: BACKGROUND_JOB isn't necessarily related to a session, so you need to create your own uuid and add them to the filter with filter Job-UUID {job_uuid}. This also only works when we don't use myevents.

ChannelState/CallState

Both look similar, but they are not. Channelstate is the core state of the channel while CallState holds the overall channel status, but isn't that well defined in an enum like Channelstate. Since we got both in nearly every event we should track them both in objects.

I've implemented my channels with that quirks in mind. The filtering is important.

[Otoru]

We're mixing up a lot of different things in this topic. We will address the other topics in other discussions if it is relevant., I'll stick to the issue of myevents:

What you said went right over my head. I think a good approach for this case would be to change the default value we have today to false and start sending the equivalent filters if we don't have myevents, something like a sequence of:

• filter Unique-ID

Since we already have the UUID of the session that we already have in the outbound context. What do you think?

[Netzvamp]

Yes, that would be fine, change the default to false and manually set the filter for Unique-ID.

[Otoru]

@Netzvamp see the changes I made to the documentation and how I handle the myevents parameter. I believe it's closer to what you described.

PR: #62