pp1

join:2006-06-28

Somerset, NJ 3 recommendations pp1 to naf

Member to naf

Re: Asterisk Google Voice SIP testing and technical discussion Use voice.telephony.goog instead of obihai.telephony.goog for the sip connection and things seem to work.

gridbox

join:2018-10-12 gridbox Member That worked for me as well! Many thanks. How did you figure out to use that instead? Here's hoping it stays working for a while...



AllThumbs

join:2006-02-07

Charleston, SC AllThumbs to pp1

Member to pp1

said by pp1: Use voice.telephony.goog instead of obihai.telephony.goog for the sip connection and things seem to work.



sed -i 's|obihai.telephony.goog|voice.telephony.goog|' /etc/asterisk/pjsip_custom.conf

amportal restart

sed -i 's|obihai.telephony.goog|voice.telephony.goog|' /root/gvsip-naf/install-gvsip

Perfect. Thanks, pp1 . For those using Incredible PBX, here's the quick fix:



WhyADuck

Premium Member

join:2003-03-05 WhyADuck to pp1

Premium Member to pp1





cd /etc/asterisk sed -i -e 's/obihai.telephony.goog/voice.telephony.goog/g' pjsip_custom_post.conf

And restarted Asterisk, and that seemed to fix the problem. I do note that there are still lines such as



server_uri=sip:obihai.sip.google.com client_uri=sip:user@obihai.sip.google.com realm=obihai.sip.google.com contact=sip:obihai.sip.google.com

and wonder if any of those should also be changed, but right now it does appear to be working again with those references to obihai still in place. Thanks very much for that information. I did this:And restarted Asterisk, and that seemed to fix the problem. I do note that there are still lines such asand wonder if any of those should also be changed, but right now it does appear to be working again with those references to obihai still in place.



jsolo1

Premium Member

join:2001-07-01 1 edit jsolo1 to pp1

Premium Member to pp1

Thanks!



Are you able to receive calls after making this change? I can place calls now but not receive.



Edit: Appears to be working now (with no further changes made).

naf

join:2017-12-12 3 edits naf Member

SNI=obihai.telephony.goog FROM:64.9.241.108 TLSv1.2: Certificate, Server Key Exchange, Certificate Request, Server Hello Done TO:64.9.241.108 TLSv1.2: Certificate, Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message <-- length-0 certificate presented FROM:64.9.241.108 TLSv1.2: Alert (Level: Fatal, Description: Handshake Failure) SNI=voice.telephony.goog (or whatever) FROM:64.9.241.108 TLSv1.2: Certificate, Server Key Exchange, Server Hello Done TO:64.9.241.108 TLSv1.2: Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message FROM:64.9.241.108 TLSv1.2: New Session Ticket, Change Cipher Spec, Encrypted Handshake Message

UPDATE: yep. real obi's present a client cert. [didn't notice when i proxied the connection because my proxy just so happens to present a obi-signed client cert, haha] my (always questionable) analysis of the traffic is that the failures are due to the server requesting a client certificate and the client responding without one?UPDATE: yep. real obi's present a client cert. [didn't notice when i proxied the connection because my proxy just so happens to present a obi-signed client cert, haha]

gridbox

join:2018-10-12 gridbox to WhyADuck

Member to WhyADuck

said by WhyADuck: server_uri=sip:obihai.sip.google.com client_uri=sip:user@obihai.sip.google.com realm=obihai.sip.google.com contact=sip:obihai.sip.google.com

and wonder if any of those should also be changed, but right now it does appear to be working again with those references to obihai still in place. and wonder if any of those should also be changed, but right now it does appear to be working again with those references to obihai still in place. I was able to change all of the references of obihai to voice. The only caveat is I had to load the codec_opus module.



WhyADuck

Premium Member

join:2003-03-05 4 edits WhyADuck Premium Member said by gridbox: I was able to change all of the references of obihai to voice. The only caveat is I had to load the codec_opus module.



In FreePBX my trunk Custom Dial Strings were PJSIP/$OUTNUM$@gvsip-whatever and changing that to PJSIP/+1$OUTNUM$@gvsip-whatever made it work (after changing all the references to obihai in pjsip_custom_post.conf to voice). I did already have the Opus codec installed so it confused me at first why it wouldn't work.



