UPDATE:This problem seems to affect OUTBOUND calls only. Inbound Gtalk Calls Are received.
I have had Gtalk working nicely for some time and now when I dial I get a busy signal. CLI error messages:
[quote][Sep 27 21:48:39] WARNING[1093]: channel.c:5635 ast_channel_make_compatible_helper: No path to translate from Gtalk/18005551212@voice.google.com-03d7 to SIP/101-00000015
[Sep 27 21:48:39] NOTICE[19563]: chan_gtalk.c:1977 gtalk_parser: Remote peer reported an error, trying to establish the call anyway[/quote]
Is this a problem on my end or Google’s? If you have a Gtalk channel please test and post your results (working \ not working). It’s not clear to me what this error message means.
I ran a couple of quick jabber diagnostics:
root@athomehost:~# asterisk -rx "jabber show connections"
Jabber Users and their status:
[myAccount1] myAccount1@gmail.com/Talk - Connected
[myAccount2] myAccount2@gmail.com/Talk - Connected
I checked the gmail UI and it shows the message I configured in jabber.conf.
My ATA’s code is also setup to use multiple codecs. Here is my sip.conf:
@david55: do you have a suggestion action I can take to verify and correct the issue?
As I re-read the error message (above), this seems like a routing issue (no path). Gtalk was working nicely (except when Google boogered up there side) for several months and now I am seeing a problem. I have been attempting to optimize sip traffic so that it uses G729 instead of ulaw lately, however, I don’t think this is a problem because I do not force G729: I make it optional along with ulaw. The other SIP endpoint (callcentric.com) supports G729 and the ATA is setup so that if given the choice, it will use G729, otherwise it will use ulaw.
It’s a route through the codec translations, not through the network.
[code] /* Set up translation from the ‘from’ channel to the ‘to’ channel */
src = from->nativeformats;
dst = to->nativeformats;
/* If there's no audio in this call, don't bother with trying to find a translation path */
if ((src & AST_FORMAT_AUDIO_MASK) == 0 || (dst & AST_FORMAT_AUDIO_MASK) == 0)
return 0;
if (ast_translator_best_choice(&dst, &src) < 0) {
ast_log(LOG_WARNING, "No path to translate from %s(%d) to %s(%d)\n", from->name, src, to->name, dst);
return -1;
}
[/code]
[code]/*!
\brief Chooses the best translation path
Given a list of sources, and a designed destination format, which should
I choose?
\return Returns 0 on success, -1 if no path could be found.
\note Modifies dests and srcs in place
*/
int ast_translator_best_choice(int *dsts, int *srcs);
UPDATE: Inbound GV through the Gtalk channel seems to work. Only outbound has problems.
@david55: excellent detective work. Thanks for making it explicit \ clarifying. Is there anything that can be done to remedy this problem? Thank you.
I am providing additional information below in the hope that it will be enough to provide a diagnosis that results in a remedy or a determination that the problem is on Google’s side. I tried rebooting (hard \ soft) and had temporary success.
[quote]Today, Google Talk supports the following standard voice codecs:
•PCMA
•PCMU
•G.722
•GSM
•iLBC
•Speex
We also support the following codecs from Global IP Sound: ISAC, IPCMWB, EG711U, EG711A.[/quote]
Based on past traffic from successful calls, I believe that the EG711u codec was used.I don’t think that my codecs have changed: I have posted an image of my ATA’s configuration below. It is setup to use negotiate from multiple codecs.
Traffic Snapshot to ID Codec (from successful Gtalk call setup)
athomehost*CLI> jabber set debug on
Jabber Debugging Enabled.
