Asterisk Google Voice SIP testing and technical discussion
On 7/18/2018, Google turned off the old XMPP interface to Google Voice, previously implemented in asterisk as chan_motif.
The replacement interface, officially used by the google voice "wifi calling" mode as well as obihai ATAs, is based on various SIP protocols. See community-sourced documentation here: »gvsip.info/
The old method, shown below, is no longer recommended and uses an incompatible config template.
[original text follows...] Google has threatened (but not taken action yet) to remove the old XMPP interface implemented in asterisk as chan_motif that supports GV trunks. [EDIT: as of 7/18/2018, action has been taken. XMPP appears to be dead]
The replacement interface, officially used by the google voice "wifi calling" mode as well as obihai ATAs, is based on various SIP protocols. See community-sourced documentation here: »gvsip.info/
Ongoing work on modifying/configuring asterisk to support the new SIP protocol suite for GV trunks is currently hosted on github here: »github.com/naf419/asteri ··· ee/gvsip
Although the current code/config can make and receive test calls, there are still technical details to be worked out. The purpose of this thread is to exchange technical info and test results.
To access the code changes, you may: - clone the repo's gvsip branch (git clone »github.com/naf419/asterisk.git --branch gvsip) - download the gvsip branch directly as a tgz (not zip cause that loses all file permissions): »api.github.com/repos/naf ··· ll/gvsip - download the gvsip branch as a patch and apply it against asterisk 13.21.1 (it wont be clean but it worked at last check): »github.com/naf419/asteri ··· ip.patch
ETA: so with the 'r', asterisk relays the 180 Ringing down to the softphone when it receives it from GV. without the 'r', it doesn't relay the message, but it does whatever magic on the GV-side to keep GV happy. we need a combination of the two...
Unless things have recently improved in Asterisk, the 'r' option (with a non-GV trunk) just sends a 180 to the phone, in lieu of any early media, undesirable except as a last resort. I'm reasonably sure that GV requires incoming media while the called phone is being rung, otherwise after a timeout you get the 603. With 'r', the phone never gets the 183 needed to cause it to send media (which Asterisk would then relay to GV, keeping it happy).
There are a couple of related options in Asterisk. I hope that there is a combination which causes it to send in-band ringback tone to the phone, while still relaying media from phone to GV. See »support.broadvoice.com/w ··· ing-back .
Even if the above works, I suspect that any early media announcements from GV will be overridden with the ringback tone. If that's the case, fixing it properly would require triggering the locally-generated ringback tone by the 180 from the trunk, passing normal 183 early media otherwise.
Just to confirm, with RTP debugging on I just verified what you say is correct:
without r Dial option (softphone doesnt ring but call completes) from softphone: INVITE w/sdp to softphone: 100 Trying to GV: INVITE w/sdp from GV: 100 Trying from GV: 183 Session Progress w/sdp to softphone: 183 Session Progress w/sdp (RTP packets start being exchanged) from GV: 180 Ringing (25 seconds elapses) from GV: 200 OK w/sdp to GV: ACK to softphone: OK w/sdp from softphone: ACK
With r Dial option (softphone rings, but call is aborted by gv) from softphone: INVITE w/sdp to softphone: 100 Trying to softphone: 180 Ringing to GV: INVITE w/sdp from GV: 100 Trying from GV: 183 Session Progress w/sdp from GV: 180 Ringing to softphone: 180 Ringing (23 seconds elapses) from GV: 603 media inactivity to GV: ACK to softphone: 503 Service Unavailable from softphone: ACK
I've sent you my log when I met SSL_ERROR_ZERO_RETURN via IM.
It seems to happen randomly after couple hours of running asterisk. Run Module Reload in cli will fix it for the moment.
Your INVITE to GV is coming back with a 403 Forbidden response. I would assume GV closes the connection after this.
Hard to say why without a *complete* log showing the REGISTER message traffic... (or lack thereof?), but it sure sounds like the re-register after ~50 minutes failed with a stale token, a problem that was fixed already...
Regarding lack of ringback, are there any numbers to test where google sends something other than the 183 with silent audio followed by the 180 ringing, or is that what it does every time?
Regarding lack of ringback, are there any numbers to test where google sends something other than the 183 with silent audio followed by the 180 ringing, or is that what it does every time?
Regarding lack of ringback, are there any numbers to test where google sends something other than the 183 with silent audio followed by the 180 ringing, or is that what it does every time?
1 631 265 0000 ?
Good call. No 180 Ringing there. OK, so everytime we see the 180 Ringing we need to (somehow) convince the device to ring? Are devices going to be okay with seeing a 180 Ringing at the same time as sending media, or do we have to splice a ringing sound into the media itself?
ETA: or just send the word out that that phone ain't ringing, but the calls are still free so you get what you pay for
In the absence of a 180 from GV, it should behave as it does now (early media exchanged both ways with phone).
If a 180 comes in, IMO Asterisk should start sending ringback tone in the media stream to the phone, in lieu of the silent stream that GV is presumably still sending. I believe that's what the Inband Progress option does, but be sure that the fake ringback tone is not unconditional (it should not be sent unless a 180 was received) and that it does not interrupt the outbound media stream needed to keep GV alive.
Found a third case: calling a Tello phone#, i get the 183 Session Progress but then the RTP media is *not* silent and does have the ringback tone already coming from GV. (using the same config, calling a Fi phone# has no ringback tone in the media)
Having *some* nonempty streams makes it seem like its GV fucking up and forgetting to put the ringback tone into the stream on their end, and there's nothing we can/should do about it on our end? surely we wont be having code to detect silence and conditionally splice in audio based on that and the presence of a 180...
P.S. i dont see any code related to progressinband or inband_progress that does anything to the rtp stream. its all manipulating the control 180/183 messages as far as I see.
The core handles tone generation. The return value of the "chan_pjsip_indicate" function does it. If "-1" is returned then the core knows to generate the tone.
Insert third attempt to clarify here as this is complicated. The chan_pjsip_indicate function is invoked on a channel to tell it 'hey, send ringing, or busy, or etc'. The inband_progress setting causes some of those to become audio instead. This is done by chan_pjsip_indicate returning a -1 which tells the core to generate ringing.
This is not for the case where we are externally told that something is ringing or there is progress. (ie: we receive a 180 Ringing). There is nothing for that, as we generally just raise the information and pass it through the core. This is the case for an outbound call to Google Voice.
The core handles tone generation. The return value of the "chan_pjsip_indicate" function does it. If "-1" is returned then the core knows to generate the tone.
Ah yes, I missed that, thanks. [this is why it doesn't say 'naf' at the top of the file ]
OK so there is existing infrastructure to make a tone if we need it use it, but we still have the "we don't know if GV is already putting the ringback tone in the media or not" problem. (or maybe not, if we just overwrite the incoming possibly-ringing media only when we see a 180 Ringing from GV, in which case we dont really care if it previously had silence or ringing?)
IMHO, there is no need to "listen" for silence. If there is a 183 and no 180, there is almost certainly an announcement, ringback tone, busy tone, etc. from the carrier. Just send it to the phone; in the rare case that it's silent, let's hope that the caller doesn't hang up before it's answered.
If there is a 180, substitute local ringback tone for whatever media may be coming in. Though an announcement would lost, that would be a carrier error, because 180 specifically means that the called party is being alerted.
I leave to catch a plane in an hour, so won't be able to post for a while.
SO I am not well versed in any of this, but RFC 3960 seems to cover these 3 scenarios very well.
1. Unless a 180 (Ringing) response is received, never generate local ringing.
2. If a 180 (Ringing) has been received but there are no incoming media packets, generate local ringing.
3. If a 180 (Ringing) has been received and there are incoming media packets, play them and do not generate local ringing.
Note that a 180 (Ringing) response means that the callee is being alerted, and a UAS should send such a response if the callee is being alerted, regardless of the status of the early media session.
Google will do as Google likes re: RFCs and standards. ^_^ or more specifically, Google will use standards as a base and drive them - but ultimately in their own interest diverge and do their own thing. Particularly with pseudo-open systems (like this new one). They have control (or a relationship in the case of Obihai) and don't have to truly implement standards or be beholden to them.
As for the other two comments...
There is a tone generation API, and users of it, but I don't think there's anything specifically for the use case of replacing the incoming audio from a channel with it. It's a rabbit hole kind of depending on where the change is done, because off the wire has no translation stuff (it's done in the core automatically - channel drivers like PJSIP just pass the media they get up unmodified) so if the logic is pushed into chan_pjsip on the read path, you have to take that into account and translate accordingly.
Google will do as Google likes re: RFCs and standards.
Asterisk as well? If spec says "a UAS should send such a response if the callee is being alerted, regardless of the status of the early media session." then why does asterisk not forward the received 180 onto the client instead of suppressing it just because theres a media sesssion in progress? (not that the client would do anything with it, since its supposed to play the media session instead of ringing anyway)
I got it that Google does as Google wants. But given what is being seen, are you saying there are instances where Google is sending the 180, media packets are being received, but there is no inband ring audio?
The PJSIP behavior in some areas is generally modeled after chan_sip, as it's been around for many years and has been used against a myriad of endpoints. That could be the case for that. You can open an issue if you'd like, but I don't know when it would get looked into as in practice it hasn't been a problem for anything else. It may also be a limitation of the core itself.
From what I understand (I'm not working on this, just answering questions and providing help where I can) yes - there's a silent audio stream except sometimes it's not silent
From what I understand (I'm not working on this, just answering questions and providing help where I can) yes - there's a silent audio stream except sometimes it's not silent
I'd give out a test number where there's silent audio, but its my wife's # and I think she might suspect my involvement if a buncha internet strangers start blowing up her phone
Thanks for the clarification. I am just trying to understand what is being seen and have not been able to pick up on that from the current posts.
So in that case, I don't think anything should be changed in code in order to "fix" this. Wonder if there is an option in pjsip to always ignore media and always provide local ring audio until answer.
Again, I have not dug into any sip for a while so am very rusty on config options.
There is no option within PJSIP to do such a thing, as it's counter to what most individuals would want. The only thing available, which was mentioned previously, is the 'r' option to Dial to always provide ringing.
There is no option within PJSIP to do such a thing, as it's counter to what most individuals would want. The only thing available, which was mentioned previously, is the 'r' option to Dial to always provide ringing.
And the problem with using that option is that without the early media google gives up on the call after about 20 seconds. (sucks if voicemail would have kicked in at 25s)
You need to CANCEL using the same Route: headers that you INVITE'd with. I had the same bug in my implementation. CANCEL is a new request (not a reply) which is why the method in CSeq changes.
You need to CANCEL using the same Route: headers that you INVITE'd with. I had the same bug in my implementation. CANCEL is a new request (not a reply) which is why the method in CSeq changes.
I've sent you my log when I met SSL_ERROR_ZERO_RETURN via IM.
It seems to happen randomly after couple hours of running asterisk. Run Module Reload in cli will fix it for the moment.
maxm, you still having those intermittent outbound call rejection issues? i saw your full log, but i haven't gleaned any insights from it (other than that you make a lot of calls)
I just updated to your latest version this morning and I'll keep eye on the SSL_ERROR.
As for 603 inactive media, removing the r in dial plan (extension.conf) actually fixed the problem with my tmobile cellphone. I could hear ring and could reach voicemail after 25s now. I don't know if it's because I am using a Yealink T46s ip phone which has work around for 183/180 built-in. (»support.yealink.com/faq/ ··· fo?id=54).
And yes, I make a lot of calls, lol. I'll keep you posted if I see anything.
Update: I tried calling another google voice number, NO Ring..., but can reach voicemail after 25s.