So basically, I probably could have just originally done



sed -i -e 's/obihai/voice/g' /etc/asterisk/pjsip_custom_post.conf

And then changed my trunk Custom Dial Strings as mentioned above and it would have worked (not I am not saying anyone else should do that, because someone may have added references to obihai that have nothing to do with GVSIP, and that line would change those also). Note that what I said above assumes that $OUTNUM$ contains 10 digits; if $OUTNUM$ contains 11 digits or more (as it might if you place international calls through Google Voice) then you would omit the 1 after the +, so it then becomes PJSIP/+$OUTNUM$@gvsip-whatever



Unfortunately you do have to add the + (at least) in the Custom trunk's Custom Dial String because a + has a meaning in FreePBX's Dial Number Manipulation Rules. Alternately, I suppose you could add the +1 or + prefix in the Outbound Dial Prefix field in the trunk's Dial Number Manipulation Rules tab; for most FreePBX users it probably would not matter which way you did it (there is a slight technical difference in that if you add it using the Outbound Dial Prefix field, the prefix gets added somewhat earlier in the dialplan. In particular, it gets added before the macro-dialout-trunk-predial-hook macro is executed, so if you have added any custom dialplan there that depends on the outgoing number being in a particular format, putting the prefix in the Outbound Dial Prefix field might break your custom dialplan, whereas adding it to the Custom Dial String would not).



I do have the Opus codec loaded, but I think that requirement would be a big problem for the Raspberry Pi users, so they probably should NOT make any of the changes shown in this post (or alternately, they could TRY installing the Opus codec, I just remembered At first when I tried that outgoing calls did not work for me, but then I read the part about how numbers need to be sent using +1 at the start when you use voice.sip.google.com, and that appears to work.In FreePBX my trunk Custom Dial Strings were PJSIP/$OUTNUM$@gvsip-whatever and changing that to PJSIP/+1$OUTNUM$@gvsip-whatever made it work (after changing all the references to obihai in pjsip_custom_post.conf to voice). I did already have the Opus codec installed so it confused me at first why it wouldn't work.So basically, I probably could have just originally doneAnd then changed my trunk Custom Dial Strings as mentioned above and it would have worked (not I am not saying anyone else should do that, because someone may have added references to obihai that have nothing to do with GVSIP, and that line would change those also). Note that what I said above assumes that $OUTNUM$ contains 10 digits; if $OUTNUM$ contains 11 digits or more (as it might if you place international calls through Google Voice) then you would omit the 1 after the +, so it then becomes PJSIP/+$OUTNUM$@gvsip-whateverUnfortunately you do have to add the + (at least) in the Custom trunk's Custom Dial String because a + has a meaning in FreePBX's Dial Number Manipulation Rules. Alternately, I suppose you could add the +1 or + prefix in the Outbound Dial Prefix field in the trunk's Dial Number Manipulation Rules tab; for most FreePBX users it probably would not matter which way you did it (there is a slight technical difference in that if you add it using the Outbound Dial Prefix field, the prefix gets added somewhat earlier in the dialplan. In particular, it gets added before the macro-dialout-trunk-predial-hook macro is executed, so if you have added any custom dialplan there that depends on the outgoing number being in a particular format, putting the prefix in the Outbound Dial Prefix field might break your custom dialplan, whereas adding it to the Custom Dial String would not).I do have the Opus codec loaded, but I think that requirement would be a big problem for the Raspberry Pi users, so they probably should NOT make any of the changes shown in this post (or alternately, they could TRY installing the Opus codec, I just remembered this post I had made a while back that may point to a way of doing that but I still have not personally tested that).

naf

join:2017-12-12 1 recommendation naf Member said by naf: my (always questionable) analysis of the traffic is that the failures are due to the server requesting a client certificate and the client responding without one?

SNI=obihai.telephony.goog FROM:64.9.241.108 TLSv1.2: Certificate, Server Key Exchange, Certificate Request, Server Hello Done TO:64.9.241.108 TLSv1.2: Certificate, Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message <-- length-0 certificate presented FROM:64.9.241.108 TLSv1.2: Alert (Level: Fatal, Description: Handshake Failure) SNI=voice.telephony.goog (or whatever) FROM:64.9.241.108 TLSv1.2: Certificate, Server Key Exchange, Server Hello Done TO:64.9.241.108 TLSv1.2: Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message FROM:64.9.241.108 TLSv1.2: New Session Ticket, Change Cipher Spec, Encrypted Handshake Message

UPDATE: yep. real obi's present a client cert. [didn't notice when i proxied the connection because my proxy just so happens to present a obi-signed client cert, haha] UPDATE: yep. real obi's present a client cert. [didn't notice when i proxied the connection because my proxy just so happens to present a obi-signed client cert, haha]



