[asterisk-bugs] [Asterisk 0012569]: Receiving Text from chan_gtalk

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=12569 
====================================================================== 
Reported By:                eech55
Assigned To:                phsultan
====================================================================== 
Project:                    Asterisk
Issue ID:                   12569
Category:                   Channels/chan_gtalk
Reproducibility:            always
Severity:                   feature
Priority:                   normal
Status:                     ready for testing
Asterisk Version:           SVN 
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 115340 
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             05-02-2008 00:38 CDT
Last Modified:              05-16-2008 07:28 CDT
====================================================================== 
Summary:                    Receiving Text from chan_gtalk
Description: 
Hello,

So far, chan_gtalk sends text to GTalk clients only. There is no way to
hear input from them which limit us a lot.

It will be awesome if we are able to receive text from GTalk users, to
provide extra services such as:

1) Voice menus. The user can select menus by sending corresponding keys
2) Or, "text" menus by which the chan_gtalk replies by text messages
instead of voice

I am glad that phsultan thought about it, however very disappointed that
it was canceled.
http://bugs.digium.com/bug_view_advanced_page.php?bug_id=8659


======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0008659 [patch] Add a jabber text receiver appl...
====================================================================== 

---------------------------------------------------------------------- 
 eech55 - 05-16-08 07:28  
---------------------------------------------------------------------- 
> [sip-context]
> exten => s,1,answer()
> exten =>
s,n,JabberSend(asterisk,philippe.sultan at gmail.com,${CALLERID(name)} is >
trying to call ${EXTEN}, allow?)
> exten => s,n,JabberReceive(philippe.sultan at gmail.com,RCV_EXT)
> ... string comparison, etc. ...
Looks interesting. Will try it later on.

Just applied the trunk-12569-3.diff patch. All went as expected, and I was
able to use the ${CALLERID(name)} variable.

Regarding JabberReceive application. In addition to the extra timeout
argument, I think it would be great if we have a timeout action as well. To
provide a professional end user experience, by sending him a friendly
message instead of the immediate call termination.

Since a timeout message could be more than merely sending text messages, I
think it would be more scalable (to adapt future applications as well) to
jump to another step. Similar to the Dial application timeout, which moves
to 101+ step, where a timeout action is specified (e.g.
s,102,playback(tt-allbusy)

Personally, I think hard coding an offset (e.g. +101) may not be very
scalable, just in case the context grows or complicates. I think having a
default value, while allowing the choice of setting a manually step number
via a forth JabberReceive argument would be the safest choice. For
example:

[gtalk-in]
exten => s,1,answer()
exten => s,n,SendText("What extention would you like to call?")
exten => s,n,JabberReceive(${CALLERID(name)},RCV_EXT,10,105)
exten => s,n,SendText("Please wait, calling ${RCV_EXT}..")
exten => s,n,goto(family,${RCV_EXT},1)
exten => s,n,hangup()
exten => s,105,SendText("We are sorry. Too late response. Bye.")
exten => s,n,hangup()

In the above example, timeout is set to 10, and timeout action step is set
to 105.

One more thing that seems irrelevent to the patches. I found an Asterisk
crash condition, that exists without the patches as well, including the
latest chan_gtalk.c and res_jabber.c SVNs.

Asterisk crashes when a GTalk user calls Asterisk's JID and immediately
ends the call prior to Asterisk answering the call. I repeated this
multiple times, and Asterisk crashed every time the GTalk user repeated
that condition.

Here's the CLI output:
http://sial.org/pbot/31055?tx=on&submit=Format+it%21 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
05-16-08 07:28  eech55         Note Added: 0086938                          
======================================================================