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.