For those of us that have a few obi-signed certs lying around, asterisk works fine against obihai.telephony.goog with a couple config lines in the transport section:



[transport_tls]

type=transport

protocol=tls

bind=0.0.0.0:5061

cert_file=/obi200/certs/client.crt

priv_key_file=/obi200/certs/client.key



im assuming they cant use the same trick on voice.telephony.goog if its the endpoint that the android app uses for 'wifi' calling, due to the nature of how the android app is distributed (no individual-installation-unique signed key to potentially ban when we all reuse it) [hows that wifi "beta" that i cant get in going, btw?] Checked one last thing: obihai.telephony.goog appears to only accept client certs signed by the obihai ca.For those of us that have a few obi-signed certs lying around, asterisk works fine against obihai.telephony.goog with a couple config lines in the transport section:im assuming they cant use the same trick on voice.telephony.goog if its the endpoint that the android app uses for 'wifi' calling, due to the nature of how the android app is distributed (no individual-installation-unique signed key to potentially ban when we all reuse it) [hows that wifi "beta" that i cant get in going, btw?]



file

join:2011-03-29

Riverview, NB file Member They still may eventually do the same with that host, and issue a certificate through some interaction between the app and Google.

ELudicatEd

join:2018-10-13

united state ELudicatEd to naf

Member to naf

said by naf: im assuming they cant use the same trick on voice.telephony.goog if its the endpoint that the android app uses for 'wifi' calling, due to the nature of how the android app is distributed (no individual-installation-unique signed key to potentially ban when we all reuse it) [hows that wifi "beta" that i cant get in going, btw?]



I'd prefer to disable it on the handset, personally. It took forever to have it activated following signup and while the quality is comparable to using ilbc/speex on the old setup, it is creepy to seed that much more direct control to the big ABC. It works on one of my phones, but not the other, and not on 3 roms under genymotion.



Maybe it is time to properly attempt to mitm the phone that works while in action as the only kind of love asterisk is getting from obihai.sip.google.com

is a 400 with the uri/proxy change, followed by complete name change from obihai to voice, either with/without tlsv1_2 as method, and without certs... )



following name change, self signed certs yield:



res_pjsip_outbound_registration.c:590 stateless_send_resolver_callback: Resolver failed. Cannot send message



old obi addresses in pjsip.conf yield, prior to name swap, regardless:



[Oct 13 00:39:22] WARNING[14988]: pjproject:0 : SSL SSL_ERROR_SSL (Handshake): Level: 0 err:



Packet capture on the android device with an imported cert gave me issues and only cleartext. I don't think the app likes to communicate over the vpn capture method or something, but that is an android issue. I'll play with it later. Kinda at my wits end after yesterday.



That makes sense.I'd prefer to disable it on the handset, personally. It took forever to have it activated following signup and while the quality is comparable to using ilbc/speex on the old setup, it is creepy to seed that much more direct control to the big ABC. It works on one of my phones, but not the other, and not on 3 roms under genymotion.Maybe it is time to properly attempt to mitm the phone that works while in action as the only kind of love asterisk is getting from obihai.sip.google.comis a 400 with the uri/proxy change, followed by complete name change from obihai to voice, either with/without tlsv1_2 as method, and without certs... )following name change, self signed certs yield:res_pjsip_outbound_registration.c:590 stateless_send_resolver_callback: Resolver failed. Cannot send messageold obi addresses in pjsip.conf yield, prior to name swap, regardless:[Oct 13 00:39:22] WARNING[14988]: pjproject:0 : SSL SSL_ERROR_SSL (Handshake): Level: 0 err:Packet capture on the android device with an imported cert gave me issues and only cleartext. I don't think the app likes to communicate over the vpn capture method or something, but that is an android issue. I'll play with it later. Kinda at my wits end after yesterday.



