Moving Google Voice Line to a different SP Trunk

[restamp]

Quick question:  If I've already OAUTH-registered a device with Google Voice and would like to move GV's assigned SP trunk, say from SP1 to SP4, can I do this without re-registering with GV, and if not, would there be any problem with re-registering the device?

TIA

[SteveInWA]

http://www.obitalk.com/forum/index.php?topic=9911.msg65622#msg65622

[restamp]

Thanks, Steve.  I was familiar with the thread you pointed me to.  My reading of it was that the OP wanted to change GV accounts and of course in that case you'd have to re-register the device.  I don't want to change my GV account, just move the SP trunk associated with it and was wondering if re-registration was a requirement for doing so.  Perhaps another way of asking the question is:  Are the GV OATH 2.0 credentials based strictly on the device, or the device plus the trunk GV is homed on?

Why not just go in through the OBiTalk portal and remove/re-add the GV line?  Well, I've made some changes manually and suspect they'd be removed if I do this through the portal.

A side question:  If I have two OBi devices and register the same GV account with both, can both be used with GV, either simultaneously or not, or will the second registration invalidate the first?

OK, this brings up a third point I've wondered about:  If I get my OBi device configured the way I want it and properly registered with GV and then create a backup .xml file of the configuration, can I restore to that backup and still make use of GV (will the OAUTH credentials remain valid after the restore), or will I have to re-register using the OBiTalk portal?  (I know I'll have to manually re-add the passwords for SIP connections.)

Thanks.

[SteveInWA]

To move the Google Voice service from one SP slot to another on the same OBi requires that you delete the configuration on the original SPx, and then set it up via the OBiTALK portal on the other SPx slot.  The portal-based procedure assigns a OAUTH secure access token to the particular slot, and no, you can't manipulate this manually/locally.  It only takes a couple of minutes to accomplish this via the portal.  What takes some extra time, though (and this addresses your concern about your manually-performed configuration), is that you need to back up and restore your local device configuration if you have been using the local web-server interface of the device to configure it, instead of the portal.

The local backup and restore does not backup nor restore the OAUTH token(s) as far as I know, so restoring a local configuration will not interfere with the Google Voice service.  Note that the former password field in the Google Voice SP slot is not used under the new authentication procedure, so ignore it.  Note also that Google Voice doesn't know or care how your OBi is configured.  All it knows is that you've enabled XMPP service via the Google "Chat" forwarding destination, and that you have given OBiTALK permission to access that portion of your Google account's various services and functions via OAUTH.

First:  read, understand and follow Robert's post on how to back up and restore any locally-performed configuration:

http://www.obitalk.com/forum/index.php?topic=8685.0

Then, review my instructions to manage your Google Voice configuration via the OBiTALK portal:

http://www.obitalk.com/forum/index.php?topic=8560.msg56460#msg56460

You can register multiple OBi 20x devices and/or OBi 10xx IP phones to one or more GV accounts.  All will ring on inbound calls as well as be able to make outbound calls with the same GV account.

[OzarkEdge]

Hey Obihai,

Why not add an Expert Option to the OBiTALK web portal to ONLY configure Google Voice on the selected SPn Voice Service, and to not touch anything else i.e. permit OBiTALK Google Voice configuration to coexist with local device configuration via the Obi web interface?

OE

[restamp]

Thanks, Steve, for the comprehensive reply.  I'm thinking the best solution may well be to punt and reprogram my OBi from scratch.

@OzarkEdge: Excellent suggestion.