What's Special/Exclusive About GV's SIP Configuration?
A_Friend:
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.
drgeoff:
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.
A_Friend:
Quote from: drgeoff 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.
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?
billsimon:
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.
RFC3261:
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.
Navigation
[0] Message Index
[#] Next page