[Home]

Summary:ASTERISK-22176: Google Voice Incoming And Outgoing Calls Fail With Certain Google Voice Accounts
Reporter:Vladimir Mikhelson (vmikhelson)Labels:
Date Opened:2013-07-21 14:43:34Date Closed:2013-07-23 08:16:42
Priority:MajorRegression?
Status:Closed/CompleteComponents:Channels/chan_gtalk Resources/res_jabber
Versions:1.8.23.0 Frequency of
Occurrence		Constant
Related
Issues:
Environment:Centos 5.9, FreePBX 2.11.0.9Attachments:( 0) Failed_Incoming_Call.txt
( 1) Failed_Outgoing_Call.txt
( 2) Successful_Incoming_Call.txt
( 3) Successful_Outgoing_Call.txt
Description:Incoming calls do not get any response from Asterisk, whereas outgoing calls connect intermittently but with no audio.

The problem is manifested for certain Google Voice accounts.  Can be related to the Hangout+ conversion by Google
Comments:By: Vladimir Mikhelson (vmikhelson) 2013-07-21 14:44:53.126-0500

These are samples of the Jabber debug for successful and failed calls.
By: Vladimir Mikhelson (vmikhelson) 2013-07-21 14:47:27.209-0500

The obvious difference for the failed incoming call is the absence of the "nick:" structure, but the code suggests it is optional.

<nick:nick xmlns:nick="http://jabber.org/protocol/nick">Vladimir Mikhelson</nick:nick>

Further troubleshooting proved some calls succeed with no "nick".  So it is something else.
By: Vladimir Mikhelson (vmikhelson) 2013-07-21 18:14:13.857-0500

Another piece of information.

For a successful incoming call the debug message sequence is as follows:

[2013-07-21 17:16:08] DEBUG[6843] res_jabber.c: JABBER: Handling paktype IQ
[2013-07-21 17:16:08] DEBUG[6843] chan_gtalk.c: The client is guest for alloc
[2013-07-21 17:16:08] DEBUG[6843] rtp_engine.c: Using engine 'asterisk' for RTP instance '0xb5f7a630'
[2013-07-21 17:16:08] DEBUG[6843] res_rtp_asterisk.c: Allocated port 14822 for RTP instance '0xb5f7a630'
[2013-07-21 17:16:08] DEBUG[6843] rtp_engine.c: RTP instance '0xb5f7a630' is setup and ready to go
[2013-07-21 17:16:08] DEBUG[6843] res_rtp_asterisk.c: Setup RTCP on RTP instance '0xb5f7a630'
[2013-07-21 17:16:08] DEBUG[6843] rtp_engine.c: Setting payload 0 based on m type on 0xb5f7a7dc
[2013-07-21 17:16:08] DEBUG[6843] rtp_engine.c: Setting payload 101 based on m type on 0xb5f7a7dc
[2013-07-21 17:16:08] DEBUG[6843] rtp_engine.c: Incorporating payload 0 on 0xb5f7a7dc
[2013-07-21 17:16:08] DEBUG[6843] rtp_engine.c: Incorporating payload 101 on 0xb5f7a7dc

For a failed call it is:

[2013-07-21 16:50:01] DEBUG[9608] res_jabber.c: JABBER: Handling paktype IQ
[2013-07-21 16:50:01] DEBUG[9608] res_jabber.c: XML parsing successful

It looks like by the programmer's logic the message "XML parsing successful" means failure.  At least this message is nowhere in the successful transaction message sequence.

By: Vladimir Mikhelson (vmikhelson) 2013-07-22 23:34:51.570-0500

Started more in-depth troubleshooting.

Verified incoming calls still fail in the same exact way, i.e. chan_gtalk.c did not get control.

Started by adding some debugging output in chan_gtalk.c / gtalk_newcall.

Recompiled Asterisk, observed a number of modules recompiled. Installed. Started.

Amazingly, everything started working for incoming calls as expected. Observed my debugging output in the console screen.

Removed my modifications, recompiled. This time just chan_gtalk.c was recompiled. Re-tested, everything still worked.

I am not sure what to make out of it.  It was either a coincidence and Google fixed something on their end or my installation was somehow corrupt.
By: Vladimir Mikhelson (vmikhelson) 2013-07-22 23:39:05.378-0500

Outgoing calls work as well.

Closing the case as resolved by re-compilation of Asterisk.
By: Vladimir Mikhelson (vmikhelson) 2013-07-22 23:39:40.037-0500

Fixed by recompilation of the current version 1.8.23.