Can I set the UUID for a call?

FreeSWITCH
1

Hi.

I have an application where calls are being passed from one Freeswitch server
to another.

In order to simplify tracking the calls and how they get processed on the two
systems, I would like to be able to send the first server’s UUID for the call
to the second server in a SIP header, and get the second server to use that
UUID for the call instead of making up a new one for itself.

I can pass the value between the servers in a SIP header without any problem,
and get the second server to log it etc., but I’ve been unable to set the UUID
from it.

If I do:

then the accountcode field in the CDRs get set with the transferred UUID (so at
least I have a way of correlating the calls together on the second server),
but trying something like:

does set the variable named “uuid” to the required value for the remainder of
the dialplan, but it doesn’t end up in the CDRs.

Is there any way to tell Freeswitch to use something specific for the UUID on a
call like this?

Thanks,

Antony.

2

I like to think through these kinds of scenarios, and my hope is you’ll find my thinking valuable addition to your exploration.

Assuming it was possible and going through the conclusions of what it would require, I would imagine this would be an anti-pattern for two reasons. First, allowing setting of the UUID at all means that every bit of the system has to handle the now-much-more-real possibility of collisions or have undefined behavior (much of which could be a security issue). Second, having the same UUID in multiple systems defeats the purpose of having UUIDs in the first place, since they’re supposed to be universally unique, not coordinated. Otherwise how would you actually differentiate what happened in System A vs System B? They need a unique identifier for the separation of concerns there.

All of that for supporting a very uncommon scenario, I think? It seems the sip header would be more useful, much like an extra request_id header in a web system gets passed around everywhere.

It’s possible they’ve already thought of this and you can override it, but I’d personally think the risks were worth avoiding even if the option is there. The SIP header can also coordinate across other systems, too, making other forms of cross-system troubleshooting easier without having to conform to a UUID for that use case (I’ve seen a bit of json with metadata about the user for instance).

I hope that is good food for thought.

3

First, allowing setting of the UUID at all means that every bit of the
system has to handle the now-much-more-real possibility of collisions or
have undefined behavior (much of which could be a security issue).

I don’t understand the part about collisions. I know what they are, but
surely if System1 has assigned a UUID (which is assumed to be unique on that
system) and then System2 uses that same UUID (and does not assign its own
UUIDs) then they remain unique on each machine, but are simply shared
(identical) on System1 and System2?

Second, having the same UUID in multiple systems defeats the purpose of
having UUIDs in the first place, since they’re supposed to be universally
unique, not coordinated.

Well, I think that depends on what you define as “a system”. Is it a single
machine, or is it a tightly-coupled pair (possibly group) of machines?

I think that so long as the system architect understands what the ID is
supposed to be unique to, it can safely be shared amongst multiple servers
without any problem.

Otherwise how would you actually differentiate what happened in System A vs
System B? They need a unique identifier for the separation of concerns there.

There is still the aspect of where the information comes from. The CDRs on
System A for a given UUID will show what System A did with the call. The CDRs
on System B for the same UUID will show what it did with the call.

I don’t see any confusion there.

All of that for supporting a very uncommon scenario, I think?

It might be uncommon, but I’m still wondering whether it can be done.

I often find myself dealing with requirements which are “uncommon” but entirely
reasonable in a specific situation.

It seems the sip header would be more useful, much like an extra request_id
header in a web system gets passed around everywhere.

But, if the SIP header doesn’t get recorded in the CDRs, it can’t be used to
follow the processing of the call on System2. Or did I misunderstand what you
meant by “the SIP header”?

I hope that is good food for thought.

Indeed, and thank you; however I hope you can see that I think I have a good
reason for wanting to do this, and have thought about why it would not be a
problem. From my perspective, the question comes down to “what size ‘system’
is this thing supposed to be unique to?” Is it a single machine, or is it a
cluster of machines?

Thanks,

Antony.

1 Like
4

The collisions part is just that if you allow setting of the thing, you allow users the room to shoot themselves in the foot and your system has to handle those scenarios as they are now possible. You are describing a way to make it safer, but not safe. E.g. what if you have to retry the SIP call, and now you have two calls with the same UUID in System2? Always the gotchas in computing, to say nothing of someone down the road (usually me) forgetting that guarantee I made with myself and everything breaks accordingly, but now I don’t have any debugging capabilities because I broke the assumptions everything was designed around. (I think it’s worth re-stating the security problem as well, if there’s security assumptions around the universal uniqueness of the domain of that id.)

As for the sip header getting logged or not, I think that’s a specific form of the question. I think of these types of metadata more broadly. Not just logging, but also can it tie to the user database, the web server providing the dialplan, the phone app on mobile, the billing system. The request id header comparison seems very apt as people smarter than us have been in those trenches for a very long time. In a large system like a cloud vendor, a request will go through dozens of teams’ services, so we already know from their experience that the more metadata you can coordinate the more you can do with it both during the request’s lifetime and in the future.

Anyway, a fun exercise. I wish I knew if it could be done, that would be a more definitive answer, but the thought was still useful to me. I hope you figure it out and post back, as I’d love to know about the possibilities, too.