asterisk users - Nov 2019 - multiple softphone clients and same/different account credentials

>> 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.
Ben Ford <bford at digium.com> writes:
> 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. One of the advantages of option
> A is that you can have multiple devices (like you mentioned) that can all
> be rung at once simply if the user has a desk phone, mobile work phone,
etc.
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

On 2019-11-26 09:17, Greg Troxel wrote:
> 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.
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, Technology Captain @ Penguin PBX Solutions
📞 USA Toll Free 1-833-PNGNPBX (1-833-764-6729)
🤙 International & SMS Texting +1.720.32.42.72.9
🐧 Visit on the World Wide Web at PENGUINPBX.COM

"C.Maj" <chris at PenguinPBX.com> writes:
> 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.
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.
> 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 looks workable.  Is there a multiprocessing hazard here?  Could
${PJSIP_DIAL_CONTACTS(bar)} change between check and use.