[Home]

Summary:ASTERISK-17849: [patch] inbound call from google voice fail
Reporter:Jeremy Kister (jkister)Labels:
Date Opened:2011-05-12 22:24:14Date Closed:2011-06-14 18:04:16
Priority:MajorRegression?
Status:Closed/CompleteComponents:Channels/chan_gtalk
Versions:1.8.3 Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) console.txt
( 1) extensions.conf
( 2) externip-allowhostname-v3.patch
( 3) gtalk.conf
( 4) jabber.conf
Description:When the call comes in, asterisk immediately prints on the console:

  == Spawn extension (google-in, s, 2) exited non-zero on
'Gtalk/+12155551212-f947'
[May 12 22:47:18] NOTICE[13835]: chan_gtalk.c:1977 gtalk_parser: Remote
peer reported an error, trying to establish the call anyway
Comments:By: Jeremy Kister (jkister) 2011-05-12 22:35:04

the issue is that in previous versions of Asterisk, a DNS name in 'externip' of gtalk.conf was perfectly valid.  somewhere along the way, a limit of 15 characters was introduced, which would work if only ipv4 addresses were permitted.

so instead of 'router.example.net' being sent to google, asterisk was sending 'router.example.'

there is no reason for only an ip address to be used as a value to the externip parameter.  a dyndns name works just fine.


By: Jeremy Kister (jkister) 2011-05-12 22:51:22

i'm not convinced simply letting externip = 256 is the right answer, as sip.conf has a 'externhost' parameter, which we wouldnt want to confuse.

but in gtalk, i believe it's just /spelled/ externip, it could be called 'externthing' or 'externdoohicky' just the same.
By: Terry Wilson (twilson) 2011-06-14 17:12:33.904-0500

Since we call ast_gethostbyname on the 'ip' anyway, this looks sane--if confusing. I'll probably go ahead and commit it as-is and just add some documentation about why an "ip" is so long in 1.8. Maybe in trunk we eventually add externhost and change all of the 'ip' references to 'host' references.
By: Terry Wilson (twilson) 2011-06-14 17:20:44.204-0500

Although not for chan_jingle, because we just call inet_aton on externip.
By: Terry Wilson (twilson) 2011-06-14 17:51:37.352-0500

Actually, after investigating further, this actually sends address="whataver.externip.has" as a candidate back to google. They are apparently resolving it on their end, but I can't find anything that says that they guarantee that they will. All of the messages they send specify only an ip address in that field. The Jingle spec, which they don't actually follow, doesn't have an address field, but an ip field.

It seems like the best thing to do would be to if you use dynamic is to use stun and not externip/host. This should guarantee that things work now and if google stops resolving that address on their end. I'd prefer not to encourage an abuse of the externip field.
By: Terry Wilson (twilson) 2011-06-14 18:04:16.082-0500

I recommend just using the stunaddr field to get a proper IP address put into the externip field. Please see my previous comment for my reasoning.

If for some reason this doesn't work for you as a solution, feel free to re-open for discussion.
By: Jeremy Kister (jkister) 2011-06-14 18:57:14.361-0500

Totally agree not to abuse the externip field.  

Asterisk should do something other than fail quietly when a value > 15 characters is used.  perhaps logging to console/messages to say 'gtalk disabled because externip is too long'.  and a note for ipv6 incompatibility should be added as well.