WhyADuck

Premium Member

join:2003-03-05 WhyADuck to file

Premium Member to file

said by file: They still may eventually do the same with that host, and issue a certificate through some interaction between the app and Google. probably going to be much easier to get it from an Android device, for those that know how to do that sort of thing (not me, but I would hope that if the time ever comes, those that know how will share the technique).



In an ideal world, Digium and Google would be able to work out some official method of connection that avoids this sort of reverse engineering, but we do not live in an ideal world so I am not holding my breath waiting for that to happen. Possibly (who knows with Google?) but I suspect that it would be a lot easier to get the certificate from an Android device (of which there are millions) than from an Obihai device (of which there are relatively few). Don't quote me on this but I think you can even run Android on a Raspberry Pi or similar small computer, or in an Android emulator (virtual machine?) on a desktop computer, and my thinking is that you'd only need to run it long enough to run the Android Google Voice app and get the certificate, if it ever comes to that. All of this is just a wild guess on my part, but I just suspect that if someone can get the certificate from their Obihai device and plug it into Asterisk's configuration, it'sgoing to be much easier to get it from an Android device, for those that know how to do that sort of thing (not me, but I would hope that if the time ever comes, those that know how will share the technique).In an ideal world, Digium and Google would be able to work out some official method of connection that avoids this sort of reverse engineering, but we do not live in an ideal world so I am not holding my breath waiting for that to happen.



file

join:2011-03-29

Riverview, NB 1 recommendation file Member It depends on how precisely they would do such a thing in the application and ultimately this is Google's platform. They're the ones in control, and I think this certificate change is just showing that they are aware of this work and are likely exploring mechanisms to exert more control/limit things. Things may get more difficult as time progresses.



As for working out something official - I don't see any benefit from Google's side and they're the ones holding the keys to the kingdom. While I don't have data to back it up I think it's a drop in the bucket using GVSIP, and I suspect a lot of previous users have since moved on. That's my personal opinion.



WhyADuck

Premium Member

join:2003-03-05 WhyADuck Premium Member said by file: While I don't have data to back it up I think it's a drop in the bucket using GVSIP, and I suspect a lot of previous users have since moved on. That's my personal opinion. Well I don't want to hijack the thread with this discussion so I will just say that logically it seems that if there are really only a few using GVSIP then Google may not find it worthwhile to waste time and resources trying to come up with additional ways to keep the remaining few of us out. At least I'd hope that is the case, but since Google is so close-lipped about everything we just have no way of knowing if they actually consider GVSIP users some kind of problem that needs to be solved. But really we are just guessing as to what they might be thinking.

restamp

join:2016-07-22

Pickerington, OH 3 recommendations restamp Member I tend to agree with WhyADuck's interpretation: If Google really doesn't want us interacting with GV from Asterisk, why don't they just issue a statement to that effect. If they did, I would abide by it. Why play a cat and mouse game that wastes resources on both sides?



My take on this is that we are too small a community for Google to care about, and as such, we always are (and will always be) taken by surprise when they make a change -- one which they have coordinated with their partners in advance, but not us. So I believe it's not that they hate us and are actively trying to lock us out -- which I'm sure they could do if they wanted to -- but rather we are simply not on their radar, and as such, we will always be left to play catch-up when changes are made.



But to bring this thread back to the technical side, several posts above NAF comments: "For those of us that have a few obi-signed certs lying around, asterisk works fine against obihai.telephony.goog with a couple config lines in the transport section..." My question is: How do you acquire an OBi signed cert? Can it be extracted from an OBi device (of which I have several), and if so, how?



Inquiring minds...

MrChris4

join:2014-07-26

USA 1 edit MrChris4 to pp1

Member to pp1

At what point to the gvsip endpoints/devices show up as a device in gvoice weburl settings/phones?

naf

join:2017-12-12 4 edits naf to restamp

Member to restamp

said by restamp: How do you acquire an OBi signed cert? Can it be extracted from an OBi device (of which I have several), and if so, how?



