Hi.
I have a very basic SIP client application, which can make and receive phone
calls, and that's about it. Regard it as a pretty dumb softphone.
Unfortunately I cannot change it for a smarter one.
This client is talking to a completely capable SIP server (PBX) which can do
all the standard PBX stuff like putting calls on hold, transferring them,
conferencing, etc.
The problem is that the simple SIP client cannot itself tell the server to do
any of these things - it can send an INVITE to place a call, and it can
REGISTER and then accept an INVITE to receive a call, but it doesn't know how
to send any other commands to the server to "manage" calls once they're in
progress. The simplest example is putting a call on hold and then resuming it
later.
I'm looking for something which I can place in the network path between the
client and the server, which can send these call control commands on to the
server, so that it can then put calls on hold, transfer them, etc.
I'm assuming this "thing" needs to sit in the network path, so that it sees
the INVITEs and OKs and is then aware of the Call-IDs and sequence numbers,
etc, and can therefore present the correct call reference to the SIP server
when it wants to say "please put this one on hold". I have full access to the
SIP credentials used to authenticate the client to the server.
I had thought that Kamailio might be what I was looking for, but I've asked on
their mailing list and people are telling me that it isn't, and have suggested
PJSIP as a potential solution.
Is that possible? Could I somehow use PJSIP to generate and send commands to
a SIP server in order to control calls which have been placed either from or
to this simple SIP client softphone application?
If anyone thinks there is another, perhaps better, way of achieving this, then
I'm quite open to alternative solutions (as I say, I was initially thinking
that Kamailio might be the way forward), so anything that shows me how such
a thing might be achieved, with any tool at all, would be very welcome.
Thanks,
Antony.
--
Anyone that's normal doesn't really achieve much.
Mark Blair, Australian rocket engineer
Please reply to the list;
please *don't* CC me.
On 18.08.21 13:35, Antony Stone wrote:
Hi.
I have a very basic SIP client application, which can make and receive phone
calls, and that's about it. Regard it as a pretty dumb softphone.
Unfortunately I cannot change it for a smarter one.
This client is talking to a completely capable SIP server (PBX) which can do
all the standard PBX stuff like putting calls on hold, transferring them,
conferencing, etc.
The problem is that the simple SIP client cannot itself tell the server to do
any of these things - it can send an INVITE to place a call, and it can
REGISTER and then accept an INVITE to receive a call, but it doesn't know how
to send any other commands to the server to "manage" calls once they're in
progress. The simplest example is putting a call on hold and then resuming it
later.
I'm looking for something which I can place in the network path between the
client and the server, which can send these call control commands on to the
server, so that it can then put calls on hold, transfer them, etc.
I'm assuming this "thing" needs to sit in the network path, so that it sees
the INVITEs and OKs and is then aware of the Call-IDs and sequence numbers,
etc, and can therefore present the correct call reference to the SIP server
when it wants to say "please put this one on hold". I have full access to the
SIP credentials used to authenticate the client to the server.
I had thought that Kamailio might be what I was looking for, but I've asked on
their mailing list and people are telling me that it isn't, and have suggested
PJSIP as a potential solution.
Is that possible? Could I somehow use PJSIP to generate and send commands to
a SIP server in order to control calls which have been placed either from or
to this simple SIP client softphone application?
If anyone thinks there is another, perhaps better, way of achieving this, then
I'm quite open to alternative solutions (as I say, I was initially thinking
that Kamailio might be the way forward), so anything that shows me how such
a thing might be achieved, with any tool at all, would be very welcome.
Thanks,
Antony.
If I understand correctly, you want to be able to (un-)hold and transfer
calls.
If you want to hold/transfer "your" calls, you can do so already (like
any other SIP phone).
For holding/unholding calls, see the functions
pjsua_call_set_hold()/pjsua_call_set_hold2() here:
https://www.pjsip.org/docs/latest-2/pjsip/docs/html/group__PJSUA__LIB__CALL.htm#gabc6cf34d2b241224230701025eef489a
For transferring calls, you can initiate a transfer via REFER using i.e.
pjsua_call_xfer():
https://www.pjsip.org/docs/latest-2/pjsip/docs/html/group__PJSUA__LIB__CALL.htm#ga97637997a55ef0246aae5b3d171532f2
If you want to manage all kinds of calls on your PBX, then this is
outside the scope of the SIP protocol and you need to check
with the PBX developers. In my experience, they usually offer some kind
of "management" interface/protocol which you
can use to control the PBX. For an Asterisk PBX, this would be the AMI
and ARI interfaces.
Hope this helps,
Andreas
On Wednesday 18 August 2021 at 14:19:56, Andreas Wehrmann wrote:
If I understand correctly, you want to be able to (un-)hold and transfer
calls.
Correctly understood :)
If you want to hold/transfer "your" calls, you can do so already (like
any other SIP phone).
For holding/unholding calls, see the functions
pjsua_call_set_hold()/pjsua_call_set_hold2() here:
https://www.pjsip.org/docs/latest-2/pjsip/docs/html/group__PJSUA__LIB__CALL
.htm#gabc6cf34d2b241224230701025eef489a
For transferring calls, you can initiate a transfer via REFER using i.e.
pjsua_call_xfer():
https://www.pjsip.org/docs/latest-2/pjsip/docs/html/group__PJSUA__LIB__CALL
.htm#ga97637997a55ef0246aae5b3d171532f2
Okay, that sounds excellent - thank you :)
Where should I start with a guide to how to get PJSIP installed into my
network path so that it sees the call setups between the SIP client and the
server, and I can start using these functions to manage the calls?
Sorry for such a basic question, but I have never used PJSIP before, so a
pointer in the right direction to get me started would be most helpful. If it
matters, my SIP client is currently running under Debian Linux, and I'd be
happy to install PJSIP on the same machine, or another one in the network,
whichever is best.
If you want to manage all kinds of calls on your PBX, then this is
outside the scope of the SIP protocol and you need to check
with the PBX developers.
I don't want to do anything which a standard SIP telephone can't do, therefore
I am only looking to do things within the scope of SIP.
In my experience, they usually offer some kind of "management"
interface/protocol which you can use to control the PBX. For an Asterisk
PBX, this would be the AMI and ARI interfaces.
Well, yes, and in some cases the PBX I am talking to will be Asterisk, but
after asking about this topic on the Asterisk mailing list, I got the simple
confirmation from Joshua Colp, one of the Asterisk developers, that call hold &
resume simply isn't possible using AMI.
I find it strange, since AMI will happily notify you of calls being put on
hold or resumed, but there is no way to use it to put a call on hold.
However, as I say, I'm not trying to do anything outside the scope of SIP, and
I would really prefer not to have to implement a different way of doing it for
every SIP-based PBX I end up having to register an extension to. Many vendors
would not even tell me what access credentials I could use to connect in the
first place, whereas I always know the SIP credentials for the extension
assigned to my client application.
Thanks,
Antony.
--
Perfection in design is achieved not when there is nothing left to add, but
rather when there is nothing left to take away.
Antoine de Saint-Exupery
Please reply to the list;
please *don't* CC me.
On 18.08.21 14:38, Antony Stone wrote:
On Wednesday 18 August 2021 at 14:19:56, Andreas Wehrmann wrote:
If I understand correctly, you want to be able to (un-)hold and transfer
calls.
Correctly understood :)
Looking at your response, I think I misunderstood you, at least partially.
When you wrote you had "a very basic SIP client application",
I assumed you wrote this client yourself using the PJSUA API.
Putting PJSUA in the middle and behaving like a SIP proxy is not possible,
though you might be able to implement a B2B UA using the PJSUA API.
Would it be a problem to use another SIP client?
pjproject provides a test application "pjsua-app" which let's you do
what you want.
All the best,
Andreas
On Wednesday 18 August 2021 at 14:51:39, Andreas Wehrmann wrote:
On 18.08.21 14:38, Antony Stone wrote:
On Wednesday 18 August 2021 at 14:19:56, Andreas Wehrmann wrote:
If I understand correctly, you want to be able to (un-)hold and transfer
calls.
Correctly understood :)
Looking at your response, I think I misunderstood you, at least partially.
When you wrote you had "a very basic SIP client application",
I assumed you wrote this client yourself using the PJSUA API.
Oh, no - this is a type of "click to dial" softphone app (no idea what it is
based on) which can place and receive calls using the SIP protocol (and it
handles the RTP media as well), but does nothing beyond those very basic
functions.
Putting PJSUA in the middle and behaving like a SIP proxy is not possible,
Do you (or anyone else here) have a suggestion of what might be able to act in
that way? I initially thought that Kamailio would be a solution, but people
on their mailing list tell me it isn't (and indeed suggested PJSIP).
though you might be able to implement a B2B UA using the PJSUA API.
The problem with implementing a B2BUA (as I understand it, happy to be
corrected if possible) is that the hold and transfer functions would then be
being performed inside this new component in the network.
I need them to be performed in the existing PBX server, just the same as they
would be if I plugged in a competent SIP phone and could press the "hold"
button.
Would it be a problem to use another SIP client?
Yes, I am stuck with the client application we have; I'm trying to find a way
of implementing something which understands more about SIP in order to manage
the calls.
pjproject provides a test application "pjsua-app" which let's you do
what you want.
I'll take a look, but it sounds like it assumes it is part of the client
itself, rather than something in between client and server.
Thanks,
Antony.
--
Don't procrastinate - put it off until tomorrow.
Please reply to the list;
please *don't* CC me.
On 18.08.21 15:03, Antony Stone wrote:
though you might be able to implement a B2B UA using the PJSUA API.
The problem with implementing a B2BUA (as I understand it, happy to be
corrected if possible) is that the hold and transfer functions would then be
being performed inside this new component in the network.
I need them to be performed in the existing PBX server, just the same as they
would be if I plugged in a competent SIP phone and could press the "hold"
button.
Yes, you would have two SIP calls involved:
pbx-call between PBX and B2BUA and basic-call between B2BUA and "basic
softphone".
You would control the B2BUA and holding the call would mean holding
pbx-call.
I don't know if simply doing nothing with basic-call in this case is
problematic,
but you could initiate a hold for this call as well.
Regarding call transfer, you would initiate the transfer on pbx-call and
in case of success, simply hang up basic-call.
It sounds dirty, but might just work.
pjproject provides a test application "pjsua-app" which let's you do
what you want.
I'll take a look, but it sounds like it assumes it is part of the client
itself, rather than something in between client and server.
Yes, it acts as a SIP phone.
All the best,
Andreas
On Wednesday 18 August 2021 at 16:01:20, Andreas Wehrmann wrote:
Yes, you would have two SIP calls involved:
pbx-call between PBX and B2BUA and basic-call between B2BUA and "basic
softphone".
You would control the B2BUA and holding the call would mean holding
pbx-call.
I don't know if simply doing nothing with basic-call in this case is
problematic,
but you could initiate a hold for this call as well.
Regarding call transfer, you would initiate the transfer on pbx-call and
in case of success, simply hang up basic-call.
It sounds dirty, but might just work.
pjproject provides a test application "pjsua-app" which let's you do
what you want.
I'll take a look, but it sounds like it assumes it is part of the client
itself, rather than something in between client and server.
Yes, it acts as a SIP phone.
Thank you for a helpful answer, this sounds pretty encouraging. I'll follow
it up.
Antony.
--
What do you get when you cross a joke with a rhetorical question?
Please reply to the list;
please *don't* CC me.
Hi Antony,
Good evening.
Have you tried the following:
pjsua_call_set_hold
https://www.pjsip.org/pjsip/docs/html/group__PJSUA__LIB__CALL.htm#gabc6cf34d2b241224230701025eef489a
You can manage call control via PJSIP APIs
regards,
Varun
On Wed, 18 Aug, 2021, 7:36 AM Antony Stone, <
Antony.Stone@pjsip.open.source.it> wrote:
Hi.
I have a very basic SIP client application, which can make and receive
phone
calls, and that's about it. Regard it as a pretty dumb softphone.
Unfortunately I cannot change it for a smarter one.
This client is talking to a completely capable SIP server (PBX) which can
do
all the standard PBX stuff like putting calls on hold, transferring them,
conferencing, etc.
The problem is that the simple SIP client cannot itself tell the server to
do
any of these things - it can send an INVITE to place a call, and it can
REGISTER and then accept an INVITE to receive a call, but it doesn't know
how
to send any other commands to the server to "manage" calls once they're in
progress. The simplest example is putting a call on hold and then
resuming it
later.
I'm looking for something which I can place in the network path between
the
client and the server, which can send these call control commands on to
the
server, so that it can then put calls on hold, transfer them, etc.
I'm assuming this "thing" needs to sit in the network path, so that it
sees
the INVITEs and OKs and is then aware of the Call-IDs and sequence
numbers,
etc, and can therefore present the correct call reference to the SIP
server
when it wants to say "please put this one on hold". I have full access to
the
SIP credentials used to authenticate the client to the server.
I had thought that Kamailio might be what I was looking for, but I've
asked on
their mailing list and people are telling me that it isn't, and have
suggested
PJSIP as a potential solution.
Is that possible? Could I somehow use PJSIP to generate and send commands
to
a SIP server in order to control calls which have been placed either from
or
to this simple SIP client softphone application?
If anyone thinks there is another, perhaps better, way of achieving this,
then
I'm quite open to alternative solutions (as I say, I was initially
thinking
that Kamailio might be the way forward), so anything that shows me how
such
a thing might be achieved, with any tool at all, would be very welcome.
Thanks,
Antony.
--
Anyone that's normal doesn't really achieve much.
Mark Blair, Australian rocket engineer
Please reply to the
list;
please don't CC
me.
Visit our blog: http://blog.pjsip.org
pjsip mailing list -- pjsip@lists.pjsip.org
To unsubscribe send an email to pjsip-leave@lists.pjsip.org
On Wednesday 18 August 2021 at 23:58:41, varun ahluwalia wrote:
Hi Antony,
Good evening.
Have you tried the following:
I haven't tried anything yet, because I am completely new to the PJSIP project
(I got pointed here by someone helpful on the Kamailio list) however given
this suggestion, and that from Andreas, I shall certainly be installing it and
giving it a go :)
pjsua_call_set_hold
https://www.pjsip.org/pjsip/docs/html/group__PJSUA__LIB__CALL.htm#gabc6cf34
d2b241224230701025eef489a
You can manage call control via PJSIP APIs
Thank you. It's nice to find a friendly list on the first posting :)
Antony.
--
You can tell that the day just isn't going right when you find yourself using
the telephone before the toilet.
Please reply to the list;
please *don't* CC me.