> Al wrote:
> > Couldn't you just add two phones in sipXconfig and login with
> > different credentials depending on where you are?  Something like:
> > paulhome or pauloffice?
> >
> > Depending on which one you take would give you different settings?
> 
> That would work, but would require two user accounts for a single
user.
> Hard to maintain the config, and also chews in extra SCS license seat.
> 

We don't license phone's.. Just users..

> 
> > The problem is if you take away the servlet then you won't be
> > able to do totally automatic provisioning. Using the DHCP 120
> > the client can automatically setup requiring only
> > user/password. If we remove the servlet you will always need
> > to know the crazy URL for your ini file.
> 
> Exactly.
> 
> We could still allow profile selection with totally automatic
> provisioning by append the profile to the login username.  i.e. A User
> ID "19629" with Bria profiles "paulhome" and "pauloffice" would login
> with either "19629:paulhome" or "19629:pauloffice".  Or, the two
> profiles could be configured with "Branch" "Office" or "Remote", and
> you'd append that to the login name.  Al, maybe this is actually what
> you were suggesting above?
> 
> Ideally though the URL would simply be http://<HOST>, but we need to
> trash Apache first.  The new sipXprovision service would be a logical
> place to host an improved CounterPath servlet...
> 
> Also, HTTPS would be better, because with HTTP we're currently
> transmitting the PIN in cleartext.  But that would require pre-loading
> the self-signed CA certificate on the client machine.  Not too hard,
> but
> certainly a manual step.  (Ideally the CounterPath client could do
> this,
> similar to Firefox's "I understand the risks..." behaviour.)
> 
> 
> Damian wrote:
> > What settings need to be different for remote
> > vs. in-office? Shouldn't users with software client on a
> > laptop be able to use their phones no matter where they
> > connect from without adjusting anything?
> 
> You often want to use a low-band codec when remote.  Note that
> CounterPath Bria supports G.722, and we've disabled its mid-call codec
> optimizing, so if G.722 is negotiated when remote you're stuck with
it.
> 
> I seem to remember that there is some other setting that's often
> changed
> when remote, but I can't recall it.
> 
> 
> > Another question: if phones are capable of loading the ini
> > file directly why do we even bother with provisioning servlet
> > for Bria?
> 
> Specifically for totally automatic provisioning using DHCP Option 120.
> But more generally, so that all clients can use the same provisioning
> URL.  (Some users will be challenged to cut & paste the URL.  Being
> additionally instructed to modify it result in a support call.)
> 
> 
> Dave wrote:
> > In my case, we have a production SCS server and multiple demo
> > servers.  I want to be able to log into the production server
> > when on the road, but when doing a demo, log into one of the
> > demo servers.  The current implementation does not allow for
> > this so we bypass the login server and configure the phone
> > manually with multiple accounts.
> 
> Good point.
> 
> CounterPath is aware of this, and last I heard improvements were in
> progress.  (There is an effort underway to change the login screen for
> the next major release such that a single installation can work with
> multiple "profiles".)  I suggested that Firefox profiles be used as a
> model.  Not sure what it'll look like, or if it's ready for Bria 3.0.
> 
> 
> -Paul
> [email protected]
> 
> 
> _______________________________________________
> sipx-dev mailing list [email protected]
> List Archive: http://list.sipfoundry.org/archive/sipx-dev
> Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
> sipXecs IP PBX -- http://www.sipfoundry.org/
_______________________________________________
sipx-dev mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
sipXecs IP PBX -- http://www.sipfoundry.org/

Reply via email to