I'll write a quick extraction/decryption tool if things go south with the voice.telephony.goog endpoint. Yes, it can be extracted from an OBi device running a shelled firmware (or an obi100, but that requires "a screwdriver and some resistors" or whatever i said the first time. see those 100s are good for something)I'll write a quick extraction/decryption tool if things go south with the voice.telephony.goog endpoint.



Anon705e0

@98.208.56.x Anon705e0 Anon Is anyone actually able to connect to that domain? I am looking at a packet capture and it is saying certificate unknown on this side.



hapollo

join:2007-05-13

WesterOS hapollo Member Since the frequency of GVSIP issues are more frequent now, anyone know of a script that can be used with Asterisk/Freepbx to monitor PJSIP status and kick out an email when Chan_PJSip Registrations in Asterisk Info page becomes rejected? Similar to when fail2ban rejects an IP or crontab sends an error after running.



Rather be a bit more pro-active if possible rather than reactive.. finding the trunk is down after picking up the phone to make a call only to fail is a bit more reactive than I'd like.

VMikhelson

Premium Member

join:2000-01-05

Northbrook, IL VMikhelson to WhyADuck

Premium Member to WhyADuck

No Opus or +1 dialing was needed for me. Just changed to voice.telephony.goog.

-Vladimir



Anon6a9f5

@68.96.94.x Anon6a9f5 Anon Hooray! That works!



Megathanks to Mr Mikhelson!



WhyADuck

Premium Member

join:2003-03-05 WhyADuck to VMikhelson

Premium Member to VMikhelson

said by VMikhelson: No Opus or +1 dialing was needed for me. Just changed to voice.telephony.goog.

-Vladimir



Bill Simon's post at »



I just did not feel it was a particularly optimal situation to use a proxy without obihai in the address, but to use a registrar with obihai in the address if the latter could be easily avoided. I guess I just felt that if Google ever started looking for anomalous usage patterns, the fact that someone is using the proxy address intended for Android users along with the registrar address intended for Obihai users could be viewed as something that shouldn't be happening. I'm trying to choose my words carefully because I don't have any reason to actually think that Google would be on the lookout for that situation, but I just personally feel better about going all the way in using the Android-style connection as long as it works. I'm not saying anyone else should worry about that (or that they shouldn't), it's just my own personal comfort level at work here. And if you don't have the Opus codec installed for whatever reason, you probably cannot use the voice.sip.google.com registrar address, so you'd have to stay with obihai.sip.google.com in that case. You apparently misunderstood the situation. Just changing the instances of obihai.telephony.goog to voice.telephony.goog does NOT require you to change your outgoing dialing. It's only if you also change all instances of obihai.sip.google.com to voice.sip.google.com that you must have the Opus codec installed, and then use E.164-formatted dial patterns (the +1 at the start of a NANP number) on outgoing calls.Bill Simon's post at » community.freepbx.org/t/ ··· 0933/154 and his information post at » github.com/simontelephon ··· sip.info both mention the need for dial strings to be E.164-formatted, and my own personal experience confirms this, but apparently it's only true when using voice.sip.google.com as the registrar.I just did not feel it was a particularly optimal situation to use a proxyobihai in the address, but to use a registrarobihai in the address if the latter could be easily avoided. I guess I just felt that if Google ever started looking for anomalous usage patterns, the fact that someone is using the proxy address intended for Android users along with the registrar address intended for Obihai users could be viewed as something that shouldn't be happening. I'm trying to choose my words carefully because I don't have any reason to actually think that Google would be on the lookout for that situation, but I just personally feel better about going all the way in using the Android-style connection as long as it works. I'm not saying anyone else should worry about that (or that they shouldn't), it's just my own personal comfort level at work here. And if you don't have the Opus codec installed for whatever reason, you probably cannot use the voice.sip.google.com registrar address, so you'd have to stay with obihai.sip.google.com in that case.

gridbox

join:2018-10-12 3 recommendations gridbox to hapollo

Member to hapollo

said by hapollo: Since the frequency of GVSIP issues are more frequent now, anyone know of a script that can be used with Asterisk/Freepbx to monitor PJSIP status and kick out an email when Chan_PJSip Registrations in Asterisk Info page becomes rejected? Similar to when fail2ban rejects an IP or crontab sends an error after running.



Rather be a bit more pro-active if possible rather than reactive.. finding the trunk is down after picking up the phone to make a call only to fail is a bit more reactive than I'd like.



