We had similar issues and when we did the auto provisioning one of our codec bouncing issues went away on our smc3456 as opposed to when we manually assigned the accounts. In our scenario prior to doing auto provisioning. We could not call from a polycom set to a SMC and then put call on hold and pick it back up with out the codec on the SMC bouncing to G711 even though it had agreed to the G722 codec when it was picked back up off hold by the Polycom.
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Dave Deutschman Sent: Wednesday, September 23, 2009 12:20 PM To: 'Damian Krzeminski'; [email protected] Subject: Re: [sipX-dev] CounterPath Bria Pro provisioning limitation The issue is not one of remote versus in-office login. 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. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Damian Krzeminski Sent: Wednesday, September 23, 2009 11:27 AM To: [email protected] Subject: Re: [sipX-dev] CounterPath Bria Pro provisioning limitation Paul Mossman wrote: > Hi all, > > There's a limitation in our current CounterPath Bria Pro provisioning, > and it's affecting at least one customer. Here's how to work around it. > > The problem is in corresponding the login User with a Bria profile. > It works fine when the mapping is 1:1, but a single user can have many > Bria profiles. This is common on a laptop, which requires different > Bria settings for in-office versus remote worker operation. The user > can have two Bria profiles, but the provisioning servlet > (http://<HOST>:12000/cmcprov/login) will only ever load the first one > that it finds. > > The work-around is to avoid the provisioning servlet altogether. You > can do this by specifying the full path to the desired profile > directly in the "Server" field of the login window. For example, to > load a "pauloffice" profile use: > http://<HOST>/phone/profile/tftproot/pauloffice.ini. > > The Username and Password don't matter, since they won't be used anyway. > Unfortunately this relates to another problem. It is quite difficult > to access the "Server" field in the current Bria client. So switching > profiles in rather inconvenient. The instructions are captured in > XTRN-624, which fortunately is expected fixed in the upcoming Bria 3.0 > release. > I think that having the same set-up for all you softphones was considered a feature at one point. Clearly that does not seem to work. 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? Another question: if phones are capable of loading the ini file directly why do we even bother with provisioning servlet for Bria? D. _______________________________________________ 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/ Our company accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. No employee or agent is authorized to conclude any binding agreement on behalf of Copper State Communications with another party by email without express written confirmation by a Corporate Officer of Copper State Communications.
<<attachment: Bryan Simmons.vcf>>
_______________________________________________ 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/
