Multiple Softphone Clients And Same/different Account Credentials
(I’m new to Asterisk, after having started VOIP with vat on the mbone in the 90s.)
I am setting up my first Asterisk system, and trying to read docs/guidance and follow best practices. I have read the 5th Edition of
“Asterisk: The Definitive Guide” and like the 3rd Edition on the web it recommends that hardphones and softphones both have a unique name distinct from any concept of extension.
http://asteriskdocs.org/en/3rd_Edition/asterisk-book-html-chunk/DeviceConfig_id283201.html
Then the 5th edition goes on to give an example with a hardphone and a softphone associated with one individual, where the hardphone is named by MAC address and the softphone by JIM_VANM_SOFT (p. 61).
Despite talking about separating extensions, phone names, and people, it seems clear that a softphone is usually personal to a person (unless it’s a desk phone via a computer, but I’m talking about the personal type).
THe book does not address the notion that a user might be given credentials and then configure them on a number of softphone-type devices simultaneously, e.g. a smartphone, a tablet, and two laptops. When getting service from an ITSP, it seems there are credentials and they don’t want to know the details of how many softphones you are using.
So which option is preferred?
A) Have a softphone aor/auth_user/password for a particular human, and
expect them to configure it on multiple devices. Do not worry that 1)
multiple are registered at once (because that’s normal in SIP) and 2)
asterisk has no idea which is which (because the intent is to place a
call to that person)
B) issue credentials per device and keep them all separate. Use
extensions.conf to ring them all
Having written the question out carefully, it seems obvious that A is the way to do this, but it’s sort of contrary to the advice in the book so I thought I would ask.
Thanks, Greg
—
5 thoughts on - Multiple Softphone Clients And Same/different Account Credentials
–0000000000004478f5059841df83
Content-Type: text/plain; charset=”UTF-8″
I’m no expert on the user side of things, but I would prefer option A. Of course, this is completely your preference. Asterisk will allow either option, so you have some flexibility there.
Ben Ford writes:
Thanks. It seems that A allows the user to choose devices without changing the PBX config, and that the real issue is if one wishes to allow calling the various devices separately, or if they are really just one logical device. In this case I intend them to be one logical device as in “dial the set of softphones Alice has configured and currently has connected”.
I have looked further and turned up two wrinkles, one of which is easy and obvious in hindsight:
one has to set max_contacts high for the user’s softphone aor:
https://blogs.asterisk.org/2017/11/29/pjsip-mis-configuration-can-cause-loss-sip-registrations/
and the second appears to be an artifact of syntax processing and not trivial to deal with.
PJSIP doesn’t dial all contacts when dialing an aor, so one needs to
use PJSIP_DIAL_CONTACTS. However, that can return the empty string
and thus lead to a syntax error, leading to the need to write code to
fix formatting:
https://asteriskfaqs.org/2019/06/09/asterisk-users/dialpjsip_dial_contactsalice-pjsip_dial_contactsbob-how-not-to-fail-if-one-endpoint-has-no-registered-aor.html
For the second issue, it would be nice if Dial just discarded empty destinations, as in
Dial(PJSIP/foo&)
Dial(PJSIP/foo&&PJSIP/baz)
as would result from the following if there were no bar registrations
Dial(PJSIP/foo&${PJSIP_DIAL_CONTACTS/bar})
Dial(PJSIP/foo&${PJSIP_DIAL_CONTACTS/bar}&PJSIP/baz)
which seems to be how almost everyone (perhaps actually everyone) wants to use PJSIP_DIAL_CONTACTS.
It is starting to seem that configuring multiple endpoints is easier than maintaining code to remove a trailing or double &.
Greg
—
Howdy!
I agree that would be nice for Dial to ignore dangling/extra ampersands.
Another option for a patch would be to extend the PJSIP_DIAL_CONTACTS
function with an argument such as ‘please’ to minimally return the endpoint name in a Dialable format when no reachable contacts are found eg. “PJSIP/bar” — instead of the current empty string, which is not Dialable.
Also the empty string is somewhat in conflict with the Synopsis “Return a dial string for dialing all contacts on an AOR.” (Maybe add ” Or returns empty string if no reachable contacts. Do not Dial directly.” ?)
Regardless of patch status, I’d recommend looking at the PUSH function to build up the dial list one line item at a time — please pardon the AEL format on my example:
Set(rgrp=);
Set(PUSH(rgrp,&)=PJSIP/foo);
Set(PUSH(rgrp,&)=PJSIP/baz);
if( “${PJSIP_DIAL_CONTACTS(bar)}” != “” ) {
Set(PUSH(rgrp,&)=${PJSIP_DIAL_CONTACTS(bar)});
}
Dial(${rgrp});
…that is likely easier to maintain in the long run because any changes, such as from ‘foo’ to ‘goo’, will be more quickly visible with a diff tool and in version control logs vs. untangling changes in one really long Dial line.
Kind Regards,
—
“C.Maj” writes:
I thought of that also while considering if patching the way Dial behaves was feasible. I think you are right that having PJSIP_DIAL_CONTACTS reduce to a single PJSIP/aor string will follow the principle of least astonishment.
That looks workable. Is there a multiprocessing hazard here? Could
${PJSIP_DIAL_CONTACTS(bar)} change between check and use.
—
Thanks, I put together a patch:
https://issues.asterisk.org/jira/browse/ASTERISK-28638
Yes, if you put the Dial() further away, maybe after a Wait(), then it could be a problem. But in this example, it is not going to be that much slower than more ‘direct’ substitution Dial(${PJSIP_DIAL_CONTACTS(bar)})
because either way the PJSIP_DIAL_CONTACTS function is being evaluated first and separately from the Dial() application itself. The application only sees the results of the function.
Kind Regards,
—