/var/lib/asterisk/scripts/check_pjsip_regs.sh

#!/bin/bash # # Command description: # # /usr/sbin/asterisk -rx "pjsip show registrations" - Get registrations from asterisk # sed '1,/=/d' - Skip header information from output # sed '/^$/d' - Remove all empty lines from output # head -n -1 - Remove last line from output ("Objects found..") # grep -v "Registered" - Match anything not registered. Grep will exit 0 when it matches and 1 when not matched. # # Example output: # # gvsip1/sip:voice.sip.google.com gvsip1 Rejected # /usr/sbin/asterisk -rx "pjsip show registrations" | sed '1,/=/d' | sed '/^$/d' | head -n -1 | grep -v "Registered"

Here is an example monit config that will monitor the asterisk process and the pjsip registrations and send an email on failure.



/etc/monit/conf.d/monitor_apps

set mailserver smtp.gmail.com port 587 username <USERNAME> password <PASSWORD> using tlsv12 set alert <ALERT EMAIL ADDRESS> set daemon 30 # Check every 30s set logfile syslog facility log_daemon set limits {programOutput: 1 kB} # Check asterisk process check process asterisk with pidfile /var/run/asterisk/asterisk.pid group asterisk start program = "/bin/systemctl start asterisk" stop program = "/bin/systemctl stop asterisk" # Check pjsip registrations check program pjsip-regs with path /var/lib/asterisk/scripts/check_pjsip_regs.sh as uid "asterisk" and gid "asterisk" timeout 30 seconds if status = 0 for 3 times within 10 cycles then alert

Example email



Status failed Service pjsip-regs Date: Sun, 14 Oct 2018 08:51:52 Action: alert Host: myhost Description: status failed (0) -- gvsip1/sip:voice.sip.google.com gvsip1 Rejected Your faithful employee, Monit I use monit for monitoring all of my services and programs. I have added an entry to monitor my pjsip registrations for unregistered/rejected registrationsHere is an example monit config that will monitor the asterisk process and the pjsip registrations and send an email on failure.Example email

VMikhelson

Premium Member

join:2000-01-05

Northbrook, IL 1 edit VMikhelson to WhyADuck

Premium Member to WhyADuck

WhyADuck,



Thank you for the clarification.



I actually did not get the dependencies completely. The reson I posted was my multi-year experience with Google Voice that often times their feature deployment was regional or staged.



Interestingly, in the XMPP era +1 dialing was a must. It could have been related to the specific proxy I was using though. Google also plays with Caller ID these days. If real CID number is provided account access by dialing own number is blocked even though all calls go through.



-Vladimir



AllThumbs

join:2006-02-07

Charleston, SC 1 recommendation AllThumbs to restamp

Member to restamp

said by restamp: I tend to agree with WhyADuck's interpretation: If Google really doesn't want us interacting with GV from Asterisk, why don't they just issue a statement to that effect. If they did, I would abide by it. Why play a cat and mouse game that wastes resources on both sides? My take is that Google acts much like Saudi Arabia. They want to be perceived as being a team player while doing what they damn well please behind everyone's back. As long as Google Voice is shrouded in secrecy, they can claim openness while doing everything possible to assure that it's just the opposite. ObiHai obviously paid them a pretty penny to be the exclusive (public) hardware interface to Google Voice. I'm guessing that the new ObiHai landlords aren't too pleased that Asterisk is taking away a big chunk of what they thought they were buying with the ObiHai deal. This would obviously be much more troubling if ObiHai is paying per registration which would now include all the Asterisk registrations as well.



jsolo1

Premium Member

join:2001-07-01 1 recommendation jsolo1 Premium Member said by AllThumbs: .... I'm guessing that the new ObiHai landlords aren't too pleased that Asterisk is taking away a big chunk of what they thought they were buying with the ObiHai deal. .... What are you basing this opinion on? I suspect if it was that troubling, they would of put a stop to it already. It's not entirely rocket science to set up an asterisk server but it also isn't something your typical novice will opt to do. We'll have to wait and see how things shake out this quarter.

twinclouds

join:2010-06-12

San Diego, CA twinclouds Member Sorry I lost track lately. Does gvsip works right at all. If yes, what I should do to make it work?