[SR-Users] Is this idea even feasible?

Antony Stone Antony.Stone at kamailio.open.source.it
Wed Aug 18 14:22:47 CEST 2021

On Wednesday 18 August 2021 at 13:40:25, David Villasmil wrote:

> In freeswitch you have the uuid_hold, etc api:
> https://www.freeswitch.org/confluence/plugins/servlet/mobile?contentId=1966
> 741#content/view/1966741
> You call the API uuid_hold [uuid] or uuid_hold off  [uuid] to take the
> channel out of hold.
> UUID in freeswitch is what uniquely identifies a given channel.

But, would that not perform the hold function on the FreeSwitch server?

And, if after putting it on hold, I need to transfer a call to another number 
/ channel, that transfer would also take place on the FreeSwitch server?

Or am I misunderstanding, and FreeSwitch can pass the instruction to "place 
the call (channel if you prefer) on hold" on to the PBX system which my 
existing client application is placing its calls through?

> When you say:
> “However, my understanding of a B2BUA is that *it* would then start
> handling the state of the calls itself - whether they're on hold, routing
> the transfers, etc.”
> This is correct, that’s how B2BUA works, but you can send an API to fs via
> ESL (tcp connection on port 8021) to put on hold not just your channel,
> since that would simply send a reconly to your app, but also the B-leg of
> the call.

This all sounds as though I am getting FreeSwitch to "do the work" and manage 
the hold/transfer/resume/conference/whatever itself.  I could do that with 
Asterisk (which I already know, whereas I haven't used FreeSwitch), but it 
isn't a solution to my needs.

I need something which will *tell the existing PBX* to do these things (and 
it's probably not running FreeSwitch), in just the same way as pressing the 
buttons on a competent SIP phone such as Yealink or Polycom would tell the PBX 
to do it.


The Magic Words are Squeamish Ossifrage.

                                                   Please reply to the list;
                                                         please *don't* CC me.

More information about the sr-users mailing list