December 18, 2018, 03:25:16 am *
Welcome, Guest. Please login or register.
News:
 
   Forum Home   Search Login Register OBiTALK  
Pages: [1]
  Print  
Author Topic: What's Special/Exclusive About GV's SIP Configuration?  (Read 1668 times)
A_Friend
Full Member
***
Posts: 225


« on: August 12, 2018, 05:07:19 pm »

This is just a question out of pure curiosity, unrelated to any problems, etc.

Now that GV bagged/retired the XMPP protocol they were using and reconfigured for SIP, what is it about it that makes it incompatible with Obi100/110 and most other generic ATAs?

I see on obifirmware.com a tutorial for manually genning up your own OAUTH credentials and plugging them in their firmware, but I'm not fully understanding what makes this so different than the usual SIP credentials that you can't plug them in anywhere else.  Is it just the length of the encrypted string?  Or is this some public/private key thing?

And, no, I'm not particularly acquainted with those, either.



Logged
drgeoff
Hero Member & Beta Tester
*****
Posts: 3864


« Reply #1 on: August 13, 2018, 03:39:08 am »

https://gvsip.info/

I suspect that the ICE requirement is the major problem when trying to use existing ATAs unaided by a separate gateway/proxy.
« Last Edit: August 13, 2018, 03:42:58 am by drgeoff » Logged
A_Friend
Full Member
***
Posts: 225


« Reply #2 on: August 13, 2018, 10:37:59 am »

https://gvsip.info/

I suspect that the ICE requirement is the major problem when trying to use existing ATAs unaided by a separate gateway/proxy.

I read through and tried understanding rfc5245 ("Interactive Connectivity Establishment").  This stuff is way over my head.  But, to this non-engineer it reads like a core requirement for setting up a SIP connection.  If so, shouldn't every ATA support this, or are there other ways SIP connections get established?
Logged
billsimon
Full Member
***
Posts: 103


« Reply #3 on: August 13, 2018, 05:57:53 pm »

No devices other than Obi support the third-party auth mechanism. It's not just as simple as changing out SIP username/password for oauth2 tokens. It's actually a different SIP registration sequence.

The other "biggie" is RFC 5626, called SIP Outbound, which is largely unsupported. I don't know whether any other SIP devices support it right now.

rtcp-mux may not be very well supported, but is out there; ICE is implemented in a lot of devices and softphones.
Logged
RFC3261
Full Member
***
Posts: 249


« Reply #4 on: August 13, 2018, 06:35:55 pm »

I think there are arguments that using the (forward looking) standards in these ways can be goodness to VOIP in the long run, and there is nothing to prevent others from implementing them, but before now no vendor had combined all the standards that way because there was no other party doing so (and who does work that is not useful?).  Perhaps (and it is only a perhaps) other ATA (and SIP phone) vendors will find there is a compelling reason to do all that work to obtain some market share or additional interop at production quality, but also maybe not.  There is clearly some work by the PBX community at large to do (at least some of) that work, but that is a bit of a different audience.
Logged
Taoman
Hero Member
*****
Posts: 1159


« Reply #5 on: August 13, 2018, 06:51:11 pm »

No devices other than Obi support the third-party auth mechanism. It's not just as simple as changing out SIP username/password for oauth2 tokens. It's actually a different SIP registration sequence.

The other "biggie" is RFC 5626, called SIP Outbound, which is largely unsupported. I don't know whether any other SIP devices support it right now.

rtcp-mux may not be very well supported, but is out there; ICE is implemented in a lot of devices and softphones.

Thanks for the explanation, Bill. I was curious (along with others) about this issue.
I'm going to bookmark your post for future reference.

Wish I knew some details of the arrangement between Polycom/Obihai and Google vis--vis Google Voice and any possible "exclusivity" involved.

I also question, as you do, whether Google/Obihai will continue to allow 3rd party access to obihai.sip.google.com.
Logged
A_Friend
Full Member
***
Posts: 225


« Reply #6 on: August 13, 2018, 08:07:42 pm »

I also question, as you do, whether Google/Obihai will continue to allow 3rd party access to obihai.sip.google.com.

Well, that's in Google's domain, so I guess it's them accommodating Obihai, rather than anything Obihai "owns."  So, that will probably continue to be available to anyone using Google Voice who wants to use that protocol.  At least, logically that's the way it seems to me.

Besides Obihai devices, I'm also a fan of Raspberry Pi.  Right now, all I use mine for is entertainment, but I'm tickled by the idea that you could run a PBX on a $10 Pi Zero W, now with GV trunks!  http://nerdvittles.com/?p=26267

There's actually nothing telephonic I need right now that my Obi 202 and 200 and the four carriers I use (and their cloud/backend platforms) isn't providing, so I'm not highly motivated to dig into it, but I'm definitely tickled by the idea.
Logged
RFC3261
Full Member
***
Posts: 249


