[SR-Users] Is this idea even feasible?

[Raúl Alexis Betancor Santana]

On Wednesday, August 18, 2021 1:22:47, Antony Stone wrote:

> > 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?

Off course, because your DUMB SIP client doesn't do it. If you do it on the B-Leg
of the call, that will be the Leg facing from your FS B2BUA to your PBX

> 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?

As I told you in the other message (I think it's pending aproval, because I send
it from an account that it's not directly subscribed to the list), you are in
urgent NEED to undestad how SIP works and the roles that the different tools
takes on a comunication between A and B.
You looks like trying to build the Piramids but neither know how a hammer works.

> 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?

That only depends on how you manage the call, from your DUMB SIP endpoint, point
of view, or from the B2BUA point of view.

> > 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.

Man ... it's like talking to a wall. Your lack any knowleadge of how SIP works
and still saying that a B2BUA it's not the solution to your 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.

Forget about how you think that things works, because your are fully wrong on that.

If you have a DUMB SIP endpoint, as you have, that lacks the features to put a call on hold,
transfer a call, etc. YOU ONLY HAVE 2 WAYS of solving that.

1) Throw that SIP Endpoint to the nearest trash bin you could find

2) Put a B2BUA in front of that SIP Endpoint, and throught API, DTMF, RPC or witchever 
method that B2BUA gives you, you will have to emulate what your SIP Endpoint doesn't support

Getting to this point, this is fully out of scope of this list, as Kamailio it's not a B2BUA
and will not (without TONS of work and hours) cover that special scenario you have.

You have been given with the hints about how to solve your problem, take them or leave them
but do not argue that It doesn't solve you issue, when you don't know how things works on first
hand.

Best regards.