SOLVED Google Voice: Outgoing call ended when external party picks up.

jpstaub

New Member
Joined
Apr 8, 2016
Messages
9
Reaction score
4
Hardware configuration:
1. Asterisk Server: Raspberry Pi 2
2. IP Phone: Grandstream 1625
3. Trunk: Google Voice (advertises support for PCMA/PCMU/G.722/GSM/iLBC/Speex).​

Software configuration:
1. IncrediblePBX13-Rasbian8-GVOAUTH
A. IncrediblePBX 12.0.74
B. Asterisk 13.7.2​
2. Grandstream firmware version 1.0.2.4.​

Problem: Outgoing calls over Google Voice ended when external party picks up the call on their end.
System progression:
1. Call dialed
2. Grandstream rings normally
3. External party receives normal ring
4. External party picks up the call
5. Grandstream reports call failed after the external party picks up
6. External party gets hang-up tone.​

From Asterisk log file:
[2016-04-11 09:42:19] WARNING[9337][C-0000000a] channel.c: No path to translate from Motif/[email protected] to SIP/103-0000000c
[2016-04-11 09:42:19] WARNING[9337][C-0000000a] app_dial.c: Had to drop call because I couldn't make SIP/103-0000000c compatible with Motif/[email protected]

Note: Log file WARNING points to a CODEC version problem between the IP phone and Google Voice.

Fix:
1. Goto Incredible GUI Administration>Settings>Asterisk SIP Settings
2. Ensure at least one Google Voice supported CODEC is active
3. Ensure Google Voice supported CODECs are stacked above other activated CODECs
4. Click "Submit" button
5. Click "Apply Config" button
6. Enjoy Google Voice connectivity.​

Trouble with the fix (on Grandstream IP phone and possibly on other endpoints as well):
Asterisk appears mechanized in such a way that it looks for a compatible CODEC between the Endpoint and the SIP trunk by following the order in which activated CODECs are listed in "Asterisk SIP Settings." As a result, trunks that support CODECs of higher audio quality are degraded to the lowest common CODEC supported by Google Voice.

Overall:
It appears there is a software incompatibility between Grandstream, Asterisk, and Google Voice. Zoiper softphone endpoints did not suffer from the same CODEC handshake problem when evaluated under the same conditions. The fix above produces acceptable results although it does result in a theoretical degradation in system capability if trunks that support CODECs of higher audio quality are present. There may be a setting within the Grandstream firmware that would resolve the problem as well. However, I am not experienced enough to know what that setting would be.
 

billsimon

Experienced in Asterisk, FreePBX, and SIP
Joined
Jan 2, 2011
Messages
1,014
Reaction score
336
3. Trunk: Google Voice (advertises support for PCMA/PCMU/G.722/GSM/iLBC/Speex).
Is this in the SDP you get from Google Voice when negotiating a call? Last I saw they were only negotiating PCMU/PCMA. Sticking to PCMU end-to-end for GV calls will probably be your best bet.
 

jpstaub

New Member
Joined
Apr 8, 2016
Messages
9
Reaction score
4
Is this in the SDP you get from Google Voice when negotiating a call? Last I saw they were only negotiating PCMU/PCMA. Sticking to PCMU end-to-end for GV calls will probably be your best bet.
Thanks for turning me on to SDP. Where are SDP messages found within IncrediblePBX? It'd be interesting to see what Google Voice is sending.

Based on the Grandstream LCD readout which displays the active CODEC during a call I can say Google Voice supports G.722.

See FAQ: Open Communications for Google Talk supported CODECs.

I'll keep PCMU in mind as a fallback for future GV degradation.
 

billsimon

Experienced in Asterisk, FreePBX, and SIP
Joined
Jan 2, 2011
Messages
1,014
Reaction score
336
Turning on xmpp debug, it looks something like this:

Code:
<ses:session type="initiate" id="SIPT_8uGNneRjD_6OEZ_12022087311550872940" initiator="[email protected]/srvenc-0GEJOWSifWHtby+H/G1yH84HDvKUhRJw" xmlns:ses="http://www.google.com/session">
    <pho:description xmlns:pho="http://www.google.com/session/phone">
      <pho:payload-type id="0" name="PCMU" clockrate="8000"/>
      <pho:payload-type id="101" name="telephone-event"/>
    </pho:description>
    <transport behind-symmetric-nat="false" can-receive-from-symmetric-nat="false" xmlns="http://www.google.com/transport/raw-udp"/>
    <transport xmlns="http://www.google.com/transport/p2p"/>
  </ses:session>
In this incoming call, GV only offered PCMU (id 0) and RFC2833 DTMF (id 101).
 

jpstaub

New Member
Joined
Apr 8, 2016
Messages
9
Reaction score
4
<--- XMPP sent to 'gmailcom' --->
<description xmlns='urn:xmpp:jingle:apps:rtp:1' media='audio'>
<payload-type id='0' name='PCMU' channels='1' clockrate='8000'/>
<payload-type id='101' name='telephone-event' channels='1' clockrate='8000'/>​
</description><transport xmlns='urn:xmpp:jingle:transports:ice-udp:1'/>​

Hmm. Grandstream LCD shows G.722. XMPP says PCMU. Can't place a Google call with G.729 on top of the CODEC stack in SIP settings. At this point I'm just glad to have muddled my way to a workable solution.
 

Members online

No members online now.

PIAF 5 - Powered by 3CX

Forum statistics

Threads
22,564
Messages
138,894
Members
14,672
Latest member
evilcocuyo