« Reply #7 on: August 13, 2018, 08:42:28 pm »

Wish I knew some details of the arrangement between Polycom/Obihai and Google vis--vis Google Voice and any possible "exclusivity" involved.
The only parties that actually know are not going to be talking.  I suspect (but do not know) that Google would be open to consider negotiating with other parties than Plantronic/Polycom/Obihai, but I'll bet you are going to have to be a bigger player to get into the game (and possibly throw some resources into the pot).  AFAIK there is no one outside of Obi who have managed to successfully get into contact with the right people at Google to take any next steps (even though I am pretty sure at least one person did try when the dung hit the fan).
Quote
I also question, as you do, whether Google/Obihai will continue to allow 3rd party access to obihai.sip.google.com.
I can easily see that others should be requesting their own endpoint as part of the negotiation with Google.  As Bill documented, there are clearly endpoints for multiple entities in addition to obihai (although many look to currently be under the other bets, such as fi.telephony.goog, and waymo.telephony.goog, although we do not know how many others may exist out there (well, I should say *I* do not know how many others are out there, since I have not performed the research experiment beyond the fi and waymo)).  Those may be related to potential future load balancing, but they may also be related to potential licensing or access arrangements.  We just don't know.  I would be slightly more concerned about the registration name, which (for true obihai devices) reflects the obi device number, and it is clearly possible that devices which are not true obi devices will get purged at some point as not legitimate.  But again, we just don't know.  I would not worry about any of those things very much as long as you do not end up building solutions that have extremely high expectations of reliability and availability (and if you are I would certainly recommend getting in touch with Google first to avoid problems).
Logged
Taoman
Hero Member
*****
Posts: 1159


« Reply #8 on: August 13, 2018, 09:01:42 pm »

I would be slightly more concerned about the registration name, which (for true obihai devices) reflects the obi device number, and it is clearly possible that devices which are not true obi devices will get purged at some point as not legitimate.  But again, we just don't know.

Good point.

My point is if there is a formal agreement/contract between Polyhai and Google (with resources thrown in the pot) then if I was Polyhai I wouldn't be thrilled with 3rd parties utilizing a proxy server ostensibly (exclusively?) dedicated for Obihai devices.

And if the plan was for anyone and everyone to have access then I'd think a more generic hostname than obihai.sip.google.com would have been used. But I could easily be overthinking this.  Wink
Logged
SteveInWA
Hero Member & Beta Tester
*****
Posts: 5231



« Reply #9 on: August 13, 2018, 09:36:05 pm »

Wish I knew some details of the arrangement between Polycom/Obihai and Google vis--vis Google Voice and any possible "exclusivity" involved.
The only parties that actually know are not going to be talking.  I suspect (but do not know) that Google would be open to consider negotiating with other parties than Plantronic/Polycom/Obihai, but I'll bet you are going to have to be a bigger player to get into the game (and possibly throw some resources into the pot).  AFAIK there is no one outside of Obi who have managed to successfully get into contact with the right people at Google to take any next steps (even though I am pretty sure at least one person did try when the dung hit the fan).
Quote
I also question, as you do, whether Google/Obihai will continue to allow 3rd party access to obihai.sip.google.com.
I can easily see that others should be requesting their own endpoint as part of the negotiation with Google.  As Bill documented, there are clearly endpoints for multiple entities in addition to obihai (although many look to currently be under the other bets, such as fi.telephony.goog, and waymo.telephony.goog, although we do not know how many others may exist out there (well, I should say *I* do not know how many others are out there, since I have not performed the research experiment beyond the fi and waymo)).  Those may be related to potential future load balancing, but they may also be related to potential licensing or access arrangements.  We just don't know.  I would be slightly more concerned about the registration name, which (for true obihai devices) reflects the obi device number, and it is clearly possible that devices which are not true obi devices will get purged at some point as not legitimate.  But again, we just don't know.  I would not worry about any of those things very much as long as you do not end up building solutions that have extremely high expectations of reliability and availability (and if you are I would certainly recommend getting in touch with Google first to avoid problems).

The other domains you see are other Google services (Project Fi, the hybrid VoIP/LTE mobile phone service) and Waymo, the self-driving car subsidiary (don't ask me why they'd need that!).  Google is not doing any work with any other third parties as of now.

It's conceivable that, in the somewhat distant future, other VoIP hardware OEMs might participate, but that participation would be under the upcoming Google Voice service for G Suite (paying) customers.  Google is not interested in giving away free SIP trunks; they are interested in providing a fully-supported business-class, paid service.  And, no, this will have no impact on the continuing availability of the free consumer-targeted service.
Logged

--Steve

Google Voice Forum Product Expert

https://productforums.google.com/forum/#!forum/voice
Pages: [1]
  Print  
 
Jump to:  

Powered by SMF 1.1.11 | SMF © 2006-2009, Simple Machines LLC